Blog PRA Active Directory

Forest Recovery

Lors d'un désastre Active Directory nécessitant une reconstruction complète de la forêt, la première chose à réaliser est de restaurer le service au plus vite, en l'occurence le service d'authentification.

Blog PRA Active Directory

Forest Recovery

Le minimum à réaliser consiste à réinstaller un DNS sur lequel va s'appuyer l'AD, un controleur de domaine du domaine racine, un controleur de domaine de chaque domaine enfant ainsi qu'un global catalogue. A ce stade, le service minimum est restauré, les étapes suivantes consistent reconstruire un DC dans chaque site puis remonter tous les DC, et remettre en place les rôles FSMO.

Pour que le service d'authentification soit complètement opérationnel, celà nécessite également dans la majorité des cas qu'un catalogue global soit accessible (cas d'une forêt en mode natif nécessitant un GC pour résoudre l'appartenance aux groupe universels).

Forest Recovery

Cependant, savez-vous que pour promoter un GC, le rôle FSMO Schema Master doit être accessible? Celà implique donc que le DC possédant ce rôle devrait être restauré avant toute tentative de restauration de GC. Si la sauvegarde de ce DC n'est pas accessible, il est possible de forcer ce rôle sur un DDC (Seizure). Cependant la seizure de ce rôle nécessite d'être dans le groupe Schema Owner.

PRA Active Directory

Chez un de mes clients, le scénario suivant est survenu: ils avaient retiré le compte Administrator du groupe Schema Owner. Après restauration du premier DC, première surprise, l'administrateur ne peut seizer ce rôle, ni modifier le contenu de ce groupe, ni même se loguer avec un compte possédant les droits puisqu'aucun GC n'est disponible. Comment faire alors pour installer le premier GC de la forêt?

Solution

1. Se placer dans le contexte LocalSystem du DC

Sur le serveur, ou dans une console système (mstsc /console), dans une invite de commande, lancez la commande at /interactive hh:mm cmd.exe hh:mm représentant l'heure actuelle+ 2 minutes.

2. Lancez adsiedit.msc dans le contexte système.

Lorsque l'invite de commande apparait dans le contexte système, tapez adsieedit.msc puis appuyez sur Entrée.

Chargez la partition schema puis modifiez manuellement le DC possédant le rôle Schema Master (Attribut FSMORoleOwner de CN=SCHEMA,CN=Configuration,DC=...)

Forest Recovery

 

Blog PRA Active Directory

La prise en compte est dynamique.

A ce stade, vous avez seizé le rôle Schema Master sur le DC que vous avez restauré sans pour autant appartenir au groupe qui donne cette autorisation.

 Maintenant que le rôle est assigné, vous pouvez promoter un GC.

Promotion du GC

Bien que tous les domaines ne soient pas encore restaurés, il est possible de  promoter un GC "vide". Normalement il ne s'annoncera comme GC seulement lorsqu'il aura réussi à répliquer une fois la partition de chaque domaine.

Il est cependant possible de changer ces contraintes en éditant la clé de registre

HKEY_LOCAL_MACHINE \ SYSTEM \ Current Control Set \ Services \ NTDS \ Parameters \ Global Catalog Partition Occupancy. En la positionnant à zéro, vous indiquez au système qu'il peut s'annoncer en tant que GC dès que 0 partitions sont disponibles.

Promotez maintenant votre GC, il s'annonce immédiatement en tant que GC bien qu'il ne possède que la partition de votre domaine.

Vérification:

Lancez LDP, cliquez sur Connect et laissez les entrées à vide, cliquez ensuite sur Bind et laissez les entrées à vide.

Vous êtes alors connecté au DC qui vous affiche alors ses  capacités.

Regardez la valeur de 'attribut :

                1> isGlobalCatalogReady: True;

 

 

 

Votre domaine racine est maintenant opérationnel et poss_de un premier GC. Ses utilisateurs peuvent désormais s'authentifier.

Vous pouvez maitenant restaurer un DC de chaque domaine pour restaurer les domaines un par un ou utiliser vos outils ou scripts de Forest Recovery pour dérouler la suite de votre PRA (Plan de reprise d'acitvité).

Configurer l'authentification intégrée Windows dans IIS n'est pas en soi très compliqué. Les scénarios se compliquent cependant lorsqu'il s'agit de mettre en place Kerberos sur des serveurs mutualisés ou sur des fermes de serveurs Web.

Configuration IIS pour Délégation Kerberos

Délégation Kerberos

Configuration IIS

 Ce billet décrit pas à pas la configuration à mettre en place.

1. Configuration de l'identité de l'application Pool.

L’authentification Kerberos ne fonctionnera pas dans le cas d’une ferme de serveurs IIS dont les application pool s’exécuteraient sous Network Service ou Local Sytem/Service  car le SPN nécessaire à l'authentification Kerberos ne pourrait pas être enregistré sur les différents compte d'ordinateur de la ferme.

Configuration IIS pour Délégation Kerberos

Pour permettre l'authentification Kerberos sur une ferme Web ( Ferme NLB, boitier F5 etc.), l'application Pool d'IIS doit s'exécuter sous l'identité du même compte utilisateur du domaine sur chaque serveur. Le SPN correspondant à l'URL de connexion sera enregistré sur ce compte. Dans cette configuration, le navigateur peut demander un ticket Kerberos pour la chaine SPN spécifiée et présenter le ticket Kerberos à chaque noeud de la ferme web puisque chauqe noeud tourne sous le même compte d'utilisateur du domaine.

Délégation Kerberos

Dans l'Active Directory, créez simplement un compte utilisateur, dit compte de service, et positionnez les flags « User cannot Change Password » et « Password never expires ».

2. Configuration d'IIS

Créez ensuite dans IIS un nouveau pool d'application et définissez comme identité le compte que vous venez de créer. 

Créez ensuite le site web, puis configurez le pour s’exécuter dans le pool d’application précédemment configuré.

Cas particulier: Environnement mutualisé

 

Dans le cas où le serveur héberge plusieurs sites IIS, il faut pouvoir séparer les instances de IIS.
Celà peut être réalisé de 2 manières:
-    soit en les différençiant grâce à un numéro de port différent.
-    soit en les différençiant par le host header.

La première solution presente le désavantage d’avoir à manipuler des numéros de port nécessaires pendant la construction du SPN. Les navigateurs se comportant différemment, certains risquent de ne pas passer le numéro de port pendant la construction du SPN, au final le SPN demandé ne sera pas trouvé ou un ticket Kerberos pour le mauvais compte sera retourné par l'AD. De plus, il risque sur la route d'y avoir des réécritures de port: (ex à travers un boitier F5) et le port passé dans la construction du SPN par le client ne sera pas nécessairement celui enregistré dans le SPN dans l'AD.

Afin d’avoir une meilleure maitrise de la solution  et s’assurer d’une configuration qui fonctionne dans tous les cas, la  seconde solution  est à privilégier lorsque c’est posible. Elle nécessite la configuration du Host Header dans le site IIS.
Dans le scénario le plus simple, ce host header doit correspondre à une entrée de type A (host) dans le DNS (et pas une entrée de type CNAME (Alias) dans le DNS) et être enregistré au niveau des SPN sur le compte de service de l’application pool. 

Ainsi, lorsque le navigateur Internet Explorer, demande l’URL http://portaldns, il demande un ticket kerberos pour le SPN http/portaldns enregistré sur le compte de service domAD\svcdnsadmin. Il le presente alors au serveur IIS qui grâce au host header portaldns redirige la requête vers la bonne instance.
Si un alias est enregistré au niveau host header, le spn associé à l’entrée de type host correspondant à l’alias DNS doit également être enregistré en tant que SPN.
Vous pouvez placer plusieurs host headers sur un même instance IIS (ie plusieurs URL d’accès).

Importance du Host vs ALIAS DNS

 

Les navigateurs se comportent tous différemment.

Ainsi, lors de la construction du SPN, Internet Explorer fait une résolution DNS du nom de serveur spécifié dans l'URL et construit par défaut un SPN de type host/fqdn ou fqdn est le nom de host (type A) présent dans le DNS, même si dans l'URL un alias DNS (type CNAME) a été spécifié. en d'autre terme, si vous demandez http://alias, le spn construit sera http/host. Le mécanisme peut être inversé par le biais d'un htofix. Je ne recommande personnellement pas la modification de ce comportement. Il est en effet élégant d'avoir à n'enregistrer qu'un seul SPN dans l'AD (celui du host) et de pouvoir avoir une multitude d'aliases. Firefox par contre utilise le nom passé dans l'URL sans transformer l'alias en host.

Dans le scénario de host header, si IIS est accédé par une url contenant un alias, il faudra enregistrer en SPN le host et l'alias pour que ça fonctionne depuis n'importe quel navigateur.

3. Configuration supplémentaire

 A ce stade,ça ne fonctionne pas encore. Il faut donner les bonnes permissions au compte de service sur le serveur. Le compte de service nouvellement crée a besoin de permissions sur la metabase IIS et de permissions sur le répertoire temporaire %Windir%\Microsoft.NET\Framework\version\Temporary ASP.NET
La commande aspnet_regiis –ga réalise ces 2 opérations. Lancez: aspnet_regiis -ga Domain\AccountName

Ensuite, rajoutez le compte d’identité du pool d’application IIS dans le groupe local IIS_WPG.

Rajoutez maintenant les SPN requis sur le compte de service du pool d'application à l'aide de la commande setspn. Ex:

setspn -a http/portaldns domAD\svcportaladmin et setspn -a http/alias  domAD\svcportaladmin enregistrent les SPN pour le host et l'alias sur le compte de service. Celà permet de faire fonctionner kerberos dans la majorité des cas. Plusieurs aliases peuvent être ajoutés.

 4. Délégation Kerberos

Pour terminer, la délégation Kerberos doit être mise en place. Le compte de service doit être approuvé pour la délégation (Trusted for Delegation) dans l'Active Directory et pour des raisons de sécurité, les contraintes de délégation doivent être mises en place, c'est à dire lister uniquement les TGS Kerberos (représentés par les SPN)  que le compte de service est autorisé à demander.   

Le compte de service nouvellement crée a besoin de permissions sur la metabase IIS et de permissions sur le répertoire temporaire %Windir%\Microsoft.NET\Framework\version\Temporary ASP.NET

La commande aspnet_regiis –ga réalise ces 2 opérations. Lancez:
aspnet_regiis -ga Domain\AccountName
 

Dans le cas d’une application ASP.NET, le fichier web.config doit être configuré de la façon suivante : http://support.microsoft.com/kb/810572
Bien évidemment, pour que la délégation Keberos fonctionne, cela nécessite au préalable une authentification du poste client et donc désactivation de l’authentification anonyme et l’activation de l’authentification intégrée.




Au niveau Internet Explorer, l’authentification intégrée doit être activée, et l’URL résolue en tant que site Intranet (c’est souvent le proxy.pac qui détermine si l’url est locale ou non).