Windows™ 여러 Active Directory 도메인에서 웹 클라이언트에 대한 싱글 사인온
Windows™ 환경에 여러 Active Directory 도메인이 포함된 경우, 도메인 간에 작동하는 웹 클라이언트에 대한 Windows™ 싱글 사인온을 설정할 수 있습니다. 이 구성에 대한 추가 요구사항 및 권장사항이 있습니다.
Active Directory 신뢰 요구사항
이 태스크 정보
Windows™ 관리자는 Active Directory 도메인 및 신뢰 스냅인 유틸리티를 사용하여 도메인 간에 포리스트 신뢰 관계를 설정해야 합니다. 외부 신뢰 관계는 Kerberos 인증을 지원하지 않기 때문에 사용할 수 없습니다. 신뢰 관계 설정에 대한 정보는 Microsoft™ 설명서를 참조하십시오.
상위 도메인은 하위 도메인을 암시적으로 신뢰하므로 두 도메인 간의 신뢰 구성이 필요하지 않습니다. 하위 도메인은 DNS 계층의 다른 도메인에서 한 레벨 아래의 도메인입니다. 예를 들어 sales.east.renovations.com은 east.renovations.com의 하위 도메인입니다.
지원되는 포리스트 신뢰 유형은 다음과 같습니다.
- 양방향 Windows™ 포리스트 신뢰. 예를 들어 포리스트 A와 B 사이에 양방향 신뢰가 있으면 포리스트 A와 B의 사용자는 두 포리스트의 서버에 액세스할 수 있습니다.
- 다른 포리스트를 위한 단방향 수신 신뢰. 예를 들어 포리스트 A가 포리스트 B에 대한 수신 신뢰를 가진 경우 포리스트 A 사용자는 포리스트 B 서버에 액세스할 수 있습니다. 마찬가지로 포리스트 B 사용자가 포리스트 A에 대한 수신 신뢰를 가지고 있지 않으면 포리스트 B 사용자는 포리스트 A에 액세스할 수 없습니다.
- 다른 포리스트를 위한 단방향 송신 신뢰. 예를 들어 포리스트 A가 포리스트 B에 대한 송신 신뢰를 가진 경우 포리스트 B 사용자는 포리스트 A 서버에 액세스할 수 있습니다. 마찬가지로 포리스트 B 사용자가 포리스트 A에 대한 송신 신뢰를 가지고 있지 않으면 포리스트 A 사용자는 포리스트 B에 액세스할 수 없습니다.
- 전이적 신뢰. 포리스트 A 사용자가 신뢰 때문에 포리스트 B 서버에 액세스할 수 있을 경우 포리스트 A와 B 간의 신뢰가 전이적 신뢰로 구성된 경우 포리스트 A의 하위 도메인에 있는 사용자도 포리스트 B 서버에 액세스할 수 있습니다.
Active Directory 도메인에 대해 신뢰 관계가 설정되었는지 여부를 확인하려면:
프로시저
- [관리 도구] 메뉴에서 Active Directory 도메인 및 신뢰 유틸리티를 엽니다.
- 도메인에서 마우스 오른쪽 단추를 클릭한 다음 [특성]을 클릭합니다.
- [신뢰] 탭을 클릭하면 신뢰할 수 있는 도메인 목록이 표시됩니다.
컴퓨터 시계 동기화
이 태스크 정보
도메인 내/도메인 간의 서버 클록은 Kerberos(웹 클라이언트용 Windows™ 싱글 사인온을 위한 기본 보안 메커니즘)가 클록 스큐의 영향을 받으므로 최대한 가깝게 동기화를 유지해야 합니다. 가능하면 정확한 클록 스큐를 유지해야 합니다. 필요한 경우, Windows™ 관리자는 다음 단계를 수행하여 클록 스큐의 허용 오차를 높일 수 있습니다.
프로시저
- 그룹 정책 관리 콘솔을 시작합니다. (예를 들어, Windows™ Server 2008에서 시작 > 실행을 클릭하고 gpmc.msc를 입력한 후 확인을 클릭합니다.)
- 콘솔 트리에서 도메인을 찾아 해당 트리를 확장합니다.
- 그룹 정책 오브젝트를 확장합니다.
- 그룹 정책 오브젝트 아래에서 기본 도메인 정책을 클릭하십시오. 그러면 기본 도메인 정책이 나타납니다. 기본 도메인 정책의 [설정] 탭에서 [보안] 설정을 클릭한 다음 [계정 정책/Kerberos 정책]을 클릭합니다.
- 컴퓨터 시계 동기화에 대한 최대 허용 오차를 두 번 클릭하여 해당 설정을 편집합니다.
DNS 요구사항
east.renovations.com 및 west.renovations.com 등과 같이 도메인마다 고유한 이름 계층이 있을 경우 네트워크 관리자는 컴퓨터에서 다른 도메인의 이름을 확인할 수 있는 DNS 전달 조회 영역과 역방향 조회 영역을 구성해야 합니다.
브라우저 요구사항
각 대상 Active Directory 도메인에 대해 Windows™ 싱글 사인온을 허용하도록 브라우저를 구성해야 합니다.
Domino® 이름 조회 요구사항
각 Domino® 서버는 Active Directory 도메인에 있는 사용자에 대해 Kerberos 이름을 검색할 수 있어야 합니다. 사용자의 Kerberos 이름이 여러 Domino® 디렉토리에 저장된 경우, Domino® 관리자는 디렉토리 카탈로그 또는 디렉토리 보조자를 사용하여 2차 Domino® 디렉토리에 있는 사용자 이름을 조회할 수 있도록 각 Domino® 서버를 설정해야 합니다. 사용자의 Kerberos 이름이 디렉토리 보조자에서 Active Directory로 분석되는 경우, 각 Domino® 서버는 디렉토리 보조자를 사용하여 사용자가 있는 각 Active Directory에서 이름을 검색할 수 있습니다.
싱글 사인온 구성 권장사항
이 태스크 정보
Windows™ 싱글 사인온이 사용자에 대해 수행되면, Domino® 서버에서 사용자에 대한 LTPA 토큰을 리턴합니다. Domino® 서버가 동일한 SSO 구성을 공유할지 여부를 고려하여 SSO 배치를 주의하여 계획해야 합니다.
예를 들어 도메인 "west.renovations.com"의 서버와 동일한 SSO 키를 공유하도록 도메인 "east.renovations.com"의 서버에 대한 SSO 구성을 설정한 경우, east 서버는 west 서버에서 작성한 LTPA 토큰을 승인할 수 있습니다. 이 경우 SSO 환경 설정 문서는 "renovations.com"과 같은 일반 DNS 도메인을 사용할 수 있습니다.
그러나 east와 west에 있는 서버가 동일한 SSO 키를 공유하지 않는 경우 "renovations.com"과 같은 일반 DNS 도메인을 사용한다면 SSO는 효율성이 떨어집니다. 대신, SSO 도메인을 작동할 Windows™ DNS 도메인에 맞게 조정해야 합니다.
예: 비효율적인 SSO 구성
다음 예는 west.renovations.com과 east.renovations.com의 서버가 동일한 SSO 키를 공유하지 않을 경우 일반 SSO 도메인 renovations.com의 사용이 얼마나 비효율적인지 보여줍니다.
프로시저
- 사용자는 Windows™ 싱글 사인온을 사용하여 east.renovations.com의 서버에 인증합니다. east 서버는 east 서버의 SSO 키를 사용하여 사용자의 LTPA 토큰을 작성합니다. 사용자의 브라우저는 renovations.com DNS 도메인에서 사용할 LTPA 토큰을 획득합니다.
- 사용자가 west.renovations.com의 서버에 액세스합니다. 브라우저는 renovations.com의 모든 서버에 적용되도록 설정된 LTPA 토큰을 보냅니다. west.renovations.com의 서버는 토큰의 유효성을 검증하는 데 시간을 사용하지만, east 서버와 SSO 키를 공유하지 않기 때문에 검증할 수 없습니다.
- west 서버는 기존 LTPA 토큰의 유효성을 검증할 수 없으므로 Windows™ 싱글 사인온을 통해 사용자를 인증해야 합니다. west 서버는 west 서버의 SSO 키를 사용하여 사용자의 LTPA 토큰을 작성합니다. 사용자의 브라우저는 renovations.com DNS 도메인에서 사용할 새 LTPA 토큰을 획득합니다. 이제 브라우저는 west 서버에서 작성한 LTPA 토큰만 가지며, 이 토큰이 이전 토큰을 대체합니다.
- 사용자가 east.renovations.com의 서버에 액세스합니다. 브라우저는 renovations.com의 모든 서버에 적용되도록 설정된 LTPA 토큰을 보냅니다. east 서버는 토큰의 유효성을 검증하는 데 시간을 사용하지만, west 서버가 대체 SSO 키를 사용하여 토큰을 작성했기 때문에 검증할 수 없습니다. 사용자는 Windows™ 싱글 사인온을 사용하여 east 서버에 대해 다시 인증을 받아야 합니다. east 서버는 기존 LTPA 토큰을 덮어씁니다.
결과
Windows™ 싱글 사인온을 사용하고 LTPA 토큰 겹쳐쓰기를 반복적으로 수행하는 것은 매우 비효율적인 작업입니다.
예: 효율적인 SSO 구성
다음 예는 west.renovations.com 및 east.renovations.com의 서버가 SSO 키를 공유하지 않을 경우 Windows™ 도메인에 대해 사용자 조정한 SSO 도메인을 사용할 때 효율성이 향상되는 것을 보여줍니다.
프로시저
- 사용자 east.renovations.com의 서버에 인증하고 east.renovations.com DNS 도메인에서 사용할 LTPA 토큰을 획득합니다.
- 사용자가 west.renovations.com의 서버에 액세스합니다. 브라우저는 LTPA 토큰을 보내지 않습니다. 이것은 east 서버에 대해서만 적용됩니다.
- west 서버는 Windows™ 싱글 사인온을 통해 사용자를 인증해야 합니다. 사용자는 west.renovations.com DNS 도메인에서 사용할 두 번째 LTPA 토큰을 획득합니다.
- 사용자는 east.renovations.com에서 서버에 액세스합니다. 브라우저는 모든 east 서버에 적용되도록 설정된 첫 번째 LTPA 토큰을 보냅니다. east 서버는 LTPA 토큰을 사용하여 사용자를 식별합니다.
- 사용자는 west.renovations.com에서 서버에 액세스합니다. 브라우저는 모든 west 서버에 적용되도록 설정된 두 번째 LTPA 토큰을 보냅니다. west 서버는 LTPA 토큰을 사용하여 사용자를 식별합니다.