【Office365】 脱ADFS!! 次世代の認証機能まとめ -其之参-

皆さんこんにちは、Miyaです。

さて、本テーマの主役(?)ともいえるシームレスシングルサインオン(以下、sSSO)についてです。

これまで紹介してきた認証方式であるPTA,PHSと組み合わせることで、ユーザーはID入力だけAzureADにサインイン(=シームレスなSSO)が出来ちゃう優れものです。

【Office365】 脱ADFS!! 次世代の認証機能まとめ -其ノ壱-
【Office365】 脱ADFS!! 次世代の認証機能まとめ -其之弐-

但し、シームレスなSSOをさせるためにの前提条件や制約事項がいくつかあるので、導入検討される際はキチンと理解しておきましょう。

本記事は、現時点でのMS公開情報と筆者の検証ベースの事柄をまとめた記事ですので、参考程度で見ていただければと…。

スポンサーリンク:

シームレスシングルサインオンとは?

sSSOとは、Office365へのログインにID入力のみ(=PW不要)でサインインが出来るようになる優れた機能です。

シングルサインオン

本機能は、AzureADConnectが提供するパススルー認証(PTA)、パスワード同期(PHS)と組み合わせることで構成できるオプション機能です。

パススルー認証

これまでSSOするためには、オンプレミスにAD FSと呼ばれるIdPの役割を持ったサーバーを構築する必要があったのですが、それがAzureADConnectだけで構成できるようになりました…という事でこれからOffice365に切り替えを検討しているIT部門の方々にはコスト面で大変ハッピーな情報でした。

ところが、「AD FS無しでSSOできる」という謳い文句が一人歩きしている状況で、それを構成するための要件などをキチッと認識されている方々が多くないような気がします。

ということで、sSSOを構成するための要件を、技術的な解説を交えて紹介させていただきます。
※2018年3月現在で公開された情報ベースになるので、今後のUpdateで更新される可能性がありますことをご容赦ください。

認証フロー

Active Directoryはドメイン参加したコンピュータ(サーバー)に、同じくドメイン参加したコンピュータ(クライアント)からアクセスする時にKerberosプロトコルを使ったSSOを提供していました。

Kerberos認証
参考:Windows Server 2016 Active Directoryの構築 Kerberosプロトコルによる認証フロー

しかし、Office365のようなクラウドアプリケーションは、Active Directoryのドメイン外、認証基盤もAzureADになることから、認証基盤やID管理が多重化するデメリットがありました。

従来は上記のような対策としてAD FSを中間に置いて、AD⇔AzureADで信頼関係を構成することで、認証基盤をオンプレADに統合してました。

フェデレーションID
参考:Office365 フェデレーションIDについて考える

AD FSでは統合Windows認証を提供することから、KerberosによるSSOをOffice365に活用することが出来ました。
参考:統合 Windows 認証

これらから、Office365を導入する組織の大半がAD FS構成で取り入れていましたが、コストはかかるわ、クラウドなのにサーバー構築あるわ、であまり望ましくはない構成でした。

これらの課題に対して「AD FSなしでSSOしようぜ!」をテーマに2017年GAされたのがsSSOです。

sSSOはActive Directory上にAzureADコンピューターアカウントを生成し、ドメイン内へのSSOフローをAzureADに対しても疑似的に作り出す見事な発想でした

PTA+sSSO

「ドメイン内へのSSOフローを疑似的に…」なので、もちろんサインインするクライアント端末はActive Directoryに接続可能な状況であることが前提です。ここはオンプレミスと変わりありませんね。

パススルー認証

一方で、社外などのActive Directoryに接続できない環境である場合は、PTAにフォールバックされる仕組みです。

パススルー認証

PHS+sSSO

社内に関しては、先ほどと同じですね。

パスワード同期

社外も同様フォールバックします。PHSなのでクラウド認証ですね。

パスワード同期

すげー!社内にいる限りパスワードいらずかよ!採用!!とはなりません。sSSOの要件を満たしているかを確認しましょう。

前提要件

sSSOを利用するためには、クライアント、インフラ、サーバーで要件を満たしている必要があります。

要件を満たしていない状況では、sSSOを導入しても結局PW入力が必要になるので、まずは要件と実環境のギャップを認識し、下準備を進めていきましょう。

クライアント要件

ドメイン参加していること

当然ですね。Active DirectoryのKDCからSTを貰うためにもドメイン参加は必須です。

ドメイン参加していない場合は、PTA,PHSにフォールバックされる動作になります。

また、これも当然ですが、sSSOさせるにはクライアント端末がActive Directoryと接続できるNW環境でなければなりません。よって何度も言うようですが社外接続はPTA,PHSにフォールバックします。

ローカルイントラネットゾーンにURLを追加していること

下記のURLをインターネットオプションから[ローカルイントラネットゾーン]に追加しておく必要があります。

https://autologon.microsoftazuread-sso.com

シングルサインオン

このURLは Kerberosのサービス プリンシパル名(SPN)です。このURLをイントラネットゾーンとしてあげましょう。

IEがURL先をイントラネットとして誤解するため、KerberosチケットをAzureADに転送する動きを取り、結果的にSSOされます。

[補足]
以前は、上記URLの他に”https://aadg.windows.net.nsatc.net”もイントラネットゾーンに追加する必要があったのですが、今は一つでいいみたいです。STのサービス名としては生きているのですが、一つのみの追加でsSSOされることは確認済みです。

もちろんグループポリシーで配布することも出来ますのでお試しあれ。
[ユーザーの構成] > [管理用テンプレート] > [Windows コンポーネント] > [Internet Explorer] > [インターネット コントロール パネル] > [セキュリティ ページ] の [サイトとゾーンの割り当て一覧] から構成可能です。

シングルサインオン

シングルサインオン

また、イントラネットゾーンのセキュリティ設定から「スクリプトを介したステータス バーの更新を許可する」を有効しておきましょう。

シングルサインオン

これも同様にGPO展開可能です。[ユーザーの構成] > [管理用テンプレート] > [Windows コンポーネント] > [Internet Explorer] > [インターネット コントロール パネル] > [セキュリティ ページ] > [イントラネット ゾーン] の[スクリプトを介したステータス バーの更新を許可する] から構成可能です。

シングルサインオン

OfficeがADAL対応になっていること

OfficeでもsSSOさせたいのであれば、ADALに対応しているバージョンを選択しましょう。

Office 2016の場合は既定でADAL対応であるため、特に追加構成は必要ありませんが、Office 2013はADAL対応のために必要KBを適用させておくのと、レジストリを修正しなければなりません。

各々のファイルバージョンの要件は以下リンク先に要件が記載されています。クイック実行形式かMSI形式かを判断した上で適切な対応をしましょう。
参考:Office クライアントで Office365 先進認証を使用する

レジストリは二つのキーを新規作成し、値1を入力しておきましょう。

レジストリキー タイプ
HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\EnableADAL REG_DWORD 1
HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\Version REG_DWORD 1

それぞれのレジストリの値と認証動作の対応関係が下記サイトにまとまっています。
参考:Office 2013 クライアント アプリと Office 2016 クライアント アプリでの先進認証のしくみ

対応ブラウザ

2018年3月時点での対応状況です。Edge以外であれば基本的に対応していると思っていただければよいです。

OS IE Edge Chrome Firefox Safari
Windows 10 × ○(設定必須)
Windows 8.1 ○(設定必須)
Windows 8 ○(設定必須)
Windows 7 ○(設定必須)
Max OS X ○(設定必須) ○(設定必須) ○(ドメイン参加必須)

SafariはMacをActive Directoryにドメイン参加させる必要があるため、少々面倒ですね。
参考:OS XとActive Directoryとの統合に関するベストプラクティス

Chromeは基本的には追加構成不要みたいですが、既に AuthNegotiateDelegateWhitelist、AuthServerWhitelistポリシーを上書き設定している場合は、うまく統合Windows認証が飛ばせないことがあるみたいです。
MacOSの場合は、ターミナルからホワイトリストにURLを追加が必要。また暇なときに確かめてみます。

FirefoxはKerberos認証をするよう手動でURLを追加してあげる必要があるみたいです。手順は後ほど…

意外にもEdgeが非対応であるのが痛いですね。Win10の標準ブラウザですので少し残念です。Edge+Cookieで永続的なサインインにしておくか、Azure AD JoinでSSOするかのどちらかが現実的かと思います。

環境要件

AzureADConnectのバージョン

AzureADConnectのバージョンが1.1.644.0以上であることが前提条件です。

具体的にはそれ以前のバージョンでも構成はできるのですが、不具合などが確認できていることから、旧バージョンを既存で利用している場合はアップグレードしておきましょう。

サーバー側のADAL有効

サーバー側でADALを有効にしておく必要があります。最近Office365テナントを作成した環境であれば、既定でONになっているみたいですね。

1年ぐらい前に作ったテナントであれば、既定でOFFの時代かもしれないので、念のため確認しておきましょう。

★Exchange Online
まずは、PowerShellから下記コマンドでExchange Onlineに接続しましょう。

下記コマンドで、Exchange OnlineのADALを有効化にし、設定の確認コマンドで”True”と表示されていればOKです。

 

★Skype for Business Online
Skype for Businessに接続するためには、別途モジュールをインストールする必要がありますので、こちらからモジュールのダウンロード&インストールをしましょう。

インストールが済みましたら、下記コマンドでSfBOnlineに接続します。

下記コマンドでADALを有効にし、設定の確認コマンドで”Allowed”と表示されていればOKです。

以上で、サーバー側の構成は完了です。

接続先とポート要件

sSSOを利用するには、*.msappproxy.netへの443通信をpermitしておきましょう。

F/Wがホスト名でルールを書けないようであれば、AzureのデータセンターのIPアドレスをベースにルールを記述する必要があります。
参考:Microsoft Azure Datacenter IP Ranges

本機能に限らず、Office365を導入する場合のネットワーク設計は計画的に!構成によっては運用大変です…。

構成方法

次に構成方法ですが、AzureADConnectのウィザードから簡単に行えます。

パススルー認証

全体を通した構成手順は以下のページを参考にして下さい。
参考:Office365 AADConnectのパススルー認証によるSSO構築①
参考:Office365 AADConnectのパススルー認証によるSSO構築②

最初の同期が済んだ時点完了です。反映に時間が掛かる場合があるので少し待ちましょう。

無効にするには、ウィザードで構成変更+手動でコンピューターアカウントを削除する必要があります。
参考:シームレス SSO はどのように無効にできますか

IE

IEは何も考えずにsSSO出来ました。但し、IEに限った話ではありませんがバージョンは最新にしておきましょう。

シングルサインオンシングルサインオン

Edge

EdgeはsSSOのサポート対象外であることから、PW入力を要求されます。残念。

シングルサインオン

Cookieによる永続的サインインで我慢するか、Azure AD Joinもしくはデバイス登録を検討しましょう。

シングルサインオン

Chrome

Windows 10+最新のChromeで試した結果、問題なくsSSOされました。

シングルサインオン

上手く動作しない場合は、ホワイトリストなどのポリシー関連を確認しておきましょう。

Firefox

Firefoxは既定ではsSSOしません。Kerberos認証させるように手動でURLを追加してあげる必要があります。

Firefoxを起動してアドレスバーに「about:config」と入力して、構成メニューを表示させましょう。

Firefox

次に、Kerberosの信頼済みサイト一覧である「network.negotiate-auth.trusted-uris」メニューを見つけましょう。Ctrl+Fから検索すると素早いです。

Firefox

ダブルクリックして、KerberosのSPNである「https://autologon.microsoftazuread-sso.com」を入力し、[OK]で閉じます。

Firefox

変更されていることを確認して、後は×閉じです。

Firefox

Firefoxを再起動して、試しにOffice365にサインインしてみると…

Firefox Firefox

無事にsSSO出来ましたね。

Win7+Office2016

Windows 7とOffice 2016の組み合わせで動作を確認してみました。

パススルー認証

パススルー認証

Office 2016は既定でADAL有効のため、sSSOされました。

Win10+Office2016

Windows 10とOffice 2016の組み合わせでは、PW入力が求められました。

Office2016

Twitterとは凄いツールですね、今回のことを呟くとありがたいアドバイスが貰えました。お二方ともありがとうございました!

なるほど。この画面はWAMなのか。通常、OfficeのADALの認証フレームワークにはIEが使われており、結果的にsSSOされるのですが、それがWAMに代わってKerberos認証が出来ていない状態であることが判りました。

どうやら、Office ProPlus(16.0.7967)から認証フレームワークがIE→WAMに変更されているみたいです。

下記レジストリを設定することで、WAM→IEに変更できるので、やってみた。
参考:You can’t sign in after you update to Office 2016 build 16.0.7967 or a later version on Windows 10

Office2016

すると…これまで通りsSSOできました!

その他情報

その他、sSSOに関する情報で気にしているところをまとめておきました。メモ書きです…。

代替えIDのサポート

試していませんが、Office365のログインIDとしてUserPrincipalNameでなく、別の属性(mail属性とか)でログインさせる構成でもサポートされるみたいです。

UPNの変更には、その他サービスがLDAP連携するのに利用する属性であった場合に対応が大変ですので、代替IDがサポートされるのはうれしいですね。
参考:Configuring Alternate Login ID

複数フォレストのサポート

Office365(AzureAD)ではトップレベルのドメイン毎で異なる認証方式が構成可能でした。
参考:Azure AD とのフェデレーションに使用する複数ドメインのサポート

なので、AD FSのフェデレーションIDが既存環境としてあるテナントに、子会社展開などでドメインを追加する場合には、パススルー認証・パスワード同期+シームレスSSO構成といった異なる認証フローで追加可能ということです。
参考:“シームレス SSO” と “パススルー認証” の一般提供開始

復号化キーのロールオーバー

sSSOを構成することでActive Directoryに生成される”AZUREADSSOACC”というコンピューターアカウントのKerberosの復号化キーを、少なくとも30日間隔で更新しておけよ、とのこと。
参考:コンピューター アカウントの Kerberos の復号化キーをロール オーバーするにはどうすればよいですか

sSSOする時、AzureADに暗号化されたKerberosチケットを提示→AzureAD側で事前に共有された復号キーで復号、の流れで、この復号キーを定期的に更新しておきましょうって話だと思います。

AzureADConnectがインストールされたサーバーにAzureADに接続するための以下二つのモジュールをインストールしておきましょう。

Title:IT プロフェッショナル 用 Microsoft Online Services サインイン アシスタント RTW
https://www.microsoft.com/ja-jp/download/details.aspx?id=41950

Title:Azure Active Directory の PowerShell モジュール
https://blogs.technet.microsoft.com/jpazureid/2017/12/04/aad-powershell/

モジュールがインストール出来たら、Powershellで下記コマンドでモジュールをインポートします。

復号化キーを更新したいドメインの管理者アカウント(DomainAdmins以上?)の資格情報を入力して、Updateコマンドで更新します。

「The operation completed successfully」と出力されれば完了です。

スクリプト化しておいて、タスクスケジューラに数日周期の夜間実行で仕込めば良いかと思います。日中帯にすると、既に配布したKerberosチケットがsSSOに使えなくなるので…。

kerberosのSPN

sSSOはKerberosチケットによるシングルサインオンであるため、klistコマンドでチケットの中身を確認できます。

以前はローカルイントラネットゾーンに追加するSPNは二つ(https://aadg.windows.net.nsatc.net、https://autologon.microsoftazuread-sso.com)だったのですが、最近になって一つ(https://autologon.microsoftazuread-sso.com)に減っていたので、klist ticketsコマンドで見たところ、接続先サーバー名がhttps://aadg.windows.net.nsatc.netのまま…

Office2016

大丈夫か?とおもったのですが、autologon.microsoftazuread-sso.comのCNAMEがaadg.windows.net.nsatc.net。そういうことか。

Office2016

Kerberosチケットの話がでたので言っておくと、実は有効期限内であれば、キャッシュされたSTで社外NWからでもsSSO出来ます。

ただ、ログアウト、もしくは画面ロックアウトした時点などでキャッシュされたチケットは破棄する動きなので、基本的には社外ではPW入力が必要になります。変に社外でsSSOされちゃうと混乱するので、これはこれでOKだと思います。

スポンサーリンク