PI Services

Le blog des collaborateurs de PI Services

Azure - Utiliser la localisation GPS avec l'accès conditionnel Azure

L'accès conditionnel d'Azure ou Conditional Access (CA) est un service Azure qui permet d'autoriser les connexions vers des applications ou services Azure selon des conditions tels que la plage IP publique d'accès, le type de device ou le niveau de risque de l'utilisateur. Avec la popularisation des VPN, il est difficile de réellement restreindre les connexions depuis un pays donné. Une fonctionnalité récente sortie en 2021 permet dorénavant de demander les coordonnés GPS d'un utilisateur lorsqu'une CA est configurée.

 

Prérequis pour utiliser la localisation GPS avec l'accès conditionnel Azure

  • Chaque utilisateur qui utilise un accès conditionnel doit avoir une licence Azure AD Premium P1
  • Le compte qui configure l'accès conditionnel doit avoir un de ces rôles : Security Administrator, Conditional Access Administrator ou Global Administrator
  • Les utilisateurs doivent avoir l'application Microsoft Authenticator installée et configurée avec leur compte Azure AD

Créer un emplacement nommé basé sur la localisation GPS

Un emplacement nommé ou name location est un groupement d'IP ou de pays qui sera consommé par une CA pour appliquer une restriction d'accès.

1. Se connecter au tenant Azure AD via le lien portal.azure.com avec le compte qui a les privilèges requis pour configurer une CA

2. Cliquer sur Azure AD > Security > Named locations > + Countries location

3. Dans la blade (fenêtre Azure) qui s'est ouverte :

  • Dans le champs Name choisir un nom à donner à cette named location
  • Dans le deuxième champs dont la valeur par défaut est Determine location by IP address (IPv4 only) choisir Determine location by GPS coordinates

4. Il est possible de cocher l'option Include unknown countries/regions, cela permet d'inclure les plages IP qui n'appartiennent à aucun pays et les IPv6 qui ne sont pas incluses par défaut.

5. Dans cet exemple, on souhaite configurer la named location en France, scroller jusqu'à trouver France et cocher la checkbox associée puis cliquer sur Create

 

Créer un accès conditionnel basé sur la localisation GPS

1. Se connecter au tenant Azure AD via le lien portal.azure.com avec le compte qui a les privilèges requis pour configurer une CA

2. Cliquer sur Azure AD > Security > Conditional Access > Policies > + New policy

3. Dans le champs Name entrer le nom de la CA puis cliquer successivement sur Conditions > Locations > Configure > Include > Selected locations

4. Dans la blade qui est apparue à droite, entrer le nom de la named location précédemment entrée et cocher la checkox associé puis cliquer sur Select

5. Il est ensuite possible d'utiliser les différentes options pour choisir les éléments qui doivent être bloqués, par exemple :

  • Users or workload identites permet de choisir si la CA doit s'appliquer à l'ensemble des utilisateur ou à un groupe d'utilisateur spécifique
  • Cloud apps or actions permet de choisir l'application Azure à conditionner
  • Grant permet de configurer la CA en tant qu'autorisation ou réfutation

6. Une fois les éléments de configuration de la CA choisis, il est possible de la configurer en Report-only pour ne pas qu'elle s'applique réellement, mais pour pouvoir avoir un aperçu de ses effets au travers des Sign-in logs des utilisateurs.

Active Directory - Forcer la restauration DFSR sysvol d'un contrôleur de domaine

SYSVOL est un partage de fichier créé par défaut et partagé entre chaque contrôleur de domaines (DC) dans un Active Directory (AD). DFSR est le mécanisme en charge de la réplication du contenu du SYSVOL entre chaque DC. La santé de la réplication DFSR sysvol est essentielle, car certains services de l'AD en dépendent pour leur fonctionnement, tel que les GPO.

Prérequis pour identifier les problèmes de réplication DFSR sysvol et forcer la restauration

  • Avoir un compte Domain Admin
  • Avoir accès au DC qui a des problèmes de réplications
  • Avoir accès à la commande Dfsrdiag depuis le DC qui a des problèmes de réplications, si la commande n'est pas accessible, elle peut être installée depuis Server Manager > Add Roles and Features > Features > Role Administration Tools > File Services Tools > DFS Management Tools

Identifier les problèmes de réplication DFSR sysvol

Pour les exemples qui vont suivre, le DC2 présente des problèmes de réplications DFSR sysvol depuis le DC1 qui est sain. 

Plusieurs éléments qui ne nécessitent pas d'investiguer des logs peuvent alerter d'un problème de réplication DFSR sysvol :

  • Lorsqu'une GPO créée sur le DC1 n'est pas accessible depuis le DC2, exemple de message d'erreur dans la console Group Policy Management : The system cannot find the file specified.
  • Lorsqu'un fichier est créé dans le SYSVOL du DC1 \\DC1.domain.intern\SYSVOL\domain.intern et qu'il n'est pas répliqué dans le SYSVOL du DC2 \\DC2.domain.intern\SYSVOL\domain.intern
  • Lorsque le nombre de GPO du DC1 \\DC1.domain.intern\SYSVOL\domain.intern\Policies est différent du nombre de GPO du DC2 \\DC2.domain.intern\SYSVOL\domain.intern\Policies

Il est possible d'utiliser la console DFS Management pour faire des tests de réplication, mais ceux-ci ne sont pas assez granulaires.

Depuis le DC qui a des problèmes de réplications, dans une invite de commande PowerShell, la commande Dfsrdiag est utilisée pour avoir un état des lieux du statut des objets en attente de réplication.

PS C:\Windows\system32> Dfsrdiag replicationstate
Summary

  Active inbound connections: 0
  Updates received: 0

  Active outbound connections: 0
  Updates sent out: 0

Operation Succeeded

 

Le résultat de la commande précédente montre une réplication saine. Lorsque des objets sont en attente de réplication, la liste des objets non répliqués s'affiche.
La valeur de Sending member indique le DC (par exemple DC1) depuis lequel le DC actuel (par exemple DC2) essaye de répliquer les objets du SYSVOL.

Le paramètre syncnow de la commande Dfsrdiag peut être utilisé pour tenter de forcer la réplication des objets en attente.

 

Dfsrdiag syncnow /partner:DC1.domain.intern /time:5 /RGName:"Domain System Volume"

#synnow permet de forcer la réplication depuis le DC spécifié après le paramètre /partner. Le Sending member précédent peut être utilisé.

#/time est la durée en minutes pendant laquelle la réplication est forcée. 5 minutes sont choisies, car c'est suffisant pour répliquer une centaine d'objets si la réplication fonctionne.

#/RGName est le nom du partage DFS, pour sysvol il s'agit de Domain System Volume

Suite à cette commande, il faut revérifier le statut de la réplication avec la commande Dfsrdiag replicationstate.

Il est possible de tenter la réplication depuis un partenaire différent ou de laisser plus de temps à la réplication.
Si le nombre d'objets en attente de synchronisation ne varie pas, il faut procéder à une restauration du DFSR sysvol.

 

Forcer la restauration DFSR sysvol d'un contrôleur de domaine

La restauration du DFSR sysvol consiste à faire une synchronisation non authoritative depuis un DC sain. C'est-à-dire que le contenu SYSVOL du DC2 qui a des problèmes de synchronisation sera écrasé par le contenu du SYSVOL du DC1. Les méthodes utilisées précédemment : le fonctionnement par défaut de DFSR et la commande dfsrdiag syncnow tentent de faire des synchronisation avec gestion des conflits, mais certains conflits de versions ne peuvent être résolus par les algorithmes internes.

1. Se connecter au DC2 qui a des problèmes de réplications

2. Ouvrir la console ADSI Edit, faire un clique droit sur ADSI Edit et cliquer sur Connect to..

3. Dans Connection Point choisir Select a well known Naming Context puis choisir Default naming context, dans Computer choisir Select or type a domain or server puis entrer le nom du DC qui a des problèmes de réplication puis cliquer sur OK

4. Déplier les dossiers Default naming context > <Domain> > OU = Domain Controllers > CN=<Nom du DC qui a des problèmes de réplications> > CN =DFSR-LocalSettings > CN = Domain System Volume > faire un clic droit sur CN = SYSVOL Subscription > Properties

5. Dans l'onglet Attribute Editor chercher l'attribut msDFSR-Enabled, faire un clic droit sur cet attribut et changer la valeur de True à False. Cette action à permis de désactiver la réplication DFSR sysvol pour le DC2

6. Depuis le DC2 ouvrir une console PowerShell et entrer la commande

repadmin /syncall /AdP

Cette commande permet de forcer la synchronisation des AD du DC2

7. Depuis le PowerShell du DC2 entrer la commande

Dfsrdiag PollAD

Cette commande permet de récupérer la configuration DFSR sans attendre qu'une réplication AD s'exécute.

8. Il est possible de vérifier que la réplication DFSR a bien été arrêté en consultant l'Event Viewer du DC2 et notamment l'Event ID 4114 dans Applications and Services Logs > DFS Replication

9. Réactiver la synchronisation DFSR sysvol sur le DC2 en suivant les étapes 1 à 5. Cette fois passer la valeur de msDFSR-Enabled de False a True

10. Forcer la réplication AD et DfsrDiag depuis le DC2 avec les commandes des étapes 6 et 7

11. Vérifier le statut de la synchronisation non authoritative DFSR sysvol du DC2 en ouvrant l'Event Viewer depuis le DC2, depuis le dossier Applications and Services Logs > DFS Replication > consulter les logs et notamment la présence de l'Event ID 4614

12. Depuis le DC2 dans une console PowerShell, utiliser la commande Dfsrdiag replicationstate pour vérifier s'il existe toujours des objets non répliqués

13. Faire un test de réplication SYSVOL DFSR en crééant un fichier sur le DC1 (sain) \\DC1.domain.intern\SYSVOL\domain.intern puis se connecter sur le SYSVOL du DC2 (réparé) \\DC2.domain.intern\SYSVOL\domain.intern et vérifier que le fichier est présent

 

Pour aller plus loin

Documentation officielle Microsoft How to force authoritative and non-authoritative synchronization for DFSR-replicated sysvol replication

SQL Server - Récupérer les permissions sysadmin lorsqu'aucun compte sysadmin n'est disponible

Lorsqu'une instance est créé dans un serveur SQL, l'authentification des utilisateurs peut être configurée de 2 façons différentes :

  • Windows Authentication - les comptes de la machine et/ou du domaine AD peuvent être utilisés pour se connecter avec différents niveaux de privilèges
  • Mixed mode - l'authentification Windows ainsi que l'authentification SQL (accès avec des comptes locaux à l'instance) peuvent être utilisé

Lorsque Windows Authentication est choisi, le compte local à l'instance appelé sa qui est membre du groupe sysadmin est désactivé.

sa (system administrator) est un compte utilisateur par défaut local à l'instance SQL dont le mot de passe n'est pas connu

sysadmin est un groupe par défaut local à l'instance SQL dont les membres ont les permissions les plus élevées sur l'instance SQL

 

Dans l'éventualité ou la personne qui a créé l'instance n'est pas disponible et qu'elle n'a pas configuré ou communiqué des accès de secours, par exemple, mixed mode ou ajout d'autres IT en tant que sysadmin, les accès administrateurs à l'instance SQL semblent impossible.

 

Les prérequis pour récupérer les permissions sysadmin

  • Être administrateur du serveur sur lequel le serveur SQL est installé
  • Avoir SQL Server Managmement Studio (SSMS) installé sur le serveur
  • Si l'instance concerne un environnement de production, avertir que lors de la récupération des accès, l'instance SQL sera indisponible

 

Récupérer les permissions sysadmin

1. Se connecter sur le serveur sur lequel le serveur SQL est installé

2. Ouvrir la console SQL Server Configuration Manager

3. Faire un clic droit sur l'instance SQL dont l'accès sysadmin doit être récupéré et cliquer sur Properties

4. Ouvrir l'onglet Startup Parameters, dans Specify a startup parameters saisir -m puis cliquer sur Add, le paramètre -m permet de mettre l'instance SQL en mode maintenance, un utilisateur qui est admin du serveur et qui se connecte à l'instance SQL via SSMS sera, dans ce mode, également sysadmin. Ce mode n'autorise qu'un seul utilisateur à se connecter à la fois.

5. Redémarrer l'instance SQL, dont l'accès sysadmin doit être récupéré, via la console SQL Server Configuration Manager en faisant un clic droit sur l'instance puis choisir Restart

6. Depuis la console SQL Server Configuration Manager, vérifier que le service SQL Server Agent n'est pas démarré, si c'est le cas l'arrêter, auquel cas il utilisera la seule connecxion disponible pour se connecter à l'instance SQL

7. Ouvrir la console SQL Server management Studio en tant qu'administrateur

8. Se connecter à l'instance SQL dont l'accès sysadmin doit être récupéré avec comme méthode d'authentification Windows Authentication

9. Dans l'arborescence de l'instance SQL, déplier le dossier Security puis faire un clic droit sur Logins et clique sur New login...

10. Dans l'onglet General, dans le champs Login name choisir le compte utilisateur ou le groupe qui sera sysadmin, choisir Windows Authentication

11. Aller dans l'onglet Server Roles et cocher sysadmin puis clique sur OK 

12. Le nouvel accès apparaît dans la liste des Login

13. Fermer SSMS

14. Dans SQL Server Configuration Manager retirer le paramètre -m de l'instance SQL dont les accès sysadmin ont été récupéré, en sélectionnant -m et en cliquant sur Remove

15. Depuis la console SQL Server Configuration Manager redémarrer l'instance SQL dont l'accès sysadmin a été récupéré

 

 

PowerShell - créer et déléguer des Administrative Units

Une présentation des Administrative Units (AU) a été réalisée dans l'article suivant : Azure - présentation des Administrative Units

La délégation des Administrative Units en interface graphique a été expliquée dans l'article suivant :  Azure - déléguer les Administrative Units

 

Créer et déléguer des Administrative Units en PowerShell

#Import les modules AzureAD et AzureADPreview qui contient les commandes utilisées pour la création des Administrative Units (AU)
#Si certaines commandes ne sont pas reconnues, assurez vous d'avoir le module à jour avec la commande Update-Module
Import-Module AzureAD
Import-Module AzureADPreview

#Initie une connexion avec AzureAD dans la console PowerShell, un compte avec les droits Global Administrator ou Privileged Role Administrator est nécessaire
Connect-AzureAD

#Création d'une nouvelle AU, la commande est sauvegardé dans une variable car l'objectID doit être utilisé pour la délégation
#Par défaut l'affectation des objets à l'AU sera Assigned, pour faire de l'affectation dynamique utiliser les paramètres MembershipType, MembershipRuleProcessingState et MembershipRule 
New-AzureADMSAdministrativeUnit -Description "Test Administrative Unit created with PowerShell" -DisplayName "AdministrativeUnit-test2"

#Les propriétés de l'AU sont récupérées car l'object ID est nécessaire pour faire l'affectation des droits au groupe de délégation dans PIM
$NewAU = Get-AzureADAdministrativeUnit -Filter "displayname eq 'AdministrativeUnit-test2'"

#Création d'un groupe de délégation qui aura la délégation sur l'AU créée
#C'est un groupe de sécurité, la partie mail est donc désactivé (MailEnabled $False) et la partie sécurité est activé (SecurityEnabled $True)
#Le paramètre MailNickname est obligatoire, il est donc recommandé de rentrer la même valeur que le displayName
#Pour pouvoir affecter des rôles via PIM, il est nécessaire d'activer le paramètre IsAssignableToRole
#Le paramètre Visibility permet de modifier qui est autorisé à voir les membres du groupe, il est recommandé de choisir soit Private soit HiddenMembership
New-AzureADMSGroup -DisplayName "Group-to-manage-AdministrativeUnit-test2" -Description "Group that have the delegation on the AU AdministrativeUnit-test2" `
-MailEnabled $False -MailNickname "Group-to-manage-AdministrativeUnit-test2" -SecurityEnabled $True -IsAssignableToRole $True -Visibility "Private"

#L'affectation des droits au groupe de délégation dans PIM via la commande New-AzureADMSRoleAssignment nécessite l'ID du groupe de délégation
$NewAzureGroup = Get-AzureADGroup -Filter "displayname eq 'Group-to-manage-AdministrativeUnit-test2'"

#L'affectation des droits au groupe de délégation dans PIM via la commande New-AzureADMSRoleAssignment nécessite l'ID du rôle
#Cet ID peut être récupérer depuis portal.azure.com > Azure Active Directory > Administrative Units > {Cliquer sur une AU existante} >
#Roles and admininistrators > {Choisir le rôle a affecté} > Description > Template ID
#Le template ID choisi est celui d'User administrator
$RoleDefinitionID = Get-AzureADMSRoleDefinition -ID "fe930be7-5e62-47db-91af-98c3a49a38b1"

#L'affectation des droits au groupe de délégation dans PIM via la commande New-AzureADMSRoleAssignment nécessite l'ID de l'AU
$DirectoryScopeId = '/administrativeUnits/' + $NewAU.ObjectId

#Création de la délégation PIM du groupe Group-to-manage-AdministrativeUnit-test2 sur l'AU AdministrativeUnit-test2
New-AzureADMSRoleAssignment -DirectoryScopeId $DirectoryScopeId -RoleDefinitionId $RoleDefinitionID.Id -PrincipalId $NewAzureGroup.ObjectId

 

Vérification de la création et de la délégation

L'Administrative Unit a bien été créé

 

Le groupe de délégation ainsi que son affectation dans PIM est effective

 

Remarque : lors de l'installation du module AzureADPreview, celui-ci entre en conflit avec le module AzureAD s'il est déjà installé, lors de l'utilisation de la commande Install-Module, utiliser les paramètres AllowClobber et Force

 

Pour aller plus loin

Documentation officielle de la commande New-AzureADMSAdministrativeUnit
Documentation officielle de la commande Get-AzureADAdministrativeUnit
Documentation officielle de la commande New-AzureADMSGroup
Documentation officielle de la commande Get-AzureADGroup
Documentation officielle de la commande Get-AzureADMSRoleDefinition
Documentation officielle de la commande New-AzureADMSRoleAssignment

Azure - déléguer les Administrative Units

Une présentation des Administrative Units (AU) a été réalisée dans l'article suivant : Azure - présentation des Administrative Units

 

Créer et déléguer une Administrative Unit

Lorsqu'une Administrative Unit est en phase de création, il est proposé de réaliser la délégation via Privileged Identity Management (PIM).

Création d'une Administrative Unit

 

Choix du nom de la nouvelle AU

 

En bas de la blade choisir Next: Assign roles >

Affecter les rôles qui doivent être délégués à des utilisateurs.

Remarque : il n'est pas possible d'affecter des groupes depuis cette blade, néanmoins il est possible de le faire après que l'AU soit créé en l'éditant.

Dans l'exemple suivant, le rôle User Administrator sera affecté

 

Une fois l'affectation faite, finir la création en cliquant sur Next: Review + create >

 

Puis Create

 

L'Administrative Unit créé est alors affiché

 

Déléguer une Administrative Unit à un groupe

Cliquer sur le nom de l'AU précédemment créée, puis sous Manage choisir la blade Roles and administrators et clique sur le rôle a délégué

 

La blade affichée n'est plus la même que lors de la création de l'AU, c'est la blade de délégation PIM qui s'affiche. Cliquer sur Active assignments puis Add assignments

 

Cliquer sur No member selected et choisir le groupe à déléguer

 

Cliquer sur Next

 

Choisir le mode d'affectation, il est recommandé de choisir un Assignment type Active avec une durée d'affectation Permanently assigned étant donné que les AU sont déjà restreintes en termes de périmètre et des opérations disponibles.

 

Clique sur Assign

 

Les affectations sont visibles depuis le sous-menu PIM précédémment évoqué

 

Les délégations des Administrative Units les plus utiles en septembre 2022

 

Besoin Rôle
Réinitialisation de mot de passe Helpdesk administrator (ne permet pas de reset des mots de passes de comptes à privilèges) ou Password administrator
Edition d'utilisateur User administrator
Gestion des methodes d'authentifications utilisateurs (MFA/SSPR) Authentication Administrator (confére également les droits User administrator)
Gestion des groupes Groups administrator
Gestion des ordinateurs Cloud device administrator
Gestion des équipements Teams Teams devices administrator

 

Remarque : il n'est pas possible de créer des utilisateurs directement depuis une AU

Remarque 2 : les autres rôles donnent soient trop de permissions et ne sont pas conseillés, car proche des droits sur tout le tenant soit n'ont aucune répercussion de délégation.

 

Pour aller plus loin

Sur le même blog : PowerShell - créer et déléguer des Administrative Units

Azure - présentation des Administrative Units

Les Administratives Unites (AU) sont similaires aux Organisational Units dans l'Active Directory OnPremises. Ce sont des containers logiques qui permettent de grouper des utilisateurs, des ordinateurs ou des groupes. L'affectation de ces objets peut être faie de 3 manières différentes : assigned, dynamic user et dynamic device. Les Administrative Units sont encore en cours de développement, mais quelques fonctionalités sont d'ores et déjà disponibles.

 

Les prérequis des Administrative Units

Une licence Azure AD Premium P1 est requise pour chaque utilisateur qui administre une AU.
Une licence Azure AD Free est nécessaire pour chaque membre d'une AU.

Dans le cas où une règle d'inclusion dynamique serait utilisée, chaque membre de l'ADU doit avoir une licence Azure AD Premium P1.

Pour pouvoir crééer, modifier ou supprimer des AU, il est nécessaire d'avoir soit le rôle Azure Global Administrator soit Privileged Role Administrator.

 

Accéder aux Administrative Units

Les Administrative Units peuvent être gérer via portal.azure.com > Azure Active Directory > Administrative Units

Depuis cette blade, il est possible de consulter la liste des Administrative Units déjà créés et de les ouvrir pour voir ce qu'elles contiennent. Il est également possible d'en créer de nouvelles avec le bouton Add.

Une fois dans une Administrative Units la blade Users est sélectionnée par défaut, l'ensemble des utilisateurs contenus dans l'AU sont listés au millieu de l'écran. Dans le menu Manage plusieurs blades sont disponibles

La blade Properties permet de choisir le nom de l'AU, sa description et la façon dont les objets sont provisionnés dans l'AU

Les blades Groups et Devices listent respectivement les groupes et les ordinateurs de l'AU.

La blade Roles and administrators permet d'affecter via PIM (Privileged Identity Management) des délégations sur l'AU.

Certains rôles, bien qu'ils puissent être affectés n'ont pas d'incidence sur les délégations des AU.

La blade Dynamic membership rules apparaît si l'affectation des objets à l'AU est dynamique, elle permet de choisir les règles d'inclusions des objets dans l'AU.

 

Pour aller plus loin

Sur le même blog : Azure - déléguer les Administrative Units

Sur le même blog : PowerShell - créer et déléguer des Administrative Units

Windows Server - Collecter des logs de crash applicatifs avec Windows Error Reporting

Windows Error reporting aussi abrégé WER a été introduit depuis Windows Vista et permet de générer un fichier de dump lorsqu'un processus crash. C'est particulièrement utile car tous les processus ne génèrent pas forcément leur propre logs.

 

Identifier le processus fautif

L'identification du processus qui crash se fait à l'aide du gestionnaire d'événement ou event viewer en anglais. Il permet d'accéder à plusieurs informations du crash tel que l'heure et le nom du processus en erreur.

Dans l'exemple suivant, on voit que c'est une défaillance du process lsass.exe qui fait planter la machine et le module responsable du crash de lsass.exe est ntdll.dll

 

Activer la génération de crash dump pour le processus en erreur

  1. Ouvrir l'éditeur de registre regedit sur le serveur qui est concerné par le crash
  2. Naviguer jusqu'à HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
  3. Créer une nouvelle Key qui a comme valeur le nom du processus défaillant, dans notre exemple lsass.exe
  4. Dans la précédente clé, créer un premier DWORD (32-bit)
    1. Name : DumpCount
    2. Valeur : le nombre de crash dump a sauvegarder, par exemple 5
  5. Créer un deuxième DWORD (32-bit) value
    1. Name : DumpType
    2. Valeur : 2 cela permet de générer un full crash dump, celui-ci est le plus complet
  6. Créér une String value
    1. Name : DumpFolder
    2. Valeur : le chemin complet du dossier qu'il faudra créer et qui contiendra les dumps, par exemple c:\temp
  7. Créer un dossier temp dans le disque C:

 

Récupérer le fichier de log et l'analyser

Au prochain crash du processus, un fichier de log sera créé dans le dossier choisi dans la base de registre.

Pour pouvoir lire les fichiers de log, il est nécessaire d'installer un outil tel que WinDbg

 

Supprimer la génération de fichiers de dump

Pour supprimer la génération de log, il faut supprimer la clé précédemment créée dans la base de registre, dans notre exemple cela reviendrait à supprimer la clé lsass.exe

 

Pour aller plus loin

Documentation officielle Microsoft sur l'activation de Windows Error Reporting

Active Directory - Comment exporter la chaîne de certification d'un contrôleur de domaine ?

Certaines applications pour pouvoir voir communiquer à travers des protocoles SSL sécurisés telles que LDAPS (port 636) et GC over SSL (3269) doivent avoir l'ensemble de la chaîne de certification d'un certificat d'un contrôleur de domaine (DC). L'export des certificats de la chaîne de certification ainsi que la constitution du certificat finale peut se faire à travers les outils natifs de Windows Server.

Exporter un certificat depuis la console de certification

L'ensemble des manipulations décrites peuvent se faire à distance depuis la console de certificat, mais dans un souci de clarté, les actions décrites sont réalisés directement depuis un contrôleur de domaine.

Depuis une invite de commande, entrer la commande suivante

certlm #cmdlet qui permet d'ouvrir la console de certificats avec le contexte de l'ordinateur local, donc ici le contrôleur de domaine

 

Déployer le dossier Personal puis Certificates

 

Identifier le certificat qui sert à l'authentification des clients du contrôleur de domaine :

  • La colonne Issued To contient habituellement : le FQDN du contrôleur de domaine
  • La colonne Intended Purposes contient habituellement : Client Authentication, Server Authentication
  • La colonne Certificate Template contient habituellement : Domain Controller

 

Faire un click droit sur le certificat > All Tasks > Export...

 

L'utilitaire d'exportation de certificat se lance, choisir de ne pas exporter la clé privée : No, do not export the private key

 

Choisir un format Base-64 encoded X.509 (.CER)

 

Choisir un dossier de destination dans lequel exporter le certificat



Finir l'export du certificat via l'utilitaire

Le certificat du contrôleur de domaine a été exporté, il faut désormais exporter les autres certificats de la chaîne de certification : le certificat racine et les certificats intermédiaires 

 

Exporter chaque certificat de la chaîne de certification

De retour dans la console certlm, faire un click droit sur le certificat > All Tasks > Export...


 

Ouvrir l'onglet Certification Path, l'ensemble des certificats de la chaîne de certification est listé, le premier de la liste étant le certificat racine, le dernier le certificat du contrôleur de domaine, et les certificats entre les deux sont les certificats intermédiaires.

Cliquer sur le certificat racine puis sur View Certificate, le certificat racine s'affiche alors dans son propre onglet, cliquer sur l'onglet Details puis Copy to File...

Le même utilitaire d'export de certificat s'affiche, compléter l'exporter du certificat racine avec les mêmes options que pour le certificat du contrôleur de domaine en donnant un nom explicite au certificat pour pouvoir le différencier.

Exporter de la même façon l'ensemble des certificats intermédiaires.

 

Assembler les certificats de la chaîne de certification

Une fois l'ensemble des certificats de la chaîne de certification exportés, il faut les assembler dans un seul certificat.

  • Créer un fichier texte et remplacer l'extension .txt par .cer, dans cet exemple, on l'appellera DCCertificateFullChain.cer 
  • Ouvrir le certificat racine avec un éditeur de texte comme Notepad et copier coller le contenu dans le certificat jusqu'alors vide DCCertificateFullChain.cer
  • Dans le fichier DCCertificateFullChain.cer faire un saut de ligne après ----END CERTIFICATE----
  • Ouvrir chaque certificat intemédiaire et les copier coller à la suite du certificat racine dans le fichier DCCertificateFullChain.cer en respectant le saut de ligne
  • Finir par le certificat du contrôleur de domaine

Les certificats doivent se suivre comme suit :

 

Le certificat avec l'ensemble de la chaîne de certification est prêt.

 

Active Directory Federation Services - identifier rapidement la source d'un problème avec ADFS diagnostic analyser

Active Directory Federation Services ou ADFS est un service cœur de tout système d'informations. Les problèmes qui peuvent survenir entraînent la plupart des temps des interruptions de services directement visibles par les utilisateurs finaux. Il est alors essentiel d'identifier et de résoudre la panne au plus vite. ADFS diagnostic analyser est un outil produit par Microsoft qui permet d'analyser très simplement la conformité d'une ferme ADFS.

Installer le module PowerShell ADFSToolbox

ADFSToolbox est un module PowerShell qui permet d'exporter la configuration de serveurs ADFS. Il est conseillé de faire l'installation du module sur un serveur de la ferme ADFS pour s'affranchir des problématiques de communications réseaux. 

L'installation du module se fait via la commande PowerShell suivante :

Install-Module -Name ADFSToolbox -Force


Si la version ciblée d'ADFS est la version 2.1 ou inférieur, il faut utiliser la commande PowerShell suivante :

Install-Module -Name ADFSToolbox -RequiredVersion 1.0.13 -Force 

 

Les versions d'ADFS sont liées à la version de Windows Server de la machine virtuelle, ADFS 2.1 correspond à Windows Server 2012.

Si le module ne peut pas être installé en raison de problème de connectivité internet, l'article suivant explique comment procéder pour contourner cette restriction : Active Directory - Comment installer un module PowerShell sans connexion internet ?

 

Exporter la configuration de serveurs ADFS via le module PowerShell ADFSToolbox

Une fois le module installé, ouvrir une fenêtre PowerShell en tant qu'administrateur avec un compte administrateur du serveur ADFS et entrer la commande :

Import-Module -Name ADFSToolbox -Force #pour les versions ADFS 3.0 et suivantes

Import-Module -Name ADFSToolbox -RequiredVersion 1.0.13 -Force #pour les versions d'ADFS 2.1 et précédentes

Pour exporter la configuration d'un serveur ADFS, enter la commande PowerShell suivante :

Export-AdfsDiagnosticsFile -ServerNames @("adfs1.contoso.com", "adfs2.contoso.com") #remplacer adfs1.contoso.com et adfs2.contoso.com par les FQDN des serveurs ADFS, d'autres serveurs ADFS peuvent être ajoutés en les ajoutant à la suite des parenthèses

Export-AdfsDiagnosticsFile -ServerNames adfs1.contoso.com" #la commande peut être raccourci si on ne souhaite requêter qu'un seul serveur

 

Dans le cas d'un serveur Web Application Proxy ou WAP qui n'est pas joint au domaine Active Directory, entrer la commande PowerShell suivante depuis une fenêtre PowerShell locale au serveur (installation du module comme expliqué précédemment nécessaire) :

Export-AdfsDiagnosticsFile

 

Le fichier généré se trouve dans le dossier C:\Windows\System32 et se nomme AdfsDiagnosticsFile-[DateDuJour] ou [DateDuJour] correspond à l'heure et à la date à laquelle l'export a été réalisé.

 

Analyser l'export de la configuration ADFS avec ADFS diagnostic analyser

L'URL d'ADFS diagnostic analyser est la suivante : adfshelp.microsoft.com/DiagnosticsAnalyzer/UploadFile

Cliquer sur le point 3 - Diagnostic Analyzer > Select (choisissez le fichier AdfsDiagnosticsFile précédemment généré) > Upload a diagnostic file

Plusieurs tests sont effectués, focalisez vous sur les erreurs et notamment celles qui sont simples à résoudre, par exemple une expiration de certificat :

Active Directory - Comment installer un module PowerShell sans connexion internet ?

Pour limiter la surface d'attaque d'un système d'information, il est courant que les serveurs n'aient pas de connexions internet. C'est un problème pour l'installation de modules PowerShell via la commande Install-Module qui va utiliser une URL internet pour télécharger ses sources. Comment peut-on alors faire pour récupérer ces précieux modules ?

 

Les messages d'erreurs type lorsque le serveur n'est pas autorisé à récupérer un module depuis internet

Message d'erreur type pour Install-Module

 

Message d'erreur type pour Get-PSRepository

 

On peut essayer de réinitialiser les paramètres par défaut du répertoire PowerShell avec la commande Register-PSRepository - Default mais une nouvelle saisie de Get-Repository démontre que rien n'a été changé.

 

Il existe également d'autre paramètres pour la commande Register-PSRepository qui nous permettent par exemple de spécifier nous-mêmes les URL de repository PowerShell mais quel que soient les paramètres entrés sans connexion internet la connexion ne sera jamais établie.

 

Sauvegarder le module PowerShell depuis un ordinateur avec une connexion internet

La commande Save-Module permet de sauvegarder un module PowerShell dans un dossier défini.

Un dossier du module téléchargé est alors dans le dossier spécifié.

Le dossier du module PowerShell doit être ensuite copié sur le serveur qui n'a pas de connexion internet. Le dossier cible doit être celui par défaut pour l'installation de module PowerShell ou s'il a été changé ce dernier.

 

Pour trouver les répertoires de modules PowerShell la variable d'environnement $env:PSModulePath peut être utilisé.

 

Habituellement, il est préférable que le module soit disponible à l'ensemble des utilisateur du serveur, le dossier C:\Program Files\WindowsPowerShell\Modules va donc être utilisé comme cible pour la copie du module PowerShell.

 

La commande Import-Module peut ensuite être utilisée pour chargé le nouveau module dans une session PowerShell.