Log Analytics、およびOperation Management Suiteの使い方(Part1)

AzureにおけるLog Analytics、およびOperation Management Suite(以下OMS)を利用した、ログの分析や監視方法を紹介する。
今回は、Azure上でLog Analyticsをデプロイして、OMSでログを表示するところまでを紹介する。

1.Azureポータルから、[Log Analytics]からOMSワークスペースを追加する。

f:id:AmaDablog:20170410191932p:plain


2.[ワークスペースのデータソース]より、[仮想マシン]から、監視対象とする仮想マシンを選択し、[接続]をクリックする。

f:id:AmaDablog:20170410191953p:plain

3.[OMSポータル]をクリックし、OMSポータルにアクセスする。

f:id:AmaDablog:20170410192029p:plain

4.OMS画面より、[設定]-[Data]-[Windows イベントログ]より、収集したいログを追加する。

f:id:AmaDablog:20170410192840p:plain

5.[設定]-[Preview Features]から、Power BIやCustom Logsを有効化する。

のちのち、Power BI連携を実装するため、機能を有効化する。

f:id:AmaDablog:20170410193008p:plain

6.[設定]-[Accounts]-[Workspace Information]より、Power BI用のアカウントを追加する。

のちのち、Power BI連携を実装するため、アカウントを追加しておく。

f:id:AmaDablog:20170410193242p:plain

7.[ログ検索]より、クエリ文を入力すると、収集したログが表示される。

f:id:AmaDablog:20170410193437p:plain

※ログ検索参考資料

Log Analytics 検索リファレンス

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fja-jp%2Fazure%2Flog-analytics%2Flog-analytics-search-reference&data=02%7C01%7CMAKURODA%40064d.mgd.microsoft.com%7Cba710c4f72994dbb4b3c08d47bfbb1fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636269768356731482&sdata=az65Z5bXoUCH%2BHdqhNLPLtH%2BO%2FAmF%2BIdZKtmPuMy%2FT4%3D&reserved=0

 

正規表現を使用した Log Analytics のログ検索のフィルター処理

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fja-jp%2Fazure%2Flog-analytics%2Flog-analytics-log-searches-regex&data=02%7C01%7CMAKURODA%40064d.mgd.microsoft.com%7Cba710c4f72994dbb4b3c08d47bfbb1fc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636269768356731482&sdata=Na0J69Ihd0BXhqfMtPMHKi0doGijY5JuLeAn1T2rmBI%3D&reserved=0

以上。

次回は、OMSを利用した死活監視設定を紹介予定。

Windows Server 2016のOS設定(簡易版)

これから、Windows Server 2016でドメインの構築やSystem Center Configuration Manager 2016(以下SCCM)の構築、SCCMとIntuneの連携等を検証していきたいと思う。
まず、今日はAzureでWindows Server 2016を構築した後の、言語やロケールタイムゾーンの設定方法を記載する。
Windows Server 2012 R2の頃とあまり変わってなく、混乱する箇所はない。


1.言語の追加
まず、AzureでWindows Server 2016をデプロイすると、Windows 10と一緒のデスクトップが表示される。

Windowsボタンを右クリックし、[Control Panel]を起動する。

f:id:AmaDablog:20170308094251p:plain

 

 

[Clock,Language, and Region]-[Add a language]をクリックする。

f:id:AmaDablog:20170308094408p:plain

[Change your language preferences]より、[Add a language]をクリックする。

f:id:AmaDablog:20170308095452p:plain

[Add a language]より、[日本語]を選択し、[Add]をクリックする。

f:id:AmaDablog:20170308095518p:plain
[Change your language preferences]より、[日本語]追加されていることを確認し、[Options]をクリックする。

f:id:AmaDablog:20170308095728p:plain

[Download and install language pack]をクリックする。

f:id:AmaDablog:20170308095804p:plain

[Download and Install Updates]画面より、ダウンロードが開始されたことを確認する。

f:id:AmaDablog:20170308095817p:plain

[Download and Install Updates]画面より、インストールが完了したことを確認する。

f:id:AmaDablog:20170308095833p:plain

[Change your language preferences]より、[日本語]をクリックし、[Move up]をクリックする。

f:id:AmaDablog:20170308100006p:plain

※サインアウト/サインインしなければ反映されないが、ここではサインアウトせず後続の作業を続ける。


2.主な使用場所の変更
[Language]画面の左ペインより、[Change date,time,or number formats]をクリックする。

f:id:AmaDablog:20170308100100p:plain

[Region]画面より、[Location]タブをクリックし、[Home location]を[Japan]に変更し、[Apply]をクリックする。

f:id:AmaDablog:20170308100117p:plain

 

3.ようこそ画面と新しいユーザーアカウント
[Administrator]タブより、[Welcome screen and new accounts]セクションの[Copy settings]をクリックする。

f:id:AmaDablog:20170308100138p:plain
[Welcome screen and system accounts]と[New user accounts]にチェックを入れ、[OK]をクリックする。

f:id:AmaDablog:20170308100156p:plain
※再起動が求められるが、一旦[Cancel]をクリックする。

 

4.システムロケールの変更
[Administrator]タブより、[Language for non-Unicode programs]セクションの[Change system locale]をクリックする。

f:id:AmaDablog:20170308100225p:plain

[Region Settings]画面より、[Current system locale]を[Japanese(Japan)]を選択し、[OK]をクリックする。

f:id:AmaDablog:20170308100403p:plain
※再起動が求められるが、一旦[Cancel]をクリックする。

 

5.タイムゾーンの変更
Windowsボタンをクリックし、歯車マークをクリックする。

f:id:AmaDablog:20170308100414p:plain

[Time & language]をクリックする。

f:id:AmaDablog:20170308100537p:plain

[Date and time]画面より、[Time zone]を[(UTC + 09:00)Osaka,Sapporo,Tokyo]を選択し、右上の×をクリックする。

f:id:AmaDablog:20170308100553p:plain

 

6.適用
[Region]画面より、[Close]をクリックする。

f:id:AmaDablog:20170308100619p:plain

再起動が求められるので、[Restart now]をクリックする。

f:id:AmaDablog:20170308100834p:plain

今回は簡単なOS設定を記載した。
次回は、Windows Server 2016でドメイン構築、およびSCCM用のスキーマ拡張を記載する予定である。

 

 

 

 

self-service password reset展開のポイント

Microsoft社のエンジニアの話を聞く機会があり、SSPRを展開するための技術やお客様へのアプローチ方法等興味深い話を聞くことができた。
技術面で私が思い違いがあった個所や、展開時のポイントになりそうなことを記載しておく。

・オンプレミスからAzure ADへディレクトリ同期している環境でもリアルタイムでパスワードが書き戻しされる
※Azure AD Connectの同期間隔で書き戻しされるわけではない
・SSPRを利用してもパスワードがAzure上で保持されるわけではない
・セキュリティグループを利用した段階的な展開が可能
・認証ポリシーはセキュリティグループ等を利用した別々のポリシーを設定することができない

https://docs.microsoft.com/ja-jp/azure/active-directory/active-directory-passwords
https://docs.microsoft.com/ja-jp/azure/active-directory/active-directory-passwords-getting-started

AD FSトークン署名のSHA-1対応

グーグルとオランダの研究機関による、中核的な暗号技術「SHA-1」の解読に成功したニュースを見て、身の回りでSHA-1のハッシュアルゴリズムを利用している証明書がないかを確認し、Windows Server 2012 R2で動作するAD FSのトークン署名を思い出した。

AD FSではトークン署名のアルゴリズムとして、SHA-1とSHA-256に対応をしている。
例えばOffice 365の証明書利用者信頼では、既定値でSHA-1が選択される。
AD FSと連携している各アプリケーションのトークン署名のアルゴリズムがSHA-256に対応しているということであれば、AD FS側でSHA-1からSHA-256に設定を検討が必要である。
※Office 365はSHA-256に対応している。
手順は以下なるが、変更後の動作確認を念入りに実施してほしい。

1. プライマリ AD FS サーバーに管理者権限でログオンする。
2. [信頼関係] - [証明書利用者信頼] をクリックする。
3. 対象の証明書利用者信頼 (例 : Microsoft Office 365 Identity Platform) を右クリックし、[プロパティ] をクリックする。
4. [詳細設定] タブより、[セキュア ハッシュ アルゴリズム] ドロップダウン リストから [SHA-256] を選択し、[OK] をクリックする。

 

参考資料

https://technet.microsoft.com/windows-server-docs/identity/ad-fs/design/ad-fs-requirements