TIP 3.13 – Vérifier l’accès aux ressources et résoudre un incident AD

Lorsqu’un utilisateur indique :

« Je n’arrive plus à me connecter »

ou :

« Je n’ai plus accès à mon dossier réseau »,

le problème peut se situer à plusieurs niveaux.

Il peut concerner :

• le poste de travail ;
• la connexion réseau ;
• le DNS ;
• le domaine Active Directory ;
• le compte utilisateur ;
• les groupes de sécurité ;
• le canal sécurisé du poste ;
• le serveur de fichiers ;
• les permissions SMB ;
• les permissions NTFS.

L’objectif du technicien est donc de localiser précisément l’origine de l’incident avant de modifier quoi que ce soit.

1. Commencer par qualifier précisément l’incident

La phrase :

« Le réseau ne fonctionne pas »

est insuffisante pour commencer un diagnostic.

Pose des questions précises :

• L’utilisateur peut-il ouvrir sa session Windows ?
• Le problème concerne-t-il un seul poste ?
• Un seul utilisateur est-il concerné ?
• Les autres membres du service accèdent-ils à la ressource ?
• Internet fonctionne-t-il ?
• Le serveur est-il accessible ?
• Le problème concerne-t-il toutes les ressources ou une seule ?
• Le problème est-il apparu après un changement de mot de passe ou de service ?

2. Authentification ou autorisation ?

C’est l’une des distinctions les plus importantes.

Exemple :

Sophie ne parvient pas à ouvrir sa session de domaine :

problème potentiel d’authentification.

Sophie ouvre sa session mais reçoit « Accès refusé » sur un dossier :

problème potentiel d’autorisation.

3. Vérifier l’identité réellement utilisée

Commence par :

whoami

Résultat attendu :

entreprise\smartin

Si tu obtiens :

pc-compta-07\smartin

l’utilisateur travaille avec un compte local, pas avec son compte Active Directory.

4. Vérifier le domaine du poste

Get-CimInstance Win32_ComputerSystem |
Select-Object Name,Domain,PartOfDomain

Exemple :

Name          Domain              PartOfDomain
----          ------              ------------
PC-COMPTA-07  entreprise.local    True

Si :

PartOfDomain : False

le poste n’est pas membre du domaine.

5. Vérifier la configuration réseau

Comme dans tout incident réseau :

Get-NetIPConfiguration

ou :

ipconfig /all

Vérifie notamment :

• adresse IP ;
• passerelle ;
• DNS ;
• interface utilisée.

6. Vérifier le DNS

Active Directory dépend fortement du DNS.

Teste le contrôleur :

Resolve-DnsName dc01.entreprise.local

et les services du domaine :

Resolve-DnsName `
  -Type SRV `
  "_ldap._tcp.dc._msdcs.entreprise.local"

On peut également utiliser :

nltest /dsgetdc:entreprise.local

7. Vérifier le compte utilisateur

Avec PowerShell :

Get-ADUser `
  -Identity smartin `
  -Properties Enabled,
              LockedOut,
              PasswordLastSet,
              AccountExpirationDate |
Select-Object Name,
              Enabled,
              LockedOut,
              PasswordLastSet,
              AccountExpirationDate

Tu peux ainsi vérifier plusieurs causes courantes.

8. Compte désactivé

Si le résultat indique :

Enabled : False

le compte est désactivé.

Ne le réactive pas immédiatement sans vérifier pourquoi.

Il peut s’agir :

• d’un départ ;
• d’une suspension ;
• d’une action de sécurité ;
• d’une demande administrative.

9. Compte verrouillé

Si :

LockedOut : True

le compte est verrouillé.

Tu peux également rechercher :

Search-ADAccount -LockedOut

Après vérification de l’identité et de la procédure :

Unlock-ADAccount -Identity smartin

10. Verrouillages répétés

Déverrouiller le compte ne suffit pas si le problème revient immédiatement.

Un ancien mot de passe peut être enregistré dans :

• un téléphone ;
• une connexion Wi-Fi ;
• un lecteur réseau ;
• une application ;
• une tâche planifiée ;
• un service Windows ;
• un autre poste.

Il faut alors rechercher la source des authentifications incorrectes.

11. Vérifier l’expiration du compte

Une date d’expiration peut avoir été configurée.

Get-ADUser `
  -Identity smartin `
  -Properties AccountExpirationDate |
Select-Object Name,AccountExpirationDate

C’est notamment fréquent pour :

• prestataires ;
• stagiaires ;
• comptes temporaires.

12. Vérifier les groupes Active Directory

Pour afficher les groupes d’un utilisateur :

Get-ADPrincipalGroupMembership smartin |
Select-Object Name

Compare le résultat avec les droits attendus pour sa fonction.

Un utilisateur de Comptabilité peut par exemple devoir appartenir à :

GG_COMPTABILITE

13. Vérifier les groupes imbriqués

Dans une architecture AGDLP, l’utilisateur peut ne pas être directement membre du groupe recevant la permission.

Par exemple :

smartin
GG_COMPTABILITE
GDL_COMPTA_MODIF

Il faut donc examiner la structure des groupes et leurs membres.

Get-ADGroupMember "GDL_COMPTA_MODIF"

14. Attention au jeton de sécurité

Lorsqu’un utilisateur ouvre sa session, Windows construit un jeton de sécurité.

Il contient notamment les groupes applicables à la session.

Après une modification de groupe, la session déjà ouverte peut donc ne pas refléter immédiatement le changement.

Pour examiner les groupes présents dans le jeton courant :

whoami /groups

15. AD indique le bon groupe mais l’accès ne change pas

Supposons que :

Get-ADPrincipalGroupMembership smartin

affiche le nouveau groupe, mais :

whoami /groups

ne l’affiche pas.

La session utilisateur peut avoir été ouverte avant le changement.

Selon le contexte, une nouvelle ouverture de session peut être nécessaire.

16. Tester le canal sécurisé du poste

Pour vérifier la relation entre le poste et le domaine :

Test-ComputerSecureChannel

Résultat normal :

True

Un résultat :

False

indique qu’un diagnostic du canal sécurisé est nécessaire.

17. Relation d’approbation défaillante

Un utilisateur peut recevoir un message du type :

« La relation d’approbation entre cette station de travail et le domaine principal a échoué ».

Avant de retirer immédiatement le poste du domaine, vérifie :

• la connectivité ;
• le DNS ;
• l’heure ;
• l’objet ordinateur ;
• le canal sécurisé.

18. Tester l’accès au serveur de fichiers

Si le problème concerne :

\\SRV-FICHIERS\COMPTABILITE

teste d’abord le serveur :

Resolve-DnsName SRV-FICHIERS

puis SMB :

Test-NetConnection `
  SRV-FICHIERS `
  -Port 445

Si TCP 445 n’est pas accessible, le problème ne sera pas résolu en ajoutant des permissions NTFS.

19. Vérifier que le partage existe

Sur le serveur concerné :

Get-SmbShare

Tu dois retrouver le partage attendu.

Par exemple :

Name           Path
----           ----
COMPTABILITE   D:\Partages\Comptabilite

20. Examiner les permissions SMB

Get-SmbShareAccess `
  -Name "COMPTABILITE"

Cette commande permet de vérifier les groupes ou comptes autorisés au niveau du partage.

21. Examiner les permissions NTFS

(Get-Acl `
  "D:\Partages\Comptabilite").Access

Vérifie notamment :

• le groupe concerné ;
• le niveau de permission ;
• le type Allow ou Deny ;
• l’héritage ;
• l’étendue de l’application de la permission.

22. Partage et NTFS doivent être cohérents

Pour un accès réseau, les deux mécanismes interviennent.

Une permission plus large à un niveau ne contourne pas automatiquement une restriction à l’autre.

23. Vérifier les droits effectifs

Un utilisateur peut appartenir à plusieurs groupes et recevoir plusieurs permissions.

Il faut donc raisonner sur les droits effectifs.

Dans l’interface de sécurité avancée de Windows, l’onglet consacré à l’accès effectif permet d’évaluer les droits d’un utilisateur ou groupe sur une ressource.

24. Les refus explicites

Une entrée :

Deny / Refuser

peut expliquer un comportement inattendu.

Les refus explicites doivent être utilisés avec prudence car ils rendent souvent les ACL plus difficiles à analyser.

25. Ne pas modifier les droits au hasard

Face à un accès refusé, évite :

Tout le monde : Contrôle total

Cette modification :

• peut masquer la cause réelle ;
• peut exposer des données ;
• peut violer les règles de sécurité ;
• rend le diagnostic moins fiable.

26. Vérifier les tickets Kerberos

Dans certains diagnostics d’authentification, la commande :

klist

permet d’afficher les tickets Kerberos présents dans la session.

Elle est surtout utile lorsque le diagnostic nécessite d’aller plus loin sur l’authentification de domaine.

Le technicien de proximité doit surtout comprendre qu’un utilisateur authentifié peut disposer de tickets associés à sa session.

27. Vérifier l’heure en cas de problème Kerberos

Si l’authentification de domaine présente un comportement anormal :

w32tm /query /status

permet de contrôler l’état de la synchronisation temporelle.

Vérifie également :

• date ;
• heure ;
• fuseau horaire.

28. Cas : un seul utilisateur est concerné

Si tous les autres utilisateurs accèdent au partage depuis le même poste ou le même réseau, oriente le diagnostic vers :

• le compte ;
• ses groupes ;
• son jeton de sécurité ;
• ses permissions effectives.

La panne générale du serveur devient moins probable.

29. Cas : tous les utilisateurs sont concernés

Si personne n’accède au serveur de fichiers :

les pistes peuvent plutôt concerner :

• le serveur ;
• SMB ;
• le réseau ;
• DNS ;
• le pare-feu ;
• la disponibilité du service.

Ajouter Sophie à un autre groupe ne serait alors probablement pas pertinent.

30. Méthode complète de diagnostic

Face à un incident d’accès Active Directory, utilise cette méthode :

1. Identifier précisément le symptôme.
2. Vérifier l’identité utilisée.
3. Vérifier l’appartenance du poste au domaine.
4. Vérifier réseau et DNS.
5. Vérifier le contrôleur de domaine.
6. Vérifier le compte utilisateur.
7. Vérifier les groupes.
8. Vérifier le jeton de sécurité.
9. Tester le serveur et le port nécessaire.
10. Vérifier le partage.
11. Examiner les permissions SMB.
12. Examiner les permissions NTFS.
13. Identifier la cause.
14. Appliquer la correction minimale nécessaire.
15. Tester avec l’utilisateur.
16. Documenter.

31. Cas pratique – Groupe manquant

Sophie ouvre correctement sa session.

Elle tente d’accéder à :

\\SRV-FICHIERS\COMPTABILITE

et reçoit :

Accès refusé

Le serveur répond et TCP 445 fonctionne.

Les autres membres de Comptabilité accèdent correctement au dossier.

Get-ADPrincipalGroupMembership smartin |
Select-Object Name

32. Cas pratique – Groupe ajouté mais accès toujours refusé

Sophie vient d’être ajoutée à :

GG_COMPTABILITE

Active Directory affiche correctement son appartenance.

Mais sa session existante n’accède toujours pas au partage.

whoami /groups

33. Cas pratique – Tout le service est bloqué

Tous les utilisateurs Comptabilité ne peuvent plus accéder au partage.

34. Cas pratique – Compte verrouillé à répétition

Paul est déverrouillé le matin.

Quelques minutes plus tard, son compte est à nouveau verrouillé.

35. Cas pratique – Canal sécurisé défaillant

Un poste indique :

« La relation d’approbation entre cette station de travail et le domaine principal a échoué. »

La commande :

Test-ComputerSecureChannel

retourne :

False

36. TP – Diagnostiquer un incident d’accès AD

\\SRV-FICHIERS\COMPTABILITE

GG_COMPTABILITE

GDL_COMPTA_MODIF

GDL_COMPTA_MODIF

whoami

Get-CimInstance Win32_ComputerSystem |
Select-Object Name,Domain,PartOfDomain

Get-NetIPConfiguration

nltest /dsgetdc:entreprise.local

Get-ADUser smartin `
  -Properties Enabled,LockedOut

Get-ADPrincipalGroupMembership smartin |
Select-Object Name

Get-ADGroupMember GG_COMPTABILITE

Get-ADGroupMember GDL_COMPTA_MODIF

whoami /groups

Resolve-DnsName SRV-FICHIERS

Test-NetConnection SRV-FICHIERS -Port 445

Get-SmbShare

Get-SmbShareAccess `
  -Name COMPTABILITE

(Get-Acl `
  "D:\Partages\Comptabilite").Access

Quiz – Vérifie tes connaissances