Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Pb droit écriture base de registre (ds appli VB6) suite à changement de domaine

1 réponse
Avatar
Cédric Girard
Bonjour

Sous ce titre un peu rébarbatif se cache un problème de droit qui nous
pourrit la vie à l'heure actuelle.

Architecture :
- 180 utilisateurs (sous NT 4.0 ou XP Pro) sur 6 sites géographiques,
exploitant des applicatifs VB6 / VB.Net tournant sur serveurs Citrix XP via
sessions TSE, sur notre domaine actuel
- changement de domaine prévu très prochainement après rapprochement avec
une autre entité (entreprise)

Les applis .Net ne posent aucun soucis particulier. Par contre les applis VB
6.0 font appel à des lectures/écritures dans la base de registre, dans
CurrentUser\Software\VB & VBA Settings\<nom de l'appli>...

Cette branche est créée lors de la première utilisation de l'appli par
l'utilisateur. Le hic, c'est que nos users "tests" situés dans le nouveau
domaine n'ont pas l'autorisation d'écrire à cet endroit de la BDR !

Lorsqu'ils se loguent avec l'ancien domaine (celui sur lequel les serveurs
sont encore situés) ça fonctionne parfaitement. À noter qu'il y a une
relation d'approbation entre les deux domaines.

Donc ma question : existe-t-il un moyen simple d'autoriser à l'ensemble des
utilisateurs du domaine à écrire dans certains endroits de la base de
registres, situés dans chaque partie propre de chaque utilisateur ?
(users/xxx.xxxxx.xxxx.xxxx.xxxx/Software/, pour chaque utilisateur en fait
!)


Voilà, difficile à expliquer, j'espère avoir été assez clair ;-)


--
Cédric Girard
OCERA-CFGA (Troyes, France)
"L'entropie, la quantité d'information, délivrée par un message est
inversement proportionnelle à sa prévisibilité" C.Shannon
-----
Visitez mon élevage de Maine Coons : http://www.chatterie-koolkat.com
-----

1 réponse

Avatar
Richard M.
"Cédric Girard"
| Architecture :
| - 180 utilisateurs (sous NT 4.0 ou XP Pro) sur 6 sites géographiques,
| exploitant des applicatifs VB6 / VB.Net tournant sur serveurs Citrix XP
via
| sessions TSE, sur notre domaine actuel
| - changement de domaine prévu très prochainement après rapprochement avec
| une autre entité (entreprise)
[...]

C'est un domaine quoi ? Windows 2000 ? Mode "Mixte" ou "Natif" ?
Quel version de Windows pour le serveur TS ?
A-t-il été installé en mode de sécurité 'strict' ou 'permissif' ?

| Cette branche est créée lors de la première utilisation de l'appli par
| l'utilisateur. Le hic, c'est que nos users "tests" situés dans le nouveau
| domaine n'ont pas l'autorisation d'écrire à cet endroit de la BDR !

Quels sont les droits sur cette partie de la base de registre ? (Regardes
avec regedt32...)

| Lorsqu'ils se loguent avec l'ancien domaine (celui sur lequel les serveurs
| sont encore situés) ça fonctionne parfaitement. À noter qu'il y a une
| relation d'approbation entre les deux domaines.

Y a un truc que je ne comprend pas là : L'application est sur un serveur TSE
dans l'ancien domaine.
Mais comment sont définis les groupes locaux ? En particulier, pourquoi
*précisemment* les utilisateurs de l'autre domaine arrivent à se connecter.
(Important pour remonter la piste des autorisations !)

Je pense à une salade avec groupe locaux "utilisateur" et "utilisateur TS" &
mode "mixte".

| Donc ma question : existe-t-il un moyen simple d'autoriser à l'ensemble
des
| utilisateurs du domaine à écrire dans certains endroits de la base de
| registres, situés dans chaque partie propre de chaque utilisateur ?
| (users/xxx.xxxxx.xxxx.xxxx.xxxx/Software/, pour chaque utilisateur en fait
| !)

Regardes du côté de la commande "Subinacl" du kit de resource.
Très intéressant dans le cas de migration de domaine. (La version du reskit
2003 a des fonctionnalités plus riches, même s'il y a une syntaxe que je
n'arrive plus à utiliser :-) .)
(Dans ce cas, je fais la manip sur les "ntusers.dat" des profils itinérant.
PAS sur USERS...)

Une autre idée, expéditive : définir la permission correcte au niveau de la
bdr de "Default User" et zapper tous les profils utilisateurs !

Probablement la meilleur idée : tirer au clair l'histoire des permissions
sur "HKCUSoftware" en regardant de près les groupes ayant autorisation.
Le problème me semble tellement inhabituel que je soupçonne une spécificité
d'installation du serveur.

--Richard.