RADIUS 서버로 작동하는 NPS 계획
NPS(네트워크 정책 서버)를 RADIUS(원격 인증 서비스) 서버로 배포하는 경우 NPS는 로컬 도메인 및 로컬 도메인을 신뢰하는 도메인에 대한 연결 요청 인증, 권한 부여 및 회계 관리를 수행합니다. 이러한 계획 지침을 사용하여 RADIUS 배포를 간소화할 수 있습니다.
이러한 계획 지침은 NPS를 RADIUS 프록시로 배포하려는 상황에는 적용되지 않습니다. NPS를 RADIUS 프록시로 배포하는 경우 NPS는 원격 도메인, 신뢰할 수 없는 도메인 또는 둘 다에서 NPS 또는 다른 RADIUS 서버를 실행하는 서버에 연결 요청을 전달합니다.
NPS를 네트워크에 RADIUS 서버로 배포하기 전 다음 지침을 참조하여 배포를 계획하세요.
NPS 구성 계획.
RADIUS 클라이언트 계획
인증 방식의 적용을 계획하세요.
네트워크 정책을 계획하세요.
NPS 회계 계획.
NPS 구성 계획
어떤 도메인이 NPS를 구성원으로 가지게 될지 결정해야 합니다. 다중 도메인 환경의 경우 NPS는 구성원인 도메인의 사용자 계정 및 NPS의 로컬 도메인을 신뢰하는 모든 도메인에 대한 자격 증명을 인증할 수 있습니다. NPS가 권한 부여 프로세스 중에 사용자 계정의 접속 속성을 읽을 수 있도록 하려면 각 도메인에 대한 RAS 및 NPS 그룹에 NPS의 컴퓨터 계정을 추가해야 합니다.
NPS의 도메인 구성원 자격을 결정한 후에는 RADIUS 프로토콜을 사용하여 네트워크 액세스 서버라고도 불리는 RADIUS 클라이언트와 통신하도록 서버가 구성되어야 합니다. 또한 NPS가 이벤트 로그에 기록하는 이벤트 유형을 구성하고 서버 설명을 입력할 수 있습니다.
주요 단계
NPS 구성 계획 중 다음 절차를 활용할 수 있습니다.
NPS가 RADIUS 클라이언트에서 RADIUS 메시지를 수신하는 데 사용할 RADIUS 포트를 결정합니다. 기본 포트는 RADIUS 인증 메시지의 경우 UDP 포트 1812 및 1645이고 RADIUS 회계 메시지의 경우 포트 1813 및 1646입니다.
NPS가 여러 네트워크 어댑터로 구성된 경우 RADIUS 트래픽을 허용할 어댑터들을 선택합니다.
NPS가 이벤트 로그에 기록할 이벤트 유형을 결정합니다. 거부된 인증 요청, 성공적인 인증 요청 또는 두 가지 요청 유형 모두 기록이 가능합니다.
둘 이상의 NPS를 배포하는지 여부를 확인하세요. RADIUS 기반 인증 및 회계 내결함성을 제공하려면 두 개 이상의 NPS를 사용하세요. 하나의 NPS는 기본 RADIUS 서버로 사용되고 다른 하나는 백업으로 사용됩니다. 그러면 RADIUS 클라이언트가 각각의 NPS에서 하나씩 구성됩니다. 기본 NPS 사용이 불가하면 RADIUS 클라이언트는 대체 NPS에 액세스 요청 메시지를 보냅니다.
관리 오버헤드를 절약하고 서버 구성 오류를 방지하기 위해 하나의 NPS 구성을 다른 NPS에 복사하는 데 사용되는 스크립트를 계획합니다. NPS는 다른 NPS로 불러오기 위한 NPS 구성의 전부 또는 일부를 복사할 수 있는 Netsh 명령을 제공합니다. Netsh 프롬프트에서 명령을 수동으로 실행할 수 있습니다. 그러나 명령 순서를 스크립트로 저장하면, 서버 구성을 변경하고자 할 때 스크립트를 실행할 수 있습니다.
RADIUS 클라이언트 계획
RADIUS 클라이언트는 무선 액세스 지점, VPN(가상 사설망) 서버, 802.1X 지원 스위치 및 전화 접속 서버와 같은 네트워크 액세스 서버입니다. 연결 요청 메시지를 RADIUS 서버로 전달하는 RADIUS 프록시도 RADIUS 클라이언트입니다. NPS는 RFC 2865, "RADIUS(원격 인증 서비스)" 및 RFC 2866, "RADIUS 회계"에 설명된 대로 RADIUS 프로토콜을 준수하는 모든 네트워크 액세스 서버 및 RADIUS 프록시를 지원합니다.
Important
클라이언트 컴퓨터와 같은 액세스 클라이언트는 RADIUS 클라이언트가 아닙니다. RADIUS 프로토콜을 지원하는 네트워크 액세스 서버 및 프록시 서버만이 RADIUS 클라이언트입니다.
또한 무선 액세스 포인트와 스위치 모두 802.1X 인증을 수행할 수 있어야 합니다. EAP(확장할 수 있는 인증 프로토콜) 또는 PEAP(보호된 확장 가능 인증 프로토콜)를 배포하려는 경우 액세스 포인트 및 스위치는 EAP 사용을 지원해야 합니다.
무선 액세스 지점에 대한 PPP 연결에 대한 기본 상호 운용성을 테스트하려면 PAP(암호 인증 프로토콜)를 사용하도록 액세스 포인트 및 액세스 클라이언트를 구성합니다. 네트워크 액세스에 사용하려는 인증 프로토콜을 테스트할 때까지 PEAP와 같은 추가 PPP 기반 인증 프로토콜을 사용합니다.
주요 단계
RADIUS 클라이언트를 계획하는 중 다음 단계를 활용할 수 있습니다.
NPS에서 구성해야 하는 VSA(공급업체별 특성)를 문서화합니다. 네트워크 액세스 서버에 VSA가 필요한 경우 나중에 사용될 수 있도록 NPS의 네트워크 정책을 구성할 때 VSA 정보를 기록합니다.
RADIUS 클라이언트 및 NPS의 IP 주소를 문서화하여 모든 디바이스 구성을 간소화합니다. RADIUS 클라이언트를 배포할 때는 RADIUS 프로토콜이 인증 서버로 입력된 NPS IP 주소와 함께 사용되도록 구성해야 합니다. 또한 RADIUS 클라이언트와 통신하도록 NPS를 구성할 때는 NPS 스냅인에 RADIUS 클라이언트 IP 주소를 입력해야 합니다.
RADIUS 클라이언트 및 NPS 스냅인에서 구성에 대한 공유 비밀을 만듭니다. NPS에서 RADIUS 클라이언트를 구성하는 동안 NPS 스냅인에도 입력할 공유 비밀 또는 암호를 사용하여 RADIUS 클라이언트를 구성해야 합니다.
인증 방식의 적용을 계획하세요.
NPS는 암호 기반 및 인증서 기반 인증 방법 모두 지원합니다. 그러나 모든 네트워크 액세스 서버가 동일한 인증 방법을 지원하는 것은 아닙니다. 경우에 따라 네트워크 액세스 유형에 기반하여 다른 인증 방식의 배포를 원할 수 있습니다.
예를 들어 귀하의 조직에 무선 및 VPN 액세스 모두를 배포하기 원할 시, VPN 연결의 경우 강력한 보안을 제공하기에 EAP-TLS(전송 계층 보안) 방식, 802.1X 무선 연결의 경우 PEAP-MS-CHAP v2 방식 등 각 액세스 유형에 따라 다른 인증 방식을 사용할 수 있습니다.
Microsoft Challenge 핸드셰이크 인증 프로토콜 버전 2(PEAP-MS-CHAP v2)를 사용하는 PEAP는 휴대용 컴퓨터 및 기타 무선 장치에서 사용되도록 특별히 설계된 빠른 다시 연결이라는 기능을 제공합니다. 빠른 다시 연결을 사용하면 동일한 네트워크의 무선 액세스 포인트 간 이동 시 신규 액세스 포인트와 연결할 때마다 무선 클라이언트의 재인증 없이 이동이 가능합니다. 이렇게 하면 무선 사용자에게 더 나은 경험을 제공하고 자격 증명을 다시 입력하지 않고도 액세스 포인트 간에 이동이 가능합니다. 빠른 다시 연결과 보안을 제공하는 PEAP-MS-CHAP v2는, 합리적인 무선 연결 인증 방식 선택지 입니다.
VPN 연결의 경우, EAP-TLS는 집 또는 모바일 컴퓨터에서 조직 VPN 서버로 인터넷을 통해 전송되는 경우에도 네트워크 트래픽을 보호하는 강력한 보안을 제공하는 인증서 기반 인증 방식입니다.
인증서 기반 인증 방식
인증서 기반 인증 방식은 강력한 보안을 제공하는 이점이 있습니다만 암호 기반 인증 방식보다 배포하기가 더 어렵다는 단점이 있습니다.
PEAP-MS-CHAP v2와 EAP-TLS는 모두 인증서 기반 인증 방식이지만 둘 사이에는 배포되는 방법 외 많은 차이점이 있습니다.
EAP-TLS
EAP-TLS는 클라이언트 및 서버 인증 모두에 인증서를 사용하며 조직의 PKI(공개 키 인프라) 배포를 필요로 합니다. PKI 배포는 복잡할 수 있으며, NPS를 RADIUS 서버로 사용하기 위한 계획과 독립적인 계획 단계가 필요합니다.
EAP-TLS 사용 시 NPS는 CA(인증 기관)에서 서버 인증서를 등록하고 인증서는 인증서 저장소의 로컬 컴퓨터에 저장됩니다. 인증 프로세스 중, NPS가 액세스 클라이언트에 서버 인증서를 보내 액세스 클라이언트에 ID를 증명할 때 서버 인증이 진행됩니다. 액세스 클라이언트는 다양한 인증서 속성을 검사하여 인증서 유효성 및 서버 인증 중 사용 적합성 여부를 확인합니다. 서버 인증서가 최소 서버 인증서 요구 사항을 충족하고 액세스 클라이언트가 신뢰하는 CA에서 발급된 경우 NPS는 클라이언트에 의해 성공적으로 인증됩니다.
유사하게, 클라이언트 인증은 클라이언트가 NPS에 해당 ID를 증명하기 위해 NPS에 클라이언트 인증서를 보내는 인증 프로세스 중에 진행됩니다. NPS는 인증서를 검사하고 클라이언트 인증서가 최소 클라이언트 인증서 요구 사항을 충족 및 NPS가 신뢰하는 CA에서 발급된 경우에 액세스 클라이언트는 NPS에 의해 성공적으로 인증됩니다.
서버 인증서는 NPS 인증서 저장소에 저장되어야 하지만 클라이언트 또는 사용자 인증서는 클라이언트 또는 스마트 카드의 인증서 저장소에 저장 가능합니다.
이 인증 프로세스가 성공하려면 모든 컴퓨터에 로컬 컴퓨터 및 현재 사용자의 신뢰할 수 있는 루트 인증 기관 인증서 저장소에 귀하 조직의 CA 인증서의 존재가 필수적 입니다.
PEAP-MS-CHAP v2
PEAP-MS-CHAP v2는 서버 인증에 인증서를 사용하고 사용자 인증에 암호 기반 자격 증명을 사용합니다. 인증서는 서버 인증에만 사용되므로 PEAP-MS-CHAP v2를 사용하기 위한 PKI 배포가 불필요 합니다. PEAP-MS-CHAP v2를 배포하는 경우 다음 두 가지 방법 중 하나의 방법으로 NPS 서버 인증서를 얻을 수 있습니다.
AD CS(Active Directory 인증서 서비스)를 설치한 다음 NPS에 인증서를 자동 등록할 수 있습니다. 이 방식을 사용하는 경우 네트워크에 연결하려는 클라이언트 컴퓨터들에 CA 인증서를 등록하여 NPS에서 발급된 인증서를 신뢰하도록 해야 합니다.
VeriSign과 같은 공용 CA에서 서버 인증서 구입이 가능합니다. 이 방식을 사용할 경우, CA가 클라이언트 컴퓨터가 이미 신뢰할 수 있는 CA로 선택되어야 합니다. 클라이언트 컴퓨터가 CA를 신뢰할 수 있는지 확인하려면 클라이언트 컴퓨터에서 인증서 MMC(Microsoft 관리 콘솔) 스냅인을 연 다음 로컬 컴퓨터 및 현재 사용자에 대한 신뢰할 수 있는 루트 인증 기관 저장소를 확인합니다. 이러한 인증서 저장소에 CA의 인증서가 있는 경우 클라이언트 컴퓨터는 CA를 신뢰하므로 CA에서 발급한 어떤 인증서라도 신뢰합니다.
PEAP-MS-CHAP v2를 사용한 인증 프로세스 중, NPS가 서버 인증서를 클라이언트 컴퓨터로 보낼 때 서버 인증이 진행됩니다. 액세스 클라이언트는 다양한 인증서 속성을 검사하여 인증서 유효성 및 서버 인증 중 사용 적합성 여부를 확인합니다. 서버 인증서가 최소 서버 인증서 요구 사항을 충족하고 액세스 클라이언트가 신뢰하는 CA에서 발급된 경우 NPS는 클라이언트에 의해 성공적으로 인증됩니다.
사용자 인증은 네트워크에 연결하려는 사용자가 암호 기반 자격 증명을 입력하고 로그온을 시도할 때 진행됩니다. NPS는 자격 증명 수신 후 인증 및 권한 부여를 수행합니다. 사용자가 인증되고 권한이 성공적으로 부여되고 클라이언트 컴퓨터가 NPS를 성공적으로 인증한 경우 연결 요청이 허용됩니다.
주요 단계
인증 방식 적용 계획 중 다음 절차를 활용할 수 있습니다.
무선, VPN, 802.1X 지원 스위치 및 전화 접속 액세스와 같이 제공하려는 네트워크 액세스 유형을 식별하세요.
각 액세스 유형에 사용할 인증 방식 혹은 방식들을 결정하세요. 강력한 보안을 제공하는 인증서 기반 인증 방식 사용이 권장됩니다만, PKI를 배포하는 것은 실용적이지 않을 수 있으므로 다른 인증 방식들이 네트워크에 필요한 항목들을 더 균형적으로 제공할 수 있습니다.
EAP-TLS를 배포하는 경우 PKI 배포를 계획하세요. 여기에는 서버 인증서 및 클라이언트 컴퓨터 인증서에 사용할 인증서 템플릿 계획이 포함됩니다. 또한 도메인 구성원 및 비 도메인 구성원 컴퓨터에 인증서를 등록하는 방법 및 스마트 카드를 사용할지 여부를 결정하는 것도 포함됩니다.
PEAP-MS-CHAP v2를 배포하는 경우 AD CS를 설치하여 NPS에 서버 인증서를 발급할지 또는 VeriSign과 같은 공용 CA에서 서버 인증서를 구매할지 여부를 결정하세요.
네트워크 정책을 계획하세요.
네트워크 정책은 NPS가 RADIUS 클라이언트에서 받은 연결 요청의 허용 여부를 확인하는 데 사용됩니다. 또한 NPS는 사용자 계정의 전화 접속 속성을 사용하여 권한 부여를 결정합니다.
네트워크 정책은 NPS 스냅인에 표시되는 순서대로 처리되므로 가장 제한적인 정책을 정책 목록의 맨 위에 먼저 배치하세요. 각 연결 요청에 대해 NPS는 정책의 조건을 연결 요청 속성과 일치시키려고 시도합니다. NPS는 일치하는 항목을 찾을 때까지 각 네트워크 정책을 순차적으로 검사합니다. 일치하는 항목을 찾지 못하면 연결 요청은 거부됩니다.
주요 단계
네트워크 정책 계획 중 다음 절차를 활용할 수 있습니다.
네트워크 정책의 기본 NPS 처리 순서를 가장 제한적인 것에서 가장 제한적이지 않은 순서로 선정하세요.
정책 상태를 확인하세요. 정책 상태는 활성화 또는 비활성화 값을 가질 수 있습니다. 정책이 활성화 상태인 경우 NPS는 권한 부여를 수행하는 동안 정책을 평가합니다. 정책이 비활성화 상태면 평가되지 않습니다.
정책 유형을 확인하세요. 정책 조건이 연결 요청과 일치할 때 정책이 액세스 권한을 부여하도록 설계되었는지 또는 정책 조건이 연결 요청과 일치할 때 액세스를 거부하도록 설계되었는지 여부를 반드시 확인하세요. 예를 들어 Windows 그룹의 구성원에 대한 무선 액세스를 분명하게 거부하려는 경우 그 그룹을 특정, 무선 연결 방식을 지정하고 정책 유형 설정이 액세스 거부인 네트워크 정책을 만들 수 있습니다.
정책이 기반한 되는 그룹의 구성원인 사용자 계정의 전화 접속 속성을 NPS가 무시할지 여부를 결정하세요. 이 설정이 활성화 되어있지 않으면 사용자 계정의 전화 접속 속성이 네트워크 정책에 구성된 설정을 무시합니다. 예를 들어 사용자에게 액세스 권한을 부여하는 네트워크 정책이 구성되어 있지만 해당 사용자 계정의 전화 접속 속성이 액세스를 거부하도록 설정된 경우 사용자는 액세스가 거부됩니다. 그러나 사용자 계정 전화 접속 속성 무시 정책 유형을 활성화 하면 동일한 사용자에게 네트워크에 대한 액세스 권한이 부여됩니다.
정책의 정책 원본 설정 사용 여부를 확인하세요. 이 설정을 사용하면 모든 액세스 요청의 원본을 쉽게 특정할 수 있습니다. 가능한 원본은 터미널 서비스 게이트웨이(TS 게이트웨이), 원격 액세스 서버(VPN 또는 전화 접속), DHCP 서버, 무선 액세스 포인트 및 상태 등록 기관 서버입니다. 또는 공급업체별 원본을 지정할 수도 있습니다.
네트워크 정책을 적용하기 위해 일치해야 하는 조건을 결정하세요.
네트워크 정책의 조건이 연결 요청과 일치하는 경우 적용될 설정을 결정하세요.
기본 네트워크 정책을 사용, 수정 또는 삭제할지 여부를 결정하세요.
NPS 회계 계획
NPS는 사용자 인증 및 회계 요청과 같은 RADIUS 회계 데이터를 IAS 형식, 데이터베이스 호환 형식 및 Microsoft SQL Server 로깅의 세 가지 형식으로 기록하는 기능을 제공합니다.
IAS 형식 및 데이터베이스 호환 형식은 로컬 NPS에 로그 파일을 텍스트 파일 형식으로 생성합니다.
SQL Server 로깅은 관계형 데이터베이스 로깅의 장점을 활용하도록 RADIUS 회계를 확장하여 SQL Server 2000 또는 SQL Server 2005 XML 규격 데이터베이스에 로그하는 기능을 제공합니다.
주요 단계
NPS 회계 계획 중 다음 절차를 활용할 수 있습니다.
- NPS 회계 데이터를 로그 파일 또는 SQL Server 데이터베이스에 저장할지 여부를 결정합니다.
로컬 로그 파일을 사용하는 NPS 회계
로그 파일에 사용자 인증 및 회계 요청을 기록하는 것은 주로 연결 분석 및 요금 청구 목적으로 사용되며, 공격 후 악의적인 사용자의 활동을 추적하는 방법을 제공하는 보안 조사 도구로도 유용합니다.
주요 단계
로컬 로그 파일을 사용하는 NPS 회계 계획 중 다음 절차를 활용할 수 있습니다.
NPS 로그 파일에 사용할 텍스트 파일 형식을 결정하세요.
로그에 기록할 정보 유형을 선택하세요. 회계 요청, 인증 요청 및 정기적인 상태 로그를 기록할 수 있습니다.
로그 파일을 저장할 하드 디스크 위치를 결정하세요.
로그 파일 백업 솔루션을 디자인하세요. 로그 파일을 저장하는 하드 디스크 위치는 데이터를 쉽게 백업할 수 있는 위치여야 합니다. 또한 로그 파일이 저장되는 폴더에 대한 ACL(액세스 제어 목록)을 구성하여 해당 하드 디스크 위치를 보호해야 합니다.
새 로그 파일 생성 빈도를 결정하세요. 파일 크기 기반으로 로그 파일을 만들려면 NPS에서 새 로그 파일을 만들기 전에 허용되는 최대 파일 크기를 결정합니다.
하드 디스크에 스토리지 공간이 부족할 경우 NPS에서 이전 로그 파일을 삭제할지 여부를 결정하세요.
회계 데이터를 보거나 보고서를 생성하는 데 사용할 애플리케이션을 결정하세요.
NPS SQL Server 로깅
NPS SQL Server 로깅은 보고서 만들기 및 데이터 분석을 위해 세션 상태 정보가 필요하고 회계 데이터 관리를 중앙 집중화하고 간소화하는 데 사용됩니다.
NPS는 SQL Server 로깅을 사용하여 하나 이상의 네트워크 액세스 서버에서 받은 사용자 인증 및 회계 요청을 MICROSOFT SQL Server 데스크톱 엔진(MSDE 2000) 또는 SQL Server 2000 이후의 SQL Server 버전을 실행하는 컴퓨터의 데이터 원본으로 기록할 수 있는 기능을 제공합니다.
회계 데이터는 XML 형식의 NPS에서 데이터베이스의 저장 프로시저로 전달되며, 이 프로시저는 SQL(구조적 쿼리 언어)과 XML(SQLXML)을 모두 지원합니다. XML 규격 SQL Server 데이터베이스에서 사용자 인증 및 회계 요청을 기록하면 여러 NPS가 하나의 데이터 원본을 가질 수 있습니다.
주요 단계
NPS SQL Server 로깅을 사용한 NPS 회계 계획 중 다음 절차를 활용할 수 있습니다.
사용자 또는 조직의 다른 구성원이 SQL Server 2000 또는 SQL Server 2005 관계형 데이터베이스 개발 환경을 가지고 있는지 여부를 확인하고 이러한 제품을 사용하여 SQL Server 데이터베이스를 만들고, 수정하고, 관리하고, 관리하는 방법을 이해합니다.
SQL Server가 NPS에 설치되어 있는지 아니면 원격 컴퓨터에 설치되어 있는지 확인하세요.
SQL Server 데이터베이스에서 NPS 회계 데이터가 포함된 수신되는 XML 파일을 처리하는 데 사용할 저장 프로시저를 디자인하세요.
SQL Server 데이터베이스 복제 구조와 흐름을 디자인합니다.
회계 데이터를 보거나 보고서를 생성하는 데 사용할 애플리케이션을 결정하세요.
모든 회계 요청에 클래스 특성을 전송하는 네트워크 액세스 서버 사용을 계획하세요. 클래스 특성은 Access-Accept 메시지에서 RADIUS 클라이언트로 전송되며 회계 요청 메시지와 인증 세션의 상관 관계 지정에 유용합니다. 회계 요청 메시지에서 네트워크 액세스 서버에서 클래스 특성을 보내는 경우 회계 및 인증 레코드와 일치하도록 사용할 수 있습니다. Unique-Serial-Number, Service-Reboot-Time 및 Server-Address 특성 조합은 서버에서 허용하는 각 인증에 대한 고유 ID여야 합니다.
중간 회계 관리를 지원하는 네트워크 액세스 서버 사용을 계획하세요.
Accounting-on 및 Accounting-off 메시지를 보내는 네트워크 액세스 서버 사용을 계획하세요.
회계 데이터의 저장 및 전달을 지원하는 네트워크 액세스 서버 사용을 계획하세요. 이 기능을 지원하는 네트워크 액세스 서버는 네트워크 액세스 서버가 NPS와 통신할 수 없는 경우 계정 관리 데이터를 저장할 수 있습니다. NPS를 사용할 수 있는 경우 네트워크 액세스 서버는 저장된 레코드를 NPS에 전달하여 이 기능을 제공하지 않는 네트워크 액세스 서버에 대한 회계 안정성을 향상시킵니다.
네트워크 정책에서 항상 회계-중간-간격 특성을 구성하도록 계획하세요. 회계-중간-간격 특성은 네트워크 액세스 서버가 보내는 각 업데이트 사이의 간격(초)을 설정합니다. RFC 2869에 따르면 회계-중간-간격 특성 값은 절대 60초(1분)보다 작아서는 안 되며 600초(10분)보다 작아서는 안 됩니다. 즉, 600초 이상의 값은 RADIUS 서버에서 수신되는 업데이트 빈도를 줄입니다. 자세한 내용은 RFC 2869을 참조하세요.
NPS에서 주기적 상태 로깅 사용이 활성화 되어 있는지 확인합니다.