Kerberos 인증 구성: 핵심 구성(SharePoint Server 2010)

 

적용 대상: SharePoint Server 2010

마지막으로 수정된 항목: 2017-01-18

첫 번째 시나리오에서는 Kerberos 프로토콜을 사용하여 들어오는 클라이언트 요청을 인증하도록 두 SharePoint Server 2010 웹 응용 프로그램을 구성합니다. 데모용으로 한 웹 응용 프로그램은 표준 포트(80/443)를, 다른 웹 응용 프로그램은 비표준 포트(5555)를 사용하도록 구성됩니다. 이 시나리오는 아래의 작업이 완료되었다고 가정하는 모든 후속 시나리오의 기반이 됩니다.

중요

시나리오가 정상적으로 작동하도록 하려면 KErberos 인증을 사용하는 클래식 Windows 인증으로 웹 응용 프로그램을 구성해야 합니다. 일부 시나리오에서는 Windows 클레임 인증을 사용할 수도 있지만, 이 경우에는 아래 시나리오에 설명되어 있는 결과가 생성되지 않습니다.

참고

Windows Server 2008에 설치하는 경우에는 Kerberos 인증을 위해 다음 핫픽스를 설치해야 할 수 있습니다.
AES 알고리즘을 사용하는 경우 Windows Server 2008 또는 Windows Vista를 실행하는 컴퓨터에서 Kerberos 인증이 실패하고 오류 코드 0X80090302 또는 0x8009030f가 표시됩니다.(https://support.microsoft.com/kb/969083/ko-kr)

이 시나리오에서는 다음 작업을 수행합니다.

• 인증에 Kerberos 프로토콜을 사용하는 기본 영역을 사용하여 두 웹 응용 프로그램 구성

• 각 웹 응용 프로그램에 하나씩 두 개의 테스트 사이트 모음 만들기

• 웹 응용 프로그램의 IIS 구성 확인

• 클라이언트가 웹 응용 프로그램에 인증할 수 있는지와, 인증에 Kerberos 프로토콜이 사용되는지 확인

• 로컬 및 원격 웹 응용 프로그램에서 RSS 피드를 표시하도록 RSS 뷰어 웹 파트 구성

• 각 테스트 사이트 모음에서 각 웹 응용 프로그램 크롤링 및 콘텐츠 검색 테스트

구성 검사 목록

구성 영역	설명
DNS	NLB(네트워크 부하 분산) VIP(가상 IP) 웹 응용 프로그램에 대해 DNS A 레코드 등록
Active Directory	웹 응용 프로그램의 IIS 응용 프로그램 풀용으로 서비스 계정 만들기 웹 응용 프로그램의 IIS 응용 프로그램 풀용으로 만든 서비스 계정에 대해 웹 응용 프로그램의 SPN(서비스 사용자 이름) 등록 서비스 계정에 대해 Kerberos 제한 위임 구성
SharePoint 웹 응용 프로그램	Create SharePoint Server 관리되는 계정 만들기 SharePoint Search Service 응용 프로그램 만들기 SharePoint 웹 응용 프로그램 만들기
IIS	Kerberos 인증이 사용되는지 확인 커널 모드 인증이 사용되지 않는지 확인 SSL용 인증서 설치
Windows 7 클라이언트	웹 응용 프로그램 URL이 인트라넷 영역 또는 Windows 통합 인증을 사용하여 자동으로 인증하도록 구성된 영역에 있는지 확인
방화벽 구성	방화벽 포트를 열어 기본 및 비기본 포트에서 HTTP 트래픽 허용 클라이언트가 Active Directory에서 Kerberos 포트에 연결할 수 있는지 확인
브라우저 인증 테스트	브라우저에서 인증이 정상적으로 작동하는지 확인 웹 서버의 보안 이벤트 로그에서 로그온 정보 확인 타사 도구를 사용하여 Kerberos 인증이 올바르게 구성되어 있는지 확인
SharePoint Server 검색 인덱스 및 쿼리 테스트	인덱스 서버에서 브라우저 액세스 확인 예제 콘텐츠를 업로드하고 크롤링 수행 검색 테스트
WFE 위임 테스트	각 사이트 모음에서 RSS 피드 원본 구성 각 사이트 모음의 홈 페이지에 RSS 보기 웹 파트 추가

단계별 구성 지침

DNS 구성

환경의 웹 응용 프로그램에 대해 DNS를 구성합니다. 이 예제에서는 2개의 웹 응용 프로그램, 즉 http://portal과 http://teams:5555가 있습니다. 이 두 응용 프로그램은 동일한 NLB VIP(192.168.24.140/24)로 확인됩니다.

DNS를 구성하는 방법에 대한 일반 정보는 DNS 레코드 관리(영문일 수 있음)를 참조하십시오.

SharePoint Server 웹 응용 프로그램

http://portal - 포털 웹 응용 프로그램에 대해 새 DNS A 레코드를 구성합니다. 이 예제에서는 부하 분산된 VIP로 확인되도록 호스트 "portal"을 구성합니다.

http://teams:5555 - 팀 웹 응용 프로그램에 대해 새 DNS A 레코드를 구성합니다.

참고

여러 웹 응용 프로그램이 호스트 헤더 및 별도의 전용 서비스 계정을 사용하여 실행되는 환경에서 Kerberos 인증이 정상적으로 작동하도록 하려면 DNS 항목이 CNAME 별칭이 아닌 A 레코드인지 확인해야 합니다. Kerberos 사용 가능 웹 응용 프로그램에서 CNAME을 사용하는 경우에 발생하는 알려진 문제에 대한 설명은 Kerberos 구성 관련 알려진 문제(SharePoint Server 2010)를 참조하십시오.

Active Directory 구성

다음으로는 환경의 웹 응용 프로그램에 대해 Active Directory 계정을 구성합니다. 각 웹 응용 프로그램은 자체 보안 컨텍스트(응용 프로그램 풀 ID)를 사용하여 자체 IIS 응용 프로그램 풀에서 실행되도록 구성하는 것이 가장 좋습니다.

SharePoint 서비스 응용 프로그램 서비스 계정

이 예제에는 서로 다른 두 IIS 응용 프로그램에서 자체 응용 프로그램 풀 ID를 사용하여 실행되는 두 SharePoint Server 웹 응용 프로그램이 있습니다.

웹 응용 프로그램(기본 영역)	IIS 응용 프로그램 풀 ID
http://portal	vmlab\svcPortal10App
http://teams:5555	vmlab\ svcTeams10App

SPN(서비스 사용자 이름)

각 서비스 계정에 대해, 각 웹 응용 프로그램에 할당된 DNS 호스트 이름에 매핑되는 서비스 사용자 이름 집합을 구성합니다.

Windows Server 2008의 명령줄 도구인 SetSPN을 사용하여 새 서비스 사용자 이름을 구성합니다. SetSPN을 사용하는 방법에 대한 전체 설명은 Setspn(영문일 수 있음)을 참조하십시오. Windows Server 2008의 SetSPN 개선 사항에 대해 알아보려면 보호, 공유 및 확장: Windows Server 2008에서 SETSPN.EXE의 새로운 기능(영문일 수 있음)을 참조하십시오.

모든 SharePoint Server 웹 응용 프로그램은 포트 번호에 관계없이 다음 SPN 형식을 사용합니다.

• HTTP/<DNS HOST 이름>

• HTTP/<DNS FQDN>

예를 들면 다음과 같습니다.

• HTTP/portal

• HTTP/portal.vmlab.local

80/443 외의 비기본 포트에서 실행되는 웹 응용 프로그램의 경우 포트 번호를 포함하여 추가 SPN을 등록합니다.

• HTTP/<DNS 호스트 이름>:<포트>

• HTTP/<DNS FQDN>:<포트>

예를 들면 다음과 같습니다.

• HTTP/teams:5555

• HTTP/teams.vmlab.local:5555

참고

비기본 포트(80, 443 이외의 포트)에서 실행되는 HTTP 서비스에 대해 포트 번호를 포함하여/포함하지 않고 SPN을 구성하는 것이 좋은 이유에 대한 설명은 부록을 참조하십시오. 기술적으로 비기본 포트에서 실행되는 HTTP 서비스를 참조하는 올바른 방법은 SPN에 포트 번호를 포함하는 것이지만, 부록에 설명되어 있는 알려진 문제로 인해 포트 번호가 포함되지 않은 SPN도 구성해야 합니다. 팀 웹 응용 프로그램에 대해 포트가 포함되지 않은 SPN을 등록한다고 구성한다고 해서, 이 예제의 서비스에 기본 포트(80, 443)를 사용하여 액세스하는 것은 아닙니다.

이 예제에서는 이전 단계에서 만든 두 계정에 대해 다음 서비스 사용자 이름을 구성했습니다.

DNS 호스트	IIS 응용 프로그램 풀 ID	서비스 사용자 이름
Portal.vmlab.local	vmlab\svcPortal10App	HTTP/portal HTTP/portal.vmlab.local
Teams.vmlab.local	vmlab\ svcTeams10App	HTTP/Teams HTTP/Teams.vmlab.local HTTP/Teams:5555 HTTP/Teams.vmlab.local:5555

서비스 사용자 이름을 만들기 위해 다음 명령을 실행했습니다.

SetSPN -S HTTP/Portal vmlab\svcportal10App

SetSPN -S HTTP/Portal.vmlab.local vmlab\svcportal10App

SetSPN -S HTTP/Teams vmlab\svcTeams10App

SetSPN -S HTTP/Teams.vmlab.local vmlab\ svcTeams10App

SetSPN -S HTTP/Teams:5555 vmlab\ svcTeams10App

SetSPN -S HTTP/Teams.vmlab.local:5555 vmlab\ svcTeams10App

중요

웹 응용 프로그램에서 SSL을 사용하더라도 HTTPS를 사용하여 서비스 사용자 이름을 구성해서는 안 됩니다.

이 예제에서는 Windows Server 2008에 새롭게 도입된 명령줄 스위치 -S를 사용했습니다. 이 스위치는 계정에 대해 SPN을 만들기 전에 SPN이 있는지를 확인합니다. SPN이 이미 있는 경우에는 새 SPN이 만들어지지 않으며 오류 메시지가 표시됩니다.

중복 SPN이 검색되는 경우에는 웹 응용 프로그램에 대해 다른 DNS 이름을 사용하여 SPN을 변경하거나, 기존 SPN을 검색된 계정에서 제거하는 방법으로 문제를 해결해야 합니다.

중요

기존 SPN을 삭제하기 전에 해당 SPN이 더 이상 필요하지 않은지 확인하십시오. 그렇지 않으면 환경의 다른 응용 프로그램에 대한 Kerberos 인증이 작동하지 않을 수 있습니다.

서비스 사용자 이름 및 SSL

http 웹 응용 프로그램의 경우에는 Kerberos 서비스 사용자 이름과 URL을 혼동하기가 쉽습니다. SPN 형식과 URI 형식은 구문이 매우 비슷하기 때문입니다. 그러나 서비스 사용자 이름과 URL은 서로 다른 고유한 항목입니다. Kerberos 서비스 사용자 이름은 서비스를 식별하는 데 사용되며, 해당 서비스가 http 응용 프로그램인 경우 서비스에 SSL을 사용하여 액세스하는지 여부에 관계없이 서비스 스키마는 "HTTP"입니다. 즉, "https://someapp"를 사용하여 웹 응용 프로그램에 액세스하는 경우에도 "HTTPS/someapp"와 같이 HTTPS를 사용하여 서비스 사용자 이름을 구성하지 않으며 그렇게 구성해서도 안 됩니다.

컴퓨터 및 서비스 계정에 대해 제한된 Kerberos 위임 구성

시나리오에 따라, SharePoint Server 2010의 일부 기능은 제한 위임을 사용해야 정상적으로 작동할 수 있습니다. 예를 들어 RSS 뷰어 웹 파트가 인증된 원본의 RSS 피드를 표시하도록 구성되어 있는 경우, 원본 피드를 사용하려면 위임을 수행해야 합니다. Excel Services 등의 서비스 응용 프로그램이 클라이언트 ID를 백 엔드 시스템으로 위임할 수 있도록 제한 위임을 구성해야 하는 경우도 있습니다.

이 시나리오에서는 RSS 보기 웹 파트가 원격 웹 응용 프로그램에서 보안된 원격 RSS 피드 및 보안된 로컬 RSS 피드를 읽을 수 있도록 Kerberos 제한 위임을 구성합니다. 이후 시나리오에서는 다른 SharePoint Server 2010 서비스 응용 프로그램에 대해 Kerberos 제한 위임을 구성할 것입니다.

아래 다이어그램에서는 이 시나리오에서 구성하는 내용을 개념적으로 보여 줍니다.

이 시나리오에는 두 웹 응용 프로그램이 있으며, 각 웹 응용 프로그램에는 두 RSS 뷰어 웹 파트를 호스팅하는 사이트 페이지가 포함된 자체 사이트 모음이 있습니다. 또한 각 웹 응용 프로그램에는 Kerberos 인증을 사용하도록 구성된 기본 영역 하나가 있어서, 이들 웹 사이트에서 들어오는 모든 피드에는 인증이 필요합니다. 각 사이트에서 RSS 뷰어 하나는 목록의 로컬 RSS 피드를 읽도록 구성되고 나머지 하나는 원격 사이트의 인증 피드를 읽도록 구성됩니다.

이러한 구성을 만들려면 IIS 응용 프로그램 풀 서비스 계정 간에 위임을 허용하도록 Kerberos 제한 위임을 구성해야 합니다. 아래 다이어그램에서는 필요한 제한 위임 경로를 개념적으로 보여 줍니다.

응용 프로그램은 IIS 응용 프로그램 풀의 ID에 할당된 SPN(서비스 사용자 이름)을 사용하여 서비스 이름으로 식별합니다. 요청을 처리하는 서비스 계정은 지정된 서비스로 클라이언트 ID를 위임할 수 있어야 합니다. 위의 설명을 종합할 때, 다음과 같은 제한 위임 경로를 구성해야 합니다.

사용자 유형	사용자 이름	위임 대상 서비스
사용자	svcPortal10App	HTTP/Portal HTTP/Portal.vmlab.local HTTP/Teams HTTP/Teams.vmlab.local HTTP/Teams:5555 HTTP/Teams.vmlab.local:5555
사용자	svcTeams10App	HTTP/Portal HTTP/Portal.vmlab.local HTTP/Teams HTTP/Teams.vmlab.local HTTP/Teams:5555 HTTP/Teams.vmlab.local:5555

참고

포털 서비스 계정이 포털 서비스 응용 프로그램으로 위임하는 것과 같이 서비스 자신에 대한 위임을 구성하는 것은 중복 작업처럼 보일 수 있지만, 여러 서버에서 서비스를 실행하는 시나리오에서는 이 작업을 수행해야 합니다. 그러면 한 서버에서 같은 서비스를 실행하는 다른 서버로 위임해야 하는 시나리오를 수행할 수 있습니다. 로컬 웹 응용 프로그램을 데이터 원본으로 사용하는 RSS 뷰어를 통해 요청을 처리하는 WFE의 경우를 예로 들 수 있습니다. 팜 토폴로지 및 구성에 따라서는 다른 서버에서 RSS 요청을 처리할 수 있으며, 이 경우 위임이 정상적으로 작동해야 합니다.

위임을 구성하려면 Active Directory 사용자 및 컴퓨터 스냅인을 사용하면 됩니다. 각 서비스 계정을 마우스 오른쪽 단추로 클릭하고 속성 대화 상자를 엽니다. 이 대화 상자에는 위임 탭이 표시되는데, 이 탭은 개체에 SPN이 할당되어 있는 경우에만 표시됩니다(컴퓨터의 경우 기본적으로 SPN이 있음). 위임 탭에서 지정한 서비스에 대한 위임용으로만 이 사용자 트러스트를 선택하고 모든 인증 프로토콜 사용을 선택합니다.

추가 단추를 클릭하여 사용자(서비스 계정)를 위임할 수 있는 서비스를 추가합니다. SPN을 선택하려면 SPN이 적용되는 개체를 조회합니다. 여기서는 HTTP 서비스에 위임할 것이므로, 이전 단계에서 SPN을 할당한 IIS 응용 프로그램 풀의 서비스 계정을 검색합니다.

사용자 또는 컴퓨터 선택 대화 상자에서 사용자 및 컴퓨터를 클릭하고 IIS 응용 프로그램 풀 서비스 계정(이 예제에서는 vmlab\svcPortal10App 및 vmlab\svcTeams10App)을 검색한 후에 확인을 클릭합니다.

그러면 서비스 사용자 이름으로 개체에 할당된 서비스를 선택하라는 메시지가 표시됩니다.

서비스 추가 대화 상자에서 모두 선택을 클릭한 다음 확인을 클릭합니다. 이렇게 한 후에 위임 대화 상자로 돌아오면 선택한 모든 SPN이 표시되지 않습니다. 모든 SPN을 표시하려면 왼쪽 아래의 넓게 확인란을 선택합니다.

위임이 필요한 환경의 각 서비스 계정(이 예제에서는 서비스 계정 목록)에 대해 이 단계를 수행합니다.

SharePoint Server 구성

Active Directory 및 DNS를 구성한 후에는 SharePoint Server 2010 팜에서 웹 응용 프로그램을 만듭니다. 이 백서에서는 이 시점에서 SharePoint Server 설치가 완료되었으며 팜 토폴로지 및 지원 인프라(예: 부하 분산)가 구성되어 있다고 가정합니다. SharePoint 팜을 설치 및 구성하는 방법에 대한 자세한 내용은 SharePoint Server 2010 배포를 참조하십시오.

관리되는 서비스 계정 구성

웹 응용 프로그램을 만들기 전에 이전 단계에서 만든 서비스 계정을 SharePoint Server의 관리되는 서비스 계정으로 구성합니다. 이 작업을 미리 수행한 경우 웹 응용 프로그램 자체를 만들 때 이 단계를 건너뛰어도 됩니다.

관리되는 계정을 구성하려면

1. SharePoint 중앙 관리에서 보안을 클릭합니다.

2. 일반 보안에서 관리되는 계정 구성을 클릭합니다.

3. 관리되는 계정 등록을 클릭하고 각 서비스 계정에 대해 관리되는 계정을 만듭니다. 이 예제에서는 관리되는 서비스 계정 5개를 만들었습니다.

   계정	용도
   VMLAB\svcSP10Search	SharePoint Search Service 계정
   VMLAB\svcSearchAdmin	SharePoint 검색 관리 서비스 계정
   VMLAB\svcSearchQuery	SharePoint 검색 쿼리 서비스 계정
   VMLAB\svcPortal10App	포털 웹 응용 프로그램 IIS 응용 프로그램 풀 계정
   VMLAB\svcTeams10App	팀 웹 응용 프로그램 IIS 웹 응용 프로그램 풀 계정

   참고

   SharePoint Server 2010의 관리되는 계정은 Windows Server 2008 R2 Active Directory의 관리되는 서비스 계정과는 다릅니다.

SharePoint Server Search Service 응용 프로그램 만들기

이 예제에서는 새로 만드는 웹 응용 프로그램을 크롤링 및 검색할 수 있도록 SharePoint Server Search Service 응용 프로그램을 구성합니다. 새 SharePoint Server 검색 웹 응용 프로그램을 만들고 Search Service, 쿼리 서비스 및 관리 서비스를 응용 프로그램 서버(이 예제에서는 vmSP10App01)에 배치합니다. Search Service 응용 프로그램을 구성하는 방법에 대한 자세한 내용은 단계별 지침: Search Service 응용 프로그램 구축(영문일 수 있음)을 참조하십시오.

참고

여기서는 데모 전용으로 모든 Search Service를 한 응용 프로그램에 배치합니다. SharePoint Server 2010 검색 토폴로지 옵션 및 모범 사례에 대한 전체 설명은 이 문서에 포함되지 않습니다.

웹 응용 프로그램 만들기

중앙 관리에서 응용 프로그램 관리 섹션의 웹 응용 프로그램 관리로 이동한 다음, 도구 모음에서 새로 만들기를 선택하여 웹 응용 프로그램을 만듭니다. 다음 항목이 구성되어 있는지 확인하십시오.

• 클래식 모드 인증을 선택합니다.

• 각 웹 응용 프로그램에 대해 포트 및 호스트 헤더를 구성합니다.

• 인증 공급자로 협상을 선택합니다.

• 응용 프로그램 풀 아래에서 새 응용 프로그램 풀 만들기를 선택하고 이전 단계에서 만든 관리되는 계정을 선택합니다.

이 예제에서는 다음 설정을 사용하여 두 웹 응용 프로그램을 만들었습니다.

설정	http://Portal 웹 응용 프로그램	http://Teams 웹 응용 프로그램
인증	클래식 모드	클래식 모드
IIS 웹 사이트	이름: SharePoint - Portal - 80 포트: 80 호스트 헤더: Portal	이름: SharePoint - Teams- 5555 포트: 80 호스트 헤더: Teams
보안 구성	인증 공급자: 협상 익명 허용: 아니요 Secure Socket Layer 사용: 아니요	인증 공급자: 협상 익명 허용: 아니요 Secure Socket Layer 사용: 아니요
공용 URL	http://Portal:80	http://Teams:5555
응용 프로그램 풀	이름: SharePoint - Portal80 보안 계정: vmlab\svcPortal10App	이름: SharePoint - Teams5555 보안 계정: vmlab\svcTeams10App

새 웹 응용 프로그램을 만들면 Windows 인증 공급자를 사용하도록 구성된 새 영역(기본 영역)도 만들어집니다. 웹 응용 프로그램 관리에서 영역에 대한 공급자 및 해당 설정을 확인할 수 있습니다. 이렇게 하려면 먼저 웹 응용 프로그램을 선택한 다음 도구 모음에서 인증 공급자를 클릭합니다. 그러면 표시되는 인증 공급자 대화 상자에 선택한 웹 응용 프로그램의 모든 영역과, 각 영역의 인증 공급자가 표시됩니다. 원하는 영역을 선택하면 해당 영역의 인증 옵션을 확인할 수 있습니다.

Windows 설정을 잘못 구성하여 웹 응용 프로그램을 만들 때 NTLM을 선택한 경우에는 영역에 대해 인증 편집 대화 상자를 사용하여 영역 인증을 NTLM에서 협상으로 전환할 수 있습니다. 인증 모드로 클래식 모드를 선택하지 않은 경우에는 웹 응응 프로그램을 새 IIS 웹 사이트로 확장하여 새 영역을 만들거나, 웹 응용 프로그램을 삭제하고 다시 만들어야 합니다.

사이트 모음 만들기

인증이 올바르게 작동하는지 테스트하려면 각 웹 응용 프로그램에서 사이트 모음을 하나 이상 만들어야 합니다. 사이트 모음 만들기 및 구성은 Kerberos 기능에 영향을 주지 않으므로, 사이트 모음 만들기(SharePoint Foundation 2010)에 나와 있는 사이트 모음을 만드는 방법에 대한 기존 지침을 따르면 됩니다.

이 예제에서는 사이트 모음 2개를 구성했습니다.

웹 응용 프로그램	사이트 모음 경로	사이트 모음 서식 파일
http://portal	/	게시 포털
http://teams:5555	/	팀 사이트

대체 액세스 매핑 만들기

SSL로 보호된 서비스에서 위임이 작동하는 방식을 보여 주기 위해, HTTPS 및 HTTP를 둘 다 사용하도록 포털 웹 응용 프로그램을 구성합니다. SSL을 구성하려면 포털 웹 응용 프로그램에 HTTPS 끝점용으로 두 번째 SharePoint Server AAM(대체 액세스 매핑)이 필요합니다.

대체 액세스 매핑을 구성하려면

1. 중앙 관리에서 응용 프로그램 관리를 클릭합니다.

2. 웹 응용 프로그램 아래에서 대체 액세스 매핑 구성을 클릭합니다.

3. 대체 액세스 매핑 컬렉션 선택 드롭다운에서 대체 액세스 매핑 컬렉션 변경을 선택합니다.

4. 포털 웹 응용 프로그램을 선택합니다.

5. 위쪽 도구 모음에서 공용 URL 편집을 클릭합니다.

6. 빈 영역에 웹 응용 프로그램의 https URL을 추가합니다. 이 URL이 다음 단계에서 만들 SSL 인증서의 이름이 됩니다.

7. 저장을 클릭합니다.

   웹 응용 프로그램의 영역 목록에 HTTPS URL이 표시됩니다.

IIS 구성

SSL 인증서 설치

SSL을 사용하는 각 웹 응용 프로그램에 대해 웹 응용 프로그램 서비스를 호스팅하는 각 SharePoint Server에서 SSL 인증서를 구성해야 합니다. 이 문서에서는 SSL 인증서 및 인증서 트러스트를 구성하는 방법에 대해서도 설명하지 않습니다. 관련 내용은 이 문서의 SSL 구성 섹션에서 IIS에서 SSL 인증서를 구성하는 방법에 대한 자료를 참조하십시오.

Kerberos 인증이 사용되는지 확인

웹 사이트에서 Kerberos 인증이 사용되는지 확인하려면

1. IIS 관리자를 엽니다.

2. 확인할 IIS 웹 사이트를 선택합니다.

3. 기능 보기의 IIS 아래에서 인증을 두 번 클릭합니다.

4. 사용하도록 설정되어 있어야 하는 Windows 인증을 선택합니다.

5. 오른쪽의 작업 아래에서 공급자를 선택하고 목록 맨 위에 협상이 있는지 확인합니다.

커널 모드 인증이 사용되지 않는지 확인

커널 모드 인증은 SharePoint Server 2010에서 지원되지 않습니다. 기본적으로 모든 SharePoint Server 웹 응용 프로그램의 해당 IIS 웹 사이트에서는 커널 모드 인증이 사용하지 않도록 설정되어 있어야 합니다. 웹 응용 프로그램을 기존 IIS 웹 사이트에서 구성한 경우에도 SharePoint Server는 기존 IIS 사이트에 대해 새 웹 응용 프로그램을 구축할 때 커널 모드 인증을 사용하지 않도록 설정합니다.

커널 모드 인증이 사용되지 않는지 확인하려면

1. IIS 관리자를 엽니다.

2. 확인할 IIS 웹 사이트를 선택합니다.

3. 기능 보기의 IIS 아래에서 인증을 두 번 클릭합니다.

4. 사용하도록 설정되어 있어야 하는 Windows 인증을 선택합니다.

5. 고급 설정을 클릭합니다.

6. EAP와 커널 모드 인증이 모두 사용하지 않도록 설정되어 있는지 확인합니다.

방화벽 구성

인증을 테스트하기 전에, 클라이언트가 구성된 HTTP 포트에서 SharePoint Server 웹 응용 프로그램에 액세스할 수 있는지 확인합니다. 또한 클라이언트가 Active Directory에 인증할 수 있으며 표준 Kerberos 포트를 통해 KDC에서 Kerberos 티켓을 요청할 수 있는지도 확인합니다.

방화벽 포트를 열어 기본 및 비기본 포트에서 HTTP 트래픽 허용

일반적으로는 포트 TCP 80 및 TCP 443을 통해 들어오는 요청을 허용하려면 각 프런트 엔드 웹에서 방화벽을 구성해야 합니다. 고급 보안이 포함된 Windows 방화벽을 열고 다음 인바운드 규칙을 찾습니다.

• World Wide Web Services(HTTP 트래픽 인)

• World Wide Web Services(HTTPS 트래픽 인)

환경에서 적절한 포트가 열려 있는지 확인합니다. 이 예제에서는 HTTP(포트 80)를 통해 SharePoint Server에 액세스하므로 이 규칙이 사용하도록 설정됩니다.

또한 예제에 사용되는 비기본 포트(TCP 5555)도 열어야 합니다. 비기본 포트에서 웹 사이트를 실행하는 경우에는 해당 포트에서 HTTP 트래픽을 허용하는 사용자 지정 규칙도 구성해야 합니다.

클라이언트가 Active Directory 역할에서 Kerberos 포트에 연결할 수 있는지 확인

Kerberos 인증을 사용하려면 클라이언트가 UDP 또는 TCP 포트 88을 통해 KDC(키 배포 센터)에서 TGT(허용 티켓) 및 ST(서비스 티켓)를 요청해야 합니다. 기본적으로 Windows Server 2008 이상에서 Active Directory 역할을 설치하면 이 통신을 기본적으로 허용하기 위해 역할이 다음과 같은 들어오는 규칙을 기본적으로 구성합니다.

• Kerberos 키 배포 센터 - PCR(TCP-In)

• Kerberos 키 배포 센터 - PCR(UDP-In)

• Kerberos 키 배포 센터(TCP-In)

• Kerberos 키 배포 센터(UDP-In)

실제 작업 환경에서는 이러한 규칙이 사용하도록 설정되어 있으며 클라이언트가 포트 88을 통해 KDC(도메인 컨트롤러)에 연결할 수 있는지 확인하십시오.

브라우저 인증 테스트

Active Directory, DNS 및 SharePoint Server를 구성한 후에는 웹 응용 프로그램으로 이동하여 Kerberos 인증이 올바르게 구성되었는지 테스트할 수 있습니다. 브라우저에서 테스트하는 경우에는 다음 조건이 충족되는지 확인합니다.

1. 테스트 사용자가 SharePoint Server가 설치된 도메인에 연결된 Windows XP, Vista 또는 Windows 7 컴퓨터나 SharePoint Server 도메인에서 신뢰하는 도메인에 로그인되어 있습니다.

2. 테스트 사용자가 Internet Explorer 7.0 이상을 사용합니다. Internet Explorer 6.0은 SharePoint Server 2010에서 더 이상 지원되지 않습니다. 브라우저 지원 계획(SharePoint Server 2010))을 참조하십시오.

3. 브라우저에서 Windows 통합 인증이 사용하도록 설정되어 있습니다. 인터넷 옵션의 고급 탭에 있는 보안 섹션에서 **통합된 Windows 인증 사용***이 사용하도록 설정되어 있는지 확인합니다.

4. 로컬 인트라넷이 클라이언트 자동 로그온으로 구성되어 있습니다. Internet Explorer 옵션의 보안 탭에서 로컬 인트라넷을 선택하고 사용자 지정 수준 단추를 클릭합니다. 그런 다음 아래쪽으로 스크롤하여 인트라넷 영역에서만 자동으로 로그온이 선택되어 있는지 확인합니다.

   참고

   다른 영역에서도 자동 로그온을 구성할 수 있지만, 이 문서에서는 IE 보안 영역 모범 사례 항목에 대해서는 설명하지 않습니다. 이 데모에서는 모든 테스트에 인트라넷 영역을 사용합니다.

5. 인터넷 옵션->** 보안-> 인트라넷 영역-> 사이트**에서 인트라넷 네트워크를 자동으로 검색이 선택되어 있는지 확인합니다.

6. 정규화된 도메인 이름을 사용하여 SharePoint Server 웹 응용 프로그램에 액세스하는 경우 FQDN이 명시적으로 또는 와일드카드 포함(예: “*.vmlab.local”)을 통해 인트라넷 영역에 포함되어 있는지 확인합니다.

Kerberos 인증이 사용되고 있는지를 확인하는 가장 쉬운 방법은 테스트 워크스테이션에 로그인한 다음 해당 웹 사이트로 이동해 보는 것입니다. 사용자에게 자격 증명을 입력하라는 메시지가 표시되지 않고 사이트가 정상적으로 렌더링되면 Windows 통합 인증이 작동하는 것으로 간주할 수 있습니다. 다음 단계에서는 협상 프로토콜을 사용하여 Kerberos 인증을 요청의 인증 공급자로 협상했는지를 확인합니다. 이 작업은 다음과 같은 방식으로 수행할 수 있습니다.

프런트 엔드 웹 보안 로그

Kerberos 인증이 정상적으로 작동하면 프런트 엔드 웹의 보안 이벤트 로그에 이벤트 ID가 4624인 로그온 이벤트가 표시됩니다. 이러한 이벤트에 대한 일반 정보에는 컴퓨터에 로그온하는 보안 ID와 사용되는 로그온 프로세스(Kerberos)가 포함되어 있습니다.

KList

KList는 Windows Server 2008 및 Windows Server 2008 R2의 기본 설치에 포함된 명령줄 유틸리티로, 지정된 컴퓨터에서 Kerberos 티켓을 나열하고 제거하는 데 사용할 수 있습니다. KLIST를 실행하려면 Windows Server 2008에서 명령 프롬프트를 실행하고 Klist를 입력합니다.

티켓 캐시를 제거하려면 선택적 purge 매개 변수를 포함하여 Klist purge와 같이 Klist를 실행합니다.

KerbTray

KerbTray는 Windows Server 2000 Resource Kit Tool에 포함된 무료 유틸리티로, 클라이언트 컴퓨터에 설치하여 Kerberos 티켓 캐시를 확인하는 데 사용할 수 있습니다. Windows 2000 Resource Kit Tool: Kerbtray.exe(영문일 수 있음)에서 KerbTray를 다운로드하여 설치할 수 있습니다. KerbTray를 설치한 후에 다음 작업을 수행합니다.

1. Kerberos 인증을 사용하는 웹 사이트로 이동합니다.

2. KerbTray.exe를 실행합니다.

3. 시스템 트레이에서 KerbTray 아이콘을 마우스 오른쪽 단추로 클릭하고 List Tickets(티켓 목록 표시)를 선택하여 Kerberos 티켓 캐시를 확인합니다.

4. 인증한 웹 응용 프로그램의 서비스 티켓이 캐시된 티켓 목록에 들어 있는지 확인합니다. 이 예제에서는 다음과 같은 SPN이 등록된 다음 웹 사이트를 탐색했습니다.

   웹 사이트 URL	SPN
   http://portal	HTTP/Portal.vmlab.local
   http://teams:5555	HTTP/Teams.vmlab.local

Fiddler

Fiddler는 http://www.fiddler2.com/fiddler2/(영문일 수 있음)에서 다운로드할 수 있는 무료 HTTP 트래픽 분석기입니다. Fiddler에서는 클라이언트와 서버가 Kerberos 인증을 협상하는 과정과, 클라이언트가 각 요청의 HTTP 헤더에서 Kerberos 서비스 티켓을 서버로 보내는 작업을 확인할 수 있습니다. Fiddler를 사용하여 Kerberos 인증이 정상적으로 작동하는지 확인하려면 다음 작업을 수행합니다.

1. Fiddler(www.fiddlertool.com(영문일 수 있음))를 클라이언트 컴퓨터에 다운로드하여 설치합니다.

2. 데스크톱에서 로그아웃했다가 다시 로그인하여 웹 서버에 대한 캐시된 연결을 플러시하고, 브라우저가 Kerberos 인증을 협상하도록 강제 지정한 후에 인증 핸드셰이크를 수행합니다.

3. Fiddler를 시작합니다.

4. Internet Explorer를 열고 웹 응용 프로그램(이 예제에서는 http://portal)으로 이동합니다.

Fiddler에 SharePoint Server 프런트 엔드 웹에 대한 요청 및 응답이 표시됩니다.

첫 번째 HTTP 401은 브라우저가 인증을 하지 않고 GET 요청을 수행하려는 시도입니다. 이 시도에 대한 응답에서 서버는 "HTTP 401 - 권한 없음"을 보내며, 이 응답에는 지원되는 인증 방법이 표시됩니다. 다음 요청에서 클라이언트는 이전 요청을 다시 보내되, 이번에는 요청 헤더에 웹 응용 프로그램의 서비스 티켓을 포함하여 보냅니다. 인증이 성공하면 서버에서는 요청받은 리소스를 보냅니다.

NetMon 3.4

NetMon 3.4는 Microsoft 다운로드 센터(Microsoft Network Monitor 3.4(영문일 수 있음))에서 다운로드할 수 있는 Microsoft의 무료 네트워크 패킷 분석기입니다.

NetMon에는 KDC 및 SharePoint Server 웹 서버에 대한 모든 TCP 요청 및 응답이 표시되므로, 완전한 인증 요청을 구성하는 전체 트래픽을 확인할 수 있습니다. NetMon을 사용하여 Kerberos 인증이 작동하는지 확인하려면 다음 작업을 수행합니다.

1. NetMon 3.4(Microsoft Network Monitor 3.4(영문일 수 있음))를 다운로드하여 설치합니다.

2. 클라이언트에서 로그아웃했다가 다시 로그인하여 Kerberos 티켓 캐시를 플러시합니다. 원하는 경우 KerbTray를 사용(KerbTray를 마우스 오른쪽 단추로 클릭하고 Purge Tickets(티켓 제거) 선택)하여 티켓 캐시를 제거할 수 있습니다.

3. NetMon을 관리자 모드로 시작합니다. 이렇게 하려면 NetMon 바로 가기를 마우스 오른쪽 단추로 클릭하고 관리자 권한으로 실행을 선택합니다.

4. 환경의 활성 디렉터리 컨트롤러 및 웹 프런트 엔드에 연결되는 인터페이스에서 새 캡처를 시작합니다.

5. Internet Explorer를 열고 웹 응용 프로그램으로 이동합니다.

6. 웹 사이트가 렌더링되고 나면 캡처를 중지하고 Kerberos 인증 및 HTTP 트래픽용 프레임을 표시하도록 표시 필터를 추가합니다.

7. 프레임 창에는 HTTP 및 KerberosV5 트래픽이 모두 표시됩니다.

SSL을 통한 Kerberos 인증 테스트

클라이언트가 SSL로 보호된 리소스에 액세스할 때 요청되는 SPN을 명확하게 확인하려면 NetMon과 같은 도구를 사용하여 클라이언트와 서버 간의 트래픽을 캡처한 후에 Kerberos 서비스 티켓 요청을 확인하면 됩니다.

1. 클라이언트 컴퓨터에서 로그아웃했다가 다시 로그인하거나, KerbTray를 사용하여 캐시된 Kerberos 티켓을 모두 지웁니다.

2. 클라이언트 컴퓨터에서 새 NetMon 캡처를 시작합니다. 이때 NetMon을 관리자 권한으로 시작해야 합니다.

3. SSL을 사용하는 웹 응용 프로그램(이 예제에서는 https://portal)로 이동합니다.

4. NetMon 캡처를 중지하고 KerberosV5 트래픽을 확인합니다. 캡처 표시를 필터링하는 방법에 대한 지침은 이 문서의 NetMon 3.4 섹션에 나와 있는 지침을 참조하십시오.

5. 클라이언트가 보내는 TGS 요청을 확인합니다. 이 요청의 "Sname" 매개 변수에서 요청된 SPN을 확인할 수 있습니다.

   "Sname"은 HTTPS/portal.vmlab.local이 아닌 HTTP/portal.vmlab.local입니다.

SharePoint Server 검색 인덱스 및 쿼리 테스트

인덱스 서버에서 브라우저 액세스 확인

크롤링을 실행하기 전에 인덱스 서버가 웹 응용 프로그램에 액세스하여 정상적으로 인증할 수 있는지 확인합니다. 이렇게 하려면 인덱스 서버에 로그인한 다음 브라우저에서 테스트 사이트 모음을 엽니다. 사이트가 정상적으로 렌더링되고 인증 대화 상자가 표시되지 않으면 다음 단계로 진행합니다. 브라우저에서 사이트에 액세스하는 중에 문제가 발생하는 경우에는 이전 단계로 돌아가서 모든 구성 작업을 제대로 수행했는지 확인합니다.

예제 콘텐츠를 업로드하고 크롤링 수행

각 사이트 모음의 문서 라이브러리에 "시드" 문서, 즉 검색에서 쉽게 식별되는 문서를 업로드합니다. 예를 들어 "알파, 베타, 델타"라는 단어가 포함된 텍스트 문서를 만들어 각 사이트 모음의 문서 라이브러리에 저장합니다.

다음으로 SharePoint 중앙 관리로 이동하여 로컬 SharePoint 사이트 콘텐츠 원본(기본적으로 테스트 사이트 모음 2개가 포함됨)에 대해 전체 크롤링을 시작합니다.

검색 테스트

인덱싱이 정상적으로 완료되는 경우 인덱스에는 검색 가능한 항목이 표시되고 크롤링 로그에는 오류가 없어야 합니다.

참고

UPA(사용자 프로필 응용 프로그램)를 구성했으며 프로필 저장소에 대해 크롤링을 수행하는 경우에는 콘텐츠 액세스 계정이 프로필 데이터에 액세스할 수 있도록 UPA에서 적절한 사용 권한을 구성해야 합니다. UPA 사용 권한을 구성하지 않으면 크롤러가 프로필 서비스에 액세스할 때 HTTP 401이 발생하여 서비스에 액세스할 수 없음을 나타내는 오류가 크롤링 로그에 표시됩니다. 이때 401 오류는 Kerberos 때문에 반환되는 것이 아니라, 콘텐츠 액세스 계정에 프로필 데이터 읽기 권한이 없어서 반환되는 것입니다.

다음으로 각 사이트 모음으로 이동하여 시드 문서 검색을 수행합니다. 각 사이트 모음의 검색 쿼리에서 업로드한 시드 문서를 반환합니다.

프런트 엔드 웹 위임 테스트

이 시나리오의 마지막 단계로는 각 사이트 모음에서 RSS 뷰어 웹 파트를 사용하여 위임이 로컬 및 원격에서 모두 작동하는지 확인합니다.

각 사이트 모음에서 RSS 피드 원본 구성

포털 응용 프로그램의 경우에는 사이트 모음에서 RSS 피드를 사용하도록 설정해야 합니다. RSS 피드를 설정하려면 Office.com의 RSS 피드 관리에 나와 있는 지침을 따릅니다.

RSS 피드를 사용하도록 설정한 후에 새 사용자 지정 목록을 만들고 테스트용으로 목록 항목을 추가합니다. 그런 다음 목록 도구 모음 메뉴에서 RSS 피드를 클릭하여 RSS 피드를 표시하고, 다음 단계에 사용하기 위해 피드 URL을 복사합니다.

각 사이트 모음에 대해 이 단계를 수행합니다.

각 사이트 모음의 홈 페이지에 RSS 보기 웹 파트 추가

포털 응용 프로그램에서는 RSS 뷰어 웹 파트를 사용하려면 SharePoint Enterprise 기능 사이트 모음 기능을 사용하도록 설정해야 합니다. 이 기능을 사용하도록 설정한 후에 RSS 뷰어 웹 파트 2개를 홈 페이지에 추가합니다. 첫 번째 웹 파트의 경우 이전 단계에서 만든 로컬 RSS 피드를 가리키도록 피드 URL을 구성하고, 두 번째 웹 파트의 경우 원격 피드 URL을 가리키도록 피드 URL을 구성합니다. 이 작업을 완료하면 두 웹 파트가 로컬 및 원격 RSS 피드의 콘텐츠를 정상적으로 렌더링합니다.