kerberos
play

Kerberos Nicolas Gren` eche Centre de Ressources Informatique - PowerPoint PPT Presentation

Kerberos Nicolas Gren` eche Centre de Ressources Informatique (CRI) - Universit e dOrl eans Projet SDS - LIFO et ENSI de Bourges nicolas.greneche@univ-orleans.fr 11/07/2011 Sommaire Pourquoi Kerberos ? 1 Les acteurs 2 Le


  1. Kerberos Nicolas Gren` eche Centre de Ressources Informatique (CRI) - Universit´ e d’Orl´ eans Projet SDS - LIFO et ENSI de Bourges nicolas.greneche@univ-orleans.fr 11/07/2011

  2. Sommaire Pourquoi Kerberos ? 1 Les acteurs 2 Le protocole 3 Kerberisation d’une application 4 Tol´ erance aux pannes 5 Contexte universitaire 6 2 / 22

  3. Plan Pourquoi Kerberos ? 1 Les acteurs 2 Le protocole 3 Kerberisation d’une application 4 Tol´ erance aux pannes 5 Contexte universitaire 6 3 / 22

  4. Pourquoi Kerberos ? SSO syst` eme ; Environnement h´ et´ erog` ene ; Tol´ erance aux pannes ; Support´ e par beaucoup d’applications. 4 / 22

  5. Plan Pourquoi Kerberos ? 1 Les acteurs 2 Le protocole 3 Kerberisation d’une application 4 Tol´ erance aux pannes 5 Contexte universitaire 6 5 / 22

  6. Les acteurs KDC (Key Distribution Center) : AS (Authentication Server) et TGS (Ticket Granting Server) ; Principals (Utilisateurs, machines et services) : nom associ´ e ` a un jeu de cl´ es (la mˆ eme passphrase d´ eriv´ ee selon plusieurs algorithmes ou enctypes) ; Realm. 6 / 22

  7. Plan Pourquoi Kerberos ? 1 Les acteurs 2 Le protocole 3 Kerberisation d’une application 4 Tol´ erance aux pannes 5 Contexte universitaire 6 7 / 22

  8. Le protocole : AS Cette phase associ´ ee ` a l’authentification de l’utilisateur lui permet de r´ ecup´ erer son TGT (Ticket Granting Ticket). Le client envoi une requˆ ete AS-REQ comprenant : Nom de son principal (CPN Client Principal Name) ; Timestamp (chiffr´ e avec sa cl´ e priv´ ee si pr´ e-authentification). Le serveur envoi une r´ eponse AS-REP comprenant : Une partie chiffr´ ee avec la cl´ e de l’utilisateur comprenant une cl´ e de session avec le KDC S ; Une partie chiffr´ ee avec la cl´ e secr` ete du serveur de ticket comportant notamment S , un timstamp et l’adresse IP de l’utilisateur (optionnel). C’est le TGT (Ticket Granting Ticket). 8 / 22

  9. Le protocole : TGS (1/2) Cette phase est associ´ ee ` a l’acc` es ` a un service kerberis´ e par l’utilisateur. L’utilisateur poss` ede un TGT valide et une cl´ e de session S lui permettant de chiffrer ses ´ echanges avec le KDC. Le client envoi une requˆ ete TGS-REQ comprenant : Le SPN (Service Principal Name) : le nom du principal de l’application. Le plus souvent de la forme SERVICE/fqdn@REALM (par exemple IMAP/mailer.exemple.fr@EXEMPLE.FR pour un serveur de courrier IMAP) ; Un authentificateur qui contient le nom du principal de l’utilisateur et un timestamp le tout chiffr´ e avec la cl´ e de session S ; le TGT de l’utilisateur. 9 / 22

  10. Le protocole : TGS (2/2) Le serveur envoi une r´ eponse TGS-REP comprenant : Une partie chiffr´ ee avec la cl´ e de session S comportant une cl´ e de session de service s . Cette cl´ e s va se partager entre le client et le service kerberiz´ e vis´ e ; Une partie chiffr´ ee avec la cl´ e du service (c’est ` a dire les cl´ es attach´ ees au principal SERVICE/fqdn@REALM repr´ esentant l’application) comportant ´ egalement la cl´ e de session de service s , un timestamp et l’IP du client ayant demand´ e un acc` es au service (attention aux m´ ecanismes de translation d’adresses). Cette partie constitue le ticket de service. Enfin, le client pr´ esente ` a l’application le ticket de service obtenu. Cette partie n’est pas normalis´ ee. La cl´ e du principal attach´ e ` a l’application est stock´ ee dans un fichier appel´ e keytab. 10 / 22

  11. S´ ecurit´ e : Service KDC ; Pr´ e-authentification pour le dialogue avec l’AS (timestamp dans l’AS-REQ chiffr´ e avec la cl´ e de l’utilisateur) ; KDC Spoofing : requˆ ete vers le KDC-TGS pour le principal host/fqdn@REALM pour finaliser l’ouverture de session (obligatoire dans sssd et optionnel pour pam kerberos). 11 / 22

  12. Plan Pourquoi Kerberos ? 1 Les acteurs 2 Le protocole 3 Kerberisation d’une application 4 Tol´ erance aux pannes 5 Contexte universitaire 6 12 / 22

  13. Kerberization d’une application Lorsque l’on cherche ` a activer le support de Kerberos dans une application, cela se r´ esume ` a trois actions : Cr´ eer un principal pour l’application ; Activer le support de Kerberos dans l’application ; Installer un keytab sur le serveur h´ ebergeant l’application (attention aux permissions et au chroot). 13 / 22

  14. Activation du support de Kerberos Pour une application donn´ ee, le support de Kerberos peut se faire de trois mani` eres : L’application int` egre le code pour g´ erer Kerberos dans ces sources via les librairies MIT / Heimdal ; L’application supporte la configuration de l’authentification via les PAM (Pluggable Authentication Module) ; L’application supporte la SASL (Simple Authentication and Security Layer). 14 / 22

  15. Keytab Fichier contenant les cl´ es du principal associ´ e ` a l’application. Export´ e depuis le KDC, attention ` a la distribution (SCP) ; Permissions ; Standard : /etc/krb5.keytab, sinon d´ efinition dans l’application ou via KRB5 KTNAME. 15 / 22

  16. Plan Pourquoi Kerberos ? 1 Les acteurs 2 Le protocole 3 Kerberisation d’une application 4 Tol´ erance aux pannes 5 Contexte universitaire 6 16 / 22

  17. Tol´ erance aux pannes D´ efinition de plusieurs KDC sur les clients ; M´ ecanismes de r´ eplication : iprop (incr´ emental / synchrone) ; hprop / kprop (compl` ete / asynchrone). 17 / 22

  18. Plan Pourquoi Kerberos ? 1 Les acteurs 2 Le protocole 3 Kerberisation d’une application 4 Tol´ erance aux pannes 5 Contexte universitaire 6 18 / 22

  19. Probl´ ematique OpenLDAP pour les utilisateurs ; Sch´ emas UNRC et Supann ; Utilisateurs d´ evers´ es depuis un base de donn´ ee Oracle Harp` ege / Apog´ ee dans un Slapd maitre ; R´ eplicas accessibles par les applications n´ ecessitants un backend LDAP. Changement de mot de passe se fait sur les bases Oracle, ensuite c’est d´ evers´ e dans LDAP. 19 / 22

  20. Architecture et composants utilis´ es Utilisation du sch´ ema hdb et de l’overlay smbk5pwd sur le OpenLDAP maitre : Sch´ ema hdb compatible avec nos sch´ emas ; Overlay smbk5pwd intercepte l’op´ eration ´ etendue (exop) de changement de mot de passe LDAP pour g´ en´ erer les cl´ es associ´ e au principal. R´ eplication du KDC maitre vers des esclaves SANS serveur Slapd associ´ e : L’exposition r´ eseau des KDC esclaves diff` ere de celles des r´ eplicas LDAP ; Le KDC reste minimal ; Synchronisation compl` ete hprop dans un cron. L’incr´ emental ne fonctionne pas pour nous. 20 / 22

  21. Windows Approbation entre les AD des composantes et le KDC du CRI ; Mappage des comptes Windows ; Connexion au poste de travail avec son uid LDAP (num´ ero Harp` ege / Apog´ ee). 21 / 22

  22. Probl` emes Rattachement des postes itin´ erants (li´ es ` a aucun domaine) ; Cr´ eation d’un realm d´ edi´ e pour eux ; Approbation entre ce realm et celui du CRI ; Interface web sur ce realm d´ edi´ e pour que les correspondants puissent y cr´ eer les principals associ´ es ` a leurs machines itin´ erantes. Communication (Kerberos fait peur). 22 / 22

Recommend


More recommend