質問・問題
WorkSpacesクライアントがAD Connectorでの認証に失敗します。原因について教えてください。
回答・解決方法
WorkSpacesクライアントからAD Connectorを経由してオンプレミス側のドメインコントローラーで認証をする際に、正しいログイン情報を入力しても認証に失敗する場合、いくつかの原因が考えられます。
【原因1】認証設定に誤りがある
AD上のユーザのプロパティ「このアカウントに Kerberos DES暗号化を使う」「Kerberos 事前認証を必要としない」にチェックが入っていると認証に失敗します。
AD Connectorを使ってオンプレミス側のドメインコントローラーで認証する場合、ADユーザのプロパティである以下にチェックが入っていると認証に失敗します。
- 「このアカウントに Kerberos DES暗号化を使う」
- 「Kerberos 事前認証を必要としない」
これは AD Connectorが以下のような仕様になっているためです。
- 暗号化にはRC4-HMACアルゴリズムを利用する
- Kerberos 事前認証を行う
例：下記のようにチェックが入っている場合はAD Connectorでの認証に失敗します
AD Connector Prerequisites
http://docs.aws.amazon.com/ja_jp/directoryservice/latest/admin-guide/prereq_connector.html
Kerberos preauthentication
Your user accounts must have Kerberos preauthentication enabled. For more information about this setting, go to Preauthentication on Microsoft TechNet.
Encryption type
Your on-premises domain controller and user accounts must have RC4-HMAC encryption enabled.
【原因2】時刻同期の問題
接続先のドメインが正常に時刻同期できていない原因が考えられます。
AD Connector ではNTP サーバーと時刻同期を行っております。既定ではドメインコントローラー側の時刻と5分以上ずれていますと認証に失敗いたします。ドメイン配下のリソースはドメインコントローラーと時刻同期が行われるため、疎通に問題が無ければ認証に影響は出ませんが、 AD Connector はドメインコントローラーと同期しておりませんため、念のため時刻同期の設定についてご確認ください。
【原因3】VPNのMTUサイズが適切に設定されていない
VPNの設定がフレッツ回線のMTU（1454バイト）を考慮せず、MTU 1500を前提とした設定の場合、Kerberos認証のサイズの大きなパケットがAD Connectorで返されない状態が発生し、認証に失敗した事例が過去にありました。
VPN接続におけるMTU設定が正しいかどうか、再度ご確認ください。