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.

Troubleshoot KMS activation

Pour rappel, une fois l’installation de l’hôte KMS effectué, il est nécessaire que 25 postes clients ou 5 postes serveurs le contactent pour qu’il commence à délivrer les licences pour des OS et 5 clients ou serveurs pour la suite Office.

Une clé 2016 est capable d’activer tous les OS précédents.

Toutefois, une clé Office 2010 n’activera que du 2010 et une 2013 que du 2013.

Il est donc nécessaire d’avoir 5 client pour office 2010 et 5 clients pour office 2013 pour pouvoir activer les 2 éditions alors que ce n’est pas le cas pour Windows.

Quelque commandes utiles pour faire du troubleshoot avec un hôte KMS

Pour avoir un affichage détaillé des licences

 slmgr /dlv all

2017-05-22_14h13_47.png

Pour avoir un affichage de la clé actuellement installée

 slmgr /dli

2017-05-22_14h14_29.png

Pour modifier une clé

slmgr /ipk cle

2017-08-10_15h50_41.png

Pour activer une clé

slmgr /ato

2017-08-10_15h50_22.png

Vérification des entrées DNS de serveur KMS

nslookup -type=srv _vlmcs._tcp

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 dans Azure

Azure AD en réalité peut être comparé à AD LDS.

Il faudra noté qu’azure AD ne supporte pas l’authentification Kerberos ni NTLM. Seulement les protocoles récents sont supportés.

Lorsqu’on crée une vm dans Azure, il ne faut pas mettre une IP fixe via l’interface graphique mais utiliser Powershell afin d’effectuer une réservation. En effet, les vms dans Azure se voient affecter une adresse via un DHCP.

Lorsqu’on fait la promotion d’un DC, il faut s’assurer de mettre le sysvol et ntds sur un autre volume que C. Il faut donc penser à ajouter un autre vhdx.

Il est possible si la synchronisation de mot de passe est activée de créer automatiquement 2 DC avec les comptes renseignés dans azure AD en choisissant un nouveau domaine ou celui onpremise.

 

SCCM emplacement du fichier smsts.log

Lors du troubleshoot des séquences de tache sccm, il est nécessaire de lire le fichier smsts.log. Ce fichier voit son emplacement modifié au cours de l’évolution de la séquence de tache.

  • Sous Windows PE, avant le formatage du disque: x:\windows\temp\smstslog\smsts.log
  • Sous Windows PE, après le formatage du disque: x:\smstslog\smsts.log et copiés vers c:\_SMSTaskSequence\Logs\Smstslog\smsts.log
  • Sous Windows, avant l’installation de l’agent SCCM: c:\_SMSTaskSequence\Logs\Smstslog\smsts.log
  • Sous Windows (x86), après l’installation de l’agent SCCM: c:\windows\system32\ccm\logs\Smstslog\smsts.log
  • Sous Windows (x64), après l’installation de l’agent SCCM: c:\windows\sysWOW64\ccm\logs\Smstslog\smsts.log
  • Après l’exécution de la séquence de taches sous Windows (x86): c:\windows\system32\ccm\logs\smsts.log
  • Après l’exécution de la séquence de taches sous Windows (x64): c:\windows\sysWOW64\ccm\logs\smsts.log