Mise en Oeuvre :

Installation sur l'infrastructure :

Pour réaliser l'installation de LAPS sur un serveur membre nous aurons besoin dans un premier temps d'un compte avec les droit Administrateur Local sur le serveur, puis de bénéficier des droits Admin du Schéma puis Admin du domaine ou Admin de ou des Unités d'Organisation en fonction de l'étendue sur laquelle vous souhaiter déployer LAPS. (Pour ma part je l'ai fait avec un compte "Admin du Domaine" sur lequel j'ai accordé les droits "Admin du schéma" le temps de l'installation).

L'installation se fait en suivant les étapes ci-dessous :

1. Installation de LAPS avec les composants Serveur.
2. Extension du schéma.
3. Attribution des droits.
   1. Droits pour les computers .
   2. Création des groupes de sécurité.
   3. Délégation des droits aux groupes de sécurité sur les OU.
4. Paramétrage des GPO
   1. Import des fichiers ADMX et ADML.
   2. Création et paramétrage de GPO.

Etape 1 : Installation de LAPS avec les composant serveur :

Le fichier msi fournit par LAPS permet d'installer les composants clients et serveurs, par défaut seul les composants clients sont installés, dans notre cas nous souhaitons déployer les composant serveurs nous sélectionnerons donc les "Management Tools".

Vous remarquerez la présence de 3 modules pour les "Management Tools" :

1. Fat Client UI : Soit l'interface utilisateur client lourd permettant de récupérer les mot de passe en clair dans l'AD
2. Powershell module : L'interface Powershell
3. GPO Editor Templates : Les ADMX

Etape 2 : Extension du schéma

Exécuter Powershell en tant qu'Administrateur.

# Import du module
Import-module AdmPwd.PS
# Update du schéma
Update-AdmPwdADSchema

Etape 3 : Attribution des droits.

Pour attribuer aux machines le droit de modifier leurs attributs exécutez :

Set-AdmPwdComputerSelfPermission -OrgUnit "OU=Machines,DC=LAB,DC=INFO"

Pour créer les Groupes de sécurité afin de déléguer les droits (Lecture et Réinitialisation), vous avez deux options (en graphique via ADAC ou User & computers AD, ou avec Powershell, pour ma part ce sera Powershell).

# Création du Groupe Read_Laps
New-AdGroup -Name "Read_Laps" -SamAccountName "Read_Laps" -Description "Group For Read Permission" -GroupCategory Security -GroupScope Global -Path "OU=Groups,OU=IT,OU=Main,DC=LAB,DC=ORG"

# Création du Groupe Reset_Laps
New-AdGroup -Name "Read_Laps" -SamAccountName "Reset_Laps" -Description "Group For Reset Permission" -GroupCategory Security -GroupScope Global -Path "OU=Groups,OU=IT,OU=Main,DC=LAB,DC=ORG"

Nb: Le nom des groupes est un choix personnel, libre à vous de mettre autres choses.

Nous allons maintenant déléguer les droits sur une OU à l'aide des commandes suivantes :

# Permet d'attribuer le droit de lecture du mot de passe au Groupe "Read_Laps" sur l'OU "Main/IT/Computers"
Set-AdmPwdReadPasswordPermission -Identity "OU=COMPUTERS,OU=Main,DC=LAB,DC=ORG" -AllowedPrincipals Read_Laps –Verbose

# Permet d'attribuer le droit de changement du mot de passe au Groupe "Reset_Laps" sur l'OU "Main/IT/Computers"
Set-AdmPwdResetPasswordPermission –Identity "OU=COMPUTERS,OU=IT,OU=Main,DC=LAB,DC=ORG" –AllowedPrincipals Reset_Laps –Verbose

Nb : Le droit peut être déléguer sur l'ensemble du domaine, pour ma part seul les "Domain Admins" bénéficie de ce privilège.

Etape 4 : Paramétrage des GPO.

Par défaut, LAPS positionne les fichiers ADMX et ADML sur le poste local, si on veut les placer dans le SYSVOL de l’organisation, on ira donc récupérer :

• C:\Windows\PolicyDefinitions\AdmPwd.admx -> A copier dans le "%systemroot%\sysvol\domain\policies\PolicyDefinitions"
• C:\Windows\PolicyDefinitions\en-us\AdmPwd.adml -> A copier dans le "%systemroot%\sysvol\domain\policies\PolicyDefinitions\EN-US" (Option à répéter pour chaque langage de votre AD).

Nb: Si toutefois vous n'aviez pas les répertoires ci-dessus, il faudra les créer manuellement avec un compte ayant les droits.

Il ne nous reste plus qu'à déployer les stratégies de groupe pour définir le comportement de LAPS.

1. On ouvre donc "Group Policy Management" et on créé une nouvelle GPO (Dans cet Démo, on la nommera simplement "LAPS").
2. On accède aux nouveaux paramètres : Computer Configuration -> Policies -> Administrative Templates -> LAPS

C'est donc à partir de ces nouveaux paramètres que nous allons pouvoir activer ou inhiber LAPS et pouvoir agir sur les différentes politiques de sécurité :

• Intervalle de changement de mot de passe.
• Longueur et complexité du mot de passe.
• Définir le nom du compte Administrateur (Seulement si ce dernier à été renommé).

Activation de LAPS

Paramètre du nom de compte Administrateur : Ne pas configurer si le compte est celui par défaut.

Spécifications de longueur et complexité du mot de passe.

La configuration serveur est maintenant terminée.

Installation sur le client :

Comme par défaut le fichier msi n'installe que les composants client, il vous sera possible de scripter l'installation à l'aide de le commande : msiexec /i <emplacement>\LAPS.x64.msi /quiet

La partie client de LAPS est un CSE (Client Side Extension), soit une extension qui vient s’enregister auprès du service client de stratégies de groupe de Windows. Il s'agit donc bien d'une installation d'un composant de l'OS et non un nouveau service, que vous pourrez retrouver par défaut sous %programfiles%\LAPS\CSE\AdmPwd.dll

A chaque déclenchement du CSE, ce dernier :

• vérifie si le mot de passe est expiré à l'aide du dernier changement stocké dans l'attribut ms-Mcs-AdmPwdExpirationTime.
• S'il l'est, en génère un de manière aléatoire basé sur les politiques de sécurité définies par la GPO.
• Met à jour le mot de passe et l'inscrit en clair dans l'attribut ms-Mcs-AdmPwd et modifie l'attribut ms-Mcs-AdmPwdExpirationTime de l'objet Ordinateur dans l'Active Directory.

Voila la configuration est maintenant terminée, mappons la GPO et vérifions.

Vous êtes vous déjà posé la question "Mon parc informatique est il vulnérable?".

En terme de sécurité dans une grande majorité des cas la réponse est "Oui", mais alors pourquoi?

Grand nombre de personnes justifierons que le parc est à jour (Update, antivirus, firewall...), à cela je ne vous poserais que deux questions :

1. Le compte Admin Local est il désactivé sur toutes vos machines comme préconisé par Microsoft ? Si la réponse est non on peut déjà douter.
2. Le mot de passe du compte Admin Local des postes et/ou des serveurs est il différent sur chaque machine ? Si la réponse est non on à une faille de sécurité.

Envisageons simplement que  le mot de passe sur une de vos machines vient à être compromis, d'un coup, c'est l'ensemble de votre parc qui l'est et cela sans avoir besoin d'utiliser le compte Admin du domaine.

Une fois la première machine compromise il n'y a plus qu'a rebondir sur les autres pour pouvoir compromettre l'intégralité du parc.

Et si je vous disais qu'on pouvait gérer ce problème avec un outil développé par "Microsoft Consulting Services" et fournit gratuitement par Microsoft, laissez moi vous présenter LAPS.

Introduction à LAPS :

LAPS, qu'est ce que c'est?

LAPS pour "Local Admin Password Solution" est un outils permettant la gestion et le stockage du mot de passe Administrateur Local des machines du domaine : Postes clients et Serveurs membres.

Cette solution permet:

• De mettre à jour le mot de passe dans le contexte système et de l'envoyer au contrôleur de domaine à l'aide d'un composant client. Création aléatoire du mot de passe et transmission au contrôleur de domaine de manière crypté à l'aide de kerberos version 5 et Advanced Encryption Standard (AES).
• De stocker le mot de passe et sa durée de validité comme attribut de l'objet machine de l'Active Directory. ms-Mcs-AdmPwd et ms-Mcs-AdmPwdExpirationTime.
• Gérer le déploiement des paramètres de manière centraliser via les Stratégie de Groupes. Nom du compte, fréquence de changement, longueur et complexité.
• La récupération des mots de passe pour les utilisateurs habilités via une interface graphique ou Powershell. Par défaut seuls les "Admins du domaine" sont autorisés à accéder à ces informations mais il est possible de déléguer les droits sur un groupe.

Illustration à l'aide d'un schéma d'architecture de la solution :

Jusque là c'est sympa mais comment ça fonctionne?

Le coeur  de la solution LAPS est une extension d'un composant du client Stratégie de Groupe (CSE - Client Side Extension) qui pendant la mise à jour des Objets de Stratégies de Groupe, effectue et peut forcer les actions suivantes  :

1. Vérifier si le mot de passe Administrateur Local est expiré (Contrôle de la date de validité et de la configuration de la GPO).
2. Générer un nouveau mot de passe si l'ancien a expiré ou nécessite d'être changé avant expiration.
3. Valider que le nouveau mot de passe répond aux politiques de sécurité.
4. Envoyer le nouveau mot de passe à Active Directory et le stocker avec un attribut confidentiel dans l'objet ordinateur dans l'Active Directory.
5. Envoyer la prochaine date d'expiration du mot de passe à Active Directory et le stocker en tant qu'attribut dans l'objet ordinateur dans l'Active Directory.
6. Modifie le mot de passe du compte Administrateur local.

Il est possible de déléguer les droits suivants:

• Read Permission : Permet de lire le mot de passe depuis l'Active Directory, le client lourd LAPS ou avec Powershell par les utilisateurs autorisés. L'autorisation se fait par délégation de droits à des Groupes de sécurités (par défaut les "Admins du domaine").
• Reset Permission : Permet de soumettre une demande de changement de mot de passe depuis le client lourd LAPS ou avec Powershell.

Prérequis et OS supportés :

Prérequis :

Infrastructure :

• Active Directory : Windows Server 2003 SP1 ou ultérieur (L'attribut confidentiel n'est supporté qu'à partir du 2003 SP1 dans Active Directory)
• Ajout des attributs ms-Mcs-AdmPwd et ms-Mcs-AdmPwdExpirationTime (Action réalisé lors de l'installation).
• Restriction aux utilisateurs qui ne doivent pas accéder à l'attribut (retrait du All Extended Rights pour les groupes sensibles).
• Installation & paramétrage d'un ADMX.

•  Être Admin du Schéma le temps de l'installation (une Extension de Schéma est requise lors de l'installation)

Outils d'administrations :

• .NET Framework 4.0.
• Windows PowerShell 2.0 or ultérieur.

OS Supportés :

Clients : Windows 10 , Windows 8.1, Windows 8, Windows 7, Windows Vista avec le dernier Service Pack

Serveurs : Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, Windows Server 2008,  Windows Server 2003 avec le Service Pack 2 (mais plus supporté)

Note : Les machines Itanium ne sont pas supportées.

Contexte

Rajouter quelques PCs portables dans une salle qui ne peut plus accueillir de prises réseaux filaires.

D'abord configurer la connexion WiFi sur un PC portable, puis l’exporter avec la commande

netsh wlan export profile key=clear c:\

 C:\Users\Administrateur>netsh wlan export profile key

 Le profil d'interface « SSID » est enregistré dans le fichier « .\Wi-Fi-SSID.xml »

La clé apparaît en clair sauf avec la commande "netsh wlan export profile"

On crée la gpo sous configuration ordinateur>Paramètres Windows>paramètres de sécurité>Stratégie de réseau sans fil>nouvelle stratégie

On renseigne le SSID et mot de passe, connexion automatique et préférée, mais je change pour l’occasion le nom à diffuser en «Accès-SF »

Je lie la stratégie à une salle donnée.

Le SSID d’origine apparaît en non disponible alors que la connexion Acces-SF est active et connectée.

Les utilisateurs doivent se connecter au moins une fois en filaire sur le poste pour appliquer la stratégie.

Bonjour,

Après un second article sur l'analyse de ce fichier, voici un troisième complétant celle-ci et traitant plus spécifiquement des paramètres CSE.

Les paramètres CSE

Les paramètres CSE sont également appelés Client Side Extensions.

Ils correspondent à des fichiers DLL installés sur les clients stratégies de groupe et sont capables d'interpréter les paramètres contenus dans les stratégies. Vous pouvez voir la liste complète des extensions présentes sur votre poste en allant dans la clé registre suivante : HKEY_LOCAL_MACHINE/Software/Microsoft/Windows NT/CurrentVersion/Winlogon/GPExtensions

Deux types de traitements existent :

• Background
• Foreground

Le traitement de type Background concerne tous les paramètres CSE pouvant être modifiés sans impact pour l'utilisateur sur son poste.

Le traitement de type Foreground concerne tous les paramètres ne pouvant pas être traités en arrière-plan, les plus connus étant les paramètres Folder Redirection, Software Installation et GPP Drive Mapping. Le mode Foreground est activé uniquement au démarrage d'un poste ou lors de l'ouverture d'une session par utilisateur.

Traitement des paramètres CSE

Le traitement de ces paramètres est repérable dans la section suivante :

GPSVC(274.22f8) 11:11:30:216 ProcessGPOs: Both user and machine lists are defined. Merging them together.
GPSVC(274.22f8) 11:11:30:720 NlaQueryNetSignatures returned 1 networks
GPSVC(274.22f8) 11:11:30:720 Estimated bandwidth on one of the connections : 0 kbps
GPSVC(274.22f8) 11:11:30:721 Estimated bandwidth on one of the connections : 718611 kbps
GPSVC(274.22f8) 11:11:30:721 ReadExtStatus: Reading Previous Status for extension {35378EAC-683F-11D2-A89A-00C04FBBCFA2}

[...]

GPSVC(274.22f8) 11:11:30:761 ProcessGPOs: -----------------------
GPSVC(274.22f8) 11:11:30:761 ProcessGPOs: Processing extension Group Policy Environment
GPSVC(274.22f8) 11:11:30:761 CompareGPOLists: The lists are the same.
GPSVC(274.22f8) 11:11:30:761 CompareGPOLists: The lists are the same.
GPSVC(274.22f8) 11:11:30:762 CheckGPOs: No GPO changes but couldn't read extension Group Policy Environment's status or policy time.

On peut remarquer que :

• L'état précédent de l'extension est évalué en premier
• La valeur hexadécimale retournée pour indiquer quelle extension est analysée correspond à la liste des extensions présente dans le registre dans la clé GPExtensions
• Dans le cas d'un rafraîchissement périodique des GPO (Background Processing), une comparaison est effectuée afin de détecter les changements qui auraient été effectués depuis le dernier rafraîchissement. On remarque bien que les paramètres ne sont pas réapliqués de nouveau.

Nous allons voir ici un dernier exemple, lorsqu'un Foreground Processing est effectué (ouverture d'une session utilisateur) :

GPSVC(274.178c) 09:29:22:013 ProcessGPOList: Entering for extension Registre
GPSVC(274.178c) 09:29:22:013 UserPolicyCallback: Setting status UI to Application de la stratégie Registre...

• Le fichier des paramètres registre locaux (ntuser.pol) est analysé
• Une suppression de tous les paramètres registre présents est effectuée
• Une lecture du fichier des paramètres registre (registry.pol) pour chaque GPO est faite
• Le paramètre correspondant est appliqué dans le registre
• Une réapplication complète des paramètres utilisateurs registre est donc effectuée

Logs supplémentaires pour les paramètres CSE

Afin de pouvoir pousser les investigations encore plus loin, il est possible d'activer des fichiers de logs supplémentaires pour chaque extension CSE. Voici les principaux :

Bonjour,

Après un premier article sur l'activation de ce fichier, voici un second sur l'analyse de celui-ci.

Vous pouvez le trouver dans le dossier C:\Windows\debug\usermode\gpsvc.log

Threads

Sur les machines avec des architectures multi-coeurs, il peut y avoir plusieurs threads qui s'exécutent au même moment (un thread pour les paramètres utilisateurs et un thread pour les paramètres machine.). Il peut être utile de savoir les différencier dans le fichier de log.

Pour se faire, il suffit d'analyser les valeurs rapportées pour GPSVC :

GPSVC(78d.666) 12:41:45:477 Caller requesting for user notification/lock is from session 0

On remarque que celles-ci sont composées de deux parties :

• 78d : Correspond au PID (Process ID) (en héxadécimal)
• 666 : Correspond au TID (Thread ID)

Début du traitement des stratégies

Le traitement des stratégies débute toujours avec les paramètres machine.

Il peut être repéré par l'enregistrement suivant :

GPSVC(2dc.18c) 11:40:08:707 bMachine = 1
GPSVC(2dc.18c) 11:40:08:707 Setting GPsession state = 1

Connectivité réseau

Immédiatement après le début du traitement des stratégies machines, une vérification de la connectivité réseau est faite :

GPSVC(2dc.18c) 11:40:08:707 bMachine = 1
GPSVC(2dc.18c) 11:40:08:707 Setting GPsession state = 1
GPSVC(2dc.520) 11:40:08:707 Waiting for connectivity before applying policies

Souvent, le client Stratégies de groupe démarre avant que la connectivité réseau soit effective, ce qui génère le message suivant :

GPSVC(2dc.18c) 11:40:08:806 There is no connectivity. Waiting for connectivity again …

Mais quelques secondes plus tard, la connectivité est établie :

GPSVC(2dc.18c) 11:42:09:106 We have network connectivity… proceeding to apply policy.

En cas de non connectivité (30 secondes de timeout par défaut), on trouvera toujours l'erreur suivante :

GPSVC(2dc.520) 11:45:10:033 Application complete with bConnectivityFailure = 1.

Note : Cela peut être une erreur de connectivité mais pas uniquement réseau, cela peut concerner du LDAP par exemple

Estimation de la bande passante

Avant de traiter les stratégies de groupe, une estimation de la bande passante est faite.

Celle-ci est calculée en se connectant d'abord à un contrôleur de domaine afin d'obtenir une liste de ceux-ci, puis en évaluant la vitesse de la connexion entre le poste et un contrôleur de domaine. Le calcul de la bande passante est effectuée par le NLA (Network Location Awarnesss).

Le début de l'estimation se présente comme ceci :

GPSVC(2cc.c28) 15:56:04:821 GetDomainControllerConnectionInfo: Enabling bandwidth estimate.
GPSVC(2cc.c28) 15:56:05:134 Started bandwidth estimation successfully

La fin de l'estimation se présente comme ceci :

Ordre de traitement des stratégies

• Le lien d'un GPO peut être appliqué (enforced) ou/et désactivé
• Une stratégie peut avoir des paramètres ordinateurs/utilisateurs désactivés
• Le blocage de l'héritage au niveau de l'OU est activé
• Le mode bouclage est activé

Lecture des stratégies :

• 0 : Paramètre par défaut
• 1 : Le lien est désactivé
• 2 : Le lien est appliqué (enforced)

Traitement des stratégies :

• La présence d'un filtre WMI est détecté en 1er et s'il est présent, il est évalué.
• Le GUID de la GPO renvoie à son chemin physique dans le dossier SYSVOL.
• La présence de paramètres CSE est évaluée
• L'état de la GPO (désactivée ou non) est évaluée afin de décider de son traitement
• La présence de paramètres CSE est évaluée

Bonjour à tous !

Aujourd'hui nous allons aborder la résolution de problèmes d'application des stratégies de groupe (coté poste client) et plus précisément la partie avancée de cette résolution.

Débug usuel

Habituellement, il faut passer par l'Observateur d'Evènements du poste client afin d'obtenir plus de détails sur l'application des stratégies de groupe.

Deux sections peuvent vous intéresser :

• Journaux Windows/Système
  • Le niveau de détail est assez limité mais c'est un bon point de départ
  • Vous pouvez filtrer les événements par les sources pour ne garder que les parties intéressantes

• Journaux des applications et des services/Microsoft/Windows/GroupPolicy
  • Est beaucoup plus détaillé
  • Ne contient que les evènements stratégies de groupe

Mais parfois, il peut s'avérer que les informations remontées par ces logs ne soient pas assez précises pour trouver la vraie cause du problème.

Débug avancé

Les messages d'état détaillés

Le fichier gpsvc.log

1. Ouvrez l'éditeur de registre avec la commande Regedit
2. Dépliez la clé HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion
3. Crééz une nouvelle clé Diagnostics si elle n'existe pas
4. Crééz une nouvelle valeur DWORD (32-bit) GPSvcDebugLevel
5. Modifiez la valeur GPSvcDebugLevel par la valeur 30002 (Hexadecimal)
6. Fermez le Registre
7. Crééz le dossier Usermode si celui-ci est absent du dossier C:\Windows\Debug\
8. Lancez la commande Gpupdate /force
9. Le fichier gpsvc.log doit se créer

Bonjour à tous !

Comme vu dans le billet précédent, la plupart des erreurs rencontrées sur RUM proviennent plus de votre infrastructure (IP manquantes/non à jour dans les zones DNS, découverte réseau Windows désactivée, ...) que de RUM en lui même.

Afin de minimiser ces erreurs, sur les postes concernés par la migration, il convient de mettre en place un certain nombre de pré-requis que nous allons détailler ci-dessous.

Les pré-requis

Droits d'accès administratifs sur les postes de travail

Le serveur RUM utilise deux comptes de services distincts :

• Le compte de service du service RUM Controller
  • Il correspond au compte renseigné lors de l'installation du logiciel RUM
  • Il peut être configuré depuis la console RUM en allant dans le menu Tools -> Manage Controller Credentials

• Le compte de service du service Dell Migration Manager RUM Agent Service
  • Il correspond au compte utilisé par l'agent RUM quand il est installé sur un poste
  • ll peut être configuré depuis la console RUM en allant dans le menu Project -> Manage Domains Credentials

Le compte de service du service Controller RUM doit faire partie du groupe local Administrateurs du serveur RUM.

Le compte de service du service Dell Migration Manager RUM Agent Service doit faire partie du groupe local Administrateurs sur tous les postes devant être migrés.

Le firewall Windows/d'Entreprise

Pour la liste complète des ports, je vous renvoie à ce lien : What firewall ports need to be opened for Migration Manager for AD / Resource Updating

Pour la partie qui nous intéresse, à savoir le poste à migrer, il faut bien entendu une connectivité à minima vers les serveurs Active Directory des domaines sources et cibles.

La liste des ports à ouvrir entre un poste client et un serveur RUM est quelque peu longue, la faute au RPC Dynamique.

Vous devrez donc ouvrir de manière bi-directionnelle, entre un poste et un serveur RUM, les ports suivants :

• 135-139
• 445
• 1024-65535

La résolution de noms d'hôtes

Mais RUM utilisant également des noms d'hôtes courts, le poste doit être capable de les résoudre aussi.

Pour cela, il faut configurer sur les postes ciblés le paramètre de Liste de recherche de suffixes DNS comme ceci :

• Nom de domaine du domaine AD source
• Nom de domaine du domaine AD cible

Astuce : Ce paramètre peut aussi être mis en oeuvre sur votre serveur RUM si vous voulez travailler avec des noms d'hôtes courts (non FQDN).

Les services Windows

Sur les postes à migrer, les services Windows suivants doivent être démarrés et configurés en mode Démarrage automatique :

• Server
• Workstation
• Netlogon
• Remote Procedure Call
• Remote Procedure Call Locator
• Remote Registry
• Function Discovery Provider Host
• SSDP Discovery
• UPnP Device Host

Mise en place des pré-requis

Deux méthodes peuvent être utilisées afin de mettre en place les pré-requis décrits précédemment :

• Par GPO
• Par script

Par GPO

Voici un exemple de GPO pouvant être déployée sur les postes du domaine source :

Par Script

Voici un exemple de script pouvant être utilisé sur les postes du domaine source :

A savoir : La commande net localgroup ne supporte pas l'ajout d'un groupe étant composé de plus de 20 caractères (NET.EXE /ADD command does not support names longer than 20 characters)

REM Set startup type for services
sc config RpcSs start= auto
sc config SSDPSRV start= auto
sc config upnphost start= auto
sc config fdPHost start= auto
sc config RpcLocator start= auto
sc config Netlogon start= auto
sc config RemoteRegistry start= auto
sc config LanmanServer start= auto
sc config LanmanWorkstation start= auto

REM Start services
net start RpcSs
net start SSDPSRV
net start upnphost
net start fdPHost
net start RpcLocator
net start Netlogon
net start RemoteRegistry
net start LanmanServer
net start LanmanWorkstation

REM Disable Firewall on Domain profile
netsh advfirewall set DomainProfile state off

REM Add group to local Administrators group
net localgroup Administrateurs XXX\CORP-QUEST-ADMIN /ADD

REM Set DNS Suffix Search list
REG ADD HKLM\System\CurrentControlSet\Services\TCPIP\Parameters /v SearchList /t REG_SZ /f /d "domaine_source_fqdn,domaine_cible_fqdn"

Bonjour à tous !

Aujourd'hui nous allons voir quelles sont les erreurs les plus courantes lorsque vous travaillez avec Quest RUM (Resource Updating Manager) et quelles sont leurs solutions.

C'est parti !

The RPC Server is unavailable

Derrière son nom trivial qui indique que le serveur RPC de la machine que vous essayez de joindre n'est pas disponible, vous pouvez avoir deux comportements :

• L'erreur arrive juste après un Discovery/Processing/Move : RUM n'arrive pas à résoudre le nom de l'hôte. Vérifiez si le poste est bien référencé dans les DNS configurés sur votre serveur RUM.
• L'erreur arrive environ 20/30 secondes après un Discovery/Processing/Move : RUM arrive bien à résoudre le nom de l'hôte mais celui-ci n'est pas joignable. Vérifiez en priorité que le pare-feu Windows est correctement configuré ou désactivé et vérifiez si la découverte réseau Windows est bien activé dans les options du Centre Réseau et Partage.

En dernier, comme son nom l'indique, vous pouvez toujours vérifier si le service Serveur RPC est bien lancé mais c'est le cas le moins souvent rencontré.

Access is denied

L'erreur indique le poste est joignable mais que le serveur RUM n'arrive pas à atteindre le partage administratif du poste ciblé pour y effectuer ses opérations.

Bien qu'étant assez générique, cette erreur se rencontrera surtout lors des trois cas suivants :

• La découverte réseau Windows n'est pas active sur le poste ciblé
• Le serveur RUM ne contacte pas la machine voulue car l'IP de la machine ciblée n'est pas à jour dans les serveurs DNS utilisés
• La machine ciblée n'est pas dans le domaine renseigné (déjà migrée ou autre domaine)

Log path RUM_Server_Name is not accessible

L'erreur indique que l'agent RUM sur le poste n'arrive pas à contacter le serveur RUM ou/et n'arrive pas à accéder au partage QuestResourceUpdatingLogs$ pour y transférer ses logs.

Vous êtes plus susceptible de rencontrer cette erreur si votre poste et le serveur RUM sont dans des domaines différents. Bien souvent, cela indique que le poste n'arrive pas à résoudre le nom du serveur RUM car l'agent utilise le nom d'hôte court du serveur et non son nom FQDN pour le contacter.

Dans ce cas, la solution consiste à vérifier dans la liste de recherche de suffixes DNS Windows si le nom de domaine du serveur RUM est bien présent.

The network path was not found

De manière générale, cette erreur concerne plus les problèmes de résolution de nom NetBIOS des postes, cela étant dit, vous pouvez rencontrer également les deux comportements suivants :

• L'erreur se produit lors d'un Discovery/Processing alors que le poste était joignable juste avant : Le poste a été éteint entre temps ou son IP n'est pas à jour dans les DNS
• L'erreur se produit lors d'un Move : Il faut désactiver la recherche LMHOSTS dans les paramètres TCP/IP avancés du poste ciblé

A security package specific error occurred

Cette erreur se produit lors d'un Discovery. Une installation manuelle de l'agent RUM se terminera par la même erreur sur le poste ciblé.

La solution la plus souvent appliquée est d'utiliser l'IP du poste plutôt que son FQDN pour faire le Discovery.

The parameter is incorrect

Cette erreur se produit lors d'un Move.

Elle peut être rencontrée lorsque le serveur RUM contacte un contrôleur de domaine sous Windows Server 2012 R2 pour migrer le poste dans le domaine cible.

Deux solutions à ce problème :

• Utiliser un contrôleur de domaine non 2012 R2 pour effectuer la bascule (voir l'article Définition des contrôleurs de domaine préférés)
• Ne pas utiliser l'option "Create the computer object in this OU in the target domain" mais les attributs RestrictedKrbHost/ComputerName SPN ne seront pas repris pour l'objet ordinateur migré

Bonjour à tous,

Aujourd'hui nous allons aborder la problématique du Secure Channel (canal sécurisé) dans une infrastructure Active Directory.

Qu'est ce que le Secure Channel ?

Le Secure Channel ou Canal Sécurisé est un élément vital dans une infrastructure Active Directory. En effet, toute communication entre une station de travail et un contrôleur de domaine AD doit passer via un canal sécurisé.

Il est à noter que le canal sécurisé est également utilisé pour les communications entre deux contrôleurs de domaine.

Quand le canal sécurisé est cassé, toutes les opérations Active Directory liées au canal sont en échec (Tickets Kerberos, stratégies de groupes, ...).

Quand le Secure Channel est cassé

Le signe le plus flagrant d'un problème de canal sécurisé entre un poste et un contrôleur de domaine est le message suivant au démarrage du poste : "The trust relationship between this workstation and the primary domain failed".

La plupart du temps, ceci est du au fait que le mot de passe en usage pour établir le Secure Channel sur le poste concerné est différent du mot de passe du compte ordinateur stocké dans l'AD.

Réparer le Secure Channel

Habituellement, l'étape de réparation passe par les étapes suivantes :

1. Sortie du poste du domaine pour un retour en Workgroup
2. Réinitialisation du compte ordinateur correspondant dans l'Active Directory
3. Réintégration du poste dans le domaine

L'ancienne méthode

Une méthode, plus propre, et qui vous épargnera un redémarrage consiste à réparer le canal sécurisé directement avec une invite de commande.

La commande à utiliser est netdom resetpwd /s:domaincontroller /ud:domain\User /pd:*

La nouvelle méthode

Avec l'avènement de Powershell, une nouvelle commande a fait son apparition : Test-ComputerSecureChannel.

Si la commande renvoie True, c'est que le Secure Channel est fonctionnel entre le poste et le contrôleur de domaine concerné.

Si elle renvoie False, c'est que le Secure Channel n'est plus fonctionnel entre le poste et le contrôleur de domaine concerné.

Il faut l'utiliser avec l'option Repair afin de réparer le Secure Channel.

Le retour de la commande, True ou False, indique le succès ou non de la réparation du Canal Sécurisé.

A noter qu'à partir de Powershell v4.0, l'option Credential permet de préciser les identifiants à utiliser pour réparer le canal sécurisé.

Version Windows 7 / Windows Server 2008 R2 :

Version Windows 8 / Windows Server 2012 R2 :

Le rançongiciel Petya est apparu fin juin en Ukraine pour ensuite se propager rapidement partout dans le monde.

Il s’agirait d’une variante de WannaCrypt qui était apparu en début d’année.

Se protéger

Si vous n’avez pas encore été infectée, vous devez vérifier que vos postes disposent des dernières mises à jour et de les installer si ce n’est pas le cas.

Pour agir rapidement vous pouvez installer uniquement la KB qui correspond à votre système d’exploitation en regardant la liste sur cette article https://blog.piservices.fr/post/2017/05/30/securite-kb-pour-wanna-cry et de se rendre sur le catalogue de Microsoft pour le télécharger http://www.catalog.update.microsoft.com/home.aspx.

Vérifier avec WSUS

Si vous disposez d’un serveur WSUS vous pouvez vérifier depuis la console si votre parc informatique est protégé. Pour se faire il faut se rendre dans l’onglet Updates -> Security Updates -> Search

Dans la fenêtre qui apparaît vous devez rentrer la KB souhaitez par exemple : 4012212

Lorsque vous regardé le report de la KB (en double cliquant dessus) vous verrez :

• La description de la KB
• Les groupes qui approuvent cette KB
• L’état de déploiement par rapport à vos machines

Microsoft a également sorti un script qui permet de savoir si votre machine dispose du patch ou non. Le seul prérequis est de disposer au minimum de Windows PowerShell 2.0. https://support.microsoft.com/fr-be/help/4023262/how-to-verify-that-ms17-010-is-installed

Voici le script :

[reflection.assembly]::LoadWithPartialName("System.Version")
$os = Get-WmiObject -class Win32_OperatingSystem
$osName = $os.Caption
$s = "%systemroot%\system32\drivers\srv.sys"
$v = [System.Environment]::ExpandEnvironmentVariables($s)
If (Test-Path "$v")     {     Try         {         $versionInfo = (Get-Item $v).VersionInfo         $versionString = "$($versionInfo.FileMajorPart).$($versionInfo.FileMinorPart).$($versionInfo.FileBuildPart).$($versionInfo.FilePrivatePart)"         $fileVersion = New-Object System.Version($versionString)         }     Catch         {         Write-Host "Unable to retrieve file version info, please verify vulnerability state manually." -ForegroundColor Yellow         Return         }     }
Else     {     Write-Host "Srv.sys does not exist, please verify vulnerability state manually." -ForegroundColor Yellow     Return     }
if ($osName.Contains("Vista") -or ($osName.Contains("2008") -and -not $osName.Contains("R2")))     {     if ($versionString.Split('.')[3][0] -eq "1")         {         $currentOS = "$osName GDR"         $expectedVersion = New-Object System.Version("6.0.6002.19743")         }      elseif ($versionString.Split('.')[3][0] -eq "2")         {         $currentOS = "$osName LDR"         $expectedVersion = New-Object System.Version("6.0.6002.24067")         }     else         {         $currentOS = "$osName"         $expectedVersion = New-Object System.Version("9.9.9999.99999")         }     }
elseif ($osName.Contains("Windows 7") -or ($osName.Contains("2008 R2")))     {     $currentOS = "$osName LDR"     $expectedVersion = New-Object System.Version("6.1.7601.23689")     }
elseif ($osName.Contains("Windows 8.1") -or $osName.Contains("2012 R2"))     {     $currentOS = "$osName LDR"     $expectedVersion = New-Object System.Version("6.3.9600.18604")     }
elseif ($osName.Contains("Windows 8") -or $osName.Contains("2012"))     {     $currentOS = "$osName LDR"     $expectedVersion = New-Object System.Version("6.2.9200.22099")     }
elseif ($osName.Contains("Windows 10"))     {     if ($os.BuildNumber -eq "10240")         {         $currentOS = "$osName TH1"         $expectedVersion = New-Object System.Version("10.0.10240.17319")         }     elseif ($os.BuildNumber -eq "10586")         {         $currentOS = "$osName TH2"         $expectedVersion = New-Object System.Version("10.0.10586.839")         }     elseif ($os.BuildNumber -eq "14393")         {         $currentOS = "$($osName) RS1"         $expectedVersion = New-Object System.Version("10.0.14393.953")         }     elseif ($os.BuildNumber -eq "15063")         {         $currentOS = "$osName RS2"         "No need to Patch. RS2 is released as patched. "         return         }     }
elseif ($osName.Contains("2016"))     {     $currentOS = "$osName"     $expectedVersion = New-Object System.Version("10.0.14393.953")     }
elseif ($osName.Contains("Windows XP"))     {     $currentOS = "$osName"     $expectedVersion = New-Object System.Version("5.1.2600.7208")     }
elseif ($osName.Contains("Server 2003"))     {     $currentOS = "$osName"     $expectedVersion = New-Object System.Version("5.2.3790.6021")     }
else     {     Write-Host "Unable to determine OS applicability, please verify vulnerability state manually." -ForegroundColor Yellow     $currentOS = "$osName"     $expectedVersion = New-Object System.Version("9.9.9999.99999")     }
Write-Host "`n`nCurrent OS: $currentOS (Build Number $($os.BuildNumber))" -ForegroundColor Cyan
Write-Host "`nExpected Version of srv.sys: $($expectedVersion.ToString())" -ForegroundColor Cyan
Write-Host "`nActual Version of srv.sys: $($fileVersion.ToString())" -ForegroundColor Cyan
If ($($fileVersion.CompareTo($expectedVersion)) -lt 0)     {     Write-Host "`n`n"     Write-Host "System is NOT Patched" -ForegroundColor Red     }
Else     {     Write-Host "`n`n"     Write-Host "System is Patched" -ForegroundColor Green     }
#

Voici le résultat de se script exécuté sur un poste patché et non patché.

Information :

Si vous êtes déjà touché par le rançongiciel, la première chose à faire est d’isoler tous les équipements identifiés comme étant contaminés en les débranchant du réseau afin de contenir l’action du programme. De plus vous devez si possible mettre en veille prolongé la machine ou de la mettre hors tension pour arrêter l’action du programme et de ne surtout pas payer la rançon.

Vous pouvez lire également deux notes de l’Agence Nationale de la Sécurité des Systèmes d’Information (ANSSI) qui permet de savoir quelle attitude adopter avant et après une attaque rançongiciel.

http://www.cert.ssi.gouv.fr/site/CERTFR-2017-INF-001/CERTFR-2017-INF-001.html

http://www.ssi.gouv.fr/actualite/alerte-campagne-de-rancongiciel-3/