Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

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.

Lync Server 2013 – Erreur 0x80090331 SEC_E_ALGORITHM_MISMATCH sur un serveur Front-End

Problématique

Lors du déploiement d’une nouvelle infrastructure Lync Server 2013 (sur un socle Windows Server 2012), le problème suivant peut apparaître sur les clients Lync :

Can’t sign in to Lync
We’re having trouble connecting to the server. If this continue, please contact your support team.

 image

En lançant une analyse du composant SIPStack sur les serveurs front-End Lync via les outils Lync Server Diagnostic Tool et Snooper pendant la connexion d’un client, on observe l’erreur suivante :

0x80090331 SEC_E_ALGORITHM_MISMATCH

image

Remarque : Dans Lync Server 2013, l’outil de logging n’est plus intégré au déploiement. Pour l’installer, il faut déployer le pack d’outil Lync Server 2013 Debugging Tools disponible à l’adresse suivante : http://www.microsoft.com/en-us/download/details.aspx?id=35453

Explication

L’erreur SEC_E_ALGORITHM_MISMATCH se produit durant la phase de négociation du protocole TLS (le flux client –> serveur étant sécurisé en SIP over TLS).

Il semble que le service Lync Server Front-End ou bien le client Lync 2013 ne gère pas correctement les certificats signés numériquement en SHA512.

 image

Résolution

Dans ce cas la résolution a consisté à déployer sur les serveurs Lync 2013 front-end un nouveau certificat signé avec les algorithmes SHA1/RSA en remplacement de l’ancien certificat signé en SHA512/RSA.

Ce comportement est assez étrange car le protocole SHA512 est intégré au système depuis Windows Vista pour les postes de travail et Windows Server 2008 pour les serveurs.

Windows Server 2012 – Création d’un fichier “unattend.xml” pour automatiser le déploiement post-SYSPREP (pas-à-pas)

Les fichiers de réponses permettant d’automatiser l’assistant mini-installation post-SYSPREP doivent être créés avec l’outil Windows System Image Manager.

Cet outil est l’un des composants du kit WADK (pour Windows Assessment and Deployment Kit). Le kit WADK de Windows 8 est disponible en téléchargement à l’adresse suivante :

http://www.microsoft.com/en-us/download/details.aspx?id=30652

Durant l’installation, il faut sélectionner à minima le composant Deployment Tools pour que la console Windows System Image Manager soit disponible.

image

Une fois le kit installé, il faut lancer la console Windows System Image Manager, puis créer un nouveau fichier de réponse dans la section Answer file de la console.

image

Le fichier de réponse est composé de 7 sections correspondant chacune à une étape distincte du processus d’installation. Dans le cas d’un fichier de réponse destiné à automatiser l’installation du système (partitionnement, choix de la version du système…) la majorité des paramètres se configurent dans la section 1 windowsPE.

Dans notre cas (création d’un fichier de réponse destiné à automatiser la phase post-SYSPREP), la majorité des paramètres se configurent dans les étapes  4 (specialize) et 7 (oobe System).

image

Dans la section Windows Image de la console il faut aller sélectionner le fichier install.wim présent dans le répertoire Sources du média d’installation de Windows Server 2012.

image

Attention : Vous devez extraire les sources de Windows Server 2012 dans un dossier stocké sur un disque dur (la création des fichiers de catalogue ne pouvant être réalisée que sur un support en lecture / écriture)

Choisissez ensuite l’édition de Windows Server 2012 correspondant au système d’exploitation dont vous souhaitez automatiser le SYSPREP (dans cet exemple il s’agit d’une installation FULL de Windows Server 2012 Standard).

image

Une fois l’image sélectionnée, la phase de génération des fichiers de catalogue se lance. Attention cette phase peut être longue (environ 2 minutes sur un SSD mais jusqu’à 10/15 minutes sur un disque dur mécanique 5400 tours.min ou 7200 tours.min).

image

Une fois les fichiers de catalogue généré, l’ensemble des packages inclut dans le média doivent s’afficher dans la section Windows Image. Chaque package contient un ou plusieurs paramètres pouvant être configuré. Chaque package possède son propre périmètre d’application (certains s’appliquent à la phase 1 du déploiement uniquement, d’autres aux phases 3 et 4, etc…).

image

Pour ajouter un package (dans notre exemple il s’agit du package nommé amd64_Microsoft-Windows-IE-ESC_10.0.9200.16384_neutral qui permet de configuré les options de mode de sécurité renforcé Internet Explorer), il faut faire un clic droit, puis choisir dans quelle étape on souhaite intégrer les paramètres (dans notre exemple ce package s’applique uniquement à la phase 4 Specialize.

image

Une fois le package ajouté, il apparaît ensuite dans la section Answer File avec tous ses paramètres (ici le package dispose de deux paramètres). Une liste déroulante est disponible pour configurer chaque paramètre.

En passant les paramètres IEHardenAdmin et IEHardenUser à la valeur False, le mode de sécurité renforcé d’Internet Explorer sera désactivé durant la phase de SYSPREP.

image

La difficulté dans ce processus consiste à identifier tous les packages les plus intéressant pour réaliser une configuration automatisée de Windows Server 2012.

Le tableau ci-dessous énumère les paramètres les plus intéressants pour un déploiement standard. Les paramètres obligatoires pour automatiser le déploiement sont indiqués en bleu dans le tableau.

Les paramètres indiqués en vert sont optionnels mais peuvent être intéressant pour optimiser le déploiement (par exemple fixer une page par défaut dans le navigateur ou ne pas charger au logon la console Server Manager).

Step Nom du package Paramètre Valeur
4 amd64_Microsoft-Windows-IE-ESC_Neutral IEHardenLimit false
4 amd64_Microsoft-Windows-IE-ESC_Neutral IEUserLimit false
4 amd64_Microsoft-Windows-IE-InternetExplorer_neutral DisableFirst RunWizard true
4 amd64_Microsoft-Windows-IE-InternetExplorer_neutral Home_Page http://www.google.fr
4 amd64_Microsoft-Windows-International-Core_neutral InputLocale fr-FR
4 amd64_Microsoft-Windows-International-Core_neutral SystemLocale fr-FR
4 amd64_Microsoft-Windows-International-Core_neutral UILanguage en-US
4 amd64_Microsoft-Windows-International-Core_neutral UserLocale fr-FR
4 amd64_Microsoft-Windows-ServerManager-SrvMgrNc_neutral DoNotOpenServer ManagerAtLogon true
4 amd64_Microsoft-Windows-Shell-Setup_neutral ComputerName *
4 amd64_Microsoft-Windows-Shell-Setup_neutral ProductKey AAAAA-BBBBB-CCCCC-DDDDD-FFFFF
4 amd64_Microsoft-Windows-Shell-Setup_neutral RegisteredOrganization LAB
4 amd64_Microsoft-Windows-Shell-Setup_neutral RegisterezOwner Windows User
4 amd64_Microsoft-Windows-Shell-Setup_neutral TimeZone Romance Standard Time
7 amd64_Microsoft-Windows-Shell-Setup_neutral / Display ColorDepth 16
7 amd64_Microsoft-Windows-Shell-Setup_neutral / Display HorizontalResolution 1024
7 amd64_Microsoft-Windows-Shell-Setup_neutral / Display VerticalResolution 768
7 amd64_Microsoft-Windows-Shell-Setup_neutral / OOBE HideEULAPage true
7 amd64_Microsoft-Windows-Shell-Setup_neutral / OOBE HideLocalAccount Screen true
7 amd64_Microsoft-Windows-Shell-Setup_neutral / OOBE HideOnlineAccount Screens true
7 amd64_Microsoft-Windows-Shell-Setup_neutral / OOBE NetworkLocation work
7 amd64_Microsoft-Windows-Shell-Setup_neutral / OOBE ProtectYourPC 1
7 amd64_Microsoft-Windows-Shell-Setup_neutral / UserAccounts / AdministratorPassword value Pa$$w0rd

Au final vous devez obtenir un fichier de réponse proche de celui ci-dessous.

image

Le fichier de réponse peut ensuite être utilisé. Pour cela il faut le copier dans le répertoire C:\Windows\System32\SYSPREP, puis utiliser la ligne de commande suivante lorsque vous exécuterez la commande SYSPREP :

sysprep.exe /generalize /oobe /shutdown /unattend:"C:\Windows\System32\sysprep\monfichier.xml"

Avec ce fichier de réponse l’ordinateur / le master doit pouvoir démarrer après le sysprep sans qu’aucun paramètre ne soit demandé (aucune action entre le moment où le master est déployé et le moment où l’écran de logon s’affiche).

image