Sous Windows Server, la stratégie de mot de passe gérée par les GPO est commune à tous les utilisateurs.

À partir de Windows Server 2008 (et 2012 pour l’interface graphique, il me semble), si on veut définir des stratégies plus fines, on peut le faire en passant par les PSO (Password Settings Objects).
Il faut d’abord créer un groupe de sécurité, et y placer les utilisateurs concernés.
Ensuite, ouvrir le Active Directory Admin Center (ADAC) :
dsac.exe
Aller dans domain (local) -> System -> Password Settings Container et faire clic-droit -> Nouveau -> Paramètres de mot de passe.
Donner un nom et une priorité (1 = la + élevée) à la stratégie, régler les paramètres désirés, et choisir le groupe de sécurité précedemment créé dans “S’applique directement à”.

Une fois le PSO créé, il devrait s’appliquer correctement, uniquement aux utilisateurs positionnés dans le groupe, en étant prioritaire par rapport à la stratégie par défaut.

Généralités

La GPO est présente dans “Objets de Stratégies de groupe”. Elle n’y a aucun effet.

Elle doit être liée à un objet, qui peut être le Local system, un Domaine, un Site ou une OU (unité d’organisation).
Une fois liée, elle s’applique à cet objet, et tout ce qu’il contient.
On peut laisser le lien en place, mais le désactiver, via clic-droit sur le lien. ATTENTION, il s’agit de la notion de “Lien activé”, et non la notion d’“Appliquer” (qui est là pour forcer l’application de la GPO à la descendance).
Il est possible de désactiver les paramètres ordinateur et/ou utilisateurs d’une GPO.
Cela vaut le coup, après modification d’un GPO, d’attendre ~ une minute avant de faire gpupdate /force sur les clients, le temps qu’elle soit bien prise en compte et synchronisée sur les différents PDC.

Priorité et héritage

Les GPO sont appliquées dans l’ordre suivant, avec priorité à la dernière occurence :

1. Local
2. Site
3. Domaine
4. OU

Il est possible de bloquer l’héritage, ce qui bloque l’héritage reçu et non l’héritage légué.
On peut également “Appliquer” (Enforced) un lien vers une GPO. Ceci aura pour effet que cette GPO ne pourra pas être outrepassée par une GPO dans une OU descendant de celle-ci, et l’héritage sera forcé vers les descendants, même si ceux-ci le bloquent.

Groupes, OUs, Ordinateurs

La gestion des OUs et de leurs membres se fait dans Utilisateurs et Ordinateurs Active Directory. Les ordinateurs sont présents, en tant qu’objet Ordinateur, dans la catégorie Computers, mais également en tant que Groupe de sécurité “Ordinateurs du domaine” (donc dans la catégorie Users).
On peut sortir un ordinateur de la catégorie Computer, par exemple pour le mettre dans une OU, il restera par défaut dans le groupe “Ordinateurs du domaine”. Ceci permet de l’inclure quand même via les filtres de sécurité.

Lorsqu’on applique un filtre de sécurité, pour déterminer les (sous-)objets auxquels s’appliquer la GPO, ce sont des objets de type utilisateur, groupe, ordinateur, mais PAS des OU.
Les objets hors de ce filtre de sécurité n’ont, semble-t-il, pas le droit de lecture sur la GPO, donc impossibilité de l’appliquer.
Il me semble que cette mécanique empêche un compte hors du domaine (par exemple l’administrateur local d’un poste joint au domaine) d’appliquer quelque GPO que ce soit.

Lorsqu’une GPO est liée au domaine lui-même, elle concerne tous les objets du domaine, dont le groupe “Utilisateurs du domaine” et le groupe “Ordinateur du domaine”. Les paramètres utilisateurs et ordinateurs s’appliquent donc.
Toutefois, si on crée une OU SPECIAL_COMPUTER et une OU SPECIAL_USER, dans lesquelles on glisse respectivement un ordinateur, et un utilisateur, et que l’on lie une même GPO à ces 2 OUs, seuls les paramètres ordinateur s’appliqueront à la l’OU SPECIAL_COMPUTER et seuls les paramètres utilisateur s’appliqueront à l’OU SPECIAL_USER.

Il est possible de configurer un Loopback Processing Mode : on crée une GPO avec des règles utilisateurs, et on la lie à une unité contenant des ordinateurs. Avec l’activation du loopback, les stratégies utilisateurs s’appliquent aux utilisateurs loggés sur ces ordinateurs.
Pour ceci : modifier la GPO qui doit s’appliquer aux utilisateurs, et aller dans Config ordinateur / Stratégies / Modèles d'administration / Système / Stratégie de groupe et activer “Configurer le mode de traitement par bouclage de la stratégie de groupe utilisateur”.
La différence entre Remplacer et Fusionner est décrite dans le cadre de droite.
Si les Modèles d’administration sont absents, il faut les ajouter.

Diagnostic des GPO qui ne s’appliquent pas

• La GPO est-elle liée à l’objet désiré ? Directement ou via héritage ?
• Le lien est-il activé ?
• Des paramètres utilisateurs et/ou ordinateurs sont-ils désactivés ?
• Le filtrage de sécurité donne-t-il les autorisations de lecture à l’objet qui doit les appliquer ?
• Est-elle outrepassée par une autre GPO avec une priorité plus élevée ?
• Pour les installations de logiciel, ceci se produit avant l’ouverture de la session ; l’emplacement du fichier doit donc être accessible en lecture par le groupe “Ordinateurs du domaine”
• Pour les déploiements d’imprimante, il faut généralement déco/reco la session

http://woshub.com/group-policy-not-applied-troubleshooting/