負荷分散されたクライアント アクセス サーバーの Kerberos 認証の構成

  • [アーティクル]

 

適用先: Exchange Server 2010 SP2, Exchange Server 2010 SP3

トピックの最終更新日: 2016-11-28

Kerberos 認証をクライアント アクセス サーバーの負荷分散アレイと共に使用するには、いくつかの構成手順を完了する必要があります。Kerberos をクライアント アクセス サーバー アレイまたは負荷分散ソリューションで使用する方法の詳細は、「Kerberos をクライアント アクセス サーバー アレイまたは負荷分散ソリューションと共に使用する」を参照してください。

Active Directory で代替サービス アカウント資格情報を作成する

クライアント アクセス サーバー アレイ内のすべてのコンピューターは、同じサービス アカウントを共有する必要があります。さらに、データセンターのライセンス認証シナリオで呼び出される可能性のあるクライアント アクセス サーバーも、同じサービス アカウントを共有する必要があります。一般に、フォレストごとに 1 つのサービス アカウントがあれば十分です。このアカウントは、代替サービス アカウント資格情報 (ASA 資格情報) と呼ばれます。

注意

展開が複雑で、以下に示すシナリオの範囲を超える場合や、または展開に管理者委任問題があったり、異なる Exchange 展開スケジュールに複数のフォレスト セグメントが存在したりする場合、追加のアカウントを作成しなければならないことがあります。RollAlternateServiceAccountPasswordl.ps1 スクリプトは、作成したすべてのアカウントに対して個別に実行する必要があります。

資格情報の種類

代替サービス アカウント用にコンピューター アカウントまたはユーザー アカウントを作成できます。コンピューター アカウントは対話型ログオンを許可しないため、ユーザー アカウントよりもセキュリティ ポリシーが単純である可能性があり、そのため、ASA 資格情報に対する推奨ソリューションとなります。コンピューター アカウントを作成した場合、パスワードは実際には期限切れになりませんが、パスワードを定期的に更新することをお勧めします。ローカル グループ ポリシーには、コンピューター アカウントの最大アカウント年齢を指定でき、現在のポリシーに適合しないコンピューター アカウントを定期的に削除するようスケジュールされたスクリプトを設置できます。コンピューター アカウントのパスワードを定期的に更新することで、ローカル ポリシーに適合しないためにコンピューター アカウントが削除されることがないようにします。パスワードの変更が必要となる時期は、ローカル セキュリティ ポリシーによって決定されます。

資格情報名

ASA 資格情報の名前には特定の要件はありません。名前付けスキームに準拠している任意の名前を使用できます。

グループおよび役割

ASA 資格情報には特別なセキュリティ特権は必要ありません。ASA 資格情報にコンピューター アカウントを展開する場合、そのアカウントのみが Domain Computers セキュリティ グループのメンバーである必要があります。ASA 資格情報にユーザー アカウントを展開する場合、そのアカウントのみが Domain Users セキュリティ グループのメンバーである必要があります。

パスワード

アカウントを作成するときに指定するパスワードが実際に使用されることはありません。代わりに、スクリプトによってパスワードがリセットされます。したがって、アカウントを作成するときには、組織のパスワード要件に準拠している任意のパスワードを使用できます。

クロス フォレスト シナリオ

クロスフォレスト展開またはリソースフォレスト展開を使用しており、ユーザーが Exchange を含む Active Directory フォレストの外側にいる場合は、フォレスト間の信頼と、フォレスト間での名前サフィックスのルーティングを構成する必要があります。詳細については、「異なるフォレストのリソースにアクセスする」および「フォレスト間で名前サフィックスをルーティングする」を参照してください。

代替サービス アカウント資格情報に関連付ける必要があるサービス プリンシパル名の識別

代替サービス アカウントを作成したら、ASA 資格情報に関連付ける Exchange サービス プリンシパル名 (SPN) を決定する必要があります。Exchange SPN の一覧は構成によって異なりますが、少なくとも以下が含まれている必要があります。

  • http この SPN は、Exchange Web サービス、オフライン アドレス帳のダウンロード、自動検出サービス用に使用します。

  • exchangeMDB この SPN は、RPC クライアント アクセス用に使用します。

  • exchangeRFR この SPN は、アドレス帳サービス用に使用します。

  • exchangeAB この SPN は、アドレス帳サービス用に使用します。

SPN の値は、個別のサーバーではなくネットワーク負荷分散装置で使用されているサービス名に一致するように構成する必要があります。

展開する SPN 値を決定する際には、次の概念的なシナリオを考慮してください。

  1. 単一 Active Directory サイト

  2. 複数 Active Directory サイト

  3. DAG サイトの復元が可能な複数 Active Directory サイト

これらの各シナリオでは、クライアント アクセス サーバーのメンバーによって使用される内部 URL、外部 URL、自動検出サービスの内部 URI に、負荷分散される完全修飾ドメイン名が展開されていることを前提としています。詳細については、「プロキシとリダイレクトについて」を参照してください。

単一 Active Directory サイト

単一 Active Directory サイトがある場合、使用している環境はおそらく次の図に示す環境に類似しています。

前の図にある内部 Outlook クライアントで使用される完全修飾ドメイン名に基づいて、ASA 資格情報に次の SPN を展開する必要があります。

  • http/mail.corp.contoso.com

  • http/autod.corp.contoso.com

  • exchangeMDB/outlook.corp.contoso.com

  • exchangeRFR/outlook.corp.contoso.com

  • exchangeAB/outlook.corp.contoso.com

Outlook Anywhere を使用する外部またはインターネットベースのクライアントは、 Kerberos 認証を使用しません。したがって、これらのクライアントで使用される完全修飾ドメイン名を SPN として ASA 資格情報に追加する必要はありません。

重要

スプリット DNS インフラストラクチャを展開する場合、外部クライアントと内部クライアントは同じ完全修飾ドメイン名を使用し、これらの名前は ASA 資格情報に SPN として表される必要があります。

複数 Active Directory サイト

複数 Active Directory サイトがある場合、ご使用の環境は次の図のようなものになると思います。

前の図にある内部 Outlook クライアントで使用される完全修飾ドメイン名に基づいて、Active Directory サイト ADSite 1 内のクライアント アクセス サーバー アレイに対して使用される ASA 資格情報に、次の SPN を展開する必要があります。

  • http/mail.corp.contoso.com

  • http/autod.corp.contoso.com

  • exchangeMDB/outlook.corp.contoso.com

  • exchangeRFR/outlook.corp.contoso.com

  • exchangeAB/outlook.corp.contoso.com

前の図にある内部 Outlook クライアントで使用される完全修飾ドメイン名に基づいて、Active Directory サイト ADSite 2 内のクライアント アクセス サーバー アレイに対して使用される ASA 資格情報に、次の SPN を展開する必要があります。

  • http/mailsdc.corp.contoso.com

  • http/autodsdc.corp.contoso.com

  • exchangeMDB/outlooksdc.corp.contoso.com

  • exchangeRFR/outlooksdc.corp.contoso.com

  • exchangeAB/outlooksdc.corp.contoso.com

注意

この例では、この特定のシナリオで複数の ASA 資格情報を使用できることが示されていますが、Kerberos 認証を展開するクライアント アクセス サーバー アレイをホストするすべての Active Directory サイトに対して単一の ASA 資格情報を使用できます。

DAG サイトの復元が可能な複数 Active Directory サイト

DAG サイトの復元可能な複数 Active Directory サイトがある場合、ご使用の環境は次の図のようなものになると思います。

このアーキテクチャには両方の Active Directory サイトにまたがるデータベース可用性グループ (DAG) が含まれるため、ADSite 1 と ADSite2 内のクライアント アクセス サーバー アレイのメンバーが使用するために単一の ASA 資格情報を展開する必要があります。単一の ASA 資格情報を使用しないと、セカンダリ データセンターのクライアント アクセス サーバー アレイのメンバーが Kerberos セッション チケットを解読できないために、データセンターの切り替えを行ったときにクライアントに Kerberos 認証問題が発生します。セカンダリ データセンターのライセンス認証の詳細については、「データセンターの切り替え」を参照してください。

前の図にある内部 Outlook クライアントで使用される完全修飾ドメイン名に基づいて、ADSite1 と ADSite2 内のクライアント アクセス サーバー アレイで使用されている ASA 資格情報に、次の SPN を展開する必要があります。

  • http/mail.corp.contoso.com

  • http/autod.corp.contoso.com

  • exchangeMDB/outlook.corp.contoso.com

  • exchangeRFR/outlook.corp.contoso.com

  • exchangeAB/outlook.corp.contoso.com

  • http/mailsdc.corp.contoso.com

  • http/autodsdc.corp.contoso.com

  • exchangeMDB/outlooksdc.corp.contoso.com

  • exchangeRFR/outlooksdc.corp.contoso.com

  • exchangeAB/outlooksdc.corp.contoso.com

オフライン アドレス帳仮想ディレクトリをアプリケーションに変換する

インストール直後は、オフライン アドレス帳仮想ディレクトリは Web アプリケーションではないため、Microsoft Exchange Service Host サービスで制御されていません。その結果、オフライン アドレス帳仮想ディレクトリ対する Kerberos 認証要求は、ASA 資格情報を使用して暗号化を解除できません。

オフライン アドレス帳仮想ディレクトリを Web アプリケーションに変換するには、ConvertOABDir.ps1 スクリプトを各クライアント アクセス サーバーのメンバーに対して実行します。このスクリプトは、オフライン アドレス帳仮想ディレクトリ用の新しいアプリケーション プールも作成します。このスクリプトは、Exchange 2010 SP2 のスクリプト ディレクトリにあります。または、こちらからスクリプトをダウンロードできます。

代替サービス アカウント資格情報の展開

ASA 資格情報を作成したら、ASA 資格情報を使用するクライアント アクセス サーバーが含まれるすべての Active Directory サイト内のドメイン コントローラーすべてに、このアカウントがリプリケートされていることを確認します。

次に、Exchange 管理シェルで AlternateServiceAccount 資格情報スクリプトを実行します。詳細については、「シェルでの RollAlternateserviceAccountCredential.ps1 スクリプトの使用」を参照してください。スクリプトの実行が完了したら、対象のサーバーのすべてが適切に更新されていることを確認することを推奨します。

注意

このスクリプトは英語でのみ提供されます。

スクリプト エラーのトラブルシューティング情報については、「RollAlternateServiceAccountCredential.ps1 スクリプトのトラブルシューティング」を参照してください。

次の RollAlternateServiceAccountPassword.ps1 スクリプトの出力例は、ASA 資格情報として作成されたコンピューター アカウントを使用しています。このアカウントの名前は、contoso/newSharedServiceAccountName です。次の例では、このスクリプトは資格情報設定を、outlook.corp.contoso.com という名前のクライアント アクセス サーバー アレイの各メンバーに適用します。

このスクリプトを実行するには、次のコマンドを使用します。

RollAlternateServiceAccountPassword.ps1 -ToArrayMembers outlook.corp.contoso.com -GenerateNewPasswordFor contoso\newSharedServiceAccountName$

スクリプトを実行すると、次の出力が表示されます。パスワード変更の承認を求めるメッセージが表示されます。

========== Started at 08/02/2010 15:48:09 ==========Destination servers that will be updated:Name----CASACASBCredentials that will be pushed to every server in the specified scope (recent first):UserName                               Password--------                               --------contoso\newSharedServiceAccountName$                System.Security.SecureStringPrior to pushing new credentials, all existing credentials that are invalid or no longer work will be removed from the destination servers.Pushing credentials to server CASAPushing credentials to server CASBSetting a new password on Alternate Service Account in Active DirectoryPassword changeDo you want to change password for contoso\newSharedServiceAccountName$ in Active Directory at this time?[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"): yPreparing to update Active Directory with a new password for contoso\newSharedServiceAccountName$ ...Resetting a password in the Active Directory for contoso\newSharedServiceAccountName$ ...New password was successfully set to Active Directory.Retrieving the current Alternate Service Account configuration from servers in scopeAlternate Service Account properties:StructuralObjectClass QualifiedUserName       Last Pwd Update     --------------------- -----------------       ---------------     computer              contoso\newSharedServiceAccountName$ 8/2/2010 3:49:05 PM SPNs-----Per-server Alternate Service Account configuration as of the time of script completion:   Array: outlook.corp.contoso.comIdentity  AlternateServiceAccountConfiguration--------  ------------------------------------NAE14CAS  Latest: 8/2/2010 3:48:38 PM, contoso\newSharedServiceAccountName$          Previous: <Not set>NAE14CAS2 Latest: 8/2/2010 3:48:51 PM, contoso\newSharedServiceAccountName$          Previous: <Not set>

また、イベント ログ内には 2 つのイベント ID があります。1 つのイベントはスクリプトの開始を示し、もうひとつのイベントは正常に完了したことを示します。以下は、正常完了イベントから抜粋したものです。

Log Name:      ApplicationSource:        MSExchange Management ApplicationEvent ID:      14002Task Category: KerberosLevel:         InformationDescription:Maintenance of the Alternate Service Accounts succeeded.

ASA 資格情報の展開の確認

Exchange 管理シェルで、次のコマンドを実行してクライアント アクセス サーバーでの設定を確認します。

Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialStatus | fl name,*alter*

このコマンドの実行結果は次のようになります。

Name                                 : CASAAlternateServiceAccountConfiguration : Latest: 8/2/2010 3:48:38 PM, contoso\newSharedServiceAccountName$                                       Previous: <Not set>Name                                 : CASBAlternateServiceAccountConfiguration : Latest: 8/2/2010 3:48:51 PM, contoso\newSharedServiceAccountName$                                       Previous: <Not set>

スクリプトを何度か実行してからスクリプトを変更した場合、以前のエントリにはスクリプトを最後に変更した日時が示されます。

Name                                 : NAE14CASAlternateServiceAccountConfiguration : Latest: 8/2/2010 4:32:38 PM, contoso\newSharedServiceAccountName$                                       Previous: 8/2/2010 4:32:24 PM, contoso\sharedkerbacct$Name                                 : NAE14CAS2AlternateServiceAccountConfiguration : Latest: 8/2/2010 4:32:38 PM, contoso\newSharedServiceAccountName$                                       Previous: 8/2/2010 4:32:24 PM, contoso\sharedkerbacct$

サービス プリンシパル名の代替サービス アカウント資格情報への関連付け

SPN を構成する前に、ターゲット SPN がフォレスト内の別のアカウントでまだ構成されていないことを確認します。ASA 資格情報は、これらの SPN が関連付けられているフォレスト内の唯一のアカウントである必要があります。フォレスト内にこれらの SPN が関連付けられたアカウントが他にないことを確認するには、コマンド ラインから setspn コマンドに –q と –f パラメーターを指定して実行します。次の例は、このコマンドの実行方法を示しています。コマンドは何も返さないはずです。コマンドが値を返した場合は、既に別のアカウントが使用を予定している SPN に関連付けられています。

注意

Windows Server 2008 にのみ、setspn コマンドでの重複チェック用のフォレスト全体のパラメーター (-f) がサポートされています。

Setspn -q -f exchangeMDB/outlook.corp.contoso.com

次のコマンドは、共有された ASA 資格情報での SPN の設定例を示しています。識別するターゲット SPN すべてに対し、この構文を使った setspn コマンドを 1 回実行する必要があります。

Setspn -S exchangeMDB/outlook.corp.contoso.com contoso\newSharedServiceAccountName$

SPN を設定した場合は、次のコマンドを使用して SPN が追加されていることを確認します。

Setspn -L contoso\newSharedServiceAccountName$

Exchange クライアントの Kerberos 認証を検証する

Kerberos を正常に構成し、RollAlternateServiceAccountPasswordl.ps1 スクリプトを展開したら、クライアントが正常に認証できることを確認します。

Microsoft Exchange Service Host サービスが実行中であることの認証

クライアント アクセス サーバーの Microsoft Exchange Service Host サービスは、ASA 資格情報を管理します。このサービスが実行されていないと、Kerberos 認証を実行できません。既定では、このサービスは、コンピューターの起動時に自動的に開始するように構成されます。Exchange Server 2010 SP1 ロールアップ 3 またはそれ以降のバージョンが、使用している環境内のすべてのクライアント アクセス サーバーにインストールされていることを確認してください。

Outlook から認証を検証する

Outlook がクライアント アクセス サーバーに Kerberos 認証を使って接続できることを確認するには、次の手順を実行します。

  1. Outlook が正しい負荷分散クライアント アクセス サーバー アレイをポイントするように構成されていることを確認します。

  2. ログオン ネットワーク セキュリティとして [ネゴシエート認証] を使用するように電子メール アカウント サーバーのセキュリティ設定を構成します。または、[Kerberos パスワード認証] を使用するようにクライアントを構成することもできます。ただし、SPN が完全に削除されている場合、認証機構を [ネゴシエート認証] に再度変更するまで、クライアントを認証できません。

  3. Outlook Anywhere がクライアントに対して有効になっていないことを確認します。Outlook は Kerberos を使用した認証に失敗した場合、Outlook Anywhere にフォールバックしようとするので、このテストでは Outlook Anywhere を無効にする必要があります。

  4. Outlook を再起動します。

  5. デスクトップ コンピューターで Windows 7 を実行している場合、どの Kerberos チケットが発行され、使用されているかを確認するには、klist.exe を実行します。 Windows 7 を実行していない場合は、Windows Server 2003 リソース キットから klist.exe を取得してください。

Test-OutlookConnectivity コマンドレットを使用して検証する

Kerberos が動作しているかどうかをテストするには、Test-OutlookConnectivity コマンドレットを使用します。これが、TCP 接続を確立できるかどうかを確認する最良の方法です。既定では、コマンドレットは TCP 接続に対してネゴシエート認証を使用します。したがって Kerberos が構成されている場合、それが使用されます。コンピューターの Kerberos チケットを表示するには、ファイル klist.exe が使用できます。これはクライアント アクセス サーバー自身から実行可能であると同時に、SCOM などの自動監視ツールからも実行できます。Test-OutlookConnectivity コマンドレットを使用する場合は、メールボックス データベースで RPCClientAccessServer プロパティにクライアント アクセス サーバー アレイの名前を必ず設定します。この設定がないと、コマンドレットは共有 ASA 資格情報の機能をテストしません。

Test-OutlookConnectivity -Identity administrator -MailboxCredential $c -Protocol tcp

確実に接続に Kerberos が使用されるようにするために、klist.exe を表示して、追加された新しい SPN に関連付けられている Kerberos チケットが存在するかどうかを確認します。

クライアント アクセス サーバーから Kerberos を検証する

クライアント アクセス サーバーから Kerberos が正しく動作していることを確認するには、プロトコル ログを調べて Kerberos 接続が正常であることを確認します。Kerberos が使用されていることを確認するために、その他の検証に加えてこれらのログを使用することができます。

  • クライアント アクセス サーバー上で、アドレス帳のプロトコル ログを確認します。これらのログは、通常、以下のパスに置かれます。C:\Program Files\Microsoft\Exchange server\v14\Logging\AddressBook Service

  • 最新のログ ファイルを確認し、スクリプトが実行された後にある Kerberos という単語を探します。Kerberos トラフィックが表示される場合、接続が正常に行われています。ログ ファイルの行は、次のような形式になっています。

    2010-06-11T22:58:49.799Z,9,0,/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Administrator,,2001:4898:f0:3031:99f:ce35:750a:8b09,EXCH-A-363,ncacn_ip_tcp,Bind,,6,,,Kerberos,

Kerberos の語句が表示されれば、サーバーは正常に Kerberos 認証接続を作成しています。アドレス帳サービス ログの詳細については、「アドレス帳サービスについて」を参照してください。

認証エラーのトラブルシューティング

Kerberos 認証を構成しているときに発生する可能性がある、いくつかの一般的な問題があります。

Kerberos 認証のみを使用するように構成された Outlook クライアントが接続できない

Kerberos 認証のみを使用するように構成された Outlook クライアントが接続できない場合は、次のトラブルシューティング手順に従います。

  1. NTLM 認証のみを使用するように Outlook を構成し、接続を確認します。接続できない場合は、クライアント アクセス サーバー アレイを使用できること、またはネットワーク接続が安定していることを確認します。

    NTLM 接続が正常で、Kerberos が正常でない場合は、SPN が代替サービス アカウント以外のどのアカウントにも登録されていないことを確認します。共有する代替サービス アカウントによって使用されているアカウントに Exchange SPN が登録されていることを確認するには、このトピックで前述した setSPN クエリ コマンドを使用します。

  2. パスワードがすべてのクライアント アクセス サーバーと Active Directory 間で調整されていることを確認します。それには、スクリプトを手動モードで実行し、新しいパスワードを生成させます。

  3. クライアント アクセス サーバーで Microsoft Exchange アドレス帳サービスが実行されていることを確認します。

  4. それでも認証に成功しない場合は、Kerberos を使ってアクセスするサービスの仮想ディレクトリで、統合 Windows 認証が有効になっていることを確認します。認証方法を確認するには、Get-VirtualDirectory コマンドレットを使用できます。仮想ディレクトリの詳細については、「Outlook Web App 仮想ディレクトリについて」と「Exchange Web サービス仮想ディレクトリについて」を参照してください。

自動検出サービスのエラー

次の自動検出サービス エラーに気付いた場合、自動検出サービス要求ヘッダーに大きな Kerberos 認証チケットが含まれているため、ヘッダー サイズがインターネット インフォメーション サービス (IIS) サーバーによって構成された制限値を超えた可能性があります。エラーは次のようになります。

HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Tue, 09 Mar 2010 18:06:18 GMT
Connection: close
Content-Length: 346

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""https://www.w3.org/TR/html4/strict.dtd">

<HTML><HEAD><TITLE>Bad Request</TITLE>

<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>

<BODY><h2>Bad Request - Request Too Long</h2>

<hr><p>HTTP Error 400. The size of the request headers is too long.</p>

</BODY></HTML>

このエラーを解決するには、IIS ヘッダーのサイズ制限を増やします。詳細については、IIS のドキュメントを参照してください。

ASA 資格情報の継続的な保守

共有する ASA 資格情報のローカル パスワードを定期的に更新する必要がある場合は、定期的なパスワードの保守を実行するためのスケジュールされたタスクのセットアップ方法について、「シェルでの RollAlternateserviceAccountCredential.ps1 スクリプトの使用」を参照してください。指定されたときにパスワード ロールオーバーが行われていることを確認し、可能性のある認証の停止を防止するために、スケジュールされたタスクを監視してください。

Kerberos 認証をオフにする

クライアント アクセス サーバー アレイを元に戻し、Kerberos を使用しないようにするには、共有サービス アカウントから SPN を削除します。SPN が削除されると、クライアントによって Kerberos 認証が試行されることは無くなり、ネゴシエート認証を使用するよう構成されたクライアントは NTLM を使用します。Kerberos だけを使用するよう構成されたクライアントは接続できません。SPN が削除されたら、共有サービス アカウントも削除する必要があります。toEntireForest パラメーターを使用して、すべてのクライアント アクセス サーバー アレイのメンバー、およびサーバー パラメーターから -copy を使用して Kerberos 資格情報を持たないサーバーを指定することで、保守スクリプトを使用して資格情報をクリーンアップできます。また、最後にすべてのクライアント コンピューターを再起動して Kerberos チケット キャッシュを消去する必要があります。

 © 2010 Microsoft Corporation.All rights reserved.