[AD PowerShell] Déplacement des rôles FSMO

J'avais écrit il y a pas mal de temps un article sur le déplacement des rôles FSMO depuis les consoles Active Directory : http://www.pbarth.fr/node/79 .

Dans cet article nous allons voir comment déplacer rapidement l'ensemble des rôles FSMO avec PowerShell.

Les premières commandes que nous allons voir, permettent de déterminer les serveurs qui disposent des rôles actuellement.

Pour déterminer les serveurs qui disposent des rôles FSMO du domaine vous pouvez utiliser la commande :

[Azure AD] Domaine personnalisé

 

Dans Azure Active Directory, vous disposez d'au moins d'un répertoire par défaut contenant des utilisateurs, des groupes et d'autres objets Active Directory. Chacun de ses répertoires dispose par défaut d'un nom de domaine en mondomaine.OnMicrosoft.com. Il est possible de créer des répertoires supplémentaires pour un même compte.

Vous avez la possibilité d'ajouter un nom de domaine personnalisé, que vous pourrez utiliser en tant qu'identifiant d'utilisateur afin de faire correspondre l'identifiant avec l'adresse email par exemple.

[ Azure Cloud] Gérer son environnement

Il existe plusieurs solutions permettant de gérer son environnement Azure, que ce soit pour créer des VMs ou pour gérer Azure Active Directory. La première solution est le portail Web azure disponible à l'adresse https://portal.azure.com/#home.

Une autre solution est l'utilisation de l'application Windows que vous pourrez installer sur votre poste de travail. Vous pourrez télécharger l'application avec le lien suivant :

https://preview.portal.azure.com/app/welcome

[Azure AD] Groupe dynamique

 

Si vous disposez d'une licence Azure AD P1 ou P2, incluse dans les offres EMS E3 ou E5, vous pouvez profiter de l'utilisation de groupes dynamiques. Un groupe dynamique est un groupe de sécurité ou un groupe Office 365, dont les membres sont le résultat d'une requête sur les attributs de vos utilisateurs.

Pour configurer un groupe dynamique, ouvrez les propriétés du groupe, et sélectionnez le type d'appartenance :

[Azure AD PowerShell] Créer un utilisateur

Si vous n'utilisez pas Azure AD Connect pour synchroniser vos comptes depuis votre domaine local, vous pouvez créer les comptes directement dans l'interface de gestion d'Azure Active Directory. Il est également possible de le faire par script comme par exemple avec PowerShell. Pour cela il vous faudra installer le module PowerShell AzureAD. Vous pouvez également utiliser le module propre à MSOnLine.

[Azure AD PowerShell] Installer et mettre à jour le module Azure AD

Dans l'article suivant nous avons parlé de la gestion des comptes Office 365, stocké dans Azure AD avec PowerShell. Nous avons pour cela installé le module MSOnline. Il existe un autre module permettant de gérer Azure Active Directory et non lié à Office 365 : le module Azure AD.

La commande suivante permet de voir si le module AzureAD est déjà installé et la version que vous disposez :

[Azure Active Directory] Premium P1 et P2

 

Azure Active Directory est une solution de gestion d'identité d'authentification hébergée dans le cloud. Azure Active Directory est également fortement liée à Office 365, puisque ce dernier l'utilise pour la gestion des utilisateurs. Comme nous l'avons vu dans cette série d'articles il est possible de synchroniser, les comptes de son domaine Active Directory Domain Services avec Azure à l'aide d'AAD Connect .

 

[News] Fin du support de Windows 7 et Windows server 2008

 

Le support des produits Windows 7 et Windows Serveur 2008/ 2008R2 a pris fin le 14/01/2020.

Pour ceux qui utilisent encore ces anciennes versions, il n'y aura désormais plus de mise à jour mensuelle y compris pour les correctifs de sécurité.

 

https://support.microsoft.com/fr-fr/help/4057281/windows-7-support-ended-on-january-14-2020

Bonne année 2020 !

 

Un petit mot pour vous souhaiter une bonne année 2020 pour vous et vos familles !

D'après les statistiques de Google Analytics en 2019, vous avez consulté 316448 pages sur ce site, soit 70000 de plus qu'en 2018 !

 

[AD DS Securité] Désactiver SMB 1.0 (partie 3)

Si votre parc ne dispose pas d'OS antérieur à Windows Vista/ Windows Server 2008, vous pouvez envisager de désactiver SMB 1.0. Nous avons vu dans l'article précédent comment activer l'audit des demandes de connexions avec SMB 1.0, ce qui vous permettra de vérifier si des postes utilisent encore ce protocole obsolète. Dans cet article nous allons voir, comment modifier la configuration sur un ou l'ensemble de vos serveurs pour ne plus accepter de connexion SMB1.0.

[AD DS Sécurité] Auditer l’utilisation de SMB V1 (Partie 2)

Si vous n'avez pas lu l'article précédent sur SMB et le partage des fichiers, je vous renvoie sur le lien suivant.

Si vous souhaitez désactiver SMB 1 et si vous ne savez pas s'il est encore utilisé dans votre environnement, il est possible d'activer un audit de de ce protocole avant d'essayer de le désactiver.

Pour rappel, vous pouvez vérifier depuis un poste client les connexions et la version du protocole utilisé avec la commande : « Get-SMBConnection ». Dans l'image ci-dessous « 3.1.1 ».

[AD DS Securité] Partage de fichier et protocole SMB (Partie 1 )

À la suite de questions sur la compatibilité entre les OS anciens et récent dans un domaine AD, je vais essayer de résumer quelques informations utiles sur les protocoles de partage de fichiers (SMB). Dans un domaine Active Directory nous avons aux minimums deux partages présents sur tous les contrôleurs de domaine (en bonne santé) : « NetLogon » et « Sysvol ». Ces partages mettent à disposition des postes membres du domaine, les scripts et les paramètres de stratégie de groupes. Les protocoles d'accès aux partages de fichiers chez Microsoft sont assez anciens et ont évolué avec le temps.

[News] Kit de déploiement ADK Windows 10 1909

 

Avec la sortie de Windows 10 1909, Microsoft n'a pas publié de nouvelle version du kit de déploiement (ADK). Microsoft recommande d'utiliser la version pour 1903 :

Extrait :

A Windows ADK for Windows 10, version 1909 will not be released. You can use the Windows ADK for Windows 10, version 1903 to deploy Windows 10, version 1909.

Source :

[PowerShell] Obtenir des informations sur un ordinateur à distance

Dans l'article précédent nous avions vu comment activer la gestion à distance de Windows (WinRM) à l'aide des stratégies de groupe. Cette option vous permet entre autres d'exécuter à distance des commandes PowerShell sur des ordinateurs spécifiques. Une commande PowerShell intéressante est « Get-ComputerInfo ».

[GPO] Activer la gestion à distance (WinRM)

Il est possible que vous souhaitiez gérer et exécuter des commandes PowerShell à distance sur des postes de travail ou des serveurs membres. Les commandes PowerShell Invoke-Command et Enter-PSSession peuvent vous aider à condition que les postes cibles acceptent la gestion à distance.

Pour cela il est possible d'utiliser une stratégie de groupe, afin de configurer et démarrer le service WinRM (Windows Remote Management). Dans cette stratégie vous devrez configurer les éléments suivants.

[AD DS Sécurité] BitLocker et stockage des clés de récupération dans l’AD

 

Il est possible d'utiliser le cryptage BitLocker pour protéger par exemple, les postes nomades. Cela limite le risque de vol de données en cas de perte ou de vol du matériel.

Par défaut, BitLocker voudra utiliser un module sécurisé (TPM), sinon l'option ne sera pas disponible, comme dans l'image ci-dessous. Il est possible de modifier cette limitation avec les stratégies de l'ordinateur.

 

[RSAT] Outil d’administration de serveur distant pour Windows 10

L'article suivant http://www.pbarth.fr/node/100, expliqué comment installer les outils d'administration à distance de serveurs (RSAT). Il fallait télécharger le programme d'installation correspondant à votre version, avec par exemple le lien suivant https://www.microsoft.com/fr-FR/download/details.aspx?id=45520. Vous constaterez que les outils s'arrêtent à la version Windows 10 1803. A partir de la version 1809 la méthode d'installation est différente.

[AD DS Sécurité] Principe de l’authentification Kerberos

 

Dans un article précédent, nous avons expliqué de manière simplifiée le principe de l'authentification NTLm . Nous allons dans cet article tenté d'expliquer le principe de fonctionnement de Kerberos. L'authentification Kerberos est assurée par le centre de distribution de clés (KDC) des contrôleurs de domaine Active Directory.

Tags: 

[AD DS Sécurité] NTLM et niveau d’authentification Lan Manager

Dans un environnement Windows, il existe deux familles de protocoles d'authentifications natives permettant de gérer l'accès aux ressources. Les protocoles Lan Manager, NTLM et Kerberos. L'apparition du protocole LanManager remonte aux années 80, il y a presque 40 ans. Il est très ancien et très vulnérable. NTLM son successeur est apparu quelque temps après et la version actuel NTLMv2 date de Windows NT4 SP4. Kerberos est le protocole par défaut dans les domaines Active Directory.

[AD DS Sécurité] Le groupe « Protected User »

Avec Windows Server 2012 R2, un nouveau groupe a été rajouté dans Active Directory : « Protected Users ».

 

Le groupe « Protected User » permet de réduire les risques liés aux comptes d'administration. L'ajout d'un compte dans ce groupe va modifier certains comportements. Dans cet exemple, nous verrons quelques éléments de protection liés à ce groupe.

Tags: 

[AD DS Sécurité] L’objet « AdminSDHolder»

Dans un domaine Active Directory il existe un objet particulier qui sert de référence pour protéger les informations de sécurité de certains comptes à fort privilège. L'objet en question est « AdminSDHolder » et il est présent dans chaque domaine dans le conteneur « System ».

L'objet « AdminSDHolder » permet de protéger les informations de sécurité des comptes membres des groupes suivants :

[AD DS Sécurité] Introduction

 

À la suite de différents échanges et demande par mail ou autres, j'ai décidé d'ajouter une nouvelle rubrique concernant la sécurité et les bonnes pratiques sur l'administration d'un environnement Active Directory.

C'est un des deux sujets, que je souhaite élargir dans les prochains mois, avec la partie Azure.

[Azure Domain Services] Partie 3 : un aperçu rapide

 

Nous avons vu dans les articles précédents, comment créer un environnement Azure Domain Services, qui permet de disposer d'un domaine Active Directory classique :

[Azure Domain Services] Partie 1 : création du domaine

[Azure Domain Services] Partie 2 : serveur d'administration

[Azure Domain Services] Partie 2 : serveur d’administration

 

Dans la première partie nous avons déployé Azure AD Domain Services. Nous allons maintenant créer une machine virtuelle sous Windows 2019 dans Azure et installer les consoles d'administrations classiques des services de domaine Active Directory.

Pour rappel, nous avons créé un sous réseau virtuel « 10.0.1.0/24 ». Dans notre groupe de ressource « LabAzureADDS » contenant l'ensemble de notre environnement, nous allons sélectionner le réseau virtuel que nous avons créé.

Tags: 

[Azure Domain Services] Partie 1 : création du domaine

Dans l'article précédent :  « [AD DS / Azure AD / Azure AD DS] Comprendre les différences », j'ai essayé d'expliquer de manière succincte les différences entre Azure Active Directory et Azure Domain Services (Azure AD DS). La première qui est du type Software As A Service, on pourrait même dire « IDdentity As A Service », vous permet de gérer des utilisateurs, des équipements, des groupes, des applications, au travers d'une interface dédiée à ce but, sans vous préoccuper de la gestion de serveurs, d'OS ou autres considérations.

Tags: 

Pages

S'abonner à Philippe BARTH RSS