Différences

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

--- tutoriel:samba_ad_dc_members [Le 30/11/2015, 18:10]
Qedinux Création
+++ tutoriel:samba_ad_dc_members [Le 11/09/2022, 12:20] (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}}
+{{tag>tutoriel samba administration windows réseau}}
+----
 ====== Samba AD DC - Intégration de machines au domaine ======
@@ Ligne 22: / Ligne 24: @@
 ff02::2 ip6-allrouters
 </file>
-Les commandes //hostname// et //hostname -f// doivent retourner le même résultat, le FQDN de la machine, ubnwks01.example.com
+Les commandes //hostname// et //hostname -f// doivent retourner le même résultat, le FQDN de la machine, ubnwks01.example.com. Il est important que ce soit le FQDN qui suit en premier l'adresse 127.0.1.1.
 ==== Résolution de nom de domaine ====
 Une bonne résolution de nom de domaine est indispensable au sein d'un domaine Samba AD DC. Dans le fichier /etc/resolv.conf, il faut retrouver un serveur DNS du domaine et le domaine de recherche.
 <file - /etc/resolv.conf>nameserver 192.168.1.11
 search example.com</file>
-Ces paramètres sont soit fournis par le serveur DHCP du réseau ou configurés de façon statique dans le fichier /etc/network/interfaces par l'intermédiaire du paquet //resolvconf// avec les commandes dns-nameservers et dns-search.
+Ces paramètres sont soit fournis par le serveur DHCP du réseau ou configurés de façon statique dans le fichier **/etc/network/interfaces** (obsolète à partir de 18.04) ou dans un fichier YAML dans **/etc/netplan** (par défaut à partir de 18.04) (se référer à [[tutoriel:comment_configurer_son_reseau_local|Comment configurer son réseau local ?]] et [[utilisateurs:ool:netplan|netplan]])
-<file - /etc/network/interfaces>auto eth0
-iface eth0 inet static
-  address 192.168.1.101
-  netmask 255.255.255.0
-  gateway 192.168.1.1
-  dns-nameservers 192.168.1.11
-  dns-search example.com</file>
 Les tests suivant devraient renvoyer des résultats corrects (se référer à [[:samba-active-directory#tests_du_dns|Samba AD DC - Tests du DNS]])
 <code>dig ubndc01.example.com</code>
@@ Ligne 83: / Ligne 79: @@
 ==== Configurer samba ====
 La configuration de samba peut être réécrite comme suit :
+  * Pour Ubuntu 14.04 et 16.04 (avant Samba 4.6)
 <file - /etc/samba/smb.conf>
 # Global parameters
 [global]
         workgroup = EXAMPLE
@@ Ligne 100: / Ligne 97: @@
         winbind nss info = rfc2307
+        winbind trusted domains only = no
+        winbind use default domain = yes
+        winbind enum users = yes
+        winbind enum groups = yes
+        winbind refresh tickets = yes
+        kerberos method = system keytab
+</file>
+  * A partir d'Ubuntu 17.10 (à partir de Samba 4.6)
+<file - /etc/samba/smb.conf>
+# Global parameters
+[global]
+        workgroup = EXAMPLE
+        realm = EXAMPLE.COM
+        netbios name = ubnwks01
+        security = ADS
+        encrypt passwords = yes
+        idmap config EXAMPLE:backend = ad
+        idmap config EXAMPLE:schema_mode = rfc2307
+        idmap config EXAMPLE:range = 10000-39999
+        idmap config EXAMPLE:unix_nss_info = yes
+        idmap config *:backend = tdb
+        idmap config *:range = 40000-49999
         winbind trusted domains only = no
         winbind use default domain = yes
@@ Ligne 112: / Ligne 135: @@
 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. La ligne //winbind offline logon// permet de
+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 //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.
+<note important>A partir de Samba 4.6, le paramètre **winbind nss info = rfc2307** est remplacé par **idmap config EXAMPLE:unix_nss_info = yes**(([[https://wiki.samba.org/index.php/Idmap_config_ad#The_RFC2307_and_template_Mode_Options|The RFC2307 and template Mode Options]]))</note>
 ==== Appliquer les modifications ====
@@ Ligne 122: / Ligne 146: @@
 ==== Joindre la machine au domaine ====
-<code>sudo net join -U Administrator
+Bien que l'option **createupn** ne soit pas obligatoire pour joindre la machine dans le domaine, certaines fonctionnalités tel que [[tutoriel:samba_ad_dc_nfs4_kerberized|Partage NFSv4 avec authentification Kerberos]] auront besoin que cette information soit présente dans l'AD. Il est donc recommandé de directement fournir ces informations plutôt que de ne pas le faire, attendre et finalement s'amuser à modifier ultérieurement l'objet dans l'AD.
+<code>sudo net join -U Administrator</code>
+ou
+<code>sudo net join createupn=UBNWS01.EXAMPLE.COM\$@EXAMPLE.COM -U Administrator
 Enter Administrator's password:
 Using short domain name -- EXAMPLE
@@ Ligne 140: / Ligne 167: @@
 <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
@@ Ligne 174: / Ligne 201: @@
 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>
@@ Ligne 263: / Ligne 290: @@
 ==== Authentification hors ligne ====
+<note>A mettre à jour cfr [[https://wiki.samba.org/index.php/PAM_Offline_Authentication|PAM Offline Authentication]]</note>
 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.
@@ Ligne 276: / Ligne 304: @@
 <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]]**
+<del>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]]**</del>
 <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.
+<del>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.</del>
-Il faut également ajouter le paquet **[[apt>nss-updatedb]]**
+<del>Il faut également ajouter le paquet **[[apt>nss-updatedb]]**</del>
 <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.
+<del>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.</del>
 <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//
+<del>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//</del>
 <file - /etc/nsswitch.conf>
 passwd:        compat winbind db
@@ Ligne 294: / Ligne 322: @@
 Une fois ceci mis en place, un utilisateur du domaine pourra se reconnecter à sa session lorsqu'il est hors ligne.
-===== Outils =====
+===== Paramètres améliorant l'utilisation de la machine =====
-==== Kerberos ====
-Il pourra être utile d'installer les outils Kerberos (notamment kinit, klist, kdestroy, ...) pour investiguer, tester et dépanner les problèmes relatifs à Kerberos.
-<code>sudo apt-get install krb5-user</code>
-Plus d'infos, se référer à [[:samba-active-directory#tests_de_kerberos|Samba AD DC - Tests de Kerberos]]
 ==== Sudo ====
@@ Ligne 315: / Ligne 337: @@
 A présent, les membres du groupe "Domain Admins" peuvent exécuter toutes les commandes avec //sudo//.
-==== Policy-Kit ====
+==== Outils Kerberos ====
-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.
+Il pourra être utile d'installer les outils Kerberos (notamment kinit, klist, kdestroy, ...) pour investiguer, tester et dépanner les problèmes relatifs à Kerberos.
+<code>sudo apt-get install krb5-user</code>
-Par exemple, pour ne donner les droits qu'aux administrateurs du domaine
+Plus d'infos, se référer à [[:samba-active-directory#tests_de_kerberos|Samba AD DC - Tests de Kerberos]]
-<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 361: / Ligne 374: @@
 Guest
 localuser@ubnwks01:~$ kdestroy</code>
-===== 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//.
@@ Ligne 381: / Ligne 394: @@
 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.
+==== AppArmor ====
+Afin d'éviter de désagréables dysfonctionnements provoqués par AppArmor, il faut le reconfigurer pour définir le chemin des répertoires //home// des utilisateurs du domaine, typiquement ///home/example/ //
+<code>sudo dpkg-reconfigure apparmor</code>
+<code>   ┌────────────────────────────────────────────────┤ Configuration de apparmor ├────────────────────────────────────────────────┐
+   │ Veuillez indiquer, séparés par des espaces, les emplacements des répertoires personnels (« home ») supplémentaires des      │
+   │ utilisateurs. Ces répertoires seront ajoutés à ceux qui sont indiqués dans /etc/apparmor.d/tunables/home ; ils doivent se   │
+   │ terminer par un « / ».                                                                                                      │
+   │                                                                                                                             │
+   │ Exemple : si les répertoires des utilisateurs sont stockés dans /srv/nfs/home et /mnt/homes, vous devriez entrer «          │
+   │ /srv/nfs/home/ /mnt/homes/ ».                                                                                               │
+   │                                                                                                                             │
+   │ Emplacement du répertoire personnel supplémentaire :                                                                        │
+   │                                                                                                                             │
+   │ /home/example/                                                                                                              │
+   │                                                                                                                             │
+   │                                                           <Ok>                                                              │
+   │                                                                                                                             │
+   └─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘   </code>
+Ceci va modifier le fichier ///etc/apparmor.d/tunables/home.d/ubuntu//
+<file - /etc/apparmor.d/tunables/home.d/ubuntu>
+@{HOMEDIRS}+=/home/example/
+</file>
+==== 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>
+==== Mise en correspondance des groupes ====
+Les utilisateurs du domaine peuvent être directement ajoutés aux groupes Unix locaux mais la tâche serait fastidieuse et ingérable dans un domaine comportant un grand nombre de machine et d'utilisateur. Pour ce faire, il est possible de mettre en correspondance un groupe Samba local avec un groupe Unix local et d'ajouter un ou des groupes ou utilisateurs du domaine à ce groupe Samba local. Ainsi, les utilisateurs du domaine peuvent devenir membre des groupes Unix locaux.
+Voici un exemple plus parlant:
+  * Considérons l'utilisateur du domaine //Administrator// membre du groupe du domaine //Domain Admins//. Supposons qu'il veuille lire les fichiers log (auth.log, syslog) d'une machine linux membre du domaine. Cette action est tout à fait normale. Cependant, par défaut, cet utilisateur n'est pas membre du groupe Unix local //adm//. Il ne pourrait donc pas les lire ces fichiers sauf si les droits //sudo// lui ont été octroyés comme expliqué ci-dessus. L'alternative serait de le mettre automatiquement dans le groupe Unix local //adm//.
+Pour ce faire, il faut créer une correspondance entre le group Unix local //adm// et un groupe Samba local avec la commande suivante:
+<code>sudo net groupmap add unixgroup=adm type=local
+No rid or sid specified, choosing a RID
+Got RID 1001
+Successfully added group adm to the mapping db as a alias (local) group</code>
+Premièrement, il est possible de définir manuellement le RID du group Samba local. Quel intérêt ? Deuxièment, il est également possible de définir le nom du groupe Samba local. Par défaut, ce dernier prend le même nom que le groupe Unix local.
+Finalement, il faut ajouter le groupe du domaine //Domain Admins// (ou l'utilisateur //Administrator//) au groupe Samba local. Cependant, la commande qui va ajouter le groupe ou l'utilisateur du domaine utilise les SID de ceux-ci ainsi que le SID du groupe local. Les commandes qui suivent vont premièrement afficher le SID du groupe local //adm//, deuxièment afficher le SID du groupe du domaine //Domain Admin// et finalement rendre le second membre du premier.
+<code>sudo net groupmap list ntgroup=adm
+adm (S-1-5-21-1757501545-3173013020-1010731404-1001) -> adm
+wbinfo -n "Domain Admins"
+S-1-5-21-118621575-641544407-1507140581-512 SID_DOM_GROUP (2)
+sudo net groupmap addmem S-1-5-21-1757501545-3173013020-1010731404-1001 S-1-5-21-118621575-641544407-1507140581-512</code>
+Quelques commandes pour vérifier
+  * Pour lister les groupes Samba locaux
+<code>sudo net groupmap list verbose
+adm
+        SID       : S-1-5-21-1757501545-3173013020-1010731404-1001
+        Unix gid  : 4
+        Unix group: adm
+        Group type: Local Group
+        Comment   : Local Unix group
+Administrators
+        SID       : S-1-5-32-544
+        Unix gid  : 40000
+        Unix group: BUILTIN\administrators
+        Group type: Local Group
+        Comment   :
+Users
+        SID       : S-1-5-32-545
+        Unix gid  : 40001
+        Unix group: BUILTIN\users
+        Group type: Local Group
+        Comment   :
+</code>
+On remarque que par défaut, il existe 2 groupes locaux //BUILTIN//, Administrators et Users, dont les groupes du domaine //Domain Admins// et //Domain Users// sont respectivement membres.
+  * Pour lister les groupes du domaine membres d'un groupe Samba local
+<code>sudo net groupmap listmem S-1-5-21-1757501545-3173013020-1010731404-1001
+S-1-5-21-118621575-641544407-1507140581-512</code>
+  * Pour résoudre cet SID en nom
+<code>wbinfo -s S-1-5-21-118621575-641544407-1507140581-512
+EXAMPLE\Domain Admins 2</code>
+Le code qui suit représente le type de l'objet: 1 pour un utilisateur, 2 pour un groupe.
+<note tip>Essentiellement après avoir supprimé des groupes Samba locaux, il faut vider le cache de IDMAP pour que cette suppression soit immédiatement effective.
+<code>sudo net cache flush</code></note>
+<note info>La mise en correspondance des groupes du domaine avec les groupes Unix locaux est une méthode plus simple et plus efficace que de réaliser de multiples modifications des droits pour les donner aux utilisateurs du domaine. Ceci peut donc rendre inutile la modification précédente concernant Policy-Kit. Il serait également possible de ne pas réaliser la modification concernant //sudo//. Cependant, si la correspondance des groupes vient à être perdue, l'administrateur du domaine ne pourrait plus corriger la situation. Cette raison peut donc justifier le fait de conserver cette modification.</note>
 ==== smb4k ====
 Se référer à [[:smb4k|Monter des partages Windows sous KDE]].
@@ Ligne 403: / Ligne 514: @@
 wget http://archive.ubuntu.com/ubuntu/pool/universe/s/smb4k/smb4k_1.1.2-1_amd64.deb
 sudo dpkg -i smb4k_1.1.2-1_amd64.deb</code>
 ===== Références =====
   * [[https://wiki.samba.org/index.php/Using_RFC2307_on_a_Samba_DC|Using RFC2307 on a Samba DC]]