Comme il est difficile de trouver de la doc claire et bien faite de nos jours !!!
 
Après quelques recherches j'ai fini par trouver de la doc sur les stratégies système faite par l'académie de nancy (çà sent le prof qui connait le mot pédagogie), mais malgré tout il y a encore certaines zones d'ombre sur le fonctionnement des stratégies dont j'aimerais vous faire part.
 
D'après cette doc http://www.ac-nancy-metz.fr/servic [...] ser_xp.htm
les stratégies du domaine sont prioritaires sur les stratégies système !
 
Or, en créant un utilisateur "test" en local sur mon poste XP avec les droits d'administrateurs puis en l'intégrant au domaine avec une stratégie empêchant l'accès au paramétrage de la connexion réseau par exemple, celle ci se voit mise au second plan car l'utilisateur "test" possède toujours tous les droits sur la machine. J'ai vérifié et ma stratégie "descend" bien du serveur car certaines fonctions s'activent correctement (j'avais demandé également la suppression du menu exécuter et celle-ci s'est appliquée).
 
1ère question : se peut-il que la stratégie du domaine et la stratégie locale se mélangent !!! Un peu de blocage de celle-ci, un peu de blocage de l'autre !! vous voyez ce que je veux dire ??
 
merci

Oui, les stratégies se cumulent, mais la priorité est a celle du domaine : si tu mets le parametre A a la valeur X sur le domaine et le paramètre B a la valeur Y en local, les 2 parametres s'appliqueront bien, par contre si tu mets le parametre A a la valeur X sur le domaine et le meme parametre A a la veur Y en local, il aura au final la valeur X.
 
Attention aussi au fait que ton utilisateur "test" est un utilsateur local : si tu modifies les parametres utilisateurs de ta GPO sur le domaine, ça ne s'applique que pour les utilisateurs du domaine dans les OU ou tu as placé ta GPO, par pour les utilisateurs locaux.

Merci El Pollo !! voilà une réponse claire et précise !!! on comprends tout de suite mieux.
 
J'en profite pour te poser une autre question.
 
J'ai crée un utilisateur TEST sur le domaine qui se trouve membre du groupe "utilisateurs du domaine", il se trouve dans le dossier USER, tout ce qui a de plus banal.
 
Lorsqu'il se connecte sur la machine, tout va bien : les programmes dans le systray apparaissent, l'utilisateur jouit d'une relative liberté mis à part qu'il ne peut aller bricoler les options du poste de travail ni la connexion réseau.
 
C'est là que je veux en venir, quelle stratégie est appliquée par défaut par le controleur pour que l'utilisateur du domaine voit ces fonctions précises bloquées ??? la Default domain policy ??? quand je vérifie cette stratégie, toutes les options par défaut sont sur "non configuré"
 
Peux-tu m'expliquer ce qu'il se passe précisément ?

Tout ça est vraiment tres basique et la doc abonde sur le sujet, ne serait-ce que sur le site de Microsoft, fait un peu de lecture c'est plus efficace que du question-réponse sur un forum.
Mais pour expliquer rapidement, de base la seule GPO qui s'applique est la webservice.olympiquelyonnais.com, mais qui effectivement vide : ce sont juste les paramètres locaux sur la machine (si tu n'y a pas touché non plus, ce sont les parametres par défaut de la version de windows installée) qui s'appliquent.
La si ton user du domaine de test est bloqué pour certaine chose c'est betement qu'un user du domaine créé par défaut n'a pas les droits d'admin ni au niveau du domaine ni au niveau des stations du domaine, les restrictions sont donc celle d'un simple user sur un Windows.

Quand je crée un utilisateur fraichement crée sur le domaine et qu'il se connecte sur la machine cliente, il a des droits restreints : normal.
 
Lorsque je veux ensuite copier le profil local de l'utilisateur (qui avait les droits d'admin sur la machine) c:\D&S\toto vers le profil du domaine c:\D&S\toto.domaine et que je me connecte : j'ai des droits ultra restreints !! Plus aucun prog ne se lance dans le systray, plus de papier peint.
 
Pourquoi la copie du profil vient-elle perturber les droits basiques de l'utilisateur du domaine fraichement crée ??
 
ce sera ma dernière question, après je me replonge dans la doc avec espoir de trouver une réponse.
 
merci de ta patience car je manque de temps en plus. J'ai pas eu le droit à ma formation et je dois mettre en place tout le bazar en quelques jours alors que j'y connaissais rien en 2003 et active directory

Dans le profil d'un user tu as un fichier ntuser.dat qui correspond aux paramatres propre a l'utilisateur stockés dans la base de registre (visible dans HKCU dans regedit quand l'utilisateur est loggué) : tu as des droits internes au registre en plus des droits sur le fichier en lui meme. La avec ce que tu as fait l'utilisateur toto.domaine le ntuser.dat de toto local : il a les droits d'ecriture sur le fichier en lui-même, mais au niveau du registre il n'y a que le toto local original (et les admins) qui a acces a ces infos, pas le toto du domaine. Depuis un profil correct lance regedit et fait un clic-droit, autorisations sur une clé pour voir ces droits.
Les problemes que tu decris decoulent de cette situation bancale.