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

kerberos
SMART_READER_LITE
LIVE PREVIEW

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


slide-1
SLIDE 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

slide-2
SLIDE 2

Sommaire

1

Pourquoi Kerberos ?

2

Les acteurs

3

Le protocole

4

Kerberisation d’une application

5

Tol´ erance aux pannes

6

Contexte universitaire

2 / 22

slide-3
SLIDE 3

Plan

1

Pourquoi Kerberos ?

2

Les acteurs

3

Le protocole

4

Kerberisation d’une application

5

Tol´ erance aux pannes

6

Contexte universitaire

3 / 22

slide-4
SLIDE 4

Pourquoi Kerberos ?

SSO syst` eme ; Environnement h´ et´ erog` ene ; Tol´ erance aux pannes ; Support´ e par beaucoup d’applications.

4 / 22

slide-5
SLIDE 5

Plan

1

Pourquoi Kerberos ?

2

Les acteurs

3

Le protocole

4

Kerberisation d’une application

5

Tol´ erance aux pannes

6

Contexte universitaire

5 / 22

slide-6
SLIDE 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

slide-7
SLIDE 7

Plan

1

Pourquoi Kerberos ?

2

Les acteurs

3

Le protocole

4

Kerberisation d’une application

5

Tol´ erance aux pannes

6

Contexte universitaire

7 / 22

slide-8
SLIDE 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

slide-9
SLIDE 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

slide-10
SLIDE 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

slide-11
SLIDE 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

slide-12
SLIDE 12

Plan

1

Pourquoi Kerberos ?

2

Les acteurs

3

Le protocole

4

Kerberisation d’une application

5

Tol´ erance aux pannes

6

Contexte universitaire

12 / 22

slide-13
SLIDE 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

slide-14
SLIDE 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

slide-15
SLIDE 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

slide-16
SLIDE 16

Plan

1

Pourquoi Kerberos ?

2

Les acteurs

3

Le protocole

4

Kerberisation d’une application

5

Tol´ erance aux pannes

6

Contexte universitaire

16 / 22

slide-17
SLIDE 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

slide-18
SLIDE 18

Plan

1

Pourquoi Kerberos ?

2

Les acteurs

3

Le protocole

4

Kerberisation d’une application

5

Tol´ erance aux pannes

6

Contexte universitaire

18 / 22

slide-19
SLIDE 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

slide-20
SLIDE 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

slide-21
SLIDE 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

slide-22
SLIDE 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