Troisième article technique sur la mise en place d'une solution SSO multi-backend d'autentification avec la configuration d'un AD dans LemonLDAP::NG. Cet article n'est pas indispensable puisque le précédent avec LLDAP suffit déjà pour monter une solution SSO.
Vous devez avoir au minimum un serveur AD fonctionnel. Afin de réduire le plus possible la surface d'attaque, le serveur SSO requêtera un serveur RODC à travers un VPN dédié. Bien évidemment, il vous faudra filtrer les flux pour que le serveur SSO se connecte uniquement au port utile du RODC soit le port LDAPS TCP/636. Le serveur RODC sera quant à lui dans une DMZ et n'aura également accès qu'aux port utiles des serveurs DC.
Pour activer LDAPS sur le serveur RODC, il vous faudra créer un certificat au format P12 avec l'extension pfx protéger par un mot de passe sur votre PKI utilisée précédemment. Cet article m'a pas mal aidé https://www.arsouyes.org/blog/2020/35_LDAPs_Active_Directory/index.fr.html
Ensuite sur votre RODC :
PS C:\> $motdepasse = ConvertTo-SecureString -String "LEMOTDEPASSE_XDA" -Force -AsPlainText
PS C:\> Import-PfxCertificate -Password $motdepasse -FilePath .\cert-srv-rodc.domain.lab.pfx -CertStoreLocation Cert:\LocalMachine\My
Il vous faudra également créer un utilisateur AD qui va requêter votre annuaire. Exemple : ssobind.
Enfin je ne veux pas que mes utilisateurs puissent changer leur mot de passe depuis le portail SSO. Nous avons déjà limité l'accès au changement de mot de passe précédemment aux utilisateurs authentifiés sur LLDAP. Je n'ai pas répliqué les mots de passe sur le RODC et l'utilisateur ssobind ne peut que consulter l'annuaire.
Ne pas sauvegarder tant que cela n'est pas indiqué dans cette documentation. Si vous faites tourner LL::NG sur une VM, snpashot, ou backup.
Avant de configurer LL::NG pensez à déclarer le fqdn du RODC dans le fichier "/etc/hosts" du serveur SSO.
Rendez-vous ensuite sur Paramètres généraux > Paramètres de combinaison > Combinaison et saisir "[ADDC] or [LLDAP]
" :
Rendez-vous enfin sur Paramètres généraux > Paramètres de combinaison > Liste des modules. Ajouter les modules suivants nommés LLDAP et ADDC en cliquant sur le bouton "Nouveau module"
LLDAP étant déjà configuré, nous configurerons que le module ADDC.
Pour configurer les paramètres pour la connexion à l'Active Directory, rendez-vous sur Paramètres généraux > Paramètres de combinaison > Liste des modules > ADDC
Paramètre | Valeur |
---|---|
ldapVersion | 3 |
ldapGroupObjectClass | group |
ldapSearchDeref | find |
ldapGroupBase | DC=domain,DC=lab |
ldapGroupAttributeName | member |
ldapBase | DC=domain,DC=lab |
ldapGroupAttributeNameSearch | cn |
ldapGroupAttributeNameUser | dn |
ldapAuthnLevel | 2 |
ldapPwdEnc | utf-8 |
managerDn | CN=ssobind,CN=Users,DC=domain,DC=lab |
managerPassword | SUPERMOTDEPASSEDE_SSO |
AuthLDAPFilter | (&(objectClass=user)(sAMAccountName=$user)) |
ldapPpolicyControl | 0 |
ldapSetPassword | 0 |
ldapPort | 636 |
ldapTimeout | 120 |
ldapGroupRecursive | 1 |
ldapGroupAttributeNameGroup | dn |
ldapServer | ldaps://srv-rodc.domain.lab |
ldapExportedVars | {"group": "group", "mail": "mail", "cn": "cn", "sn": "sn", "uid": "sAMAccountName", "givenName": "givenName"} |
L'attribut ldapExportedVars est très important ici car il permet de mapper l'UID à l'attribut spécifique à l'AD sAMAccountName.
Rappel : L'UID (User IDentifier) dans OpenLDAP et le sAMAccountName dans Active Directory sont des attributs utilisés pour identifier de manière unique un utilisateur dans leurs systèmes respectifs.
Ce qui donne une fois ces paramètres renseignés (le screenshot est tronqué) :
Sauvegardez et tentez une connexion avec un utilisateur de l'AD.
Si vous souhaitez utiliser un user de l'AD pour gérer LL::NG, vous pouvez créer un groupe dédié, par exemple "ssoadmin" et y joindre un utilisateur. Une fois cela fait, rendez-vous sur Hôtes virtuels > manager.domain.tld > Règles d'accès et configurez les accès comme ceci :
(Commentaires) | (Expressions régulières) | (Règles) |
---|---|---|
Configuration | ^/(.*?\.(fcgi|psgi)/)?(manager\.html|confs|prx/|$) |
$uid eq "admin" or inGroup("ssoadmin") |
Notifications | /(.*?\.(fcgi|psgi)/)?notifications |
$uid eq "admin" or inGroup("ssoadmin") |
Sessions | /(.*?\.(fcgi|psgi)/)?sessions |
$uid eq "admin" or inGroup("ssoadmin") |
Note : c'est un exemple de configuration qui permet d'utiliser soit le compte admin de LLDAP, soit un utilisateur faisant parti du groupe "ssoadmin". Si vous reprenez cet exemple, vérifiez que l'utilisateur admin n'existe pas dans votre AD ou bien définissez un groupe dans LLDAP dédié à LL::NG.
Sauvegardez et tentez une connexion au manager avec un utilisateur faisant parti du groupe autorisé.
Pour le prochain article nous configurerons un troisième backend d'authentification avec Kerberos.