Problème de montage lecteur reseau avec %USERNAME% dans chemin Résolu/Fermé

Question

Bonjour,
Bon je ne sais pas pourquoi mon précédent post à disparu.
Je poste la réponse:
 
Bon, le choix d'utiliser un gpo + script vient du fait que c'est la première mise en place de montage de lecteurpar l'AD plutôt que manuellement pour mes 200 users et ce durant une migration de serveur de fichier.
Il a fallut que je récupère les mappages déja montés en dur par les users puis que je retraite tout ça pour affecter les nouveau partage sur le nouveau serveur de fichier.

- le réseau n'a pas bien fini de "monter", et le script se lance. (il faut vérifier un paramètre de GPO : "attendre le réseau blablabla...." 
Mes autres lecteurs dans le même script se montent bien, donc le reseau fonctionne au momment du lancement du script.

- le login script doit être lancé pour des utilisateurs et non des machines (comprendre "contexte utilisateur" et non contexte "machine" : la GPO est-elle liée à une OU comprenant des utilisateurs ou des machines ?). Ce point est une très bonne piste.
Ma gpo UTILISATEUR, est lié à une OU contenant des utilisateurs et lance un script d'ouverture de session:
voici mon script:
net use * /delete /yfor /f "delims=" %%a in (\serveurfic\montages\%USERNAME%.txt) do %%a

Où "\serveurfic\montages" contient un fichier texte pour chaques utilisateurs, avec comme nom de fichier, le SamAccountname dans l'AD.

contenu d'un fichier txt:
net use W: \serveurfic\xxx /PERSISTENT:YESnet use X: \serveurfic\yyy /PERSISTENT:YESnet use Y: \serveurfic\users\%USERNAME% /PERSISTENT:YES
Les lecteur W: et X: se montent bien, mais pas le Y: => "erreur type 55"




Configuration: Windows 7 / Firefox 24.0

kelux · Answer

Effectivement j'ai aussi  le souci avec le forum, je voies pas les posts à jour à tous les coups etc ...


%username% ne peut pas être interprété dans une boucle for à la volée ... c'est un problème connu dans batch ;)
(c'est dans le 'do' que la variable %username% ne sera pas interprétée).
Ce n'est pas un problème lié à ton script, mais du langage ... les variables ne sont pas interprétées à la volée dans des boucles/blocs avec des brackets.
Le bloc de commandes sera d'abord interprété avant les variables, d'où l'erreur.

-

Par contre mon avis est que : tu te mets des batons dans les roues avec une boucle pour parser un .txt pour chaque user et voir quels sont les points de montage à mapper....
C'est simplement pas comme cela qu'il faut procéder ...

Si demain je dois ajouter un partage, ou changer la lettre de lecteur de tous les utilisateurs ; je dois modifier chaque .txt pour tout le monde ...
=> Ingérable, inexploitable.

Ensuite pour l'appartenance à un groupe, comment dissocier tel ou tel groupe ?
(si la réponse est "j'ajoute une GPO avec un autre login script pour ce groupe" ; alors pourquoi s'ennuyer à inclure tous les mappages dans un seul login script ?)

Tu fais du login script à la NT4 ici.

Plusieurs solutions :

- tu n'utilises pas de boucle 'for' pour lister tes commandes 'net use'.
- tu utilises un autre langage qui sait mettre des variables à la volée dans des brackets  : soit VBS , soit Powershell.

- Tu utilises les GPP (et là on fait de l'Active Directory) : je te conseille cette méthode.
Tu pourras aussi utiliser l'appartenance à des groupes pour donner des lecteurs mappés automatiquement sans toucher un quelconque fichier texte ou script ...

lsda · Answer

Ex: un nouvel user vient d'arriver à la compta, tu dois modifier le partage Compta pour ajouter les droits à cet utilisateur = méthode "pas bien", car tu es obligé de modifier les ACLS. 

J'utilise le modèle agdlp mais à la différence que je met directement les users dans le Groupe de Domaine Local, plutôt qu'un groupe de sécurité. c'est très rapide de rajouter ou supprimer des users d'un Groupe de Domaine Local depuis l'AD.

Le problème, pour reprendre ton exemple, c'est que je peut avoir des user de la compta qui devront avoir accès à des partages particuliers, mais pas d'autre utilisateur du même service de la compta.
Donc si je devais suivre ta logique, avec le modele agdlp, il faudrait que je crée un groupe pour chaque partage et que je mette ce groupe membre du GDL.
à ce moment là je pourrais appliquer la GPP plus finement par partage.

Pour les tests, c'est ce que je fais déjà ;-)

Bon, suite à la limitation du batch, j'ai réussit à lancer un .bat par utilisateur en faisant un call "\serverfic\%username%"
Donc j'ai changé mes point .txt par des .bat.

Je vais essayer de creuser la piste des gpp mais ca risque de me faire créer un groupe de securité en plus pour chaque partage.
Amoins qu'on puisse filtrer sur des groupe de domaine local???

En tout cas, merci pour ton aide.

kelux · Answer

Donc tu fais de l' ADLP ; mais comme tu n'avais pas abordé le sujet plutot, je faisais que des suppositions.

Il me semble que la portée (scope) du groupe lui importe peu lors de la création du GPP.
Toutefois, il m'avait semblé lire que certains GPP ne s'appliquaient pas lorsque des stations faisaient parti d'un Groupe de domaine Local, et que la GPP utilisait ce groupe.Il faut voir avec quelques tests pour confirmer ...

Dans les deux cas, Groupe de Domaine Local ou Groupe Global, il s'agit de groupe de sécurité. (même commentaire pour les groupes universels).
C'est la portée qui jouera dans des infras avec plusieurs domaines/forests.

-

Donc tu n'es pas obligé de créer un groupe global pour faire le target des GPPs, toutefois ça reste à confirmer, je n'ai pas d'infra de tests pour le faire.

-

Autre point, disons que tu as deux groupes  : Compta_R (lecture) et Compta_W (pour écriture/lecture).
Dans ton GPP, tu peux mettre plusieurs conditions (ET/OU...):
Mapper Y: sur la ressource \server\compta si user appartient à "Domaine\Compta_R"
OU
Mapper Y: sur la ressource \server\compta si user appartient à "Domaine\Compta_W"

-

Autre possibilité : on fait le targetting (filtre) par rapport à la structure des OUs :
Mapper Y: sur la ressource \server\compta si user appartient à l'OU "OU_Compta\OU_users\domaine"
Et ce peu importe le groupe ... par contre si le user n'est pas membre d'un des groupes de la compta, il aura pas le montage ... ça va foirer car pas de droits sur les datas. (Limitation : si tu gères ton arborescence basée sur les services ; ça ne s'applique pas à tout le monde donc ...)

-

Avec ta méthode, ce qui est dommage, c'est que l'appartenance à un groupe ne te permet pas automatiquement d'avoir le point de montage associé.
Tu es obligé de modifier tes logins scripts pour ajouter le lecteur mappé en plus de l'ajouter à un groupe. Alors qu'au final tu peux faire d'une pierre deux coups...

-

Autre question, si un user a uniquement l'accès juste en Lecture au partage, a t il réellement besoin d'avoir un lecteur mappé ?

-

Le modèle AGDLP, exemple :
J'ai 3 groupes, et on considère que les users de la compta ont accès à leur partage en ecriture quoiqu'il arrive.
DL_Compta_R
DL_Compta_W
GG_Users_Compta (qui est membre de DL_Compta_W).

Tu fais un GPP, qui target uniquement GG_Users_Compta pour ton lecteur mappé ....
Et pour en rajouter et aller plus loin, autant automatiser la gestion du groupe "GG_Users_Compta" ... j'aimerai y ajouter tous les users de l'OU compta dans ce groupe : on utilise ce qu'on appelle des "shadow groups" (script qui tourne et qui inspecte les users d'une OU et qui les ajoute au groupe ciblé ....)
ça ne marche uniquement si tu as une arborescence basée sur les services...
Tu créés juste le user dans l'OU Compta et il a automatiquement ses droits sur le serveur, et son lecteur mappé ... sans aucune autre intervention...

Limitations : plus on appartient à des groupes, plus le ticket Kerberos est gros, on peut arriver à avoir des problèmes d'authentification dans certains cas. (cherche TokenSize sur le net si tu es curieux)

-

Dernier point, pourquoi créer un partage pour chaque "service" ?
Alors qu'un seul dossier partagé serait suffisant, avec les sous-dossiers de chaque service en dessous (en cassant l'héritage pour garantir l'étanchéité) ....

Tu montes un seul lecteur pour tout le monde et basta ...
Tu montes un second lecteur pour le dossier user et hop ...

Tu mets en oeuvre "ABE" pour que les users ne voient pas les sous-dossiers auxquels ils n'ont pas accès et voila !

Problème de montage lecteur reseau avec %USERNAME% dans chemin

3 réponses

Discussions similaires