「Azure AD Connect のシングル サインオンは冗長化できない」と誤解していた話

ちょっと前に「Azure AD Connect(AADC)使ってシングルサインオン出来るぞー!もうADFS必要ないんじゃーい!」みたいなニュースがありました。

これ見て、すげー!と思ったものの「AADCって冗長化サポートされてないじゃん…そんなんに認証基盤任せられるかよ…解散」となっていましたが。記事をよーく見たら冗長化サポートされていたのでした。(風呂入ってるときに「いくらなんでも冗長化されてないままリリースしないよな。もう1回確認しよ」と思って調べ直したのがきっかけ)

誤解1:AADCのシングルサインオン冗長化できない → できる

パススルー認証を運用環境デプロイで使用することを計画している場合は、別のサーバー (Azure AD Connect と最初のコネクタを実行しているサーバー以外) に 2 つ目のコネクタをインストールすることを強くお勧めします。

にある通り、

手順 1: コネクタをダウンロードしてインストールする

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稼働中と障害中でユーザーのオペレーションが違うという事くらいですが、ほとんどの会社では気にしないでしょう。

まだプレビュー機能だし、OutlookSkypeなどの動作も確認する必要がありますが、早くGAして検証したいです。