Authentification Putty Kerberos / GSSAPI

J'ai configuré quelques serveurs Linux pour s'authentifier auprès d'Active Directory Kerberos à l'aide de sssd sur RHEL6. J'ai également activé l'authentification GSSAPI dans l'espoir de connexions sans mot de passe.

Mais je n'arrive pas à obtenir que Putty (0.63) s'authentifie sans mot de passe.

GSSAPI fonctionne entre les systèmes Linux (client openSSH) configurés pour l'authentification AD, en utilisant les paramètres .ssh / config pour activer GSSAPI.

Il fonctionne également à partir de Cygwin (client openSSH), en utilisant les mêmes paramètres .ssh / config ainsi qu'en exécutant la commande kinit pour obtenir un ticket.

Samba partage également sur tous les systèmes Linux, y compris le travail des répertoires personnels à partir de l'Explorateur Windows sans nécessiter de mot de passe (je ne sais pas si GSSAPI entre en jeu là-bas)

Quel genre de choses puis-je essayer de résoudre ce problème? La plupart de mes utilisateurs utilisent Putty. De plus, je ne suis pas un administrateur Windows, je ne peux donc rien faire sur les contrôleurs de domaine. Mon compte ne dispose que des privilèges pour ajouter des serveurs au domaine AD.

J'ai activé la journalisation des paquets SSH putty. J'ai trouvé ce genre d'intéressant, je ne sais pas encore quoi faire de ces informations:

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.

Sur les machines Windows qui font partie d'un domaine Active Directory, les utilisateurs reçoivent leur ticket d'octroi de ticket Kerberos lorsqu'ils se connectent à Windows et PuTTY peut l'utiliser pour l'authentification si l'authentification GSSAPI est activée dans PuTTY Configuration Connection | SSH | Auth | GSSAPI (et les autres méthodes d'authentification qu'il essaie avant GSSAPI, telles que la clé publique via Pageant, ne sont pas configurées ou désactivées dans Connection | SSH | Auth).

[Si vous avez également besoin d'une délégation de ticket (par exemple, pour monter des systèmes de fichiers kerberized sur le serveur après la connexion), assurez-vous que la délégation GSSAPI est également activée dans PuTTY et que les serveurs auxquels vous vous connectez sont marqués dans Active Directory dans l'onglet Délégation comme " Faites confiance à cet ordinateur pour la délégation à n'importe quel service (Kerberos uniquement) ", ce qu'ils ne sont pas par défaut. Ce dernier paramètre de confiance dans AD est étrangement nécessaire uniquement pour que la délégation fonctionne à partir de clients Windows comme PuTTY; il n'est pas nécessaire pour les clients Linux "ssh -K".]

Sur les machines Windows (personnelles) autogérées qui ne font pas partie d'un domaine Active Directory, vous pouvez toujours utiliser l'authentification Kerberos / GSSAPI (et la délégation de ticket) via PuTTY, mais vous devez obtenir le ticket vous-même. Malheureusement, Windows 7 n'est pas installé avec un équivalent du programme kinit (pour que vous demandiez manuellement un ticket), et PuTTY ne vous demande pas non plus votre mot de passe Kerberos si vous n'avez pas de ticket. Par conséquent, vous devez installer le MIT Kerberos pour Windows, qui comprend à la fois les outils de ligne de commande kinit / klist / kdestroy habituels, ainsi qu'un outil graphique soigné "MIT Kerberos Ticket Manager". Utilisez-les pour obtenir votre ticket, puis PuTTY utilisera automatiquement la bibliothèque MIT GSSAPI au lieu de Microsoft SSPI, et tout devrait fonctionner. Si le "MIT Kerberos Ticket Manager" est en cours d'exécution, il vous demandera automatiquement votre mot de passe Kerberos lorsque PuTTY a besoin d'un ticket, il est donc judicieux de le lier à partir du dossier de démarrage.

Vérifiez d'abord que votre sortie klist sur la boîte Windows exécutant PuTTY affiche un TGT valide. Ensuite, dans la configuration de votre session PuTTY, assurez-vous que l' authentification GSSAPI est activée dans Connection - SSH - Auth - GSSAPI. Enfin, assurez-vous qu'il est configuré pour se connecter avec votre nom d'utilisateur automatiquement dans Connection - Data. Vous pouvez soit spécifier explicitement le nom d'utilisateur, soit sélectionner le bouton radio pour Utiliser le nom d' utilisateur du système .

Historiquement, c'est tout ce que j'avais à faire pour que la connexion SSH sans mot de passe fonctionne via Kerberos.

Le problème était dans la configuration de Windows Kerberos. Je pense que notre Active Directory est configuré de manière géniale, je ne sais pas vraiment que je ne suis pas un administrateur Windows.

Mais j'ai résolu le problème en configurant manuellement Kerberos à l'aide de ksetup dans Windows 7 CLI.

Après un redémarrage sur mon poste de travail distant, je n'ai pas pu me connecter à mon PC. En effet, dans la configuration d'origine, la partie TLD de mon domaine de domaine était toujours absente (domaine \ utilisateur) mais après l'avoir configuré manuellement, j'ai dû changer mon domaine de connexion pour refléter le nom de domaine complet du domaine (domaine.TLD \ utilisateur) et J'ai pu me connecter à mon PC Windows, bien qu'il semble plus long de s'authentifier maintenant.

Avant les modifications, la sortie de ksetup ne montrait que mon domaine par défaut, et c'était en minuscules.

J'ai utilisé "nslookup -type = SRV _kerberos._tcp.domain.TLD" pour obtenir tous les serveurs kdc pour mon domaine.

Je n'ai placé aucun drapeau.

J'ai défini mappé mon nom d'utilisateur "ksetup / mapuser [email protected] user"

Ressources que j'ai utilisées: https://wiki.ncsa.illinois.edu/display/ITS/Windows+7+Kerberos+Login+using+External+Kerberos+KDC

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

Si quelqu'un a des suggestions que je peux donner aux administrateurs Windows sur la façon de résoudre ce problème (est-ce cassé?) Je vais le transmettre.