Protected Users 노트북이 로그인 전에 VPN을 필요로 하는 이유

노트북, 동작하는 계정, 호텔 네트워크가 합쳐지면 아무리 다시 시도해도 풀리지 않는 로그인 루프가 만들어집니다. 계정은 Protected Users에 속해 있으며, 이는 Windows가 사용자를 오프라인으로 인증하는 데 필요한 검증자를 저장하지 못하게 합니다. «먼저 로그인하고 그다음 터널을 연결한다»는 형태의 계획은 순서가 거꾸로이며, 보호 기능은 약속한 대로 정확히 작동합니다. 이하는 지원되는 Windows 호스트의 전통적인 Active Directory 계정을 전제로 합니다.

보호 기능이 실제로 제거하는 것

일반적으로 Windows는 검증자를 캐시하여 도메인 컨트롤러에 연결할 수 없을 때도 도메인 계정이 로그인할 수 있게 합니다. Protected Users는 계정에 대해 이를 차단하며, 이는 오프라인 도메인 로그인을 불안정하게 만드는 대신 가능성 자체를 없앱니다.

이것은 흔한 오래된 캐시 문제가 아니며, 일반적인 처방은 적용되지 않습니다. 온라인 로그인을 반복하거나, 비밀번호를 다시 바꾸거나, 캐시된 로그온 수를 늘려도 기능은 복원되지 않습니다. 그러한 행위 중 어느 것도 정책이 저장을 거부하는 검증자를 만들지 않기 때문입니다. 계정은 설계대로 동작하고 있으며, 설계는 Windows가 요청하는 시점에 네트워크가 있다고 가정합니다. 증상을 캐시 결함으로 다루는 것이 팀이 한 번도 깨진 적 없는 프로필을 다시 만드는 경로입니다.

터널이 데스크톱보다 먼저 존재해야 하는 이유

장치는 Windows가 요구하는 순간, 즉 어떤 사용자 세션도 존재하기 전에 도메인 인증에 도달해야 합니다. 데스크톱이 나타난 뒤에야 시작하는 VPN 클라이언트는 새 로그인을 결코 오지 않는 경로 앞에서 기다리게 합니다. 이 의존성은 기계에 속하며, 아직 로그인하지 않은 사용자에게 속하지 않습니다.

엔드포인트와 ID 책임자와 합의한 지원되는 사전 로그인 방식을 사용하십시오. 컴퓨터 인증서로 인증하는 Always On VPN 장치 터널은 관리 장치가 해당 배포의 전제 조건을 충족할 때 적합합니다. 공급업체가 지원하는 로그인 화면 통합도 또 다른 선택지입니다. 자동 트리거가 있는 일반 사용자 프로필은 둘 다 아니며, 클라이언트 화면에서 아무리 비슷해 보여도 마찬가지입니다.

그 경로에는 도메인에 대한 이름 확인, 도달 가능한 도메인 컨트롤러, 계정이 사용할 수 있는 인증 프로토콜이 필요하며, «연결됨» 표시는 그중 어느 것도 제공하지 않습니다. 그 경로와 필터는 ID 서비스만 실어야 하고 필요하지 않은 것은 실어서는 안 됩니다. 그 접두사 목록이야말로 누군가 로그인하기 전에 도난당한 노트북이 얻는 표면이기 때문입니다. 사용자 터널에 대해 내린 분할 터널 결정은 장치 터널로 이어지지 않으므로 둘을 따로 검토하십시오.

도달 가능성은 인증 호환성이 아닙니다

터널이 패킷을 완벽하게 실어 나르는데도 도메인 인증이 실패할 수 있습니다. 시도되는 메커니즘이 계정이 사용할 수 없는 것이기 때문입니다. 그룹의 제한을 적용하는 도메인에서는 구성원에게 NTLM을 쓸 수 없고 Kerberos에는 AES 호환 계정과 구성이 필요합니다. 패킷 경로는 둘 중 어느 것도 고칠 수 없습니다. 그래서 도메인 컨트롤러에 대한 깨끗한 ping은 로그인이 성공한다는 증거가 아닙니다.

두 개의 자격 증명 체계가 함께 작동할 수도 있습니다. VPN은 ID 공급자에 대해 인증하고 Windows는 별도로 도메인 로그온을 필요로 할 수 있으며, 첫 번째의 수락은 두 번째에 대해 아무것도 말해 주지 않습니다. «VPN이 연결되었다»와 «사용자가 로그인했다»는 별개의 관찰이며, 하나를 고친다고 다른 하나가 성립하지는 않습니다.

인증 증거를 읽으십시오

같은 시도에 대해 한쪽만이 아니라 클라이언트와 도메인 컨트롤러 양쪽에서 이벤트를 수집하십시오. Protected Users 로그는 Applications and Services Logs\Microsoft\Windows\Authentication 아래에 있으며, 관리자가 무언가를 기록하기 전에 로그를 켜야 할 수도 있습니다. 타임스탬프를 터널 자체의 연결 로그와 대조하십시오. 순서 착오는 어느 쪽에서 보아도 자격 증명 결함처럼 보이기 때문입니다.

아래 첫 번째 명령은 장치가 노출하는 모든 인증 로그를 나열하므로 블로그 글에서 이름을 언급한 것이 아니라 실제로 존재하는 로그를 읽게 됩니다. 두 번째는 이름을 알게 된 뒤 최근 항목을 읽습니다. 인증 패키지, 계정, 실패 조건을 찾으십시오. 네트워크 경로 부재와 거부된 메커니즘은 서로 다른 증거를 남기며 그중 하나만 VPN 문제입니다. 시도 후에 터널이 올라왔다면 그 항목들이 무엇을 말하든 순서가 잘못된 것입니다.

Get-WinEvent -ListLog *Authentication*
Get-WinEvent -LogName Microsoft-Windows-Authentication/Operational -MaxEvents 20

콜드 부팅에서 경계를 증명하십시오

로그아웃했거나 막 부팅한 상태에서 제한된 계정으로 시험을 실행하고, 권한 있는 사용자를 위해 무엇이든 바꾸기 전에 승인된 복구 경로를 열어 두십시오. 이미 실행 중인 데스크톱에서의 시험은 중요한 코드 경로를 전혀 거치지 않으며, 다음 재부팅까지 유지된 수정에 관한 보고의 대부분이 이로써 설명됩니다. 그런 다음 네 단계를 이 순서로 진행하십시오.

1. 누군가 로그인하기 전에 장치가 도메인 컨트롤러를 찾을 수 있는지 nltest /dsgetdc:corp.example.com 로 확인하십시오.
2. 도메인 로그인을 시도한 뒤 klist 로 티켓이 실제로 발급되었는지 물으십시오.
3. 장치가 기록하는 인증 로그를 위의 두 명령으로 읽고 패키지와 실패 조건을 적으십시오.
4. 승인된 복구 자격 증명이 로그인 화면에서 여전히 작동하는지 확인하십시오. 경계 시험이 실패할 때 돌아오는 유일한 길이기 때문입니다.

제공된 자격 증명으로 파일 공유를 열어도 오프라인 대화형 로그온이 생기지 않으므로 위 단계 어느 것도 대신하지 못합니다. 조직이 정말로 연결 없는 로그인을 필요로 한다면 답은 의도적으로 선택한 호환되는 계정과 엔드포인트 설계입니다. 계정을 그룹에서 빼거나 모든 노트북에 제한 없는 비상 로그인을 하나 남겨 두는 것은 VPN 변경이 대신 내릴 수 없는 ID 정책 결정입니다.

Protected Users 문서 는 검증자의 동작과 이 설계가 의존하는 도메인 제한을 모두 설명합니다. 누군가 여행하기 전에 복구 절차를 계획하십시오. 콜드 부팅 시험이 실제로 훈련되는 유일한 장소이기 때문입니다.