Windows Server에 대한 AD FS 요구 사항
다음은 AD FS를 배포 하는 경우를 준수 해야 하는 다양 한 요구 사항:
5\. 인증서가 RD 게이트웨이에 대한 요구 사항을 충족하면 설치를 클릭합니다.
인증서 요구 사항
인증서는 페더레이션 서버, 웹 애플리케이션 프록시, 클레임 인식 애플리케이션 및 웹 클라이언트 간의 통신을 보호하는 데 가장 중요한 역할을 합니다. 인증서에 대한 요구 사항은 이 섹션에 설명된 대로 페더레이션 서버 또는 프록시 컴퓨터를 설정하는지 여부에 따라 달라집니다.
페더레이션 서버 인증서
| 인증서 유형 | 요구 사항, 지원 및 알아야 할 사항 |
|---|---|
| SSL(Secure Sockets Layer) 인증서: 페더레이션 서버와 클라이언트 간의 통신을 보호하는 데 사용되는 표준 SSL 인증서입니다. | - 이 인증서는 공개적으로 신뢰할 수 있는* X509 v3 인증서여야 합니다. -모든 AD FS 엔드포인트에 액세스 하는 모든 클라이언트는이 인증서를 신뢰 해야 합니다. 공용(타사) CA(인증 기관)에서 발급한 인증서를 사용하는 것이 좋습니다. 테스트 랩 환경의 페더레이션 서버에서 자체 서명된 SSL 인증서를 사용할 수 있습니다. 그러나 프로덕션 환경에서는 공용 CA에서 인증서를 얻는 것이 좋습니다. -SSL 인증서에 대 한 Windows Server 2012 r 2에서 지 원하는 모든 키 크기를 지원 합니다. - CNG 키를 사용하는 인증서를 지원하지 않습니다. - Workplace Join/Device Registration Service와 함께 사용하는 경우 AD FS 서비스에 대한 SSL 인증서의 주체 대체 이름에는 조직의 UPN(사용자 계정 이름) 접미사 뒤에 enterpriseregistration.contoso.com 값이 포함되어야 합니다. -와일드 카드 인증서 지원 됩니다. AD FS 팜을 만들 때 AD FS 서비스의 서비스 이름(예 : adfs.contoso.com)을 입력하라는 메시지가 표시됩니다. - 웹 애플리케이션 프록시 동일한 SSL 인증서를 사용하는 것이 좋습니다. 그러나 이는 웹 애플리케이션 프록시 통해 Windows 통합 인증 엔드포인트를 지원하고 확장된 보호 인증이 켜져 있는 경우(기본 설정) 동일해야 합니다. 이 인증서의 주체 이름-배포 하는 AD FS의 각 인스턴스에 대 한 페더레이션 서비스 이름을 나타내는 데 사용 됩니다. 따라서 CA가 발급한 새 인증서에서 회사 또는 조직의 이름을 파트너에게 가장 잘 나타내는 주체 이름을 선택하는 것이 좋습니다. 인증서의 ID는 페더레이션 서비스 이름(예: fs.contoso.com)과 일치해야 합니다. ID는 dNSName 형식의 주체 대체 이름 확장이거나 주체 대체 이름 항목이 없는 경우 일반 이름으로 지정된 주체 이름입니다. 그 중 하나가 페더레이션 서비스 이름과 일치 하는 경우에 여러 주체 대체 이름 항목이 인증서에 사용할 수 있습니다. - 중요: AD FS 팜의 모든 노드와 AD FS 팜의 모든 웹 애플리케이션 프록시에서 동일한 SSL 인증서를 사용하는 것이 좋습니다. |
| 서비스 통신 인증서: 이 인증서는 페더레이션 서버 간의 통신 보안에 대 한 메시지 보안 WCF를 사용 합니다. | -기본적으로 SSL 인증서는 서비스 통신 인증서로 사용 됩니다. 하지만 서비스 통신 인증서로 다른 인증서를 구성 하는 옵션도 있습니다. - 중요: SSL 인증서를 서비스 통신 인증서로 사용하는 경우 SSL 인증서가 만료되면 갱신된 SSL 인증서를 서비스 통신 인증서로 구성해야 합니다. 이 작업은 자동으로 발생하지 않습니다. -WCF 메시지 보안을 사용 하는 AD FS의 클라이언트가이 인증서를 신뢰 해야 합니다. - 공용(타사) CA(인증 기관)에서 발급한 서버 인증 인증서를 사용하는 것이 좋습니다. - 서비스 통신 인증서는 CNG 키를 사용하는 인증서일 수 없습니다. -이 인증서는 AD FS 관리 콘솔을 사용 하 여 관리할 수 있습니다. |
| 토큰 서명 인증서: 페더레이션 서버에서 발급하는 모든 토큰을 안전하게 서명하는 데 사용되는 표준 X509 인증서입니다. | - 기본적으로 AD FS는 2048비트 키를 사용하여 자체 서명된 인증서를 만듭니다. - CA 발급 인증서도 지원되며 AD FS 관리 스냅인을 사용하여 변경할 수 있습니다. -CA 인증서를 발급 한 저장 & CSP 암호화 공급자를 통해 액세스할 수 있어야 합니다. - 토큰 서명 인증서는 CNG 키를 사용하는 인증서일 수 없습니다. - AD FS는 토큰 서명에 외부에서 등록된 인증서가 필요하지 않습니다. AD FS는 만료되기 전에 이러한 자체 서명된 인증서를 자동으로 갱신하고, 먼저 파트너가 인증서를 사용할 수 있도록 새 인증서를 보조 인증서로 구성한 다음, 자동 인증서 롤오버라는 프로세스에서 기본 인증서로 전환합니다. 토큰 서명에 자동으로 생성된 기본 인증서를 사용하는 것이 좋습니다. 조직에 토큰 서명을 위해 다른 인증서를 구성해야 하는 정책이 있는 경우 PowerShell을 사용하여 설치 시 인증서를 지정할 수 있습니다(Install-AdfsFarm cmdlet의 –SigningCertificateThumbprint 매개 변수 사용). 설치 후 AD FS 관리 콘솔 또는 PowerShell cmdlet Set-AdfsCertificate 및 Get-AdfsCertificate를 사용하여 토큰 서명 인증서를 보고 관리할 수 있습니다. 외부에서 등록된 인증서가 토큰 서명에 사용되는 경우 AD FS는 자동 인증서 갱신 또는 롤오버를 수행하지 않습니다. 이 프로세스는 관리자가 수행 되어야 합니다. 위해 인증서 롤오버에 대 한 하나의 인증서가 만료 되 면 보조 토큰 서명 인증서가 AD FS에서 구성할 수 있습니다. 기본적으로 모든 토큰 서명 인증서는 페더레이션 메타데이터에 게시되지만 AD FS는 기본 토큰 서명 인증서만 사용하여 실제로 토큰에 서명합니다. |
| 토큰 암호 해독/암호화 인증서: 들어오는 토큰의 암호를 해독/암호화하는 데 사용되는 표준 X509 인증서입니다. 페더레이션 메타데이터에도 게시됩니다. | - 기본적으로 AD FS는 2048비트 키를 사용하여 자체 서명된 인증서를 만듭니다. - CA 발급 인증서도 지원되며 AD FS 관리 스냅인을 사용하여 변경할 수 있습니다. -CA 인증서를 발급 한 저장 & CSP 암호화 공급자를 통해 액세스할 수 있어야 합니다. - 토큰 암호 해독/암호화 인증서는 CNG 키를 사용하는 인증서일 수 없습니다. - 기본적으로 AD FS는 토큰 암호 해독을 위해 내부적으로 생성된 자체 서명된 인증서를 생성하고 사용합니다. 이 목적을 위해 AD FS에는 외부에 등록된 인증서가 필요하지 않습니다. 또한 AD FS는 만료되기 전에 자체 서명된 인증서를 자동으로 갱신합니다. 토큰 암호 해독을 위해 자동으로 생성된 기본 인증서를 사용하는 것이 좋습니다. 조직에 토큰 암호 해독을 위해 다른 인증서를 구성해야 하는 정책이 있는 경우 PowerShell을 사용하여 설치 시 인증서를 지정할 수 있습니다(Install-AdfsFarm cmdlet의 –DecryptionCertificateThumbprint 매개 변수 사용). 설치 후 AD FS 관리 콘솔 또는 PowerShell cmdlet Set-AdfsCertificate 및 Get-AdfsCertificate를 사용하여 토큰 암호 해독 인증서를 보고 관리할 수 있습니다. 외부에서 등록된 인증서가 토큰 암호 해독에 사용되는 경우 AD FS는 자동 인증서 갱신을 수행하지 않습니다. 이 프로세스는 관리자가 수행해야 합니다.. - AD FS 서비스 계정은 로컬 컴퓨터의 개인 저장소에 있는 토큰 서명 인증서의 프라이빗 키에 액세스할 수 있어야 합니다. 이 알아서 설치 합니다. 이후에 토큰 서명 인증서를 변경하는 경우 AD FS 관리 스냅인을 사용하여 이 액세스를 보장할 수도 있습니다. |
주의
토큰 서명 및 토큰 암호 해독/암호화에 사용되는 인증서는 페더레이션 서비스의 안정성에 매우 중요합니다. 자체 토큰 서명 및 토큰 암호 해독/암호화 인증서를 관리하는 고객은 이러한 인증서가 백업되고 복구 이벤트 중에 독립적으로 사용할 수 있도록 해야 합니다.
참고 항목
AD FS에서 디지털 서명에 사용되는 SHA(Secure Hash Algorithm) 수준을 SHA-1 또는 SHA-256(더 안전한)으로 변경할 수 있습니다. AD FS는 MD5(Makecert.exe 명령줄 도구와 함께 사용되는 기본 해시 알고리즘)와 같은 다른 해시 메서드에서 인증서 사용을 지원하지 않습니다. 최상의 보안 방법으로, 모든 서명에 SHA-256(기본적으로 설정됨)을 사용하는 것이 좋습니다. SHA-1은 타사 제품 또는 레거시 버전의 AD FS와 같이 SHA-256을 사용하는 통신을 지원하지 않는 제품과 상호 운용해야 하는 시나리오에서만 사용하는 것이 좋습니다.
참고 항목
CA에서 인증서를 받은 후에는 모든 인증서를 로컬 컴퓨터의 개인 인증서 저장소로 가져와야 합니다. 인증서 MMC 스냅인을 사용하여 인증서를 개인 저장소로 가져올 수 있습니다.
하드웨어 요구 사항
다음 최소 및 권장 하드웨어 요구 사항은 Windows Server 2012 r 2의 AD FS 페더레이션 서버에 적용 됩니다.
| 하드웨어 요구 사항 | 최소 요구 사항 | 권장 요구 사항 |
|---|---|---|
| CPU 속도 | 1.4GHz 64비트 프로세서 | 쿼드 코어, 2GHz |
| RAM | 512MB | 4GB |
| 디스크 공간 | 32GB | 100GB |
소프트웨어 요구 사항
다음 AD FS 요구 사항은 Windows Server® 2012 R2 운영 체제에 기본 제공 되는 서버 기능을 위해:
엑스트라넷 액세스의 경우 Windows Server® 2012 R2 원격 액세스 서버 역할의 일부인 웹 애플리케이션 프록시 역할 서비스를 배포해야 합니다. Windows Server® 2012 r 2에서 AD FS와 이전 버전의 페더레이션 서버 프록시를 사용 하는 것이 없습니다.
페더레이션 서버와 웹 애플리케이션 프록시 역할 서비스는 동일한 컴퓨터에 설치할 수 없습니다.
AD DS 요구 사항
도메인 컨트롤러 요구 사항
모든 사용자 도메인 및 AD FS 서버 가입 된 도메인의 도메인 컨트롤러 2008 이상 Windows Server를 실행 되어야 합니다.
참고 항목
Windows Server 2003 도메인 컨트롤러와 환경에 대 한 모든 지원이 확장 지원 종료 날짜에 대 한 Windows Server 2003 후에 종료 됩니다. 가능한 한 빨리 해당 도메인 컨트롤러를 업그레이드 하려면 고객을 사용 하는 것이 좋습니다. 방문 이 페이지 Microsoft 지원 기간에 대 한 추가 정보입니다. 발견 된 문제 수 있는 Windows Server 2003 도메인 컨트롤러 환경에 특정 한 수정 프로그램이 실행 될 보안 문제에 대해서만 하 고 수정 프로그램을 확장 지원 Windows Server 2003의 만료 되기 전에 실행 될 수 있습니다.
참고 항목
AD FS에는 읽기 전용 Do기본 컨트롤러가 아닌 전체 쓰기 가능한 Do기본 컨트롤러가 작동해야 합니다. 계획된 토폴로지에서 읽기 전용 Do기본 컨트롤러를 포함하는 경우 읽기 전용 do기본 컨트롤러를 인증에 사용할 수 있지만 LDAP 클레임 처리에는 쓰기 가능한 do기본 컨트롤러에 대한 연결이 필요합니다.
do기본 기능 수준 요구 사항
모든 사용자 계정 도메인 및 AD FS 서버 가입 된 도메인의 Windows Server 2003 이상 도메인 기능 수준에서 작동 해야 합니다.
대부분의 AD FS 기능은 AD DS를 기능 수준에서 수정하지 않아도 정상적으로 작동합니다. 그러나 인증서가 AD DS의 사용자 계정에 명시적으로 매핑된 경우에는 Windows Server 2008 도메인 기능 수준 이상이 있어야 클라이언트 인증서 인증이 작동합니다.
스키마 요구 사항
AD FS는 AD DS에 대한 스키마 변경 또는 기능 수준 수정이 필요하지 않습니다.
작업 공간 연결 기능을 사용 하려면 AD FS 서버에 가입 된 포리스트의 스키마를 Windows Server 2012 r 2로 설정 되어야 합니다.
서비스 계정 요구 사항
모든 표준 서비스 계정은 AD FS에 대 한 서비스 계정으로 사용할 수 있습니다. 그룹 관리 서비스 계정도 지원됩니다. 이렇게 하려면 Windows Server 2012 이상을 실행하는 하나 이상의 do기본 컨트롤러(둘 이상을 배포하는 것이 좋습니다)가 필요합니다.
do기본 조인 클라이언트와 AD FS 간에 작동하려면 'HOST/<adfs_service_name>'를 서비스 계정에서 SPN으로 등록해야 합니다. 기본적으로 AD FS이 키를 구성 하기에 충분 한 권한이이 작업을 수행할 경우 새 AD FS 팜을 만들 때.
AD FS 서비스 계정이 AD FS 서비스를 인증 하는 사용자를 포함 하는 모든 사용자 도메인에서 신뢰 되어야 합니다.
도메인 요구 사항
모든 AD FS 서버는 AD DS 도메인에 조인 이어야 합니다.
모든 AD FS 서버 팜 내에서 단일 도메인에 배포 되어야 합니다.
AD FS 서버에 가입 된 도메인에는 AD FS 서비스에 인증 하는 사용자가 포함 된 모든 사용자 계정 도메인을 신뢰 해야 합니다.
다중 포리스트 요구 사항
모든 사용자 계정 도메인 이나 포리스트의 AD FS 서비스에 인증 하는 사용자가 포함 된 AD FS 서버에 가입 된 도메인 신뢰 해야 합니다.
AD FS 서비스 계정이 AD FS 서비스를 인증 하는 사용자를 포함 하는 모든 사용자 도메인에서 신뢰 되어야 합니다.
구성 데이터베이스 요구 사항
다음은 요구 사항 및 구성 저장소의 형식에 따라 적용 되는 제한:
WID
신뢰 당사자 트러스트가 100개 이하인 경우 WID 팜에는 페더레이션 서버가 30개로 제한됩니다.
SAML 2.0의 아티팩트 확인 프로필은 WID 구성 데이터베이스에서 지원되지 않습니다. 토큰 재생 검색은 WID 구성 데이터베이스에서 지원되지 않습니다. 이 기능은 AD FS는 페더레이션 공급자 역할을 하 고 외부 클레임 공급자의 보안 토큰을 사용 하는 경우에만 사용 됩니다.
서버 수가 30을 초과하지 않는 한 장애 조치(failover) 또는 지리적 부하 분산을 위해 고유 데이터 센터에 AD FS 서버를 배포하는 것이 지원됩니다.
다음 표에서 WID 팜 사용에 대 한 요약을 제공 합니다. 구현 계획을 사용 합니다.
| 1-100개의 RP 트러스트 | 100 개가 넘는 RP 트러스트 |
|---|---|
| 1-30 AD FS 노드: WID 지원 | 1-30 AD FS 노드: WID를 사용하여 지원되지 않음 - SQL 필요 |
| 30개 이상의 AD FS 노드: WID를 사용하여 지원되지 않음 - SQL 필요 | 30개 이상의 AD FS 노드: WID를 사용하여 지원되지 않음 - SQL 필요 |
SQL Server
Windows Server 2012 R2의 AD FS의 경우 SQL Server 2008 이상을 사용할 수 있습니다.
브라우저 요구 사항
브라우저 또는 브라우저 컨트롤을 통해 AD FS 인증을 수행할 때는 브라우저 다음 요구 사항을 준수 해야 합니다.
JavaScript은 사용 하도록 설정
쿠키를 켜야 합니다.
SNI(서버 이름 표시)를 지원해야 합니다.
사용자 인증서 및 디바이스 인증서 인증(작업 공간 연결 기능)의 경우 브라우저에서 SSL 클라이언트 인증서 인증을 지원해야 합니다.
몇 가지 주요 브라우저 및 플랫폼 세부 사항으로는 아래 나열 된 렌더링 및 기능에 대 한 유효성 검사를 종류입니다. 위에 나열 된 요구 사항을 충족 하는 경우에 브라우저 및이 테이블에 포함 되지 않은 디바이스 지원 계속 됩니다.
| 브라우저 | Platforms |
|---|---|
| IE 10.0 | Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 |
| IE 11.0 | Windows 7의 경우, Windows 8.1, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 |
| Windows 웹 인증 브로커 | Windows 8.1 |
| Firefox [v21] | Windows 7, Windows 8.1 |
| Safari [v7] | iOS 6, Mac OS-X 10.7 |
| Chrome [v27] | Windows 7, Windows 8.1, Windows Server 2012, Windows Server 2012 R2, Mac OS-X 10.7 |
Important
알려진 문제 - Firefox: 디바이스 인증서를 사용하여 디바이스를 식별하는 작업 공간 조인 기능은 Windows 플랫폼에서 작동하지 않습니다. Firefox는 현재 Windows 클라이언트의 사용자 인증서 저장소에 프로비전된 인증서를 사용하여 SSL 클라이언트 인증서 인증 수행을 지원하지 않습니다.
쿠키
AD FS는 로그인, 로그아웃, SSO(Single Sign-On) 및 기타 기능을 제공하기 위해 클라이언트 컴퓨터에 저장해야 하는 세션 기반 및 영구 쿠키를 만듭니다. 따라서 클라이언트 브라우저가 쿠키를 허용하도록 구성되어야 합니다. 인증에 사용되는 쿠키는 항상 원래 서버에 대해 기록되는 HTTPS(Secure Hypertext Transfer Protocol) 세션 쿠키입니다. 클라이언트 브라우저가 이러한 쿠키를 허용하도록 구성되지 않은 경우 AD FS가 제대로 작동할 수 없습니다. 영구 쿠키는 사용자가 선택한 클레임 공급자를 유지하는 데 사용됩니다. 구성 파일에서 AD FS 로그인 페이지에 대한 구성 설정을 사용하여 쿠키를 사용하지 않도록 설정할 수 있습니다. TLS/SSL 지원은 보안상 필요합니다.
엑스트라넷 요구 사항
AD FS 서비스에 대 한 엑스트라넷 액세스를 제공 하려면 배포한 웹 애플리케이션 프록시 역할 서비스 엑스트라넷 연결 역할을 프록시 인증 요청을 사용 하는 AD FS 서비스를 안전한 방식. 이렇게 하면 AD FS 서비스 엔드포인트를 격리하고 인터넷에서 시작된 요청으로부터 모든 보안 키(예: 토큰 서명 인증서)를 격리할 수 있습니다. 또한 엑스트라넷 소프트 계정 잠금 등의 기능에는 웹 애플리케이션 프록시의 사용을 해야합니다. 웹 애플리케이션 프록시에 대 한 자세한 내용은 참조 웹 애플리케이션 프록시합니다. `
네트워크 요구 사항
다음 네트워크 서비스를 적절 하 게 구성 하는 것이 조직에서 AD FS의 성공적인 배포에 대 한 중요 합니다.
회사 방화벽 구성
웹 애플리케이션 프록시 및 페더레이션 서버 팜 및 클라이언트와 웹 애플리케이션 프록시 간의 방화벽 사이 있는 두 방화벽에는 TCP 포트 443을 사용할 수 있어야 합니다. 인바운드 합니다.
또한 클라이언트 사용자 인증서 인증(X509 사용자 인증서를 사용한 clientTLS 인증)이 필요한 경우 Windows Server 2012 R2의 AD FS를 사용하려면 클라이언트와 웹 애플리케이션 프록시 간의 방화벽에서 TCP 포트 49443을 인바운드로 사용하도록 설정해야 합니다. 웹 애플리케이션 프록시 및 페더레이션 서버) 간의 방화벽에는 필요하지 않습니다.
참고 항목
또한 AD FS 및 웹 애플리케이션 프록시 서버의 다른 서비스에서 포트 49443을 사용하지 않는지 확인합니다.
DNS 구성
인트라넷 액세스의 경우 내부 회사 네트워크(인트라넷) 내에서 AD FS 서비스에 액세스하는 모든 클라이언트는 AD FS 서비스 이름(SSL 인증서에서 제공하는 이름)을 AD FS 서버 또는 AD FS 서버의 부하 분산 장치로 확인할 수 있어야 합니다.
엑스트라넷 액세스의 경우 회사 네트워크 외부에서 AD FS 서비스에 액세스하는 모든 클라이언트(엑스트라넷/인터넷)는 AD FS 서비스 이름(SSL 인증서에서 제공하는 이름)을 웹 애플리케이션 프록시 서버 또는 웹 애플리케이션 프록시 서버의 부하 분산 장치로 확인할 수 있어야 합니다.
엑스트라넷 액세스가 제대로 작동하려면 DMZ의 각 웹 애플리케이션 프록시 서버가 AD FS 서비스 이름(SSL 인증서에서 제공하는 이름)을 AD FS 서버 또는 AD FS 서버의 부하 분산 장치로 확인할 수 있어야 합니다. 호스트 파일을 사용 하 여 로컬 서버 해상도 변경 하거나 DMZ 네트워크에 대체 DNS 서버를 사용 하 여 수행할 수 있습니다.
Windows 통합 인증이 웹 애플리케이션 프록시 통해 노출되는 엔드포인트의 하위 집합에 대해 네트워크 내부 및 네트워크 외부에서 작동하려면 A 레코드(CNAME 아님)를 사용하여 부하 분산 장치를 가리킵니다.
페더레이션 서비스에 대해 회사 DNS 및 디바이스 등록 서비스 구성에 대 한 내용은 참조 페더레이션 서비스와 DRS에 대해 회사 DNS 구성합니다.
웹 애플리케이션 프록시에 대한 회사 DNS 구성에 대한 자세한 내용은 1단계: 웹 애플리케이션 프록시 인프라 구성의 "DNS 구성" 섹션을 참조하세요.
NLB를 사용하여 클러스터 IP 주소 또는 클러스터 FQDN을 구성하는 방법에 대한 자세한 내용은 다음에서 http://go.microsoft.com/fwlink/?LinkId=75282클러스터 매개 변수 지정을 참조하세요.
특성 저장소 요구 사항
AD FS에는 해당 사용자에 대 한 보안 클레임을 추출 하는 사용자를 인증에 사용할 하나 이상의 특성 저장소가 필요 합니다. 특성의 목록이 저장 AD FS는 지원에 대 한 참조 The 특성 저장소의 역할합니다.
참고 항목
AD FS는 기본적으로 "Active Directory" 특성 저장소를 자동으로 만듭니다. 특성 저장소 요구 사항은 조직이 수행하는 역할(페더레이션된 사용자를 호스트하는 계정 파트너 또는 페더레이션된 애플리케이션을 호스트하는 리소스 파트너)에 따라 다릅니다.
LDAP 특성 저장소
다른 LDAP(Lightweight Directory Access Protocol) 기반 특성 저장소를 사용하는 경우 Windows 통합 인증을 지원하는 LDAP 서버에 연결해야 합니다. 또한 RFC 2255에 설명된 대로 LDAP URL 형식으로 LDAP 연결 문자열을 기록해야 합니다.
또한 AD FS 서비스의 서비스 계정에는 LDAP 특성 저장소에서 사용자 정보를 검색할 수 있는 권한이 필요합니다.
SQL Server 특성 저장소
AD fs가 작동 하려면 Windows Server 2012 r 2에서에서 SQL Server 특성 저장소를 호스팅하는 컴퓨터 실행 되어야 합니다 Microsoft SQL Server 2008 이상. 또한 SQL 기반 특성 저장소를 사용하는 경우 연결 문자열을 구성해야 합니다.
사용자 지정 특성 저장소
고급 시나리오를 지원하는 사용자 지정 특성 저장소를 개발할 수 있습니다.
AD FS에서 기본 제공되는 정책 언어는 다음 시나리오를 향상시킬 수 있도록 사용자 지정 특성 저장소를 참조할 수 있습니다.
로컬로 인증된 사용자에 대한 클레임 만들기
외부에서 인증된 사용자에 대한 클레임 보완
사용자에게 토큰을 가져올 수 있는 권한 부여
서비스에 사용자 대신 토큰을 가져올 수 있는 권한 부여
신뢰 당사자를 AD FS에서 발급 한 보안 토큰의 추가 데이터를 발급 합니다.
.NET 4.0을 기반으로 또는 그 보다 높은 모든 사용자 지정 특성 저장소를 빌드해야 합니다.
사용자 지정 특성 저장소를 사용 하는 경우 연결 문자열을 구성 하려면 할 수 있습니다. 이 경우 사용자가 선택한 사용자 지정 특성 저장소에 대 한 연결 수 있게 해 주는 사용자 지정 코드를 입력할 수 있습니다. 이 상황에서 연결 문자열 사용자 지정 특성 저장소의 개발자가 구현한 것으로 해석되는 이름/값 쌍 집합입니다. 사용자 지정 특성 저장소를 개발하고 사용하는 방법에 대한 자세한 내용은 특성 저장소 개요를 참조하세요.
애플리케이션 요구 사항
AD FS는 다음 프로토콜을 사용하는 클레임 인식 애플리케이션을 지원합니다.
WS-Federation
WS-Trust
IDPLite, SPLite 및 eGov1.5 프로필을 사용 하는 SAML 2.0 프로토콜입니다.
OAuth 2.0 권한 부여 프로필
AD FS는 웹 애플리케이션 프록시 지원되는 비 클레임 인식 애플리케이션에 대한 인증 및 권한 부여도 지원합니다.
인증 요구 사항
AD DS 인증(기본 인증)
AD DS에 대 한 다음과 같은 표준 인증 메커니즘은 인트라넷 액세스를 위한 지원 됩니다.
Kerberos 및 NTLM에 대 한 협상을 사용 하 여 Windows 통합 인증
사용자 이름/암호를 사용하여 인증 양식
AD DS의 사용자 계정에 매핑된 인증서를 사용 하 여 인증서 인증
엑스트라넷 액세스에 대 한 다음 인증 메커니즘이 지원 됩니다.
사용자 이름/암호를 사용하여 인증 양식
AD DS의 사용자 계정에 매핑되는 인증서를 사용 하 여 인증서 인증
Windows 통합 인증을 허용하는 WS-Trust 엔드포인트에 대해 협상(NTLM만 해당)을 사용하는 Windows 통합 인증
인증서 인증의 경우:
Pin 보호 될 수 있는 스마트 카드를 확장 합니다.
사용자가 핀을 입력하는 GUI는 AD FS에서 제공되지 않으며 클라이언트 TLS를 사용할 때 표시되는 클라이언트 운영 체제의 일부여야 합니다.
스마트 카드의 판독기 및 CSP(암호화 서비스 공급자)가 브라우저가 있는 컴퓨터에서 작동해야 합니다.
스마트 카드 인증서가 모든 AD FS 서버와 웹 애플리케이션 프록시 서버에 신뢰할 수 있는 루트에 연결 해야 합니다.
인증서가 다음 방법 중 하나를 통해 AD DS의 사용자 계정에 매핑되어야 합니다.
인증서 주체 이름이 AD DS의 사용자 계정에 대한 LDAP 고유 이름에 해당합니다.
인증서 주체 대체 확장에 AD DS의 사용자 계정에 대한 UPN(사용자 계정 이름)이 있습니다.
완벽 한 Windows 통합 인증에 대 한 Kerberos는 인트라넷에서 사용 하 여
서비스 이름이 신뢰할 수 있는 사이트 또는 로컬 인트라넷 사이트의 일부여야 합니다.
또한 AD FS 팜이 실행되는 서비스 계정에서 HOST/<adfs_service_name> SPN을 설정해야 합니다.
Multi-Factor Authentication
AD FS는 공급업체/고객이 로그인 중에 관리자가 등록하고 사용할 수 있는 자체 다단계 인증 어댑터를 빌드할 수 있는 공급자 모델을 사용하여 추가 인증(AD DS에서 지원하는 기본 인증 외)을 지원합니다.
모든 MFA 어댑터는.NET 4.5를 기반으로 구축 해야 합니다.
MFA에 대 한 자세한 내용은 참조 하십시오. 중요 한 애플리케이션에 대 한 Multi-factor Authentication 사용 하 여 위험 관리합니다.
디바이스 인증
AD FS 디바이스 연결 하는 최종 사용자 작업을 하는 작업 하는 동안 디바이스 등록 서비스에서 프로 비전 인증서를 사용 하 여 디바이스 인증을 지원 합니다.
작업 공간 조인 요구 사항
최종 사용자가 작업 공간 연결에 AD FS를 사용 하 여 조직에 자신의 디바이스를 수 있습니다. 이 AD FS에서 디바이스 등록 서비스에서 지원 됩니다. 결과적으로, 최종 사용자가 AD FS에서 지 원하는 애플리케이션에서 SSO의 추가 이점을 얻을 수 있습니다. 또한 관리자는 작업 공간 조직에 연결 된 디바이스에만 애플리케이션에 대 한 액세스를 제한 하 여 위험을 관리할 수 있습니다. 다음은이 시나리오를 사용 하도록 설정 하려면 다음 요구 사항입니다.
AD FS는 Windows 8.1 및 iOS 5+ 디바이스에 대한 작업 공간 조인을 지원합니다.
작업 공간 연결 기능을 사용 하려면 AD FS 서버에 가입 된 포리스트의 스키마를 Windows Server 2012 r 2 이어야 합니다.
AD FS 서비스에 대한 SSL 인증서의 주체 대체 이름에는 조직의 UPN(사용자 계정 이름) 접미사 뒤에 enterpriseregistration.corp.contoso.com 값 enterpriseregistration이 포함되어야 합니다.
암호화 요구 사항
다음 표에서는 AD FS 토큰 서명, 토큰 암호화/암호 해독 기능에 대한 추가 암호화 지원 정보를 제공합니다.
| 알고리즘 | 키 길이 | 프로토콜/애플리케이션/주석 |
|---|---|---|
| TripleDES – 기본값 192(지원되는 192 – 256) - http://www.w3.org/2001/04/xmlenc#tripledes-cbc | >= 192 | 보안 토큰의 암호를 해독하는 데 지원되는 알고리즘입니다. 이 알고리즘을 사용하여 보안 토큰을 암호화하는 것은 지원되지 않습니다. |
| AES128 - http://www.w3.org/2001/04/xmlenc#aes128-cbc | 128 | 보안 토큰의 암호를 해독하는 데 지원되는 알고리즘입니다. 이 알고리즘을 사용하여 보안 토큰을 암호화하는 것은 지원되지 않습니다. |
| AES192 - http://www.w3.org/2001/04/xmlenc#aes192-cbc | 192 | 보안 토큰의 암호를 해독하는 데 지원되는 알고리즘입니다. 이 알고리즘을 사용하여 보안 토큰을 암호화하는 것은 지원되지 않습니다. |
| AES256 - http://www.w3.org/2001/04/xmlenc#aes256-cbc | 256 | Default입니다. 보안 토큰을 암호화 하는 데 지원 되는 알고리즘입니다. |
| TripleDESKeyWrap - http://www.w3.org/2001/04/xmlenc#kw-tripledes | .NET 4.0 이상에서 지원하는 모든 키 크기 | 보안 토큰을 암호화 하는 대칭 키를 암호화 하는 데 지원 되는 알고리즘입니다. |
| AES128KeyWrap - http://www.w3.org/2001/04/xmlenc#kw-aes128 | 128 | 보안 토큰을 암호화 하는 대칭 키를 암호화 하는 데 지원 되는 알고리즘입니다. |
| AES192KeyWrap - http://www.w3.org/2001/04/xmlenc#kw-aes192 | 192 | 보안 토큰을 암호화 하는 대칭 키를 암호화 하는 데 지원 되는 알고리즘입니다. |
| AES256KeyWrap - http://www.w3.org/2001/04/xmlenc#kw-aes256 | 256 | 보안 토큰을 암호화 하는 대칭 키를 암호화 하는 데 지원 되는 알고리즘입니다. |
| RsaV15KeyWrap - http://www.w3.org/2001/04/xmlenc#rsa-1_5 | 1024 | 보안 토큰을 암호화 하는 대칭 키를 암호화 하는 데 지원 되는 알고리즘입니다. |
| RsaOaepKeyWrap - http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p | 1024 | 기본값. 보안 토큰을 암호화 하는 대칭 키를 암호화 하는 데 지원 되는 알고리즘입니다. |
| SHA1-http://www.w3.org/PICS/DSig/SHA1_1_0.html | 해당 없음 | 아티팩트 SourceId 생성에서 AD FS 서버에서 사용: 이 시나리오에서 STS는 SHA1(SAML 2.0 표준의 권장 사항에 따라)을 사용하여 아티팩트 sourceiD에 대한 짧은 160비트 값을 만듭니다. 또한 AD FS 웹 에이전트(WS2003 기간의 레거시 구성 요소)에서 STS에서 정보를 업데이트할 시기를 알 수 있도록 "마지막으로 업데이트된" 시간 값의 변경 내용을 식별하는 데 사용됩니다. |
| SHA1withRSA- | 해당 없음 | AD FS Server가 SAML AuthenticationRequest 서명의 유효성을 검사하고 아티팩트 확인 요청 또는 응답에 서명하고 토큰 서명 인증서를 만드는 경우에 사용됩니다. 이러한 경우 SHA256은 기본값이며, SHA1은 파트너(신뢰 당사자)가 SHA256을 지원할 수 없고 SHA1을 사용해야 하는 경우에만 사용됩니다. |
권한 요구 사항
AD FS의 설치 및 초기 구성을 수행하는 관리자는 로컬 do기본(즉기본 페더레이션 서버가 조인되는 기본 관리자 권한이 있어야 합니다.)