Annuaire on slash-root.fr

Keycloak : Federation d’un annuaire LDAPS (Active Directory)

Tue, 23 Aug 2022 15:10:58 +0200

Cet article a pour but de décrire la mise en place de la fédération d'un annuaire LDAPS (Active Directory) au sein d'un royaume Keycloak.

Testé avec un domaine Active Directory On-Premises et avec Azure Active Directory.

Contexte de l’infrastructure

L'infrastructure sur laquelle je vais m'appuyer est la suivante :

1 contrôleur de domaine Active Directory (AD DS) avec sa PKI (AD CS) sous Windows Serveur 2019 Standard
- Domaine : aukfood.lan
- FQDN du contrôleur de domaine : dc01.aukfood.lan
1 serveur Keycloak en version 19.0.1
- Déployé dans docker swarm avec ce stack : /docker-swarm-stack-keycloak-v19-latest/
- URL : keycloak.example.com

Certificat TLS

Note : Les commandes de ce chapitre sont réalisées depuis le serveur hébergeant le conteneur keycloak.

Récupération du certificat

Pour commencer, il va falloir récupérer le certificat TLS utilisé pour la liaison LDAPS.

LDAP = Port 389 TCP

LDAPS = Port 636 TCP

Avec l'utilitaire openssl, il est possible de tester que la liaison LDAPS est fonctionelle ainsi que de récupérer différentes informations (dont le certificat du serveur) :

openssl s_client -connect dc01.aukfood.lan:636

Voici le retour pour cette infra :

depth=0 CN = dc01.aukfood.lan
---
Certificate chain
 0 s:CN = dc01.aukfood.lan
 i:DC = lan, DC = aukfood, CN = aukfood-DC01-CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHLzCCBRegAwIBAgITTAAAAAczDQgCtUWEjAAAAAAABzANBgkqhkiG9w0BAQsF
[...]
AniSQdTOnACZrX//9tDg73RV9w==
-----END CERTIFICATE-----
subject=CN = dc01.aukfood.lan
issuer=DC = lan, DC = aukfood, CN = aukfood-DC01-CA

Copier le Server certificate commençant par -----BEGIN CERTIFICATE----- et se terminant par -----END CERTIFICATE----- dans un fichier server-ldaps.cer :

cat <<EOF > server-ldaps.cer
-----BEGIN CERTIFICATE-----
MIIHLzCCBRegAwIBAgITTAAAAAczDQgCtUWEjAAAAAAABzANBgkqhkiG9w0BAQsF
[...]
AniSQdTOnACZrX//9tDg73RV9w==
-----END CERTIFICATE-----
EOF

Création du keystore

Maintenant que le certificat TLS du contrôleur de domaine a été récupéré, il va falloir l'importer dans un keystore.

Tout d'abord, installer openjdk-11-jre :

sudo apt install openjdk-11-jre

Puis importer le certificat server-ldaps.cer dans un keystore nommé keystore.jks :

keytool -import -trustcacerts -alias dc01.aukfood.lan-CA -file server-ldaps.cer -keystore keystore.jks

Saisir un mot de passe à appliquer au keystore :

Entrez le mot de passe du fichier de clés : 
Ressaisissez le nouveau mot de passe :

Vérifier la présence du certificat dans le keystore généré :

keytool -list -keystore keystore.jks

Après avoir entrer le mot de passe du keystore, le certificat est bien présent :

Entrez le mot de passe du fichier de clés : 
Type de fichier de clés : PKCS12
Fournisseur de fichier de clés : SUN

Votre fichier de clés d'accès contient 1 entrée

dc01.aukfood.lan-ca, 22 août 2022, trustedCertEntry, 
Empreinte du certificat (SHA-256) : 61:EA:83:97:92:[...]:B5:59:EE:2C:8A:2D:EA

Déclaration du keystore

Maintenant que le keystore a été généré avec le certificat TLS du contrôleur de domaine, il va falloir le déclarer au sein de Keycloakpour qu'il puisse être exploité.

Dans la stack keycloak (voir lien en début d'article), un volume conf est monté pour la persistance des données du répertoire /opt/keycloak/conf dans le conteneur.

Envoyer le keystore précédement généré dans le conteneur :

docker cp ./keystore.jks $(docker ps -qf name=keycloak):/opt/keycloak/conf/

Puis ajouter les variables suivantes sur la stack de keycloak :

services:
 app:
 [...]
 environment:
 [...]
 # Indiquer le mot de passe du keystore
 KC_SPI_TRUSTSTORE_FILE_FILE: /opt/keycloak/conf/keystore.jks
 KC_SPI_TRUSTSTORE_FILE_PASSWORD: MotDePasseTresSecure
 [...]

Le MotDePasseTresSecure est celui qui a été indiqué lors de la création du keystore.

Lister les stacks dans docker swarm :

docker stack ls

Identifier l'ID du service docker exécutant

NAME SERVICES ORCHESTRATOR
keycloak 1 Swarm
nextcloud 2 Swarm
portainer 2 Swarm
rocketchat 2 Swarm
swarmpit 4 Swarm
traefik 1 Swarm

La stack faisant tourner le keycloack en v19 est nommé keycloak dans ce cluster docker.

Supprimer la stack keycloak :

docker stack rm keycloak

Puis relancer la stack kycloak pour prendre en compte les nouvelles variables d'environnement concernant le truststore :

docker stack deploy -c ./keycloak/stack.yml keycloak

Le fichier stack.yml est stocké dans un répertoire nommé keycloak de mon répertoire courant. A adapter suivant son emplaccement dans le FHS.

Logs

Avant de passer à la configuration de la fédération de l'annuaire Active Directory via LDAPS à Keycloak, il est important de vérifier et de de s'assurer du bon redémarrage du conteneur.

Pour cela, lister les services en cours au sein du cluster docker :

docker service ls

Identifier le service adéquat (ici : keycloak_app) :

ID NAME MODE REPLICAS IMAGE PORTS
2degmsl8r3se dashy replicated 0/0 lissy93/dashy:latest 
7jq3dje5b0t8 keycloak_app replicated 1/1 quay.io/keycloak/keycloak:latest 
ubq1dvhwv0st nextcloud_app replicated 1/1 nextcloud:latest 
arz4ca4gvfgv nextcloud_mariadb replicated 1/1 mariadb:latest 
vr2c7ptq6a8k portainer_agent global 5/5 portainer/agent:latest 
h6h5merxg9a2 portainer_portainer replicated 1/1 portainer/portainer-ce:latest 
mzsq3uof6c1r rocketchat_mongodb replicated 1/1 bitnami/mongodb:4.4 
tmu3kz5n7xq9 rocketchat_rocketchat replicated 1/1 registry.rocket.chat/rocketchat/rocket.chat:latest 
kos1zg1wowxi swarmpit_agent global 5/5 swarmpit/agent:latest 
gtjs3mikbtaf swarmpit_app replicated 1/1 swarmpit/swarmpit:latest 
nx6s2mt19bzx swarmpit_db replicated 1/1 couchdb:2.3.0 
n5oq9gx05bnd swarmpit_influxdb replicated 1/1 influxdb:1.7 
u7b8rsym5lzp traefik_traefik replicated 1/1 traefik:latest

Vérifier la bonne exécution du service en gardant un shell ouvert avec la lecture des logs en temps réel :

docker service logs -f keycloak_app

Configuration de la fédération LDAPS

Note : A partir de maintenant, la configuration est à effectuer à travers la console web d'administration du service Keycloak.

User federation

Sélectionner le royaume adéquat ou en créer un nouveau (1), puis se rendre sur User federation (2) :

Ajouter un fournisseur LDAP :

Note : Pour les explications des différents champs, leurs fonctions, leurs utilités, etc... qui vont suivre, se référer à cet article que j'ai écris en 2021 sur l'intégration d'un annuaire LDAP (OpenLDAP, huhu) : /keycloak-integration-ldap-externe/

Tous les paramètres de synchronisation y sont traités :

Gestion du stockage des utilisateurs
L'influence du mode Import Users sur les requêtes LDAP (LDAPS, même combat)
L'Edit Mode et ses différents paramètres
Les types de Vendor
Les différents champs Users DN ou Bind DN
Les configurations possibles pour la synchronisation ainsi que leurs périodicités

General options

(1) Console display name : Entrer un nom afin d'identifier cette fédération d'utilisateurs au sein de Keycloak.
(2) Vendor : Indiquer le type d'annuaire.

Connection and authentication settings

(1) Connection URL : Renseigner l'URL de connexion à l'annuaire LDAPS sous la forme ldaps://FQDN_DC:636. Cette URL doit correspondre au "Common Name" du certificat. Celui-ci peut être identifié lors de l'utilisation de la commande openssl au début de cet article.

(2) Use Truststore SPI : Indiquer l'utilisation du truststore javax.net.ssl.trustStore (pour le keystore.jks) uniquement pour ldaps.

(3) Bind DN : Indiquer le DistinguishedName de l'utilisateur de l'annuaire qui sera utilisé par Keycloak. Pour le récupérer facilement :

Get-ADUser UTILISATEUR_AD | FT DistinguishedName

(4) Bind credentials : Mettre le mot de passe de l'utilisateur indiqué au point précédent.

A noter que pour le moment, il manque des informations dans le paramétrage de la liaison LDAPS. De ce fait, le "Test connection" et le "Test authentication" ne sont pas encore réalisables (Une des différences avec les versions de Keycloak sous Wildfly en version 16 et inférieure).

LDAP searching and updating

(1) Edit mode : Définir le mode d'édition de l'annuaire.

(2) Users DN : Indiquer le DistinguishedName de l'OU contenant les utilisateurs à fédérer.

Tests et import utilisateurs

Il est maintenant possible de tester la connexion LDAPS et l'authenfication.

Ces 2 tests doivent aboutir :

Ensuite, en haut à droite de la page, bien s'assurer que cette fédération soit enabled. Puis dans action (1), déclencher la synchronisation (2) de tous les utilisateurs :

L'importation des utilisateurs aboutie :

Dans les utilisateurs du royaume Keycloak, je retrouve bien les utilisateurs contenus dans l'OU définit dans la fédération.

Mappers

Dans ce contexte, l'utilisateur "Julien LOUIS", se retrouve avec un username contenant des espaces. Cela est dû au faites que l'attribut cn de l'annuaire a été mappé vers l'attribut username de Keycloak.

Pour voir tous les utilisateurs du royaume keycloak (fédération incluse), rechercher ***** comme utilisateur.

De plus, pour l'utilisateur final, cela ne correspondra pas au login auquel il est habitué d'utiliser.

Pour modifier ce comportement, il faut mapper l'attribut sAMAccountName de l'anuaire Active Directory vers l'attribut username de Keycloak.

Se rendre sur les paramétrages de la fédération précédement réalisée, puis dans l'onglet Mappers (1), éditer le mapper username (2) :

Modifier le champ LDAP Attribute pour y inscrire sAMAccountName :

Puis, enregistrer la modification en bas de page.

Ensuite, dans l'onglet Settings, modifier l'Username LDAP attribute en y inscrivant sAMAccountName :

Puis, enregistrer la modification en bas de page.

En relançant la synchronisation de tous les utilisateurs de l'annuaire vers Keycloak, les utilisateurs sont mis à jour :

A présent, le login des utilisateurs importés dans Keycloak est correctement paramétré.

Keycloak : Integration LDAP externe

Thu, 04 Nov 2021 17:33:31 +0100

Introduction

La solution Keycloak est embarqué avec la possibilité de joindre un annuaire LDAP/AD. Il est possible de fédérer plusieurs serveurs d'annuaires au sein d'un même royaume keycloak. Les attributs utilisateurs de l'annuaire LDAP peuvent être mappé dans un model d'utilisateur keycloak. Par défaut, les attributs username, email, first name, last name sont mappés mais d'autres attributs peuvent l'être également.

Cet article fait suite à :

Keycloak : Installation avec Docker et reverse-proxy SSL Nginx

OpenLDAP : Installation avec FusionDirectory

Prérequis

Un serveur Keycloak fonctionnel
Un serveur OpenLDAP/FusionDirectory fonctionnel

Toute la procédure fera référence aux configuration déployées dans les articles cités en introduction.

Configuration

Se rendre sur la WebUI du serveur Keycloak : https://keycloak.example.com
Se rendre dans la partie User Federation et ajouter ldap en provider :

Paramétrage - 1ère partie

Stockage

Par défaut, Keycloak importe les utilisateurs de l'annuaire LDAP dans sa base locale d'utilisateurs. Cette copie des utilisateurs peut être synchronisée soit manuellement soit automatiquement toutes les x minutes par exemple. Seul les mots de passes ne sont pas synchronisés. Dans le processus d'identification de l'utilisateur, la validation du mot de passe est délégué au serveur LDAP. L'avantage de cette approche est que toutes les fonctionnalités de Keycloak fonctionneront avec des attributs utilisateurs supplémentaires qui sont stockés localement sur Keycloak. Cela permet également de réduire la charge sur le serveur LDAP.

Il est possible de ne pas importer les utilisateurs de l'annuaire LDAP dans Keycloak en décochant Import Users. Cela aura pour effet d'augmenter les requêtes vers le serveur LDAP car aucune information utilisateur ne sera stockée localement sur Keycloak. L'autre conséquence de ce choix est que si une fonctionnalité de Keycloak repose sur une partie non supporté par l'annuaire LDAP, celle-ci ne fonctionnera pas. En revanche, l'avantage est de ne pas avoir à gérer la synchronisation des comptes.

Edition

L'Edit Mode permet aux utilisateurs et aux administrateurs, à travers leurs consoles respectives sur Keycloak, de modifier les metadas utilisateur.

READONLY : Les attributs utilisateurs resteront inchangés. Une erreur apparaitra si une modification d'attribut est faites. Cela est également valable pour la modification d'un mot de passe utilisateur.
WRITABLE : Tous les attributs utilisateurs modifiés seront synchronisés automatiquement avec l'annuaire LDAP.
UNSYNCED : Tous les changements d'attributs seront stockés localement dans la base de Keycloak. La synchronisation des modifications au sein de Keycloak vers l'annuaire LDAP devra être faites manuellement.

Vendor

Plusieurs choix sont possibles suivant le type d'annuaire LDAP en face :

Active Directory
Red Hat Directory Server
Tivoli
Novell eDirectory
Other

L'annuaire installé étant OpenLDAP, other est le choix à faire.

Paramétrage - 2nd partie

Connection URL : Indiquer le chemin d'accès au serveur LDAP
Users DN : Indiquer le chemin d'accès aux utilisateurs dans l'annuaire.
Bind DN : Indiquer un compte dans l'annuaire ayant des droits d'écriture.
Bind Credential : Le mot de passe du compte spécifié dans "Bind DN".

Synchronisation

Un peu plus bas de la page de configuration de la connexion au serveur LDAP, un menu Sync Settings est disponible :

Batch Size : Le nombre de compte utilisateurs qui seront traités en une synchronisation.
Periodic Full Sync : La planification en secondes de la synchronisation totale / complète.
Periodic Changed Users Sync : La planification en secondes de la synchronisation des changements apportés aux attributs utilisateurs.

Après avoir sauvegarder tous les paramètres, il est possible de déclencher manuellement une première synchronisation des utilisateurs de l'annuaire LDAP dans Keycloak :

Mappers

Par défaut, des Mappers sont mis en place. Un mapper va permettre de mapper un attribut utilisateur de l'annuaire LDAP à un attribut utilisateur de Keycloak :

Dans mes différents essais, en déployant cette solution de SSO avec un OpenLDAP, il est apparu que l'attribut firstName de Keycloak est mappé avec l'attribut cn de l'annuaire LDAP. L'attribut cn dans l'annuaire (avec la couche FusionDirectory) est une concaténation du prénom et du nom de l'utilisateur :

Au lieu de modifier la configuration de l'annuaire LDAP, modifier le mapper first name dans Keycloak :

Modifier LDAP Attribute pour indiquer givenName.

givenName est le nom de l'attribut prénom au sein de l'annuaire LDAP dans notre configuration.

OpenLDAP : Installation avec FusionDirectory

Thu, 04 Nov 2021 13:12:04 +0100

Introduction

OpenLDAP est un annuaire informatique qui fonctionne sur le modèle client/serveur. Il contient des informations de n'importe quelle nature qui sont rangées de manière hiérarchique. Pour bien comprendre le concept, il est souvent comparé aux pages jaunes, où le lecteur recherche un numéro de téléphone particulier : il va d'abord sélectionner la profession, puis la ville, puis le nom de l'entrée pour trouver finalement le numéro de téléphone. En pratique, dans un réseau informatique, il est utilisé pour enregistrer une grande quantité d'utilisateurs ou de services, parfois des centaines de milliers. Il permet d'organiser hiérarchiquement les utilisateurs par département, par lieu géographique ou par n'importe quel autre critère. C'est une alternative libre à Microsoft Active Directory.

Source : OpenLDAP — Wikipédia (wikipedia.org)

FusionDirectory est une application web qui permet la gestion des infrastructures et le déploiement des systèmes. Son but est de faciliter le travail de l’administrateur système indépendamment de la taille et de la variété du parc à gérer.

Source : FusionDirectory — Wikilivres (wikibooks.org)

Dans cet article, je vais présenter l'installation et la configuration initiale d'OpenLDAP avec FusionDirectory sur un même serveur Debian 10 fraîchement installé avec les outils de base.

Prérequis

Un serveur Debian 10 fraîchement installé et à jour.
Une adresse IP statique doit être configuré sur le serveur.

Le nom d'hôte du serveur doit être le FQDN futur dans l'annuaire ldap.

Vérifier les fichiers /etc/hostname et /etc/hosts.

# Exemple d'un fichier /etc/hostname
srv-ldap.domaine.local

# Exemple d'un fichier /etc/hosts
127.0.0.1 localhost
127.0.1.1 srv-ldap
192.168.1.10 srv-ldap.domaine.local srv-ldap

Installation

OpenLDAP

Installer les paquets nécessaires :
```
sudo apt install slapd ldap-utils
```
Saisir le mot de passe souhaité pour le compte admin de l'annuaire :
Saisir une seconde fois le mot de passe pour confirmer.
Vérifier l'installation d'OpenLDAP :
```
sudo slapcat
```

Voici le retour attendu :

dn: dc=domaine,dc=local
objectClass: top
objectClass: dcObject
objectClass: organization
o: domaine.local
dc: domaine
structuralObjectClass: organization
entryUUID: a91714fa-d1a0-103b-9752-7ba3681b6a0b
creatorsName: cn=admin,dc=domaine,dc=local
createTimestamp: 20211104095226Z
entryCSN: 20211104095226.276305Z#000000#000#000000
modifiersName: cn=admin,dc=domaine,dc=local
modifyTimestamp: 20211104095226Z

dn: cn=admin,dc=domaine,dc=local
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: e1NTSEF9bHRGR2hnUTNCMTdLcWlUSTI1UVU2TjI2d3U4dmhydWc=
structuralObjectClass: organizationalRole
entryUUID: a9175640-d1a0-103b-9753-7ba3681b6a0b
creatorsName: cn=admin,dc=domaine,dc=local
createTimestamp: 20211104095226Z
entryCSN: 20211104095226.278012Z#000000#000#000000
modifiersName: cn=admin,dc=domaine,dc=local
modifyTimestamp: 20211104095226Z

La configuration du schéma de l'annuaire sera faites à travers FusionDirectory.

FusionDirectory

Récupérer et ajouter la clef GPG officielle de FusionDirectory :

wget https://public.fusiondirectory.org/FD-archive-key
sudo apt install -y gnupg2 && sudo apt-key add FD-archive-key

Ajouter le repository de fusiondirectory pour debian :

sudo cat > /etc/apt/sources.list.d/fusiondirectory-release.list << 'EOL'
#fusiondirectory repository
deb https://public.fusiondirectory.org/stretch-fusiondirectory-release/ stretch main
EOL

Ajouter le repository de schema2ldif pour debian :

sudo cat > /etc/apt/sources.list.d/schema2ldif-release.list << 'EOL'
#latest version of schema2ldif
deb https://public.fusiondirectory.org/stretch-schema2ldif-release/ stretch main
EOL

Mettre à jour la liste des paquets :
```
sudo apt update
```
Les repositories étant en https, installer le paquet apt-transport-https :
```
sudo apt install apt-transport-https
```

Installer les paquets pour FusionDirectory :

sudo apt install fusiondirectory fusiondirectory-schema

Apache2 sera déployé en même temps. Il est possible de se reposer sur un autre serveur web mais cela ne sera pas abordé ici.

Installer les paquets manquant pour PHP :
```
sudo apt install php-xml
```
Installer les schémas FusionDirectory dans la base LDAP :
```
sudo fusiondirectory-insert-schema
```
Redémarrer Apache2 :
```
sudo systemctl restart apache2.service
```

Configuration

Se connecter à la WebUI de FusionDirectory : http://srv-ldap.domaine.local/fusiondirectory/
Pour accéder au serveur, il est nécessaire de mettre un token dans un fichier. Celui-ci est indiquer sur la WebUI :

Copier / Coller la commande avant de cliquer sur Suivant :

sudo echo -n cm5ch69brdj9jdm8uejjrfans0 > /var/cache/fusiondirectory/fusiondirectory.auth

Configurer la langue :
Vérifier que l'installation soit entièrement en vert avant de continuer :
Vérifier les informations de connexion au serveur LDAP et saisir le mot de passe du compte admin de l'annuaire spécifié lors de l'installation d'OpenLDAP plus haut :
Régler le fuseau horaire :

La configuration par défaut est conservé dans cette procédure. Il est bien évidement possible de la modifier plus tard pour par définir une politique de sécurité des mots de passes par exemple.

Une inspection LDAP est effectuée et propose plusieurs actions afin d'être pleinement compatible avec FusionDirectory. Effectuer les actions nécessaires :
Télécharger le fichier de configuration :
Placer ce fichier fusiondirectory.conf dans le répertoire du serveur /etc/fusiondirectory/.
Vérifier la configuration de FusionDirectory :
```
sudo fusiondirectory-setup --check-config
```

Une erreur est détectée. Répondre Yes afin de corriger les permissions du fichier de configuration de fusion :

Checking FusionDirectory's config file
/etc/fusiondirectory/fusiondirectory.conf exists…
/etc/fusiondirectory/fusiondirectory.conf is not set properly, do you want to fix it ?: [Yes/No]?
Yes

OpenLDAP et FusionDirectory sont fonctionnels :

Attribut mail

Par défaut, il n'y pas d'attribut mail sur un utilisateur. Cependant, il est possible de l'ajouter.

Installer les paquets nécessaires :

sudo apt install fusiondirectory-plugin-mail fusiondirectory-plugin-mail-schema

Modifier le schéma de l'annuaire afin de faire apparaitre l'attribut mail :

sudo fusiondirectory-insert-schema -i /etc/ldap/schema/fusiondirectory/mail-fd.schema

Il est désormais possible de spécifier une adresse mail pour les utilisateurs :

Samba : Installation d’un contrôleur de domaine

Fri, 29 Oct 2021 10:40:56 +0200

Introduction

Samba permet d'implémenter le protocole propriétaire SMB/CIFS de Microsoft sous un environnement Unix et ses dérivés. Il offre la possibilité de partager des ressources dans un SI hétérogène Windows/Linux.

A partir de la version 3, Samba fournit le partage de fichiers/imprimantes et peut intégrer un domaine Active Directory en tant que membre. Il peut également être PDC (Primary Domain Controller) avec un niveau fonctionnel NT4.

A partir de la version 4, Samba peut servir de contrôleur de domaine Active Directory avec un niveau fonctionnel Windows Server 2008 et offre les services d'authentification AD. Des GPOs peuvent être déployées.

Dans cette procédure, une distribution Debian 10 et Samba en version 4 sont utilisées.

Le serveur samba sera nommé : srv-samba
Le domaine sera : domaine.local
L'adresse IP du serveur samba sera : 192.168.1.10

Préparation

Modifier le nom du serveur en y indiquant le futur domaine :

sudo echo "srv-samba.domaine.local" > /etc/hostname # Pour la persistence après un reboot
sudo hostname $(cat /etc/hostname) # Pour modifier le nom sans avoir à reboot

Attribuer une adresse IP fixe :

sudo vi /etc/network/interfaces
# Exemple :
# auto ens18
# iface ens18 inet static
# address 192.168.1.10
# netmask 255.255.255.0
# gateway 192.168.1.254

Modifier le fichier hosts en conséquence :

sudo echo "192.168.1.10 srv-samba.domaine.local srv-samba" >> /etc/hosts

Installation et configuration de Samba

Installation des paquets nécessaires :
```
sudo apt -y install samba krb5-config winbind smbclient
```
- Modifier smb.conf pour utiliser les paramètres WINS fournis par DHCP ? : Non
- Royaume (« realm ») Kerberos version 5 par défaut : domaine.local
- Serveurs Kerberos du royaume : srv-samba.domaine.local
- Serveur administratif du royaume Kerberos : srv-samba.domaine.local
Samba est installé.

Création du domaine

Renommer le fichier de configuration principal de samba /etc/samba/smb.conf :
```
sudo mv /etc/samba/smb.conf /etc/samba/smb.conf.org
```
Provisionner le domaine :
```
sudo samba-tool domain provision
```
- Realm [DOMAINE.LOCAL]: Appuyer sur Entrée
- Domain [DOMAINE]: Appuyer sur Entrée
- Server Role (dc, member, standalone) [dc]: Appuyer sur Entrée
- DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]: Appuyer sur Entrée (Le serveur DNS sera interne à Samba dans cette installation)
- DNS forwarder IP address (write 'none' to disable forwarding) [1.1.1.1]: Appuyer sur Entrée
- Administrator password: Saisir le mot de passe admin du domaine
- Retype password: Ressaisir le mot de passe admin du domaine

Le domaine est créé :

Looking up IPv4 addresses
Looking up IPv6 addresses
No IPv6 address will be assigned
Setting up share.ldb
Setting up secrets.ldb
Setting up the registry
Setting up the privileges database
Setting up idmap db
Setting up SAM db
Setting up sam.ldb partitions and settings
Setting up sam.ldb rootDSE
Pre-loading the Samba 4 and AD schema
Unable to determine the DomainSID, can not enforce uniqueness constraint on local domainSIDs

Adding DomainDN: DC=domaine,DC=local
Adding configuration container
Setting up sam.ldb schema
Setting up sam.ldb configuration data
Setting up display specifiers
Modifying display specifiers and extended rights
Adding users container
Modifying users container
Adding computers container
Modifying computers container
Setting up sam.ldb data
Setting up well known security principals
Setting up sam.ldb users and groups
Setting up self join
Adding DNS accounts
Creating CN=MicrosoftDNS,CN=System,DC=domaine,DC=local
Creating DomainDnsZones and ForestDnsZones partitions
Populating DomainDnsZones and ForestDnsZones partitions
Setting up sam.ldb rootDSE marking as synchronized
Fixing provision GUIDs
A Kerberos configuration suitable for Samba AD has been generated at /var/lib/samba/private/krb5.conf
Merge the contents of this file with your system krb5.conf or replace it with this one. Do not create a symlink!
Once the above files are installed, your Samba AD server will be ready to use
Server Role: active directory domain controller
Hostname: srv-samba
NetBIOS Domain: DOMAINE
DNS Domain: domaine.local
DOMAIN SID: S-1-5-21-1555810112-1359199810-2012430263

Mise en service du domaine

Copier le fichier de configuration de kerberos dans le répertoire /etc :
```
sudo cp /var/lib/samba/private/krb5.conf /etc/
```
Arrêter les services SMB, NMBD et Bind :
```
sudo systemctl stop smbd nmbd winbind
```
Désactiver les services SMB, NMBD et Bind :
```
sudo systemctl disable smbd nmbd winbind
```
Rendre visible le service samba-ad-dc :
```
sudo systemctl unmask samba-ad-dc
```
Démarrer le service :
```
sudo systemctl start samba-ad-dc
```
Activer le service :
```
sudo systemctl enable samba-ad-dc
```
Vérifier le statut de Samba :
```
smbclient -L localhost -U%
```

Tout est OK :

 Sharename Type Comment
 --------- ---- -------
 netlogon Disk
 sysvol Disk
 IPC$ IPC IPC Service (Samba 4.9.5-Debian)
Reconnecting with SMB1 for workgroup listing.

 Server Comment
 --------- -------

 Workgroup Master
 --------- -------
 WORKGROUP SRV-SAMBA

Vérifier le niveau fonctionnel du domaine :
```
sudo samba-tool domain level show
```

Le niveau fonctionnel du domaine est Windows 2008 R2 :

Domain and forest function level for domain 'DC=domaine,DC=local'

Forest function level: (Windows) 2008 R2
Domain function level: (Windows) 2008 R2
Lowest function level of a DC: (Windows) 2008 R2

Création utilisateur

Créer un 1er utilisateur dans l'annuaire :
```
sudo samba-tool user create superman
```

Indiquer le mot de passe de superman :

New Password:
Retype Password:
User 'superman' created successfully

Jonction au domaine

La jonction au domaine d'un poste Windows est identique qu'avec un contrôleur de domaine Microsoft. Les outils d'administrations (RSAT) peuvent être employé pour administrer les objets du domaine (dsa.msc), les gpo (gpmc.msc), le serveur dns (dnsmgmt.msc)...

Avec un DC Microsoft, un compte utilisateur du domaine peut être employé pour joindre un poste au domaine. Avec samba, le compte administrator doit être employé.