Active Directory – SSO avec Kerberos (SPNEGO)

Bien que ce ne soit pas tout récent, il arrive de temps en temps de devoir configurer un SSO d’une application basé sur le protocole Kerberos. JE rencontre souvent ce besoin pour des applications web  hébergées sur des JVM. Bien que SAML soit la voie royal pour le SSO des applications web, SPNEGO est toujours présent et est souvent source d’erreur.

Dans le cas d’applications configurées en haute disponibilité, notamment lors de l’utilisation de VIP pour le NLB /HA, il est toujours possible d’utiliser le SSO sur Kerberos.

Dans le cas ci-dessous, nous allons créer la configuration pour la ressource web :

  • auth.teddycorp.net

Nous allons créer un nouveau SPN dans AD de type http :

  • HTTP/auth.teddycorp.net@mondomain.local
PICTO_AVERTISSEMENT

Notons que le domaine AD n’a pas besoin d’avoir le même UPN que le SPN. Ici domaine AD en @mondomaine.local pour un SPN en @teddycorp.net.

Par contre, toutes les machines (clientes, serveurs web, utilisateurs) doivent être dans le même domaine AD.

Sommaire

Configuration DNS

Pour commencer, il est nécessaire que la résolution DNS du SPN puisse être faites.

Il est nécessaire de créer coté DNS l’enregistrement de type A correspondant à mon SPN, ici “auth.teddycorp.net” ainsi que l’enregistrement PTR qui lui est rattaché. Ne pas utiliser d’autre type d’enregistrement notamment CNAME, uniquement de type A.

Création du compte AD

Dans Active Directory, créer un compte utilisateur. Ce compte sera utiliser pour porter le SPN du service (ici : webSSOTeddy).

Configurer les options suivantes :

  • User cannot change password.
  • Password never expires.
  • This account supports Kerberos AES 265 …
Kerberos SPNEGO Account
AD Account

Notes : Le support d’AES 256 peut-être a ajuster selon la prise en charge de l’application sur lequel le SSO sera configuré.

Vérification des SPN portés sur le compte

Le SPN que nous allons créer /utiliser :

  • HTTP/auth.teddycorp.net@mondomain.local

doit être unique dans le domaine AD.

Pour lister les SPN portés par un compte AD :

setspn -L webSSOTeddy
SPNEGO00020
SETSPN -L

Vu que nous venons de créer le compte utilisateur, celui-ci est vierge.

Si d’autres SPN sont déjà présent sur le compte, ceux-ci doivent être supprimés à l’aide de la commande :

setspn -D HTTP/auth001.teddycorp.net webSSOTeddy
SETSPN -D

Voici la configuration au niveau des SPN que vous devez obtenir sur le compte :

setspn -L webSSOTeddy
SPNEGO00010
SETSPN -L

Création du fichier Keytab

Maintenant, nous pouvons générer le fichier keytab qui sera utilisé par les applications web pour l’authentification SSO.

PICTO_AVERTISSEMENT

Domaine du SPN doit être en majuscule !!!

 

HTTP/auth.teddycorp.net@TEDDYCORP.LOCAL

 

En lien avec la déclaration du fichier krb5.conf

ktpass /out C:\temp\authted.keytab /mapuser webSSOTeddy@teddycorp.local /princ HTTP/auth.teddycorp.net@TEDDYCORP.LOCAL /pass PWD_AD_UserAccount /pType KRB5_NT_PRINCIPAL /kvno 0 /crypto all
SPNEGO00050
KTPASS

La configuration coté AD est terminée, il ne reste que à configurer votre application pour utiliser le fichier KTPASS généré dans la configuration SSO Kerberos.

Vous noterez que la commande KTPASS à mis à jour l’UPN de l’utilisateur avec le SPN déclaré dans la commande KTPASS.

SPNEGO00060
User account

Création du fichier krb5

Le fichier de configuration du realm kerberos, généralement nommé “krb5.ini” ou “krb5.conf” est utilisé quant à lui pour indiquer au server quel kdc adressé.

Je n’ai pas encore une grande maitrise de ce fichier, mais voici un exemple : 

# Other applications require this directory to perform krb5 configuration.
includedir /etc/krb5.conf.d/

includedir /var/lib/sss/pubconf/krb5.include.d/
[logging]
    default = FILE:/var/log/krb5libs.log
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = TEDDYCORP.LOCAL
 dns_lookup_realm = true
 dns_lookup_kdc = true
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = true
    rdns = false
    default_ccache_name = KEYRING:persistent:%{uid}
    default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4
    default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4
    permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4
[realms]
 TEDDYCORP.LOCAL = {
    kdc = DC01.teddycorp.local
    kdc = DC02.teddycorp.local
    default_domain = teddycorp.local
    admin_server = DC01.teddycorp.local

}

[domain_realm]
 teddycorp.local = TEDDYCORP.LOCAL
 .teddycorp.local = TEDDYCORP.LOCAL

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *