mercredi 10 juillet 2019

Gestion des accès privilégiés et Active Directory sous Windows 2016

Introduction:


Parmi les nouvelles fonctionnalités proposées par l'active directory sous Windows 2016 : il y a la possibilité d’ajouter un membre à un groupe active directory pour une durée bien déterminée. 
Pour activer cette fonctionnalité, il  faut que tous les contrôleurs de domaine de la forêt soient installés sous Windows 2016 ou plus et le niveau fonctionnel  de la forêt soit Windows 2016 :



Niveau fonctionnel Windows 2016:

Pour pouvoir augmenter le niveau fonctionnel vers Windows 2016 , il faut que tous les contrôleurs de domaine de la forêt soient installés sous Windows 2016 et le niveau fonctionnel des domaines enfants soit Windows 2016.
Pour savoir comment augmenter un niveau fonctionnel veuillez consulter ce lien : Le niveau fonctionnel FFL/DFL.
Une fois que le niveau fonctionnel de la forêt est égal à Windows 2016, une nouvelle fonctionnalité sera ajoutée avec la corbeille s’appelant : Privileged Access Management Feature :

Get-ADOptionalFeature -Filter *

L'activation de la fonctionnalité Privileged Access Management :

L’activation de la fonctionnalité Privileged Access Management permet d’ajouter un objet active directory dans un groupe pour une durée bien déterminée.
L'activation de cette fonctionnalité modifie la partition Configuration de l'active directory. Si vous avez besoin de faire un retour en arrière pour désactiver cette fonctionnalité, il faut restaurer toute la forêt. 
Pour activer cette fonctionnalité , il suffit de lancer la commande ci-dessous avec un compte membre du groupe enterprise Admins :

Enable-ADOptionalFeature -Identity  "Priviliged Access Management Feature" –scope ForestOrConfigurationSet –Target "Lab.lan"

Pour vérifier l’activation, lancer la commande suivante:

Get-ADOptional –Filter *
et vérifier que EnabledScope n’est pas vide dans les propriétés de Priviliged Access Management:


Une fois que la vérification de l’activation est terminée, maintenant nous sommes capable d’ajouter un membre d'un groupe active directory pour une durée bien déterminée.

Ajouter un utilisateur dans la liste des membres d'un groupe temporairement:


Pour ajouter un objet active directory dans un groupe pour une durée bien déterminée , vous pouvez n'utilisez que les commandes Powershell:

Add-ADGroupMember -Identity "domain Admins" -Members "test" -MemberTimeToLive (New-TimeSpan -minutes 30)
Si l'audit est activé sur les modifications des objets active, vous allez trouver un évènement d'ID 5169 et source Microsoft Windows security généré dans le journal d'évènement après chaque ajout d'un objet dans un groupe temporairement:



La commande ci-dessous permet d’afficher les membres temporaires d’un groupe:

Get-ADGroup "Domain Admins" -Properties member -ShowMemberTimeToLive



La durée de vie d'un ticket Kerberos :


Si un utilisateur essaie d'accéder à une ressource via l'authentification kerberos, le ticket kerberos qui inclus par défaut tous les SIDs des groupes de l'utilisateur .
Si, un utilisateur est configuré comme membre à un groupe temporairement pour une durée inférieur à la valeur de la durée de vie configurée par défaut pour un ticket kerberos, le nouveau ticket Kerberos sera expiré quand l'utilisateur ne sera plus membre de ce groupe.
Si l'utilisateur appartient pour une durée limitée à plusieurs groupes la durée minimale sera la durée du vie du ticket kerberos.

Dans l’exemple ci-dessous, on va vérifier la durée de vie du ticket kerberos avant et après  l’ajout d’un utilisateur LAB\test dans deux groupes  temporairement.
Dans la figure ci-dessous, on constate bien que la durée de vie du ticket kerberos est égale à 10 heures :


Maintenant, nous allons ajouter l’utilisateur LAB\test dans le groupe Domain Admins pour une durée de 30 minutes et dans le groupe Entreprises Admins pour une durée de 20 minutes:

 Add-ADGroupMember -Identity "domain Admins" -Members "test" -MemberTimeToLive (New-TimeSpan -minutes 30)
 Add-ADGroupMember -Identity "Entreprise Admins" -Members "test" -MemberTimeToLive (New-TimeSpan -minutes 20)
Add-ADGroupMember -Identity "Entreprise Admins" -Members "test" -MemberTimeToLive (New-TimeSpan -minutes 20)


La commande ci-dessous permet d’afficher la liste des groupes de l’utilisateur LAB\test :

 whoami /groups

Pour supprimer les tickets kerberos de l'utilisateur dans le cache nous lançons la commande suivante:

klist purge

Nous exécutons la commande ci-dessous pour afficher les nouveaux tickets kerberos TGT :

klist

La figure ci-dessous, montre bien que la durée de vie du ticket kerberos ne dépasse pas 20 minutes.

Quelques recommandations:

  • Contrôler régulièrement la liste des groupes avec pouvoir dans l'active directory: un utilisateur ajouté temporairement dans un groupe domain Admins par exemple , est capable de créer un autre utilisateur et de l'ajouter dans ce groupe et garder les privilèges Domain Admins
  • Avec l'authentification NTLM, il n'y a pas la notion du TTL, pour cela il est recommandé de demander à l'utilisateur de fermer sa session s'il n'est plus membre d'un groupe 
  • Avant d'activer cette fonctionnalité , il faut s'assurer que tous les domaines de la forêt sont bien sauvegardés. Si vous désirez désactiver cette fonctionnalité il faut restaurer toute la forêt comme la corbeille active directory. 

lundi 29 octobre 2018

Les nouveautés de l'active directory sous Windows 2019

Microsoft a annoncé officiellement la sortie de Windows 2019 depuis le 2 Octobre 2019.
Concernant l'active directory jusqu'à présent, je n'ai trouvé aucun article officiel de la part de Microsoft parlant sur les nouveautés  de l'active directory sous Windows 2019.
Dans cet article, nous allons partager quelques informations et quelques nouveautés de l'active directory, en se basant sur les tests que nous avons réalisés dans notre environnement de test et quelques informations publiées sur des Blog publiques.

La mise à jour du schémas:

La mise à jour du schéma est une étape indispensable qui doit être lancée avant la promotion du premier contrôleur de domaine sous Windows 2019 avec un compte membre des groupes suivants:

  • Administrateurs du schéma
  • Administrateurs de l'entreprise
  • Domain Admin du domaine root

Windows 2019 a gardé les mêmes méthodes utilisées depuis l'arrivé du Windows 2012 pour la préparation de la forêt et la mise à jour du schéma. Pour avoir plus de détails veuillez consulter le lien suivant:
 Préparer une forêt et un domaine pour l'installation du premier contrôleur de domaine sous Windows 2016

Après la préparation de la forêt pour la promotion du premier contrôleur du domaine sous Windows 2019,voici les changement constatés:

  •  Un nouveau attribut nommé msDS-preferredDataLocation est créé et attaché à tous les objets utilisateurs, groupes et contacts.  
  • La nouvelle version du schéma est 88:





Les nouveautés du niveau fonctionnel FFL et DFL:

Le niveau fonctionnel Windows 2019:

Dans les tests que nous avons effectués avec les premières versions de Windows 2019 publiées par Microsoft, nous avons constaté que le niveau fonctionnel le plus élevé proposé par Windows 2019 est Windows Server 2016  :


Donc, jusqu'à présent nous ne pouvons pas empêcher la promotion des contrôleurs de domaine sous Windows 2016, vue que même après la sortie du Windows 2019 le niveau fonctionnel le plus élevé est toujours Windows 2016 en attendant les prochaines mises à jour qui peuvent apporter du nouveau à propos de ce sujet.

Le niveau fonctionnel requis pour la promotion du premier contrôleur de domaine sous Windows 2019:

Les contrôleurs de domaine sous Windows 2019 supportent que les niveaux fonctionnels  Windows 2008 ou plus:



Par conséquence, pour pouvoir promouvoir le premier contrôleur de domaine sous Windows 2019 dans une forêt existante, il faut rétrograder tous les contrôleurs de domaine sous Windows 2003 ensuite augmenter le niveau fonctionnel du domaine et de la forêt vers Windows 2008 ou plus.
Le lien ci-dessous, vous explique comment augmenter le niveau fonctionnel:
Le niveau fonctionnel FFL/DFL

Les nouveautés au niveau de la réplication SYSVOL:


Pour la réplication du répertoire SYSVOL, les contrôleurs de domaine sous Windows 2019 ne supportent pas le système de réplication de fichier FRS :



Si un domaine utilise encore FRS pour la réplication SYSVOL, dans ce cas il faut le migrer  pour utiliser DFS pour pouvoir ajouter le premier contrôleur de domaine sous Windows 2019.
Le lien ci-dessous explique les étapes de cette migration:
How to migrate the SYSVOL replication system from FRS to DFS-R

Les nouveautés au niveau du déploiement:

Au niveau déploiement,la seule différence avec la version Windows 2016 est au niveau prérequis. Dans cette partie nous allons expliquer ce point avec plus de détails.

Prérequis:

Comme expliqué ci-dessus, pour ajouter le premier contrôleur de domaine sous Windows 2019, il faut préparer les prérequis suivants:


  • Le niveau fonctionnel de la forêt soit Windows 2008 ou plus
  • DFS soit utilisé pour le réplication SYSVOL

Les méthodes de promotion supportées:

Il est possible de promouvoir un contrôleur de domaine sous Windows 2019 via l'interface graphique ou Powershell. Ce sont les mêmes procédures utilisées avec Windows 2016:
Déployer le premier contrôleur de domaine sous Windows 2016

La mise à niveau sur place (Upgrade In-place):

L'upgrade In-place des contrôleurs de domaine est possible à partir du Windows 2012 comme l'explique ce lien : Mise à niveau sur place d'un contrôleur de domaine.
Pour Windows 2019, l'Upgrade in-place est supporté depuis un contrôleur de domaine Windows 2016.
Avant de lancer l'upgrade in-place, il faut préparer les prérequis suivants:

  • Le niveau fonctionnel de la forêt soit Windows 2008 ou plus
  • Le système de réplication SYSVOL est DFS
  • La préparation de la forêt et du domaine est lancé manuellement via la commande adprep.

Conclusion:

Windows 2019 n'a pas apporté beaucoup de nouveauté par rapport à Windows 2016.
Ce que nous pouvons remarquer est que les contrôleurs de domaine Windows 2019 et Windows 2003 ne peuvent pas cohabiter dans la même forêt.

vendredi 17 août 2018

How-to create passoword policy through GPO

The password policy define the criteria to enhance the security of user password.

In this topic, I will shows you how we can apply password policy through GPO.

To apply a password policy on domain user accounts, there are two methods: Group Policy Object  and Password Settings Object.

How-to apply a passwor policy on domain user accounts through GPO: 

By default, the password policy settings defined on the defaut GPO Default Domain Policy are applied on all domain user accounts.



The Default Domain Policy GPO is the only GPO that can enforce a password policy on domain accounts. therefore, we can only apply one password policy per domain via GPO for domain user accounts.
If you need to create many password policy in the same domain, you have to create Password Settings object available when the domain functional level is Windows 2008 or higher.

How-to apply a password policy on local user accounts:

Concerning the local users accounts, we can apply the password policy through domain GPO:

Just create a new GPO with the password policy settings, attach it to the organizational unit of the machines in question.

It is also possible to use the local GPO via the gpedit.msc tool to set and enforce a password policy settings on local accounts.


Comment appliquer une stratégie du mot de passe via GPO

La stratégie de mot de passe permet de définir des critères pour renforcer la sécurité des mots de passe des utilisateurs.

Dans cet article nous allons expliquer comment créer et appliquer une stratégie de mot de passe via GPO qui répond aux critères et aux exigences de la sécurité.

Gérer la stratégie de mot de passe des comptes utilisateurs du domaine:

Pour appliquer une stratégie de mot de passe sur les comptes utilisateurs du domaine, il existe deux méthodes : soit par GPO ou bien PSO.

Appliquer la stratégie de mot de passe sur les utilisateurs de domaine via GPO:

Par défaut, tous les utilisateurs du domaine subissent la stratégie du mot de passe définie dans la GPO Default Domain Policy:




la GPO Default Domain Policy est la seule GPO capable d'appliquer une stratégie de mot passe sur les comptes du domaine. Par conséquence, nous ne pouvons appliquer qu'une seule stratégie de mot de passe par domaine via GPO.
Pour créer plusieurs stratégies de mot de passe ,il faut utiliser PSO (Password Settings Object) qui ne sont disponible que dans les domaines ayant un niveau fonctionnel du domaine Windows 2008 ou plus.

Gérer la stratégie de mot de passe des comptes locaux:    

Pour les comptes locaux, la stratégie de mot de passe  peut être appliqués via GPO:

Il suffit de créer une nouvelle GPO avec les paramètres de stratégie de mot de passe ,l'attacher à l’unité d'organisation des machines en question.
Il est également possible utiliser la GPO local via l'outil gpedit.msc pour définir et appliquer une stratégie de mot de passe sur les comptes locaux.



jeudi 9 août 2018

How to migrate certification authority to new server


In this topic , we will explain step by step how to migrate certification Authority to another server.
 In our example we will try to migrate CA server installed on Windows 2008 R2 to new server under Windows 2016:

Backup certification authority:

  • The CA backup can be performed through the CA wizard:

  • Click on next to continue:



  • On this page check the two options and spécify the path of backup then click Next:


  • A new password is required to access on backup files:

  • Click on finish:

  • On backup path, we find all backed up files:



Export registry keys :

Export registry keys from this path HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration:


Remove CA role from old server:

To be able to reuse the name of old server , you have to remove the CA role before rename it.
  • From server manager, you can perform the CA uninstalling:

  • Click on remove:


  • Restart the server to finish:


Now you can rename the old server.

Install new server with the same name as old server and restore CA certificate and database:

Install the role certification autority on new server then start the AD CS configuration:
  • Specify the credentials then click on Next:


  • Select Certification Authority role then click on NEXT:


  • Specify the Type of the CA then click  on NEXT:



  • Select the type of CA then click NEXT:



  • Select the option Use existing private key:



  • Click on Import:



  • Specify the existing Certificate:



  • Select on Certificate and click on NEXT:



  • Add the database locations then select NEXT:


  • Click on confirmation:



  • Click on close:



  • Open CA console then click on Restore:



  • Click on NEXT:



  • Specify the path and select the 2 items to restore:



  • Specify the password:



Once you complete database restoration , you can restore registry keys backed up from the old Server.



mardi 1 mai 2018

How to migrate the SYSVOL replication system from FRS to DFS-R

Since Windows Server 2008,  DFS-R can be used for SYSVOL replication instead of FRS.
A domain controller on Windows Server 2019 is no longer compatible  with FRS for SYSVOL replication.
If you still use FRS for SYSVOL replication, you have to migrate to DFS-R to be able to add an additional domain controller on Windows Server 2019.
If the first domain controller is promoted on Windows 2008 or higher and the Domain functional level is Windows 2008 or higher  , DFS-R will be automatically used for SYSVOL replication.
In this article, I will show you how to migrate SYSVOL replication system from FRS to DFS.

Prepare prerequisites:

  • All domain controller running on Windows Server 2003 must be demoted 
  • The Domain Functional Level must be 2008 or higher :



  • Check the replication status and domain controllers health:

        

  • Check the DFSR migration status, you can use the following command:
    dfsrmig /getglobalstate

Before starting the migration, you can check the current sysvol path by running the  command net share on each domain controller:


You can also check the SYSVOL path from registry key:


How to migrate SYSVOL replication system to DFS-R:

  • Run the following command to start the migration:
dfsrmig /setglobalstate 0
  • Run the following command to change the migration state from "Started" to "Prepared" on all domain controller:

dfsrmig /setglobalstate 1


During in this step a new folder named SYSVOL_DFSR will be created on all domain controllers:


Run the following command to check if all domain controllers are migrated to "Prepared" state before performing the next step:

dfsrmig /getglobalstate
  • Run the following command to change the migration state from "Prepared" to "Redirected":

dfsrmig /setglobalstate 2

During in this step, it is recommended to avoid any modification on sysvol share ( GPO,script..ect) because the SYSVOL folder will be moved to  SYSVOL_DFSR.We can check it from the registry key value once the domain controller status become "Redirected":

We can also use net share to check the new path of sysvol share:

Run the following command to check if all domain controllers are migrated to "Redirected" state before performing the next step:

dfsrmig /getglobalstate
  • Run the followings command to change migration state from "Redirected" to "Eliminated":
dfsrmig /setglobalstate 3
 

In this step , the old folder sysvol will be deleted:

The Ntfrs service will be also disabled  on all domain controllers:


Run the following command to check if all domain controller are migrated to "Eliminated" state:

dfsrmig /Getglobalstate