Bonjour à tous,

Aujourd'hui nous abordons la partie 2 de notre série sur la migration du dossier SYSVOL du mécanisme FRS vers DFS-R, elle sera consacrée au déroulement global de celle-ci.

Etats de migration

Etats de migration globaux et locaux

Il existe deux types d'états de migration :

• Global : Les commandes pour initier les étapes de migration vont agir sur le PDC. Une fois que l'état de migration a changé sur le PDC, il est défini au niveau du domaine Active Directory, d'oû sa portée globale.
• Local: Une fois que l'état de migration a été défini sur le PDC, chaque contrôleur de domaine annexe va évaluer son propre état de migration par rapport à celui du domaine et va effectuer les opérations demandées si les deux ne correspondent pas. D'ou un état de migration local propre à chaque contrôleur de domaine.

Déroulement de la migration

La migration se compose de 4 états globaux qui sont les suivants :

Au niveau de chaque controleur de domaine, il existe 6 états locaux qui sont les suivants :

Schématiquement, nous pouvons résumer la migration (et un retour arrière) comme ceci :

Remarques importantes

• Un niveau fonctionnel de forêt/domaine AD 2008 minimum est nécéssaire pour démarrer la migration.
• Une copie du dossier original SYSVOL, appelée SYSVOL_DFSR et située au même endroit que le dossier SYSVOL orinigal, est utilisée en parallèle par DFS-R pour la réplication des données.
• La commande dfsrmig est utilisée pour configurer les états de migration et est à utiliser de préférence sur le PDC du domaine conerné, ou tout du moins sur n'importe quel contrôleur de domaine accéssible en écriture (hors RODC donc).
• Le retour arrière n'est possible que jusqu'à l'état 2. Pas de retour arrière possible une fois le domaine en état 3.
• Il faut vérifier manuellement l'état de réplication du dossier SYSVOL à chaque étape. Il n'y a pas de vérification automatique de l'intégrité du dossier SYSVOL lors de l'utilisation de la commande dfsrmig.
• Il n'est pas possible de renommer un contrôleur de domaine pendant toute la durée de la migration.
• Toute modification de GPOs, ou d'ajout/suppression de contrôleur de domaine durant la durée de la migration est fortement déconseillée, mais reste toutefois possible.
• Un contrôleur de domaine peut être éteint et allumé de nouveau pendant la migration.
• Les états de transitions sont plus longs pour les RODCs (c'est le PDC qui fait les opérations pour eux) et les sites distants.

Commandes utiles

• dfsrmig /GetGlobalState : Indique l'état de migration du dossier SYSVOL au niveau du domaine AD
• dfsrmig /SetGlobalState Numero_etat_de_migration (0,1,2,3) : Configure l'état de migration du dossier SYSVOL au niveau du domaine AD
• dfsrmig /GetMigrationState : Indique l'état de migration du dossier SYSVOL pour tous les contrôleurs de domaine du domaine AD
• repadmin /syncall /AeD : Force la syncronisation de tous les contrôleurs de domaine AD

Dans le prochain billet, nous entrerons plus en détail sur le déroulement de la première étape, Prepared.

Bonjour à tous,

Aujourd'hui nous commençons une série de billets consacrée à la migration du dossier SYSVOL du mécanisme de réplication FRS vers DFS-R.

Historique

FRS (File Replicating System) est un mécanisme de réplication de fichiers introduit avec Windows 2000 et à été utilisé au sein d'Active Directory pour la réplication du dossier SYSVOL.

Avec l'arrivée de Windows Server 2008, Microsoft a introduit une nouvelle technologie appellée DFS (Distributed File System). Cette technologie se décline en deux composants : DFS-N (qui gère les espaces de noms de dossiers partagés) et DFS-R (qui gère la réplication entre des dossiers).
Microsoft a rendu possible l'utilisation de DFS-R pour la réplication du dossier SYSVOL depuis Windows Server 2008 (et son niveau fonctionnel de forêt/domaine correspondant).

A partir de Windows Server 2008 R2, Microsoft ne permet plus l'utilisation de la technologie FRS pour la réplication de dossiers mais pour des raisons de compatibilité laisse cette possiblité pour le dossier SYSVOL jusqu'à Windows Server 2012 R2 (et son niveau fonctionnel de forêt/domaine correspondant).

Pourquoi migrer ?

Le mécanisme FRS n'est plus supporté par aucun contrôleur de domaine à partir de Windows Server 2016.

Plus précisemment, même si vous voulez ajouter un contrôleur de domaine sous OS Windows Server 2016 et garder un niveau fonctionnel de forêt/domaine Windows Server 2012 R2, ce n'est pas possible car Microsoft à tout simplement retiré les binaires FRS de l'OS ! (ce n'était pas le cas jusqu'à la RS3).

Même si vous avez effectué une montée du niveau fonctionnel d'une forêt AD, la migration de FRS vers DFS-R n'est pas éffectuée automatiquement.

DFS-R est le mécanisme de réplication utilisé par défaut pour le dossier SYSVOL depuis le niveau fonctionnel de forêt/domaine AD 2008 pour toute création d'une nouvelle forêt AD avec un niveau fonctionnel de forêt/domaine 2008. Si vous êtes dans ce cas, alors il n'y a pas de migration à prévoir.

En revanche, si vous avez hérité d'une forêt AD historique remontant à Windows Server 2003 et que vous n'avez éffectué uniquement que des montées de niveau fonctionnel de forêt/domaine AD sans vous préoccuper du SYSVOL, il y a de fortes chances pour que FRS soit toujours utilisé pour sa réplication.

Comment vérifier si FRS est toujours utilisé ?

Il faut passer par la console ADSIEdit.

Connectez-vous au Default Naming Context (Contexte de nommage par défaut).

Dans l'aborescence, allez dans CN=votredomaine,DC=local -> CN=System -> CN=DFSR-GlobalSettings. Ouvrez les propriétés de CN=DFSR-GlobalSettings.

Cherchez la propriété msDFSR-Flags et notez la valeur présente.

Si la valeur est nulle, alors c'est FRS qui est actuellement utilisé pour la réplication du dossier SYSVOL.

Si la valeur est 48, alors c'est DFS-R qui est actuellement utilisé pour la réplication du dossier SYSVOL.

Si la valeur est 0, 16 ou 32 alors c'est que la migration du mécanisme de réplication est en cours (0 correspond à l'état Start, 16 correspond à l'état Prepared, 32 correspond à l'état Redirected et 48 correspond à l'état Eliminated).

Dans le prochain billet, nous aborderons la procédure de migration du dossier SYSVOL du mécanisme FRS vers DFS-R.

Bonjour à tous !

Aujourd'hui voici un billet pour les personnes rencontrant des problèmes de coupures intempestives sur des lecteurs réseau.

Contexte :

Des utilisateurs travaillant sur des lecteurs réseau vous rapportent des problèmes d'accès intempestifs à leurs fichiers, avec des coupures ou des lecteurs marqués comme déconnectés dans le poste de travail.
Ces coupures peuvent intervenir à n'importe quel moment de la journée et ne suivent pas des intervalles précis.

Cependant les serveurs hébergeant les partages concernés par les coupures semblent être toujours les mêmes, tout comme les postes de travail.

Vous pouvez remarquer que les plantages surviennent aussi lorsque les fichiers sont utilisés sur de longues periodes (applicatif sur un lecteur réseau par exemple).

Solution :

Depuis Windows Server 2012 R2 ainsi que Windows 8, Microsoft a introduit une nouveauté dans le traitement des stratégies de groupe.

Le traitement des paramètres de préférences de stratégies de groupe (les fameuses Group Policy Preferences), et plus particulèrement celles concernant les lecteurs réseau se passe désormais en arrière-plan (background processing) et non plus uniquement à l'ouverture de la session d'un utilisateur (foreground processing).

En conséquence, quand vos lecteurs réseau sont mappés avec l'option Replace et non l'option Update, chaque rafraîchissement de la stratégie de groupe concernée entrainera une suppression du lecteur réseau, puis sa re-création provoquant ainsi une coupure temporaire.

C'est donc une nouvelle Best Practice à adopter, l'option Replace ne doit être utilisée que lorsque vous avez besoin d'écraser un paramètre pour le remplacer par un différent (je pense notemment à des mappages d'imprimantes lors d'un changement d'imprimante), l'option Update doit désormais être préférée pour tous les éléments ne devant pas être écrasés mais simplement mis à jour.

A bientôt,

Réinitialisation du mot de passe :

Avec un compte faisant partie de "Read_Laps"

Normalement lorsqu'un compte ne fait pas partie du groupe "Reset_Laps", il ne bénéficie pas du droit de réinitialiser le mot de passe, vérifions cela.

Avec le client lourd  :

En effet nous pouvons constater que lorsque l'on essaie de réinitialiser le mot de passe le client affiche au bas de la fenêtre un message "Failed to request password reset"

Avec Powershell :

Avec Powershell le résultat est le même (voir plus explicite), l'utilisateur ne possède pas les droits.

Avec un compte faisant partie de "Reset_Laps"

Maintenant nous allons utiliser un compte qui se trouve dans le groupe "Reset_Laps" mais pas dans le groupe "Read_Laps", par conséquent il n'est pas possible de lire le mot de passe mais je devrais pouvoir le réinitialiser. 

Avec le client lourd  :

Cette fois-ci nous pouvons constater que le mot de passe n'est pas lisible, et au bas du client lourd le message "Password reset request was successful".

Avec Powershell :

Conclusion :

Grâce à cette solution gratuite de Microsoft vous pouvez améliorer la sécurité de votre parc informatique en réduisant la portée d'attaque d'une intrusion à l'aide du compte administrateur local.

https://www.microsoft.com/en-us/download/details.aspx?id=46899&wt.mc_id=fy16techdays

https://technet.microsoft.com/en-us/library/security/3062591?wt.mc_id=fy16techdays

https://blogs.msdn.microsoft.com/laps/

https://support.microsoft.com/en-us/kb/3062591

Voici quelques commandes Powershell pour trouver les OU dont l'héritage est bloqué:

$GPOBlocked = Get-ADOrganizationalUnit -SearchBase "DC=LAB,DC=Org" -Filter * | Get-GPInheritance | Where-Object {$_.GpoInheritanceBlocked}
$GPOBlocked.count
$GPOBlocked | Select Name,Path

Le DistinguishedName (Path) n'est pas toujours agréable à lire je fais donc une conversion en CanonicalName, ensuite vous pouvez afficher les données à l'écran ou les écrire dans un fichier:

$GPOBlocked | ForEach-Object {
        $Name = $_."Name"
        $Path = $_."Path"
        $CanonicalName = Get-ADOrganizationalUnit -Filter {DistinguishedName -like $Path} -Properties CanonicalName | Select-Object -ExpandProperty CanonicalName
        Write-Output "$Name; $CanonicalName" | Add-Content C:\Temp\GpoInheritanceBlocked.txt
    }

Vérifications Serveur / Clients

Depuis le serveur

Vérifions l'état du mot de passe du compte Administrateur Local d'une machine cible.

Avec le client lourd  :

Avec Powershell :

Depuis l'Active Directory dans l'onglet éditeur d'attribut 

Depuis le poste Client

Avec un compte faisant partie de "Read_Laps"

Réalisons donc une mise à jour de la stratégie de groupe 

Nous allons pouvoir vérifier l'état du mot de passe du compte admin local.

Avec le client lourd  :

Avec Powershell :

Avec un compte faisant partie de "Reset_Laps"

Avec le client lourd  :

Avec Powershell :

Test de connexion

Nous testerons donc de nous connecter à la machine avec le nouveau mot de passe

C'est fonctionnel.

Mise en Oeuvre :

Installation sur l'infrastructure :

Pour réaliser l'installation de LAPS sur un serveur membre nous aurons besoin dans un premier temps d'un compte avec les droit Administrateur Local sur le serveur, puis de bénéficier des droits Admin du Schéma puis Admin du domaine ou Admin de ou des Unités d'Organisation en fonction de l'étendue sur laquelle vous souhaiter déployer LAPS. (Pour ma part je l'ai fait avec un compte "Admin du Domaine" sur lequel j'ai accordé les droits "Admin du schéma" le temps de l'installation).

L'installation se fait en suivant les étapes ci-dessous :

1. Installation de LAPS avec les composants Serveur.
2. Extension du schéma.
3. Attribution des droits.
   1. Droits pour les computers .
   2. Création des groupes de sécurité.
   3. Délégation des droits aux groupes de sécurité sur les OU.
4. Paramétrage des GPO
   1. Import des fichiers ADMX et ADML.
   2. Création et paramétrage de GPO.

Etape 1 : Installation de LAPS avec les composant serveur :

Le fichier msi fournit par LAPS permet d'installer les composants clients et serveurs, par défaut seul les composants clients sont installés, dans notre cas nous souhaitons déployer les composant serveurs nous sélectionnerons donc les "Management Tools".

Vous remarquerez la présence de 3 modules pour les "Management Tools" :

1. Fat Client UI : Soit l'interface utilisateur client lourd permettant de récupérer les mot de passe en clair dans l'AD
2. Powershell module : L'interface Powershell
3. GPO Editor Templates : Les ADMX

Etape 2 : Extension du schéma

Exécuter Powershell en tant qu'Administrateur.

# Import du module
Import-module AdmPwd.PS
# Update du schéma
Update-AdmPwdADSchema

Etape 3 : Attribution des droits.

Pour attribuer aux machines le droit de modifier leurs attributs exécutez :

Set-AdmPwdComputerSelfPermission -OrgUnit "OU=Machines,DC=LAB,DC=INFO"

Pour créer les Groupes de sécurité afin de déléguer les droits (Lecture et Réinitialisation), vous avez deux options (en graphique via ADAC ou User & computers AD, ou avec Powershell, pour ma part ce sera Powershell).

# Création du Groupe Read_Laps
New-AdGroup -Name "Read_Laps" -SamAccountName "Read_Laps" -Description "Group For Read Permission" -GroupCategory Security -GroupScope Global -Path "OU=Groups,OU=IT,OU=Main,DC=LAB,DC=ORG"

# Création du Groupe Reset_Laps
New-AdGroup -Name "Read_Laps" -SamAccountName "Reset_Laps" -Description "Group For Reset Permission" -GroupCategory Security -GroupScope Global -Path "OU=Groups,OU=IT,OU=Main,DC=LAB,DC=ORG"

Nb: Le nom des groupes est un choix personnel, libre à vous de mettre autres choses.

Nous allons maintenant déléguer les droits sur une OU à l'aide des commandes suivantes :

# Permet d'attribuer le droit de lecture du mot de passe au Groupe "Read_Laps" sur l'OU "Main/IT/Computers"
Set-AdmPwdReadPasswordPermission -Identity "OU=COMPUTERS,OU=Main,DC=LAB,DC=ORG" -AllowedPrincipals Read_Laps –Verbose

# Permet d'attribuer le droit de changement du mot de passe au Groupe "Reset_Laps" sur l'OU "Main/IT/Computers"
Set-AdmPwdResetPasswordPermission –Identity "OU=COMPUTERS,OU=IT,OU=Main,DC=LAB,DC=ORG" –AllowedPrincipals Reset_Laps –Verbose

Nb : Le droit peut être déléguer sur l'ensemble du domaine, pour ma part seul les "Domain Admins" bénéficie de ce privilège.

Etape 4 : Paramétrage des GPO.

Par défaut, LAPS positionne les fichiers ADMX et ADML sur le poste local, si on veut les placer dans le SYSVOL de l’organisation, on ira donc récupérer :

• C:\Windows\PolicyDefinitions\AdmPwd.admx -> A copier dans le "%systemroot%\sysvol\domain\policies\PolicyDefinitions"
• C:\Windows\PolicyDefinitions\en-us\AdmPwd.adml -> A copier dans le "%systemroot%\sysvol\domain\policies\PolicyDefinitions\EN-US" (Option à répéter pour chaque langage de votre AD).

Nb: Si toutefois vous n'aviez pas les répertoires ci-dessus, il faudra les créer manuellement avec un compte ayant les droits.

Il ne nous reste plus qu'à déployer les stratégies de groupe pour définir le comportement de LAPS.

1. On ouvre donc "Group Policy Management" et on créé une nouvelle GPO (Dans cet Démo, on la nommera simplement "LAPS").
2. On accède aux nouveaux paramètres : Computer Configuration -> Policies -> Administrative Templates -> LAPS

C'est donc à partir de ces nouveaux paramètres que nous allons pouvoir activer ou inhiber LAPS et pouvoir agir sur les différentes politiques de sécurité :

• Intervalle de changement de mot de passe.
• Longueur et complexité du mot de passe.
• Définir le nom du compte Administrateur (Seulement si ce dernier à été renommé).

Activation de LAPS

Paramètre du nom de compte Administrateur : Ne pas configurer si le compte est celui par défaut.

Spécifications de longueur et complexité du mot de passe.

La configuration serveur est maintenant terminée.

Installation sur le client :

Comme par défaut le fichier msi n'installe que les composants client, il vous sera possible de scripter l'installation à l'aide de le commande : msiexec /i <emplacement>\LAPS.x64.msi /quiet

La partie client de LAPS est un CSE (Client Side Extension), soit une extension qui vient s’enregister auprès du service client de stratégies de groupe de Windows. Il s'agit donc bien d'une installation d'un composant de l'OS et non un nouveau service, que vous pourrez retrouver par défaut sous %programfiles%\LAPS\CSE\AdmPwd.dll

A chaque déclenchement du CSE, ce dernier :

• vérifie si le mot de passe est expiré à l'aide du dernier changement stocké dans l'attribut ms-Mcs-AdmPwdExpirationTime.
• S'il l'est, en génère un de manière aléatoire basé sur les politiques de sécurité définies par la GPO.
• Met à jour le mot de passe et l'inscrit en clair dans l'attribut ms-Mcs-AdmPwd et modifie l'attribut ms-Mcs-AdmPwdExpirationTime de l'objet Ordinateur dans l'Active Directory.

Voila la configuration est maintenant terminée, mappons la GPO et vérifions.

Vous êtes vous déjà posé la question "Mon parc informatique est il vulnérable?".

En terme de sécurité dans une grande majorité des cas la réponse est "Oui", mais alors pourquoi?

Grand nombre de personnes justifierons que le parc est à jour (Update, antivirus, firewall...), à cela je ne vous poserais que deux questions :

1. Le compte Admin Local est il désactivé sur toutes vos machines comme préconisé par Microsoft ? Si la réponse est non on peut déjà douter.
2. Le mot de passe du compte Admin Local des postes et/ou des serveurs est il différent sur chaque machine ? Si la réponse est non on à une faille de sécurité.

Envisageons simplement que  le mot de passe sur une de vos machines vient à être compromis, d'un coup, c'est l'ensemble de votre parc qui l'est et cela sans avoir besoin d'utiliser le compte Admin du domaine.

Une fois la première machine compromise il n'y a plus qu'a rebondir sur les autres pour pouvoir compromettre l'intégralité du parc.

Et si je vous disais qu'on pouvait gérer ce problème avec un outil développé par "Microsoft Consulting Services" et fournit gratuitement par Microsoft, laissez moi vous présenter LAPS.

Introduction à LAPS :

LAPS, qu'est ce que c'est?

LAPS pour "Local Admin Password Solution" est un outils permettant la gestion et le stockage du mot de passe Administrateur Local des machines du domaine : Postes clients et Serveurs membres.

Cette solution permet:

• De mettre à jour le mot de passe dans le contexte système et de l'envoyer au contrôleur de domaine à l'aide d'un composant client. Création aléatoire du mot de passe et transmission au contrôleur de domaine de manière crypté à l'aide de kerberos version 5 et Advanced Encryption Standard (AES).
• De stocker le mot de passe et sa durée de validité comme attribut de l'objet machine de l'Active Directory. ms-Mcs-AdmPwd et ms-Mcs-AdmPwdExpirationTime.
• Gérer le déploiement des paramètres de manière centraliser via les Stratégie de Groupes. Nom du compte, fréquence de changement, longueur et complexité.
• La récupération des mots de passe pour les utilisateurs habilités via une interface graphique ou Powershell. Par défaut seuls les "Admins du domaine" sont autorisés à accéder à ces informations mais il est possible de déléguer les droits sur un groupe.

Illustration à l'aide d'un schéma d'architecture de la solution :

Jusque là c'est sympa mais comment ça fonctionne?

Le coeur  de la solution LAPS est une extension d'un composant du client Stratégie de Groupe (CSE - Client Side Extension) qui pendant la mise à jour des Objets de Stratégies de Groupe, effectue et peut forcer les actions suivantes  :

1. Vérifier si le mot de passe Administrateur Local est expiré (Contrôle de la date de validité et de la configuration de la GPO).
2. Générer un nouveau mot de passe si l'ancien a expiré ou nécessite d'être changé avant expiration.
3. Valider que le nouveau mot de passe répond aux politiques de sécurité.
4. Envoyer le nouveau mot de passe à Active Directory et le stocker avec un attribut confidentiel dans l'objet ordinateur dans l'Active Directory.
5. Envoyer la prochaine date d'expiration du mot de passe à Active Directory et le stocker en tant qu'attribut dans l'objet ordinateur dans l'Active Directory.
6. Modifie le mot de passe du compte Administrateur local.

Il est possible de déléguer les droits suivants:

• Read Permission : Permet de lire le mot de passe depuis l'Active Directory, le client lourd LAPS ou avec Powershell par les utilisateurs autorisés. L'autorisation se fait par délégation de droits à des Groupes de sécurités (par défaut les "Admins du domaine").
• Reset Permission : Permet de soumettre une demande de changement de mot de passe depuis le client lourd LAPS ou avec Powershell.

Prérequis et OS supportés :

Prérequis :

Infrastructure :

• Active Directory : Windows Server 2003 SP1 ou ultérieur (L'attribut confidentiel n'est supporté qu'à partir du 2003 SP1 dans Active Directory)
• Ajout des attributs ms-Mcs-AdmPwd et ms-Mcs-AdmPwdExpirationTime (Action réalisé lors de l'installation).
• Restriction aux utilisateurs qui ne doivent pas accéder à l'attribut (retrait du All Extended Rights pour les groupes sensibles).
• Installation & paramétrage d'un ADMX.

•  Être Admin du Schéma le temps de l'installation (une Extension de Schéma est requise lors de l'installation)

Outils d'administrations :

• .NET Framework 4.0.
• Windows PowerShell 2.0 or ultérieur.

OS Supportés :

Clients : Windows 10 , Windows 8.1, Windows 8, Windows 7, Windows Vista avec le dernier Service Pack

Serveurs : Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, Windows Server 2008,  Windows Server 2003 avec le Service Pack 2 (mais plus supporté)

Note : Les machines Itanium ne sont pas supportées.

Bonjour,

Après un second article sur l'analyse de ce fichier, voici un troisième complétant celle-ci et traitant plus spécifiquement des paramètres CSE.

Les paramètres CSE

Les paramètres CSE sont également appelés Client Side Extensions.

Ils correspondent à des fichiers DLL installés sur les clients stratégies de groupe et sont capables d'interpréter les paramètres contenus dans les stratégies. Vous pouvez voir la liste complète des extensions présentes sur votre poste en allant dans la clé registre suivante : HKEY_LOCAL_MACHINE/Software/Microsoft/Windows NT/CurrentVersion/Winlogon/GPExtensions

Deux types de traitements existent :

• Background
• Foreground

Le traitement de type Background concerne tous les paramètres CSE pouvant être modifiés sans impact pour l'utilisateur sur son poste.

Le traitement de type Foreground concerne tous les paramètres ne pouvant pas être traités en arrière-plan, les plus connus étant les paramètres Folder Redirection, Software Installation et GPP Drive Mapping. Le mode Foreground est activé uniquement au démarrage d'un poste ou lors de l'ouverture d'une session par utilisateur.

Traitement des paramètres CSE

Le traitement de ces paramètres est repérable dans la section suivante :

GPSVC(274.22f8) 11:11:30:216 ProcessGPOs: Both user and machine lists are defined. Merging them together.
GPSVC(274.22f8) 11:11:30:720 NlaQueryNetSignatures returned 1 networks
GPSVC(274.22f8) 11:11:30:720 Estimated bandwidth on one of the connections : 0 kbps
GPSVC(274.22f8) 11:11:30:721 Estimated bandwidth on one of the connections : 718611 kbps
GPSVC(274.22f8) 11:11:30:721 ReadExtStatus: Reading Previous Status for extension {35378EAC-683F-11D2-A89A-00C04FBBCFA2}

[...]

GPSVC(274.22f8) 11:11:30:761 ProcessGPOs: -----------------------
GPSVC(274.22f8) 11:11:30:761 ProcessGPOs: Processing extension Group Policy Environment
GPSVC(274.22f8) 11:11:30:761 CompareGPOLists: The lists are the same.
GPSVC(274.22f8) 11:11:30:761 CompareGPOLists: The lists are the same.
GPSVC(274.22f8) 11:11:30:762 CheckGPOs: No GPO changes but couldn't read extension Group Policy Environment's status or policy time.

On peut remarquer que :

• L'état précédent de l'extension est évalué en premier
• La valeur hexadécimale retournée pour indiquer quelle extension est analysée correspond à la liste des extensions présente dans le registre dans la clé GPExtensions
• Dans le cas d'un rafraîchissement périodique des GPO (Background Processing), une comparaison est effectuée afin de détecter les changements qui auraient été effectués depuis le dernier rafraîchissement. On remarque bien que les paramètres ne sont pas réapliqués de nouveau.

Nous allons voir ici un dernier exemple, lorsqu'un Foreground Processing est effectué (ouverture d'une session utilisateur) :

GPSVC(274.178c) 09:29:22:013 ProcessGPOList: Entering for extension Registre
GPSVC(274.178c) 09:29:22:013 UserPolicyCallback: Setting status UI to Application de la stratégie Registre...

• Le fichier des paramètres registre locaux (ntuser.pol) est analysé
• Une suppression de tous les paramètres registre présents est effectuée
• Une lecture du fichier des paramètres registre (registry.pol) pour chaque GPO est faite
• Le paramètre correspondant est appliqué dans le registre
• Une réapplication complète des paramètres utilisateurs registre est donc effectuée

Logs supplémentaires pour les paramètres CSE

Afin de pouvoir pousser les investigations encore plus loin, il est possible d'activer des fichiers de logs supplémentaires pour chaque extension CSE. Voici les principaux :

Bonjour,

Après un premier article sur l'activation de ce fichier, voici un second sur l'analyse de celui-ci.

Vous pouvez le trouver dans le dossier C:\Windows\debug\usermode\gpsvc.log

Threads

Sur les machines avec des architectures multi-coeurs, il peut y avoir plusieurs threads qui s'exécutent au même moment (un thread pour les paramètres utilisateurs et un thread pour les paramètres machine.). Il peut être utile de savoir les différencier dans le fichier de log.

Pour se faire, il suffit d'analyser les valeurs rapportées pour GPSVC :

GPSVC(78d.666) 12:41:45:477 Caller requesting for user notification/lock is from session 0

On remarque que celles-ci sont composées de deux parties :

• 78d : Correspond au PID (Process ID) (en héxadécimal)
• 666 : Correspond au TID (Thread ID)

Début du traitement des stratégies

Le traitement des stratégies débute toujours avec les paramètres machine.

Il peut être repéré par l'enregistrement suivant :

GPSVC(2dc.18c) 11:40:08:707 bMachine = 1
GPSVC(2dc.18c) 11:40:08:707 Setting GPsession state = 1

Connectivité réseau

Immédiatement après le début du traitement des stratégies machines, une vérification de la connectivité réseau est faite :

GPSVC(2dc.18c) 11:40:08:707 bMachine = 1
GPSVC(2dc.18c) 11:40:08:707 Setting GPsession state = 1
GPSVC(2dc.520) 11:40:08:707 Waiting for connectivity before applying policies

Souvent, le client Stratégies de groupe démarre avant que la connectivité réseau soit effective, ce qui génère le message suivant :

GPSVC(2dc.18c) 11:40:08:806 There is no connectivity. Waiting for connectivity again …

Mais quelques secondes plus tard, la connectivité est établie :

GPSVC(2dc.18c) 11:42:09:106 We have network connectivity… proceeding to apply policy.

En cas de non connectivité (30 secondes de timeout par défaut), on trouvera toujours l'erreur suivante :

GPSVC(2dc.520) 11:45:10:033 Application complete with bConnectivityFailure = 1.

Note : Cela peut être une erreur de connectivité mais pas uniquement réseau, cela peut concerner du LDAP par exemple

Estimation de la bande passante

Avant de traiter les stratégies de groupe, une estimation de la bande passante est faite.

Celle-ci est calculée en se connectant d'abord à un contrôleur de domaine afin d'obtenir une liste de ceux-ci, puis en évaluant la vitesse de la connexion entre le poste et un contrôleur de domaine. Le calcul de la bande passante est effectuée par le NLA (Network Location Awarnesss).

Le début de l'estimation se présente comme ceci :

GPSVC(2cc.c28) 15:56:04:821 GetDomainControllerConnectionInfo: Enabling bandwidth estimate.
GPSVC(2cc.c28) 15:56:05:134 Started bandwidth estimation successfully

La fin de l'estimation se présente comme ceci :

Ordre de traitement des stratégies

• Le lien d'un GPO peut être appliqué (enforced) ou/et désactivé
• Une stratégie peut avoir des paramètres ordinateurs/utilisateurs désactivés
• Le blocage de l'héritage au niveau de l'OU est activé
• Le mode bouclage est activé

Lecture des stratégies :

• 0 : Paramètre par défaut
• 1 : Le lien est désactivé
• 2 : Le lien est appliqué (enforced)

Traitement des stratégies :

• La présence d'un filtre WMI est détecté en 1er et s'il est présent, il est évalué.
• Le GUID de la GPO renvoie à son chemin physique dans le dossier SYSVOL.
• La présence de paramètres CSE est évaluée
• L'état de la GPO (désactivée ou non) est évaluée afin de décider de son traitement
• La présence de paramètres CSE est évaluée