Hello,
 
J'ai un soucis bien tordus comme vous les aimez
 
J'ai des serveurs Citrix XenApp 6.5, sous Windows Server 2008 R2. A l'ouverture de session, les utilisateurs ont un script de logon qui se charge entre autres de mapper les lecteurs réseau dont ils ont besoin (script VBS).
 
Un fournisseur nous a livré un package SCCM permettant le déploiement du client IBM DB2 v9 (oui je sais, c'est vieux). L'install du package s'est bien passée, mais on a un effet de bord des plus étranges : depuis cette install, malgré la bonne exécution des scripts de logon (les fichiers LOGs générés par le scripts le sont bien), aucun lecteur réseau n'est mappé !!
Si je désinstalle le client DB2, le problème persiste !
 
Une idée de quoi ça peut venir avant que je me tape la réinstall complète des serveurs ?
 
A noter que si une fois ma session ouverte je lance manuellement le script de logon, les mappages se font. Ca sent le paramétrage à la con modifié par l'install du client DB2...

J'ai trouvé une piste...
 
A l'install du client DB2, un groupe DB2ADMNS est créé localement sur le serveur, et des droits lui sont attribués sur le système.  
Pour des raisons fonctionnelles, le groupe des utilisateurs du domaine était imbriqué dans ce groupe.
 
En fait, le système semble considérer ce groupe DB2ADMNS comme le groupe Administrateurs local, et bloque les mappage réseau à cause de l'UAC.
 
Ce que je ne m'explique pas du coup, c'est comment il détermine que ce groupe DB2ADMNS est un groupe d'administration, alors qu'il n'est pas imbriqué avec le groupe Administrateurs... Une idée ?
 
Je suppose que c'est lié à un de ces droits, mais lequel... (cliquez pour agrandir) :

Mais c'est quoi cette appli pourrie    
 
Débugger les programmes -> le plus haut niveau de privilège que tu peux avoir sur un OS Windows
 
En gros tous les utilisateurs de ton domaine ont plus de droits sur ces serveurs que les administrateurs.
 
Faut brûler ton appli là

Si seulement...
Je vais cuisiner l'équipe en charge de l'appli pour déterminer si ils ont réellement besoin de ce type de droits. J'en suis pas bien sûr.
 

Accessoirement donner des droits à tous les utilisateurs du domaine c'est merdique aussi.
 
Le minimum c'est que l'appli accorde des droits sur la base d'un groupe AD, et que tu puisses placer les utilisateurs de l'applicatif (et eux uniquement) dedans.
 
Par contre, les scripts logon en VBS, ça appartient à l'histoire. Remplace les par des GPP c'est tellement plus simple et plus fiable.

Les serveurs eux-mêmes sont spécialisés pour cette appli ou des applis ayant besoin de ce client. La population est de toute façon limitée.

Je sais que les GPP c'est tellement mieux...mais c'est pas moi qui décide ou développe les scripts de Logon, etc. On doit cohabiter avec des infras plus anciennes, on est tributaire d'environnements beaucoup plus larges.

A toi de voir pour la partie sécurité si le besoin business surpasse le risque. Si tu dépends d'environnements plus larges, ceux-ci n'ont pas de directives en matière de packaging/sécurité applicative ? Pas de cahier des charges transverse ?
 
Tu n'as pas moyen de faire un test via GPP au moins ? C'est typiquement le genre de situation où elles se comportent de façon plus fiable que les scripts. Et si concluant cela te permettrait d'appuyer ce changement de configuration  

Je suis passé aussi en gpp en refaisant les serveurs il y a quelques années, c'est ultra simple à faire fonctionner, très souple (applicables en fonction des bons critères dont les admins ont besoin, avec des ET et des OU pour affiner), et ça n'a jamais buggué malgré tous les changements appliqués ensuite.
Les trucs exécutés auparavant par du vbs sont également exécutés par des gpp.
À essayer !

Je sais que les GPP c'est bien, etc. Mais je ne peux pas tout simplement pas les utiliser, je dois utiliser ce qui m'est fourni.
 
Pour le coup, j'ai pu virer les utilisateurs du groupe DB2ADMNS. A priori, utiliser le groupe DB2USERS suffit.