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:
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é:
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:
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 technique323076 - How to set event log security locally or by using Group Policy in Windows Server 2003http://support.microsoft.com/default.aspx?scid=kb;EN-US;3230761
Plus de détails sur le format SDDL Dans l'article MSDNSecurity Descriptor String Format http://msdn2.microsoft.com/en-us/library/aa379570.aspx
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
Si lors du chargement d'un profil errant de Vista SP1 et si vous ne pouvez pas nous logguer
Lorsque le problème de chargement de profil arrive, on a l'erreur suivante dans le journal d'evenements :
>>>Source : User Profile ServiceNiveau : erreurEvénement : 1500Description : Windows ne peut pas vous ouvrir une session car votre profil ne peut pas etre charge.Verifiez que vous etes connecte au reseau et que le reseau fonctionne correctement. DETAIL - Acces refuse.
. Afin de pouvoir se logguer de nouveau avec le profil corrompu, vérifiez le contenu du profilelist dans les registres avec l'article suivant : Error message when you log on to a Windows Vista-based computer by using a temporary profile: "The User Profile Service failed the logon. User profile cannot be loaded"http://support.microsoft.com/kb/947215/en-us
. Si on utilise l'outil TRACLOG fourni dans http://www.microsoft.com/whdc/DevTools/WDK/WDKpkg.mspx
tracelog -addautologger profile -guid #eb7428f5-ab1f-4322-a4cc-1f1a9b2c5e98 -level 3 -flag 255 -sessionguid #eb7428f5-ab1f-4322-a4cc-1f1a9b2c5e98
default file location is C:\Windows\system32\Logfiles\WMIdefault file name is LoggerName.etlex. profile.etl
. L'analyse du fichier .etl permet de voir les details suivants :
[0]02A4.02A8::09/11/2008-09:29:51.989 [userenv]Leave LoadUserProfile()...............................[0]02A4.02A8::09/11/2008-09:29:51.990 [userenv]Entering CreateEnvironmentBlock ...>>> [0]02A4.02A8::09/11/2008-09:29:51.991 [userenv]Service account. No DNS domain name available.Problème d'accès au DNS, de résolution de nom.[0]02A4.02A8::09/11/2008-09:29:51.991 [userenv]Got AppData path C:\Windows\ServiceProfiles\LocalService\AppData\Roaming!...[0]02A4.02A8::09/11/2008-09:30:09.019 [userenv]returning dwErr = 0[0]02A4.02A8::09/11/2008-09:30:09.019 [userenv]Leave LoadUserProfile()..................................[0]02A4.02A8::09/11/2008-09:30:09.019 [userenv]Entering CreateEnvironmentBlock ...[0]02A4.02A8::09/11/2008-09:30:09.020 [userenv]Service account. No DNS domain name available.Problème d'accès au DNS, de résolution de nom.[0]02A4.02A8::09/11/2008-09:30:09.020 [userenv]Got AppData path C:\Windows\ServiceProfiles\LocalService\AppData\Roaming![0]0884.08B8::09/11/2008-09:30:09.166 [userenv]LibMain: Process Name: C:\Windows\system32\svchost.exe>>> [0]08BC.08C0::09/11/2008-09:30:09.423 [userenv]LibMain: Process Name: C:\Program Files\...\Rtvscan.exeOn voit que l'antivirus est actif durant le chargement du profil[0]02A4.02A8::09/11/2008-09:30:09.478 [userenv]Entering CreateEnvironmentBlock ...[0]02A4.02A8::09/11/2008-09:30:09.479 [userenv]Service account. No DNS domain name available.Problème d'accès au DNS, de résolution de nom.[0]02A4.01D4::09/11/2008-09:30:11.326 [userenv]Service account. No DNS domain name available.[0]02A4.01D4::09/11/2008-09:30:11.327 [userenv]Got AppData path C:\Windows\system32\config\systemprofile\AppData\Roaming!...[0]02A4.01D4::09/11/2008-09:30:11.327 [userenv]Got Local AppData path C:\Windows\system32\config\systemprofile\AppData\Local![0]0A80.0A84::09/11/2008-09:30:11.527 [userenv]LibMain: Process Name: C:\PROGRA~1\...\LIVEUP~1\LUCOMS~1.EXE[0]0A40.0A44::09/11/2008-09:30:11.772 [userenv]LibMain: Process Name: C:\Windows\system32\rundll32.exe[0]064C.06CC::09/11/2008-09:30:11.820 [userenv]Entering CreateEnvironmentBlock ...>>> [0]064C.06CC::09/11/2008-09:30:11.821 [proflib]Failed to impersonate user, error = 5Error 5 => Access Denied[0]064C.06CC::09/11/2008-09:30:11.821 [userenv]Got AppData path C:\Windows\system32\config\systemprofile\AppData\Roaming![0]064C.06CC::09/11/2008-09:30:11.821 [userenv]Got Local AppData path C:\Windows\system32\config\systemprofile\AppData\Local![0]0B70.0B74::09/11/2008-09:30:22.308 [userenv]LibMain: Process Name: C:\Program Files\...\SescLU.exeL'antivirus est actif.[0]02A4.01D4::09/11/2008-09:30:22.565 [userenv]Entering CreateEnvironmentBlock...[0]0520.0570::09/11/2008-09:31:26.896 [profsvc]Got profile server name XXX[0]0520.0570::09/11/2008-09:31:26.900 [profsvc]IP Address = 163.110.208.153[0]0520.0570::09/11/2008-09:31:26.900 [profsvc]IP Address = 163.110.208.151[0]0520.0570::09/11/2008-09:31:26.900 [userenv]PingComputer: PingBufferSize set as 2048[0]0520.0570::09/11/2008-09:31:26.905 [userenv]PingComputer: Adapter speed 1073741824 bps[0]0520.0570::09/11/2008-09:31:26.910 [userenv]PingComputer: First time: 2[0]0520.0570::09/11/2008-09:31:26.910 [userenv]PingComputer: Fast link. Exiting.[0]0520.0570::09/11/2008-09:31:26.910 [profsvc]MinRate = 500, ActualRate = 1048576, SLOWLINK = FALSE>>>[0]0520.0570::09/11/2008-09:31:27.005 [profsvc]NetShareGetInfo, (szServer, szShare, 1005 failed, hr = 8007090680070906 => NERR_NetNameNotFound[0]0520.0570::09/11/2008-09:31:27.006 [profsvc]Got CSC bypassed path <\\XXX$ZZZ$\PHD\Profiles\3001.V2>[0]0520.0570::09/11/2008-09:31:27.252 [userenv]Checking ownership for \\XXX$ZZZ$\PHD\Profiles\3001.V2[0]0520.0570::09/11/2008-09:31:27.281 [userenv]Owner is the right user[0]0520.0570::09/11/2008-09:31:27.297 [profsvc]Found an user profile <\\XXX$ZZZ$\PHD\Profiles\3001.V2\ntuser.dat>[0]0520.0570::09/11/2008-09:31:27.297 [profsvc]Checking Local Profile ...>>> [0]0520.0570::09/11/2008-09:31:28.239 [profsvc]RegRenameKey failed, hr = 8007000580070005 = E_ACCESSDENIED[0]0520.0570::09/11/2008-09:31:28.239 [profsvc]RestoreKeyFromBackup failed, hr = 80070005[0]0520.0570::09/11/2008-09:31:28.239 [profsvc]CheckProfileListKey failed, hr = 80070005[0]0520.0570::09/11/2008-09:31:28.239 [profsvc]CheckLocalProfile failed, hr = 80070005[0]0520.0570::09/11/2008-09:31:28.239 [profsvc]Issue Temporary Profile ...[0]0520.0570::09/11/2008-09:31:28.239 [profsvc]RegRenameKey failed, hr = 80070005[0]0520.0570::09/11/2008-09:31:28.239 [profsvc]BackupProfileListEntry failed, hr = 80070005[0]0520.0570::09/11/2008-09:31:28.239 [profsvc]IssueTempProfile failed, hr = 80070005[0]0520.0570::09/11/2008-09:31:28.239 [profsvc]Leaving RestoreUserProfile() with hr = 80070005[0]0520.0570::09/11/2008-09:31:28.239 [profsvc]RestoreUserProfile failed, hr = 80070005>>[0]0520.0570::09/11/2008-09:31:28.239 [profsvc]LeaveLock <S-1-5-21-3558753324-2695999026-1591784692-1265>[0]0520.0570::09/11/2008-09:31:28.243 [profsvc]Logging Event < Windows ne peut pas vous ouvrir une session car votre profil ne peut pas être chargé. Vérifiez que vous êtes connecté au réseau et que le réseau fonctionne correctement. DÉTAIL - Acces refuse >>>[0]0520.0570::09/11/2008-09:31:28.244 [profsvc]pUserProfile->Load failed, hr = 80070005[0]0520.0570::09/11/2008-09:31:28.244 [profsvc]Returning hr = 80070005[0]0520.0570::09/11/2008-09:31:28.244 [profsvc]Exit Logon Thread.....................................
[0]0520.05D0::09/11/2008-09:31:28.244 [profsvc]Worker thread done, hr = 80070005[0]0520.05D0::09/11/2008-09:31:28.244 [profsvc]Returning winlogon 500[0]0520.05D0::09/11/2008-09:31:32.408 [profsvc]Enter OnLogOff for session 1[0]0520.05D0::09/11/2008-09:31:32.408 [profsvc]New session, spawn new worker thread![0]0520.05D0::09/11/2008-09:31:32.408 [profsvc]Creating entry for session 1[0]0520.05D0::09/11/2008-09:31:32.408 [profsvc]Waiting for the request event ...
Le problème pourrait provenir de full scan de l'antivirus durant le processus de login et de chargement du profil itinérant. Pour éviter cela, désactiver le full scan de l'antivirus durant la phase de login.
L'utilisation d'un environnement d'intégration est intéressant, voir indispensable pour de nombreuses opérations impliquant des modifications importantes de l'environnement Active Directory.
Certains de ces changements nécessitent d'être testés avant d'être déployés. Je pense, entre autre, à la mise en place de stratégie de groupe modifiant la sécurité (modification des stratégies de mot de passe, activation du SMB Signing,...) ou le réseau (mise en place d'IPSec, configuration de ports statique pour la réplication, ...)
D'autres modifications impactant directement l'Active Directory doivent être faite avec précaution en raison des risques qu'elles comportent. En particulier les extensions de schéma qui, si elles se déroulent mal, imposent la reconstruction de la forêt.
L'utilisation d'un environnement d'intégration permet plusieurs choses. Elle garantie l'absence d'impact sur l'environnement de production, donc d'indisponibilité. De plus, étant donné qu'il n'y a pas d'impératif de reprise d'activité, cela laisse le temps de mener les investigations pour déterminer l'origine exacte du problème et donc de le résoudre.
Il y a deux méthodes permettant de construire un environnement d'intégration. Elles ont chacune leurs avantages et leurs inconvénients.
La première consiste à construire une nouvelle forêt avec le même contenu, la seconde à dupliquer la forêt existante. Bien entendue chacune de ces solutions peuvent exploiter la virtualisation de serveurs. Il faut cependant garder à l'esprit les recommandations concernant la virtualisation de contrôleurs de domaine.(Voir l'article technique 888794 - Considerations when hosting Active Directory domain controller in virtual hosting environments)
En raison de la présence de doublons de noms Netbios (sur le nom de domaine, et éventuellement sur des noms de serveurs et/ou de station), il est recommandé d'utiliser deux réseaux différents pour isoler les deux environnements.
L'autre point, valable pour les deux solutions, est la pérennité de cet environnement. A moyen-long terme, il va forcément diverger de l'environnement de production. Il sera nécessaire, avant des tests d'opération sensible, de reconstruire l'environnement pour s'assurer qu'il est aussi proche que possible de la production.
Pour éviter au maximum tout risque de confusion, il est intéressant de créer la forêt et les domaines avec une arborescence de nommage différent (nom DNS et Netbios). Cela permet de dissocier clairement les deux environnements et si les deux environnements venaient à être connectés, cela éviterait les problèmes de doublons de nom netbios. Cet environnement doit être créé par la même méthode que celui de production. Cela signifie même chemin d’installation (upgrade de 2000 à 2003 par exemple), et même ordre d’extension du schéma (pour reprendre les dépendances ou conflits d'attributs et de classes).
Une fois la structure de domaine créé, il faut importer les données. Les utilisateurs, ordinateurs, et groupes par un outil de migration (ADMT par exemple). Les GPOs peuvent être importées à l'aide de GPMC (via l'interface ou les scripts). La structure des OUs peut être reconstruite via export puis import par ldifde.exe.
Cette solution ne présente aucun risque pour l’environnement de production étant donné qu'il s'agit de domaines distincts. Il ne présente pas de risque de confusion (grace aux noms de domaines et de serveurs distincts). Il nécessite par contre un travail important pour sa mise en place : il faut rejouer l’évolution du domaine puis importer les données depuis l’autre environnement.
Cet environnement ne reflète donc pas exactement l'environnement de production.
Cette solution assure d’avoir une image à l’identique, mais le problème de divergence à partir de ce point existe toujours. Elle nécessite également aussi un travail de mise en place. Mais surtout, il existe un risque d’impact important voire critique sur l’environnement de production en raison de risque de réplication entre ces deux contextes en premier temps, et ensuite à cause des doublons de noms.
Pour construire un nouvel environnement à partir des données du domaine de production,
deux cas sont à envisager : l'utilisation d’un backup si un matériel identique existe, ou l'ajout puis l'isolation d’un DC. Dans les deux cas, il faut faire cette opération pour chacun des domaines de la forêt. Ces deux méthodes peuvent On peut mixer les deux méthodes. Dans ce cas, il faut commencer par ajouter les DCs et attendre la réplication de ces informations avant de faire les sauvegardes.
Les étapes sont les suivantes. Il faut d'abord identifier une machine ayant le même hardware qu’un serveur de la production, ce serveur original doit également être serveur DNS, par contre, il est conseillé qu’il ne soit pas Catalog Global. Sur le serveur cible, installer le même système d'exploitation avec la même langue et le même niveau de service pack. Le laisser en groupe de travail et l’isoler du réseau de production.
Sur le serveur de production, faire une sauvegarde, au minimum de l'état du système. Ensuite restaurer cette image sur le nouveau serveur ne prenant soin de marquer le sysvol autoritaire, comme présenté dans la capture ci-dessous. Enfin, redémarrer le serveur.
Il faut promouvoir une nouvelle machine en tant que contrôleur de domaine supplémentaire dans le domaine existant, ce nouveau DC peut être physique ou virtuel. Il faut ensuite y installer le service DNS afin qu'il récupère les partitions applicatives ForestDnsZones et DomainDnsZones.
Une fois la réplication terminée (et AD et DNS et Sysvol), le serveur doit être isolé (changement de réseau). Il faut ensuite purger le domaine des informations concernant ce serveur retiré.
Cette opération n’est à faire que si le serveur a été créé par promotion, la méthode sauvegarde puis restauration ne créant pas de serveur mais en clonant un ne nécessite pas de nettoyer l'environnement de production.
Pour cela, il suffit de suivre les informations de l’article suivant pour supprimer toute référence au serveur isolé sur le domaine de production.216498 - How to remove data in Active Directory after an unsuccessful domain controller demotion
Succinctement, cette opération consiste à
A ce stade, on doit avoir dans un réseau isolé un DC de chacun des domaines, ce serveur doit également être serveur DNS. Le domaine de production ne doit avoir aucune information concernant les serveurs isolés. Enfin les serveurs isolés ne doivent pas être en mesure de communiquer physiquement avec le reste du domaine.
Il faut tout d'abord modifier la configuration réseau des serveurs pour être client DNS d’eux-mêmes et la configuration du service DNS pour mettre à jour les redirecteurs et les délégations. Il faudra probablement aussi vérifier la configuration WINS.
Il faut enfin, sur ces serveurs, retirer toutes les références aux autres contrôleurs des domaines qui n'ont pas été isolés. Cela correspond à, dans la partition configuration, les Objets NTDS Settings et objets Servers, et dans les partitions domaines, les objets computers
Ces opérations de nettoyage sont décrites toujours dans le même article technique. 216498 - How to remove data in Active Directory after an unsuccessful domain controller demotion
Elles doivent être faites pour tous les DCs de la forêt excepté ceux isolés. Elles vont provoquer en même temps le transfert des rôles FSMO. Il est possible de transférer le rôle à l’avance via ntdsutl / roles / seize …, comme décrit dans l'article 255504 - Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller
A l'issue, il faut redémarrer le ou les serveurs isolés, puis activer le rôle Global Catalog sur au moins un serveur. Si un ou plusieurs des serveurs étaient Global Catalog, il faudra lui retirer le rôle puis le réactiver, pour s'assurer qu'il ne contient bien que des objets également présent sur les DCs isolés. Enfin vérifier la réplication des partitions entre les contrôleurs de domaine et la configuration du domaine et du réseau
Pour prévenir toute réplication entre l’environnement de test et de production, qui aurait un impact dramatique, il faut rendre impossible les authentifications entre les deux contextes. Pour cela, il faut réinitialiser 2 fois les mots de passe des comptes utiliser pour les authentifications entres DCs (le mot de passe du compte Krbtgt, des comptes machines, et de la relation d’approbation). Le détail de ces opérations se trouve dans le documentBest Practice Recommendation for Recovering your Active Directory Forest
En bref, modifier 2 fois le mot de passe du compte machine du serveur. Ce mot de passe est utilisé pour encrypter les TGS pour les SPNs que le compte machine publienetdom resetpwd /server:<PDC> /userD:<administrator> /passwordD:*
Modifier 2 fois le mot de passe du compte KRBTGT. Ce mot de passe est utilisé pour encrypter les TGTs du domaineDans la console Active Directory Users and Computers , menu View / advanced features, clic-droit sur le compte désactivé KrbTgt dans le containeur user puis reset password.Modifier le mot de passe des relations d’approbation, Implicites et explicites. Cette opération n‘est à faire qu’une seule foisSur le domaine parentnetdom trust <domaine parent> /domain:<domaine enfant> /resetOneSide /passwordT:example/userO:administrator /passwordO:*Sur le domaine enfantnetdom trust <domaine enfant> /domain:<domaine parent> /resetOneSide /passwordT:example/userO:administrator /passwordO:*
Si de nouveaux DCs sont ajoutés, ils obtiendront les nouveaux mots de passe par réplication lors de leur promotion et pourront communiquer avec tout l'environnement isolé. Par sécurité, conservez tout de même les deux environnements isolés.
Active Directory Migration Tool v3ADMT v3 Migration GuideDownload Active Directory Migration Tool v3.0
Active Directory Migration Tool v3.1Migrating and Restructuring Active Directory Domains Using ADMT v3.1Download Active Directory Migration Tool version 3.1
Group Policy Management ConsoleEnterprise Management with the Group Policy Management ConsoleDownload the GPMC with Service Pack 1 (SP1)
237677 - Using LDIFDE to import and export directory objects to Active Directory
139822 - How to Restore a Backup to Computer with Different Hardware
216498 - How to remove data in Active Directory after an unsuccessful domain controller demotion
Best Practice Recommendation for Recovering your Active Directory Forest
325850 - How to use Netdom.exe to reset machine account passwords of a Windows Server 2003 domain controller
Running Domain Controllers in Virtual Server 2005
888794 - Considerations when hosting Active Directory domain controller in virtual hosting environments
897615 - Support policy for Microsoft software running in non-Microsoft hardware virtualization software
Cyrille de Pardieu
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.