「Azure AD Connect のシングル サインオンは冗長化できない」と誤解していた話
ちょっと前に「Azure AD Connect(AADC)使ってシングルサインオン出来るぞー！もうADFS必要ないんじゃーい！」みたいなニュースがありました。
- ADFSなしでOffice365へのシングルサインオンを実現する(2) | Always on the clock
- Azure AD Connect のシングル サインオン & パススルー認証 (プレビュー) によるクラウド完結のユーザー認証インフラの実現 – MS Japan Office 365 Tech Blog
これ見て、すげー！と思ったものの「AADCって冗長化サポートされてないじゃん…そんなんに認証基盤任せられるかよ…解散」となっていましたが。記事をよーく見たら冗長化サポートされていたのでした。(風呂入ってるときに「いくらなんでも冗長化されてないままリリースしないよな。もう1回確認しよ」と思って調べ直したのがきっかけ)
誤解1：AADCのシングルサインオンは冗長化できない → できる
の
パススルー認証を運用環境デプロイで使用することを計画している場合は、別のサーバー (Azure AD Connect と最初のコネクタを実行しているサーバー以外) に 2 つ目のコネクタをインストールすることを強くお勧めします。
にある通り、
AADApplicationProxyConnectorInstaller.exe REGISTERCONNECTOR=“false” /q
手順 2: パススルー認証用にコネクタを Azure AD に登録する
.\RegisterConnector.ps1 -modulePath “C:\Program Files\Microsoft AAD App Proxy Connector\Modules\” -moduleName “AppProxyPSModule” -Feature PassthroughAuthentication
とします。Azure AD側で複数のコネクタが存在すると認識し、使用できるコネクタに対して認証要求を投げるようです。ここらへんはAzure AD Health Serverとか使ってるのかな?
誤解2：AADCのシングルサインオンが使えない場合、Office365にログインできない → できる
仮にAADCが全て停止した場合、AzureADの認証先であるAADCが使えないためO365にログインできない…と思ってましたが、これはADFSの発想でした。AADCの場合、サービス停止時は、単純にO365に直接ログインする形になるようです。
シームレス SSO は便宜的な機能であり、何らかの理由で失敗した場合、ユーザーのサインイン エクスペリエンスはその通常の動作に戻ります。つまり、ユーザーはサインイン ページでパスワードを入力する必要があります。
ADFSと違ってO365上のドメインがFederetedにならないので、このような動作になるんですね。そういった意味ではADFSを冗長化するよりも耐障害性が強いと言えます。
これらを考慮すると、Azure AD Connectシングルサインオン構成は利点しかない、という事が分かりました。強いて言うなら、AADC稼働中と障害中でユーザーのオペレーションが違うという事くらいですが、ほとんどの会社では気にしないでしょう。