NTLM 사용 중단으로 업무 앱이 멈출까 ── 감사 로그를 모으는 방법과, 의존을 없애는 순서

「NTLM이 사용 중단된다고 한다. 우리는 괜찮은가」──2024년 6월 Microsoft가 NTLM의 모든 버전을 사용 중단(deprecated)으로 발표한 이후, 이 질문을 받는 일이 늘었습니다. 답은, 괜찮은지는 조사하면 알 수 있고, 지금 조사하면 늦지 않는다입니다.

NTLM 사용 중단은 「어느 날 패치가 적용되어 전사가 멈춘다」 종류의 변경이 아닙니다. OS를 새로 올릴 때마다 조금씩 조여 가는 변경이며, 게다가 아직 NTLM이 동작하는 지금만, 「자사 어디가 NTLM에 의존하는지」를 안전하게 목록화할 수 있습니다. 전부 멈춘 뒤에 깨진 곳을 찾는 것은, 가장 해서는 안 되는 순서입니다.

이 기사는 그 목록을 만들어 없애 나가기 위한 실무 절차에 한정합니다. 프로토콜 자체(왜 NTLM이 위험한지, 왜 Kerberos로 가지 않는지)는, 짝이 되는 기사 「그림으로 이해하는 NTLM과 Kerberos ── 왜 인증은 NTLM으로 「fallback」하는가」로 나눴습니다.

1. 먼저 결론

• NTLM은 2024년 6월에 사용 중단이 되었습니다. 대상은 LANMAN·NTLMv1·NTLMv2를 포함한 모든 버전이며, 「더 이상 적극적인 기능 개발은 하지 않는다」는 선언입니다. 동시에 「차기 Windows Server와 다음 연간 릴리스의 Windows에서도 NTLM 이용은 계속 동작한다」고도 적혀 있습니다. ¹
• 이미 삭제된 부분이 있습니다. NTLMv1은 Windows 11 버전 24H2와 Windows Server 2025에서 삭제되었습니다. ¹
• 사용 중단은 3단계로 진행됩니다. 1단계가 이용 현황 가시화와 감사, 2단계(2026년 후반)가 NTLM에 의존할 수밖에 없는 장면을 없애기 위한 기능(IAKerb, 로컬 KDC), 3단계가 차기 메이저 릴리스에서의 네트워크 NTLM 인증 기본 사용 안 함입니다. ²
• 지금 해야 할 일은 하나뿐입니다. 감사 모드를 돌려 「어느 단말의, 어느 앱이, 어느 서버에 대해」 NTLM을 쓰는지의 목록을 만드는 것입니다(4장).
• 도메인 계정 조사는 도메인 컨트롤러부터 시작합니다. 이벤트 8004 → 멤버 서버의 8003 → 클라이언트의 8001 순으로 따라가면, 마지막에 앱 이름까지 닿습니다(4.2절). 다만 로컬 계정으로의 인증은 도메인 컨트롤러를 거치지 않으므로 8004가 나오지 않습니다. 이 경로는 서버 측 8003과 클라이언트 측 8001에서 잡습니다. ³
• 원인의 대부분은 「이름」입니다. IP 주소 직접 입력과 SPN 미등록이 두 가지 큰 요인이며, 둘 다 앱을 다시 만들지 않고 고칠 수 있습니다(5장). ³²
• 한 대만으로 안전하게 시험하는 방법이 있습니다. Windows 11 24H2 / Windows Server 2025라면 NET USE \\server\share /BLOCKNTLM으로, 정책을 전혀 바꾸지 않고 「NTLM 없이 연결되는지」를 확인할 수 있습니다(7장). ⁴
• 자체 앱은 NTLM을 지정한 곳을 Negotiate로 바꿉니다. Microsoft 자신이 「NTLM 보안 패키지에 직접 접근하지 마라」고 적고 있습니다(8장). ⁵

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 29건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 「사용 중단」은 무엇을 뜻하는가

먼저 용어를 정리해 둡니다. 여기를 모호하게 둔 채 사내에 설명하면, 「이제 못 쓴다」와 「아직 몇 년은 괜찮다」가 동시에 퍼져 이야기가 꼬입니다.

Microsoft의 사용 중단 기능 목록에 실린 NTLM 서술은, 요약하면 다음 세 가지입니다. ¹

1. LANMAN, NTLMv1, NTLMv2를 포함한 모든 버전의 NTLM이, 적극적인 기능 개발 대상이 아니며, 사용 중단이다.
2. NTLM 이용은 차기 Windows Server와 다음 연간 릴리스의 Windows에서도 계속 동작한다.
3. NTLM 호출은 Negotiate 호출로 바꿔야 한다. Negotiate는 Kerberos 인증을 시도하고, 필요할 때만 NTLM으로 fallback한다.

그리고 업데이트 정보로, NTLMv1은 Windows 11 버전 24H2 및 Windows Server 2025에서 삭제되었다는 점이 추가되어 있습니다. ¹

즉 현재 위치는 「사용 중단(deprecated)」이지 「삭제(removed)」가 아닙니다. 다만 NTLMv1만은 사용 중단을 지나 이미 삭제 단계에 들어갔습니다. 오래된 복합기나 NAS가 NTLMv1로만 인증할 수 있는 경우, Windows 11 24H2로의 업데이트가 그대로 장애가 됩니다. 이는 미래의 이야기가 아니라, 지금 일어나는 이야기입니다.

하나 더 짚어 둘 점은, NTLM에는 「대체 수단이 없는 용도」가 남아 있다는 것입니다. Microsoft는, 작업 그룹 구성 시스템에서의 Windows 인증과, 도메인 컨트롤러 이외에서의 로컬 로그온 인증에는, 여전히 NTLM이 쓰이며, 쓰여야 한다고 명시합니다. ⁶ 2단계에서 예정된 로컬 KDC는, 바로 이 「로컬 계정 때문에 NTLM이 필요」라는 구멍을 메우기 위한 기능입니다. ²

2.1. 3단계의 현재 위치

사용 중단 로드맵은 3단계입니다. 시점 의존 정보이므로, 기준일을 붙여 정리합니다(아래 표는 2026년 7월 시점의 상황입니다).

이 표에서 확인해 주었으면 하는 것은, 지금 자기 손으로 움직일 수 있는 것은 1단계뿐이다라는 점입니다. 2단계 기능은 6장의 판단 표에서 「답이 될 수 있다」고 적은 곳이 있지만, 모두 제공 상황 확인이 전제입니다. 제공 시기는 바뀔 수 있으므로, 이 표의 내용은 자사 판단 시점에 반드시 다시 잡으세요.

3. 왜 사라지는가 ── 3분만

마이그레이션 판단 재료로 최소한만 짚습니다. 자세한 그림은 짝이 되는 기사에 맡깁니다.

Microsoft는 정책 설정 문서에서, NTLM 및 NTLMv2 인증은, SMB 릴레이, 중간자 공격, 무차별 대입 공격을 포함한 다양한 악의적 공격에 취약하다고 분명히 적습니다. ⁷ 뿌리에는, Kerberos와의 비교로 이야기되는 다음 성질이 있습니다. ⁸

• 상호 인증이 없다. NTLM에서는, 클라이언트가 서버의 신원을 검증하는 것도, 서버가 다른 서버의 신원을 검증하는 것도 할 수 없습니다. NTLM은 「서버는 진짜이다」고 가정할 수 있는 네트워크 환경을 위해 설계된 것입니다. Kerberos는 그 가정을 두지 않습니다. 이 차이가, 가짜 서버로 인증 정보를 보내게 하는 릴레이 공격의 성립 조건이 됩니다.
• 서버가 매번 도메인 컨트롤러에 조회한다(도메인 계정의 경우). NTLM에서는, 애플리케이션 서버는 도메인 계정 클라이언트를 인증할 때마다 도메인 컨트롤러에 연결해야 합니다(서버에 로컬인 계정이라면, 서버가 자신의 계정 데이터베이스를 조회해 판정합니다). ⁶ Kerberos에서는 갱신 가능한 세션 티켓이 이 pass-through 인증을 대체하며, 서버는 PAC(권한 특성 인증서) 검증이 필요한 경우를 제외하고 도메인 컨트롤러로 갈 필요가 없습니다.
• 인증 재료가 비밀번호 해시 그 자체다. NTLM 자격 증명은 도메인 이름과 사용자 이름, 그리고 비밀번호의 일방향 해시로 구성되며(해시되는 것은 비밀번호뿐입니다), 클라이언트는 이 해시로 챌린지를 암호화해 응답을 반환합니다. ⁵ 해시를 훔치면, 평문 비밀번호를 몰라도 가장할 수 있다는 성질이 여기서 나옵니다.

「상호 인증이 없다」의 실무적 의미는, SMB 공유에 연결하려 한 것만으로, 가짜 서버에 인증 정보를 넘길 수 있다는 것입니다. Microsoft가 SMB 클라이언트 측 NTLM 차단 기능을 마련한 이유도, 「악의적 서버에 NTLM 요청을 보내게 하는 수법을 막는다」고 설명되어 있습니다. ⁴

4. 감사 ── 어디에서 NTLM이 쓰이는지를 목록으로 만든다

여기가 본론입니다. Microsoft 가이드도, 제한 정책을 구현하기 전에 현재 NTLM 인증 트래픽 상태를 발견하고 감사하는 것이 필요하다고 명시합니다. ⁹

4.1. 감사 모드를 켠다

설정하는 것은 세 가지 정책입니다. 위치는 모두 컴퓨터 구성\Windows 설정\보안 설정\로컬 정책\보안 옵션이며, 재시작은 필요 없습니다. 로컬에 저장한 경우에도, 그룹 정책으로 배포한 경우에도, 설정이 적용된 시점에 유효해집니다. ⁷

다만 「재시작이 필요 없다」와 「바로 전 대에 적용된다」는 다른 이야기입니다. 도메인 GPO로 배포하는 경우, GPO를 저장한 시점에 갱신되는 것은 AD/SYSVOL 상의 정책뿐이며, 각 단말이 실제로 감사를 시작하는 것은 다음 백그라운드 갱신 또는 gpupdate /force를 친 뒤입니다. 감사 기간의 기점은 「GPO를 저장한 일시」가 아니라 「대상 단말에 적용이 퍼진 일시」로 세세요. 여기를 잘못 잡으면, 첫 한 번의 집계만 대상 대수가 적은 형태로 결과가 왜곡됩니다.

세 번째 「원격 서버로의 송신 NTLM 트래픽」에는 모두 허용 / 모두 감사 / 모두 거부 / 정의되지 않음의 네 값이 있으며, 정의되지 않음은 「모두 허용」과 같습니다. Microsoft 권장도 분명해서, 갑자기 「모두 거부」를 고르지 말고, 먼저 「모두 감사」로 두고 운영 로그를 확인한 뒤, 어느 서버가 인증 요청을 받는지 파악하고 나서 예외 목록을 만들어라, 입니다. ⁷

기록 위치는 이벤트 뷰어 > 애플리케이션 및 서비스 로그 > Microsoft > Windows > NTLM(Microsoft-Windows-NTLM/Operational)입니다. 이 감사에는 대응하는 보안 감사 이벤트 정책이 없으므로, 보안 로그가 아니라 이 채널을 봅니다. ⁷

현장에서 가장 혼동하기 쉬운 것이, 「어느 머신에, 어느 정책을 넣고, 어느 이벤트를 볼 것인가」의 대응입니다. 위 표의 세 정책을 ①②③으로 두고, 체크리스트로 만듭니다.

로그는 어느 머신이든 같은 Microsoft-Windows-NTLM/Operational입니다. ①은 도메인 컨트롤러에만 효과가 있고, ②③을 빠뜨린 단말은 「NTLM을 쓰지 않는 단말」이 아니라 「기록하지 않는 단말」이 됩니다. 이 차이가 집계를 왜곡하는 가장 큰 원인입니다.

주의: 감사 모드는 기록만 할 뿐 아무것도 차단하지 않습니다. 한편 대수가 많은 환경에서는 로그량이 한꺼번에 늘어납니다. 이벤트 수집(WEF)을 쓰지 않는 경우에는, 로그 크기 상한과 보존 기간을 먼저 검토한 뒤에 켜세요. Microsoft 가이드도, 환경 복잡도에 따라서는 분석에 수개월이 걸릴 수 있다고 합니다. ³

4.2. 추적은 「도메인 컨트롤러에서 아래로」

모인 이벤트를 어떻게 읽을지에는 정해진 순서가 있습니다. Microsoft 가이드가 보이는 추적 경로는 다음과 같습니다. ³

flowchart TD
    DC["도메인 컨트롤러<br/>이벤트 8004"]
    MS["멤버 서버<br/>이벤트 8003"]
    CL["클라이언트<br/>이벤트 8001"]
    APP["원인 애플리케이션"]

    DC -->|"보안 채널 이름 =<br/>조사할 서버"| MS
    MS -->|"워크스테이션 이름 =<br/>조사할 클라이언트"| CL
    CL -->|"클라이언트 프로세스 이름"| APP
    MS -.->|"PID가 4 (SYSTEM)이면<br/>SMB 경유"| CL

그림 1: NTLM 감사 이벤트의 추적 순서

각 이벤트에서 봐야 할 항목은 다음과 같습니다. ³

이 경로에서 특히 가치 있는 것은, 8001의 「대상 서버」와 「클라이언트 프로세스 이름」입니다. 전자는 「왜 Kerberos가 되지 않았는지」를, 후자는 「누가 원인인지」를 직접 알려 줍니다. Microsoft 가이드도, 이 정보로부터 사용자가 웹 서버의 IP 주소에 연결하고 있어, Kerberos를 쓸 수 있었을 NetBIOS 이름이나 FQDN을 쓰지 않고 있음을 특정할 수 있다고 설명합니다. ³

참고로, 도메인 컨트롤러에 8004가 나오지 않는 경우도 있습니다. 로컬 사용자 계정으로 파일 서버에 연결하는 경우, 그 인증은 도메인 컨트롤러를 거치지 않기 때문입니다. ³ 「DC 로그를 보니 적어서 괜찮다」고 판단해서는 안 됩니다.

4.3. PowerShell로 집계한다

이벤트 뷰어 GUI로 수천 건을 보는 것은 현실적이지 않으므로, Get-WinEvent로 모읍니다. 먼저, 그 머신에 어느 이벤트가 몇 건 나왔는지 확인합니다.

# NTLM/Operational 이벤트를 ID별로 집계한다(관리자 권한으로 실행)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-NTLM/Operational'
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue |
    Group-Object Id |
    Sort-Object Count -Descending |
    Select-Object Count, @{ N = 'EventId'; E = { $_.Name } }

이벤트가 나온 것을 확인한 뒤, 클라이언트 측 8001을 「연결 대상 서버 × 호출 측 프로세스」로 묶습니다. 이벤트 필드 구성은 이벤트 ID마다 다르므로, 먼저 1건을 Format-List로 열어 구조를 확인한 뒤에 인덱스를 정하는 편이 안전합니다.

# 먼저 1건만 내용을 확인한다
$sample = Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-NTLM/Operational'
    Id      = 8001
} -MaxEvents 1

$sample | Format-List TimeCreated, Id, Message
# 구조화 필드를 볼 경우
([xml]$sample.ToXml()).Event.EventData.Data |
    Select-Object Name, '#text'

구조를 알면, XML의 Name 속성으로 꺼내 집계합니다. 속성 이름은 OS 버전에 따라 차이가 있으므로, 이름으로 꺼내는 편이 위치 지정보다 잘 깨지지 않습니다.

# 최근 7일의 8001을 「연결 대상 × 호출 측 프로세스」로 집계한다
$events = Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-NTLM/Operational'
    Id        = 8001
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue

$rows = foreach ($e in $events) {
    $data = @{}
    foreach ($d in ([xml]$e.ToXml()).Event.EventData.Data) {
        $data[$d.Name] = $d.'#text'
    }
    [pscustomobject]@{
        Time    = $e.TimeCreated
        # 실제로 있던 필드 이름만, 우선순위를 두고 고른다
        Target  = @('TargetName', 'TargetServer', 'ServerName') |
                  Where-Object { $data.ContainsKey($_) } |
                  ForEach-Object { $data[$_] } | Select-Object -First 1
        Process = @('ClientProcessName', 'ProcessName', 'ApplicationName') |
                  Where-Object { $data.ContainsKey($_) } |
                  ForEach-Object { $data[$_] } | Select-Object -First 1
    }
}

$rows | Group-Object Target, Process |
    Sort-Object Count -Descending |
    Select-Object Count, Name

마지막 집계는, Count(건수)와 Name(연결 대상, 호출 측 프로세스를 쉼표로 이은 것)의 두 열로 돌아옵니다. 즉 출력은 이 형태입니다(값은 설명을 위한 예입니다).

Count Name
----- ----
  412 192.168.1.10, System
  118 fileserver.corp.example.com, System
   57 192.168.1.24, MyBizApp.exe
    9 legacy-nas, System

봐야 할 것은 Name의 앞부분, 즉 연결 대상입니다. 행별 읽는 법은 다음과 같습니다.

건수의 절댓값 자체에는 큰 의미가 없습니다. 「IP 주소 대상 행이 상위에 왔는지」「실행 파일 이름까지 갈린 행이 몇 개인지」 두 점을 보세요. 전자는 고치면 확실히 줄어드는 의존이고, 후자는 담당자를 붙일 수 있는 의존입니다.

필드 이름은 OS 버전에 따라 차이가 있으므로, 후보를 우선순위 있는 배열로 늘어놓고, 실재하는 것만 고르는 형태로 되어 있습니다. 여기서 -match 'Process' 같은 부분 일치를 쓰면, ClientProcessId 같은 PID 필드까지 걸려, 실행 파일 이름이 아니라 매번 바뀌는 PID로 집계해 버리는 일이 있습니다(해시 테이블 키 순서는 정해져 있지 않아, 어느 쪽이 잡힐지도 안정되지 않습니다). Process 열이 전부 비면, 후보 이름이 실제 스키마와 맞지 않는다는 신호이므로, 앞 단계에서 확인한 이름을 배열에 더하세요.

여러 대에서 모은다면, PowerShell Remoting으로 병렬로 돌리는 편이 빠릅니다(「PowerShell Remoting(WinRM) 입문」). Get-WinEvent의 필터는 -FilterHashtable을 쓰는지에 따라 소요 시간이 자릿수가 달라지므로, 그 요령은 「Get-WinEvent로 이벤트 로그를 실무적으로 조사한다」에 정리했습니다.

4.4. 보안 로그 쪽에서 본다 ── NTLMv1이 아직 쓰이지 않는지

NTLM/Operational과는 별도로, 보안 로그의 로그온 이벤트에서 NTLM 버전을 확인하는 방법도 있습니다. 절차는, 보안 로그에서 「인증 패키지」를 검색하고, 각 이벤트의 「자세한 인증 정보」를 보는 것입니다. ³

상세한 인증 정보:
    로그온 프로세스:          NtLmSsp
    인증 패키지:             NTLM
    전환된 서비스:         -
    패키지 이름 (NTLM만):   NTLM V1
    키 길이:                 128

이 「패키지 이름 (NTLM만)」이, NTLM 프로토콜 군 중 어느 서브프로토콜이 쓰였는지를 가리킵니다. ³ NTLM V1이 나온 호스트는, 그대로 Windows 11 24H2 / Windows Server 2025로 올리면 인증이 통과하지 않게 되는 후보입니다. NTLMv1은 이들 버전에서 삭제되어 있기 때문입니다. ¹ 감사를 돌릴 때, 이 관점만은 우선순위를 올려 잡으세요.

4.5. PID가 4(SYSTEM)뿐이라 진행이 안 될 때

감사를 시작하면, 거의 반드시 이 벽에 부딪힙니다. SMB(공유 폴더)처럼 리디렉터 경유로 통신하는 앱에서는, 인증을 요청하는 주체가 커널 모드 리디렉터가 되므로, 이벤트에 남는 PID는 항상 4(SYSTEM)가 됩니다. ³

Microsoft 가이드가 보이는 대처는 다음과 같습니다. ³

1. NTLM 자격 증명을 보내는 클라이언트(8001의 「컴퓨터」)에, 프로세스 감시 도구를 넣는다.
2. 상대 서버의 컴퓨터 이름과 IP 주소 둘 다로 경로를 필터한다. 장시간 채취가 필요하면 백그라운드 모드로 돌린다.
3. 채취 결과를, 서버 측 이벤트 8003의 타임스탬프와 맞춘다. 사용자·경로·인증 식별자가 대응하므로, 거기서 호출한 애플리케이션을 특정할 수 있다.

도구는 Process Monitor(ProcMon)입니다. 필터 거는 법과 읽는 법은 「Process Monitor(ProcMon) 실전 가이드」에 정리되어 있습니다.

실무적인 요령을 하나 더하면, 이 단계까지 이벤트 로그만으로 「어느 단말인지」를 좁힌 뒤에, 그 단말 한 대에만 ProcMon을 거는 것이 압도적으로 빠릅니다. 전 대에 ProcMon을 배포하는 것은 현실적이지 않습니다.

5. NTLM으로 fallback하는 전형적인 패턴

감사로 장소를 알았으면, 다음은 원인 분류입니다. Microsoft 가이드는, 이론상으로는 Kerberos를 지원해도, NTLM을 쓰게 되는 애플리케이션으로 다음 네 가지를 듭니다. ³

• 다양한 보안 구성이나 공급자를 고를 수 있는 애플리케이션
• SPN(서비스 주 이름)이 올바르게 구성되지 않은 애플리케이션
• 설정 실수나 벤더 문서 때문에, DNS 이름이 아니라 IP 주소를 쓰는 애플리케이션
• 레거시 코드 베이스를 갖고, NTLM 전용 부분이 남은 애플리케이션

Microsoft 일본 지원 블로그는, NTLM이 쓰이는 대표적인 원인으로, IP 주소 지정으로의 서버 접근, Kerberos에 필요한 포트의 방화벽에 의한 제한, SPN 미등록, 트러스트 관계 상대로의 인증, 작업 그룹 환경에서의 인증을 듭니다. ²

이를 현장에서 만나는 형태로 정리하면 다음 표가 됩니다. 오른쪽 두 열은 우선순위를 매기기 위한 기준입니다. 「영향 범위」는 멈췄을 때 곤란한 넓이, 「수정 용이성」은 자사 판단만으로 고칠 수 있는지를 나타냅니다. 이 둘이 있으면, 그대로 계획서의 착수 순서가 됩니다.

착수 순서는, 이 두 열에서 기계적으로 정해집니다.

1. 영향 범위와 관계없이 최우선은, NTLMv1만 말할 수 있는 기기와 NTLM V1이 기록된 호스트입니다(4.4절). 여기만은 「기한이 이미 왔다」기 때문이며, 우선순위 계산 밖에 둡니다. ¹
2. 다음이 영향 범위=대 그리고 수정 용이성=고, 즉 IP 주소 직접 입력입니다. 건수가 많고, 자사 판단만으로 고칠 수 있습니다. 첫 한 달은 여기에 집중하세요.
3. 그다음이 수정 용이성=중인 SPN 관련. 이름 통일과 세트로 진행합니다.
4. 수정 용이성=저인 것(기기 의존, 경로, 2단계 대기)은, 착수가 늦는 것이 아니라 리드 타임이 길 뿐이므로, 벤더 조회와 예산 확보만은 1~3과 병행해 먼저 시작합니다.

「바로 고칠 수 있다」와 「SPN 등록으로 고친다」로 분류된 것이, 감사 결과의 대부분을 차지할 것입니다. 여기를 없애는 것만으로, 남는 예외는 상당히 적어집니다.

6. 고치는 법 판단 표

7. SMB의 NTLM 차단 ── 현장 확인의 최단 경로

감사 로그는 「쓰이고 있다」는 것은 알려 주지만, 「멈추면 어떻게 되는지」는 알려 주지 않습니다. 여기서 도움이 되는 것이, Windows Server 2025와 Windows 11 버전 24H2에서 추가된, SMB 클라이언트 측 NTLM 차단입니다. ⁴

이 기능은, SMB 클라이언트가 원격으로의 송신 연결에서 NTLM 인증을 쓰는 것을 차단합니다. Microsoft는, 이로써 악의적 서버로 NTLM 요청을 보내게 하는 수법을 막고, 무차별 대입·크래킹·Pass-the-Hash 공격에 대항할 수 있다고 하며, 나아가 조직의 인증 프로토콜을 Kerberos로 전환하는 데 NTLM 차단이 필요하다고 위치 짓습니다. 동시에, NTLM을 완전히 사용 안 함으로 두지 않아도 이 보호 계층만 켤 수 있다고도 적습니다. ⁴

전제 조건은 다음 두 가지입니다. ⁴

• SMB 클라이언트가 Windows Server 2025 이후, 또는 Windows 11 버전 24H2 이후일 것
• 연결 대상 SMB 서버가 Kerberos를 쓸 수 있을 것(SMB 서버 측 OS는, PKU2U 또는 Kerberos를 쓸 수 있는 것이면 무엇이든 좋다)

7.1. 먼저 한 대·한 연결만 시험한다

갑자기 정책을 배포하지 말고, 연결 단위로 차단을 지정할 수 있다는 점을 씁니다. 이것이 현장 확인의 최단 경로입니다.

# 그 연결만 NTLM을 금지하고 연결해 본다(연결되면, 그 공유는 NTLM 없이 충분하다)
NET USE \\fileserver.corp.example.com\share /BLOCKNTLM

# PowerShell 매핑에서도 같은 일을 할 수 있다
New-SmbMapping -RemotePath \\fileserver.corp.example.com\share -BlockNTLM $true

연결되면, 그 경로는 NTLM 없이 성립한다는 뜻입니다. 실패하면, 거기가 NTLM 의존 지점입니다. 정책을 전혀 바꾸지 않고, 한 연결씩 「운영에서 멈출지」를 확인할 수 있으므로, 감사 로그의 교차 확인에 맞습니다.

결과 확인처는 세 곳입니다. (1)연결 성패는 명령 결과 그 자체이며, 성공하면 매핑이 만들어져 net use 목록과 Get-SmbConnection -ServerName <서버이름>에 나타나고, 실패하면 오류로 끝나 매핑은 남지 않습니다. (2)정말 NTLM 원인인지는, 아래 절차 3(플래그 없이 연결)과 짝을 지어 판단합니다. 플래그 없이라도 실패하면 다른 문제입니다. (3)무엇으로 인증했는지까지 확정하고 싶다면, 이 절 마지막에서 말하는 방법(klist와 서버 측 보안 로그)을 씁니다. 오류 메시지 문구만으로 NTLM 의존이라고 단정하지 마세요.

다만, 이 확인에는 절차가 필요합니다. 생각 없이 실행하면, 양쪽으로 오판합니다.

$server = 'fileserver.corp.example.com'

# 1. 그 서버로의 매핑을 「하나도 남김없이」 뺀다
#    다른 공유가 하나라도 남아 있으면, 서버 단위 세션이 계속 살아 있다
net use | Select-String $server              # 먼저 무엇이 연결되어 있는지 본다
net use \\$server\share  /delete
net use \\$server\other  /delete             # 같은 서버의 다른 공유도 모두

# 2. 세션이 정말 사라진 것을 확인한다(빌 때까지 다음으로 가지 않는다)
Get-SmbConnection -ServerName $server

# 3. 먼저 플래그 없이 연결되는지를 확인한다(여기서 실패하면 NTLM 이외의 문제)
net use \\$server\share
net use \\$server\share /delete
Get-SmbConnection -ServerName $server        # 여기에서도 비게 되돌린다

# 4. 그다음에 /BLOCKNTLM을 붙여 시험한다
net use \\$server\share /BLOCKNTLM

• 절차 1~2가 필요한 이유: SMB 세션은 공유 단위가 아니라 서버 단위입니다. 그 서버로의 인증된 세션이 남아 있으면, 리디렉터는 인증을 다시 하지 않고 그것을 재사용합니다. /BLOCKNTLM이 먹히는 것은 그 매핑을 위해 이루어지는 인증만이며, 이미 확립된 세션(NTLM으로 맺어졌을 수 있는 것)을 거슬러 검증하지는 않습니다. 즉, 테스트 대상 공유만 /delete해도 충분하지 않습니다. 같은 서버의 다른 공유가 연결된 채로면, NTLM 의존이 있는데도 성공해 버립니다. Get-SmbConnection이 아무것도 반환하지 않는 상태까지 떨어뜨리세요. 자신의 매핑 말고도, 상주 앱이나 백업 작업이 세션을 잡고 있는 경우가 있습니다. 확실히 하려면, 그 서버에 한 번도 연결하지 않은 단말에서 시험하는 것이 가장 빠릅니다.
• 절차 3이 필요한 이유: 이름 확인 실패, 자격 증명 오류, 공유 자체에 대한 접근 권한 부족이어도 /BLOCKNTLM을 붙인 실행은 실패합니다. 플래그 없이라도 실패하면, 그것은 NTLM 의존이 아니라 다른 문제입니다.

여기서 말할 수 있는 것은 「NTLM을 필요로 하지 않았다」까지이며, 「Kerberos로 인증되었다」까지는 말할 수 없다는 점에 주의하세요. 이 기능의 전제 조건은 「Kerberos를 쓸 수 있는 SMB 서버」이지만, 연결 대상은 PKU2U를 쓸 수 있는 OS여도 된다고 되어 있습니다. ⁴ 즉 성공 이유가 Kerberos가 아니라 PKU2U일 가능성이 남습니다. 도메인 가입된 파일 서버가 상대라면 우선 문제가 되지 않지만, 실제로 무엇으로 인증했는지까지 확정하고 싶을 때는, 연결 후 클라이언트에서 klist를 실행해 해당 서버의 cifs/ 티켓이 취득되었는지를 보거나, 서버 측 보안 로그에서 로그온 이벤트의 인증 패키지(4.4절)를 확인하세요.

7.2. 단말 단위로 켠다

교차 확인이 끝나면, 파일럿 단말에서 단말 전체 차단으로 진행합니다. ⁴

# SMB 클라이언트 전체에서 NTLM을 차단한다(관리자 권한)
Set-SmbClientConfiguration -BlockNTLM $true

그룹 정책의 경우에는 컴퓨터 구성 > 관리 템플릿 > 네트워크 > Lanman 워크스테이션의 「NTLM 차단 (LM, NTLM, NTLMv2)」을 사용으로 둡니다. ⁴

7.3. 어떻게든 남는 상대는 예외 목록으로

도메인에 가입하지 않은 SMB 서버 등, 어떻게든 NTLM이 필요한 상대는 예외로 둘 수 있습니다. 그룹 정책의 Lanman 워크스테이션 > NTLM 서버 예외 목록 차단을 사용으로 두고, 허용할 상대의 IP 주소·NetBIOS 이름·FQDN을 나열합니다. ⁴

예외 목록 자체를 만드는 PowerShell cmdlet은 준비되어 있지 않으므로, 처음은 그룹 정책 편집기에서 설정해야 하지만, 일단 만든 뒤의 개별 추가는 레지스트리 조작으로 할 수 있습니다. ⁴

# 기존 예외 목록에 항목을 추가한다
$params = @{
  Path = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\LanmanWorkstation"
  Name = "BlockNTLMServerExceptionList"
}
$Entries = "192.168.10.10", "corp.contoso.com", "CORP"

$CurrentValue = (Get-ItemProperty @params -ErrorAction SilentlyContinue).BlockNTLMServerExceptionList
$params["Value"] = if ($null -eq $CurrentValue) { $Entries }
                   else { $CurrentValue + $Entries }
Set-ItemProperty @params

주의: Microsoft 문서에 실린 샘플은, 값이 아직 없는 경우의 분기가 @("")를 설정하는 것뿐이라, 추가하려던 항목이 그대로 버려집니다. ⁴ 첫 실행에서는 예외가 한 건도 들어가지 않고, 두 번째 실행에서야 들어가는 동작이 되므로, 위의 코드에서는 미작성인 경우에도 추가 대상을 그대로 쓰도록 했습니다. 그렇다고 해도, 원래 이 레지스트리 값은 그룹 정책이 관리하는 영역입니다. 항구적인 예외는 그룹 정책 쪽에서 관리하고, 이 조작은 긴급 시의 일시 대응에 그쳐 주세요. 다음 정책 적용에서 덮어쓰입니다.

주의: 이 기능은 SMB 클라이언트 측 기능입니다. ⁴ SMB 이외의 경로(자체 앱의 HTTP 통신, SQL Server로의 연결, WinRM 등)에서의 NTLM은, 이것으로는 멈추지 않습니다. 그쪽은 5장의 분류에 따라 개별적으로 없애야 합니다.

8. 개발자가 보는 NTLM ── Negotiate를 쓴다

자체적으로 Windows 앱을 만드는 경우, 고칠 곳은 분명합니다. Microsoft는 다음과 같이 명시합니다. ⁵

애플리케이션은 NTLM 보안 패키지에 직접 접근해서는 안 됩니다. 대신 Negotiate 보안 패키지를 써야 합니다. Negotiate는, 인증에 관여하는 시스템이 지원하면, 더 고도의 보안 프로토콜을 쓸 수 있게 합니다. 현재 Negotiate 보안 패키지는 Kerberos와 NTLM 중 하나를 선택합니다. Negotiate는, 인증에 관여하는 시스템 중 어느 하나라도 Kerberos를 쓸 수 없는 경우를 제외하고, Kerberos를 선택합니다.

즉 「NTLM」이라고 적힌 곳을 「Negotiate」로 바꾸는 것이 원칙입니다. 사용 중단 기능 목록의 서술도 같아서, NTLM 호출은 Negotiate 호출로 바꿔야 한다고 되어 있습니다. ¹

8.1. .NET에서 흔한 「NTLM 지정」

// 나쁜 예: 인증 유형에 NTLM을 지정한다
var credential = new NetworkCredential(user, password, domain);
var cache = new CredentialCache();
cache.Add(new Uri("http://intra.example.local/"), "NTLM", credential);

var handler = new HttpClientHandler { Credentials = cache };

// 좋은 예: 바꾸는 것은 인증 유형만. 자격 증명은 그대로 넘긴다
var credential = new NetworkCredential(user, password, domain);
var cache = new CredentialCache();
cache.Add(new Uri("http://intra.example.local/"), "Negotiate", credential);

var handler = new HttpClientHandler { Credentials = cache };

여기서 바꾸는 것은 인증 유형 문자열뿐입니다. credential을 CredentialCache.DefaultNetworkCredentials로 바꾸면, 인증 프로토콜만이 아니라 인증하는 주체까지 바뀝니다. 지정하던 계정이 아니라, 그 프로세스를 실행하는 계정(서비스 계정이나 로그온 중인 사용자)으로 인증하러 가게 되어, 연결 대상의 권한 설정에 따라서는 동작하지 않게 됩니다. 프로토콜 교체와 자격 증명 재검토는, 별개의 변경으로 나눠 진행하세요.

한편, 애초에 로그온 중인 사용자의 자격 증명으로 인증하고 싶다면(통합 Windows 인증) 더 단순하게 쓸 수 있습니다. 이쪽은 「누구로서 인증할지」를 의도적으로 바꾸는 경우의 쓰는 법입니다.

// 통합 Windows 인증(현재 로그온 사용자로 인증한다)
var handler = new HttpClientHandler
{
    UseDefaultCredentials = true,
};

HttpClient 자체의 다루기(using으로 감싸지 않기, 생성 패턴, 타임아웃 설계)는 「HttpClient를 using으로 감싸지 마라」에 정리했습니다.

SSPI를 직접 다뤄야 하는 경우에는, .NET 7 이후 추가된 System.Net.Security.NegotiateAuthentication을 쓰면, Negotiate를 통한 인증을 매니지드 코드에서 다룰 수 있습니다. 여기에서도 패키지 이름에 NTLM을 지정하지 않는 것이 요점입니다.

8.2. 코드보다 먼저 봐야 할 「연결 대상 쓰는 법」

코드를 고쳐도, 연결 대상이 IP 주소인 채로면 결국 NTLM으로 fallback합니다. 기본에서는, 호스트 이름이 IP 주소인 경우 Windows는 그 호스트에 대해 Kerberos 인증을 시도하지 않고, NTLM 등 유효한 다른 프로토콜로 fallback하기 때문입니다. ¹⁰ 구체적으로는 다음을 훑으세요.

• 설정 파일(appsettings.json, App.config, ini 파일)에 적힌 서버 이름
• SQL Server 연결 문자열의 서버 지정(Data Source)
• UNC 경로를 조립하는 곳. 하드코딩된 IP 주소가 없는지
• 설치 프로그램이나 초기 세팅 절차서의 기본값
• 과거 장애 대응에서 「이름 확인이 불안정해서」 IP로 바꿔 두고 되돌리지 않은 곳

마지막 항목은 정말 자주 발견됩니다. IP 주소 직접 입력은, 당시에는 올바른 응급 처치였지만, 지금은 기술 부채입니다.

8.3. 서비스 측을 만들고 있다면

자체 Windows 서비스나 IIS 앱을 Kerberos로 받고 싶은 경우에는, 티켓을 복호화하는 계정에, 클라이언트가 접근에 쓰는 이름으로 SPN을 등록하는 것이 필요합니다. SPN이 등록되지 않은 애플리케이션은, Kerberos 대응을 내세워도 NTLM으로 fallback한다는, 대표적인 예로 Microsoft 자신이 들고 있는 그대로입니다. ³

등록처를 「서비스를 실행하는 계정」으로 단순하게 생각하면, IIS에서 막힙니다. IIS의 Windows 인증은 기본으로 커널 모드 인증이 켜져 있고, 이때 Kerberos 티켓을 복호화하는 것은 애플리케이션 풀 ID가 아니라 HTTP.sys가 쓰는 머신 계정입니다. 전용 도메인 계정으로 애플리케이션 풀을 돌리고 있다고 해서, 그 계정에 사이트의 HTTP SPN을 등록하면, SPN 소유자와 실제로 복호화하는 계정이 어긋나, NTLM으로 fallback하는 정도가 아니라 KRB_AP_ERR_MODIFIED로 인증 자체가 실패합니다.

요점은 「SPN 등록처와, 티켓을 복호화하는 ID를 일치시키는」 것입니다. 취할 수 있는 형태는 다음 두 가지입니다.

• 머신 계정으로 복호화한다(기본 그대로): 사이트를 호스트 이름으로 공개한다면, 그 호스트 이름의 HTTP SPN을 머신 계정에 등록한다.
• 애플리케이션 풀 ID로 복호화한다: useAppPoolCredentials를 켠 뒤에, HTTP SPN을 애플리케이션 풀 계정에 등록한다.

어느 쪽을 고를지는, 여러 서버에서 같은 서비스 계정을 공유하는지(공유한다면 풀 ID로 맞추는 형태가 다루기 쉽다)로 정해집니다. 참고로 SPN은 하나의 계정에만 등록할 수 있으므로, 전환할 때는 옛 등록 삭제를 잊지 마세요. 중복 등록은 Kerberos 인증 자체를 깨뜨립니다.

클라이언트를 가장해 다른 서버로 접근하는 설계(위임)를 쓰는 경우에는, NTLM과 Kerberos에서 다루기가 바뀝니다. Kerberos는, 서비스가 클라이언트의 대리로서 다른 서비스에 연결하는 위임 메커니즘을 지원하지만, NTLM이 제공하는 것은 로컬에서의 가장에 필요한 권한 부여 정보까지입니다. ⁸ 가장 주변의 구현은 「Windows의 가장(Impersonation)과 토큰」에서 다룹니다.

9. 단계적으로 조여 가는 로드맵

이상을 정리하면, 진행 방법은 다음 순서가 됩니다. 어느 단계든 「되돌릴 수 있다」가 조건입니다.

9.1. SMB를 멈춰도, 그것은 NTLM 대책의 절반

단계 4~6이 다루는 것은 SMB뿐입니다. 7장에서 말한 대로, SMB 클라이언트의 NTLM 차단은 SMB 클라이언트 측 기능이며, ⁴ 그 이외의 경로에는 효과가 없습니다. 단계 2에서 「HTTP로 인증한다」「SQL Server가 NTLM이다」「WinRM이 NTLM을 쓴다」고 분류한 것은, 단계 6까지 진행해도 손대지 않은 채로 남습니다. 게다가 SMB 예외 목록에도 실리지 않으므로, 건수를 세어도 보이지 않습니다.

거기를 조이는 것이 단계 6b입니다. 쓰는 것은 4장에서 감사 모드로 둔, 그 세 정책 그 자체입니다. 절차는 같은 형태를 따릅니다. ¹¹

1. 「원격 서버로의 송신 NTLM 트래픽」을 모두 감사인 채로, 남은 연결 대상을 파악한다
2. 어떻게든 필요한 상대를 「원격 서버 예외를 추가한다」에 등록한다
3. 파일럿 단말에서 모두 거부로 바꾸고, 업무가 한 바퀴 돌기를 기다린다
4. 문제가 없으면 전개한다

도메인 전체에 대해서는 「이 도메인에서의 NTLM 인증」을, 마찬가지로 감사 → 예외(「이 도메인에서의 서버 예외를 추가한다」) → 거부 순으로 진행합니다. ¹² Microsoft도, 거부 옵션을 고르기 전에 대응하는 감사 정책을 같은 옵션으로 설정해 영향을 평가해야 한다고 합니다. ¹²

「SMB를 차단했으니 NTLM 대책은 완료」가 아닙니다. 완료 지표로 삼는다면, SMB 예외 목록과 Restrict NTLM의 서버 예외 목록 둘 다를 세세요.

9.2. 감사 기간은 「일수」가 아니라 「업무의 한 바퀴」로 정한다

단계 1에서 가장 실패하기 쉬운 것이, 기간 정하는 법입니다. 「2주 모았으니 완료」로 두면, 그 2주에 돌지 않은 처리는 목록에 실리지 않습니다. 그리고 실리지 않은 것은, 단계 6에서 차단을 배포한 뒤에야 처음 깨집니다.

구체적으로 빠지기 쉬운 것은 다음과 같습니다.

• 월차·분기 마감 처리. 월말 배치가 공유 폴더나 DB에 IP 주소 직접 입력으로 연결한다, 는 전형입니다.
• 연차 처리. 재고 조사, 연도 전환, 결산 관련.
• 장애 시에만 통과하는 경로. 백업에서의 복구 절차, 대체 서버로의 전환, DR 훈련.
• 장기간 오프라인인 단말. 반출 PC, 장기 휴가 중인 담당자 단말, 평소 전원이 꺼진 예비기.
• 1년에 몇 번만 쓰는 업무 앱.

Microsoft 가이드 자신도, 분석은 배포 복잡도에 따라서는 수개월에 이를 수 있다고 합니다. ³ 현실적인 선은 다음 중 하나입니다.

1. 업무가 한 바퀴 돌 때까지 감사를 계속 돌린다. 최소한 월차 마감을 한 번, 가능하면 분기를 넘긴다.
2. 저빈도 처리를 파악해, 의도적으로 실행한다. 기간을 기다릴 수 없는 경우에는, 마감 처리나 DR 절차를 검증 환경에서 돌리고, 그 결과를 목록에 더한다. 「실행하지 않아서 나오지 않았을 뿐」인 처리를, 담당자 청취로 먼저 나열해 두는 것이 요점입니다.

어느 쪽이든, 「이벤트가 나오지 않았다」와 「아직 실행되지 않았다」를 구별할 수 있는 상태로 만든 뒤에 다음 단계로 가세요.

9.3. 한꺼번에 거부로 돌리지 않는다

여기서 「송신 NTLM 트래픽=모두 거부」로 한꺼번에 돌리지 않는 것이 요점입니다. Microsoft도, 이 정책을 거부로 설정하면 다수의 NTLM 인증 요청이 실패해 생산성을 떨어뜨릴 수 있으므로, 구현 전에 「모두 감사」로 로그를 확인하고, 서버를 분석하고, 제외할 예외 목록을 만들어야 한다고 합니다. ⁷ 도메인 전체를 대상으로 하는 「이 도메인에서의 NTLM 인증」 정책에 대해서도 같은 경고가 적혀 있습니다. ¹²

10. 정리

• NTLM은 2024년 6월에 모든 버전이 사용 중단이 되었습니다. 즉시 정지하는 변경이 아니라, 차기 Windows Server·다음 연간 릴리스의 Windows에서도 계속 동작한다고 되어 있습니다. ¹
• 한편 NTLMv1은 이미 삭제되어 있습니다(Windows 11 24H2 / Windows Server 2025). NTLMv1만 말할 수 있는 기기와, NTLM V1이 기록된 호스트가, 가장 가까운 기한입니다. ¹
• 사용 중단은 3단계이며, 1단계는 감사, 2단계(2026년 후반)가 IAKerb와 로컬 KDC, 3단계가 기본 사용 안 함입니다. ²
• 감사는 세 정책을 감사 모드로 두고 Microsoft-Windows-NTLM/Operational을 모읍니다. 도메인 계정이라면 DC의 8004 → 멤버 서버의 8003 → 클라이언트의 8001 순으로, 마지막에 앱 이름까지 닿습니다. 로컬 계정으로의 인증은 8004가 나오지 않으므로, 서버와 클라이언트의 이벤트에서 잡습니다. ³⁷
• SMB 경유는 PID가 항상 4(SYSTEM)가 됩니다. 이벤트 로그로 단말까지 좁힌 뒤에, 그 한 대를 ProcMon으로 추적하세요. ³
• 원인의 대부분은 「이름」입니다. IP 주소 직접 입력과 SPN 미등록을 없애는 것만으로, 남는 예외는 크게 줄어듭니다. ³²
• NET USE \\server\share /BLOCKNTLM은, 정책을 바꾸지 않고 한 연결만으로 교차 확인할 수 있는, 가장 안전한 확인 수단입니다. ⁴
• 자체 앱은 NTLM 지정을 Negotiate로 바꾸고, 연결 대상 쓰는 법을 FQDN으로 맞춥니다. ⁵
• 예외 목록은 해결이 아니라 유예입니다. 건수가 매년 줄고 있는지를 지표로 하세요.

관련 기사

• 그림으로 이해하는 NTLM과 Kerberos ── 왜 인증은 NTLM으로 「fallback」하는가
• 네트워크 드라이브와 UNC 경로의 함정 ── 업무 앱에서 파일 서버(공유 폴더)를 다루는 실무
• Get-WinEvent로 이벤트 로그를 실무적으로 조사한다 ── 필터의 속도가 조사 시간을 정한다
• Process Monitor(ProcMon) 실전 가이드 ── 「설정이 읽히지 않는다」「ACCESS DENIED」를 10분 만에 특정한다
• PowerShell Remoting(WinRM) 입문 ── 여러 대의 Windows를 일괄 관리한다
• PowerShell에서 자격 증명의 안전한 다루기 ── 평문 비밀번호를 스크립트에서 몰아낸다
• WinForms/WPF 앱에 Entra ID 인증을 넣는다 ── MSAL.NET과 WAM 브로커의 실무 구성
• Windows의 TPM이란 무엇인가 ── 그림으로 이해하는 「키를 밖으로 내지 않는 금고」와 측정 부팅

관련 상담 영역

合同会社小村ソフト에서는, NTLM 의존 파악과 Kerberos 전제로의 이전에 따르는 업무 앱 수정, 인증 주변의 장애 조사를 다룹니다.

• Windows 앱 개발
• 장애 조사·원인 분석
• 기존 자산 활용·이전 지원
• 문의

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

NTLM이 사용 중단되면, 언제부터 업무가 멈춥니까?

「사용 중단(deprecated)」안내만으로는 아무것도 멈추지 않습니다. Microsoft는 2024년 6월에 NTLM의 모든 버전을 사용 중단으로 했지만, 그때의 안내는 「차기 Windows Server와 다음 연간 릴리스의 Windows에서도 NTLM 이용은 계속 동작한다」는 것이었습니다. 이미 동작하지 않게 된 구체적인 변경은, Windows 11 버전 24H2와 Windows Server 2025에서의 NTLMv1 삭제입니다. 향후 릴리스에서 네트워크 NTLM이 기본으로 사용 안 함이 되는 계획은 공개되어 있지만, 그 시점에도 정책으로 다시 켤 수 있다고 되어 있습니다. 즉 「어느 날 갑자기 회사 전체가 멈춘다」 종류의 변경이 아니라, OS를 새로 올릴 때마다 조금씩 조여 가는 종류의 변경입니다. 그래서 멈춘 뒤에 조사하는 것이 아니라, 아직 NTLM이 동작하는 동안에 감사 로그로 의존 지점을 파악해 두는 것이 유일한 현실적인 대비입니다.

NTLM을 쓰는 곳은, 어떻게 목록으로 만들 수 있습니까?

그룹 정책의 「네트워크 보안: NTLM을 제한한다」계열 설정을 감사 모드로 두고, NTLM/Operational 로그를 모읍니다. 도메인 컨트롤러에 「이 도메인에서의 NTLM 인증을 감사한다」, 서버와 클라이언트에 「수신 NTLM 트래픽을 감사한다」와 「원격 서버로의 송신 NTLM 트래픽=모두 감사한다」를 설정하면, 이벤트 뷰어의 「애플리케이션 및 서비스 로그 > Microsoft > Windows > NTLM」에 이벤트가 기록됩니다. 도메인 계정으로의 인증이라면, 추적 순서는 도메인 컨트롤러의 이벤트 8004에서 사용자와 연결 대상 서버(보안 채널 이름)를 특정하고, 그 서버의 이벤트 8003에서 프로세스 ID를 본 뒤, 마지막으로 클라이언트의 이벤트 8001에서 「어느 앱이, 어느 서버 이름으로」요청했는지를 확정하는 순서입니다. 이벤트 8001에는 대상 서버 이름과 클라이언트 프로세스 이름이 들어가므로, 여기까지 오면 원인 앱을 알 수 있습니다. 다만 로컬 계정으로의 인증은 도메인 컨트롤러를 거치지 않으므로 8004가 나오지 않습니다. 작업 그룹 기기나 파일 서버의 로컬 계정으로 공유에 연결하는 경로는, 서버 측 8003과 클라이언트 측 8001에서 잡아야 합니다. 도메인 컨트롤러 로그만 보고 「우리는 적다」고 판단하지 마세요.

감사했더니 이벤트의 PID가 4(SYSTEM)뿐이라, 어느 앱인지 모르겠습니다.

SMB(공유 폴더) 경유 통신이기 때문입니다. SMB 인증은 커널 모드의 리디렉터가 수행하므로, 호출한 앱은 SMB 패킷 반대편에 가려져 이벤트에 남는 PID는 항상 4(SYSTEM)가 됩니다. Microsoft 가이드도 이 경우를 명시하고 있으며, 대처로 이벤트가 나온 클라이언트에서 Process Monitor(ProcMon)를 돌리고, 상대 서버의 컴퓨터 이름과 IP 주소로 경로를 필터한 뒤, 서버 측 이벤트 8003의 타임스탬프와 맞춰 호출 측 프로세스를 특정하라고 안내합니다. 실무에서는 먼저 「어느 단말인지」까지를 이벤트 로그로 좁힌 다음, 그 단말만 ProcMon으로 추적하는 편이 빠릅니다.

Kerberos를 지원할 앱이 NTLM으로 fallback하는 이유는 무엇입니까?

거의 모두 이름 문제입니다. Microsoft 가이드는, 이론상으로는 Kerberos를 지원해도 NTLM을 쓰게 되는 앱으로, 보안 구성이나 공급자를 고를 수 있는 앱, SPN(서비스 주 이름)이 올바르게 등록되지 않은 앱, 설정 실수나 벤더 절차서 때문에 DNS 이름이 아니라 IP 주소로 연결하는 앱, 레거시 코드 베이스에 NTLM 전용 부분이 남은 앱, 네 가지를 들고 있습니다. 이벤트 8001의 「대상 서버」가 NetBIOS 이름도 FQDN도 아닌 형식(즉 IP 주소)이면, 기본 구성에서는 Kerberos가 쓰이지 않습니다. IP 주소 직접 입력을 FQDN으로 고치고, 별칭으로 접근하고 있다면 그 이름으로 SPN을 등록하는 것이 먼저 할 두 가지입니다. 참고로, 어떻게든 이름으로 바꿀 수 없는 경우에 대비해, 클라이언트에 TryIPSPN을 설정하고 IP 주소의 SPN을 수동 등록하는 방법도 준비되어 있지만, Microsoft 자신이 DNS 이름으로의 변경이 불가능한 경우에 한정해야 한다고 하므로, 어디까지나 최후의 수단입니다.

직접 만드는 Windows 앱은, 무엇을 고치면 됩니까?

인증 패키지에 NTLM을 지정한 곳을 Negotiate로 바꿉니다. Microsoft는 「애플리케이션은 NTLM 보안 패키지에 직접 접근해서는 안 되며, Negotiate 패키지를 써야 한다」고 명시합니다. Negotiate는 Kerberos와 NTLM 중 하나를 고르며, 인증에 관여하는 시스템 중 어느 하나라도 Kerberos를 쓸 수 없는 경우를 제외하고 Kerberos를 고릅니다. .NET이라면, CredentialCache.Add에 넘기는 인증 유형을 "NTLM"에서 "Negotiate"로 바꾸는 것이 전형적인 수정입니다(인증 유형을 지정하는 것은 CredentialCache.Add이며, NetworkCredential의 생성자가 아닙니다). 더불어, 연결 대상을 IP 주소나 hosts에 적은 별칭이 아니라 FQDN으로 지정하는 것, 자체 서비스를 Kerberos로 받으려면 그 서비스 계정에 SPN을 등록하는 것도 필요합니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.