クライアント アクセス サーバー配列への MAPI クライアント接続に対する Kerberos 認証

概要

Active Directory サイトに複数のクライアント アクセス サーバーがある 2010 年Microsoft Exchange Server展開の場合、トポロジでは、サイト内のすべてのクライアント アクセス サーバー間でトラフィックを分散するために、クライアント アクセス サーバー配列と負荷分散ソリューションが頻繁に必要になります。 Exchange Server 2010 の変更により、MAPI 電子メール クライアントは、クライアント アクセス サーバー配列を使用しているときに Kerberos 認証を使用してメールボックスに接続できません。 この動作を回避するために、Microsoft Exchange Server Service Pack 1 (SP1) には、クライアント アクセス サーバー配列で MAPI 電子メール クライアントの Kerberos 認証を構成できる新機能が含まれています。

以前のバージョンのExchange Serverでの Kerberos 認証のしくみと、Kerberos 認証が MAPI 電子メール クライアントと連携できないようにする Exchange Server 2010 の変更の詳細については、Exchange チームブログの次のブログ投稿を参照してください。

推奨事項: MAPI クライアントの Kerberos 認証を有効にする

詳細情報

クライアント アクセス サーバー (CAS) ロールで実行される Microsoft Exchange Service Host サービスは、2010 SP1 Exchange Serverで拡張され、Kerberos 認証に共有代替サービス アカウント (ASA) 資格情報を使用します。 このサービス ホスト拡張機能は、ローカル コンピューターを監視します。 資格情報が追加または削除されると、ローカル システム上の Kerberos 認証パッケージとネットワーク サービス コンテキストが更新されます。 資格情報が認証パッケージに追加されるとすぐに、すべてのクライアント アクセス サービスが Kerberos 認証に使用できます。 クライアント アクセス サーバーは、ASA 資格情報を使用できるだけでなく、直接アドレス指定されたサービス要求を認証することもできます。 サービスレットと呼ばれるこの拡張機能は既定で実行され、実行する構成やアクションは必要ありません。

次の理由により、Exchange Server 2010 organizationに Kerberos 認証を使用しなければならない場合があります。

  • ローカル セキュリティ ポリシーには Kerberos 認証が必要です。

  • RPC クライアント アクセス サービスへの直接 MAPI 接続によって NTLM エラーが断続的に発生するなど、NTLM スケーラビリティの問題が発生しているか、予期しています。

    大規模な顧客展開では、NTLM によってクライアント アクセス サーバーでボトルネックが発生する可能性があります。 これにより、断続的な認証エラーが発生する可能性があります。 NTLM 認証を使用するサービスは、Active Directory の待機時間の問題の影響を受けやすくなります。 これにより、クライアント アクセス サーバー要求の割合が増加すると、認証エラーが発生します。

Kerberos 認証を構成するには、Active Directory とクライアント アクセス サーバー配列を設定する方法に精通している必要があります。 また、Kerberos 認証に関する実用的な知識も必要です。

Kerberos 認証用の ASA 資格情報をデプロイするには、次の手順に従います。

ASA 資格情報として使用するアカウントを作成する

クライアント アクセス サーバー配列内のすべてのコンピューターは、同じサービス アカウントを共有する必要があります。 これには、データセンターの切り替えの一部として開始できるクライアント アクセス サーバーが含まれます。 一般に、フォレストごとに 1 つのサービス アカウントで十分です。

コンピューター アカウントでは対話型ログオンが許可されないため、代替サービス アカウント (ASA) のユーザー アカウントではなくコンピューター アカウントを作成します。 したがって、コンピューター アカウントには、ユーザー アカウントよりも簡単なセキュリティ ポリシーが含まれている可能性があり、ASA 資格情報の推奨ソリューションです。

コンピューター アカウントを作成する方法の詳細については、「 新しいコンピューター アカウントを作成する」を参照してください。

注:

コンピューター アカウントを作成しても、パスワードの有効期限は切れません。 ただし、パスワードは定期的に更新することをお勧めします。 ローカル グループ ポリシーでは、コンピューター アカウントの最大アカウント期間を指定できます。また、ネットワーク管理者は、現在のポリシーを満たしていないコンピューター アカウントを定期的に削除するようにスクリプトをスケジュールできます。 コンピューター アカウントがローカル ポリシーを満たしていない場合に削除されないようにするには、コンピューター アカウントのパスワードを定期的に更新します。 ローカル セキュリティ ポリシーは、パスワードを変更する必要があるタイミングを決定します。

注:

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

ASA 資格情報の名前に関する特定の要件はありません。 名前付けスキームに続く任意の名前を使用できます。 ASA 資格情報には特別なセキュリティ特権は必要ありません。 ASA 資格情報のコンピューター アカウントを展開する場合、これは、アカウントがドメイン コンピューター セキュリティ グループのメンバーである必要があることを意味します。 ASA 資格情報のユーザー アカウントを展開する場合、これは、アカウントがドメイン ユーザー セキュリティ グループのメンバーである必要があることを意味します。

代替サービス アカウント資格情報に関連付ける SPN を決定する

代替サービス アカウントを作成した後、ASA 資格情報に関連付けられる Exchange サービス プリンシパル名 (SPN) を決定する必要があります。 SPN 値は、個々のサーバーではなく、ネットワーク ロード バランサーで使用されるサービス名と一致するように構成する必要があります。 Exchange SPN の一覧は構成によって異なる場合がありますが、一覧には少なくとも次のものが含まれている必要があります。

  • http Exchange Web サービス、オフライン アドレス帳のダウンロード、自動検出サービスにこの SPN を使用します。
  • exchangeMDB RPC クライアント アクセスにこの SPN を使用します。
  • exchangeRFR アドレス帳サービスにこの SPN を使用します。
  • exchangeAB アドレス帳サービスにこの SPN を使用します。

小規模企業の場合は、1 つの Active Directory サイトよりも大きなサイトはありません。 たとえば、単一の Active Directory サイトは次の図のようになります。

1 つの Active Directory サイトを含む小規模企業のスクリーンショット。

この例で使用する SPN を特定するには、前の図の内部 Outlook クライアントで使用されている完全修飾ドメイン名 (FQDN) を確認する必要があります。 この例では、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 として使用する FQDN を ASA 資格情報に追加する必要はありません。

サイトが 1 つの Active Directory サイトより大きい場合は、「 Load-Balanced クライアント アクセス サーバーの Kerberos 認証の構成 」のトピックで、その他の例を確認できます。

OAB 仮想ディレクトリをアプリケーションに変換する

オフライン アドレス帳 (OAB) 仮想ディレクトリは Web アプリケーションではありません。 そのため、Microsoft Exchange サービス ホスト サービスによって制御されません。 その結果、ASA 資格情報は、OAB 仮想ディレクトリに対する Kerberos 認証要求の暗号化を解除できません。

OAB 仮想ディレクトリを IIS Web アプリケーションに変換するには、各 CAS メンバーで ConvertOABVDir.ps1 スクリプトを実行します。 スクリプトでは、OAB 仮想ディレクトリの MSExchangeOabAppPool という名前の新しいアプリケーション プールも作成されます。 スクリプトをダウンロードするには、Microsoft スクリプト センターの ConvertOABDir.ps1 ページに移動します。

CAS メンバーに ASA 資格情報をデプロイする

Exchange Server 2010 SP1 には、ASA 資格情報のデプロイを有効にするスクリプトが含まれています。 スクリプトは RollAlternateServiceAccountPassword.ps1 という名前で、Scripts ディレクトリにあります。

スクリプトを使用して、初めてセットアップするためにフォレスト内のすべてのクライアント アクセス サーバーに資格情報をプッシュするには、次の手順に従います。

  1. Exchange 管理シェル で次のコマンドを実行します。

    .\RollAlternateserviceAccountPassword.ps1 -ToEntireForest -GenerateNewPasswordFor "Your_Domain_Name\Computer_Account_Name$" -Verbose
    
  2. 次のコマンドを実行して、"Exchange-RollAsa" と呼ばれる月に 1 回の自動パスワード ロールスケジュールタスクをスケジュールします。このコマンド スケジュールされたタスクは、フォレスト内のすべてのクライアント アクセス サーバーの ASA 資格情報を、スクリプトによって生成された新しいパスワードで更新します。 スケジュールされたタスクは作成されますが、スクリプトは実行されません。 スケジュールされたタスクが実行されても、スクリプトは無人モードで実行されます。

    .\RollAlternateServiceAccountPassword.ps1 -CreateScheduledTask "Exchange-RollAsa" -ToEntireForest -GenerateNewPasswordFor "Your_Domain_Name\Computer_Account_Name$"
    

RollAlternateserviceAccountPassword.ps1 スクリプトの使用方法の詳細については、「 シェルでの RollAlternateserviceAccountPassword.ps1 スクリプトの使用 」を参照してください。

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>

SPN を ASA 資格情報に関連付ける

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

注:

複製チェック フォレスト全体のパラメーター (-f) は、Windows Server 2008 を実行しているコンピューターで setspn コマンドと共にのみ使用できます。

Setspn -q -f exchangeMDB/outlook.**domain.domain.domain_root**

このコマンドでは、 exchangeMDB/outlook.domain.domain.domain_root は、 exchangeMDB/outlook.corp.contoso.com などの RPC クライアント アクセス用 SPN の SPN です。

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

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

SPN を設定した後、次のコマンドを実行して、SPN が追加されたことを確認します。

Setspn -L contoso\newSharedServiceAccountName

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

Microsoft Exchange Service Host サービスが実行していることを確認する

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

  1. CAS で [サービス] を開きます。 サービスを開くには、[スタート] ボタン、[コントロール パネル] の順にクリックし、[管理ツール][サービス] の順にダブルクリックします。
  2. サービスの一覧で、Microsoft Exchange サービス ホスト サービスを見つけます。
  3. [ 状態 ] 列で、状態が [開始] になっていることを確認します。 サービスが開始されていない場合は、[ Microsoft Exchange サービス ホスト サービス] を右クリックし、[ 開始] をクリックします。 サービスを自動的に開始するように構成するには、Microsoft Exchange Service Host サービスを右クリックし、[プロパティ] をクリックし、[スタートアップの種類] の一覧で [自動] をクリックし、[OK] をクリックします
    Outlook からの認証を検証する

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

  1. 正しい負荷分散されたクライアント アクセス サーバー配列を指す Outlook が構成されていることを確認します。
  2. ログオン ネットワーク セキュリティネゴシエート認証を使用するように電子メール アカウント サーバーのセキュリティ設定を構成します。 注:Kerberos パスワード認証を使用するようにクライアントを構成できますが、SPN が削除された場合、認証メカニズムをネゴシエート認証に戻すまで、クライアント コンピューターは認証できません。
  3. クライアント コンピューターで Outlook Anywhere が有効になっていないことを確認します。 Outlook が Kerberos パスワード認証を使用して認証できない場合は、Outlook Anywhere にフォールバックしようとします。そのため、このテストでは Outlook Anywhere を無効にする必要があります。
  4. Outlook を再起動します。
  5. デスクトップ コンピューターが Windows 7 を実行している場合は、klist.exe を実行して、付与され、使用されている Kerberos チケットを確認できます。 Windows 7 を実行していない場合は、Windows Server 2003 Resource Kit から klist.exe を取得できます。

その他のリソース

この問題とその回避策の詳細については、次の TechNet の記事を参照してください。

Kerberos をクライアント アクセス サーバー アレイまたは負荷分散ソリューションと共に使用する

負荷分散されたクライアント アクセス サーバーで Kerberos 認証を使用する方法の詳細については、次の TechNet 記事を参照してください。

Load-Balanced クライアント アクセス サーバーの Kerberos 認証の構成