Le problème
L'identifiant La commande affiche différents UID et GID sur différents serveurs sssd pour le même utilisateur Windows Active Directory. Après avoir purgé le cache sssd par sss_cache, l'UID et le GID sont toujours différents.
1. Sortie d'un serveur :
# id ad_test_user uid=[UID](ad_test_user) gid=[GID](ad_test_group) groups=[GID](ad_test_group2),[GID](ad_test_group)
# sss_cache -u ad_test_user
# id ad_test_user uid=[UID](ad_test_user) gid=[GID](ad_test_group) groups=[GID](ad_test_group2),[GID](ad_test_group)
2. Sortie d'un autre serveur :
# id ad_test_user uid=[UID](ad_test_user) gid=[GID](ad_test_group) groups=[GID](ad_test_groups),[GID](ad_test_group3),[GID](ad_test_group4),[GID](ad_test_group5), [GID](ad_test_group2),[GID](ad_test_group)
# sss_cache -u ad_test_user
# id ad_test_user uid=[UID](ad_test_user) gid=[GID](ad_test_group) groups=[GID](ad_test_groups),[GID](ad_test_group3),[GID](ad_test_group4),[GID](ad_test_group5), [GID](ad_test_group2),[GID](ad_test_group)
Impacts possibles sur le serveur Linux :l'utilisateur AD ne peut pas se connecter à Linux
# su - ad_test_user Last login: Fri Sep 11 11:11:11 COT 2015 from 10.10.xx.xx on pts/1 Last failed login: Tue Mar 13 13:13:13 COT 2015 from 10.10.10.2 on ssh:hostname There were 1 failed login attempts since the last successful login. su: warning: cannot change directory to /home/ad_test_user: Permission denied id: cannot find name for group ID [GID] -bash: /home/ad_test_user/.bash_profile: Permission denied -bash-4.2$
La solution
L'UID et le GID de l'utilisateur Linux proviennent du SID Windows AD. Le sssd ne le changera pas. La fonctionnalité de mappage d'ID permet à sssd d'agir en tant que client d'Active Directory sans obliger les administrateurs à étendre les attributs utilisateur pour prendre en charge les attributs POSIX pour les identifiants d'utilisateur et de groupe.
Active Directory fournit un objectSID pour chaque utilisateur et objet de groupe dans l'annuaire. Cet objectSID peut être divisé en composants qui représentent l'identité de domaine Active Directory et l'identificateur relatif (RID) de l'objet utilisateur ou groupe. L'algorithme de mappage d'ID sssd prend une gamme d'UID disponibles et la divise en sections de composants de taille égale - appelées "tranches "-. Chaque tranche représente l'espace disponible pour un domaine Active Directory.
Lorsqu'une entrée d'utilisateur ou de groupe pour un domaine particulier est rencontrée pour la première fois, le sssd(8) alloue l'une des tranches disponibles pour ce domaine. Afin de rendre cette affectation de tranche reproductible sur différentes machines clientes, l'algorithme suivant est utilisé :la chaîne SID est passée à travers l'algorithme murmurhash3 pour la convertir en une valeur hachée de 32 bits. Prenez ensuite le module de cette valeur avec le nombre total de tranches disponibles pour choisir la tranche.
Remarque :Il est possible de rencontrer des collisions dans le hachage et le module suivant. Dans ces situations, la prochaine tranche disponible est utilisée, mais il peut ne pas être possible de reproduire exactement le même ensemble de tranches sur d'autres machines puisque l'ordre dans lequel elles sont rencontrées déterminera leur tranche. Dans cette situation, il est recommandé de passer à l'utilisation d'attributs POSIX explicites dans Active Directory (en désactivant le mappage d'ID) ou de configurer un domaine par défaut pour garantir qu'au moins un est toujours cohérent. Voir "Configuration" pour plus de détails.Lorsque le mappage d'ID est activé dans sssd(8), les attributs uidNumber et gidNumber sont ignorés. Cela permet d'éviter la possibilité de conflits entre les valeurs attribuées automatiquement et manuellement. Si vous devez utiliser des valeurs attribuées manuellement, TOUTES les valeurs doivent être attribuées manuellement.
Remarque :la modification des options de configuration liées au mappage d'ID entraînera la modification des ID d'utilisateur et de groupe. Pour le moment, sssd(8) ne prend pas en charge la modification des ID, la base de données sssd doit donc être supprimée. Étant donné que les mots de passe mis en cache sont également stockés dans la base de données, la suppression de la base de données ne doit être effectuée que lorsque les serveurs d'authentification sont accessibles, sinon les utilisateurs risquent d'être bloqués. Afin de mettre en cache le mot de passe, une authentification doit être effectuée.Le sssd.conf fichier sur les clients Linux doit être cohérent. En particulier, les deux paramètres suivants doivent être cohérents dans tous les sssd.conf car ils affectent l'algorithme de mappage d'ID sssd :
1. ldap_idmap_default_domain_sid (chaîne)
Spécifiez le SID de domaine du domaine par défaut. Cela garantira que ce domaine sera toujours attribué à la tranche zéro dans la carte d'identification, en contournant l'algorithme murmurhash décrit ci-dessus.
Par défaut :non défini
2. ldap_idmap_default_domain (chaîne)
Spécifiez le nom du domaine par défaut.
Par défaut :non défini