Si vous avez des applications qui ne font que des accès en lecture dans ADDS, ces applications continuent à fonctionner aussi bien sur les DC en écriture (writable DC) que sur les RODC.

Les applications qui interagissent avec l'ADDS utilisent 2 types de technologie : ADSI (Active Directory Service Interface) ou LDAP (Lightweight Directory Access Control). Pour localiser un DC, ces applications utilisent en général la fonction DsGetDcName() du DC Locator, le résultat de la fonction DsGetDcName() pourrait être soit un DC ou un RODC, tout dépend des arguments passés dans la fonction DsGetDcName().

. Pour une application ADSI, la fonction DsGetDcName() du DC Locator est appelée implicitement. Par défault un DC (writable) est retourné.

. Pour une application LDAP, le développeur peut appeler explicitement la fonction DsGetDcName() et pourrait passer comme argument un DC (writable) ou un RODC. Si lors d'une opération en écriture et un DC est passé comme argument, faire tourner cette application sur un RODC ne devrait pas poser de problème. Il faut juste vérifier que le DC (writable) passé en argument est joignable.

Pour avoir plus d'information sur la fonction DsGetDcName(), vous trouverez des détails sur ce lien :

DWORD DsGetDcName(
  __in   LPCTSTR ComputerName,
  __in   LPCTSTR DomainName,
  __in   GUID *DomainGuid,
  __in   LPCTSTR SiteName,
  __in   ULONG Flags,
  __out  PDOMAIN_CONTROLLER_INFO *DomainControllerInfo
);

http://msdn.microsoft.com/en-us/library/ms675983.aspx

. Les opérations d'écriture sur un RODC

Si l'application ADSI ou LDAP fait une demande d'écriture sur un RODC, cette requête d'écriture échoue et le RODC retourne un referral vers un DC, cette application doit être capable de répondre à ce referral et d'utiliser les informations reçues pour localiser un DC. Une application ADSI est capable de le faire automatiquement. Mais pour une application LDAP, le développeur doit la configurer l'application LDAP pour localiser un DC en écriture. Cette configuration est appelée un LDAP_Write_Referral.

Pour plus d'information, voir :

http://msdn.microsoft.com/en-us/library/system.directoryservices.aspx

http://msdn.microsoft.com/en-us/library/system.directoryservices.referralchasingoption.aspx

. Les opérations d'écriture et de lecture :

Certaines opérations d'écriture puis de relecture des mêmes données pourraient échouer dans un environnement où il y a des RODC. En effet, l'opération d'écriture a été effectuée sur un DC, mais l'opération de relecture est faite sur un autre DC en lecture, en l'occurence un RODC. Ce scénario pourrait échouer dans la mesure où les changements faits sur le DC ne sont pas encore répliqués sur le RODC. Afin d'éviter ce problème, s'assurer que les opérations de lecture et d'écriture sont faites sur le même DC.

http://technet.microsoft.com/en-us/library/cc772597.aspx

Dans tous les cas de scénario décrits ci-dessus, il est conseillé de tester toutes les applications qui sont destinées à fonctionner sur un RODC.

Huu-Duc Le

Sous Windows NT4 et Windows 2000, il n'est pas possible de définir de manière détaillée les permissions sur les journaux d'événements. Les permissions implémentées par défaut vis-à-vis des journaux d'événements sont:

• Full control pour les utilisateurs possédant le droit "Manage auditing and security log".
• Lecture des journaux Application et System pour tout le monde, y compris pour le compte Guest.

Il est possible de retirer le droit de lecture au compte Guest des journaux Application et System en créant la valeur RestrictGuestAccess de type REG_DWORD et en la mettant à 1 sous la clé: HKLM\System\CCS\Services\EventLog\<nom_journal> (Par exemple: HKLM\System\CCS\Services\EventLog\System)

Un redémarrage est nécessaire pour que cette valeur soit prise en compte.

A partir de Windows Server 2003 et Windows XP, l'accès aux journaux d'événement est contrôlé:

• Par les permissions gérant les accès distants à la registry. Elles sont positionnées sur la clé HKLM\System\CCS\Control\SecurePipeServers\WinReg
• Par des permissions positionnées sur chaque journal. Elles sont stockées dans le registre, dans la valeur CustomSD du paramétrage de chacun des journaux (sous HKLM\SYSTEM\CurrentControlSet\Services\EventLog).

Les valeurs de CustomSD contiennent le secutity descriptor au format SDDL. Trois permissions peuvent être positionnées: Read, Write et Clear. Pour le journal Security, seules les permissions Read et Clear peuvent être positionnés car le droit Write est réservé à LSA.

Les valeurs positionnées par défaut sont:

• Pour le journal Application, Directory Service, DNS Server: O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG)(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x5;;;SO)(A;;0x1;;;IU)(A;;0x1;;;SU)(A;;0x1;;;S-1-5-3)
• Pour le journal System: O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG)(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x7;;;SO)(A;;0x3;;;IU)(A;;0x3;;;SU)(A;;0x3;;;S-1-5-3)
• Pour le journal sécurité: O:BAG:SYD:(D;;0xf0007;;;AN)(D;;0xf0007;;;BG)(A;;0xf0005;;;SY)(A;;0x5;;;BA)

Ces permissions sont plus restrictives que sous Windows 2000 car elles n'autorisent pas la lecture par le réseau aux comptes utilisateurs. Elles les autorisent par contre, pour ces derniers, lorsqu'ils sont connectés en interactif.

Plus de détail sur cette fonctionnalité dans l'article technique
323076 - How to set event log security locally or by using Group Policy in Windows Server 2003
http://support.microsoft.com/default.aspx?scid=kb;EN-US;3230761

Plus de détails sur le format SDDL Dans l'article MSDN
Security Descriptor String Format
http://msdn2.microsoft.com/en-us/library/aa379570.aspx

Le rédémarrage d'un contrôleur de domaine Windows peut nécessiter une très longue durée. Cela peut prendre jusqu'à plus d'une demi-heure.

L’initialisation du moteur de l’Active Directory lors du redémarrage sur un contrôleur de domaine détenant un rôle FSMO nécessite qu’une réplication initiale (en vue de réduire les risques de doublons au niveau des rôles FSMO). Une foi cette opération réalisée avec succès, l’AD se considère complètement initialisée.
Pour plus d’information, voir l'article technique
305476 :Initial synchronization requirements for Windows 2000 Server and Windows Server 2003 operations master role holders
http://support.microsoft.com/default.aspx?scid=kb;EN-US;305476.

La cause précise du délai constaté est liée à l'imbrication de l'Active Directory et du DNS. Pour contacter un partenaire de réplication, le contrôleur de domaine a besoin de le localiser. Son nom est obtenu à partir de la topologie de réplication, la demande de résolution du nom en adresse IP est faite via une requête DNS. Le DNS n'étant pas en mesure de charger les enregistrements des zones qu'il détient, du fait de l'Active Directory en cours d'initialisation, le client DNS n'obtient pas de réponse. La réplication initiale ne peut avoir lieue, et le serveur se retrouve bloqué jusqu'à l'expiration de tous les timeout.

Deux solutions sont possibles pour prévenir cette situation

• Sur les serveur détenant des rôles FSMO, configurez le client DNS pour ne pas envoyer les requêtes à soi même, mais uniquement à un autre contrôleur du domaine
• Mettre en place la valeur de registre Repl Perform Initial Synchronizations de type REG_DWORD sous HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters et la mettre à 0
  Cette deuxième solution désactive la nécessité de la réplication initiale pour l'initialisation complète de l'Active Directory.

Un autre article blog parle de ce mécanisme :
Adroitly Sidestepping Initial Synchronization Requirements
http://blogs.technet.com/ad/archive/2007/04/29/adroitly-sidestepping-initial-synchronization-requirements.aspx

Cyrille de Pardieu

Lsass est le module qui traite toute la sécurité de Windows. Entre autre les demandes d'authentification, la gestion de l'Active Directory, de la réplication, etc.

Lsass.exe est souvent la "victime" d'un autre processus générant un très grand nombre de requêtes LSA. Cela peut être des demandes d'authentification, des recherches de site, de serveur, l'évaluation des groupes d'un utilisateur, la traduction de nom d'utilisateur (vers un SID par exemple), ...

La première étape consiste à vérifier si l'activité Lsass est causée par des sollicitations réseau ou si elles sont causées par une activité interne. Pour cela, le test consiste à débrancher le câble réseau ou à désactiver la carte réseau (attention aux logiciels de prises de main à distance) pendant une dizaine de seconde. Si l'activité baisse à partir de ce moment-là, il faut se concentrer sur les requêtes réseau. Autrement, il faut se concentrer sur l'activité locale.

Origine réseau

Une trace réseau pendant une durée significative (une à cinq minutes) permettra d'obtenir une idée précise des requêtes adressées au contrôleur de domaine. Il faut ensuite analyser la trace pour identifier quel type de trafic est le plus important, s'il provient d'une machine identifiée ou de tout type d'ordinateur. Des exemples de 100% CPU causé par le réseau sont des demandes d'énumération des groupes par un applicatif, des accès massif à un partage, des requêtes LDAP très complexe ne pouvant tirer parti des index en place (en particulier avec des filtres contenant des chaînes partielles en utilisant des wildcards).

Il convient alors de vérifier en fonction du type de trafic et de son origine quel composant ou application en est à l'origine et déterminer s'il est normal ou pas.

Origine locale

Plusieurs actions complémentaires sont possibles : suivre les performances des modules exploitant lsass.exe (annuaire ldap, authentification, réplication, …) et capturer l'image de l'exécution du processus lsass.exe,

Performance

Pour cela, lancez le moniteur de performance avec les compteurs suivants :

• L’objet thread avec les compteurs  % Temps processeur  et ajouter toutes les instances LSASS et ID Thread.
• L’objet Process avec le compteur lsass avec toutes les instances LSASS
• L’objet Processeur avec le compteur % Temps processeur et %Temps Utilisateur avec l’option toutes les instances sélectionné
• L’objet NTDS avec les compteurs : DRA Inbound Bytes Total/sec, DRA Inbound Object Updates Remaining in Packet, DRA Outbound Bytes Total/sec, DRA Pending Replication Synchronizations, Kerberos Authentications/sec, NTLM Authentications, LDAP Bind Time, LDAP Successful Binds/sec, LDAP Client Sessions, LDAP Searches/sec

Pour votre information voici quelques détails sur les compteurs NTDS :

• DRA Inbound Bytes Total/sec : Nombre d'octets reçus par secondes résultants de réplications entrantes (somme des données compressées et non compressées).
• DRA Inbound Object Updates Remaining in Packet : Nombre d'octets reçus de réplications entrantes qui n'ont pas été enregistrés dans la base. Indique que le serveur reçoit des réplications entrantes mais est trop chargé pour les appliquer rapidement.
• DRA Outbound Bytes Total/sec : Nombre d'octets émis par secondes résultants de réplications sortantes (somme des données compressées et non compressées).
• DRA Pending Replication Synchronizations : Nombre de réplications mises en queue en attente d'être effectuées (réplication backuplog). Revient à ce qui est affiché par repadmin/queue.
• Kerberos Authentications/sec : Nombre d'authentifications par secondes par dessus Kerberos effectuées par secondes.
• NTLM Authentications : Nombre d'authentifications par secondes par dessus NTLM effectuées par secondes.
• LDAP Bind Time : Temps en millisecondes nécessaire pour effectuer un bind à l'AD.
• LDAP Successful Binds/sec : Nombre de binds LDAP par seconde gérés par le serveur.
• LDAP Client Sessions : Nombre de sessions LDAP courantes gérées par le serveur.
• LDAP Searches/sec : Nombre de recherches LDAP effectuées par secondes

Vous pouvez également utiliser le "Performance Monitor Wizard" disponible sur le site web Microsoft. Il permet de configurer l'analyseur de performance facilement. (http://www.microsoft.com/downloads/details.aspx?FamilyID=31FCCD98-C3A1-4644-9622-FAA046D69214&displaylang=en)

Image du processus

Pour cela, il faut installer les Debugging Tools for Windows disponibles sur le site web Microsoft à l'adresse
http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx

Ensuite, via le script AdPlus.vbs (installé par défaut dans \Program Files\Dubugging tools for Windows), générez plusieurs dump du processus lsass à l'aide de la commande
   cscript adplus.vbs -hang -pn lsass.exe -r <nombre de snapshot> <intervalle en secondes>
L'idéal étant d'avoir au moins 3 dumps à 1mn d'écart.

Exemple
   Cscript adplus.vbs -hang -pn lsass.exe -r 3 30

Un dossier sera alors créé :
   Hang_Mode__Date_01-16-2009__Time_15-36-2525
avec, entre autre le fichier
   PID-436__LSASS.EXE__full_0650_2009-01-16_15-47-12-110_01b4.dmp

L'analyse de ces dumps est assez complexe, mais une première vérification peut être faite.

Avec WinDBg, ouvrez le fichier PID-436__LSASS.EXE__full_0650_2009-01-16_15-47-12-110_01b4.dmp (File, Open Crash Dump...). Il faut ensuite configurer les symboles pour pouvoir interpréter son contenu. Cela se fait via la commande
   .sympath srv*c:\symbols*http://msdl.microsoft.com/download/symbols
le dossier c:\symbols sera utilisé pour mettre en cache les fichiers téléchargés.

Exécutez ensuite la commande !runaway. Cela vous affiche, par ordre croissant de temps d 'activité chacun des thread de lsass.exe

Exemple :
   0:000> !runaway
   User Mode Time
   Thread Time
   40:40c 0 days 0:00:00.110
   35:2fc 0 days 0:00:00.090
   32:2d8 0 days 0:00:00.080
   49:608 0 days 0:00:00.070
   51:658 0 days 0:00:00.060
   30:2cc 0 days 0:00:00.060

Identifiez le ou les threads les plus consommateurs et, pour chacun, exécuter la commande.
   ~<thread>k

Vous aurez ainsi la pile d'appel de fonction et donc le ou les modules en cours d'exécution. Ainsi que les éventuels modules tierces chargés.

Ces manipulations permettent une première analyse et l'identification de suspect. Pour une analyse plus avancée, il sera nécessaire d'ouvrir un incident auprès de votre support Windows.

Cyrille de Pardieu