PI Services

Le blog des collaborateurs de PI Services

Distribuer un profil WiFi par GPO

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.

Outlook - Connexion au serveur Exchange indisponible

Contexte

Lors de l'initialisation du client d'Outlook un popup apparaît :

"Impossible de trouver une correspondance pour ce nom. La connexion à Microsoft Exchange n'est pas disponible. Outlook doit être en ligne ou connecté pour effectuer cette action"

Impossible d’aller plus loin. Dans l’observateur des événements l'entrée MAPI : 350569 me dirige vers une impossibilité de contacter le serveur mail.

Solution de contournement

Modifier la base de registre pour spécifier le FQDN du DC où se situe le catalogue global. Créer une nouvelle entrée String Value (REG_SZ) nommer DS Server avec une valeur le nom du serveur.

Il faut redémarrer Outlook et relancer la configuration qui peut  alors se terminer complètement. 

HKEY_CURRENT_USER\Software\Microsoft\Exchange\Exchange Provider.

 

Windows Server : Forcer la détection du type de réseau sur une NIC

Bonjour,

Aujourd'hui nous allons voir comment forcer la détection du type de réseau afin que le bon profil de pare-feu (public, privé, réseau de domaine) soit appliqué sur une connexion réseau.

La manipulation se fait via une console Powershell lancée en tant qu'administrateur.

La 1ère étape est de récupérer le numéro d'index de l'interface que l'on veut modifier avec la commande suivante :

Get-NetConnectionProfile

Ce qui doit donner le résultat suivant :

Ensuite, il suffit d'appliquer la commande suivante afin de forcer le profil voulu :

Set-NetConnectionProfile -InterfaceIndex 12 -NetworkCategory Private

A noter que vous avez le choix parmi deux des trois profils suivants :

  • Private : correspond au profil Privé, celui qui est activé par défaut si vous acceptez l'activation de la découverte réseau lors de la première initialisation de l'interface
  • Public : correspond au profil Publique, celui qui est activé par défaut si vous refusez l'activation de la découverte réseau lors de la première initialisation de l'interface
  • DomainAuthenticated : correspond au profil Réseau de domaine. Il n'est pas forçable car il est automatiquement détecté lorsqu'une machine est membre d'un domaine et que celle-ci dispose d'une connectivité vers un contrôleur de domaine. Si votre machine est membre d'un domaine mais que le profil appliqué est privé ou public, c'est que vous avez très probablement un problème de connectivité avec le domaine AD dont la machine est membre.

 

 

 

Stratégies de groupe : Analyse du fichier gpsvc.log - Paramètres CSE (Partie 3/3)

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...

GPSVC(274.178c) 09:29:22:029 ResetPolicies: Entering.
[...]
GPSVC(274.178c) 09:29:22:029 ParseRegistryFile: Entering with <C:\Users\XXX\ntuser.pol>.
GPSVC(274.178c) 09:29:22:029 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Cryptography\AutoEnrollment\
[...]
GPSVC(274.178c) 09:29:22:169 ParseRegistryFile: Entering with <\\contoso.com\sysvol\contoso.com\Policies\{E29B2A23-1589-4A05-A637-B83976319901}\User\registry.pol>.
GPSVC(274.178c) 09:29:22:169 SetRegistryValue: NoWelcomeScreen => 1 [OK]
GPSVC(274.178c) 09:29:22:169 SetRegistryValue: ForceStartMenuLogOff => 1 [OK]
GPSVC(274.178c) 09:29:22:169 SetRegistryValue: AEPolicy => 7 [OK]
 
On remarque les éléments suivants :
  • 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 :

Scripts and Administrative Templates CSE Debug Logging (gptext.dll) HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon

ValueName: GPTextDebugLevel 
ValueType: REG_DWORD 
Value Data: 0x00010002 
Options: 0x00000001 = DL_Normal 
0x00000002 = DL_Verbose 
0x00010000 = DL_Logfile 
0x00020000 = DL_Debugger

Log File: C:\WINNT\debug\usermode\gptext.log 

Security CSE WINLOGON Debug Logging (scecli.dll) 
KB article: 245422 How to Enable Logging for Security Configuration Client Processing in Windows 2000

HKLM\Software\Microsoft\WindowsNT\CurrentVersion\WinLogon\GPExtensions\{827D319E-6EAC-11D2- A4EA-00C04F79F83A

ValueName: ExtensionDebugLevel 
ValueType: REG_DWORD 
Value Data: 2 
Options: 0 = Log Nothing 
1 = Log only errors 
2 = Log all transactions

Log File: C:\WINNT\security\logs\winlogon.log

Folder Redirection CSE Debug Logging (fdeploy.dll) 
HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Diagnostics

ValueName: fdeployDebugLevel 
ValueType: REG_DWORD 
Value Data: 0x0f

Log File: C:\WINNT\debug\usermode\fdeploy.log

Offline Files CSE Debug Logging (cscui.dll) 
KB article: 225516 How to Enable the Offline Files Notifications Window in Windows 2000 

Software Installation CSE Verbose logging (appmgmts.dll) 
KB article: 246509 Troubleshooting Program Deployment by Using Verbose Logging 
HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Diagnostics

ValueName: AppmgmtDebugLevel 
ValueType: REG_DWORD 
Value Data: 0x9B or 0x4B

Log File: C:\WINNT\debug\usermode\appmgmt.log 

Software Installation CSE Windows Installer Verbose logging 
KB article: 314852 How to enable Windows Installer logging

HKLM\Software\Policies\Microsoft\Windows\Installer

ValueName: Logging 
Value Type: Reg_SZ 
Value Data: voicewarmup

Log File: C:\WINNT\temp\MSI*.log

Stratégies de groupe : Analyse du fichier gpsvc.log (Partie 2/3)

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 There is connectivity
GPSVC(2dc.18c) 11:42:09:106 Wait For Connectivity : Succeded

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 :

GPSVC(2cc.c28) 15:56:05:510 IsSlowLink: Bandwidth Threshold (WINLOGON) = 500.
GPSVC(2cc.c28) 15:56:05:510 IsSlowLink: Bandwidth Threshold (SYSTEM) = 500.
GPSVC(2cc.c28) 15:56:05:510 IsSlowLink: WWAN Policy (SYSTEM) = 0.
GPSVC(2cc.c28) 15:56:05:510 IsSlowLink: Current Bandwidth >= Bandwidth Threshold.
 
On remarque que le seuil est de 500 kbps par défaut.

Ordre de traitement des stratégies

Les stratégies vont être traitées de manière hiérarchique dans l'ordre suivant :
1) Ordinateur Local
2) Sites AD
3) Domaines AD
4) OU Parentes
5) OU Enfants
 
Avec toutefois quelques exceptions :
  • 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é
 
La règle à retenir est la suivante : C'est le dernier paramètre lu qui gagne
 
Exemple : Vous avez deux GPOs qui définissent une page de démarrage pour Internet Explorer.
Une est à la racine du domaine, l'autre dans une OU enfant.
Dans le fichier de log, le paramètre de la GPO étant à la racine du domaine sera traité en premier et le paramètre de la GPO étant dans une OU enfant sera traité en deuxième.
Le dernier paramètre lu étant celui qui est appliqué, ce sera donc le paramètre de la GPO étant située dans l'OU enfant qui sera appliqué.
 
Voici comment cela se présente dans le fichier de log :

Lecture des stratégies :

GPSVC(2dc.22b0) 17:16:01:922 SearchDSObject: Searching <OU=OU_Enfant,OU=OU_Parent,DC=contoso,DC=local>
GPSVC(2dc.22b0) 17:16:01:922 SearchDSObject: Found GPO(s): <[LDAP://cn={D110C8FA-777B-4F95-BB65-A333A8B0091D},cn=policies,cn=system,DC=contoso,DC=local;0]...>
GPSVC(2dc.22b0) 17:16:01:922 ProcessGPO: ==============================
 
Il existe trois valeurs numériques à la fin de la requête LDAP pour chaque lien :
  • 0 : Paramètre par défaut
  • 1 : Le lien est désactivé
  • 2 : Le lien est appliqué (enforced)
 Une fois que toutes les GPO sont lues, celles-ci sont traitées.

Traitement des stratégies :

GPSVC(2dc.22b0) 17:16:02:109 ProcessGPO: Searching <cn={EC37F666-21C0-459E-88DF-3AD63AE600A1},cn=policies,cn=system,DC=contoso,DC=local>
GPSVC(2dc.22b0) 17:16:02:109 ProcessGPO: User has access to this GPO.
GPSVC(2dc.22b0) 17:16:02:109 FilterCheck: Found WMI Filter id of: <[contoso.local;{118D5E2E-9A8A-41C8-AB0C-D87AAE094BF1};0]>
GPSVC(2dc.22b0) 17:16:02:171 ProcessGPO: GPO passes the filter check.
GPSVC(2dc.22b0) 17:16:02:171 ProcessGPO: Found functionality version of: 2
GPSVC(2dc.22b0) 17:16:02:171 ProcessGPO: Found file system path of: <\\contoso.local\sysvol\gds.local\Policies\{EC37F666-21C0-459E-88DF-3AD63AE600A1}>
GPSVC(2dc.22b0) 17:16:02:203 ProcessGPO: Found common name of: <{EC37F666-21C0-459E-88DF-3AD63AE600A1}>
GPSVC(2dc.22b0) 17:16:02:203 ProcessGPO: Found display name of: <CONTOSO-COMPUTER_WSUS>
GPSVC(2dc.22b0) 17:16:02:203 ProcessGPO: Found user version of: GPC is 1, GPT is 1
GPSVC(2dc.22b0) 17:16:02:203 ProcessGPO: Found flags of: 1
GPSVC(2dc.22b0) 17:16:02:203 ProcessGPO: No client-side extensions for this object.
GPSVC(2dc.22b0) 17:16:02:203 ProcessGPO: GPO CONTOSO-COMPUTER_WSUS is disabled. It will be skipped.
 
Plusieurs remarques peuvent être faites :
  • 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
Une fois ces GPO traitées, une passe particulière est réalisée pour les paramètres CSE (Client Side Extentions).
Ce sera l'objet de notre prochain billet.
 

Stratégies de groupe : Activation du fichier gpsvc.log (Partie 1/3)

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

Une première étape concerne l'activation des Messages d'état détaillés sur le poste client.
Ces messages détaillés vont afficher le détail des étapes de démarrage ou d'arrêt d'un poste.
On retrouvera dans ces messages le déroulement de l'application des GPO à l'ouverture d'une session utilisateur.
Ce n'est pas forcément très verbeux mais cette option est utile pour voir sur quelle section l'application des GPO bloque ou prend du temps.
L'activation de ce paramètre se fait par GPO ou GPEdit :

Le fichier gpsvc.log

Une deuxième étape concerne l'activation du fichier gpsvc.log.
Ce fichier va contenir toutes les étapes et tous les détails de l'application des GPO sur un poste, du démarrage du poste au bureau de l'utilisateur.
C'est aussi le cas lors d'un rafraîchissement manuel des GPOs par un GPUpdate.
 
Voici la procédure pour activer ce 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

Astuce : Une fois le fichier activé, sur Windows 7/Windows 2008 R2 ou en-dessous, il peut arriver que plusieurs threads concurrents écrivent en même temps dans le fichier, occasionnant des pertes d'informations.
Dans ce cas, il est recommandé de séparer le rafraîchissement des paramètres ordinateurs et utilisateurs avec la commande Gpupdate /force /target:computer ou Gpupdate /force /target:user
 
Une fois le fichier créé, il faut maintenant l'analyser. Ce sera l'objet d'une deuxième partie.
 

Quest RUM : Bien préparer ses machines avant une migration

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

Le poste doit être capable de résoudre les noms d'hôtes pour les domaines sources et cibles donc il faut penser à ajouter des redirecteurs conditionnels sur les serveurs DNS utilisés par vos postes clients.
Une fois les redirecteurs mis en place, la résolution de nom FQDN est assurée sur les postes ciblés.

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"

 

Quest RUM : Les erreurs les plus courantes

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é

Active Directory : Réparer le Secure Channel

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 :

Sécurité : Windows KB pour Ransomware – PETYA

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

clip_image002

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

clip_image003

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

clip_image004

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é.

clip_image005

clip_image006

 

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/