はじめに

ブラウザーでは ADAL 認証になるので、Windows コンピューターからパスワードを入力することなしに、Office 365 ポータルなどにシームレス シングルサインオンできる動作は確認できていましたが、Office ProPlus クライアントを使ってサインインする際には、以前に ADAL から WAM の起動を無効化する必要が以前はありました。

現行の Office ProPlus でも同様の動作にパスワードを要求される動作になるかを確認しました。

やってみる

検証環境は以下のとおりです。

1. Windows Server 2019
2. Office 365 ProPlus (バージョン 16.0.12228.20322)

結論から言いますと、Office クライアントからパスワード入力なしにシングル サインオンができました。
また、シームレス シングル サインオンの構成方法については、下記記事を参考にしていただければ幸いです。

-参考情報
AD FS 認証から パススルー認証 ＋ シームレス シングル サインオンに切り替える手順について
URL:https://qiita.com/Shinya-Yamaguchi/items/3b5ddeb6e2171244283f

実際に動作を確認してみます。
まず、事前に kerberos チケットを持っていないことを klist tickets コマンドレットで確認します。

C:\Users\test002>klist tickets

Current LogonId is 0:0x2b9263

Cached Tickets: (0)

チケットを持っている場合は、 klist purge コマンドレットでパージします。

C:\Users\test002>klist purge

Current LogonId is 0:0x2b9263
        Deleting all tickets:
        Ticket(s) purged!

PowerPoint を起動し、画面左下の「アカウント」をクリックします。

「サインイン」をクリックします。
※すでにライセンスは認証済みの状態です。

サインイン画面でオンプレミス AD から Azure AD 同期済みユーザーを指定して「次へ」をクリックします。

下記画面ショットのように、パスワード入力なしに、下記画面ショットのように PowerPoint にサインインできました。

Fiddler を見ると、31 行目に Kerberos チケットが取得できていることが確認できます。

コマンド プロンプトの klist tickets コマンドレットで確認すると、サーバー名「autologon.microsoftazuread-sso.com」に対して Kerberos チケットを送っていることを確認できます。(#1 の項目です)

C:\Users\test002>klist tickets

Current LogonId is 0:0x2b9263

Cached Tickets: (3)

#0>     Client: test002 @ YAMARARA.WORK
        Server: krbtgt/YAMARARA.WORK @ YAMARARA.WORK
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
        Start Time: 1/3/2020 5:38:50 (local)
        End Time:   1/3/2020 15:38:50 (local)
        Renew Time: 1/10/2020 5:38:50 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0x1 -> PRIMARY
        Kdc Called: AD-010.yamarara.work

#1>     Client: test002 @ YAMARARA.WORK
        Server: HTTP/autologon.microsoftazuread-sso.com @ YAMARARA.WORK
        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
        Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
        Start Time: 1/3/2020 5:40:29 (local)
        End Time:   1/3/2020 15:38:50 (local)
        Renew Time: 1/10/2020 5:38:50 (local)
        Session Key Type: RSADSI RC4-HMAC(NT)
        Cache Flags: 0
        Kdc Called: AD-010.yamarara.work

#2>     Client: test002 @ YAMARARA.WORK
        Server: LDAP/AD-010.yamarara.work/yamarara.work @ YAMARARA.WORK
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize
        Start Time: 1/3/2020 5:38:50 (local)
        End Time:   1/3/2020 15:38:50 (local)
        Renew Time: 1/10/2020 5:38:50 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0
        Kdc Called: AD-010.yamarara.work

Office クライアントなどのネイティブ クライアントを利用したシームレス シングル サインオンの詳細な動作は、下記 Microsoft の公開情報に細かく図解付きで記載されていますので、参考にしてみてください。

-参考情報
ネイティブ クライアントでのシームレス SSO によるサインインのしくみ
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/hybrid/how-to-connect-sso-how-it-works#how-does-sign-in-on-a-native-client-with-seamless-sso-work

下記画面ショットのように、パスワード入力を要求されたり、 WAM の画面を要求される場合は、シームレス シングル サインオンが正常に動作していないと考えることができます。(少なくともパスワードを要求されている時点でシームレス シングル サインオンの認証フローには遷移していません。)

要因は様々考えられるので一概には言えませんが、下記 Microsoft 公開情報に書いてあるトラブルシュートの項目を参考に、シームレス シングル サインオンが正常に構成されているか、構成面で確認することと、Fiddler を取りながら切り分けを行う方法が良いかと思います。

-参考情報
トラブルシューティングのチェックリスト
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/hybrid/tshoot-connect-sso#troubleshooting-checklist

おわりに

今回はネイティブ クライアントを利用したシームレス シングル サインオンの動作を確認してみました。
今回検証した構成はシンプルに UPN ＝ メールアドレスのユーザーを利用しているので、メールアドレスを利用した代替ログオン ID を利用した際の動作までは確認しませんでした。

シームレス シングル サインオンを構成していても Hybrid Azure AD Join で Azure AD にデバイスを登録している場合は PRT が Kerberos チケットよりも優先されるので、気づかずシングル サインオンできていた、ということもあり得ると思います。

Kerberos チケットを利用してシングル サインオンできているかどうかは、上述でご案内した Fiddler や klist コマンドレットで確認できますので、参考にしてみてください。

今回の記事が少しでも参考になれば幸いです。