Kerberos, le SSO universel

  • View
    225

  • Download
    2

Embed Size (px)

Transcript

  • Kerberos, le SSO universel

    Guillaume RousseIngenieur systeme a lINRIA

    novembre 2011

    Table des matieres

    1 Presentation 31.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

    1.3.1 Protocole . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3.2 Remarques . . . . . . . . . . . . . . . . . . . . . . . . . . 6

    1.4 Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

    2 Deploiement de linfrastructure 82.1 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Mise en place du KDC . . . . . . . . . . . . . . . . . . . . . . . . 92.3 Mise en place du serveur dadministration . . . . . . . . . . . . . 122.4 Mise en place du serveur de changement de mot de passe . . . . 14

    3 Integration des applications 153.1 Principes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

    3.1.1 Creation du principal . . . . . . . . . . . . . . . . . . . . 163.1.2 Mise en place du fichier keytab . . . . . . . . . . . . . . . 17

    3.2 Telnet, RSH, FTP . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3 OpenSSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

    3.3.1 Authentification Kerberos . . . . . . . . . . . . . . . . . . 183.3.2 Recuperation de ticket Kerberos . . . . . . . . . . . . . . 22

    3.4 Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4.1 Authentification Kerberos . . . . . . . . . . . . . . . . . . 223.4.2 Validation de mot de passe . . . . . . . . . . . . . . . . . 24

    3.5 OpenLDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.5.1 Authentification Kerberos . . . . . . . . . . . . . . . . . . 253.5.2 Validation de mots de passe . . . . . . . . . . . . . . . . . 26

    3.6 NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.6.1 Mise en place . . . . . . . . . . . . . . . . . . . . . . . . . 283.6.2 Cote serveur . . . . . . . . . . . . . . . . . . . . . . . . . 29

    1

  • 3.6.3 Cote client . . . . . . . . . . . . . . . . . . . . . . . . . . 303.6.4 Authentification des utilisateurs . . . . . . . . . . . . . . 313.6.5 Chiffrement et controle dintegrite . . . . . . . . . . . . . 34

    3.7 PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

    4 Subtilites diverses 364.1 Identification de service . . . . . . . . . . . . . . . . . . . . . . . 37

    4.1.1 Canonicalisation . . . . . . . . . . . . . . . . . . . . . . . 374.1.2 Alias de principaux . . . . . . . . . . . . . . . . . . . . . . 384.1.3 Principaux multiples . . . . . . . . . . . . . . . . . . . . . 39

    4.2 Transformation de nom dutilisateur . . . . . . . . . . . . . . . . 39

    5 Mise en uvre avancee 415.1 Politique de mots de passe . . . . . . . . . . . . . . . . . . . . . . 415.2 Configuration DNS . . . . . . . . . . . . . . . . . . . . . . . . . . 435.3 Replication de serveurs . . . . . . . . . . . . . . . . . . . . . . . . 44

    5.3.1 Replication complete . . . . . . . . . . . . . . . . . . . . . 455.3.2 Replication incrementale . . . . . . . . . . . . . . . . . . . 46

    5.4 Gestion de la coherence entre bases . . . . . . . . . . . . . . . . . 485.4.1 Stockage LDAP . . . . . . . . . . . . . . . . . . . . . . . . 485.4.2 Fusion des bases . . . . . . . . . . . . . . . . . . . . . . . 505.4.3 Utilisation des attributs Kerberos pour lauthentification . 54

    6 Relation de confiance entre royaumes 596.1 Confiance entre royaumes Unix . . . . . . . . . . . . . . . . . . . 606.2 Confiance entre royaume Unix et domaine Active Directory . . . 636.3 Mise en place de la relation de confiance . . . . . . . . . . . . . . 63

    6.3.1 Configuration du royaume externe . . . . . . . . . . . . . 666.3.2 Mise en place dune correspondance de compte utilisateur 676.3.3 Acces a un partage CIFS depuis le monde Unix . . . . . . 686.3.4 Ouverture de session Windows via le royaume Kerberos

    Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.3.5 Acces a site web Unix depuis le monde Windows . . . . . 72

    7 Resolution de problemes 737.1 Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737.2 Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

    8 Conclusion 74

    2

  • Kerberos est un protocole dauthentification reseau, qui presente la parti-cularite dallier a la fois securite et confort dutilisation, puisquil sagit dunsysteme dauthentification unique (SSO, Single Sign On). A lheure ou fleu-rissent les articles vantant les merite des systemes de type CAS, assurant unservice similaire, mais limite aux seules applications Web, il parait interessantde presenter cette technologie quelque peu meconnue.

    Larticle commence par presenter le protocole et ses concepts. Ensuite, ilexplique le deploiement de linfrastructure, puis lintegration des applications acelle-ci. Enfin, il aborde certaines subtilites de configuration et quelques exemplesdutilisation plus avancee.

    1 Presentation

    1.1 Historique

    Kerberos a vu le jour, dans les annees 1980, au sein du projet Athena, unprojet de recherche conjoint entre le MIT, DEC et IBM, dou sortit egalementle systeme X Windows. Il sagit dun systeme concu pour assurer une authen-tification fiable et reciproque entre differents nuds dun reseau non securise,garantissant la confidentialite des echanges et limpossibilite de les rejouer. Letout a une epoque ou la norme etait plutot a lutilisation des mots de passe enclair via telnet, pour situer le contexte...

    Vers la fin des annees 80, la premiere version publique est publiee, sous lenom de Kerberos 4. En plus detre utilisee pour le projet Athena, cette versionest egalement adoptee comme protocole dauthentification par AFS, le systemede fichier distribue concu au sein de luniversite de Carnegie-Mellon.

    La version 5, destinee a corriger certaines limites de la version precedente, estla premiere a faire lobjet dune specification, sous la forme de la RFC 1510 en1993. Cette premiere specification sera ensuite remplacee par la RFC 4120 (TheKerberos Network Authentication Service) en 2005, et completee par dautrestelles que les RFC 3961 (Encryption and Checksum Specifications), 3962 (AESEncryption for Kerberos 5), et 4121 (GSS-API).

    1.2 Concepts

    Une installation de Kerberos constitue un royaume, cest-a-dire une entitedistincte de tout autre installation. Ce royaume va constituer un espace de nom-mage unique pour ses differents participants. Par convention, et afin dassurercette unicite, cest le nom de domaine DNS mis en majuscule qui determinele nom de ce royaume. Au domaine zarb.home correspond donc le royaumeZARB.HOME.

    A linterieur de ce royaume, chaque participant est identifie par un princi-pal, de la forme nom@ROYAUME. Certains acteurs peuvent eventuellement possederplusieurs principaux, differencies alors par leur instance, ce qui donne des prin-cipaux de la forme nom/instance@ROYAUME. Typiquement, les principaux corres-

    3

  • pondante a des services heberges sur une machine sont de la forme service/machine@ROYAUME,et les administrateurs systeme possedent des principaux nom/admin@ROYAUMEdedies a ladministration, en supplement de leurs principaux dutilisateur nom@ROYAUME.

    Lelement central de chaque royaume est le Key Distribution Center, ouKDC. Celui-ci est constitue dune base de donnees de tous les principaux duroyaume, chacun associe a un secret partage avec lentite correspondant a ceprincipal. Pour un utilisateur, ce secret est son mot de passe. Pour un service,ce secret est en general genere aleatoirement a la creation du principal. Cesecret est stocke sous la forme dune cle pour chaque algorithme de chiffragesupporte. Dautres informations relatives au principal peuvent egalement etrestockees, comme par exemple la duree de validite du principal, la date de dernierchangement de mot de passe, etc. . .

    Le KDC joue le role dun tiers de confiance, en distribuant aux utilisateursdes tickets, prouvant leur identite vis-a-vis dun service cible. Ces tickets sonten fait des jetons dauthentifications, a duree de vie limitee afin deviter uneattaque par rejeu. Ils sont totalement opaques pour lutilisateur, et dechiffrableuniquement par linterlocuteur quil a choisi, ce qui assure une authentificationreciproque.

    Il faut bien comprendre que ce mecanisme nassure que lauthentification desdivers participants. La seule information vehiculee par un ticket est que son pos-sesseur est bien celui quil pretend etre, mais en aucun cas qui il est. Ceci peutetre suffisant pour des scenarios simples (tout utilisateur authentifie est valide),mais ne permet absolument pas de gerer des scenarios plus complexes, basessur des notions dautorisation. Et encore moins de gerer lensemble des infor-mations liees a la notion de compte informatique (GID, UID, etc...). Pour cetteraison, un royaume Kerberos nest pas une alternative a une base de comptescentralisees, comme un annuaire LDAP par exemple, mais un complement pos-sible, apportant un mecanisme supplementaire dauthentification, plus securiseet plus transparent pour lutilisateur.

    1.3 Fonctionnement

    1.3.1 Protocole

    De facon plus detaille, le protocole fait intervenir 4 acteurs : le serveur dauthentification (Authentification Server) le serveur de ticket (Ticket-Granting Server) le client le serviceDans la pratique, les deux premiers roles sont tenus par le KDC, meme sil

    sagit de roles distincts.Le schema 1 montre le dialogue entre le client et le serveur dauthentifica-

    tion, lorsque lutilisateur sauthentifie. Ce dialogue est unique pour la session detravail, cest le principe meme du SSO.

    Le client envoie une requete (AS-REQ), co