Ok vous avez terminé votre migration sous 2008R2 et vous avez plein de nouvelles features, comme la corbeille AD avec un niveau fonctionnel de forêt sous 2008R2…

Et bien en termes de PRA béton: Il ne vous reste plus qu’à passer sous Windows 8… Ceci afin de pouvoir faire des snapshots de vos V-DC La phrase suivante fera plaisir à mes collègues Hypervisor et VMDude:

Microsoft is working with other virtualization vendors to make sure they include this technology in the latest version of their hypervisors as well. It’s in their interest to do so.

winrm id -r:%machinename%

Or le message d’erreur suivant est apparu:

WSManFault Message = The WinRM client cannot complete the operation within the time specified. Check if the machine name is valid and is reachable over the network and firewall exception for Windows Remote Management service is enabled.

Les ouvertures de port ont été vérifiées (test du 5985 via telnet par ex) et nous avons suivi, entre autres, les étapes de troubleshooting de ce post et de cet article technet. Tout semblait OK, c’est en regardant le journal d’événements que nous avons vu l’erreur suivante:

L’événement d’ID 128 du journal “Windows Remote Management/Operational” indique une ERROR_WINHTTP_TIMEOUT. Le problème vient donc d’une requête HTTP envoyée qui n’aboutit pas, nous avons donc utilisé WireShark pour faire une capture réseau et filtrer le trafic HTTP:

A notre grande surprise tout le trafic était redirigé vers le port 8080 d’un serveur proxy situé dans subnet non joignable à partir de notre IP. Nous avons donc lancé la commande netsh for Windows HTTP suivante:

netsh winhttp show proxy

Et le résultat confirme nos soupçons:

Le serveur qui est au fait une VM, a été déployé à partir d’un template qui embarquait cette configuration proxy. Nous avons donc réinitialisé ce paramètre à l’aide de la commande:

netsh winhttp reset proxy

WinRM fonctionne maintenant correctement,  pour terminer il est possible de configurer WinRM afin qu’il utilise un proxy, mais ce n’était vraiment pas notre objectif

Une fois vos clients configurés et votre serveur Event Collector en place, les clients commencent à envoyer au serveur les événements auquel ce dernier a souscrit dans le journal Forwarded Events. La description de certains événements envoyés par un client XP ou 2003 à un serveur 2008 peut ne pas correctement s’afficher. Vous aurez alors ce type de description  pour l’event posant problème: 

The description for Event ID ( %ID% ) in Source ( %SOURCE% ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer 

Cela vient du fait que l’exécutable ou la DLL assurant la traduction de ce message sur l’ordinateur local (i.e. l’event collector Windows 2008 server), n’est pas présente ou possède une version incompatible avec la version du même exécutable ou DLL  en charge de lire les événement de même source sur le client (Windows XP ou Windows 2003).

La solution pour résoudre ce problème est donnée dans ce post de Event Log Blog. Dans notre cas, le message concernait la source  %SOURCE%  = KmsRequests du journal Key Management Services. Nous avons donc vérifié que le clef HKLM\System\CurrentControlSet\Services\Eventlog\Key Management Services\KmsRequests existait:

Ce qui était le cas, cependant on constate que l’exécutable sppsvc.exe donné par la valeur de EventMessageFile, possède une version différente entre le client XP/ 2003 et le serveur 2008:

Nous avons donc copié l’exécutable sppsvc.exe du client XP/2003 sur le serveur Event Collector dans le répertoire C:\XP2003clients et modifié la valeur EventMessageFile de la clef HKLM\System\CurrentControlSet\Services\Eventlog\Key Management Services\KmsRequests de la manière suivante:

Une fois le serveur Event Collector rebooté la description des événements forwardés par le client XP-2003 est bien interprétée:

Vous pourrez alors, par exemple, traiter le contenu de la description de l’event en Powershell avec le cmdlet Get-WinEvent.

Get-QADUser -NotMemberof 'ldap389\domain users' | export-csv domusers.csv

Après avoir retiré du fichier les comptes qui ne doivent pas être membre du groupe utilisateurs du domaine, comme le compte guest par exemple. Il nous reste à ajouter les comptes mal migrés dans le groupe utilisateurs du domaine et surtout définir ce groupe comme étant le groupe primaire du compte:

$csv = import-csv domusers.csv
 
foreach ($line in $csv) { Add-QADMemberOf $line.UserPrincipalName -Group 'ldap389\domain users' ; Set-QADUser $line.UserPrincipalName  -ObjectAttributes @{primaryGroupID=@(513)} }

Vous remarquez que 513 est l’ID pour définir le groupe primaire utilisateurs du domaine, pour une liste complète des groupes primaires connus et les IDs correspondants vous pouvez vous référer à cette KB.

1. Commande: adprep /domainprep /gpprep: 
   • Problèmes de droits:

   Lors du lancement de cette commande, vous avez un code d’erreur “LDAP API ldap_modify_ext_s() finished, return code is 0×32” alors il s’agit problème de droits, la commande a pourtant bien été lancée avec un compte membre de “domain admins” . En ouvrant le fichier adprep.log nous avons les informations suivantes:

   [2010/11/26:15:12:19.468]
   Adprep was about to call the following LDAP API. ldap_modify_s(). The entry to modify is CN={64E2BDA7-0FC4-48DA-BB70-79261A7B4822},CN=Policies,CN=System
   ,DC=ldap389,DC=info.
   [2010/11/26:15:12:19.468]
   LDAP API ldap_modify_ext_s() finished, return code is 0×32

   Il s’agit d’un problème sur une GPO qui intervient lors de la partie gpprep du setup. Nous allons donc vérifier les permissions sur celle ci:

   

   L’administrateur qui a créé la GPO a retiré les droits au groupe “domain admins”, pour corriger cela il faut se mettre propriétaire de l’objet et rétablir les droits sur celui-ci. Une fois cela corrigé, la commande adprep /domainprep /gpprep passe sans problème.

   • Remarque concernant le staging:

   Si l’intervalle de réplication entre certains de vos contrôleurs de domaine est long (i.e. un de vos DCs réplique une fois tous les X jours avec ses partenaires de réplication) alors le répertoire de staging de votre SYSVOL peut augmenter de manière conséquente, ceci de manière temporaire. En effet, l’ensemble des GPOs de votre domaine étant modifiées par la partie gpprep du setup, toutes ces modifications doivent être répliquées sur l’ensemble des DCs, le répertoire de staging voit alors sa taille augmenter tant que le DC répliquant le moins souvent n’a pas répliqué les modifications, cette taille baisse au fur et à mesure que ce DC réplique les modifications sur son partage SYSVOL.

2. Commande adprep /rodcprep:

Si vous rencontrez le message d’erreur suivant: “Adprep could not contact a replica for partition DC=DomainDnsZones,DC=ldap389,DC=info“, alors il vous suffit de lancer le script correctif fournit dans cette KB.

Si vous désirez lire plus d’articles concernant les erreurs avec adprep je vous conseille la lecture de cet article technet et de ce post de askDS.

Exchange ActiveSync doesn’t have sufficient permissions to create the “CN=<user name>,OU=<OU Name>,DC=ldap389,DC=info” container under Active Directory user “Active Directory operation failed on <dc-name>.ldap389.info. This error is not retriable. Additional information: Access is denied.
Active directory response: 00000005: SecErr: DSID-03151E04, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
“.
Make sure the user has inherited permission granted to domain\Exchange Servers to allow List, Create child, Delete child of object type “msExchangeActiveSyncDevices” and doesn’t have any deny permissions that block such operations.

Une solution est proposée dans cet article, cependant dans notre cas l’héritage était bien activé sur le compte. Le problème vient du fait que notre compte est de la classe InetOrgPerson et non de la classe user.

Quand on regarde les permissions mises en place lors de l’extension de schéma pour Exchange 2010 qui sont détaillées dans cet article Technet:

On remarque que la création d’objets msExchActiveSyncDevice par “Exchange Servers” n’est autorisée que sur les objets de classe user mais par sur les objets de classe InetOrgPerson. Ce qui interpelle, c’est que pour d’autres types de permissions les deux classes d’objets utilisateur sont bien prises en compte:

Il nous suffit d’appliquer les mêmes permissions pour les objets de classe InetOrgPerson et le problème est résolu:

Permissions à mettre en place au niveau de votre domaine si l’emploi des comptes utilisateurs de classe InetOrgPerson est généralisé.

Merci à mon collègue UtOpiK et à l’équipe d’intégration du projet Exchange 2010 d’avoir remonté ce bug.

Les principaux problèmes rencontrés sont apparus lors du lancement de la commande: “setup.com /PrepareAD /OrganizationName:<Organization Name>”. Nous allons voir la résolution  d’un problème bloquant et d’un warning.

1. Message d’erreur: “The Exchange organization name is invalid”:

Le setup sort en erreur avec le message d’erreur suivant, que l’on trouve dans le fichier Exchangesetup.log:

The Exchange organization name is invalid. Message: ‘The property value you specified, “{335A1087-5131-4D45-BE3E-3C6C7F76F5EC}”, isn’t valid. The value must not contain “‘~’, ‘`’, ‘!’, ‘@’, ‘#’, ‘$’, ‘%’, ‘^’, ‘&’, ‘*’, ‘(‘, ‘)’, ‘_’, ‘+’, ‘=’, ‘{‘, ‘}’, ‘[', ']‘, ‘|’, ‘\’, ‘:’, ‘;’, ‘”‘, ”’, ‘<’, ‘>’, ‘,’, ‘.’, ‘?’, ‘/’”.’

Cela est du au fait qu’une précédente préparation du schéma pour Exchange 2003 a été réalisée, ceci sans qu’aucun serveur Exchange n’ai été installé dans votre domaine. La commande setup /forestprep créé un nom d’organisation temporaire avec le GUID mentionné ci dessus lors du lancement de la preparation de schéma pour Exchange 2003. Le nom d’organisation définitif n’est définit que lors de l’installation du premier serveur Exchange. Pour plus de détails sur l’extension de schéma pour Exchange 2003 vous pouvez lire cet article. Dans les versions suivantes de Exchange, le nom de l’organisation est donné lors de la préparation du schéma AD.

Pour corriger cela il vous suffit d’utiliser le CD d’installation Exchange 2003 et de lancer la commande “Setup /removeorg”, ceci afin de supprimer l’organisation temporaire (voir cette KB pour plus de détails). Puis de relancer votre commande “setup.com /PrepareAD /OrganizationName:<Organization Name>” avec les sources Exchange 2010.

Ce problème a déjà été evoqué sur un forum technet pour Exchange 2007, nous avons rencontré le même problème pour la preparation du schéma Exchange 2010. La même résolution est proposée.

2. Warning: The recipient “ldap389.info/users/test-user” is invalid and couldn’t be updated:

Ce message d’avertissement ne bloque pas l’extension de schéma Exchange 2010. Mais peut poser problème lorsque la BAL pour test-user sera configurée. L’attribut MailNickName du compte possédait une valeur, cet attribut existait sur les comptes du domaine (apporté par la précédente modification de schéma Exchange 2003) mais a été utilisé pour les besoins d’une autre application que Exchange. La valeur de l’attribut a donc du être nettoyée afin d’éviter ces warnings

L’application et la réplication des GPOs dans notre domaine fonctionnait normalement, par contre l’édition des stratégies de groupe sur le DC impacté devenait impossible, en même temps que la GPMC freezait une surcharge CPU du process lsass.exe survenait sur le contrôleur de domaine et ceci tant que la GPMC n’était pas killée sur la console. Nous avons donc continué à éditer nos GPOs à partir d’autres DCs et le fonctionnement de la production était quasi-normal le temps de la résolution de l’incident.

Afin de mieux comprendre le problème, la première chose à faire est de lancer lors du freeze de GPMC une analyse avec Server Performance Advisor sur le DC dont voici le résultat:

On voit que le DC a du mal à effectuer une recherche LDAP initiée par la GPMC et cela entraine une consommation anormale du process lsass.exe, afin d’en savoir plus nous réalisons deux analyses de trames avec WireShark sur nos consoles d’administration: La première en reproduisant le problème en lançant la GPMC connecté au DC impacté, la seconde en connectant la GPMC à un autre DC et sur lequel l’édition de GPOs est possible:

On voit que sur le DC posant problème la requête LDAP n’aboutit pas, au bout de plus de 2 minutes toujours pas de résultat. Lors d’un fonctionnement normal de la GPMC, les GPOs liées à notre OU sont trouvées en quelques secondes.

Il nous faut maintenant identifier quelle requête LDAP n’arrive pas à traiter notre DC, pour cela nous allons activer le diagnostique Active Directory Field Engineering, l’événement d’ID 1644 sera alors généré lorsque le problème survient, celui ci est caractéristique d’une requête LDAP consommant trop de ressources. Une fois l’audit activé, nous avons alors l’événement suivant qui apparaît lors du freeze de GPMC:

Les valeurs retournées par la requête sont GPLink et GPOptions (on peut d’ailleurs observer le résultat sur la capture de trames réseau).  Le filtre de recherche se fait sur ObjectCategory qui est un attribut indexé par défaut de la base AD. La requête LDAP devrait donc être réalisée rapidement, ce qui n’est pas du tout le cas, nous en avons malheureusement la confirmation en lançant la même requête avec ldp.exe, le résultat est le suivant:

———–
***Searching…
ldap_search_ext_s(ld, “DC=ldap389,DC=info”
, 2, “( |  (objectCategory=CN=Domain-DNS,CN=Schema,CN=Configuration,DC=ldap389,DC=info)  (objectCategory=CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=ldap389,DC=info) )”, attrList,  0, svrCtrls, ClntCtrls, 10, 0 ,&msg)
Error: Search: Timeout. <85>
Server error:
Error<94>: ldap_parse_result failed: No result present in message
Getting 0 entries:
———–

La requête tombe en Timeout, alors que sur les autres DCs aucun problème avec celle ci. Nous avons donc décidé dans un premier temps d’augmenter la valeur du paramètre MaxQueryDuration des stratégies LDAP de notre DC, ainsi que de configurer ldp.exe afin d’augmenter la période de TimeOut. Ces manipulations n’ont servi à rien.

Après quelques recherches nous sommes tombés sur cet article très instructif de Tim Springston. Il affirme que:

“if the attribute(s) which are showing as taking an extended amount of time to search for are already indexed then the lack of an index is clearly not your problem.  Sometimes indices, perhaps through frequent changes or other reasons, need to be re-indexed to remove “whitespace” or other problems.  So checking the integrity of the database or doing an offline defrag may be the way to go.”

Procédons donc d’abord à une analyse sémantique du ntds.dit de notre DC:

Le résultat est immédiat: des inconsistances dans la base ont été trouvées. Nous relançons cette fois la même analyse sur la base, mais en mode “fixer les problèmes” (voir point 11 de la KB). Pour terminer nous réalisons une défragmentation offline du ndts.dit et nous quittons le mode DSRM pour rebooter notre DC normalement.

Une fois le DC redémarré nous essayons d’utiliser la GPMC en étant connecté sur le DC qui posait problème: L’utilisation de l’éditeur de stratégies de groupe se fait normalement et nous pouvons à nouveau éditer des GPOs sur ce contrôleur de domaine.

On voit que le DC est particulièrement sollicité aux horaires de bureau, la piste d’une application utilisée par les postes clients nuisant aux performances du DC semble donc la plus plausible. Nous laçons donc une analyse avec SPA sur le DC impacté dont voici le résultat:

La requête SamEnumUsersInDomain nous prend 42% de CPU, l’IP des clients provoquant ces requêtes n’est malheureusement pas remontée de manière claire via l’outil, nous allons donc utiliser WireShark  pour analyser l’activité réseau de notre DC et identifier les clients:

Après un peu d’analyse des trames nous voyons que le protocole de communication Windows (MCPP) utilisé par ces requêtes est MS-SAMR, il nous suffit d’utiliser le filtre Wireshark correspondant (SAMR) pour identifier les clients. Après avoir envoyé la liste de ces derniers au service informatique du site impacté il s’est avéré que ce sont des portables avec le logiciel HP ProtectTools security manager installé. Celui ci a été retiré de la plupart des postes, car les SMART cards n’étaient pas utilisées, et le résultat a été immédiat sur la courbe CPU des DCs:

Afin de d’identifier sur la partie cliente le processus émettant via un protocole particulier vers une autre machine vous pouvez utiliser le logiciel TCPview ou bien CurrPorts que mon collègue de CTXBlog présente dans cet article.

Le problème concernant l’application HP ProtectTools a été discutée sur un des forums HP, la solution serait de passer le Sp41408 de l’application, cependant nous avons fait le choix de désinstaller cette application, car elle était inutile pour nous.

Ce problème a déjà été traité dans un post de l’équipe AskDS, nous allons le compléter avec des scripts et commentaires qui vous aideront à mieux venir à bout de ce virus.

La méthode qui s’est avérée la plus payante est l’utilisation de la stratégie permettant d’activer les échecs d’authentification dans le journal de sécurité des DCs. Pour cela créer une GPO avec filtrage de sécurité sur les DCs impactés qui permet d’appliquer les paramètres suivants :

Mettre à jour les stratégies de groupe sur les DCs concernés, vous devriez voir apparaître les événements suivants dans le journal de sécurité:

Laisser tourner cet audit pendant plusieurs minutes puis désactiver la GPO de façon à ne pas trop poluer votre journal de sécurité. Voyons maintenant plus précisément le contenu de l’événement d’ID 672:

Nous voyons que nous pouvons récupérer l’IP du poste infecté via “Client Adress”. Nous allons donc réaliser un script qui scanne le journal de sécurité du DC à la recherche de cet événement et nous compte le nombre d’occurences de chaque IP. Nous aurons alors les PCs les plus infectés et sollicitant le plus notre DC.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89

'Enter Name of your DC
strComputer = "XXXXXX"
 
Const ForReading = 1, ForWriting = 2, ForAppending = 8
Set fso = CreateObject("Scripting.FileSystemObject")
 
sCurPath = fso.GetAbsolutePathName(".")
 
Set FLog = FSO.CreateTextFile(sCurPath&"\ip.txt")
 
Set objWMIService = GetObject("winmgmts:" _
 & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
 
'Get time one hour ago
dtmCurrentDate = DateAdd("h", -1, now)
 
'Format time
dtmTargetDate = Year(dtmCurrentDate)
dtmMonth = Month(dtmCurrentDate)
If Len(dtmMonth) = 1 Then
 dtmMonth = "0" & dtmMonth
End If
dtmTargetDate = dtmTargetDate & dtmMonth
dtmDay = Day(dtmCurrentDate)
If Len(dtmDay) = 1 Then
 dtmDay = "0" & dtmDay
End If
dtmTargetDate = dtmTargetDate & dtmDay
dtmHour = Hour(dtmCurrentDate)
If Len(dtmHour) = 1 Then
 dtmHour = "0" & dtmHour
End If
dtmTargetDate = dtmTargetDate & dtmHour
dtmTargetDate = dtmTargetDate & "0000.000000"
dtmTargetDate = dtmTargetDate & chr(43) & Cstr(120)
 
'search all EventID 672 occuring one hour ago
Set colLoggedEvents = objWMIService.ExecQuery _
 ("SELECT * FROM Win32_NTLogEvent WHERE Logfile = 'Security' AND EventCode = '672' AND TimeWritten >='"&dtmTargetDate&"'")
For Each objEvent in colLoggedEvents
'parse the Message IP is between Client Adress and Certificate Issuer Name
   message = objEvent.Message
   message1 = split(message,"Client Address:")
   messagef = split(message1(1),"Certificate Issuer Name:")
   FLog.Writeline (messagef(0))
Next
msgbox "View all IPs in ip.txt, now lets count occurences"
FLog.close
 
Set df1 = fso.OpenTextFile(sCurPath&"\ip.txt",ForReading,True)
Set FLog2 = fso.CreateTextFile(sCurPath&"\result.csv")
 
Dim IPCOUNT(80000,2)
 
'Initialize counting table
for j=0 to 80000
IPCOUNT(j,0) = "0"
IPCOUNT(j,1) = 0
Next
'read lines of ip.txt and save result in table, if a new IP is discovered a new column is filled in with IP otherwise counter is increased by one
Do while Not df1.AtEndOfStream
IPTST = df1.readline()
marque = "non"
   if IPTST <> "" then
   i=0
      Do While IPCOUNT(i,0) <> "0"
           if IPCOUNT(i,0) = IPTST then
             IPCOUNT(i,1) = IPCOUNT(i,1) + 1
             marque = "oui"
         End if
      i = i + 1
      Loop
 
      if marque = "non" then
      IPCOUNT(i,0) = IPTST
      IPCOUNT(i,1) = 1
      End if
 
  End if
Loop
 
df1.close
 
'write table result in text file
for k=0 to 80000
FLog2.writeline(IPCOUNT(k,0)&";"&IPCOUNT(k,1))
Next
 
msgbox "Done, Check result.csv"

Pour télécharger le script vbs c’est ici:

Les IPs dont le nombre d’occurrences est le plus fort correspondent aux postes à traiter le plus rapidemment par votre service informatique. Cet audit est à réaliser en plusieurs fois, car biensur les postes éteints et inféctés ne sont pas localisés par cet audit. De plus Conficker s’active via des tâches planifiées, donc il se peut que lors de votre audit la tâche soit inactive. Au bout de plusieurs audits nous sommes venus à bout de ce virus sur un site particulièrement infecté, en témoigne le graphique d’activité CPU du DC ci dessous:

Pour terminer il se peut que certains postes infectés ne soient pas atteignables facilement par votre service informatique et que vous ne pouvez pas attendre pour régler ce problème de charge CPU car cela pénalise les autres utilisateurs. Il existe pour cela une manière simple mais radicale: bannir cette IP afin qu’elle ne contacte plus votre DC à l’aide la commande suivante, à lancer sur votre DC:

cmd /c route -p add %CLIENT_IP_ADRESS% MASK 255.255.255.255 %UNUSED_IP_ADRESS%

La variable %UNUSED_IP_ADRESS% correspond à une adresse IP du même subnet que votre DC qui ne pointe sur rien, et %CLIENT_IP_ADRESS% l’adresse IP du poste infecté. Le commutateur /p permet de garder cette route même après reboot du DC. Cette commande est à lancer sur tous les DCs que le poste infecté est susceptible d’atteindre.