[RESOLU] [PARTAGE NFS MOUNT KRB5i] - Accès impossible dossier partagé

Mike2302 · Le 02/05/2024, à 13:49

Bonjour à tous,

Je suis actuellement confronté à un défi concernant la gestion des accès aux dossiers partagés sur un serveur Linux agissant en tant que serveur Active Directory (AD) dans un environnement mixte Windows/Linux.

Voici un résumé de la situation actuelle :

Le serveur Linux joue le rôle de serveur AD, avec des services de partage de fichiers et de DNS configurés.
Les postes clients, qu'ils soient sous Windows ou Linux, sont intégrés au domaine AD.

Pour monter les dossiers partagés, j'utilise la commande suivante : mount -o sec=krb5i \\XXX.XXX.XXX.XXX\srv\data S:. Cette commande monte le dossier partagé situé à l'adresse IP XXX.XXX.XXX.XXX, dans le répertoire /srv/data, en utilisant Kerberos pour l'authentification sécurisée.

Pour gérer les accès aux dossiers partagés, j'utilise des commandes chown et chgrp. Par exemple, j'ai utilisé la commande suivante pour changer le groupe propriétaire de manière récursive : chgrp -R [numéro UID] /srv/data/[dossier_partagé].

Je galère ++++ dans la mise en place de ce contrôle d'accès :

- Actuellement, seuls les utilisateurs propriétaires des dossiers ou appartenant au groupe "Domain Users" ont accès aux dossiers partagés situés sous DATA.

- Lorsque je crée un nouveau groupe de sécurité (par exemple : GG_TEST) dans l'AD pour gérer les autorisations d'accès aux dossiers partagés, cela ne produit pas les résultats escomptés.
J'attribue à ce groupe un GidNumber dans l'éditeur d'attribut sur l'AD, puis j'utilise la commande chgrp -R [gidnumber] /srv/data/[dossier_partagé] afin de modifier récursivement le groupe propriétaire du répertoire.
La commande se déroule sans erreur, le GID propriétaire du dossier est modifié comme prévu mais je n'accède pas au dossier.
Dans ce groupe GG_TEST, il y moi en tant qu'utilisateur mais aussi les administrateurs et le groupe Domain_Users.

En résumé, pour accéder à un dossier partagé, il faut soit être le propriétaire UID, soit que le dossier possède le GID du groupe "Domain Users".

Ce que je recherche, c'est une solution me permettant de définir précisément les autorisations d'accès aux dossiers partagés sur le serveur Linux, pour les utilisateurs et les groupes de sécurité. Je souhaite pouvoir spécifier quels utilisateurs ou groupes ont accès à quels dossiers partagés, avec un contrôle précis et granulaire, en utilisant les UID propriétaire et GID groupe.

Toute suggestion ou conseil sur la manière de mettre en place cette gestion d'accès serait grandement apprécié.

Merci d'avance pour votre aide !

Dernière modification par Mike2302 (Le 07/05/2024, à 15:22)

iznobe · Le 02/05/2024, à 14:26

Bonjour , changer les permissions du coté client ne sert à rien . Heureusement d' ailleurs , imagine si tu fais :

chown root: /tonmachin/partagé .

Bonjour les failles de securités si le proprietaire changeait sur le serveur ...

si tu dois changé les proprio / permissions , c ' est à faire coté serveur .
Tu peux ensuite restreindre les permissions au montage coté client si besoin par contre .
Exemple : sur le serveur ton partage en " g+rwx " , tu peux monter ton partage sur le client en passant seulement les droits de lecture ecriture si besoin .
pareil pour " g+rw- " sur le serveur , tu peux ne donner au montage que les droits de lire et / ou ecrire sur ton client .
Mais tu ne pourras jamais attribuer des permissions que le serveur ne tolere pas de base , ni changer les proprietaires du coté du montage sur les clients .

Dernière modification par iznobe (Le 02/05/2024, à 14:38)

Mike2302 · Le 02/05/2024, à 14:36

Merci pour ton retour, iznobe

Les modifi sont effectuées du côté du serveur en ce qui concerne les propriétaires et les permissions. Je me connecte en SSH et j'applique un chown -R ou chgrp -R sur le répertoire concerné.
Au final, cela ne fonctionne que si je suis le propriétaire de ce dossier (avec mon UID) ou si le GID correspond au groupe Domain Users...

iznobe · Le 02/05/2024, à 14:38

je pense qu ' entre les modifications de permissions , il faut redemarrer l' AD pour qu ' ils prennent en compte .
theoriquement tu dois pouvoir consulter les partages effectifs et leurs permissions directement apres le redemarrage du service sous le serveur linux lui-meme .

En résumé, pour accéder à un dossier partagé, il faut soit être le propriétaire UID, soit que le dossier possède le GID du groupe "Domain Users".

cela me parait plutot normal .

j ' ai du loupé un truc ???

Dernière modification par iznobe (Le 02/05/2024, à 14:41)

Mike2302 · Le 02/05/2024, à 14:51

Bien, comment fais-tu si tu souhaites donner des accès à un groupe de sécurité et pas à un autre ?
Dans un environnement full windows, partage smb dossier partagé, tu vas dans propriétés, tu as un onglet sécurité dans lequel tu vas aller rajouter tous tes groupes de l'AD que tu souhaites.

Dans la config, actuelle, cela se gère avec les attributs NFS, tu n'as que 2 possibilités : rentrer l'UID et le GID.
Si je souhaite que plusieurs groupe de sécurité accède à mon dossier, il faudra surement mettre des groupes dans des groupes. Est-ce que tu comprends ?
Mais ça ne fonctionne pas, d'où ma problématique...

iznobe · Le 02/05/2024, à 14:57

- Lorsque je crée un nouveau groupe de sécurité (par exemple : GG_TEST) dans l'AD pour gérer les autorisations d'accès aux dossiers partagés, cela ne produit pas les résultats escomptés.
J'attribue à ce groupe un GidNumber dans l'éditeur d'attribut sur l'AD, puis j'utilise la commande chgrp -R [gidnumber] /srv/data/[dossier_partagé] afin de modifier récursivement le groupe propriétaire du répertoire.
La commande se déroule sans erreur, le GID propriétaire du dossier est modifié comme prévu mais je n'accède pas au dossier.
Dans ce groupe GG_TEST, il y moi en tant qu'utilisateur mais aussi les administrateurs et le groupe Domain_Users.

Ce que je recherche, c'est une solution me permettant de définir précisément les autorisations d'accès aux dossiers partagés sur le serveur Linux, pour les utilisateurs et les groupes de sécurité. Je souhaite pouvoir spécifier quels utilisateurs ou groupes ont accès à quels dossiers partagés, avec un contrôle précis et granulaire, en utilisant les UID propriétaire et GID groupe.

c' est precisément pour cet objectif que les permissions existent .

ca se resume a la gestion de tes groupes .
en gros il te faut faire un genre de plan de tes differents dossiers / sous-dossiers partagés .
que tu structures tes groupes ( en y inserant les utilisateurs que tu veux qui y accedent ) et que tu les attribue correctement .

un exemple rapide :
/srv/data/[dossier_partagé] => acces aux admins
/srv/data/[dossier_partagé]/admins => acces aux admins
/srv/data/[dossier_partagé]utilisateurs => acces au groupe domain_users
/srv/data/[dossier_partagé]utilisateurs/paul => acces a paul seulement .

l ' ideal , serait de décrire un cas simplifié le plus fidelement possible ( en remplacant les noms ou informations a risques ) et de permissions actuel que tu n' arrives pas a parametré correctement .
je ne connais pas d' autres moyens que de gerer les permissions avec chown , chgrp et chmod UID / GID ...

ls -l /chemin

permet de donner les permissions .

iznobe · Le 02/05/2024, à 14:59

Bien, comment fais-tu si tu souhaites donner des accès à un groupe de sécurité et pas à un autre ?

ben tu configures un groupe de securité pour chaque cas , puis tu attribues le GID au dossier en question .

je ne pense pas qu ' on puisse inclure un groupe dans un autre groupe .

par contre tu peux faire , par exemple :
groupe admin niveau 1 dedans tu y met pierre paul et jacques
groupe admin niveau 2 dedans tu y met pierre paul , jacques martine .
groupe admin niveau 3 dedans tu y met pierre paul , jacques martine .et jeannot
c' est repetitif , mais ca revient strictement au meme que d' inclure un groupe dans un autre .

en commande , je ne me rappelle plus la syntaxe précise , mais tu peux ajouter un utilisateur a groupe admin niveau 1 + groupe admin niveau 2 + groupe admin niveau 3 en une seule .
du genre :

userrmod -a pierre G  admin1 admin2 admin3

Dernière modification par iznobe (Le 02/05/2024, à 15:09)

Mike2302 · Le 02/05/2024, à 15:08

C'est justement ce qui ne fonctionne pas...

iznobe · Le 02/05/2024, à 15:11

admettons , mais apres une modification coté serveur des permissions , il me semble imperatif que le daemon relise les permissions et re exporte les dossiers partagés pour que le changement de permissions soit effectif coté clients .
Donc , tu fais un changement , puis tu passes :

sudo service nfs-kernel-server restart

pour verifier ce qu ' il exporte , tu as :

sudo exportfs -rav

Apres sans avoir une idée precise des permissions attribuées aux dossiers partagés et aux utilisateurs et groupes configurés , ca va etre difficile de dire pourquoi ca ne fonctionne pas .

Le mieux serait de faire un partage fictif , avec des noms d ' utilisateurs et de dossiers fictifs , mais exposant le soucis que tu rencontres .
au moins on aurait du concret a traiter .

Dernière modification par iznobe (Le 02/05/2024, à 15:18)

Mike2302 · Le 02/05/2024, à 15:23

Je te donne un exemple :

Je suis user_A, utilisateur dans l'AD et mon UID est 100 200.
Je suis membre d'un groupe qui s'appelle USERS DOMAIN dont le gid est 105 150
Je suis également membre d'un groupe qui s'appelle ADMINS dont le gid est 106 300

J'ai crée un dossier partagé TEST_UNBUNTU à la racine de MONSERVEUR/SRV/DATA

Mon dossier TEST_UBUNTU, quand je vais dans propriétés, je vois que son uid est celui d'user_A 100 200 (puisque c'est lui qui a crée le dossier, donc owner par défaut) et son gid 105 150 (users domain).
Je veux que tous les membres du groupe ADMINS accèdent au dossier TEST_UBUNTU. Donc je change le gid est je le met en 106 300 avec la commande suivante :
chgrp -R 106300 /srv/data/TEST_UBUNTU. Changement groupe GID ok pour le répertoire TEST_UBUNTU.

Maintenant, user_2 souhaite accéder au dossier TEST_UBUNTU
user_2 fait partie du groupe ADMINS, mais ne peut pas y accéder.
Pareil pour tous les autres utilisateurs du domaine.
Pourtant dans le groupe ADMINS, j'ai bien rajouté le groupe USERS DOMAIN.

Dernière modification par Mike2302 (Le 02/05/2024, à 15:27)

iznobe · Le 02/05/2024, à 15:43

et bien oui , mais les UID et GID seuls ne sont pas suffisant pour determiner un acces a un dossier .
il faut verifier les permissions du dossier en question avec la commande

ls -l

comme je l' ai dit dans un message precedent . sans ca impossible dire qui a le droit de faire quoi sur un dossier et donc son contenu , meme si celui ci lui appartient .

Exemple :

ls -l mon_fichier

--------- mon_fichier

personne ne peut lire ecrire ou executer ce fichier .
pour un dossier le principe est un peu different et vient complementer les permissions des fichiers .
si mon_fichier a maintenant pour permissions :
777 ou rwxrwxrwx ce qui revient au meme , tout le monde peut le lire , l' excuter , l ' ecrire .
ce fichier est dans MONSERVEUR/SRV/DATA et ce dossier a pour proprietés : rw-rw-rw , alors personne ne pourra traverser le dossier pour acceder a mon_fichier qui pourtant a toutes les permissions possibles ...

On tourne en rond avec ton histoire , tant que tu ne donnes pas des retours de commandes precis , meme avec des noms fictifs !

Dernière modification par iznobe (Le 02/05/2024, à 15:44)

Mike2302 · Le 02/05/2024, à 17:08

J'ai bien les droits ok pour ce dossier en drwxrws---+

J'ai l'impression que cela vient de windows et du montage NFS, comme si pour le client NFS je n'ai pas le droit d'y accéder.
Coté Linux, cela fonctionne.

iznobe · Le 02/05/2024, à 17:59

oui sauf que là , en plus y a les droits en ACL ( façon windobz ) du AD ( le " + " à la fin ) .
de plus y a un " s " c' est un droit spécial , il me semble que c' est le setgid dans ce cas , puisqu ' il est au niveau du groupe .

Voir https://tech.feub.net/2008/03/setuid-se … ticky-bit/ pour explications en francais .

y a de quoi avoir mal aux neurones effectivement avec tout ça

Dernière modification par iznobe (Le 02/05/2024, à 18:02)

Mike2302 · Le 03/05/2024, à 16:37

J'avoue ça fait mal à la tête ^^

Sur mon serveur Linux, l'utilisateur_A est affilié à plusieurs groupes de sécurité. La commande "groups utilisateur_A" me permet de visualiser tous ces groupes auxquels mon utilisateur est associé dans le domaine.

Cependant, lorsque j'accède à PowerShell depuis mon PC client, je constate que mon primaryGroup ainsi que supplementaryGroups sont vides, quand je fais un "get-NfsMappedIdentity - AccountType User".
J'aimerais pouvoir ajouter des groupes supplémentaires pour permettre à l'utilisateur d'appartenir à plusieurs groupes. Aurais-tu une solution ? Malgré mes tentatives avec diverses commandes, je n'arrive pas à ajouter ces groupes supplémentaires.

Est-ce que tu as une idée ?
Je ne pense pourtant pas à un problème de synchro entre le serveur Linux et le client Windows...
Merci d'avance

iznobe · Le 04/05/2024, à 11:57

Cependant, lorsque j'accède à PowerShell depuis mon PC client, je constate que mon primaryGroup ainsi que supplementaryGroups sont vides, quand je fais un "get-NfsMappedIdentity - AccountType User".

Malheureusement je ne connais pas les clients windobz ...
Par contre un truc bete , mais sait on jamais , il n ' y aurais pas une commande qui permet de " peupler " aussi les groupes ? genre :
"get-NfsMappedIdentity - AccountType Groups"

la " synchro " doit se faire a la demande je suppose , avec une commande appropriée .

je ne suis pas le plus competent en serveur , encore moins en AD

Dernière modification par iznobe (Le 04/05/2024, à 11:58)

iznobe · Le 04/05/2024, à 20:16

il ya cette doc , peut etre pourra t elle t ' aider : https://doc.ubuntu-fr.org/samba-active-directory

Mike2302 · Le 07/05/2024, à 14:57

top merci beaucoup Iznobe !

iznobe · Le 07/05/2024, à 19:54

Salut , pourrais tu nous en dire plus sur comment tu as pu resoudre le probleme stp ?

ca pourra probablement en aider d' autres et j ' apprendrai certainement quelquechose .

Mike2302 · Le 10/05/2024, à 10:39

en fait, je n'ai pas vraiment résolu mon problème. J'ai juste compris que je devais orienter mes recherches sur le magasin de mappage, utilisé pour mapper les groupes d'utilisateurs AD sur les groupes Unix/Linux. Le magasin de mappage est une partie importante de la configuration de l'intégration AD-Unix/Linux et Windows , car il définit comment les informations sur les utilisateurs et les groupes sont interprétées et gérées sur les deux plateformes.

Lorsque le magasin de mappage configuré est "MapFiles", cela signifie que les informations sur les utilisateurs et les groupes sont stockées dans des fichiers de configuration spécifiques sur le système Unix/Linux. Dans ce contexte, "PrimaryGroup" et "SupplementaryGroups" se réfèrent à deux types de groupes :
- Le groupe principal (PrimaryGroup) : Il s'agit du groupe principal auquel un utilisateur est associé dans Active Directory. Sur les systèmes Unix/Linux, chaque utilisateur doit appartenir à un groupe principal, qui est généralement utilisé comme propriétaire par défaut des fichiers créés par cet utilisateur.
- Les groupes supplémentaires (SupplementaryGroups) : Il s'agit des groupes auxquels un utilisateur est également associé dans Active Directory, en plus de son groupe principal. Ces groupes supplémentaires peuvent accorder à l'utilisateur des autorisations supplémentaires sur les fichiers et répertoires, en fonction des autorisations accordées à ces groupes sur le système Unix/Linux.

Reste à savoir comment rajouter les utilisateurs dans ces fichiers MapFiles. C'est pour cela que j'ai crée un nouveau sujet de discussion..

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 02/05/2024, à 13:49

[RESOLU] [PARTAGE NFS MOUNT KRB5i] - Accès impossible dossier partagé

#2 Le 02/05/2024, à 14:26

Re : [RESOLU] [PARTAGE NFS MOUNT KRB5i] - Accès impossible dossier partagé

#3 Le 02/05/2024, à 14:36

Re : [RESOLU] [PARTAGE NFS MOUNT KRB5i] - Accès impossible dossier partagé

#4 Le 02/05/2024, à 14:38

Re : [RESOLU] [PARTAGE NFS MOUNT KRB5i] - Accès impossible dossier partagé

#5 Le 02/05/2024, à 14:51

Re : [RESOLU] [PARTAGE NFS MOUNT KRB5i] - Accès impossible dossier partagé

#6 Le 02/05/2024, à 14:57

Re : [RESOLU] [PARTAGE NFS MOUNT KRB5i] - Accès impossible dossier partagé

#7 Le 02/05/2024, à 14:59

Re : [RESOLU] [PARTAGE NFS MOUNT KRB5i] - Accès impossible dossier partagé

#8 Le 02/05/2024, à 15:08

Re : [RESOLU] [PARTAGE NFS MOUNT KRB5i] - Accès impossible dossier partagé

#9 Le 02/05/2024, à 15:11

Re : [RESOLU] [PARTAGE NFS MOUNT KRB5i] - Accès impossible dossier partagé

#10 Le 02/05/2024, à 15:23

Re : [RESOLU] [PARTAGE NFS MOUNT KRB5i] - Accès impossible dossier partagé

#11 Le 02/05/2024, à 15:43

Re : [RESOLU] [PARTAGE NFS MOUNT KRB5i] - Accès impossible dossier partagé

#12 Le 02/05/2024, à 17:08

Re : [RESOLU] [PARTAGE NFS MOUNT KRB5i] - Accès impossible dossier partagé

#13 Le 02/05/2024, à 17:59

Re : [RESOLU] [PARTAGE NFS MOUNT KRB5i] - Accès impossible dossier partagé

#14 Le 03/05/2024, à 16:37

Re : [RESOLU] [PARTAGE NFS MOUNT KRB5i] - Accès impossible dossier partagé

#15 Le 04/05/2024, à 11:57

Re : [RESOLU] [PARTAGE NFS MOUNT KRB5i] - Accès impossible dossier partagé

#16 Le 04/05/2024, à 20:16

Re : [RESOLU] [PARTAGE NFS MOUNT KRB5i] - Accès impossible dossier partagé

#17 Le 07/05/2024, à 14:57

Re : [RESOLU] [PARTAGE NFS MOUNT KRB5i] - Accès impossible dossier partagé

#18 Le 07/05/2024, à 19:54

Re : [RESOLU] [PARTAGE NFS MOUNT KRB5i] - Accès impossible dossier partagé

#19 Le 10/05/2024, à 10:39

Re : [RESOLU] [PARTAGE NFS MOUNT KRB5i] - Accès impossible dossier partagé

Pied de page des forums