|
|
Ce blog rassemble des articles rédigés par les équipes CSS (Customer Support Services) et MCS (Consulting) ayant trait à l'Active Directory et à la Sécurité.
-
Il est nécessaire d’avoir les privilèges administrateurs du serveur pour suivre la procédure suivante. 1. Dans un command prompt, saisir la commande suivante : netsh interface ipv4 show interfaces 
Repérer le numéro dans la colonne “Idx” correspondant à votre carte réseau.
Si votre serveur contient plus d’une carte, noter le numéro de celle à qui sera définie une adresse IP statique. 2. Dans un command prompt, saisir : netsh interface ipv4 set address name="<ID>" source=static address=<StaticIP> mask=<SubnetMask> gateway=<DefaultGateway> 
Où :
ID est le numéro relevé dans le point 1,
StaticIP est l’adresse IP statique que vous souhaitez définir,
SubnetMask est le masque de sous-réseau pour cette adresse IP,
DefaultGateway est votre passerelle par défaut. 3. Dans un command prompt, saisir : netsh interface ipv4 add dnsserver name="<ID>" address=<DNSIP> index=1 
Où:
ID est le numéro relevé dans le point 1,
DNSIP est l’adresse IP de votre serveur DNS,
Répéter cette action pour chaque serveur DNS que vous souhaitez paramétrer en incrémentant la valeur « index= x+1 ». 4. Vérifier que la configuration a correctement été appliquée avec la commande:
ipconfig /all 5. Pour changer le nom de votre serveur Déterminer le nom actuel de votre serveur avec la commande ipconfig /all 
Dans un command prompt, saisir : netdom renamecomputer <ComputerName> /NewName:<NewComputerName> 
Redémarrer le serveur, dans un command prompt, saisir :
shutdown /r /t 0 
6. Manager le serveur Core en utilisant « Windows Remote Shell » Pour activer “Windows Remote Shell” sur le Serveur Core,
Saisir la commande suivante dans un command prompt: WinRM quickconfig Saisir “Y” à chaque questions pour accepter les paramètres par défaut.
Puis sur le serveur distant : Utiliser WinRS.exe afin d’exécuter les commandes à distance sur le serveur Core :
par exemple sur un autre serveur, saisir la commande suivante :
winrs -r:<ServerNameCore> cmd 
Toutes les commandes saisies sont exécutées sur le serveur Core. 7. Pour joindre le serveur au domaine Dans un command prompt, saisir : netdom join <ComputerName> /domain:<DomainName> /userd:<UserName> /passwordd:* 
Où:
ComputerName est le nom du serveur Core,
DomainName est le nom du domaine à joindre,
UserName est le compte ayant les permissions d’ajout au domaine. Redémarrer le serveur, dans un command prompt, saisir :
shutdown /r /t 0 8. Lancement des services : Dans un command prompt, saisir : start /w ocsetup DFSN-Server 
start /w ocsetup DFSR-Infrastructure-ServerEdition 
Note : Il n’y a pas de message indiquant que l’opération s’est correctement déroulée. Vous pouvez confirmer que les services sont bien démarrés : 
Vous pouvez désormais ajouter ce serveur à un Réplica via la console DFS « DFSMGMT.MSC » sur un serveur complet. Joseph Besançon
|
-
La virtualisation étant de plus en plus répandue et simple à mettre en place, il est important de valider et respecter certains pré-requis pour éviter de mettre en production un DC potentiellement dangereux pour votre environnement. Le but de cet article est de partager des règles de base à respecter lors de la mise en place d’un DC dans un environnement virtuel. 1- Support de l’environnement de virtualisation Microsoft met gratuitement en ligne un petit assistant permettant de vérifier la supportabilité des différents environnements virtuels en 3 étapes: http://www.windowsservercatalog.com/svvp.aspx?svvppage=svvpwizard.htm Par exemple : Est-ce que mon DC virtuel Windows Server 2000 SP4 est supporté sur Hyper-V ? Etape 1 : Le choix du produit Dans la liste des produits disponibles, on ne retrouve pas « active directory » puisque c’est un « rôle » que l’os peut posséder au même titre que les services DNS, DHCP, etc. Je choisi donc Windows 2000 version SP4. 
Etape 2 : Le choix du « Host » et du « guest » Dans cette étape, nous devons choisir la technologie de virtualisation communément appelé le « host » et la version d’OS du client communément appelé le « guest ». Pour notre exemple, je choisie donc un « host » de type hyper-V et un « guest » Windows 2000 SP4 x86. 
Etape 3 : Le résultat Dans la partie « Summary Support Statement » vous trouverez le résultat de votre requête : Pour notre exemple de DC Windows 2000 sous hyper-v, notre configuration est bel et bien supportée. 
2- Les recommandations Les contrôleurs de domaines font parti des serveurs critiques d’un environnement de production. Pour éviter des heures de dépannage inutiles sur des problèmes pouvant allez jusqu’à une corruption d’une forêt entière, il est fortement recommandé de respecter certains points. Prévoir de garder quelques contrôleurs de domaine physiques - Il est recommandé, dans la mesure du possible, de garder 1 ou 2 DC physique, pour éviter qu’un souci qui toucherait le logiciel de virtualisation, rendre indisponible un domaine voir une forêt entière. Attention à la sécurité du host - Les comptes ayant les droits d’administration locale d'un serveur qui héberge les DCs virtuels, doivent avoir la même politique de sécurité que les comptes administrateur de domaine/forêt. - Les fichiers VHD sont équivalents aux disques physiques d’un serveur. Il est donc important que seul les gens habilités ait accès aux fichiers. Service de temps - Pour tous les DCs virtuels sans exception, il faut désactiver la synchronisation de temps avec le host dans les options d’intégrations. Ce paramètre entre en conflit avec le mécanisme de synchronisation de temps de la forêt : W32Time. Des arrêts de production majeurs ont déjà été répertoriés au support suite à une simple maintenance hardware de la machine host provoquant un retour arrière de plus d’un an de la date du bios et donc de tous les DCs hébergé sur celle-ci… Sauvegarde - Les sauvegarde et restauration de domaine contrôleurs virtuels doivent être réalisés à l’identique des serveurs physiques : « système » + « système state ». Les backups/restaures de VHD sont totalement proscrits et non supporté aux même titre que les snapshots, les disques diférentiels ou autre logiciel de type Norton Ghost. Eléments à BANIR ! - Ne jamais utiliser les outils de snapshots ou de disques différentiels sur un domaine contrôleur virtuel. Un retour arrière sur un DC vous générera au minimum un problème d’USN rollback ! - Ne jamais cloner une machine virtuelle sans avoir effectué au préalable un sysprep. Une duplication sans sysprep n’est d’ailleurs pas supportée ref: http://support.microsoft.com/kb/162001. Il ne faut pas cloner un contrôleur de domaine, seules les machines en workgroup peuvent être clonées. - Il n’est pas supporté d’utiliser la fonctionnalité Hyper-V « export » pour exporter une machine virtuelle de type domaine contrôleur. Vous pouvez retrouver les explications détaillées de ces différentes recommandations dans les articles suivants : Running Domain Controllers in Hyper-V
http://technet.microsoft.com/en-us/library/dd363553(WS.10).aspx Considerations when hosting Active Directory domain controller in virtual hosting environments
http://support.microsoft.com/kb/888794 Pour terminer, vous pouvez consulter le site TechNet « Virtualization TechCenter » entièrement dédié à la virtualisation : http://technet.microsoft.com/en-us/virtualization/default.aspx Marc Bouchard
|
-
Si vous avez des applications qui ont été développées avant Windows 2008, et que vous avez récemment intégré des RODC (read only DC), assurez-vous que ces applications sont compatibles avec les RODC.
De même, si vous avez des clients XP et 2003 se trouvant dans un site ayant des RODC, n'oubliez pas d'installer le pack de compatibilité ci-dessous.
Description of the Windows Server 2008 read-only domain controller compatibility pack for Windows Server 2003 clients and for Windows XP clients
http://support.microsoft.com/kb/944043/en-us
Afin de diagnostiquer de potentiels problèmes avec les RODC, vous pouvez activer une trace réseau. Dans les trames réseaux capturées, au niveau de la section "Flags", regardez si l'option DSWritableFlag n'est pas positionnée à 0x1.
Si DSWritableFlag = 0x1, ceci signifie que le DC en question n'est pas un DC en lecture/écriture que le client recherche.
L'option DSWritableFlag signifie "DC does not have a writable DS.". Donc si cette option est positionnée à 0x1, cela signifie que le client rencontre un RODC alors qu'il est à la recherche d'un DC en lecture/écriture.
HDL.
|
-
Jusqu'à Windows Server 2003 R2, il était possible d'avoir un cmd s'exécutant dans le contexte système. Cela permettait, entre autre, de tester le contexte système (pour des accès à des partages par exemple) et d'afficher les tickets Kerberos attribué à la machine. Pour cela, il fallait - Ouvrir une session localement sur le serveur ou se connecter à la session console en bureau à distance (mstsc /console)
- Planifier une tâche interactive démarrant cmd.exe
at HH:MM /interactive cmd.exe A l'heure indiquée un nouveau command prompt apparait, il s'exécute dans le contexte système. 
Depuis Windows Vista et Windows Serveur 2008, ce mécanisme ne fonctionne plus. Les tâches planifiées via AT ne peuvent plus être interactives. 
Pour obtenir un command prompt dans le contexte système sur ces plateformes, plusieurs autres solutions existent. PsExec 
Remote.exe Remote.exe fait parti des Debugging Tools disponibles sur le site web Microsoft à l'adresse
http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx - Copier remote.exe sur la machine dans le dossier c:\Debuggers (par exemple)
- Démarrez un command prompt avec tous les privilèges (Exécuter en tant qu'administrateur)
- Exécutez la commande
AT HH:MM c:\Debuggers\remote.exe /s c:\windows\system32\cmd.exe SYSCMD - Une fois l'heure spécifiée passée, exécutez la commande
c:\debuggers\remote.exe /c <ComputerName> SYSCMD La commande cmd.exe affichera alors ****************************************
*********** REMOTE *************
*********** CLIENT *************
****************************************
Connected...
c:\windows\system32
** Remote: Connected to %computername% 
Mots clés Technorati : contexte système, vistaCyrille de Pardieu
|
-
Ou comment lancer Windows Explorer en tant qu'administrateur
Ce cas de figure peut se présenter quand un administrateur se connecte sur un serveur où l'UAC est actif et souhaite, pour créer des fichiers dans les dossiers protégés de Windows par exemple, exécuter une instance de l'explorateur avec un contexte administrateur. Sans la case "launch folder windows in a separate process" cochée dans les propriétés des dossiers Sans fenêtre d'explorateur ouverte, on trouve un processus explorer.exe (PID 1656) qui tourne sans privilège, c'est le shell de l'utilisateur, son bureau. On lance un explorateur, sans demander l'élévation de privilège, aucun nouveau processus n'est créé et, logiquement, les actions d'administration ne sont pas possibles. On lance un explorateur, en demandant l'élévation de privilège, aucun nouveau processus n'est créé non plus et, logiquement, les actions d'administration ne sont pas possibles. Avec la case "launch folder windows in a separate process" cochée Sans fenêtre d'explorateur ouverte, on trouve un processus explorer (PID 216) qui tourne sans privilège, c'est le shell de l'utilisateur, son bureau. On lance un explorateur, sans demander l'élévation de privilège, un nouveau processus est créé (PID 2432, fils de 216) et, logiquement, les actions d'administration ne sont pas possibles On le ferme et lance un explorateur, en demandant l'élévation de privilège, un nouveau processus est créé (PID 2804, pas de processus père) et, logiquement, les actions d'administration sont possibles On le ferme On lance un explorateur, sans demander l'élévation de privilège (PID 3004, fils de 216, pas d'action d'administration possible) puis on lance un second explorateur, en demandant l'élévation de privilège. Aucun processus n'est créé pour ce deuxième explorateur et aucune action d'administration n'est possible. On ferme des ceux explorateurs et effectue l'opération inverse : On lance un premier explorateur avec élévation de privilège (PID 1100, pas de parent, actions d'administrations possibles) puis un second explorateur sans demander l'élévation de privilège. Aucun nouveau processus n'est créé pour ce deuxième explorateur et les deux permettent de réaliser des actions d'administration. Plusieurs solutions de contournement existent - Forcer par GPO (Group Policy Prefernce ou un adm personnalisé), l'activation de " launch folder windows in a separate process"
- Utiliser Internet explorer comme explorateur.
- Démarrer Notepad.exe en tant qu'administrateur et sauvegarder le fichier directement dans le dossier souhaité.
Tout est très bien documenté dans le blog de Aaron Margosis (très bonne source d'information sur sur UAC) : Aaron Margosis' "Non-Admin" WebLog - RunAs with Explorer
http://blogs.msdn.com/aaron_margosis/archive/2004/07/07/175488.aspx Mots clés Technorati : UAC, Vista, sécurité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 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 Mots clés Technorati : 100% CPU, Lsass
|
-
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 Mots clés Technorati : réplication, FSMO
|
-
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
|
-
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 Mots clés Technorati : adsi, ldap, referral, RODC
|
-
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 Service
Niveau : erreur
Evénement : 1500
Description : 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\WMI
default file name is LoggerName.etl
ex. 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.exe
On 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 = 5
Error 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.exe
L'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 = 80070906
80070906 => 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 = 80070005
80070005 = 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. Huu-Duc Le
|
-
Pourquoi un environnement d’intégration ? 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. Comment construire son environnement d’intégration ? 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) Recommandations générales 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. Construction d’une nouvelle forêt 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. Duplication de la forêt existante 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. Utilisation d’une sauvegarde 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. ![clip_image001[4]](http://blogs.technet.com/blogfiles/domaineetsecurite/WindowsLiveWriter/MiseenplacedunenvironnementdintgrationAc_CBDA/clip_image001%5B4%5D_thumb.jpg)
Ajout puis isolation d'un contrôleur de domaine 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é. Nettoyage du domaine de production 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 à - · Supprimer l’objet NTDS Settings dans la partition configuration référençant le serveur isolé
- · Supprimer l’objet server dans la partition configuration référençant le serveur isolé
- · Supprimer l’objet computer dans la partition domaine référençant le serveur isolé
- · Supprimer les enregistrements DNS et WINS correspondant à ce serveur
Configuration de l’AD isolée 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 document
Best 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 publie
netdom 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 domaine
Dans 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 fois
Sur le domaine parent
netdom trust <domaine parent> /domain:<domaine enfant> /resetOneSide /passwordT:example
/userO:administrator /passwordO:*
Sur le domaine enfant
netdom 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. Liens utiles Active Directory Migration Tool v3
ADMT v3 Migration Guide
Download Active Directory Migration Tool v3.0 Active Directory Migration Tool v3.1
Migrating and Restructuring Active Directory Domains Using ADMT v3.1
Download Active Directory Migration Tool version 3.1 Group Policy Management Console
Enterprise Management with the Group Policy Management Console
Download 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.
|
|
|
|
