Problème NFS - Récupération des informations "PrimaryGroup" et "SupplementaryGroups" - Commande Get-NfsMappedIdentity

Question

Bonjour à toutes et à tous,

Je rencontre une problématique et je ne trouve aucune solution. Voici le contexte :

Deux machines virtuelles sous Linux Debian :

SERVEUR NFS
Serveur NFS pour le partage de fichiers.
Utilise Winbind pour l'intégration au domaine Active Directory (AD).

SERVEUR AD
Serveur Active Directory (AD) sous Samba.
Sert également de serveur DNS et Kerberos.
Gère les utilisateurs et les groupes de sécurité.

Objectif :
Permettre aux postes clients Windows intégrés au domaine AD de monter les dossiers partagés en utilisant Kerberos pour une authentification sécurisée.
Problématique

Les postes clients Windows rencontrent des difficultés pour récupérer les informations suivantes depuis l'Active Directory :

Les "groupes supplémentaires" (supplementary groups).  
Le "groupe primaire" (primary group).  

Observations :

• Serveur NFS
  Les informations concernant les groupes supplémentaires et le groupe primaire sont correctement récupérées et affichées pour les utilisateurs.

- Serveur AD Samba  
    Les configurations semblent correctes selon le schéma LDAP de Samba basé sur les définitions RFC2307.  

- Postes Clients Windows  
    Les postes clients Windows ne parviennent pas à récupérer les informations sur les groupes supplémentaires et le groupe primaire via la commande Get-NfsMappedIdentity -AccountType User. Je retrouve bien les informations suivantes : "UserIdentifier", "GroupIdentifier", et "UserName" mais les deux autres champs, à savoir "PrimaryGroup" et "SupplementaryGroup", restent vides. Je suspecte une stratégie de groupe et/ou locale qui bloque ou interfère avec la remontée de ces informations.  
    Lorsque je monte mon partage sur le client Windows avec la commande : mount -o sec=krb5i \\SRVnfs\srv\data M:, cela fonctionne, mais je n'arrive pas à accéder aux dossiers/fichiers gérés par les groupes... (je ne sais pas si je suis clair).  

Conclusion :
A priori, Il y aurait un problème spécifique avec les clients Windows qui ne parviennent pas à récupérer les informations de groupe de l'AD, alors que le serveur NFS et les clients Linux n'ont pas ce problème. Cela suggère une possible incompatibilité/mauvaise configuration/problème de stratégies ? entre les clients Windows et le serveur AD Samba, malgré une configuration correcte du schéma LDAP selon les standards RFC2307.

Auriez-vous des informations ou des pistes afin de m'éclairer, s'il vous plaît ?
Je suis perdu, j'ai l'impression d'avoir tout essayé et rien ne fonctionne.
Merci d'avance pour votre aide.

Answer 1

Cette réponse a été automatiquement traduite. Par conséquent, il peut y avoir des erreurs grammaticales ou des formulations étranges.

Bonjour Mickaël MARTI,

Merci d’avoir posté dans les forums de la communauté Microsoft.

Assurez-vous que l’utilisateur du client Windows dispose de privilèges suffisants pour accéder aux informations de groupe dans AD. Il peut être nécessaire de vérifier que l’utilisateur appartient au groupe ou au rôle approprié qui peut accéder aux informations de groupe dans AD.

Si l’utilisateur actuel ne dispose pas de privilèges suffisants pour effectuer une opération (telle que le déploiement de la stratégie de groupe), cela peut entraîner un échec. Dans ce cas, vous devez vous assurer que l’utilisateur sur le client Windows dispose des autorisations appropriées.

Vérifiez si la connexion réseau entre le client Windows et le serveur AD fonctionne correctement. Vous pouvez utiliser la commande ping ou d’autres outils de diagnostic réseau pour tester la connexion.

Vérifiez les paramètres de pare-feu entre le client Windows et le serveur AD pour vous assurer que les communications LDAP ou Kerberos nécessaires ne sont pas bloquées.

Le pare-feu ou d’autres paramètres de sécurité peuvent bloquer les communications réseau nécessaires, entraînant l’échec du déploiement de la stratégie de groupe. Assurez-vous que le port de communication LDAP de l’AD (389 ou 636 par défaut, si vous utilisez SSL) n’est pas bloqué par le pare-feu.

Assurez-vous que tous les paramètres nécessaires sur le serveur LDAP sont correctement configurés et que le client Windows est en mesure de résoudre correctement l’adresse du serveur LDAP.

Si l’authentification Kerberos est utilisée, assurez-vous que les paramètres Kerberos et la configuration du centre de distribution de clés (KDC) sont corrects.

Vérifiez la configuration du client LDAP sur le client Windows pour vous assurer qu’elle pointe vers le serveur et le port LDAP corrects et que la méthode d’authentification correcte (par exemple, Kerberos ou Simple Bind) est utilisée.

Si un logiciel client ou des bibliothèques LDAP spécifiques sont utilisés, assurez-vous qu’ils ont été mis à jour vers la dernière version et qu’ils sont compatibles avec votre serveur LDAP.

Examinez les fichiers journaux du client Windows et du serveur AD pour rechercher les erreurs ou les messages d’avertissement liés aux communications LDAP. Ces journaux peuvent fournir des informations plus détaillées sur le problème et vous aider à déterminer la cause première du problème.

Sinceres salutations

Neuvi Jiang