2017-02-10 1 views
2

Ich versuche, meine lokale Windows 10-Maschine zu einem Webdienst zu authentifizieren, der in einem Dockercontainer ausgeführt wird. Um genauer zu sein, dieser Container führt Hadoop-Dienste und ein MIT-Kerberos-KDC aus. Ich habe MIT Kerberos für Windows auf meinem lokalen Rechner installiert und erfolgreich ein Ticket hadoop/[email protected] vom KDC bekommen. Wenn ich mich mit dem gleichen Prinzipal innerhalb meines Containers authentifiziere und diesen Befehl anrufe: curl -i --negotiate -u : "http://quickstart.cloudera:50070/webhdfs/v1/?op=GETFILESTATUS" bekomme ich eine gültige Antwort. Allerdings gibt die gleiche Befehl ausgeführt von meinem Windows-Rechner diesen Fehler:HTTP-Aushandlung schlägt von Windows zu Linux fehl

Error 403 GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag) 

Kann jemand vertraut mit SSPI/GSSAPI geben Sie mir einen kleinen Einblick auf das, was hier das Problem sein könnte?

Ich habe die Umgebungsvariable KRB5CCNAME=<path to ccache> richtig eingestellt. Dies ist die cURL Informationen von meiner Windows-Eingabeaufforderung:

curl 7.52.1 (x86_64-w64-mingw32) libcurl/7.52.1 WinSSL zlib/1.2.8 WinIDN libssh2/1.7.0_DEV 
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp 
Features: IDN IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz 

Lassen Sie mich wissen, wenn Sie weitere Informationen über meine Umgebung Setup benötigen.

Update:

Hier ist die vollständige HTTP-Antwort von meinem Windows-Rechner, wenn ich den Befehl mit der -v Flagge für Ausführlichkeit hinzugefügt laufen.

* timeout on name lookup is not supported 
* Trying 127.0.0.1... 
* TCP_NODELAY set 
* Connected to quickstart.cloudera (127.0.0.1) port 50070 (#0) 
> GET /webhdfs/v1/?op=GETFILESTATUS HTTP/1.1 
> Host: quickstart.cloudera:50070 
> User-Agent: curl/7.52.1 
> Accept: */* 
> 
< HTTP/1.1 401 Authentication required 
HTTP/1.1 401 Authentication required 
< Cache-Control: must-revalidate,no-cache,no-store 
Cache-Control: must-revalidate,no-cache,no-store 
< Date: Fri, 10 Feb 2017 19:41:27 GMT 
Date: Fri, 10 Feb 2017 19:41:27 GMT 
< Pragma: no-cache 
Pragma: no-cache 
< Date: Fri, 10 Feb 2017 19:41:27 GMT 
Date: Fri, 10 Feb 2017 19:41:27 GMT 
< Pragma: no-cache 
Pragma: no-cache 
< Content-Type: text/html; charset=iso-8859-1 
Content-Type: text/html; charset=iso-8859-1 
< WWW-Authenticate: Negotiate 
WWW-Authenticate: Negotiate 
< Set-Cookie: hadoop.auth=; Path=/; HttpOnly 
Set-Cookie: hadoop.auth=; Path=/; HttpOnly 
< Content-Length: 1404 
Content-Length: 1404 
< Server: Jetty(6.1.26.cloudera.4) 
Server: Jetty(6.1.26.cloudera.4) 

< 
* Ignoring the response-body 
* Curl_http_done: called premature == 0 
* Connection #0 to host quickstart.cloudera left intact 
* Issue another request to this URL: 'http://quickstart.cloudera:50070/webhdfs/v1/?op=GETFILESTATUS' 
* Found bundle for host quickstart.cloudera: 0x817220 [can pipeline] 
* Re-using existing connection! (#0) with host quickstart.cloudera 
* Connected to quickstart.cloudera (127.0.0.1) port 50070 (#0) 
* Server auth using Negotiate with user '' 
> GET /webhdfs/v1/?op=GETFILESTATUS HTTP/1.1 
> Host: quickstart.cloudera:50070 
> Authorization: Negotiate TlRMTVNTUAABAAAAt4II4gAAAAAAAAAAAAAAAAAAAAAKAFopAAAADw== 
> User-Agent: curl/7.52.1 
> Accept: */* 
> 
< HTTP/1.1 403 GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag) 
HTTP/1.1 403 GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag) 
< Cache-Control: must-revalidate,no-cache,no-store 
Cache-Control: must-revalidate,no-cache,no-store 
< Date: Fri, 10 Feb 2017 19:41:27 GMT 
Date: Fri, 10 Feb 2017 19:41:27 GMT 
< Pragma: no-cache 
Pragma: no-cache 
< Date: Fri, 10 Feb 2017 19:41:27 GMT 
Date: Fri, 10 Feb 2017 19:41:27 GMT 
< Pragma: no-cache 
Pragma: no-cache 
< Content-Type: text/html; charset=iso-8859-1 
Content-Type: text/html; charset=iso-8859-1 
< Set-Cookie: hadoop.auth=; Path=/; HttpOnly 
Set-Cookie: hadoop.auth=; Path=/; HttpOnly 
< Content-Length: 1546 
Content-Length: 1546 
< Server: Jetty(6.1.26.cloudera.4) 
Server: Jetty(6.1.26.cloudera.4) 

< 
<html> 
<head> 
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/> 
<title>Error 403 GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)</title> 
</head> 
<body><h2>HTTP ERROR 403</h2> 
<p>Problem accessing /webhdfs/v1/. Reason: 
<pre> GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)</pre></p><hr /><i><small>Powered by Jetty://</small></i><br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 
<br/> 

</body> 
</html> 
* Curl_http_done: called premature == 0 
* Closing connection 0 

Im Gegensatz dazu ist dies die Antwort von läuft den gleichen Befehl in meinem Container:

* About to connect() to quickstart.cloudera port 50070 (#0) 
* Trying 172.18.0.2... connected 
* Connected to quickstart.cloudera (172.18.0.2) port 50070 (#0) 
> GET /webhdfs/v1/?op=GETFILESTATUS HTTP/1.1 
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 
> Host: quickstart.cloudera:50070 
> Accept: */* 
> 
< HTTP/1.1 401 Authentication required 
HTTP/1.1 401 Authentication required 
< Cache-Control: must-revalidate,no-cache,no-store 
Cache-Control: must-revalidate,no-cache,no-store 
< Date: Fri, 10 Feb 2017 21:15:39 GMT 
Date: Fri, 10 Feb 2017 21:15:39 GMT 
< Pragma: no-cache 
Pragma: no-cache 
< Date: Fri, 10 Feb 2017 21:15:39 GMT 
Date: Fri, 10 Feb 2017 21:15:39 GMT 
< Pragma: no-cache 
Pragma: no-cache 
< Content-Type: text/html; charset=iso-8859-1 
Content-Type: text/html; charset=iso-8859-1 
< WWW-Authenticate: Negotiate 
WWW-Authenticate: Negotiate 
< Set-Cookie: hadoop.auth=; Path=/; HttpOnly 
Set-Cookie: hadoop.auth=; Path=/; HttpOnly 
< Content-Length: 1404 
Content-Length: 1404 
< Server: Jetty(6.1.26.cloudera.4) 
Server: Jetty(6.1.26.cloudera.4) 

< 
* Ignoring the response-body 
* Connection #0 to host quickstart.cloudera left intact 
* Issue another request to this URL: 'http://quickstart.cloudera:50070/webhdfs/v1/?op=GETFILESTATUS' 
* Re-using existing connection! (#0) with host quickstart.cloudera 
* Connected to quickstart.cloudera (172.18.0.2) port 50070 (#0) 
* Server auth using GSS-Negotiate with user '' 
> GET /webhdfs/v1/?op=GETFILESTATUS HTTP/1.1 
> Authorization: Negotiate YIICkQYJKoZIhvcSAQICAQBuggKAMIICfKADAgEFoQMCAQ6iBwMFAAAAAACjggGBYYIBfTCCAXmgAwIBBaEKGwhDTE9VREVSQaImMCSgAwIBA6EdMBsbBEhUVFAbE3F1aWNrc3RhcnQuY2xvdWRlcmGjggE8MIIBOKADAgESoQMCAQKiggEqBIIBJnWbXp9WlAVk0nGIqD7T25On1+OCPzXDX/aoH01FTjJbEwrYj4cMML7Tf6jaKDIANEh57kTJOvPknL3CWHI1c3LeNpt1Ir8H2M3Zvk91HpbWXzv5WJTeUOK9L6zTaKFEs/dKQgD7VzmHKDJtMyVKQWLLVU8JuyKAV6iM4FvxfZ+WDF8QCk7pxwjgX1OT7jv9jR28MPpsIweqUYYnneJxVTsxgmsHdOvj5wpMGy9RA9R8jtR+Wh3l5r3a3zcUTmGwAqY+NXhBkviSTw+DgitnipYh5tXBRhNqGfk86qWAdodGgL+SdkwwGsq91PyYQiMCLXjWx90aBOEFeZLDyqBaXlMIZ3TT3urUQEuB206+8KNw1n6N6+u+ZY4QT7NJyVZqHbnOR5V5maSB4TCB3qADAgESooHWBIHTyaBY3PormkycaX9uf/lLe6ISYnItZikJqslAGpJVnla2HXYvhFjqn5yr8td1pw3zzdnDEZx3a9EylIrRQD5IoIvHCzd0mlJhHFj4xxISM5hxlMiL8DewMjGsVcDveqpHw1SyxIsrEPOhe62HuRXS7c1Z9kYkP6KldzyAJOttOVYCuL36hOxwEFqJtbWk1/f9gfTdzmxQmEASM3/wsj2Q/WYCZY/hazDIz6dmHsyla/F6NXGK0BwRnHHBCqSHe7GdWmBDNjHiuo6R0/YvqTl5Uvf0Rw== 
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.15.3 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 
> Host: quickstart.cloudera:50070 
> Accept: */* 
> 
< HTTP/1.1 200 OK 
HTTP/1.1 200 OK 
< Cache-Control: no-cache 
Cache-Control: no-cache 
< Expires: Fri, 10 Feb 2017 21:15:39 GMT 
Expires: Fri, 10 Feb 2017 21:15:39 GMT 
< Date: Fri, 10 Feb 2017 21:15:39 GMT 
Date: Fri, 10 Feb 2017 21:15:39 GMT 
< Pragma: no-cache 
Pragma: no-cache 
< Expires: Fri, 10 Feb 2017 21:15:39 GMT 
Expires: Fri, 10 Feb 2017 21:15:39 GMT 
< Date: Fri, 10 Feb 2017 21:15:39 GMT 
Date: Fri, 10 Feb 2017 21:15:39 GMT 
< Pragma: no-cache 
Pragma: no-cache 
< Content-Type: application/json 
Content-Type: application/json 
< Set-Cookie: hadoop.auth="u=hadoop&p=hadoop/[email protected]&t=kerberos&e=1486797339425&s=BqBHGJ+/FxxeSR0ayBXHOrfPkwU="; Path=/; HttpOnly 
Set-Cookie: hadoop.auth="u=hadoop&p=hadoop/[email protected]&t=kerberos&e=1486797339425&s=BqBHGJ+/FxxeSR0ayBXHOrfPkwU="; Path=/; HttpOnly 
< Transfer-Encoding: chunked 
Transfer-Encoding: chunked 
< Server: Jetty(6.1.26.cloudera.4) 
Server: Jetty(6.1.26.cloudera.4) 

< 
* Connection #0 to host quickstart.cloudera left intact 
* Closing connection #0 
{"FileStatus":{"accessTime":0,"blockSize":0,"childrenNum":5,"fileId":16385,"group":"supergroup","length":0,"modificationTime":1459909590753,"owner":"hdfs","pathSuffix":"","permission":"755","replication":0,"storagePolicy":0,"type":"DIRECTORY"}} 
+0

gibt 'curl -v' weitere Details? – rogerdpack

+0

Meinst du "-v" wie in der ausführlichen Einstellung, wenn ich den Befehl ausführe? Ich werde das Ergebnis zur ursprünglichen Frage hinzufügen. – ejang

Antwort

1

Die Antwort ist sehr einfach, in diesem Fall. Curl unter Windows wird mit SSPI kompiliert. Wenn SSPI aufgefordert wird, SPNEGO auszuführen, versucht es Kerberos, was hier fehlschlägt. Wahrscheinlich "Server nicht in der Datenbank gefunden" (verwenden Sie Wireshark) und fällt dann zurück auf NTLM. Es sendet ein rohes NTLM-Token an Ihren JGSS-backed-Server, der das Token zurückweist, weil

  1. Dies ist kein SPNEGO-Token wrapped, sondern ein rohes NTLM-Token
  2. Java unterstützt keine NTLM

Here ist ein Beispielcode, wie Sie dies abfangen und mit einer aussagekräftigen Nachricht antworten können. Beheben Sie ein Problem mit Hadoop.

Darüber hinaus ist Ihre Curl-Version 7.19.7 unter Linux extrem alt und unsicher, Sie sollten sofort upgraden UND der SPNEGO Authenticator auf Jetty ist defekt, weil er nicht mit einem Context-Completion-Token antwortet. Zusammenfassend sollte die gesamte Authentifizierung nicht vertrauenswürdig sein, da sie fehlerhaft ist. Siehe RFC 7546.