Différences

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

--- utilisateurs:qedinux:samba_ad_dc_members [Le 05/11/2014, 08:52]
Qedinux [smb4k] - Ajout méthode installation v1.1.2
+++ 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/smb.conf>
+<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>
-Les lignes //idmap config EXAMPLE ...// sont très importantes. Elles définissent le backend (méthode d'accès) AD (Active Directory), le schéma rfc2307 (contenant les extensions NIS utiles pour les systèmes Linux et UNIX) et le range d'identifiants numériques pour les utilisateurs et groupes du domaine EXAMPLE. Ce range doit être défini dans la politique du domaine. Afin d'éviter des usurpations d'identité et de droits, il faut garantir que ces numéros soient uniques. Ils ne peuvent donc pas être utilisés localement (sur aucune machine du domaine).
+Les lignes //idmap config EXAMPLE ...// sont très importantes. Elles définissent le backend (méthode d'accès) AD (Active Directory), le schéma rfc2307 (contenant les extensions NIS utiles pour les systèmes Linux et UNIX) et la plage d'identifiants numériques pour les utilisateurs et groupes du domaine EXAMPLE. Cette plage doit être définie dans la politique du domaine. Afin d'éviter des usurpations d'identité et de droits, il faut garantir que ces numéros soient uniques. Ils ne peuvent donc pas être utilisés localement (sur aucune machine du domaine).
-Les lignes //idmap config *:... // définissent le backend tdb (base de données locale) et le range 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.
+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.
 ==== 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 114: / 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 ====
-===== Mettre en place winbind =====
+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.
-==== Installer les paquets ====
+On peut vérifier si le fichier existe avec
-Il faut installer **[[apt>libnss-winbind]]** et **[[apt>libpam-winbind]]**
+<code>ls -l /etc/krb5.keytab
-<code>sudo apt-get install libnss-winbind libpam-winbind</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
+<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>
+===== Authentifier les utilisateurs =====
+==== Installer Winbind ====
+Il faut installer **[[apt>libnss-winbind]]**, **[[apt>libpam-winbind]]** et **[[apt>winbind]]**
+<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 155: / 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 193: / Ligne 249: @@
    └────────────────────────────────────────────────────────────────────────┘   </code>
-On peut à présent tester l'authentification soit sur une autre console (Ctrl+F2) ou avec ssh
+On peut à présent tester l'authentification soit sur une autre console (Ctrl+F2), soit avec ssh
 <code>
 ssh administrator@localhost
@@ Ligne 205: / 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 226: / 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 260: / 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 270: / 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'').
+La modification du fichier /etc/ssh/sshd_config doit se faire sur chaque machine sur laquelle un client essaye d'ouvrir une session SSH.
-Deux opérations sont nécessaires, la première consiste à demander 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 intérroge le DC, reçoit les clés et crée le fichier /etc/krb5.keytab sur la machine.
+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]])
-<code>sudo kinit administrator
-Password for administrator@EXAMPLE.COM:
-sudo net ads keytab create -k
-Warning: "kerberos method" must be set to a keytab method to use keytab functions.</code>
-<note tip>L'avertisement vient du fait que le paramètre "kerberos method" n'est pas définit dans /etc/samba/smb.conf
-Se référer à ''man smb.conf''</note>
+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.
-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>
-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.
 ==== smb4k ====
 Se référer à [[:smb4k|Monter des partages Windows sous KDE]].
-Dans //smb4k//, il existe l'option //Essayer de s'authentifier avec Kerberos// de l'onglet //Paramètres généraux// dans //Configuration Smb4k / Samba//. Cette option doit permettre de monter un partage Windows (CIFS) à partir du ticket Kerberos de l'utilisateur reçu lors de son login. Sous Trusty (14.04), smb4k est fourni en v1.0.9. Lorsque l'utilisateur essaie de monter son partage, il reçoit le message d'erreur : //"Mount error (126): Required key not available. Refer to the mount.cifs(8) manual page."// Le problème vient de l'accès au ticket Kerberos. L'application //mount.cifs//, étant toujours exécutée par root via le setuid bit, cherche le ticket Kerberos de l'utilisateur root et non celui de l'utilisateur réel. Ne le trouvant pas, l'application renvoie l'erreur ci-dessus.
+Dans //smb4k//, il existe l'option //Essayer de s'authentifier avec Kerberos// de l'onglet //Paramètres généraux// dans //Configuration Smb4k / Samba// qui sert lors de l'authentification de l'utilisateur vis-à-vis du serveur de fichier distant. Cependant, il faut utiliser l'option avancée //Mode de sécurité// de l'onglet //Montage// dans //Configuration Smb4k / Samba// et choisir //Kerberos 5 authentication//. Cette option permet de monter un partage Windows (CIFS) à partir du ticket Kerberos de l'utilisateur reçu lors de son login. Elle correspond exactement à l'option sec=krb5 de //mount.cifs//.
 Ceci reviendrait à exécuter la commande :
 <code>sudo mount.cifs //server/share /mnt/point -o sec=krb5</code>
-La solution à ce problème est de passer l'option //cruid// avec la valeur UID de l'utilisateur dans le champ //Options supplémentaires// de l'onglet //Montage// dans //Configuration Smb4k / Samba//. Ceci fonctionne et le partage est accessible par l'utilisateur.
+Sous Trusty (14.04), lorsque l'utilisateur essaie de monter son partage ainsi, il reçoit le message d'erreur : //"Mount error (126): Required key not available. Refer to the mount.cifs(8) manual page."// Le problème vient de l'accès au ticket Kerberos. L'application //mount.cifs//, étant toujours exécutée par root via le setuid bit, cherche le ticket Kerberos de l'utilisateur root et non celui de l'utilisateur réel. Ne le trouvant pas, l'application renvoie l'erreur ci-dessus.
+La solution à ce problème est de passer l'option //cruid// avec la valeur UID de l'utilisateur dans le champ //Options supplémentaires// de l'onglet //Montage// dans //Configuration Smb4k / Samba//, par exemple //cruid=10000//. Ceci résout le problème et permet d'accéder au partage.
 Ceci reviendrait à exécuter la commande :
 <code>sudo mount.cifs //server/share /mnt/point -o sec=krb5,cruid=$UID</code>
-Cependant, l'utilisation de l'option //cruid// représente une faille de sécurité qui permet à un utilisateur d'encoder l'UID d'un autre utilisateur et ainsi d'obtenir les droits de cet utilisateur (CVE-2014-2581). Actuellement en l'absence de mise à jour de sécurité sur ce paquet, il est recommandé d'utiliser une version supérieur ou égale à 1.1.1. En effet, à partir de la version 1.1.1, le réglage du paramètre //cruid// est refusé par l'application //smb4k//. En arrière plan, l'application utilise ce paramètre avec la valeur UID de l'utilisateur. Il est donc recommandé d'utiliser la v1.1.2 disponible pour Utopic (14.10) parfaitement compatible d'un point de vue de ces dépendances avec Trusty (14.04).
+Cependant, l'utilisation de l'option //cruid// représente une faille de sécurité qui permet à un utilisateur d'encoder l'UID d'un autre utilisateur et ainsi d'obtenir les droits de cet utilisateur (CVE-2014-2581). Actuellement, Trusty (14.04) fourni le paquet //smb4k// en v1.0.9 sans appliquer une mise à jour de sécurité concernant cette faille. A partir de la version 1.1.1, le réglage du paramètre //cruid// est refusé par l'application //smb4k//. En arrière plan, l'application utilise ce paramètre avec la valeur UID de l'utilisateur réel. Il est donc recommandé d'utiliser la v1.1.2 disponible pour Utopic (14.10) parfaitement compatible d'un point de vue de ces dépendances avec Trusty (14.04).
-Pour les utilisateurs de Trusty (14.04), la méthode la plus simple consiste à installer le paquet //smb4k// qui installera automatiquement les dépendances. Après, il faut désinstaller le paquet //smb4k// mais pas ses dépendances. Il ne faut donc pas exécuter un //autoremove//. Et finalement, il faut télécharger le paquet depuis un dépôt officiel (attention au choix de l'architecture amd64 ou i386) et l'installer manuellement.
+Pour les utilisateurs de Trusty (14.04), la méthode la plus simple consiste à installer le paquet //smb4k// qui installera automatiquement les dépendances. Après, il faut désinstaller ce paquet mais pas ses dépendances. Il ne faut donc pas exécuter un //autoremove//. Et finalement, il faut télécharger le paquet depuis un dépôt officiel (attention au choix de l'architecture amd64 ou i386) et l'installer manuellement.
 <code>sudo apt-get install smb4k
 sudo apt-get remove smb4k