PI Services

Le blog des collaborateurs de PI Services

Windows – Changement de domaine Active directory d’un poste connecté en VPN.

 

Comme toute migration ou changement de domaine d’un poste de travail cette opération doit rester la plus transparente possible pour l’utilisateur final.

Cet article aborde la migration d’un poste connecté au réseau d’entreprise par un VPN.

Dans cette situation ce n’est pas la migration du poste qui pose une difficulté, mais l’impossibilité pour l’utilisateur de pouvoir ouvrir une session sur son poste.

Les informations d’authentification du compte (en cache) du domaine Active Directory qu’on peut utiliser même si le domaine n’est pas disponible, ce qu’on décrit comme le mode hors connexion, ne sont plus disponibles après le changement du domaine.

Par défaut Windows 7 cache jusqu’à dix comptes.

Le cache est enregistré dans la ruche suivante : HKEY_LOCAL_MACHINE\SECURITY\Cache.

clip_image002

Pour accéder à cette ruche il faut utiliser un outil tel que PsExec de SysInternal afin de débloquer l’accès.

La ligne de commande est la suivante : psexec -i -d -s c:\windows\regedit.exe

Après le changement de domaine les données mentionnées dans les valeurs NL$ seront supprimées (remises à zéro).

L’utilisateur ne peut donc plus ouvrir de session !

Pour ma part j’ai eu à traiter des utilisateurs travaillant dans des coins très reculés.J’ai eu part exemple le cas d’un VIP travaillant en Australie à plus de 3000 kms d’une agence disposant d’un réseau connecté à l’entreprise. La marge de manœuvre est quasiment nulle…

Pour contourner ce problème je propose deux techniques.

La première technique consiste à démarrer la connexion VPN donc l’authentification avant l’authentification Windows.

Il faut donc avant la migration configurer le client VPN afin qu’il se lance avant l’authentification Windows.

Sur les clients VPN récents de CheckPoint l’option Enable Secure Domain Logon permet ce mécanisme.

clip_image004

Vous verrez un icône supplémentaire dans la fenêtre d’authentification Windows.

Pour information cette option pour le client CheckPoint sur Windows XP n’est pas fonctionnelle.

La seconde technique si l’on ne souhaite pas ou si l’on ne peut pas démarrer la connexion VPN avant l’authentification Windows, consiste à ouvrir une session locale puis à lancer une application qu’on exécute en tant que avec son compte de domaine. Bien entendu la connexion VPN doit être démarrée.

En résumé :

· Création d’un compte local (admin si possible, bien utile pour se sortir de situation délicate) avant la migration.

· Après migration, authentification avec ce compte local.

· Lancer le VPN.

· Lancer une application. Exécuter en tant que (ex Notepad) avec son compte de domaine. (Pour information le RunAS ne fonctionne pas sous XP).

· Fermer la session et ouvrir une session avec son compte de domaine Active Directory.

Le VPN n’étant pas démarré, les informations mis en cache lors du lancement de Notepad exécuté « En tant que » précédemment seront utilisées.

La migration sous un VPN étant très délicate il faut bien entendu bien valider son processus avant de passer au concret.

Je conseille fortement quel que soit le scénario, de créer un compte local admin et de faire installer un outil tel que Team Viewer qui s’affranchit de l’adresse IP pour l’aide à distance.

TMG - IPv6, VPN et Best Practices avec Threat Management Gateway 2010

TMG et support de l'IPv6

A l'instar de son prédécesseur, TMG 2010 ne supporte pas le trafic IPv6. Ainsi lors de l'installation, certaines fonctionnalités IPv6 intégrées à Windows Server 2008 / Windows Server 2008 R2 sont désactivées. De plus un serveur TMG rejette par défaut l'intégralité du trafic IPv6 qu'il reçoit.

Ce comportement est intrinsèque au produit et est documenté sur Microsoft Technet dans la page unsupported configuration. Voici un extrait de l'article :

Forefront TMG does not support IPv6 traffic
Issue: IPv6 traffic is not supported by Forefront TMG (except for DirectAccess).

Cause: Filtering of IPv6 traffic is not supported, and all IPv6 traffic is blocked by default.

Solution: It is recommended that you disable IPv6 traffic on the Forefront TMG computer or array members. To disable the IPv6 stack on the Forefront TMG computer or array member, see Knowledge Base article KB929852 (http://go.microsoft.com/fwlink/?LinkId=179983).

Microsoft conseille donc de positionner la clé de registre DisabledComponents avec la valeur 0xFFFFFFFF afin de désactiver totalement la pile IPv6 dans le système d'exploitation.

Le seul scénario où l'utilisation de l'IPv6 avec TMG est supporté correspond à la mise en oeuvre de Direct Access. En effet Direct Access nécessite l'activation de la pile IPv6 ainsi que celle de plusieurs technologies de transition (ISATAP, Teredo...).

Dans ce cas bien précis une clé de registre spécifique doit être créée avant l'installation de TMG sur le serveur.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RAT\Stingray\Debug\ISACTRL]
"CTRL_SKIP_DISABLE_IPV6_PROTOCOLS"=dword:00000001

A titre informatif, la procédure exacte de configuration de Direct Access sur TMG est disponible sur le Blog Technet dédié à TMG.

Remarque : Même si il est possible d'implémenter Direct Access sur un serveur TMG, la plateforme à privilégier reste Forefront UAG (Unified Access Gateway). Pour en apprendre plus sur les avantages de Direct Access avec UAG, consultez ce lien.

Problématique rencontrée avec le service VPN / RRAS

Une fois la clé de registre DisabledComponents positionnée et le serveur TMG redémarré, toutes les fonctionnalités de TMG fonctionnent correctement hormis le service VPN (qui correspond en fait au service Routage et accès distant de Windows) qui refuse de démarrer.

Dans la console MMC de TMG, le service Remote Access Service est en état arrêté et l'erreur suivante se produit lorsque l'on tente de le démarrer manuellement :

The service could not be started

image

image

En parallèle, les erreurs suivantes sont générées dans le journal Système à chaque tentative de démarrage du service.

  • Source : Service Control Manager
    Event ID : 7024
    Description : The Routing and Remote Access service terminated with service-specific error A device attached to the system is not functioning.
  • Source : RemoteAccess
  • Event ID : 20103
    Description : Unable to load C:\Windows\System32\iprtrmgr.dll.

Ce sujet est abordé dans certains forums (dont les forums MS Technet) et un moyen de contournement consisterait à supprimer la clé de registre suivante ainsi que tout son contenu :

HKEY_LOCAL_MACHINE \ System \ currentcontrolset \ services \ remoteaccess \ routermanagers \ IPV6

Effectuer cette opération permet en effet un lancement manuel du service RRAS mais à chaque redémarrage du serveur TMG, le service RRAS refuse de démarrer automatiquement et il faut impérativement le lancer manuellement ! Dans ce scénario l'erreur suivante est loguée dans le journal d'évènements Applications :

  • Log Name : Application
    Source : Microsoft Forefront TMG Firewall
    Event ID : 21199
    Description: The Remote Access Service configuration for VPN could not be completed. As a result, the Remote Access Service may be stopped.

  • image

Cette solution (suppression de la clé de registre routermanagemers\IPV6) n'est donc pas une fin en soi mais un simple contournement permettant de démarrer (manuellement) le service RRAS. De plus dans ce scénario, le service RRAS accepte de démarrer mais la configuration positionnée dans TMG ne descend plus sur le service RRAS (TMG ne remplit donc plus son rôle qui consiste à "piloter" le service RRAS).

La solution : réactiver l'IPv6 !

Après de nombreux tests infructueux, j'ai finalement déterminé une solution au problème : il suffit de "réactiver l'IPv6" en supprimant la clé de registre DisabledComponents !

Comme quoi il faut parfois aller au delà des préconisations Microsoft.

Si vous souhaitez aller plus loin, cette problématique est également en discussion sur le forum Technet suivant :

http://social.technet.microsoft.com/Forums/en-US/ForefrontedgeVPN/thread/d033a9d1-aff6-4098-a002-e5e15ee1834c