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.
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 ».
À 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.
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.
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 ».
Il est assez simple de créer une fonction qui ajoute dans un groupe tous les membres d'un autre groupe. La fonction ci-dessous permet de faire cette opération simplement, avec très peu de lignes.
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.
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.
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.
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.
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.
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.
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 :
À 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.
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 :
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éé.
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.
Ce nouveau livre sur les services de domaine Active Directory, vous permettra de vous familiariser avec le module PowerShell sur les opérations que nous effectuons régulièrement.
Le contenu du livre vous permettra de tester les différentes commandes et scripts proposés au fil de la lecture.
Jusqu'au chapitre 5, vous apprendrez à utiliser des commandes PowerShell simple. A partir du chapitre 6, les commandes que vous allez découvrir sont proposés sous forme de fonction ou de script, afin de vous familiariser avec l'automatisation de tâche avec PowerShell.
Dans l'article précédent nous avons vu comment créer une application Web hébergeant un site Drupal 8. Dans cet article, nous allons nous connecter en FTP sécurisé sur les fichiers de notre application.
Pour cela, la première étape va être de créer un compte FTP dans Azure pour notre application. Nous allons ouvrir le portail Azure, sélectionner le groupe de ressource contenant l'application, puis notre application, qui port le nom de « dr-pbarth ».
Dans cet article nous allons voir comment créer une application Web basé sur Drupal 8.
Nous vérons dans la deuxième partie, comment définir un nom de domaine personnalisé pour l'accès depuis un navigateur. Nous avons déjà pu voir dans l'article précédent comment créer une zone DNS dans Azure et assurer la résolution de nom sur Internet : [Azure DNS Zone] Créer une Zone DNS avec PowerShell
Dans l'article précédent nous avons vu comment créer une zone DNS sur Azure à travers le portail de gestion. Dans cet exemple nous allons créer une nouvelle zone DNS en utilisant PowerShell installé localement sur le poste.
Nous ouvrons une fenêtre PowerShell en tant qu'administrateur du poste.
Si le module AzureRM n'est pas installé sur votre poste, il suffit de saisir la commande pour l'installer :
Vous avez la possibilité dans votre abonnement Azure de créer une zone DNS personnalisé comme domaine principal ou comme sous domaine de votre domaine public.
Dans cet article nous allons montrer comment mettre en place une zone DNS pour un sous-domaine de notre domaine principal.
La mise en place est très rapide et se fait en deux étapes :
Création de la zone DNS dans les services Azure
Déclaration des serveurs DNS pour le nom de domaine chez votre hébergeur
Cette rubrique présentera différents articles sur les services Cloud proposé par Microsoft.
Si vous ne connaissez pas Azure, il s'agit d'un ensemble de services à la carte permettant à une entreprise d'offrir des services et des outils performants à ses collaborateurs.
Il peut arriver que l'on se retrouve avec des fichiers partagés verrouillés par certains utilisateurs après que le document se soit mal refermé.
Il est possible de voir les fichiers ouverts depuis la console « Gestion de l'ordinateur ». Néanmoins la liste peut être longue et il peut être difficile de retrouver un élément précis.
La commande PowerShell « Get-SmbOpenFile », permet de lister les fichiers ouverts. LA commande ci-dessous listera tous les fichiers ouverts par des utilisateurs dont le nom contient les lettres « pba ».
Il est possible d'installer des packs de langue supplémentaire dans Windows et de modifier l'affichage par défaut. Vous avez sans doute déjà ajouté un clavier supplémentaire ? Si vous utilisez une machine virtuelle sur Azure, comme dans cet exemple, la langue par défaut est l'anglais. Il est possible d'afficher l'ensemble des menus et de l'environnement dans une autre langue, comme par exemple le français.
Dans les propriétés de langue après avoir ajouté le clavier français, cliquez sur « options » à droite.
Si vous utilisez une forêt multi-domaines vous comprendrez sans doute l'intérêt d'interroger le catalogue global. Lorsque vous exécutez une commande comme « Get-ADUser » en spécifiant un contrôleur de domaine mais sans préciser le port de destination, vous allez interroger le port ldap par défaut (389). Il est possible d'interroger le catalogue global en précisant le port « 3268 ». Dans l'exemple, ci-dessous nous recherchons un compte d'abord sur la partition d'annuaire ensuite dans le catalogue global. Nous sélectionnons deux attributs distincts (SamAccountName et AccountExpirest).
Il existe des attributs Active Directory qui ne sont pas répliqués entre les contrôleurs de domaine. Pour les objets utilisateurs, on retrouve notamment les attributs suivants :