Exchange 2007 계정 (SMTP/POP3/IMAP)에 로그인하기 위해 Windows 통합 인증 (현재 기록 된 Windows 사용자의 기본 자격 증명 사용)을 얻으려고합니다.NegotiateStream이 SASL (POP3/IMAP/SMTP)을 통해 Kerberos/NTLM/GSSAPI와 함께 작동하지 않습니까?
이미 구현되어 있지만 SSPI 기능을 사용하므로 관리되지 않는 코드 권한 (좋지 않음)이 필요합니다. 이것에 대해 NegotiateStream 클래스를 사용하려고했지만 작동하지 않습니다.
NegotiateStream을 POP3/IMAP/SMTP와 함께 직접 사용할 수 없습니다. 전체 대화의 모든 요청과 응답은 base64로 묶어야하며 메일 프로토콜 접미사 등으로 포위해야합니다. 따라서 자체 스트림 클래스 이 작업을 수행하고 NetworkStream과 NegotiateStream 사이에 삽입합니다. 그러나 NegotiateStream에서 생성 된 요청과 예상되는 응답이 성공적으로 사용 된 요청 (그리고 NTLM/GSSAPI 인증 일 수있는 다른 메일 클라이언트에서 생성 된 요청)과 다른 것으로 나타났습니다.
특히 NegotiateStream은 다른 구현에 의해 전송되지 않은 5 바이트 길이 요청을 먼저 보냅니다. 이 패킷은 Exchange에서 "프로토콜 오류"메시지와 함께 거부됩니다.
NegotiateStream에서 만든 두 번째 요청이 올바른 것입니다 (NTLMSSP로 시작). 그래서, 내 base64 인코딩 중간 스트림의 첫 번째 패킷을 무시하고 보내지 않기로 결정했습니다. Exchange는 두 번째 패킷을 가져 오면이 패킷을 성공적으로 먹고 적절한 연속 응답을 반환합니다. 그러나 이번에는 서버가 훨씬 더 큰 응답을 반환하는 동안 NegotiateStream은 5 바이트 응답을 수신하려고합니다. 간략히 말하자면 NegotiateStream은 +1 요청을 보내고 +1 응답을 기대합니다.
첫 번째 "중복"5 바이트 패킷을 보내지 않아도되지만 NegotiateStream에서 예상하는 첫 번째 5 바이트 응답 패킷을 만들 수는 없습니다. NegotiateStream이 이전에 보내려고했던 동일한 패킷을 먹이려고했지만이 과정은 효과가 없습니다.
나는 무슨 일이 일어나고 있는지 그리고 어떻게 해결할 지 알고 싶습니다. Windows XP SP3 및 Windows Server 2008에서도 동일한 문제가 발생합니다.
저는 Kerberos/GSSAPI 전문가가 아니지만 Kerberos 대화가 실제로 5 바이트 패킷으로 시작되어야한다고 생각합니다. 그러나 다른 작업 도구를 사용할 때이를 본 적이 없으며 Exchange도이를 거부합니다. 어쩌면 GSSAPI가 SASL 프로토콜 (POP3/IMAP/SMTP에서 인증에 사용됨)에 사용되는 경우 첫 번째 패킷을 생략해야합니까? 하지만 NegotiateStream에 대해 또는 적어도 서버에서 5 바이트 응답을 기대할 때 무엇을 보내야하는지에 대해 어떻게 말할 수 있습니까?
서로 다른 모드의 NegotiateStream을 시도했지만 Exchange에 AUTH NTLM과 AUTH GSSAPI를 모두 발행했지만이 점이 전혀 차이가 없습니다. GSSAPI와 NTLM을 모두 지원하는 다른 작업 구현은 모두 동일한 방식으로 작동합니다 (GSSAPI와 NTLM 패킷간에 큰 차이는 없습니다). 모든 들어오고 나가는 패킷은 5 바이트보다 훨씬 큽니다.
Windows XP에서 IIS SMTP 서비스를 사용해도 동일한 결과가 나타납니다. NegotiateStream은 첫 번째 패킷 때문에 SSPI 기반 non-NegotiateStream 구현이 작동합니다. 보내지 않으면 NegotiateStream이 첫 번째 응답으로 기대하는 바가 전혀 없습니다.
SmtpClient 클래스가 어떻게 든이를 관리하고 기본 자격 증명과 NTLM으로 인증 할 수 있기 때문에 가능하다고 생각한 적이 있습니다. 하지만 SmtpClient는 내부적으로 NegotiateStream을 사용하지 않는다는 것을 알았습니다. 이전 버전의 소프트웨어에서와 마찬가지로 관리되지 않는 SSPI 호출을 생성합니다.
Visual Studio 2010/.NET 4.0에서도 사용해 보았습니다.아니 행운 (그리고 NegotiateStream에서 물건을 미세 조정하는 새로운 방법/속성).
나는 완전히 NegotiateStream를 사용하여 자신의 구현을 작성해야합니다/당신이 원하는 마십시오. 내가 정확히 질문이 무엇인지 확실하지 않다
관리되지 않는 호출을 사용하지 않고 현재 기록 된 Windows 사용자의 기본 자격 증명으로 인증해야합니다. 비밀번호가있는 경우 관리되는 버전을 작성하는 것은 문제가되지 않습니다. 해당 암호가 없으면 관리되지 않는 호출을 사용하거나 .NET 기능을 사용하여이 작업을 수행해야합니다. 나는 두 번째 방법을 찾고있다. (이미 명시 적으로 지정된 로그인과 패스워드로 잘 동작하는 관리 코드 구현을 가지고있다.) –
귀하의 구성 요소가 기본 자격 증명으로 인증 할 수있는 것처럼 보이지만 SSPI를 통해 간단하게 작동하는지 (보안상의 이유로 .NET 응용 프로그램에 대한 관리되지 않는 호출을 허용하지 않는 요즘의 습관과 거의 유사하지 않음) 확실하지 않습니다. 핵심 질문은 구현이 관리되는지 여부입니다. 나는 이미 원래의 게시물에서 언급했는데, 나는 이미 작동중인 것을 가지고 있기 때문에 관리되지 않는 구현에 관심이 없다. (하지만 관리되지 않는 호출을하면 사실상 쓸모가 없다.) –
Rebex Secure Mail의 Kerberos/NTLM/GSSAPI는 관리되지 않는 SSPI 호출을 통해 작동합니다. 불행히도 관리되는 구현은 없습니다. 사실, 우리는 지금 당신이 지금 노력하고있는 (.NET의 NegotiateStream으로부터 개별 패킷을 얻기 위해 특수한 스트림 클래스를 사용하는) 동일한 접근법을 시도해 보았지만 이것에 대해 며칠을 보냈지 만 POP3/IMAP/SMTP와 함께 작동시키지 못했습니다 및 Exchange 중 하나를 선택합니다. 그래서 대신 SSPI를 통해 구현했습니다. 안타깝게도 Rebex Secure Mail은 문제의 해결책이 아닙니다. –