Authentification kerberos entre domaines avec ssh


4

Comment puis-je configurer l'authentification inter-domaines sur un serveur openssh à l'aide de Kerberos sans devoir ajouter de principes pour les deux domaines dans le fichier .k5login?

Réponses:


7

Lorsqu'un nom de compte (fourni par SSH) et un nom de principal sont attribués, la bibliothèque Kerberos utilise la krb5_kuserok()fonction pour autoriser ou refuser l'accès.

Par défaut, krb5_kuserok()autorise l'accès si le nom du principal est répertorié dans ~/.k5userok. Si ce fichier n'existe pas, il vérifie si la fonction krb5_aname_to_localname () renvoie le même nom de compte.

Désormais, par défaut, krb5_aname_to_localname()renvoie le nom du principal (sans domaine) si le principal a exactement un composant de nom et que son domaine correspond exactement au domaine par défaut du système. sinon, il renvoie le nom principal entier avec le royaume.


Le moyen le plus simple de changer cela consiste donc à apprendre krb5_aname_to_localname()à traduire les noms principaux étrangers . Il y a plusieurs méthodes:

Si vous souhaitez un mappage simple un-à-un pour tout le royaume, vous pouvez écrire une règle de traduction dans krb5.conflaquelle cela supprime simplement le royaume. (Notez que ces exemples concernent le MIT Kerberos; vous devrez les ajuster quelque peu pour Heimdal.)

[royaumes]
        NULLROUTE.EU.ORG = {
                auth_to_local = REGLE: [1: $ 1 @ $ 0] (. * @ EXEMPLE \ .COM) s /@.*//
                auth_to_local = REGLE: [1: 1 $ @ 0 $] (. * @ ATHENA \ .MIT \ .EDU) s /@.*/@ athena /
                auth_to_local = DEFAULT
        }

Dans cet exemple, [1:...]vérifie que le côté "local" (gauche) a exactement un composant; [1:$1@$0]construit une seule chaîne à partir du premier composant + un @ + le nom du domaine (donnant ainsi le nom principal d'origine); (.*@EXAMPLE\.COM)fait correspondre la chaîne construite avec une expression rationnelle pour vérifier qu'elle se termine par un nom de domaine spécifié; s/@.*//remplace l'expression régulière @.*(tout ce qui suit le @signe) par une chaîne vide. Le résultat sera utilisé comme nom de compte système.

La deuxième règle fonctionne de la même manière, mais remplace le royaume par "@athena", ce qui donne des noms d'utilisateur similaires root@athena. Je ne fais que l'inclure à titre d'exemple, car le client LDAP / AD SSSD peut utiliser cette syntaxe, ce qui permet de disposer de plusieurs domaines par hôte.

La troisième règle vient de ce que j'ai décrit au début.

Si vous souhaitez uniquement mapper des noms spécifiques, vous pouvez ajouter une auth_to_local_namessection. la configuration ressemblerait à ceci: (note: Heimdal utilise auth_to_local)

[libdefaults]
        default_realm = NULLROUTE.EU.ORG

[royaumes]
        NULLROUTE.EU.ORG = {
                auth_to_local_names = {
                        grawity/admin@EXAMPLE.COM = grawity
                        root@ATHENA.MIT.EDU = root
                }
        }

Cela ne traduit que deux noms principaux dans un seul compte local.

Si vous recherchez une méthode automatisée, les versions récentes de MIT Kerberos disposent d'une API pour les plug-in "localauth" qui peut fournir leurs propres implémentations pour la vérification des autorisations ainsi que pour la traduction principal / compte.

Par exemple, le client SSSD IPA / AD a récemment (il y a environ un mois) commencé à fournir son propre plug-in pour la traduction des noms principaux d'utilisateurs FreeIPA et Active Directory.


1
Merci Grawity. Votre 1ère solution était sur place. Je noterai que vous devez également disposer de la ligne auth_to_local = DEFAULT pour que le REALM local fonctionne.
Iain Conochie

Vous méritez tellement plus de points que cela. Cette réponse m'a mis dans la bonne direction pour que notre configuration fonctionne sans les fichiers .k5login. Nous avons fini par utiliser une règle du type RULE:[1:$1@$0], qui fonctionne en conjonction avec RFC tools.ietf.org/html/rfc6806.html
Ben
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.