タケさんより、AADSyncに仕込む管理者アカウントをFederationユーザにしたらどう?というコメントを頂きましたので、どうなるのかちょっと試してみました。
※昨日のコメント欄を見ていただければわかると思いますが、ws-trust/saml-ecpなどのActiveEndpointのことをすっかり忘れていましたので、当然FederationユーザはAADSyncやPowerShellでは使えないと思い込んでいました。タケさんありがとうございました。
結果、もともとの課題(シングルテナントに複数のドメインを定義し、各ドメイン毎にAADSyncを入れてオンプレADと同期、ただしドメイン間でユーザ情報の閲覧などはさせたくない)については解決は出来なかったのですが、管理者アカウントの制御を含め別の使い方も出来そうなので、簡単にまとめておきます。
構築したのは下図のような環境です。
AADSyncやPowerShellなどMicrosoft Online Serviceサインインアシスタント経由の通信はAzure Active Directory(AzureAD)上に登録したドメインに設定されたActiveUriへws-trustやSAML(ECP)で通信して認証されるので、ActiveUrlだけをインターネットに公開し、Webブラウザ経由でアクセスされるPassiveUriは.localドメインなど社内ネットワークからのみアクセスできるアドレスを設定します。
この設定により、AADSyncなどに設定するAzureAD管理者アカウントとパスワードを知っていてもW社外ユーザは、社内にあるIdPに到達できないため、Webアプリケーションは使えない、という環境が作れます。
具体的な設定ですが、一旦は.localドメインでAD FSを構築し、AzureADとSSO設定を行った後、「Set-MsolDomainFederationSettings」コマンドレットでActiveLogOnUriプロパティのURIを外部公開しているURIに変更する、という方法をとりました。
設定した結果はこんな感じです。
> Get-MsolDomainFederationSettings -DomainName example.com ActiveLogOnUri : https://adfs.example.com/adfs/services/trust/ 2005/usernamemixed FederationBrandName : eIdentity IssuerUri : http://adfs.eidentity.local/adfs/services/trus t LogOffUri : https://adfs.eidentity.local/adfs/ls/ MetadataExchangeUri : https://adfs.eidentity.local/adfs/services/trust/mex NextSigningCertificate : PassiveLogOnUri : https://adfs.eidentity.local/adfs/ls/ SigningCertificate : MIIC9DCCAdygAwIBAgIQSjWgIWhJdKVN1NL85LCH3zANBgkqhkiG9w 0BAQsFADA2MTQwMgYDVQQDEytBREZTIFNpZ25pbmcgLSBhZGZzLWFh
ActiveLogOnUriのみ外部公開ドメインになっていて、後は.localになっているのがわかります。
これで、AADSyncに設定する管理アカウントにFederationユーザを設定しても問題なく認証が通るようになります。
ただ、昨日のポストでも書いたように、
・PowerShellが使えるのでGet/Set-MsolUserコマンドレットなどでユーザ一覧は参照・更新可能
・Synchronization Service ManagerのConnector SpaceやMetaverseでユーザ一覧を参照可能
・当然カスタムルールを書けば他ドメインのユーザを更新や削除も可能
なので、シングルテナント・マルチドメインの環境でドメイン単位でセキュリティ境界を作るのは困難なのは変わりません。
0 件のコメント:
コメントを投稿