先日、Azure AD Connectに関するセキュリティ・アドバイザリが発表され、脆弱性対応版として最新版がリリースされました。
脆弱性対応のためとはいえ、一部ヘルプデスク運用が変わってくるので、Office365やAzure ADの管理者の方は十分に注意して運用マニュアルの修正などを行う必要があります。
セキュリティ・アドバイザリ 4033453
Azure AD Connect の脆弱性により特権が昇格される
https://technet.microsoft.com/ja-jp/library/security/4033453
最新ビルド（1.1.553.0）
https://www.microsoft.com/en-us/download/details.aspx?id=47594
しかし、発表された内容を見ていると、どちらかというと脆弱性というよりも単に不適切な運用をしているだけじゃ、、、という話なので内容を解説してみたいと思います。
また、アドバイザリの中では対応策として、最新ビルドにバージョンアップすることが推奨されていますが、単にバージョンアップしただけでは環境によっては不具合が出ることもあるので、その辺りも解説しておきます。
最後に、Azure AD Connectの話としてアドバイザリが出ていますが、構成によってはFIM（Forefront Identity Manager）/MIM（Microsoft Identity Manager）にも当てはまる内容なので、FIM/MIMを使っている場合の構成の見直しポイントも簡単に。
◆脆弱性？の概要
簡単に言うと、パスワード書き戻しが有効になっているテナントにおいて、同期元のローカルActive Directory上で管理者権限を持っているユーザのパスワードをAzure ADやOffice 365上でリセットすると当然の事ながらローカルActive Directory上の管理者権限を持ったユーザのパスワードもリセットされてしまうので、悪意のあるAzure AD管理者がクラウド上でパスワードリセットを行うことによりローカルActive Directoryの管理者権限の奪取が可能になってしまう、という話です。色々と前提があるので整理をしておきましょう。
- 環境
- パスワード書き戻しが有効になっていること
- 管理者権限のあるユーザをAzure ADへ同期していること
- 同期を実行しているユーザに特権ユーザに対するパスワードリセットの権限を付与していること（以下が典型的なケースです）
- Domain AdminsやEnterprise Adminsのメンバにしている
- 同期対象のOUの管理権限を同期ユーザへ委譲し、AdminSDHolderコンテナにパスワードリセット権限を付与している
- 脆弱性利用者
- 悪意のある管理者。オンプレミスのリソース（AD配下）へアクセスが可能なこと
※AdminSDHolerの話は国井さんのブログ記事を参照してください。
こうやって見ていくと当たり前すぎて、製品の不具合というより構成の問題という気がしてきます。
基本的に同期対象となっているOUに管理者権限を持ったユーザが存在するのは、、、ということです。同期してOffice365にログインするユーザなのであれば、恒常的にローカルActive Directoryの管理者権限を与える必要もないはずですし。
◆実際どうなるのか？
では、管理者権限を持ったローカルActive Directory上のユーザをAzure Active Directoryへ同期させてみて、パスワード・リセットをしてみます。まずは、同期されたユーザ自身によるパスワード変更のパターンです。
アクセスパネルのプロフィール変更画面よりパスワードを変更します。
当然ですが、パスワードがオンプレミスに書き戻され、新しいパスワードでログインできるようになります。（試しにリモートデスクトップしてみるとちゃんとログインできます。当たり前ですが）
次に、SSPR（セルフ・サービス・パスワード・リセット）のシナリオを見てみます。いわゆる秘密の質問や認証用電話・メールなどを使ってパスワードを忘れた際に回復する、というシナリオです。
秘密の質問への回答をします。
無事にパスワードがリセットされ、ローカルActive Directoryへパスワードが書き戻されます。
最後に、管理者によるリセットです。
Azure AD Portalからユーザを選んでパスワードをリセットするやつですね。
これも管理者がリセットを行い、一時パスワードが割り当てられた段階でローカルActive Directoryのパスワードも変更されるので、一時パスワードでローカルリソースへアクセスできてしまいます。
そう、パスワード書き戻しの機能を普通に使っているだけです。
単に対象となっているユーザの中に管理者権限を持っているユーザが存在しただけです。
これが脆弱性なのか、と・・・。
◆Azure AD Connectのバージョンアップと注意点
どのみち、今後のバージョンのAzure AD Connectにはこの改修が入ってしまうので、仕方がないので対応版である1.1.553.0へバージョンアップします。バージョンアップによる具体的な変更内容は、アドバイザリのサイトにもあるように以下の2点です。
- 対象ユーザのadminCount属性の値を見てNullもしくは0なら一般ユーザとみなし、パスワード書き戻しを許可する
- 対象ユーザが特権ユーザだった場合、パスワードリセットを要求したAzure ADユーザが、対象ユーザと同じユーザだった場合は書き戻す（メタバース上で要求したユーザと対象ユーザの関係を確認する）
- この部分が原文・翻訳ともにものすごくわかりにくいです。
- 日本語「要求したユーザーが対象のオンプレミス AD アカウントのオーナーであるかどうかを検証します。それは、対象のオンプレミス AD アカウントと、要求したユーザーの Azure AD アカウントの関係をメタバースで確認します。要求したユーザーがオーナーの場合、Azure AD Connect はパスワード ライトバック要求を許可します。そうではない場合、要求は拒否されます」
- 原文「it then validates whether the requesting user is the owner of the target on-premises AD account. It does so by checking the relationship between the target on-premises AD account and the Azure AD account of the requesting user in its Metaverse. If the requesting user is indeed the owner, Azure AD Connect permits the Password writeback request. Otherwise, the request is rejected」
- このオーナー（is the owner）というのが何を指すのか、が全く分からず、ローカルAD上のOUや対象ユーザのセキュリティ構成でオブジェクトのオーナーにしてみたり、と色々とやったのですが、結局オーナー＝自身のアカウント、というオチだと思います。＃違ったらご指摘ください。
早速バージョンアップを行います。
無事に1.1.553.0になりました。
この状態でユーザ自身でのパスワード変更をAzure AD側で行います。
ここは問題なく変更、書き戻しされます。
同様に自身によるパスワード・リマインドでも問題なく変更、書き戻しされます。
次に管理者によるリセットです。
見事に失敗します。
この時、イベントログには特権ユーザに対するパスワードリセットが拒否された旨、記録されます。
このAdminUpnとうのがリセットを要求した管理者ユーザ、そのあとのUserPrincipalNameが対象のユーザでこの2つのUPNが合致しないとリセット・書き戻しは行われません。
ちなみに、対象ユーザが一般ユーザの場合は従来通り問題なく管理者によるパスワード・リセットを行うことが可能です。
つまり、今後は運用を行う上で、ローカルActive Directory上で管理者権限を持っているユーザについては自分自身でしかパスワード・リセットが出来ない、ということになりますので、従来のヘルプデスク等の運用を変えなければなりません。
この点が最大の注意点です。
