Putty Kerberos / GSSAPI-Authentifizierung

Ich habe einige Linux-Server für die Authentifizierung bei Active Directory-Kerberos mithilfe von sssd unter RHEL6 konfiguriert. Ich habe auch die GSSAPI-Authentifizierung in der Hoffnung auf kennwortlose Anmeldungen aktiviert.

Aber ich kann Putty (0.63) scheinbar nicht dazu bringen, sich ohne Passwort zu authentifizieren.

GSSAPI funktioniert zwischen Linux-Systemen (openSSH-Client), die für die AD-Authentifizierung konfiguriert sind, und verwendet die Einstellungen für .ssh / config, um GSSAPI zu aktivieren.

Es funktioniert auch von Cygwin (openSSH-Client) aus, wobei dieselben .ssh / config-Einstellungen verwendet werden und der Befehl kinit ausgeführt wird, um ein Ticket zu erhalten.

Auch Samba-Freigaben auf allen Linux-Systemen, einschließlich Home-Verzeichnissen, funktionieren über Windows Explorer, ohne dass ein Kennwort erforderlich ist (ich bin nicht sicher, ob GSSAPI dort ins Spiel kommt).

Welche Art von Dingen kann ich versuchen, dies zu beheben? Die meisten meiner Benutzer verwenden Putty. Außerdem bin ich kein Windows-Administrator, daher kann ich auf den Domänencontrollern nichts tun. Mein Konto verfügt nur über Berechtigungen zum Hinzufügen von Servern zur AD-Domäne.

Ich habe die Kitt-SSH-Paketprotokollierung aktiviert. Ich fand diese Art von interessant, ich bin mir noch nicht sicher, was ich mit diesen Informationen anfangen soll:

Event Log: Server version: SSH-2.0-OpenSSH_5.3
Event Log: Using SSH protocol version 2
Event Log: We claim version: SSH-2.0-PuTTY_Release_0.63
Outgoing packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)
Incoming packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)
Event Log: Doing Diffie-Hellman group exchange
Outgoing packet #0x1, type 30 / 0x1e (SSH2_MSG_KEX_DH_GEX_REQUEST)
Incoming packet #0x1, type 31 / 0x1f (SSH2_MSG_KEX_DH_GEX_GROUP)
Event Log: Doing Diffie-Hellman key exchange with hash SHA-256
Outgoing packet #0x2, type 32 / 0x20 (SSH2_MSG_KEX_DH_GEX_INIT)
Incoming packet #0x2, type 33 / 0x21 (SSH2_MSG_KEX_DH_GEX_REPLY)
Outgoing packet #0x3, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: Initialised AES-256 SDCTR client->server encryption
Event Log: Initialised HMAC-SHA1 client->server MAC algorithm
Outgoing raw data at 2014-11-25 00:21:08
Incoming packet #0x3, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: Initialised AES-256 SDCTR server->client encryption
Event Log: Initialised HMAC-SHA1 server->client MAC algorithm
Outgoing packet #0x4, type 5 / 0x05 (SSH2_MSG_SERVICE_REQUEST)
Incoming packet #0x6, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
...%gssapi-keyex
,gssapi-with-mic
,password.
Event Log: Using SSPI from SECUR32.DLL
Event Log: Attempting GSSAPI authentication
Outgoing packet #0x6, type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
Incoming packet #0x7, type 60 / 0x3c (SSH2_MSG_USERAUTH_GSSAPI_RESPONSE)
Event Log: GSSAPI authentication initialised
Outgoing packet #0x7, type 61 / 0x3d (SSH2_MSG_USERAUTH_GSSAPI_TOKEN)
Incoming packet #0x8, type 61 / 0x3d (SSH2_MSG_USERAUTH_GSSAPI_TOKEN)
Event Log: GSSAPI authentication initialised
Event Log: GSSAPI authentication loop finished OK
Outgoing packet #0x8, type 66 / 0x42 (SSH2_MSG_USERAUTH_GSSAPI_MIC)
Incoming packet #0x9, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
...%gssapi-keyex
,gssapi-with-mic
,password.

Auf Windows-Computern, die Teil einer Active Directory-Domäne sind, erhalten Benutzer ihr Kerberos-Ticketgewährungsticket, wenn sie sich bei Windows anmelden. PuTTY kann dieses zur Authentifizierung verwenden, wenn die GSSAPI-Authentifizierung in PuTTY Configuration Connection | SSH | Auth | GSSAPI aktiviert ist (und andere Authentifizierungsmethoden, die vor GSSAPI versucht werden, wie z. B. der öffentliche Schlüssel über Pageant, werden in Connection | SSH | Auth nicht eingerichtet oder deaktiviert).

[Wenn Sie auch eine Ticketdelegierung benötigen (z. B. um kerberisierte Dateisysteme nach der Anmeldung auf dem Server bereitzustellen), stellen Sie sicher, dass die GSSAPI-Delegierung auch in PuTTY aktiviert ist und die Server, bei denen Sie sich anmelden, in Active Directory auf der Registerkarte Delegierung als markiert sind " Vertrauen Sie diesem Computer für die Delegierung an einen Dienst (nur Kerberos) ", was nicht standardmäßig der Fall ist. Diese letztere Vertrauensstellung in AD wird seltsamerweise nur benötigt, damit die Delegierung von Windows-Clients wie PuTTY aus funktioniert. es wird nicht für Linux "ssh -K" Clients benötigt.]

Auf selbstverwalteten (persönlichen) Windows-Computern, die nicht Teil einer Active Directory-Domäne sind, können Sie die Kerberos / GSSAPI-Authentifizierung (und die Ticketdelegierung) weiterhin über PuTTY verwenden, müssen das Ticket jedoch selbst erwerben. Leider wird Windows 7 nicht mit einem Äquivalent des Kinit-Programms installiert (damit Sie manuell ein Ticket anfordern können), und PuTTY fordert Sie auch dann nicht zur Eingabe Ihres Kerberos-Kennworts auf, wenn Sie kein Ticket haben. Daher müssen Sie MIT Kerberos für Windows installierenPaket, das sowohl die üblichen Kinit / Klist / Kdestroy-Befehlszeilentools als auch ein ordentliches GUI-Tool "MIT Kerberos Ticket Manager" enthält. Verwenden Sie diese, um Ihr Ticket zu erhalten, und dann verwendet PuTTY automatisch die MIT GSSAPI-Bibliothek anstelle der Microsoft SSPI-Bibliothek, und alles sollte funktionieren. Wenn der "MIT Kerberos Ticket Manager" ausgeführt wird, werden Sie automatisch zur Eingabe Ihres Kerberos-Kennworts aufgefordert, wenn PuTTY ein Ticket benötigt. Es empfiehlt sich daher, es über den Startordner zu verknüpfen.

Überprüfen Sie zunächst, ob Ihre Klist-Ausgabe auf der Windows-Box, auf der PuTTY ausgeführt wird, eine gültige TGT anzeigt. Stellen Sie dann in der Konfiguration für Ihre PuTTY-Sitzung sicher, dass die Option GSSAPI-Authentifizierung versuchen in aktiviert ist Connection - SSH - Auth - GSSAPI. Stellen Sie schließlich sicher, dass es so konfiguriert ist, dass Sie sich automatisch mit Ihrem Benutzernamen anmelden Connection - Data. Sie können entweder den Benutzernamen explizit angeben oder das Optionsfeld für Systembenutzernamen verwenden aktivieren .

In der Vergangenheit war das alles, was ich tun musste, damit die kennwortlose SSH-Anmeldung über Kerberos funktioniert.

Das Problem lag im Windows Kerberos-Setup. Ich denke, unser Active Directory ist funky eingerichtet, ich weiß nicht wirklich, dass ich kein Windows-Administrator bin.

Ich habe das Problem jedoch behoben, indem ich Kerberos mithilfe von ksetup in der Windows 7-CLI manuell konfiguriert habe.

Nach einem Neustart meiner Remote-Workstation konnte ich mich nicht bei meinem PC anmelden. Dies liegt daran, dass in der ursprünglichen Konfiguration der TLD-Teil meiner Realm-Domäne immer fehlte (Domäne \ Benutzer), aber nachdem ich ihn manuell konfiguriert hatte, musste ich meine Anmeldedomäne ändern, um den vollständigen Realm-Domänennamen (domain.TLD \ Benutzer) und wiederzugeben Ich konnte mich bei meinem Windows-PC anmelden, obwohl die Authentifizierung jetzt anscheinend länger dauert.

Vor den Änderungen zeigte die Ausgabe von ksetup nur meinen Standardbereich und war in Kleinbuchstaben.

Ich habe "nslookup -type = SRV _kerberos._tcp.domain.TLD" verwendet, um alle kdc-Server für meinen Realm abzurufen.

Ich habe keine Flags gesetzt.

Ich habe meinen Benutzernamen "ksetup / mapuser user@domain.TLD user" zugeordnet.

Von mir verwendete Ressourcen: https://wiki.ncsa.illinois.edu/display/ITS/Windows+7+Kerberos+Login+using+External+Kerberos+KDC

https://www.cgl.ucsf.edu/Security/CGLAUTH/CGLAUTH.html

Wenn jemand Vorschläge hat, die ich den Windows-Administratoren geben kann, wie sie das beheben können (ist es kaputt?), Werde ich sie weitergeben.