Si vous souhaitez migrer, votre application de synchronisation  Azure AD Connect vers un nouveau serveur, une méthode simple consiste à installer l'outil sur le nouveau serveur en mode préproduction. Le mode de préproduction configure les éléments de la synchronisation, mais les données ne sont pas réellement copiées d'un vers l'autre. Vous pouvez suivre les étapes suivantes :

La gestion des comptes locaux des postes de travail membre du domaine peut s'avérer délicate. Il peut arriver de devoir utiliser un compte local avec des droits d'administrations sur l'ordinateur. Mais la gestion du mot de passe de ce compte présent sur l'ensemble des postes peut poser un problème. Il existe une solution gratuite proposée par Microsoft permettant de gérer des mots de passe uniques pour un compte spécifique sur l'ensemble des postes membres du domaine : Microsoft Local Administrator Password Solution (LAPS).

Il y a quelques années j'avais écrit sur un article sur la gestion des utilisateurs et groupe locaux à l'aide des GPO. Je vous présente ici, une autre méthode qui existe depuis 2008 et qui utilise les préférences dans les stratégies de groupes. L'objectif est d'ajouter un groupe spécifique en tant qu'administrateurs des postes de travail, afin d'éviter d'utiliser des mots de passe de comptes administrateurs du domaine sur les postes.

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.

À 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.

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.

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.

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.

À 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.

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 ».

Lors de l'installation d'un contrôleur de domaine dans un environnement existant ou dans une nouvelle forêt vous devez disposer de droits spécifiques en fonction de votre déploiement. Le tableau suivant, décrit les droits minimums requis pour effectuer l'opération.

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).

Si vous utilisez de nombreux postes et serveurs, le processus d'activation de la licence Windows peut être contraignant. Si vous disposez de licence en volume vous pouvez utiliser les services d'activation en volume et une clé KMS. Il existe deux méthodes pour l'utilisation de ce type de clé de licence. La première date de Windows Server 2008 et de Windows Vista. Elle consiste à installer un serveur de licence KMS (KMS : clé d'activation multiple). Les postes clients trouvent le serveur de licence en utilisant la résolution DNS et envoient une demande d'activation.

À la suite d'une question sur les forums Technet, j'ai ressorti un de mes scripts pour l'améliorer et le mettre à disposition sur les Gallery :

https://gallery.technet.microsoft.com/Get-FolderSizeps1-036f331a?redir=0

Je pense que nous utilisons tous des outils comme Treesize ou WindirStat. Ces outils sont bien pratiques rapide et facile d'emploi.