이 글의 목적은 Windows 유선 802.1X 인증이 실패할 때 NPS(Network Policy Server) 로그(Event ID 6273)와 클라이언트 Wired AutoConfig 로그를 기준으로 원인을 신속하게 분류하고, 정책·인증방식·인증서·계정·스위치 설정을 체계적으로 복구할 수 있도록 실무 절차를 제공하는 것이다.
1. 802.1X 유선 인증 구조를 먼저 확정해야 하는 이유이다
유선 802.1X 장애는 “PC 문제”, “스위치 문제”, “NPS 문제”처럼 보이지만 실제로는 세 구성요소의 상호작용 실패로 발생하는 경우가 대부분이다.
클라이언트는 Supplicant로서 EAPOL 프레임을 송수신하고, 스위치는 Authenticator로서 포트를 제어하며, NPS는 RADIUS 서버로서 AD 계정과 정책에 따라 허용 또는 거부를 결정하는 구조이다.
따라서 증상만 보고 추정으로 수정하면 장애 범위가 확대되기 쉬우며, 반드시 로그 기반으로 “어디에서 거부가 발생했는지”를 먼저 확정해야 한다.
주의 : 802.1X 정책 변경은 사내 모든 유선 포트 인증에 영향을 줄 수 있으므로, 운영 시간대에는 테스트 포트 또는 제한된 VLAN에서 먼저 검증하는 것이 안전하다.
2. 증상별로 “인증 실패 위치”를 5분 안에 판별하는 방법이다
2.1 스위치에서 포트가 Authorized 상태로 전환되지 않는 경우이다
스위치 포트가 Unauthorized 상태에 머무르면 클라이언트가 네트워크 접근 자체를 못 하거나, 게스트 VLAN 또는 제한 VLAN로만 떨어지는 현상이 발생한다.
이 경우 스위치가 EAPOL을 수신하는지, 스위치가 NPS로 RADIUS 요청을 보내는지, NPS가 거부했는지를 순서대로 확인해야 한다.
2.2 NPS에 Event ID 6273(Audit Failure)가 찍히는 경우이다
NPS 보안 로그에 Event ID 6273이 기록되면 “요청이 NPS까지 도달했고 NPS가 거부했다”는 의미이므로 정책·인증방식·계정·인증서 영역을 집중 점검해야 한다.
반대로 6273이 아예 없다면 스위치와 NPS 간 네트워크/공유 비밀/포트/방화벽 문제 가능성이 높다.
2.3 NPS에 Event ID 6272(Audit Success)가 찍히는데도 접속이 안 되는 경우이다
NPS가 6272로 허용했는데도 통신이 안 되면, 스위치의 VLAN 할당·동적 VLAN·ACL·포트 보안 또는 DHCP/라우팅 문제로 범위를 전환해야 한다.
3. NPS에서 반드시 확인해야 하는 핵심 필드 정리이다
NPS 이벤트 상세에는 원인 추적에 필요한 단서가 포함되어 있으며, 아래 항목을 복사해두면 재현 없이도 원인 분류가 가능하다.
| 확인 항목이다 | 어디에서 확인하는지이다 | 의미와 활용 방법이다 |
|---|---|---|
| Event ID 6273 또는 6272이다 | Event Viewer의 Security 로그이다 | 6273이면 NPS가 거부한 상태이며 6272이면 NPS가 허용한 상태이다 |
| Reason Code와 Reason 텍스트이다 | 이벤트 메시지 하단이다 | 원인 분류의 기준이며 코드 값보다 함께 표시되는 텍스트를 우선 신뢰해야 한다 |
| Network Policy Name이다 | 이벤트 본문 중간이다 | 어떤 네트워크 정책이 매칭되었는지 보여주며 정책 우선순위 오류를 찾는 핵심 단서이다 |
| Authentication Type과 EAP Type이다 | 이벤트 본문 중간이다 | PEAP, EAP-TLS 등 실제 협상된 인증방식을 확인하여 클라이언트 설정과 불일치를 찾는 근거이다 |
| Client Friendly Name과 NAS IP Address이다 | 이벤트 본문 중간이다 | 요청을 보낸 장비가 어떤 스위치인지 식별하여 특정 구간 장애를 분리하는 근거이다 |
| User Name 또는 Computer Name이다 | 이벤트 본문 중간이다 | 사용자 인증인지 컴퓨터 인증인지 구분하여 AD 그룹과 정책 조건을 올바르게 설계하는 근거이다 |
주의 : 로그가 성공과 실패로 모두 남지 않으면 원인 분류가 불가능해지므로, NPS 감사 정책이 꺼져 있는지 반드시 점검해야 한다.
4. NPS 감사 로그가 안 찍힐 때 즉시 복구하는 절차이다
NPS 이벤트는 기본적으로 활성화되어 있지만, 환경에 따라 성공 또는 실패 감사가 비활성화되어 로그가 누락되는 경우가 있다.
아래 명령으로 “Network Policy Server” 하위 범주의 감사 상태를 확인하고, 필요 시 즉시 활성화해야 한다.
auditpol /get /subcategory:"Network Policy Server" auditpol /set /subcategory:"Network Policy Server" /success:enable /failure:enable5. Event ID 6273 Reason Code 기준으로 원인을 빠르게 분류하는 방법이다
Event ID 6273의 Reason Code는 환경마다 다양한 값을 가질 수 있으며, 우선은 이벤트에 함께 출력되는 Reason 텍스트를 기준으로 분류하는 것이 정확하다.
아래 표는 유선 802.1X에서 자주 만나는 패턴을 “대표 원인”으로 정리한 것이며, 실제 조치는 반드시 해당 이벤트의 필드 값과 정책 설정을 대조하여 결정해야 한다.
| Reason Code 예시이다 | 현장에서 흔한 의미이다 | 우선 점검 포인트이다 | 즉시 조치 방향이다 |
|---|---|---|---|
| 16이 자주 나타나는 경우이다 | 자격 증명 불일치로 거부되는 경우가 많다 | 계정 잠금·비활성·암호 오류·인증 주체가 사용자/컴퓨터로 뒤바뀐 상태를 점검해야 한다 | 클라이언트 인증 방식과 정책의 대상 그룹을 일치시키고, 테스트 계정으로 재현하여 범위를 축소해야 한다 |
| 22가 나타나는 경우이다 | 서버가 처리하지 못하는 EAP 유형으로 요청된 경우가 많다 | NPS 정책의 “Authentication Methods”에 클라이언트가 사용하는 EAP 방식이 허용되어 있는지 점검해야 한다 | PEAP 또는 EAP-TLS 중 실제 사용할 방식을 확정하고, 나머지는 비활성화하여 혼선을 제거해야 한다 |
| 23이 나타나는 경우이다 | EAP 협상 과정에서 오류가 발생한 경우가 많다 | NPS 서버 인증서 유효성·체인 신뢰·만료·CRL 접근성·TLS 설정을 우선 점검해야 한다 | NPS에 올바른 서버 인증서가 선택되어 있는지 확인하고, 클라이언트가 해당 발급기관을 신뢰하도록 배포해야 한다 |
6. 유선 802.1X에서 가장 많이 틀리는 설계 포인트 7가지이다
6.1 사용자 인증과 컴퓨터 인증을 혼합하면서 정책 조건을 분리하지 않는 문제이다
Windows 유선 802.1X는 부팅 직후 “컴퓨터 인증”이 먼저 발생하고, 로그인 이후 “사용자 인증”으로 전환되거나 병행되는 구성이 가능하다.
정책이 사용자 그룹만 허용하도록 되어 있으면 부팅 단계 인증이 실패하여 도메인 로그온 자체가 불안정해지는 문제가 발생하기 쉽다.
이 경우 “컴퓨터 인증 정책”과 “사용자 인증 정책”을 분리하고, 조건과 우선순위를 명확히 두는 것이 안전하다.
6.2 네트워크 정책 우선순위 때문에 의도와 다른 정책이 먼저 매칭되는 문제이다
NPS는 위에서 아래로 정책을 평가하므로, 범용 정책이 상단에 있으면 특정 부서 정책이 적용되지 않는 현상이 발생한다.
이벤트의 Network Policy Name이 의도한 정책인지 먼저 확인하고, 아니라면 조건을 더 구체화하거나 정책 순서를 조정해야 한다.
6.3 NAS Port Type, Called-Station-ID, NAS Identifier 조건이 환경과 맞지 않는 문제이다
유선 환경인데 무선 전용 조건이 들어가 있거나, 스위치가 전달하는 식별 문자열 형식이 예상과 달라 매칭이 실패하는 경우가 있다.
스위치가 실제로 어떤 속성 값을 보내는지는 NPS 이벤트의 속성 목록으로 확인하고 그 값에 맞추어 조건을 재설계해야 한다.
6.4 PEAP 사용 시 서버 인증서 검증을 무시하거나, 인증서가 교체되었는데 클라이언트 신뢰가 갱신되지 않은 문제이다
PEAP도 TLS 터널을 사용하므로 NPS 서버 인증서가 만료되거나 체인이 바뀌면 유선 인증이 대규모로 실패할 수 있다.
서버 인증서는 Server Authentication 용도의 EKU를 가져야 하며, 개인키가 존재하고, 클라이언트가 신뢰하는 발급기관 체인을 형성해야 한다.
6.5 EAP-TLS 사용 시 클라이언트 인증서가 없거나, 목적에 맞지 않는 인증서를 가진 문제이다
EAP-TLS는 클라이언트 인증서가 필수이므로, 사용자 인증서 또는 컴퓨터 인증서가 올바른 저장소에 존재하는지 점검해야 한다.
인증서 템플릿의 용도, 개인키 존재 여부, 자동 등록 정책 적용 여부가 함께 맞아야 한다.
6.6 시간 동기화가 틀어져 인증서 유효기간 또는 도메인 검증이 불안정한 문제이다
클라이언트와 NPS, 도메인 컨트롤러 간 시간이 크게 어긋나면 인증서 유효기간 판단과 인증 과정이 실패할 수 있다.
운영 환경에서는 NTP 기반으로 시간을 표준화하는 것이 기본 전제이다.
6.7 스위치 RADIUS 공유 비밀, 포트, 방화벽 설정이 장비별로 불일치한 문제이다
NPS에 6273이 없고 스위치에서 타임아웃이 보이면 공유 비밀 불일치 또는 UDP 1812/1813 경로 차단 가능성이 높다.
이 경우 장비 간 핑만으로는 판단이 불가능하므로, 스위치의 RADIUS 테스트 기능과 NPS 로그 유무로 경로를 판별해야 한다.
7. Windows 클라이언트 측에서 반드시 확인해야 하는 항목이다
7.1 Wired AutoConfig 서비스가 동작 중인지 확인하는 절차이다
유선 802.1X는 Wired AutoConfig 서비스가 중지되어 있으면 시작 자체가 불가능하다.
서비스 이름은 dot3svc이며, 조직에서는 그룹 정책으로 시작 유형을 자동으로 유지하는 구성이 일반적이다.
7.2 적용된 유선 802.1X 프로필이 의도한 EAP 방식인지 확인하는 절차이다
클라이언트가 PEAP로 요청하는데 NPS는 EAP-TLS만 허용하면 즉시 거부가 발생한다.
반대로 NPS는 PEAP만 허용하는데 클라이언트가 EAP-TLS를 요구하면 인증서 요구 조건을 충족하지 못해 실패한다.
7.3 유선 인증이 “컴퓨터 계정으로만” 시도되는지 “사용자 계정으로도” 시도되는지 확인하는 절차이다
NPS 이벤트에서 User Name이 PC이름 끝에 달러 기호가 붙는 형태로 보이면 컴퓨터 인증이 수행되는 상태일 가능성이 높다.
이때 사용자 그룹만 허용하는 정책이면 정상 사용자라도 부팅 단계에서 계속 거부될 수 있다.
주의 : 도메인 환경에서 부팅 단계 유선 인증이 실패하면 도메인 로그온 캐시로 우회되어 문제를 늦게 인지하는 경우가 있으므로, 신규 PC 배포 시 부팅 단계 인증 성공 여부를 별도로 검증해야 한다.
8. NPS 서버 측에서 “정책과 인증서”를 안전하게 점검하는 순서이다
8.1 NPS 이벤트에서 매칭된 정책 이름을 먼저 고정하는 절차이다
정책이 잘못 매칭되면 어떤 수정을 해도 해결되지 않으므로, 먼저 이벤트의 Network Policy Name이 의도한 정책인지 확정해야 한다.
의도한 정책이 아니라면 조건을 조정하거나 우선순위를 변경하여 올바른 정책이 매칭되도록 해야 한다.
8.2 정책의 Authentication Methods에서 허용된 EAP 유형을 점검하는 절차이다
유선 802.1X는 대개 PEAP 또는 EAP-TLS로 운영하며, 정책에서 허용된 방식이 클라이언트 설정과 일치해야 한다.
운영 안정성을 위해 동일 정책에 여러 인증 방식을 무분별하게 허용하지 않는 것이 문제 분석에 유리하다.
8.3 PEAP 또는 EAP-TLS에서 NPS 서버 인증서 선택을 점검하는 절차이다
NPS의 EAP 속성에서 선택된 서버 인증서가 올바른지 확인해야 한다.
올바른 서버 인증서는 만료되지 않아야 하고, 서버 인증 용도로 발급되어야 하며, 개인키가 존재해야 하고, 클라이언트가 신뢰하는 체인을 가져야 한다.
인증서 갱신 직후 장애가 발생했다면 가장 먼저 “새 인증서로 자동 선택이 바뀌었는지” 또는 “새 체인을 클라이언트가 신뢰하지 못하는지”를 확인해야 한다.
9. 스위치 측에서 자주 놓치는 설정 점검 체크리스트이다
스위치마다 명령어는 다르지만, 유선 802.1X 장애에서 반복적으로 등장하는 점검 항목은 공통적이다.
- RADIUS 서버 주소가 NPS의 실제 IP로 설정되어 있는지 확인해야 한다.
- RADIUS 공유 비밀이 NPS의 RADIUS Client 설정과 완전히 동일한지 확인해야 한다.
- 인증 포트(일반적으로 UDP 1812)와 회계 포트(일반적으로 UDP 1813)가 경로에서 차단되지 않았는지 확인해야 한다.
- 포트가 802.1X 인증 모드로 동작하며, 인증 실패 시의 게스트 VLAN 또는 제한 정책이 의도대로인지 확인해야 한다.
- 단말 한 대만 실패한다면 해당 포트의 MAC 제한, 포트 보안, 기존 세션 잔존 여부를 함께 확인해야 한다.
10. 재현 시 바로 수집할 수 있는 “클라이언트·NPS 동시 로그 수집” 표준 절차이다
인증서 검증, EAP 협상, 정책 매칭 문제는 화면 메시지만으로는 결론을 내릴 수 없으므로, 재현 시점에 ETL과 추적 로그를 동시에 남기는 것이 가장 빠르다.
아래 절차는 유선 시나리오에서 사용하도록 정리한 명령 집합이며, 관리자 권한 콘솔에서 실행해야 한다.
10.1 클라이언트에서 유선 추적을 시작하는 절차이다
mkdir C:\MSLOG
netsh ras set tracing * enabled
netsh trace start scenario=lan globallevel=0xff capture=yes maxsize=1024 tracefile=C:\MSLOG%COMPUTERNAME%_wired_cli.etl
wevtutil.exe sl Microsoft-Windows-CAPI2/Operational /e:true
wevtutil sl Microsoft-Windows-CAPI2/Operational /ms:10485760010.2 NPS 서버에서 유선 추적을 시작하는 절차이다
mkdir C:\MSLOG
netsh ras set tracing * enabled
netsh trace start scenario=lan globallevel=0xff capture=yes maxsize=1024 tracefile=C:\MSLOG%COMPUTERNAME%_wired_nps.etl
wevtutil.exe sl Microsoft-Windows-CAPI2/Operational /e:true
wevtutil sl Microsoft-Windows-CAPI2/Operational /ms:10485760010.3 문제를 재현한 뒤 추적을 종료하고 증적을 내보내는 절차이다
netsh trace stop netsh ras set tracing * disabled
wevtutil.exe sl Microsoft-Windows-CAPI2/Operational /e:false
wevtutil.exe epl Microsoft-Windows-CAPI2/Operational C:\MSLOG%COMPUTERNAME%_CAPI2.evtx클라이언트와 NPS 모두에서 %SystemRoot%\Tracing 폴더의 로그를 함께 보관하면 EAPOL, TLS, EAP 협상 분석에 도움이 된다.
주의 : trace와 CAPI2 로그는 파일이 커질 수 있으므로, 재현 직후 즉시 중지하고 필요한 기간에만 활성화해야 한다.
11. 실무에서 가장 빠른 해결 시나리오 6가지이다
11.1 “정책이 잘못 매칭”된 경우의 해결이다
NPS 이벤트에 표시되는 Network Policy Name이 의도와 다르면, 조건을 세분화하고 정책 우선순위를 조정하여 올바른 정책이 먼저 매칭되도록 해야 한다.
11.2 “클라이언트 EAP 방식과 NPS 허용 방식 불일치”인 경우의 해결이다
클라이언트가 PEAP인데 NPS가 EAP-TLS만 허용하거나 그 반대이면 즉시 실패하므로, 조직 표준을 확정하고 한 가지 방식으로 정렬하는 것이 해결의 핵심이다.
11.3 “서버 인증서 문제”인 경우의 해결이다
서버 인증서 만료, 체인 신뢰 실패, CRL 접근 불가가 의심되면 NPS의 EAP 설정에서 인증서 선택을 재확인하고, 클라이언트에 발급기관 신뢰를 배포해야 한다.
11.4 “클라이언트 인증서 문제”인 경우의 해결이다
EAP-TLS 사용 환경에서 클라이언트 인증서가 없거나 개인키가 없으면 인증이 진행되지 않으므로, 자동 등록 정책과 인증서 저장소 상태를 점검해야 한다.
11.5 “계정 상태 문제”인 경우의 해결이다
계정이 잠금, 비활성, 암호 만료, 권한 부족이면 NPS에서 거부가 발생하므로, 테스트 계정으로 재현하여 계정 요인을 분리해야 한다.
11.6 “RADIUS 경로 또는 공유 비밀 문제”인 경우의 해결이다
NPS에 로그가 없고 스위치에서 타임아웃이면 공유 비밀 및 UDP 포트 경로를 점검하여 요청이 NPS까지 도달하도록 복구해야 한다.
12. 운영 환경에서 재발 방지 기준을 만드는 방법이다
유선 802.1X는 한번 장애가 나면 영향 범위가 넓으므로, 사전에 기준을 문서화하면 장애 시간을 크게 줄일 수 있다.
- 표준 인증 방식은 PEAP 또는 EAP-TLS 중 하나로 고정하는 것이 바람직하다.
- NPS 정책은 컴퓨터 인증과 사용자 인증을 분리하고 우선순위를 명확히 두는 것이 바람직하다.
- NPS 서버 인증서는 만료 30일 전 갱신과 사전 테스트 절차를 포함해야 한다.
- 스위치 RADIUS 클라이언트 목록과 공유 비밀은 중앙에서 일관되게 관리해야 한다.
- 장애 시 즉시 수집할 로그 절차와 담당자를 정해두는 것이 바람직하다.
FAQ
유선 802.1X인데 NPS에 6273 이벤트가 전혀 보이지 않는 이유가 무엇인지 궁금하다.
이 경우 스위치가 NPS로 요청을 보내지 못했거나, 요청이 네트워크에서 차단되었거나, 공유 비밀 불일치로 요청 처리가 실패했을 가능성이 높다.
스위치의 RADIUS 서버 설정과 공유 비밀, UDP 1812/1813 경로, NPS의 RADIUS Client 등록 여부를 순서대로 점검하는 것이 합리적이다.
Event ID 6273에서 Reason Code 23이 나오면 무엇부터 봐야 하는지 궁금하다.
Reason Code 23은 EAP 협상 단계에서 오류가 발생했음을 시사하는 경우가 많으므로, NPS 서버 인증서 선택과 유효성, 체인 신뢰, 만료 여부, 그리고 클라이언트가 해당 발급기관을 신뢰하는지부터 점검해야 한다.
동시에 클라이언트와 NPS에서 trace와 CAPI2 로그를 수집하면 인증서 검증 실패 흔적을 더 명확히 확인할 수 있다.
Event ID 6273에서 Reason Code 16이 반복되는데 사용자 암호는 맞는 상황이 궁금하다.
이때는 인증 주체가 사용자 계정이 아니라 컴퓨터 계정으로 들어오고 있는지, 또는 정책이 요구하는 인증 방식과 실제 시도가 불일치하는지부터 확인해야 한다.
NPS 이벤트의 User Name 형식과 매칭된 정책 이름을 기준으로 사용자 인증/컴퓨터 인증 정책 분리 여부를 재점검하는 것이 효과적이다.
NPS에 6272 성공이 찍히는데도 PC가 네트워크가 안 되는 이유가 무엇인지 궁금하다.
이 경우 802.1X 인증 자체는 성공했으므로, 스위치의 VLAN 할당, 동적 VLAN 응답 처리, ACL, 포트 보안, DHCP 또는 라우팅 영역을 집중 점검해야 한다.
성공 이벤트의 속성에서 부여된 정책과 속성 값을 확인하고 스위치의 실제 적용 상태와 대조하는 것이 필요하다.