Différences

Ci-dessous, les différences entre deux révisions de la page.

--- utilisateurs:qedinux:samba_ad_dc_members [Le 12/01/2015, 18:30]
Qedinux [ssh] Renouvellement du /etc/krb5.keytab
+++ utilisateurs:qedinux:samba_ad_dc_members [Le 11/09/2022, 13:15] (Version actuelle)
moths-art Suppression des espaces en fin de ligne (détecté et corrigé via le bot wiki-corrector (https://forum.ubuntu-fr.org/viewtopic.php?id=2067892)
@@ Ligne 1: / Ligne 1: @@
-{{tag>samba administration windows réseau}}
+~~REDIRECT>tutoriel/samba_ad_dc_members~~
 ====== Samba AD DC - Intégration de machines au domaine ======
-Cette page détaille une possibilité d'intégration d'une machine Ubuntu dans un domaine [[:samba-active-directory|Samba - Active Directory Domain Controller (AD DC)]]. Pour l'exemple, le nom de la machine qui sera jointe au domaine est UBNWKS01.
+L'intégration d'une machine dans un domaine Active Directory (AD) va permettre d'authentifier les utilisateurs du domaine sur cette machine. Cette authentification se fait vis-à-vis d'un domaine contrôleur (DC).
+La création d'un domaine contrôleur Active Directory est détaillée dans [[:samba-active-directory|Samba - Active Directory Domain Controller (AD DC)]]. Pour l'exemple, le nom de la machine qui sera jointe au domaine est UBNWKS01.
 ===== Prérequis =====
@@ Ligne 38: / Ligne 40: @@
 <code>dig doc.ubuntu-fr.org</code>
-==== Synchronisation NTP ====
+==== Synchronisation du temps ====
-La synchronisation du temps entre les machines qui utilisent l'authentification Kerberos est indispensable. L'authentification Kerberos est une des fonctionnalités de Samba AD DC. Pour ce faire, il faut installer le paquet **[[apt>ntp]]**
+Pour plusieurs raisons dont l'authentification Kerberos, la synchronisation des horloges entre les machines est indispensable.
+Pour ce faire, il faut installer le paquet **[[apt>ntp]]**
 <code>sudo apt-get install ntp</code>
@@ Ligne 72: / Ligne 76: @@
 Il faut installer le paquet **[[apt>samba]]**
 <code>sudo apt-get install samba</code>
+Stopper les services
+<code>sudo service smbd stop
+sudo service nmbd stop</code>
 ==== Configurer samba ====
 La configuration de samba peut être réécrite comme suit :
 <file - /etc/samba/smb.conf>
 # Global parameters
 [global]
         workgroup = EXAMPLE
@@ Ligne 97: / Ligne 105: @@
         winbind enum groups = yes
         winbind refresh tickets = yes
         kerberos method = system keytab
 </file>
@@ Ligne 104: / Ligne 112: @@
 Les lignes //idmap config *:... // définissent le backend tdb (base de données locale) et la plage d'identifiants pour les utilisateurs et groupes venant d'autres domaines. On retrouve ici entre-autre les groupes venant de BUILTIN. Par défaut, une machine qui rejoint le domaine reçoit deux groupes locaux, //BUILTIN\Administrators// et //BUILTIN\Users//. Par défaut, le groupe //EXAMPLE\Domain Admins// est membre du groupe //BUILTIN\Administrators// et le groupe //EXAMPLE\Domain Users// est membre du groupe //BUILTIN\Users//. Les autres groupes qui seraient créés localement sur la machine auront la forme //UBNWKS01\Nom du groupe//.
-Les lignes //winbind ...// définissent d'autres options pour l'utilisation de //winbind//. Notamment, la ligne //use default domain// permet de ne pas devoir inscrire à chaque fois le nom du domaine pour un utilisateur ou un groupe appartenant au domaine par défaut.
+Les lignes //winbind ...// définissent d'autres options pour l'utilisation de //winbind//. Notamment, la ligne //use default domain// permet de ne pas devoir inscrire à chaque fois le nom du domaine pour un utilisateur ou un groupe appartenant au domaine par défaut. La ligne //winbind offline logon// permet de
-**__A vérifier:__** La ligne //kerberos method = system keytab// permet de générer un fichier keytab (/etc/krb5.keytab). Ce fichier est une clé d'authentification Kerberos pour la machine (UBNWKS01$). Cette clé comme toute autre clé Kerberos expirera (après 10 jours ?). Le service //samba// maintiendra à jour cette clé en la renouvelant régulièrement.
+La ligne //kerberos method = system keytab// va générer, lorsque l'on joint la machine au domaine, et maintenir à jour un fichier keytab propre à la machine (/etc/krb5.keytab). Ce fichier est le jeton d'authentification Kerberos pour la machine (UBNWKS01$). Ce jeton comme toute autre jeton Kerberos expire après un certain délais (10 jours ?). Avec cette option, le service //samba// maintient à jour ce jeton en le renouvelant régulièrement à condition d'avoir une connexion avec le DC.
 ==== Appliquer les modifications ====
-Il faut arrêter et redémarrer les services //smbd// et //nmbd//.
+Redémarrer les services //smbd// et //nmbd//.
-<code>sudo service smbd stop && sudo service nmbd stop
+<code>sudo service smbd start
-sudo service smbd start && sudo service nmbd start</code>
+sudo service nmbd start</code>
 ==== Joindre la machine au domaine ====
@@ Ligne 118: / Ligne 126: @@
 Using short domain name -- EXAMPLE
 Joined 'UBNWKS01' to dns domain 'example.com'
-No DNS domain configured for ubnwks01. Unable to perform DNS Update.
+</code>
-DNS update failed: NT_STATUS_INVALID_PARAMETER</code>
-<note>FIXME "No DNS domain configure for ubnwks01. Unable to perform DNS Update. DNS update failed ..."
+<note>En cas d'erreur: "No DNS domain configure for ubnwks01. Unable to perform DNS Update. DNS update failed ..."
-On peut ajouter manuellement le record dans le DNS avec la commande samba-tool comme suit :
+Ceci peut résulter du fait que le fichier /etc/hostname ne contenait pas le FQDN de la machine. Pour y remédier, on peut ajouter manuellement le record dans le DNS avec la commande qui suit :
-<code>samba-tool dns add ubndc01 example.com ubnwks01 A 192.168.1.101 -U Administrator</code>
+<code>samba-tool dns add ubndc01 example.com ubnwks01 A 192.168.1.101 -U Administrator</code></note>
-Aucun problème rencontré, si /etc/hostname contient le FQDN et pas uniquement le nom et /etc/hosts adapté avec FQDN et nom simple. Les services smbd et nmbd étaient arrêtés. A ce moment, un record A est ajouté dans la zone DNS du domaine. Encore à vérifier...</note>
+==== Ticket Kerberos de la machine ====
+Si la ligne //kerberos method = system keytab// était présente dans la partie globale du fichier /etc/samba/smb.conf, un fichier /etc/krb5.keytab a été crée lorsque la machine a été jointe au domaine. Ce fichier contient le ticket Kerberos de la machine (UBNWKS01$). De par sa nature, cette information est sensible et donc protégée par des droits d'accès restreints (''%%-rw------%% root root''). Tant que la ligne //kerberos method = system keytab//, ce jeton d'authentification sera renouvellé à temps à condition de ne pas dépasser le délais de renouvellement.
+On peut vérifier si le fichier existe avec
+<code>ls -l /etc/krb5.keytab
+-rw------- 1 root root 1057 Nov  4 19:37 /etc/krb5.keytab</code>
+Avec les [[utilisateurs:qedinux:samba_ad_dc_members#kerberos|outils Kerberos]], on peut lire ce ticket
+<code>sudo klist -ket
+Keytab name: FILE:/etc/krb5.keytab
+KVNO Timestamp           Principal
+---- ------------------- ------------------------------------------------------
+11/04/2014 19:37:24 host/ubnwks01.example.com@EXAMPLE.COM (des-cbc-crc)
+11/04/2014 19:37:24 host/ubnwks01.example.com@EXAMPLE.COM (des-cbc-md5)
+11/04/2014 19:37:24 host/ubnwks01.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
+11/04/2014 19:37:24 host/ubnwks01.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
+11/04/2014 19:37:24 host/ubnwks01.example.com@EXAMPLE.COM (arcfour-hmac)
+11/04/2014 19:37:24 host/ubnwks01@EXAMPLE.COM (des-cbc-crc)
+11/04/2014 19:37:24 host/ubnwks01@EXAMPLE.COM (des-cbc-md5)
+11/04/2014 19:37:24 host/ubnwks01@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
+11/04/2014 19:37:25 host/ubnwks01@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
+11/04/2014 19:37:25 host/ubnwks01@EXAMPLE.COM (arcfour-hmac)
+11/04/2014 19:37:25 UBNWKS01$@EXAMPLE.COM (des-cbc-crc)
+11/04/2014 19:37:25 UBNWKS01$@EXAMPLE.COM (des-cbc-md5)
+11/04/2014 19:37:25 UBNWKS01$@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
+11/04/2014 19:37:25 UBNWKS01$@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
+11/04/2014 19:37:25 UBNWKS01$@EXAMPLE.COM (arcfour-hmac)
+</code>
+On peut vérifier que ce fichier est toujours valide pour authentifier la machine et ses services vis-à-vis du serveur Kerberos
+<code>sudo kinit -V -k 'UBNWKS01$' -c /dev/null
+Using default cache: /tmp/krb5cc_1000
+Using principal: UBNWKS01$@EXAMPLE.COM
+Authenticated to Kerberos v5
+</code>
+La ligne //Authenticated to Kerberos v5// témoigne de la bonne exécution et donc de la validité du fichier /etc/krb5.keytab. Si au contraire, on reçoit //kinit: Bad encryption type while getting initial credentials//. Ceci signifie que le ticket d'authentification présent dans ce fichier est expiré. Il faut le régénérer avec la commande //net ads keytab create//. On verra alors avec la commande //klist -ket// que le chiffre dans la colonne KVNO a été incrémenté (une ou plusieurs fois)
+Si le fichier /etc/krb5.keytab n'existe pas ou que le ticket d'authentification a expiré, il faut vérifier la présence de la ligne //kerberos method = system keytab// dans la partie globale du fichier /etc/samba/smb.conf et recréer manuellement le fichier. Deux opérations sont nécessaires. La première consiste à obtenir un ticket Kerberos au nom de //Administrator// (un compte du domaine possédant les droits d'administration sur celui-ci) pour le superutilisateur //root//.
+<code>sudo kinit administrator
+Password for administrator@EXAMPLE.COM:</code>
+La seconde interroge le DC pour recevoir un nouveau jeton et crée le fichier /etc/krb5.keytab sur la machine.
+<code>sudo net ads keytab create -k</code>
+<note tip>Vous recevez un avertissement si le paramètre "kerberos method" n'est pas définit dans /etc/samba/smb.conf
+<code>Warning: "kerberos method" must be set to a keytab method to use keytab functions.</code>
+</note>
+Finalement et pour la sécurité, on peut détruire le ticket Kerberos utilisé avec les droits root
+<code>sudo kdestroy</code>
-===== Mettre en place winbind =====
+===== Authentifier les utilisateurs =====
-==== Installer les paquets ====
+==== Installer Winbind ====
-Il faut installer **[[apt>libnss-winbind]]** et **[[apt>libpam-winbind]]**
+Il faut installer **[[apt>libnss-winbind]]**, **[[apt>libpam-winbind]]** et **[[apt>winbind]]**
-<code>sudo apt-get install libnss-winbind libpam-winbind</code>
+<code>sudo apt-get install libnss-winbind libpam-winbind winbind</code>
 A ce stade, la commande //wbinfo// devrait déjà fonctionner mais pas //getent// pour les utilisateurs et groupes du domaine (correctement configurés).
 <code>wbinfo -u
 wbinfo -g</code>
-==== Configurer Name Service Switch ====
+==== Configurer le Name Service Switch ====
 Il faut ajouter **winbind** aux possibilités //passwd// et //group//.
 <file - /etc/nsswitch.conf>
@@ Ligne 159: / Ligne 211: @@
 uid=10000(administrator) gid=10000(domain admins) groups=10000(domain admins),10005(schema admins),10007(group policy creator owners),10017(denied rodc password replication group),10004(enterprise admins),10003(domain users)</code><note>Les commandes ci-dessus ne mentionnent pas le domaine auquel appartient l'utilisateur ou le groupe. Cette information n'est pas nécessaire car //samba// est configuré pour utiliser le domaine par défaut avec la ligne //winbind use default domain = yes//. Dans le cas contraire, il aurait fallu noter EXAMPLE\Administrator</note>
-Tout ceci montre une situation correctement configurée c'est-à-dire que chaque utilisateur ou groupe de domaine possède un identifiant NIS unique. Dans le cas contraire, par exemple pas d'identifiant pour le groupe //schema admins// donnerait ce résultat avec la commande //id//
+Tout ceci montre une situation correctement configurée c'est-à-dire que chaque utilisateur ou groupe du domaine possède un identifiant NIS unique. Dans le cas contraire, par exemple pas d'identifiant pour le groupe //schema admins// donnerait ce résultat avec la commande //id//
 <code>id administrator
 uid=10000(administrator) gid=10000(domain admins) groups=10000(domain admins),4294967295,10007(group policy creator owners),10017(denied rodc password replication group),10004(enterprise admins),10003(domain users)</code>
@@ Ligne 209: / Ligne 261: @@
 On voit que le répertoire HOME de l'utilisateur a été créé lors du processus de login (même par SSH).
+==== Authentification hors ligne ====
+Le cas des ordinateurs portables est typique d'une situation dans laquelle l'utilisateur est amené à ne pas être connecté au réseau et par conséquence, ne pas être capable de se faire authentifier par le DC. Une solution à ce problème consiste à mettre en place un cache des authentifications sur base des authentifications réussies. Ainsi, lorsque le DC est inaccessible, le cache permet d'authentifier l'utilisateur lui permettant de travailler.
+La ligne //winbind offline login = yes// dans le fichier /etc/samba/smb.conf indique au PAM pour Winbind d'autoriser l'authentification sur base d'un cache. Il faut donc ajouter cette ligne.
+<file - /etc/samba/smb.conf>...
+        winbind offline logon = yes
+...</file>
+Il faut également ajouter l'option //cached_login// au PAM pour Winbind en créant ou modifiant le fichier /etc/security/pam_winbind et en rechargeant PAM
+<file - /etc/security/pam_winbind>[global]
+# request a cached login if possible (needs "winbind offline logon = yes" in smb.conf)
+cached_login = yes</file>
+<code>sudo pam-auth-update</code>
+Afin de réaliser le cache des d'informations d'authentification, il faut installer le PAM pour CCRED (Cache Credentials) avec le paquet **[[apt>libpam-ccreds]]**
+<code>sudo apt-get install libpam-ccreds</code>
+Le PAM pour CCRED (Cache Credentials) réalise le cache des informations d'authentification. Ce cache est stocké dans une base de données de type Berkeley DB, /var/cache/.security.db. Il est possible d'interroger cette base de données avec les outils //cc_dump// et //cc_test// fournis par le paquet //libpam-ccreds//. Cette base de données équivaut au //shadow// du NSS.
+Il faut également ajouter le paquet **[[apt>nss-updatedb]]**
+<code>sudo apt-get install nss-updatedb</code>
+Le paquet //nss-updatedb// fourni la commande //nss_updatedb// qui permet de créer des bases de données de type Berkeley DB stockant les données équivalentes aux //passwd// et //group// du NSS. Il faut l'invoquer régulièrement afin de maintenir à jour ces bases de données.
+<code>sudo nss_updatedb winbind</code>
+De plus, il faut informer le système qu'il peut utiliser ces bases de données comme source pour //passwd// et //group// en ajoutant //db// aux entrées respectives du fichier ///etc/nsswitch.conf//
+<file - /etc/nsswitch.conf>
+passwd:        compat winbind db
+group:         compat winbind db
+</file>
+Une fois ceci mis en place, un utilisateur du domaine pourra se reconnecter à sa session lorsqu'il est hors ligne.
 ===== Outils =====
@@ Ligne 230: / Ligne 314: @@
 A présent, les membres du groupe "Domain Admins" peuvent exécuter toutes les commandes avec //sudo//.
+==== Policy-Kit ====
+Les droits d'administration pour PolicyKit sont définis par les fichiers dans ///etc/polkit-1/localauthority.conf.d//. Par défaut dans ce répertoire, il existe déjà 2 fichiers //50-localauthority.conf// et //51-ubuntu-admin.conf//. Ces deux fichiers définissent le même paramètre de configuration //AdminIdentities//, les identités des administrateurs. Le fichier ayant le plus grand nombre écrase les paramètres identiques définis par les fichiers ayant un nombre inférieure. Ainsi par défaut sous Ubuntu, c'est le fichier //51-ubuntu-admin.conf// qui sera utilisé pour définir les identités des administrateurs. Pour redéfinir ces identités d'administration, il est recommandé de créer un nouveau fichier car les fichiers existant pourraient être automatiquement modifiés lors d'une mise à jour. Ce nouveau fichier doit alors avoir un nombre supérieur à 51.
+Par exemple, pour ne donner les droits qu'aux administrateurs du domaine
+<file - /etc/polkit-1/localauthority.conf.d/60-example.com-admin.conf>
+[Configuration]
+AdminIdentities=unix-group:Domain Admins
+</file>
+__Ou__ pour donner les droits aux administrateurs du domaine et aux administrateurs locaux (environnement mixte)
+<file - /etc/polkit-1/localauthority.conf.d/60-example.com-admin.conf>
+[Configuration]
+AdminIdentities=unix-group:Domain Admins;unix-group:sudo;unix-group:admin
+</file>
 ==== Samba-tool ====
@@ Ligne 264: / Ligne 363: @@
 ===== Applications utilisant le ticket Kerberos =====
 ==== ssh ====
-Pour activer l'utilisation de l'authentification par Kerberos pour SSH, il faut décommenter les lignes concernant GSSAPIAuthentication dans /etc/ssh/sshd_config (pour la partie serveur) et GSSAPIAuthentication et GSSAPIDelegateCredentials dans /etc/ssh/ssh_config (pour la partie cliente) et activer ces options en passant la valeur yes au lieu de no.
+Pour activer l'utilisation de l'authentification par Kerberos pour SSH, il faut décommenter les lignes concernant GSSAPIAuthentication dans /etc/ssh/sshd_config (pour la partie serveur) et GSSAPIAuthentication et GSSAPIDelegateCredentials dans /etc/ssh/ssh_config (pour la partie cliente) et activer ces options en passant la valeur à //yes// au lieu de //no//.
 <file - /etc/ssh/sshd_config>
 ...
@@ Ligne 274: / Ligne 373: @@
         GSSAPIDelegateCredentials = yes
 ...</file>
-La modification du fichier /etc/ssh/ssh_config doit se faire sur chaque machine à partir de laquelle un client essaye d'ouvrir une session SSH sur le serveur.
+La modification du fichier /etc/ssh/ssh_config doit se faire sur chaque machine à partir de laquelle un client essaye d'ouvrir une session SSH.
-Pour que le serveur SSH puissent accepter l'authentification de l'utilisateur, il doit posséder lui-même un ticket Kerberos valide. Ce ticket sera le fichier /etc/krb5.keytab où sont stockées les clés de la machine lui permettant de s'authentifier auprès du serveur Kerberos. De par sa nature, cette information est sensible et donc protégée par des droits d'accès restreints (''%%-rw------%% root root''). Si le paramètre //kerberos method// est définit dans le fichier ///etc/samba/smb.conf// avec la valeur //system keytab//. Ce fichier, /etc/krb5.keytab, aurait dû être créé lorsque la machine a été jointe au domaine. Sinon, il faut le créer manuellement. Deux opérations sont nécessaires. La première consiste à obtenir un ticket Kerberos au nom de //Administrator// (un compte du domaine possédant les droits d'administration sur celui-ci) pour le superutilisateur //root//. La seconde interroge le DC pour recevoir les clés et crée le fichier /etc/krb5.keytab sur la machine.
+La modification du fichier /etc/ssh/sshd_config doit se faire sur chaque machine sur laquelle un client essaye d'ouvrir une session SSH.
-<code>sudo kinit administrator
-Password for administrator@EXAMPLE.COM:
-sudo net ads keytab create -k</code>
-<note tip>Vous recevez un avertissement si le paramètre "kerberos method" n'est pas définit dans /etc/samba/smb.conf
-<code>Warning: "kerberos method" must be set to a keytab method to use keytab functions.</code>
-</note>
-On peut vérifier le résultat avec
-<code>ls -l /etc/krb5.keytab
--rw------- 1 root root 1057 Nov  4 19:37 /etc/krb5.keytab</code>
-<code>sudo klist -ket
-Keytab name: FILE:/etc/krb5.keytab
-KVNO Timestamp           Principal
----- ------------------- ------------------------------------------------------
-11/04/2014 19:37:24 host/ubnwks01.example.com@EXAMPLE.COM (des-cbc-crc)
-11/04/2014 19:37:24 host/ubnwks01.example.com@EXAMPLE.COM (des-cbc-md5)
-11/04/2014 19:37:24 host/ubnwks01.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
-11/04/2014 19:37:24 host/ubnwks01.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
-11/04/2014 19:37:24 host/ubnwks01.example.com@EXAMPLE.COM (arcfour-hmac)
-11/04/2014 19:37:24 host/ubnwks01@EXAMPLE.COM (des-cbc-crc)
-11/04/2014 19:37:24 host/ubnwks01@EXAMPLE.COM (des-cbc-md5)
-11/04/2014 19:37:24 host/ubnwks01@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
-11/04/2014 19:37:25 host/ubnwks01@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
-11/04/2014 19:37:25 host/ubnwks01@EXAMPLE.COM (arcfour-hmac)
-11/04/2014 19:37:25 UBNWKS01$@EXAMPLE.COM (des-cbc-crc)
-11/04/2014 19:37:25 UBNWKS01$@EXAMPLE.COM (des-cbc-md5)
-11/04/2014 19:37:25 UBNWKS01$@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
-11/04/2014 19:37:25 UBNWKS01$@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
-11/04/2014 19:37:25 UBNWKS01$@EXAMPLE.COM (arcfour-hmac)
-</code>
-On peut vérifier que ce fichier est valide pour s'authentifier (authentifier la machine) au près du serveur Kerberos
-<code>sudo kinit -V -k 'UBNWKS01$'
-Using default cache: /tmp/krb5cc_1000
-Using principal: UBNWKS01$@EXAMPLE.COM
-Authenticated to Kerberos v5
-</code>
-La ligne //Authenticated to Kerberos v5// témoigne de la bonne exécution et donc de la validité du fichier /etc/krb5.keytab. Si au contraire, on reçoit //kinit: Bad encryption type while getting initial credentials//. Ceci signifie que les clés d'authentification présentes dans ce fichier sont expirées. Il faut donc régénérer ce fichier avec la commande //net ads keytab create//. On verra alors avec la commande //klist -ket// que le chiffre dans la colonne KVNO a été incrémenté (une ou plusieurs fois)
-**__A vérifier:__** Avec le paramètre //kerberos method = system keytab// dans /etc/samba/smb.conf, le fichier /etc/krb5.keytab est renouvelé automatiquement.
+Pour que le serveur SSH puissent accepter l'authentification de l'utilisateur, il doit posséder lui-même un ticket Kerberos valide. Sans configuration particulière, le serveur SSH utilisera le ticket Kerberos de la machine pour s'authentifier (c-à-d. le fichier /etc/krb5.keytab). En cas de problème, il faut vérifier la validité du ticket (se référer à [[utilisateurs:qedinux:samba_ad_dc_members#ticket_kerberos_de_la_machine|Ticket Kerberos de la machine]])
-A présent, un utilisateur du domaine utilisant une autre machine peut ouvrir une session SSH sur la machine //ubnwks01// sans devoir introduire son mot de passe.
+A présent, un utilisateur du domaine utilisant une autre machine du domaine peut ouvrir une session SSH sur la machine //ubnwks01// sans devoir introduire son mot de passe.
 ==== smb4k ====