다음을 통해 공유

부하 분산된 클라이언트 액세스 서버에 대해 Kerberos 인증 구성

  • 아티클

 

적용 대상: Exchange Server 2010 SP2, Exchange Server 2010 SP3

마지막으로 수정된 항목: 2016-11-28

부하가 분산된 클라이언트 액세스 서버의 배열에 Kerberos 인증을 사용하려면 몇 가지 구성 단계를 완료해야 합니다. 클라이언트 액세스 서버 배열 또는 부하 분산 솔루션에 Kerberos를 사용하는 방법에 대한 자세한 내용은 클라이언트 액세스 서버 배열 또는 부하 분산 솔루션에 Kerberos 사용을 참조하십시오.

Active Directory에서 대체 서비스 계정 자격 증명 만들기

클라이언트 액세스 서버 배열 내의 모든 컴퓨터가 동일한 서비스 계정을 공유해야 합니다. 또한 데이터 센터 활성화 시나리오에서 호출될 수 있는 모든 클라이언트 액세스 서버도 같은 서비스 계정을 공유해야 합니다. 일반적으로 포리스트당 하나의 서비스 계정으로 충분합니다. 이 계정을 ASA 자격 증명(대체 서비스 계정 자격 증명)이라고 합니다.

참고

배포가 복잡하고 아래 설명된 시나리오 이상으로 확장되거나, 관리자 위임 문제가 있거나, 서로 다른 Exchange 배포 일정에 여러 포리스트 세그먼트가 있는 경우에는 추가 계정을 만들어야 할 수 있습니다. 만드는 모든 계정에 대해 RollAlternateServiceAccountPasswordl.ps1 스크립트를 따로 실행해야 합니다.

자격 증명 유형

대체 서비스 계정에 대해 컴퓨터 계정 또는 사용자 계정을 만들 수 있습니다. 컴퓨터 계정은 대화형 로그온을 허용하지 않으므로 사용자 계정보다 더 단순한 보안 정책을 사용할 수 있으며, 따라서 ASA 자격 증명의 기본 솔루션이 됩니다. 컴퓨터 계정을 만들 경우 암호는 실제로 만료되지 않지만 그래도 정기적으로 암호를 업데이트하는 것이 좋습니다. 로컬 그룹 정책에서 컴퓨터 계정에 대해 최대 계정 기간을 지정할 수 있고 스크립트를 통해 현재 정책을 충족시키지 않는 컴퓨터 계정을 주기적으로 삭제하도록 예약할 수 있습니다. 컴퓨터 계정의 암호를 주기적으로 업데이트하면 컴퓨터 계정이 로컬 정책을 충족하지 않는다는 이유로 삭제되지 않습니다. 암호 변경이 필요한 시기는 로컬 보안 정책에 따라 결정됩니다.

자격 증명 이름

ASA 자격 증명의 이름에는 특정 요구 사항이 없습니다. 사용자 이름 지정 체계를 따르는 것이면 어떤 이름이든 사용할 수 있습니다.

그룹 및 역할

ASA 자격 증명에는 특수 보안 권한이 필요하지 않습니다. ASA 자격 증명에 대한 컴퓨터 계정을 배포하는 경우 계정이 Domain Computers 보안 그룹의 구성원이기만 하면 됩니다. ASA 자격 증명에 대한 사용자 계정을 배포하는 경우 계정이 Domain Users 보안 그룹의 구성원이기만 하면 됩니다.

암호

계정을 만들 때 제공하는 암호는 실제로 사용되지 않습니다. 대신 스크립트에서 암호를 다시 설정합니다. 따라서 계정을 만들 때에는 조직의 암호 요구 사항에 맞는 암호를 원하는 대로 사용할 수 있습니다.

크로스 포리스트 시나리오

크로스 포리스트 또는 리소스 포리스트 배포를 사용하며 Exchange가 포함된 Active Directory 포리스트 외부에 사용자가 있는 경우에는 포리스트 간 크로스 포리스트 트러스트 및 이름 접미사 라우팅을 구성해야 합니다. 자세한 내용은 포리스트에서 리소스 액세스 및 포리스트 간 이름 접미사 라우팅을 참조하십시오.

대체 서비스 계정에 연결되어야 하는 서비스 사용자 이름 식별

대체 서비스 계정을 만들었으면 ASA 자격 증명과 연결할 Exchange SPN(서비스 사용자 이름)을 결정해야 합니다. Exchange SPN 목록은 구성에 따라 달라질 수 있지만 최소한 다음을 포함해야 합니다.

  • http 이 SPN은 Exchange 웹 서비스, 오프라인 주소록 다운로드 및 자동 검색 서비스에 사용합니다.

  • 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 사용을 사용하는 외부 클라이언트나 인터넷 기반 클라이언트는 Kerberos 인증을 사용하지 않습니다. 따라서 이러한 클라이언트에서 사용되는 정규화된 도메인 이름은 ASA 자격 증명에 SPN으로 추가할 필요가 없습니다.

중요

분할된 DNS 인프라를 배포하는 경우 외부 및 내부 클라이언트가 동일한 정규화된 도메인 이름을 사용하며 해당 이름이 ASA 자격 증명에 SPN으로 표시되어야 합니다.

여러 Active Directory 사이트

여러 Active Directory 사이트가 있는 경우 환경이 다음 그림 중 하나와 같을 수 있습니다.

이전 그림의 내부 Outlook 클라이언트에서 사용되는 정규화된 도메인 이름을 기준으로 Active Directory 사이트 ADSite1 내의 클라이언트 액세스 서버 배열에 사용되는 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 사이트 ADSite2 내의 클라이언트 액세스 서버 배열에 사용되는 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(데이터베이스 가용성 그룹)이 포함되어 있으므로 ADSite1과 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

오프라인 주소록 가상 디렉터리를 응용 프로그램으로 변환

기본적으로 오프라인 주소록 가상 디렉터리는 웹 응용 프로그램이 아니므로 Microsoft Exchange Service Host Service에 의해 제어되지 않습니다. 따라서 ASA 자격 증명을 통해 오프라인 주소록 가상 디렉터리에 대한 Kerberos 인증 요청을 암호 해독할 수 없습니다.

오프라인 주소록 가상 디렉터리를 웹 응용 프로그램으로 변환하려면 각 클라이언트 액세스 서버 구성원에서 ConvertOABDir.ps1 스크립트를 실행합니다. 이 스크립트는 또한 오프라인 주소록 가상 디렉터리에 대한 새 응용 프로그램 풀을 만듭니다. 이 스크립트는 Exchange 2010 SP2 Scripts 디렉터리에 있으며, 그렇지 않은 경우에는 여기서 다운로드할 수 있습니다.

대체 서비스 계정 자격 증명 배포

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>

이벤트 로그에 이벤트 ID 두 개도 표시됩니다. 한 이벤트는 스크립트 시작을 나타내고 다른 이벤트는 완료를 나타냅니다. 다음은 완료 이벤트에서 추출한 내용입니다.

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>

스크립트를 여러 번 실행하고 변경한 경우 Previous 항목은 마지막 변경 작업이 수행된 시기를 보여 줍니다.

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이 연결된 유일한 계정이어야 합니다. 명령줄에서 –q 및 –f 매개 변수와 함께 setspn 명령을 실행하면 포리스트의 다른 계정이 연결되어 있지 않은 것을 확인할 수 있습니다. 다음 예에서는 이 명령을 실행하는 방법을 보여 줍니다. 명령에서 아무것도 반환되지 않아야 합니다. 값이 반환되면 사용하려는 SPN에 다른 계정이 이미 연결되어 있는 것입니다.

참고

Windows Server 2008에서만 setspn 명령에 포리스트 수준의 중복 검사 매개 변수 (-f)를 사용할 수 있습니다.

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

다음 명령은 공유 ASA 자격 증명에 SPN을 설정하는 방법의 예를 제공합니다. 이 구문을 사용한 setspn 명령은 식별하는 각 대상 SPN에 대해 한 번 실행해야 합니다.

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

SPN을 설정한 경우 다음 명령을 사용하여 추가되었는지 여부를 확인합니다.

Setspn -L contoso\newSharedServiceAccountName$

Exchange 클라이언트 Kerberos 인증 유효성 검사

Kerberos를 성공적으로 구성하고 RollAlternateServiceAccountPasswordl.ps1 스크립트를 배포했으면 클라이언트를 성공적으로 인증할 수 있는지 확인합니다.

Microsoft Exchange Service Host Service가 실행되고 있는지 확인

클라이언트 액세스 서버의 Microsoft Exchange Service Host Service는 ASA 자격 증명을 관리합니다. 이 서비스가 실행되고 있지 않으면 Kerberos 인증을 사용할 수 없습니다. 기본적으로 컴퓨터를 시작할 때 자동으로 시작되도록 서비스가 구성되어 있습니다. 환경에 있는 모든 클라이언트 액세스 서버에 Exchange Server 2010 SP1 롤업 3(영문) 이상 버전을 설치했는지 확인합니다.

Outlook에서 인증 유효성 검사

Outlook에서 Kerberos 인증을 사용하여 클라이언트 액세스 서버에 연결할 수 있는지 확인하려면 다음 단계를 수행합니다.

  1. Outlook이 부하가 분산된 올바른 클라이언트 액세스 서버 배열을 가리키도록 구성되어 있는지 확인합니다.

  2. 로그온 네트워크 보안 협상 인증을 사용하도록 전자 메일 계정 서버 보안 설정을 구성합니다. 또는 Kerberos 암호 인증을 사용하도록 클라이언트를 구성할 수 있습니다. 하지만 SPN이 제거된 경우 인증 메커니즘을 다시 협상 인증으로 변경할 때까지 클라이언트가 인증할 수 없습니다.

  3. 외부에서 Outlook 사용이 클라이언트에 대해 활성화되지 않았는지 확인합니다. Outlook은 Kerberos를 사용한 인증에 실패하면 외부에서 Outlook 사용으로 돌아가려고 하므로 이 테스트에서는 외부에서 Outlook 사용을 비활성화해야 합니다.

  4. Outlook을 다시 시작합니다.

  5. 데스크톱 컴퓨터에서 Windows 7을 실행하는 경우 klist.exe를 실행하여 부여되어 사용 중인 Kerberos 티켓을 확인할 수 있습니다. Windows 7을 실행하지 않는 경우 Windows Server 2003 Resource Kit에서 klist.exe를 구할 수 있습니다.

Test-OutlookConnectivity Cmdlet을 사용하여 유효성 검사

Kerberos가 작동하는지 테스트하려면 Test-OutlookConnectivity cmdlet을 사용합니다. 이는 TCP 연결을 설정할 수 있는지 확인할 수 있는 가장 좋은 방법입니다. 기본적으로 이 cmdlet은 TCP 연결을 위해 협상 인증을 사용합니다. 따라서 Kerberos를 구성한 경우 Kerberos가 사용됩니다. klist.exe 파일을 사용하여 컴퓨터의 Kerberos 티켓을 볼 수 있습니다. 이 파일은 SCOM과 같은 자동 모니터링 도구 뿐만 아니라 클라이언트 액세스 서버 자체를 통해서도 실행할 수 있습니다. Test-OutlookConnectivity cmdlet을 사용하는 경우 해당 사서함 데이터베이스에 RPCClientAccessServer 속성이 클라이언트 액세스 서버 배열 이름으로 설정되어 있는지 확인합니다. 그렇지 않은 경우 cmdlet이 공유 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이 등록되어 있지 않은지 확인합니다. 이 항목의 앞부분에서 설명한 것과 같이, setSPN query 명령을 사용하여 공유 대체 서비스 계정에서 사용되는 계정에 Exchange SPN이 등록되어 있는지 확인합니다.

  2. 모든 클라이언트 액세스 서버와 Active Directory 간에 암호가 지정되었는지 확인합니다. 이를 위해 유인 모드에서 스크립트를 실행하여 새 암호가 생성되도록 합니다.

  3. 클라이언트 액세스 서버에서 Microsoft Exchange 주소록 서비스가 실행되고 있는지 확인합니다.

  4. 그래도 인증에 성공하지 못한 경우는 Kerberos로 액세스하려는 서비스의 가상 디렉터리가 통합 Windows 인증을 사용하도록 설정되어 있는지 확인합니다. Get-VirtualDirectory cmdlet을 사용하여 인증 방법을 확인할 수 있습니다. 가상 디렉터리에 대한 자세한 내용은 Outlook Web App 가상 디렉터리 이해 및 Exchange 웹 서비스 가상 디렉터리 이해를 참조하십시오.

자동 검색 서비스 실패

다음과 같은 자동 검색 서비스 실패가 발생한다면 자동 검색 서비스 요청 헤더에 큰 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 티켓 캐시를 지우기 위해 모든 클라이언트 컴퓨터를 다시 시작해야 합니다.

 © 2010 Microsoft Corporation. 모든 권리 보유.