Clés de registres modifiées via GPO

Le programme polviewer permet de connaitres les clées de registres modifiées via une GPO.

Publicités

Restauration du sysvol FRS

Dans le cas d’une infrastructure FRS, il arrive fréquement que la réplication SYSVOL ne soit plus opérationnelle.

On peut alors la réparer via diverses solutions :

  1. Dépromotion + repromotion du serveur impacté
  2. Utilisation d’une restauration non authoritaire
  3. Utilisation d’une restauration autoritaire

1. Dépromotion et repromotion

Cette solution sera utilisée si la méthode numéro 2 ne fonctionne pas et que la méthode 3 n’est pas envisageable dans certaines infrastructure de taille importante.

2. Utilisation d’une restauration non autoritaire

Ce cas est le premier à essayer. Il permet de placer un controleur de domaine dans un état d’esclave et recopier le sysvol depuis un autre DC du domaine.

Pour cela il faut aller modifier la valeur de la clé burflag de 0 à D2 à l’emplacement

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup

Et redémarrer ensuite le service. La clé passe alors à la valeur 0.

Au niveau du journal d’évènements on voit alors l’évènement 13565 pour le début d’une réplication ne faisant pas autorité et 13516 une fois la manipulation terminée.

3. Utilisation d’une restauration autoritaire

Ce cas la permet de dire dans le domaine qu’on a un serveur qui fait autorité pour la réplication et TOUS les autres DC. Il est donc nécessaire de positionner la valeur D4 de la clé en partie 2. pour le contrôleur faisant autorité et D2 pour tous les autres DC. On redémarre ensuite le DC qui a la valeur D4 et ensuite les autres DC à D2.

La suivi se fait via l’évènement 13566  pour le démarrage d’une restauration faisant autorité et 13516 une fois la réplication terminée.

Activation basée sur l’AD / KMS

Lorsqu’on souhaite activer les clients/serveurs on peut utiliser KMS ou alors l’activation basée sur l’AD. Cette dernière n’est disponible que pour des OS minimum windows 8 /2012. Si jamais les 2 activations sont disponibles alors les postes compatibles utiliseront d’abord l’AD et ensuite le KMS. Le fonctionnement pour l’activation concernant l’AD s’effectue lors de la jonction au domaine pour une validité de 180 jours renouvelée tous les 7 jours.

Si on veut supprimer l’activation basée sur l’AD il faut supprimer les objets présents dans le container suivant dans la console ADSI edit :

 partition de configuration / services / microsoft spp / activation objects

2017-08-28_11h51_55.png

GPO activer log pour troubleshoot

Il est possible d’activer les logs en cas de problème d’application de GPO pour aller un peu plus en profondeur. Pour cela, il est nécessaire d’exécuter ces actions sur le client :

Aller dans le registre à l’emplacement ci dessous

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion

Créer un nouveau répertoire Diagnostics

Créer une clé de registre GPSvcDebugLevel de type DWORD avec pour valeur 0x30002

Faire ensuite un gpupdate /force /target:computer ou gpupdate /force /target:user

Le fichier de log est généré à l’emplacement %windir%\debug\usermode\Gpsvc.log

 

AD troubleshoot enregistrements SRV DNS

Dans un domaine AD, plusieurs enregistrement DNS de type SRV sont effectués pour que les clients puissent localiser les serveurs AD.

Afin de pouvoir diagnostiquer les éventuels problèmes, plusieurs outils sont à notre disposition.

La commande ci dessous permet de tester les enregistrement DNS + LDAP sans utiliser le cache en faisant une nouvelle demande de DC locator.

nltest /dsgetdc:corp.contoso.com /force

2017-05-07_22h13_37.png

Les flags permettent de voir quelques options dont dispose le DC. En l’occurrence, on voit qu’il est PDC, GC, serveur AD, LDAP, prise en charge de l’authentification kerberos, serveur de temps, il possède bien les zones dns forest et domain. WS DS_8 signifie que le DC est au moins sur un OS 2012 et DS_9 2012R2. On a DS_10 pour 2016

Il est donc possible par exemple de filtrer tous les DC 2016 via la commande

Nltest /dsgetdc :contoso.com /force /ds_10

AD secure channel

Il peut arrivé que l’authentification d’un compte utilisateur sur le domaine ne soit pas possible et que l’on rencontre le message ci dessous lorsqu’on valide les credentials.

8fb7daacf3b24e82ac7fb31c4ae24355

La raison provient du secure channel entre la machine membre et le domaine qui a été cassé. Il existe alors plusieurs méthodes pour tester et tenter une réparation du secure channel

  • Powershell

Vérification de l’état du secure channel

 test-computersecurechannel

2017-05-07_19h54_01.png

Réparation du secure channel

<pre> test-computersecurechannel -repair -credential $(get-credential)</pre>

2017-05-07_21h58_28.png

  • nltest.exe

Vérification de l’état du secute channel

<pre>Nltest /sc_verify :corp.contoso.com </pre>

2017-05-07_22h05_32.png

Rq : Attention à ne pas utiliser la commande nltest /sc_query:corp.contoso.com qui garde en cache le résultat même si on arrête netlogon sur le DC qui est utilisé par le poste membre.

Reconstruction du secure channel

<pre>Nltest /sc_reset :corp.contoso.com</pre>

2017-05-07_22h06_26.png

 

 

 

AD services pour le fonctionnement

Afin de garantir le fonctionnement de l’AD voici les services indispensables

  • DHCP client car le client dhcp est en charge de l’enregistrement du client dans le serveur DNS pour les postes avant 2008. La description dans services.msc n’a pas été mise à jour.
  • FRS / DFSR pour la réplication du sysvol
  • DNS client pour l’enregistrement dans le DNS pour les postes à partir de 2008. Par défaut, le nom est enregistré via la machine (A) et pour le PTR (c’est le serveur DHCP)
  • DNS server
  • Kerberos Key distribution Center (KDC) pour l’authentification Kerberos
  • Netlogon pour le maintien du secure channel et les enregistrement SRV dans le DNS
  • Windows Time
  • AD DS
  • ADWS (webservices) sert à l’import du module powershell et donc à la console ADAC
  • Intersite messaging