Besoin :
On ne peut pas identifier simplement les noms de groupes qui sont membres du groupe local "Administrateurs" sur une machine joint à l'Azure AD.
Si on fait Windows+R et on tape "lusrmgr.msc" pour afficher les utilisateurs et groupes locaux d'une machine, on souhaite par exemple afficher les membres du groupe Administrateurs, on n'aura pas les noms des groupes membres mais plutôt leurs SID.
Ces SID doivent être convertis en GUID pour pouvoir chercher les noms des groupes dans Azure AD.
Solution :
J'ai utilisé ce script PowerShell pour convertir le SID en GUID :
function Convert-AzureAdSidToObjectId {
<#
.SYNOPSIS
Convert a Azure AD SID to Object ID
.DESCRIPTION
Converts an Azure AD SID to Object ID.
Author: Oliver Kieselbach (oliverkieselbach.com)
The script is provided "AS IS" with no warranties.
.PARAMETER ObjectID
The SID to convert
#>
param([String] $Sid)
$text = $sid.Replace('S-1-12-1-', '')
$array = [UInt32[]]$text.Split('-')
$bytes = New-Object 'Byte[]' 16
[Buffer]::BlockCopy($array, 0, $bytes, 0, 16)
[Guid]$guid = $bytes
return $guid
}
$sid = "S-1-12-1-1943430372-1249052806-2496021943-3034400218"
$objectId = Convert-AzureAdSidToObjectId -Sid $sid
Write-Output $objectId
# Output:
# Guid
# ----
# 73d664e4-0886-4a73-b745-c694da45ddb4
N.B : Il faut renseigner le SID dans la variable $sid pour que le script retourne son GUID
Besoin :
On souhaite identifier le SID d'un groupe Azure AD mais l'attribut n'existe pas.
Solution :
J'ai utilisé ce script PowerShell pour convertir le GUID en SID :
function Convert-AzureAdObjectIdToSid {
<#
.SYNOPSIS
Convert an Azure AD Object ID to SID
.DESCRIPTION
Converts an Azure AD Object ID to a SID.
Author: Oliver Kieselbach (oliverkieselbach.com)
The script is provided "AS IS" with no warranties.
.PARAMETER ObjectID
The Object ID to convert
#>
param([String] $ObjectId)
$bytes = [Guid]::Parse($ObjectId).ToByteArray()
$array = New-Object 'UInt32[]' 4
[Buffer]::BlockCopy($bytes, 0, $array, 0, 16)
$sid = "S-1-12-1-$array".Replace(' ', '-')
return $sid
}
$objectId = "73d664e4-0886-4a73-b745-c694da45ddb4"
$sid = Convert-AzureAdObjectIdToSid -ObjectId $objectId
Write-Output $sid
# Output:
# S-1-12-1-1943430372-1249052806-2496021943-3034400218
N.B : il faut renseigner le GUID dans la variable $objectId pour que le script retourne son SID
Scénario:
Créer un groupe d'appreils dynamique dans Azure AD qui regroupe les ordinateurs qui sont gérés par Intune ou Co-managed (Mode de gestion hybride: MECM+INTUNE).
Solution:
Dans Azure AD, créer un groupe d'appareils dynamique en utilisant une règle d'appartenance dynamique basée sur la propriété Mobile Device Management Type.
Dans la configuration de la règle, nous devons sélectionner la propriété deviceManagementAppId.
En tant que valeur, il faut renseigner l'un des identifiants ci-dessous :
- 54b943f8-d761-4f8d-951e-9cea1846db5a pour Co-managed
- 0000000a-0000-0000-c000-000000000000 pour Intune
Exemple:
Ceci est un exemple de configuration d'une règle dynamique pour un groupe d'appareils Co-managed:
Selon l'opérateur que vous préférez, vous devez entrer l'intégralité de l'ID ou pouvez utiliser une partie de l'ID.
Pour afficher le bouton SSPR (Self-Service Password reset) sur l'écran d'ouverture de session Windows 10, il faut ajouter la clé de registre ci-dessous manuellement ou via GPO (sous réserve d'avoir SSPR déjà activé pour l'utilisateur et l'ordinateurs est joint à Azure AD en mode Hybride) :
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AzureADAccount]
"AllowPasswordReset"=dword:00000001
Dans certains cas, même après l'ajout de cette clé de registre, le bouton SSPR ne s'affiche pas sur l'écran d'ouverture de session.
En regardant sur Azure AD, l'état de la machine qui n'a pas fonctionné, nous avons constaté qu'elle est bien Hybrid Azure AD Joined mais le statut d'enregistrement est en Pending
Afin de résoudre ce problème, il faut forcer l'enregistrement de la machine à Azure AD en ajoutant les deux valeurs de la clé de registre ci-dessous :
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD]
"TenantId"="<YourTenantId>"
"TenantName"="<YourCompany.com>"
Une fois ajoutés, redémarrez l'ordinateur et il sera enregistré dans Azure AD.
Sur l'écran d'ouverture de session, le bouton SSPR doit maintenant s'afficher.
Contexte
La synchronisation entre l’Active Directory et Office 365 est un sujet extrêmement sensible dans un environnement de production. Une mauvaise configuration peut entrainer la suppression de nombreux objets dans le cloud (comptes, groupes…).
Le domaine enfant de mon domaine Active Directory a été décoché dans la configuration de mon connecteur dans la console Synchronization Service Manager.
Figure 1 – Propriétés du connecteur
Lorsque l’on coche à nouveau le domaine enfant et que l’on relance une synchronisation, le domaine enfant n’est pas resynchronisé.
Solution
Lors de la suppression du domaine enfant, les étapes de synchronisation associées sont supprimées.
On remarque en allant dans Configure Run Profiles… sur le connecteur qu’il n’y a qu’une seule étape qui correspond au domaine parent.
Figure 2 – Profil du connecteur pour le Full Import avec une seule étape (domaine parent)
Il est donc nécessaire de recréer les étapes pour le domaine enfant. Pour cela il est recommandé de lancer l’outil de configuration d’Azure AD Connect.
Une fois l’outil de configuration terminée, les étapes pour le domaine enfant sont de nouveaux en place.
Figure 3 – Profil du connecteur pour le Full Import avec deux étapes (domaine parent et domaine enfant)
Il est ensuite nécessaire de relancer dans l’ordre :
- Full Import – Connecteur Active Directory
- Full Synchronisation – Connecteur Active Directory
- Export – Connecteur Active Directory
- Delta Import – Connecteur Office 365 (domaine.onmicrosoft.com)
- Delta Synchronisation – Connecteur Office 365 (domaine.onmicrosoft.com)
- Export – Connecteur Office 365 (domaine.onmicrosoft.com)