Différences

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

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
utilisateurs:qedinux:samba_ad_dc_members [Le 15/11/2015, 09:44]
Qedinux
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 ====== ====== Samba AD DC - Intégration de machines au domaine ======
  
Ligne 84: Ligne 84:
 La configuration de samba peut être réécrite comme suit : La configuration de samba peut être réécrite comme suit :
 <file - /​etc/​samba/​smb.conf>​ <file - /​etc/​samba/​smb.conf>​
-# Global parameters ​                                                                        ​+# Global parameters
 [global] [global]
         workgroup = EXAMPLE         workgroup = EXAMPLE
Ligne 112: 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 //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 //winbind offline logon// permet de
  
 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. 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.
Ligne 140: Ligne 140:
 <​code>​ls -l /​etc/​krb5.keytab <​code>​ls -l /​etc/​krb5.keytab
 -rw------- 1 root root 1057 Nov  4 19:37 /​etc/​krb5.keytab</​code>​ -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 ​+Avec les [[utilisateurs:​qedinux:​samba_ad_dc_members#​kerberos|outils Kerberos]], on peut lire ce ticket
 <​code>​sudo klist -ket <​code>​sudo klist -ket
 Keytab name: FILE:/​etc/​krb5.keytab Keytab name: FILE:/​etc/​krb5.keytab
Ligne 174: Ligne 174:
 La seconde interroge le DC pour recevoir un nouveau jeton et crée le fichier /​etc/​krb5.keytab sur la machine. 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>​ <​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 ​+<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>​ <​code>​Warning:​ "​kerberos method"​ must be set to a keytab method to use keytab functions.</​code>​
 </​note>​ </​note>​
Ligne 263: Ligne 263:
  
 ==== Authentification hors ligne ==== ==== 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.+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équencene 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. 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.
Ligne 281: Ligne 281:
 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. 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.
  
-<​note>​FIXME ​Il faut ajouter le paquet **[[apt>​nss-updatedb]]**+Il faut également ​ajouter le paquet **[[apt>​nss-updatedb]]**
 <​code>​sudo apt-get install nss-updatedb</​code>​ <​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. 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></​note>+<​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>
  
-<​note>​Les bases de données de type Berkeley DB peuvent être manipulées avec les outils du paquet **[[apt>​db-util]]**</​note>​ 
 Une fois ceci mis en place, un utilisateur du domaine pourra se reconnecter à sa session lorsqu'​il est hors ligne. Une fois ceci mis en place, un utilisateur du domaine pourra se reconnecter à sa session lorsqu'​il est hors ligne.
  
  • utilisateurs/qedinux/samba_ad_dc_members.1447577061.txt.gz
  • Dernière modification: Le 15/11/2015, 09:44
  • par Qedinux