PI Services

Le blog des collaborateurs de PI Services

Intune : Intégration manuelle du Hash ID avec le mode Online

Besoin :

Intégrer manuellement le Hash ID d'un device Autopilot dans Intune sans passer par la clé USB et le fichier csv.

 

Solution :

Ceci est possible en utilisant le mode Online du script PowerShell "Get-WindowsAutopilotInfo.ps1".

Une fois Windows est démarré et que vous êtes sur la page OOBE (Out Of the Box Experience) et connectés à Internet, il faut taper Shift + F10 pour ouvrir l'invite de commande ensuite dérouler les commandes PowerShell suivantes :

> Powershell

> Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -force

> Install-Script Get-WindowsAutopilotInfo

    --> Choisir Yes  pour confirmer l'installation du script

> Get-WindowsAutopilotInfo.ps1 -Online -Assign -GroupTag "CompanyGroupTag"

    --> Quand invité à se connecter à Intune,  utilisez un compte d'administration ayant le droit d'import de device Autopilot

 

Active directory : problème d'authentification par smartcard

Un de nos clients utilise des cartes à puce pour s'authentifier sur les postes de travail et depuis quelques mois, un problème apparemment aléatoire se produit : lorsque certaines cartes sont associées à certains comptes Active Directory, l'authentification ne fonctionne pas (erreur "invalid credentials" lors d'une tentative d'ouverture de session Windows).

Les mêmes cartes associées à d'autres comptes ne posent cependant aucun problème, et réciproquement.

La seule autre indication dont nous disposons au moment de commencer les investigations est un évènement 4771 généré dans le journal Security des contrôleurs de domaine. Il indique une erreur 0x42, qui se traduit par KRB_ERR_CERTIFICATE_MISMATCH (et non pas KRB_AP_ERR_USER_TO_USER_REQUIRED comme une première recherche nous l'avait fait penser, nous entraînant sur une fausse piste!)

Dernière information pertinente : les certificats présents sur ces cartes à puce ne contiennent pas l'UPN du compte qui les utilise pour ouvrir une session. Il s'agit de certificats génériques, fournis par une entité tierce.

Il est donc nécessaire de peupler la propriété LDAP altSecurityIdentities pour lier le compte Active Directory d'un utilisateur à une smartcard.

Première vérification évidente : les comptes utilisateurs contiennent bien une référence au certificat présent dans la smartcard dans cette propriété altSecurityIdentities.

Il s'agit plus précisément de leur propriété RFC822, autrement dit un identifiant au format adresse email.

L'erreur "Certificate Mismatch" ne semble donc pas être pertinente ici, mais une nouvelle recherche permet de trouver une note récente de Microsoft ( https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-winerrata/85d75079-92de-47e6-a1c1-7e4fd7f27a10 ) qui indique que depuis la mise à jour mensuelle de Mai 2022, les informations utilisées pour remplir la propriété altSecurityIdentities sont divisées en deux catégories "forte" et "faible"; que l'adresse RFC822 fait partie des "faibles" et que lors de l'utilisation d'une information "faible", l'erreur Certificate Mismatch "peut" être présente.

On progresse donc, mais il nous reste à comprendre quelles sont les conditions exactes pour obtenir cette erreur puisque par ailleurs la majorité des comptes fonctionne avec la majorité des cartes à puce sans problème, en utilisant le même identifiant RFC822 "faible".

Un nouvel événement (id 40 dans le journal System des contrôleurs de domaine) nous met la puce à l'oreille :

The Key Distribution Center (KDC) encountered a user certificate that was valid but could not be mapped to a user in a strong way (such as via explicit mapping, key trust mapping, or a SID). The certificate also predated the user it mapped to, so it was rejected

Il confirme clairement ce dont nous nous doutions déjà, à savoir que le certificat est valide mais pas associé au compte AD de façon sûre.

Mais il indique également un élément supplémentaire : s'il a été rejeté, c'est parce qu'en plus la date d'émission du certificat est antérieure à la date de création du compte.

Il s’agit d’un blocage destiné à permettre l’évolution progressive de la configuration de vos altSecurityIdentities : en effet, Microsoft indique que toutes les authentifications par certificat lié par une association « faible » échouera à partir de Mai 2023 (cf. KB5014754: Certificate-based authentication changes on Windows domain controllers - Microsoft Support ), et ce blocage permet donc d’éviter de créer des associations qui poseront problème après quelques mois seulement.

Deux solutions sont alors disponibles : 

· Regénérer le certificat de façon à ce qu’il contienne l’extension SID (introduite également lors de la mise à jour de Mai 2022), mais cette solution ne fonctionne que pour les certificats signés par une PKI Microsoft et dont les informations sont récupérées dans l’AD et non pas fournies dans la requête

· Changer les altSecurityIdentities de façon à établir une association forte.

Dans notre contexte, seule la seconde solution est possible puisque les certificats sont fournis par une entité tierce. 

Le format recommandé par Microsoft pour établir une liaison forte est le suivant : X509:<I>IssuerName<SR>1234567890

Il contient le nom de l’autorité de certification (au format Distinguished Name) ainsi que le numéro de série du certificat.

Attention : ces deux informations doivent être indiquées « à l’envers ». Par exemple, si le DN de l’autorité émettrice est CN=CONTOSO-DC-CA, DC=contoso, DC=com et le numéro de série du certificat est 2B 3C F4, alors le champ altSecurityIdentities doit contenir la chaine suivante : X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>F43C2B

Une fois cette modification effectuée, la connexion à l’aide de la smartcard fonctionne enfin !

PowerBI - Coloration conditionnel - Exemple avancé

Derrière le terme un peu technique "Coloration conditionnel" se cache simplement le fait, dans un dashboard PowerBI d'afficher un changement de couleur dans le champ d'un tableau, en fonction de condition.

En plus des fonctions natives de mise en forme dans PowerBI Desktop, il est possible de creer une mesure (code DAX) , avec des conditions, que l'on va utiliser pour afficher une valeur dans un champ. Et cette valeur peut etre un code couleur.

Dans l'exemple du code ci-dessous, on a une application "MyApp" pour laquelle, dans PowerBI nous avons trois datasets (deux correspondrait par exemple a deux tables de la base de donnée associée a "MyApp", et un troisième qui est une connexion vers un outil qui reference la criticité de mes machines (ex: outil de gestion des asset ou cmdb)):

- MyAppAgents, qui contiens des infos sur les agents de mon application

MyAppVersions, qui contiens un historique des numeros de version de mon application

-  MyServers qui est donc la table qui liste la criticité des mes serveurs.

Objectif: On veux dans un dashboard, colorer un champ en rouge ou jaune (exemple, le nom du serveur), pour lequel la version ((MyAppAgents[MyApp_agent_version]) serai differente de la dernière version, ET dont le serveur serait un serveur de Production ou de test.

 

Color_MyApp_agent = 

   VAR Result1 = SELECTEDVALUE(MyAppAgents[MyApp_agent_version])
   VAR Result2 = SELECTEDVALUE(MyAppVersions[MyApp_Last_version_available])
   VAR Result3 = SELECTEDVALUE(MyServers[Server_Criticity])

-- SI MyApp_agent EST DIFFERENT DE MyApp_Last_version_available ET SI Server_Criticity = "PROD" alors on renvoi "CRITICAL"
   VAR Critical = IF(AND(Result1<>Result2, Result3="PROD"),"CRITICAL")
   
-- SI MyApp_agent EST DIFFERENT DE MyApp_Last_version_available ET SI Server_Criticity <> "TEST" alors on renvoi "WARNING"  
   VAR Warning = IF(AND(Result1<>Result2, Result3<>"TEST"),"WARNING")
   
-- SI MyApp_agent EST EGALE A MyApp_Last_version_available   
   VAR OK = IF(Result1=Result2,"OK")

   
 -- SELON LE CAS ON RENVOI UN CODE COULEUR DIFFERENT
RETURN
SWITCH(
True(),
 Critical="CRITICAL" , "#FEA19E",
Warning="WARNING" , "#F9FF28",
 OK="OK" , "#96FF93" 
)

 

On crée donc une mesure (measure) dans laquelle on va coller le code ci-dessus

Apres validation la mesure apparait dans le dataset ou elle a été crée

On selectionne ensuite le champ que l'on veut colorer puis Conditional formatting/Background color

 

On selectionne Format by "Field Value", et on va venir selectionner notre mesure (Color_MyApp_agent)

 

Apres validation, Les valeurs de la colonne seront formatée selon la condition rencontrée (Les code couleurs '#FEA19E' peuvent bien sur etre modifié dans le code pour choisir une autre coloration):