Lync Online 認証 のトラブルシューテイングについて -上級編

こんばんは、Lync サポートのワトソンです。

今日は簡単ではありますが、Lync Online へのサインインのトラシューについての案内となります。

まず、以下のブログで簡単に認証のシーケンスについて以前ご案内させて頂いております。

https://blogs.msdn.com/b/lync_support_team_blog_japan/archive/2014/09/04/lync-online.aspx

Lync Online と認証のトラシュを開始する前、まずは自身の環境について以下をご認識頂く必要があります。

▼  Proxy を経由し、Lync Online と接続している (YES/NO)

YES の場合、以下のブログ記事にある注意点をクリアしているかについて
ご確認下さい。

https://blogs.msdn.com/b/lync_support_team_blog_japan/archive/2014/11/06/lync-online-web-proxy.aspx

==トラシュ開始==

- 1 Microsoft Online Sign-In Assistant Service ログの有効化

Lync Online サーバーと認証を行う際、WS_Trust クライアントである Lync 2013 クライアントは

Microsoft Online Sign-In Assistant Service を経由し、認証トークンの取得を行います。

Lync 2010 のごろこちらのサービスは別のサービスとして存在しましたが、Lync 2013 では

ライブラリが内蔵されてます。

Microsoft Online Services Sign-In Assistant と クラウド間の認証の流を確認する場合、

Lync クライアントの SIP ログやサポートが利用する Lync 2013 クライアントの etl

ファイルから確認をする事ができないため、まず、トラシュをするにあたり、

Microsoft Online Service Sign-In Assistant のログを有効にする必要があります。

ユーザー権限のコマンドプロンプトより以下のコマンドを実行し、ログを有効にするレジストリを追加します。

REG ADD HKCU\SOFTWARE\Microsoft\MSOIdentityCRL\Trace /v "Folder" /t REG_SZ /d "c:\MSOTrace" /f
REG ADD HKCU\SOFTWARE\Microsoft\MSOIdentityCRL\Trace /v "Flags" /t REG_DWORD /d 1 /f
REG ADD HKCU\SOFTWARE\Microsoft\MSOIdentityCRL\Trace /v "level" /t REG_DWORD /d 99 /f

- 2 Lync クライアント再起動し、サインインができない状態を再現

Online サーバーへの認証が発生した時点で、c:\MSOTrace に msoXXX の名前の
ログファイルが出力されます。

今日はこのファイルの内容の確認について簡単にお話しをさせて頂きます。

ファイル内で "Send to host:" で始まる行でどこと通信を行っているか確認ができます。

まず、以下の認証のシーケンスではシングルサインインが有効であり、
途中まで成功しているが、組織内の AD FS サーバーとの通信が失敗して
おり、結果、トークンの取得に失敗している例になります。

▼ コメント: ユーザーの設定の詳細を取得するため、 login.microsoft.com に接続
2472,16:59:27:918>:        GETUSERREALM URL: 'https://login.microsoftonline.com/getuserrealm.srf'@passportclientlibrary.cpp_748
2472,16:59:27:918>:        +CPPCRLBaseRequest::SendInternal(this=0xe19dc18, pRequest=0xe19dc18, lpszServerName=login.microsoftonline.com, nServerPort=443 XXXX
...... (何行がつつく）
16:59:27:918>:         Send to host:login.microsoftonline.com, port: 443,
...... (何行がつつく）
▼ コメント: プロキシを利用している場合この行で Proxy の設定を取得している事がわかります。以下の場合 kaisyanoproxy.coontoso.com
 2504,2472,16:59:27:933>:            Obtained proxy settings through explicitly named proxy <settings.@proxyconfig.cpp_430>
...... (何行がつつく）
 2472,16:59:27:933>:            +CProxyHandler::SetNextProxySettings()@proxyconfig.cpp_598
 2472,16:59:27:933>:            SetNextProxySettings: dwAccessType=3, lpszProxy=proxy01.kaisyanoproxy.contoso.com:80, lpszProxyBypass = sts.contoso.com;<local>@proxyconfig.cpp_634
▼ コメント: このあと、ユーザー設定情報が返されます。以下のレスポンスの場合、シングルサインユーザーなので自社の AD FS サーバーの URL
がトークンの取得先として記載されます。以下のレスポンスの場合  AuthURL と STSAuthURL と MEXURL に記載があるサーバー　https://sts.contoso.com/XXX
 <2504,2472,16:59:28:543>:          RealmInfo Response: <RealmInfo Success="true"><State>3</State><UserState>2</UserState>
<Login>user01@contoso.com</Login><NameSpaceType>Federated</NameSpaceType><DomainName>contoso.com</DomainName>
<FederationGlobalVersion>1</FederationGlobalVersion>
<AuthURL>https://sts.contoso.com/adfs/ls/</AuthURL>
<IsFederatedNS>true</IsFederatedNS>
<STSAuthURL>https://sts.contoso.com/adfs/services/trust/2005/usernamemixed</STSAuthURL>
FederationBrandName>Contoso Tenant</FederationBrandName>
<MEXURL>https://sts.contoso.com/adfs/services/trust/mex</MEXURL>
.......</RealmInfo>
▼ コメント: つぎに上記で取得した MEXURL よりユーザーの情報を抽出します。
2472,16:59:28:558>:       +CMEXInfoRequest::......
...... (何行がつつく）
2472,16:59:28:558>:         Send to host:sts.contoso.com, port: 443,
...... (何行がつつく）
2472,16:59:28:558>:          ##TestHook: URL-https://sts.contoso.com/adfs/services/trust/mex@transport.cpp_345
...... (何行がつつく）
▼ コメント： Proxy の設定をまた、認識
2472,16:59:28:558>:            SetNextProxySettings: dwAccessType=3, lpszProxy=proxy01.contoso.com:80, lpszProxyBypass = sts.contoso.com;
▼ コメント： 以下の例の場合、は ここのアクセスに失敗しております。
2072,17:53:20:491>: Mex query failed, hr = <0x80048051@singleidentity.cpp_294>
2072,17:53:20:491>: Realm discovery failed for user 'user@contoso.com
▼ コメント: 成功する場合以下のように Obtained Responce と表示されます。
2556,16:32:33:622>: ObtainResponse on 0XX
▼ コメント：その後、認証トークンを STS に依頼
2556,16:32:33:669>: Send to host:sts.contoso.com, port: 443, path:/adfs/services/trust/2005/windowstransport@transport.cpp_193
▼ コメント: 以下のように Soap responce があれば、レスポンスがきている事になります。
2556,16:32:33:669>: ## SOAP Request:
2556,16:32:34:28>: ## SOAP Response:

▼ コメント: その後、取得したトークンをオンラインのサーバーに送信し認証します。
16:32:34:59>:      +CPPCRLBaseRequest::SendInternal(this=0xbf8c1b0, pRequest=0xbf8c1b0, lpszServerName=login.microsoftonline.com, nServerPort=443, 

▼コメント：リクエストが正常に終了した場合、オンラインサーバーより証明書が発行され SOAP Responce がとどきます。

2556,16:32:34:903>:         ## SOAP Response: <?xmlＸＸＸＸ
2556,16:32:34:966>:   +CClientSingleIdentity::GetServiceToken(ServiceURI='https://webpoolhkn0f06.infra.lync.com/WebTicket/WebTicketService.svc/WsFed_bearer')@idcrlidentity.cpp_934
2556,16:32:34:966>:   -CClientSingleIdentity::GetServiceToken=0x0
2556,16:32:34:966>:  Current time: 2014-11-10T07:32:34 @idcrlidentity.cpp_2274
2556,16:32:34:966>:  Token Expired time:2014-11-10T15:32:31 @idcrlidentity.cpp_2276

上記の場合、正常に 8 時間有効な証明書を取得できている事分かります。

認証が失敗する場合にチェックする項目

1.  Proxy を利用している場合 SetNextProxySettings の右で表示される Proxy の名前は正しいかについて。
- IE の設定を確認して頂き、プロキシの設定が正しいか、ご確認下さい。
- WPAD を利用していない場合は IE の設定で自動的に設定を検出するチェックボックスを外して下さい。
2.   MEX や Auth URL へのリクエストが失敗している場合で内部クライアントがアクセスできない場合かつ、
Proxy が表示されている場合、この Proxy に届いたリクエストは
内部の AD FS サーバーに転送されておりますでしょうか。AD FS Proxy の場合 Proxy の Hosts ファイルのエントリ
をして頂き、正しく AD FS サーバー [内部] に向けて下さい。
3. MEX や Auth URL へのリクエストが失敗している場合、AD FS サーバーの時間はずれていないでしょうか。
4. ドメインユーザーで、MEX や Auth URL へのリクエストが失敗している場合、このクライアントは Domain に参加しているクライアントでしょうか。

以上、簡単ではありますが、Lync Online への認証のトラシュのご紹介になります。

引き続き快適な Lync Life をお楽しみください。