Windows Server용 AD FS 요구 사항
다음은 AD FS를 배포 하는 경우를 준수 해야 하는 다양 한 요구 사항:
인증서 요구 사항
인증서는 가장 중요 한 역할 간의 보안 통신에 페더레이션 서버, 웹 애플리케이션 프록시, 클레임인식 애플리케이션과 웹 클라이언트입니다. 인증서에 대한 요구 사항은 이 섹션에 설명된 대로 설정하는 컴퓨터가 페더레이션 서버인지 또는 프록시인지에 따라 다릅니다.
페더레이션 서버 인증서
| 인증서 유형 | 요구 사항, 지원 & 알아 둘 사항 |
|---|---|
| Secure Sockets Layer SSL 인증서: 페더레이션 서버와 클라이언트 간의 보안 통신에 사용 되는 표준 SSL 인증서입니다. | - 이 인증서는 공개적으로 신뢰할* 수 있는 X509 v3 인증서여야 합니다. -모든 AD FS 엔드포인트에 액세스 하는 모든 클라이언트는이 인증서를 신뢰 해야 합니다. 공용(타사) CA(인증 기관)에서 발급한 인증서를 사용하는 것이 좋습니다. 테스트 랩 환경의 페더레이션 서버에서 자체 서명 SSL 인증서를 성공적으로 사용할 수 있습니다. 그러나 프로덕션 환경에서는 공용 CA에서 인증서를 얻는 것이 좋습니다. -SSL 인증서에 대 한 Windows Server 2012 r 2에서 지 원하는 모든 키 크기를 지원 합니다. - CNG 키를 사용하는 인증서는 지원하지 않습니다. - 작업 공간 연결/디바이스 등록 서비스와 함께 사용하는 경우에는 AD FS 서비스용 SSL 인증서의 주체 대체 이름에 조직(예: enterpriseregistration.contoso.com)의 사용자 주체 이름(UPN) 접미사가 뒤에 오는 값 enterpriseregistration이 포함되어야 합니다. -와일드 카드 인증서 지원 됩니다. 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(보안 해시 알고리즘)을 SHA-1 또는 SHA-256(더 안전)으로 변경할 수 있습니다. AD FS는 MD5(Makecert.exe 명령줄 도구에서 사용되는 기본 해시 알고리즘)와 같은 다른 해시 메서드와 함께 인증서를 사용하는 것을 지원하지 않습니다. 최상의 보안 방법으로, 모든 서명에 SHA-256(기본적으로 설정됨)을 사용하는 것이 좋습니다. SHA-1은 SHA-256을 사용한 통신을 지원하지 않는 제품(예: 타사 제품 또는 레거시 버전의 AD FS)과 상호 운용해야 하는 경우에만 사용하는 것이 좋습니다.
참고 항목
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를 사용하기 위해서는 읽기 전용 도메인 컨트롤러가 아닌 전체 쓰기 가능한 도메인 컨트롤러가 작동해야 합니다. 계획된 토폴로지에서 읽기 전용 도메인 컨트롤러를 포함하는 경우 읽기 전용 도메인 컨트롤러를 인증에 사용할 수 있지만, LDAP 클레임 처리에는 쓰기 가능한 도메인 컨트롤러에 대한 연결이 필요합니다.
도메인 기능 수준 요구 사항
모든 사용자 계정 도메인 및 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 이상을 실행하는 도메인 컨트롤러를 하나 이상을 배포해야 합니다(둘 이상을 배포하는 것이 좋습니다).
도메인 가입 클라이언트와 AD FS 사이에서 Kerberos가 작동하려면 '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
WID 팜은 신뢰 당사자 트러스트가 100개 이하인 경우 페더레이션 서버 수가 30개로 제한됩니다.
SAML 2.0에 있는 아티팩트 확인 프로필은 WID 구성 데이터베이스에서 지원되지 않습니다. 토큰 재생 검색은 WID 구성 데이터베이스에서 지원되지 않습니다. 이 기능은 AD FS는 페더레이션 공급자 역할을 하 고 외부 클레임 공급자의 보안 토큰을 사용 하는 경우에만 사용 됩니다.
장애 조치(failover) 또는 지리적 부하 분산을 위해 AD FS 서버를 고유한 데이터 센터에 배포하는 것은 서버 수가 30개를 초과하지 않는 경우에 지원됩니다.
다음 표에서 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 서비스 이름(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 트러스트 엔드포인트용 협상(NTLM 전용)을 사용하는 Windows 통합 인증
인증서 인증의 경우:
Pin 보호 될 수 있는 스마트 카드를 확장 합니다.
사용자가 PIN을 입력할 수 있는 GUI는 AD FS에서 제공되지 않으며, 클라이언트 TLS를 사용할 때 표시되는 클라이언트 운영 체제의 일부여야 합니다.
스마트 카드의 판독기 및 CSP(암호화 서비스 공급자)가 브라우저가 있는 컴퓨터에서 작동해야 합니다.
스마트 카드 인증서가 모든 AD FS 서버와 웹 애플리케이션 프록시 서버에 신뢰할 수 있는 루트에 연결 해야 합니다.
인증서가 다음 방법 중 하나를 통해 AD DS의 사용자 계정에 매핑되어야 합니다.
인증서 주체 이름이 AD DS의 사용자 계정에 대한 LDAP 고유 이름에 해당합니다.
인증서 주체 대체 확장에 AD DS의 사용자 계정에 대한 UPN(사용자 계정 이름)이 있습니다.
완벽 한 Windows 통합 인증에 대 한 Kerberos는 인트라넷에서 사용 하 여
서비스 이름은 신뢰할 수 있는 사이트나 로컬 인트라넷 사이트의 일부여야 합니다.
그리고 HOST/<adfs_service_name> SPN이 AD FS 팜이 실행되는 서비스 계정에 설정되어야 합니다.
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가 포함되어야 합니다(예: enterpriseregistration.corp.contoso.com).
암호화 요구 사항
다음 표에는 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 서버에서 SAML AuthenticationRequest 서명의 유효성을 검사하고, 아티팩트 확인 요청이나 응답에 서명하고, 토큰 서명 인증서를 만드는 경우에 사용됩니다. 이 경우 SHA256이 기본값이며, SHA1은 파트너(신뢰 당사자)가 SHA256을 지원할 수 없어 SHA1을 사용해야 하는 경우에만 사용됩니다. |
권한 요구 사항
AD FS를 설치하고 처음 구성하는 관리자는 로컬 도메인(즉, 페더레이션 서버가 가입되어 있는 도메인)에서 도메인 관리자 권한이 있어야 합니다.