IIS에서 NTLM 대신 Kerberos를 사용하는 이유는 무엇입니까?

이것은 내가 실제로 대답 할 수 없었던 것입니다. NTLM 대신 IIS에서 Kerberos 인증을 사용하면 어떤 이점이 있습니까?

나는 많은 사람들이 그것을 설정하기 위해 정말로 어려움을 겪는 것을 보았고 (나 자신을 포함하여) 그것을 사용하는 좋은 이유를 생각해 낼 수 없었다. 그래도 꽤 큰 장점이 있어야합니다. 그렇지 않으면 설정하는 데 모든 어려움을 겪을 가치가 없습니다.

Windows 관점에서만 :

NTLM

• 외부 (도메인이 아닌) 클라이언트 와 내부 클라이언트 모두에서 작동
• IIS 상자에서 도메인 계정 과 로컬 사용자 계정 모두에서 작동
  • 도메인 계정을 사용 하는 경우 서버 만 도메인 컨트롤러 (DC)에 직접 연결해야합니다.
  • 로컬 계정을 사용하면 어디서나 연결이 필요하지 않습니다. :)
  • 자격 증명을 사용하기 위해 해당 사용자로 로그온 할 필요가 없습니다.
  • 제외 : 직류가 NTLM 요청의 볼륨 바쁜 NTLM 서버 (IIS, 교환, TMG / ISA, 등)에 의해 압도되는 것이 아닌 그 드문 일이다 (완화 : MaxConcurrentAPI, AuthPersistSingleRequest(거짓)을 ., 빠른 DC가) ( 자가 추천 보너스 .)
• IIS 서버에 대해서만 클라이언트 연결이 필요 합니다 (사이트 포트에서 다른 것은 없습니다. 즉, 모든 것이 HTTP (또는 HTTPS)를 통해 발생합니다.)
• 지원하는 모든 프록시 통과 할 수 HTTP 연결 유지 들
  • TLS / SSL을 사용하여 다른 사람을 해결할 수 있습니다.
• 작은 패킷 으로 인증을 위해 여러 번 왕복 해야합니다.
  • (로그 패턴은 사용자 이름 이 401.2, 401.1, 200 임)
• 이중 홉 인증이 필요한 시나리오에서는 사용할 수 없습니다
  • 즉, 사용자의 자격 증명이 다른 컴퓨터의 서비스로 전달되어야합니다.
• 이전 클라이언트 지원 (<Win2000)
• LM 인증 수준 불일치에 취약 함 (일치하지 lmcompatibilitylevel않음)
• 커브가 실패하면 협상 패키지에서 대체로 사용됩니다.
  • ( " Kerb로 액세스가 거부 된 경우"가 아니라 NTLM을 사용 하려면 Curb가 중단 되어야합니다. 일반적으로 티켓을받지 않는 것처럼 보입니다. 클라이언트가 티켓을 받고 완벽하지 않으면 폴 백이 발생하지 않습니다.

Kerberos

• 작동 현재 도메인에 가입 된 클라이언트에만
  • AD DC (tcp / udp 88) 및 서버에 클라이언트 연결 필요 (티켓은 클라이언트가 Curb 포트를 통해 DC에서 검색 한 후 HTTP를 사용하여 서버에 제공)

• 수도 프록시를 통과하지만, 위의 DC 포인트를 볼 수 있습니다 : 당신은 여전히 서버를 수행, 활성 DC와 동일한 네트워크에 있어야합니다 .

  • 따라서 이론적 으로 인터넷에 연결된 클라이언트가 인터넷에 연결된 DC와 직접 채팅하는 도메인이 있다면 작동 할 수 있습니다. 그러나 당신이 이미 알지 못한다면 그렇게하지 마십시오 .
  • 리버스 프록시 시나리오 (ISA / TMG)에서 프로토콜 전환 서버는 클라이언트가 아닌 해당 네트워크에 있어야하지만 클라이언트는 실제로 Kerberos 비트를 수행하는 서버가 아닙니다 (필수-Forms auth to Curb 전이).

• 티켓은 수명이 긴되는 의미 (10H) 이하 DC 통신 티켓 수명 동안 - 그리고 강조 :이 요청의 수백만 수천을 절약 할 수 클라이언트에 따라 그 수명 기간 동안 - ( AuthPersistNonNTLM여전히 일; 의 Kerberos PAC 유효성 검사 일이 될하는 데 사용)

• 인증을 위해서는 단일 왕복이 필요 하지만 인증 페이로드 크기는 비교적 큽니다 (일반적으로 6-16K) ( 401 , {(encoded) token size} 200 )
• (항상 함께하시기 바랍니다 사용할 수 있습니다 제약 ) 대표 다음 서비스에 연결하는 사용자의 Windows 인증을 사용하려면
  • 예를 들어 UserAIIS에 액세스하고 IIS가 SQL Server에 액세스 할 때 동일한 사용자 계정을 사용하려면 "인증 위임"입니다.
  • ( 이 문맥에서 제한 되는 것은 Exchange 나 다른 SQL 상자와 같은 "아무것도"을 의미합니다)
• 현재 협상 인증을위한 기본 보안 패키지입니다.
  • 즉, Windows 도메인 구성원은 얻을 수있을 때 선호합니다
• SPN 등록이 필요 하며 까다로울 수 있습니다. 도움이되는 규칙 .
• IP 주소가 아닌 대상 으로 이름 을 사용해야 함
• 연석이 실패 할 수있는 이유 :
  • 이름 대신 IP 주소 사용
  • SPN 등록 안 됨
  • 중복 SPN 등록
  • 잘못된 계정에 등록 된 SPN ( KRB_ERR_AP_MODIFIED)
  • 클라이언트 DNS / DC 연결 없음
  • 클라이언트 프록시 설정 / 대상 사이트에 사용되지 않는 로컬 인트라넷 영역

우리가있는 동안 :

기본

• 멀티 홉 가능. 그러나 사용자 이름과 비밀번호 를 대상 웹 앱에 직접 노출 하면됩니다.
  • 그런 다음 원하는대로 할 수 있습니다. 아무것도 .
  • "오, 도메인 관리자가 내 앱을 사용 했습니까? 이메일을 읽었습니까? 비밀번호를 재설정 하시겠습니까? Awww. Pity "
• 필요 전송 계층 보안 보안 모든 형태 (예 : TLS / SSL)을.
  • 그런 다음 이전 문제를 참조하십시오
• 모든 브라우저에서 작동
  • (그러나 첫 번째 문제 참조 )
• 인증 하려면 단일 왕복이 필요 합니다 ( 401 , 200 )
• Windows가 기본 자격 증명으로 대화 형 로그온을 수행 할 수 있기 때문에 멀티 홉 시나리오에서 사용할 수 있습니다.
  • 필요가있다 LogonType이를 위해 구성 할 (2000 년과 2003 년 사이의 네트워크 일반 텍스트로 변경 기본을 생각하지만, misremembering 수 있습니다)
  • 그러나 다시 , 첫 번째 문제를 참조하십시오 .
  • 첫 번째 문제 가 정말로 중요하다는 인상을 받고 있습니까? 그것은.

요약하면 :

커브는 설정하기 까다로울 수 있지만 프로세스를 단순화하려고하는 가이드 ( 내 가이드 )가 많이 있으며 도구가 2003 년에서 2008 년까지 크게 개선되었습니다 ( SetSPN중복을 검색 할 수 있습니다. 이것은 가장 일반적인 주요 문제입니다) ; -A 사용 지침이 보이면 언제든지 사용SETSPN -S 하십시오.

제한된 위임은 입장료가 필요합니다.

• Kerberos는 NTLM보다 빠르고 안전한 인증 메커니즘으로 명성이 높습니다.
• 또한 NTLM의 연결 기반 특성으로 인해 역사적으로 NTLM보다 프록시 서버를 통해 연결하는 것이 더 쉽습니다.
• 즉, Kerberos를 시작하고 실행하기가 더 어려우며 항상 실용적이지 않은 AD에 연결해야합니다.

또 다른 방법은 인증을 설정하고 다른 인증 negotiate대신에 둘 모두를 사용하는 것입니다.

일반적인 개발자 실수를 감지 하는 Microsoft Application Verifier . 이러한 실수 중 하나는 NTLM을 사용하는 것입니다 .

NTLM은 응용 프로그램과 운영 체제의 보안을 손상시킬 수있는 결함이있는 오래된 인증 프로토콜입니다. 가장 중요한 단점은 서버 인증이 없기 때문에 공격자가 스푸핑 된 서버에 연결하도록 사용자를 속일 수 있습니다. 누락 된 서버 인증의 결과로 NTLM을 사용하는 응용 프로그램은 "반사"공격으로 알려진 공격 유형에 취약 할 수 있습니다. 후자는 침입자가 사용자의 인증 대화를 합법적 인 서버로 하이재킹하고이를 사용하여 사용자의 컴퓨터에 대한 침입자를 인증 할 수 있습니다. NTLM의 취약성과 취약성을 악용하는 방법은 보안 커뮤니티에서 연구 활동을 증가시키는 목표입니다.

Kerberos는 수년 동안 사용 가능했지만 많은 응용 프로그램이 여전히 NTLM 만 사용하도록 작성되었습니다. 이것은 응용 프로그램의 보안을 불필요하게 줄입니다. 그러나 Kerberos는 모든 시나리오에서 주로 NTLM을 대체 할 수 없습니다. 주로 클라이언트가 도메인에 가입되지 않은 시스템 (가장 일반적으로 사용되는 홈 네트워크)에 인증해야하는 시스템입니다. 협상 보안 패키지는 가능할 때마다 Kerberos를 사용하는 이전 버전과 호환 가능한 타협을 허용하며 다른 옵션이없는 경우에만 NTLM으로 되돌아갑니다. NTLM 대신 협상을 사용하도록 코드를 전환하면 응용 프로그램 호환성이 거의 또는 전혀없는 상태에서 고객의 보안이 크게 향상됩니다. 협상 자체는 은총 알이 아닙니다. 공격자가 NTLM으로 강제로 다운 그레이드 할 수 있지만 악용하기가 훨씬 더 어렵습니다. 그러나 협상을 올바르게 사용하도록 작성된 응용 프로그램은 NTLM 리플렉션 공격에 자동으로 영향을받습니다.

NTLM 사용에 대한 최종 경고로 향후 Windows 버전에서는 운영 체제에서 NTLM 사용을 비활성화 할 수 있습니다. 응용 프로그램이 NTLM에 대한 의존성이 높으면 NTLM을 사용할 수 없을 때 인증에 실패합니다.

매우 중요한 점을 추가해야합니다.

NTLM은 20 년 이상 유닉스에서 표준이자 개방형 프로토콜 인 반면 NTLM은 Microsoft의 독점 솔루션으로 Microsoft에만 알려져 있습니다.

iis 서버에없는 리소스에 액세스하려면 사용자를 가장해야하는 경우 Kerberos가 필요합니다.