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 :

Si vous n'avez pas lu la première partie de l'article, je vous conseille de la lire avant de modifier vos stratégies d'expiration de mot de passe.

Les paramètres d'expiration et d'avertissement peuvent être modifiant en utilisant le lien dans le portail Web d'administration de Microsoft : https://admin.microsoft.com/Adminportal/Home#/settings/security

Pour modifier les paramètres, il suffit de cliquer sur modifier à droite.

Dans la première partie nous avons :

• Installer LAPS sur le poste de management
• Etendue le schéma de l'annuaire AD
• Déléguer le droit d'enregistrer le mot de passe dans l'annuaire au compte de l'ordinateur
• Déléguer le droit de lire le mot de passe à un compte spécifique de l'équipe support.

Dans cette seconde partie, nous allons :

Dans la gestion quotidienne des comptes de l'annuaire Active Directory, il n'est pas recommandé d'utiliser systématiquement des comptes membre de « Admins du domaine ». Il est possible de déléguer ces opérations à des groupes d'utilisateurs spécifiques. Vous pouvez par exemple, limiter le droit de réinitialiser le mot de passe à une partie de l'équipe IT, vous pouvez également déléguer le droit de remplir certaines informations comme la fonction ou le service de l'utilisateur à l'équipe RH.

Dans un article précédent, j'avais présenté l'option d'authentification unique (SSO) ainsi que l'option d'authentification directe qui évite la synchronisation du mot de passe dans Azure (Pass Through Authentication) de Azure AD Connect. Si vous utilisez l'option d'authentification directe, un connecteur est installé sur le serveur ou se trouve Azure AD Connect et ce dernier va faire le lien. En cas de panne de ce service, les utilisateurs ne pourront plus s'authentifier dans Azure et Office 365.

Microsoft lance sa solution de gestion de l'impression depuis le cloud Azure en Preview. La solution vous permet de vous affranchir de déployer une solution d'impression On-Premise.

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.

Cette semaine, Active Directory a fêté ses 20 ans, tout comme Windows server 2000.

Windows 2000 sorti le 17/02/2000 a vu le remplacement des anciens domaines NT, par un annuaire compatible LDAP prenant en charge les protocoles d'authentification Kerberos.

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.

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 :

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

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.

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