- 공유 링크 만들기
- X
- 이메일
- 기타 앱
이 글의 목적은 802.1X 유선(유선 LAN) 환경에서 인증 실패가 발생할 때, Windows NPS(Network Policy Server) 오류를 중심으로 원인을 빠르게 분류하고 재발 없이 해결할 수 있도록 실무 절차와 점검 항목을 체계적으로 제공하는 것이다.
1. 802.1X 유선 인증 흐름을 먼저 정리하다
802.1X 유선 인증은 “단말(서플리컨트)–스위치(인증자)–NPS(RADIUS)” 3자 구조로 동작하다. 단말은 EAPOL로 스위치에 인증을 요청하고, 스위치는 이를 RADIUS(UDP 1812/1813)로 NPS에 중계하다. NPS는 정책과 자격증명(AD/인증서/계정 조건)을 평가한 뒤 Accept 또는 Reject를 반환하다.
따라서 장애 분석은 “단말 설정 문제”, “스위치/네트워크 중계 문제”, “NPS 정책/인증서/AD 문제”로 나눠 접근하는 것이 가장 빠르다.
주의 : 유선 802.1X 장애를 단말만 재설치로 해결하려 하면 재발하는 경우가 많다. 반드시 NPS 로그의 거부 사유(Reason Code)와 스위치 로그의 RADIUS 응답 결과를 근거로 원인을 확정한 뒤 조치해야 하다.
2. 증상을 3분 안에 분류하는 체크리스트
2.1 단말 측 증상
네트워크가 “식별 중” 또는 “인증 실패”로 반복되거나, 특정 사용자만 실패하거나, 로그인 전에는 실패하고 로그인 후에만 성공하는 증상이 대표적이다. 이는 EAP 방식 불일치, 인증서 문제, GPO 적용 문제, 컴퓨터/사용자 인증 순서 문제에서 자주 발생하다.
2.2 스위치 측 증상
포트가 Guest VLAN으로만 떨어지거나, 인증 타임아웃 후 차단되거나, MAB로만 붙는 증상이 대표적이다. 이는 RADIUS 공유키 불일치, RADIUS 서버 도달 불가, 802.1X 포트 설정 누락, 동적 VLAN/ACL 적용 실패에서 자주 발생하다.
2.3 NPS 측 증상
NPS 이벤트 뷰어에 6273(거부), 6272(허용), 4402/4401(EAP 관련), 18/16(정책/자격증명 관련) 등이 기록되며, 대부분 “Reason Code”가 해결의 핵심 단서가 되다.
| 분류 | 가장 흔한 원인 | 가장 먼저 볼 로그 | 즉시 조치 방향 |
|---|---|---|---|
| 단말 | EAP 방식/인증서/자격증명 | Windows Wired-AutoConfig, Schannel | 유선 정책(GPO)와 인증서 체인 점검 |
| 스위치 | RADIUS 공유키/도달성/포트 설정 | 스위치 AAA/RADIUS 로그 | RADIUS 서버 상태 및 공유키, 802.1X 포트 설정 점검 |
| NPS | 정책 순서/조건/권한/인증서 | NPS 이벤트 6273/6272, IAS 로그 | Reason Code 기반으로 정책/PEAP-TLS 설정 수정 |
3. NPS 로그를 “증거”로 확보하는 방법
3.1 이벤트 뷰어에서 NPS 이벤트 확인하다
NPS 서버에서 이벤트 뷰어의 “사용자 지정 보기” 또는 “서버 역할 > 네트워크 정책 및 액세스 서비스”에서 6273/6272를 확인하다. 여기서 “클라이언트 친화적 이름(스위치 이름)”, “NAS IP”, “정책 이름”, “EAP 타입”, “Reason Code”를 확보하는 것이 핵심이다.
3.2 텍스트 로그(IAS/NPS Accounting)도 함께 남기다
이벤트만으로 부족하면 NPS 로깅을 활성화해 IAS 형식 로그를 남기다. 장애 재현 시점의 단말 MAC, 사용자, EAP 타입, 스위치 IP, 응답 결과를 한 줄로 확인할 수 있어 대량 장애 분석에 유리하다.
주의 : 로깅을 켠 뒤 디스크 용량을 관리하지 않으면 로그가 누적되어 서버 운영에 영향을 줄 수 있다. 저장 경로와 보관 기간을 운영 정책으로 고정해야 하다.
3.3 단말에서 유선 자동 구성 로그를 확인하다
단말(Windows)은 “Wired-AutoConfig”와 “Schannel” 로그에서 EAP/TLS 실패 원인을 구체적으로 남기다. 특히 인증서 만료, 신뢰되지 않는 루트, CRL 조회 실패, 서버 이름 불일치가 자주 보이다.
REM (단말) 유선 자동 구성 로그 확인 위치 예시 REM 이벤트 뷰어 > 응용 프로그램 및 서비스 로그 REM Microsoft > Windows > Wired-AutoConfig/Operational REM (단말) 시스템 시간 동기 확인 w32tm /query /status REM (단말) 도메인 신뢰/채널 상태 점검 nltest /sc_verify:도메인명4. NPS 오류(6273 등) “Reason Code”별 원인과 해결
NPS 6273은 “요청이 거부됨”을 의미하며, 실제 원인은 Reason Code로 갈리다. 아래 표는 유선 802.1X에서 실무적으로 가장 자주 만나는 패턴을 정리한 것이다.
| NPS 이벤트 | 대표 Reason Code(예시) | 의미(실무 해석) | 가장 흔한 원인 | 조치 |
|---|---|---|---|---|
| 6273 | 16 | 자격증명 거부 또는 인증 실패로 처리됨 | 비밀번호 오류, 계정 잠김, 인증 방식 불일치 | AD 계정 상태/잠금/비밀번호 정책 확인, EAP 방식 통일 |
| 6273 | 18 | 지정된 정책 조건을 만족하지 못함 | 정책 순서 문제, 그룹 조건 불일치, NAS 포트 타입 조건 불일치 | NPS 정책 우선순위 재정렬, 조건 단순화 후 단계적으로 강화 |
| 6273 | 22 | 클라이언트가 인증 방법을 사용할 권한이 없음 | 다이얼 인 권한/네트워크 액세스 권한 충돌, NPS 권한 부족 | 사용자/컴퓨터 계정의 네트워크 액세스 권한 정책 정리, NPS-AD 등록 확인 |
| 6273 | 48 | 인증서/서버 신뢰 문제로 EAP 협상 실패 | 서버 인증서 만료, EKU 누락(Server Authentication), 루트 미신뢰 | NPS 서버 인증서 재발급 및 체인 배포, PEAP/TLS 설정 재점검 |
| 6273 | 66 | 클라이언트가 EAP 응답을 보내지 않음 또는 중간에서 끊김 | 스위치 타임아웃, MTU/방화벽, EAPOL 차단 | 스위치 dot1x 타이머 조정, 1812/1813 및 EAPOL 흐름 점검 |
4.1 정책 순서가 꼬이면 “정상 사용자도 전부 실패”가 발생하다
NPS는 위에서 아래로 정책을 평가하다. 상단 정책이 너무 넓은 조건으로 매칭되면서 인증 방법이 맞지 않거나 접근이 거부되면, 하단의 올바른 정책까지 도달하지 못하다. 특히 유선(IEEE 802.3)과 무선(IEEE 802.11)을 한 서버에서 같이 운영할 때 조건이 섞여 장애가 커지다.
유선 802.1X는 최소한 다음 조건을 명확히 분리하는 것이 안전하다.
| 구분 | 권장 분리 조건 | 설명 |
|---|---|---|
| 유선 | NAS Port Type = Ethernet | 유선 요청만 해당 정책이 매칭되도록 하다 |
| 무선 | NAS Port Type = Wireless - IEEE 802.11 | 무선과 유선이 섞여 인증 방식이 꼬이는 것을 막다 |
| 게스트/격리 | 특정 스위치/특정 VLAN/특정 그룹 | 예외 정책은 최하단으로 두고 범위를 좁히다 |
주의 : “모든 사용자” 조건의 테스트 정책을 상단에 두면 운영 정책을 덮어 장애가 확산하다. 테스트는 제한된 스위치 IP 또는 제한된 AD 그룹으로만 수행해야 하다.
4.2 PEAP(MSCHAPv2) 실패는 “서버 인증서 신뢰”가 절반이다
유선 802.1X에서 가장 흔한 조합은 PEAP + MSCHAPv2이다. 이 방식은 단말이 NPS 서버 인증서를 신뢰해야 하며, 단말 정책에서 “서버 인증서 유효성 검사”를 강제하면 작은 인증서 문제도 즉시 전면 장애로 이어지다.
다음 항목이 하나라도 맞지 않으면 실패할 수 있다.
- NPS 서버 인증서의 EKU에 Server Authentication이 포함되어야 하다.
- 인증서 주체 또는 SAN의 서버 이름이 단말에서 기대하는 이름과 일치해야 하다.
- 루트/중간 인증서 체인이 단말에 신뢰로 배포되어야 하다.
- CRL 조회가 차단되면 정책에 따라 인증이 실패할 수 있다.
REM (NPS 서버) 인증서 확인(개념 절차) REM 1) MMC 실행 > Certificates(Computer) 스냅인 추가 REM 2) Personal > Certificates 에서 NPS에 바인딩된 인증서 확인 REM 3) Enhanced Key Usage에 Server Authentication 포함 확인 REM 4) 만료일, 체인, CRL/OCSP 접근성 확인 REM (단말) 루트/중간 인증서 배포 여부 확인(개념 절차) REM MMC > Certificates(Current User 또는 Local Computer) REM Trusted Root Certification Authorities / Intermediate 확인4.3 EAP-TLS(인증서 기반) 실패는 “클라이언트 인증서 조건”이 핵심이다
EAP-TLS는 사용자 또는 컴퓨터 인증서로 인증하다. 이때 단말 인증서에 Client Authentication EKU가 필요하며, 개인 키가 존재해야 하다. 또한 NPS 정책에서 “인증서 선택(스마트카드 또는 기타 인증서)” 설정과 매칭되어야 하다.
특히 유선에서 “컴퓨터 인증 먼저, 사용자 인증은 로그인 후” 구조를 쓰면 컴퓨터 인증서가 없거나 자동 배포가 안 된 단말에서 로그인 전 네트워크가 끊겨 도메인 로그온 자체가 실패하다. 이 경우 배포 체계(GPO 자동 등록, 인증서 템플릿 권한)를 먼저 정상화해야 하다.
주의 : 도메인 환경에서 유선 802.1X를 인증서 기반으로 설계할 경우, “로그인 전 네트워크”가 보장되어야 하다. 컴퓨터 인증서 배포 실패는 단순 네트워크 장애가 아니라 업무 마비로 이어지다.
5. 스위치(네트워크 장비)에서 반드시 확인할 항목
5.1 RADIUS 공유키(Shared Secret) 불일치
스위치와 NPS의 RADIUS 클라이언트 설정에서 공유키가 한 글자라도 다르면 인증이 실패하다. 이 경우 NPS에는 “클라이언트에서 온 요청을 처리할 수 없음” 또는 인증 시도 자체가 로그에 약하게 남는 경우가 있어 스위치 로그가 더 빠른 단서가 되다.
5.2 RADIUS 서버 정의(IP/포트/소스 IP)
스위치가 NPS로 나갈 때 소스 IP가 관리 VLAN인지 라우티드 인터페이스인지에 따라 NPS의 “RADIUS 클라이언트”로 등록된 IP와 달라질 수 있다. NPS는 등록되지 않은 클라이언트의 요청을 기본적으로 거부하다. 스위치의 NAS IP와 NPS에 등록된 클라이언트 IP가 일치하는지 반드시 확인해야 하다.
5.3 802.1X 포트 모드, 타이머, MAB/게스트 VLAN
운영에서는 802.1X 실패 시 게스트 VLAN로 보내는 설계를 자주 쓰다. 이때 게스트 정책이 강하게 적용되어 정상 단말도 게스트로 떨어지는 장애가 발생하다. 인증 타이머가 너무 짧아 EAP 협상 도중 타임아웃이 나면 “간헐적 실패”가 반복되다.
| 항목 | 점검 포인트 | 장애 패턴 | 개선 방향 |
|---|---|---|---|
| 포트 모드 | access/voice, multi-host 설정 | 전화기/PC 혼재 시 한쪽만 성공 | 단말 구성에 맞게 multi-auth 등 설계 반영 |
| 타이머 | EAPOL 시작/재시도/서버 타임아웃 | 간헐 실패, 특정 모델에서만 실패 | 기본값 대비 여유 있게 조정 후 추적 |
| 게스트 VLAN | 실패 시 fallback 조건 | 정상 사용자도 게스트로 강제 | 게스트 정책의 적용 조건을 좁히다 |
6. 단말(GPO/로컬 설정)에서 실무적으로 자주 놓치는 부분
6.1 유선 802.1X 정책(GPO) 적용 여부
Windows 유선 802.1X는 GPO로 “Wired Network(IEEE 802.3) Policies”를 배포하는 구성이 일반적이다. 정책이 미적용이면 단말마다 EAP 방식이 달라지고, 사용자가 수동으로 바꾸며 상태가 더 악화하다. 따라서 장애 시 “정책이 실제로 적용되었는지”부터 확인해야 하다.
REM (단말) 그룹 정책 적용 결과 확인 gpresult /r REM (단말) 로컬 정책/프로파일 상태 점검은 환경에 따라 상이하므로 REM 우선 gpresult로 Wired 정책 적용 여부를 확인하는 것이 빠르다.6.2 사용자 인증 vs 컴퓨터 인증, 그리고 로그인 전 연결
유선은 “로그인 전에도 네트워크가 살아 있어야” 도메인 로그인, 스크립트, 인증서 자동 등록이 가능하다. 따라서 컴퓨터 인증을 우선 사용하거나, 최소한 “컴퓨터 사용 가능 시” 옵션을 적절히 구성해야 하다. 사용자 인증만 강제하면 로그인 화면에서 네트워크가 없어지는 상황이 발생하다.
6.3 서버 인증서 유효성 검사 옵션
보안을 위해 서버 인증서 검증을 켜는 것이 바람직하다. 다만 인증서 체인 배포(루트/중간)와 서버 이름 정책이 정교하지 않으면 대규모 장애가 발생하다. 운영 전환 시에는 파일럿 그룹에서 충분히 검증한 뒤 전체 적용해야 하다.
주의 : “서버 인증서 검증”을 갑자기 전체 강제하면, 이전에 묵인되던 인증서 체인 문제와 이름 불일치 문제가 한 번에 폭발하다. 파일럿–단계적 확대 절차가 필수이다.
7. 재발 방지를 위한 표준 트러블슈팅 절차(권장)
7.1 장애 발생 시 수집해야 하는 최소 정보
| 수집 항목 | 예시 | 왜 필요한가 |
|---|---|---|
| 단말 정보 | MAC, OS, 유선 어댑터 모델 | 단말별/드라이버별 재현성 판단에 필요하다 |
| 사용자/컴퓨터 계정 | 도메인\\사용자 또는 컴퓨터명 | 사용자 인증/컴퓨터 인증 구분에 필요하다 |
| 스위치 정보 | 스위치명, 포트, NAS IP | NPS RADIUS 클라이언트 매칭에 필요하다 |
| NPS 이벤트 | 6273/6272, Reason Code, 정책명 | 거부 근거를 확정하는 핵심 증거이다 |
| EAP 방식 | PEAP(MSCHAPv2), EAP-TLS | 인증서/암호 기반 분기에 필수이다 |
7.2 원인 확정 후 조치 순서
다음 순서를 따르면 불필요한 변경을 최소화하면서 해결할 수 있다.
- NPS 6273의 Reason Code로 “정책 문제인지, 인증서 문제인지, 자격증명 문제인지”를 먼저 확정하다.
- 스위치 로그로 RADIUS 서버 도달과 응답 수신 여부를 확인하다.
- 단말 Wired-AutoConfig/Schannel 로그로 EAP 협상 실패 지점을 확인하다.
- 정책은 조건을 단순화해 성공시키고, 이후 보안 조건을 단계적으로 강화하다.
7.3 운영 품질을 올리는 설정 팁
운영 안정성을 위해 다음을 권장하다.
- NPS 정책은 “유선/무선/게스트”를 확실히 분리하고, 정책명을 표준화하다.
- 스위치 RADIUS 클라이언트 등록은 “소스 IP 기준”으로 통일하고 변경 관리하다.
- 서버 인증서는 자동 갱신 체계를 갖추고 만료 60~90일 전 알림을 운영하다.
- 단말 유선 정책은 GPO로 통일하고, 로컬 수동 변경을 제한하다.
8. 현장에서 바로 쓰는 진단 명령 예시
REM (NPS 서버) 시간 동기 확인(도메인 환경에서 매우 중요) w32tm /query /status
REM (NPS 서버) 도메인 신뢰 채널 확인
nltest /sc_verify:도메인명
REM (단말) 적용된 GPO 확인
gpresult /r
REM (단말) 네트워크 어댑터/드라이버 문제 의심 시 장치관리자에서
REM 유선 NIC 드라이버 버전 확인 후, 동일 모델 간 증상 비교를 수행하다.FAQ
802.1X 유선이 “어제까지 되다가 오늘 갑자기” 전부 실패하는 가장 흔한 원인은 무엇인가?
NPS 서버 인증서 만료, 인증서 체인 변경(루트/중간 갱신), NPS 정책 우선순위 변경, 스위치의 RADIUS 소스 IP 변경, 공유키 변경이 대표적 원인이다. 이 경우 NPS 6273의 Reason Code와 인증서 만료일, 스위치 NAS IP 변화를 동시에 확인하는 것이 가장 빠르다.
특정 사용자만 802.1X 유선 인증이 실패하는데 NPS는 6273으로 거부된다. 무엇부터 봐야 하는가?
Reason Code로 “자격증명 실패(비밀번호/잠금)”인지 “정책 조건 불일치(그룹/시간/장치 조건)”인지 먼저 분리해야 하다. 그 다음 AD 계정 잠금/만료, 그룹 멤버십, 정책 조건(그룹/컴퓨터 그룹)을 점검하는 것이 정석이다.
로그인 화면에서 네트워크가 안 잡혀 도메인 로그인이 안 된다. 해결 방향은 무엇인가?
사용자 인증만 강제하는 구성에서 자주 발생하다. 컴퓨터 인증을 활성화하거나 “컴퓨터 사용 가능 시” 옵션을 적용해 로그인 전에도 포트가 인증되도록 설계해야 하다. 인증서 기반(EAP-TLS)이라면 컴퓨터 인증서 자동 배포가 선행되어야 하다.
PEAP를 쓰는데 단말에서 서버 인증서 경고가 뜨거나 바로 실패한다. 무엇을 고쳐야 하는가?
NPS 서버 인증서의 EKU(Server Authentication), 만료 여부, 체인(루트/중간) 신뢰 배포, 서버 이름 일치, CRL 접근 가능 여부를 점검해야 하다. 단말 정책에서 서버 이름을 지정해 두었다면 인증서의 이름 정보가 정확히 일치해야 하다.
NPS에 6273이 없고 스위치에서만 인증 실패가 보인다. 어디가 문제인가?
스위치에서 NPS로 RADIUS 요청이 도달하지 못했거나, NPS가 “등록되지 않은 RADIUS 클라이언트”로 즉시 차단했을 가능성이 크다. 스위치의 RADIUS 서버 IP/포트, 소스 IP, 경로 ACL/방화벽(UDP 1812/1813), 그리고 NPS RADIUS 클라이언트 등록 IP 일치를 확인해야 하다.