Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

ADFS – L’authentification WIA échoue avec l’erreur 0xc000035b

Lorsqu’une ferme ADFS est exposée sur Internet ou à des réseaux externes à l’entreprise, il est courant de déployer en frontal des serveurs reverse proxy (service WAP natif ou services tiers comme F5 BigIP ou Kemp Loadmaster) :

Dans ce cas, il est également relativement fréquent d’utiliser un certificat différent sur les équipements positionnés en frontal/DMZ de celui utilisé sur les serveurs de la ferme ADFS, en particulier lorsqu’il s’agit d’un certificat public.
Cette configuration peut néanmoins entrer en conflit avec la fonctionnalité Extended Protection for Authentication (EPA) lors d’une authentification intégrée Windows (WIA), puisqu’elle traite le reverse proxy/load balancer frontal comme une attaque Man in the Middle lorsque ce dernier ne dispose pas du même certificat.

Ce problème peut être un peu difficile à identifier au premier abord puisque coté client, le seul symptôme visible est un échec de l’authentification. Coté serveur ADFS on retrouve par contre l’évènement suivant dans le journal Sécurité :

Audit Failure
ID : 4625
Failure reason : an error occured during logon
Status : 0xc000035b

Deux options s’offrent alors à nous pour résoudre le problème :
– Utiliser le même certificat SSL à la fois en DMZ et sur les serveurs de la ferme ADFS
– Désactiver la protection à l’aide de la commande powershell Set-ADFSProperties -ExtendedProtectionTokenCheck None

Set-AdfsSslCertificate échoue avec une erreur « Access is denied »

Lors d’une récente intervention chez un client, j’ai été amené à modifier le certificat externe d’une ferme ADFS.
Cette manipulation se fait normalement très simplement via l’import du certificat dans le magasin Personnel de chaque serveur de la ferme puis l’exécution de la commande Set-AdfsSslCertificate -Thumbprint XXXXXXXXXXXXXXXXXXXX mais j’ai cette fois ci rencontré un message d’erreur bizarre :

PS0317: One or more of AD FS servers returned errors during execution of command 'Set-AdfsSslCertificate'. Error information: PS0316: AD FS Server:
'localhost', Error: 'Connecting to remote server localhost failed with the following error message : Access is denied. For more information, see the about_Remote_Troubleshooting Help topic.'.

L’invite de commande était pourtant bien ouverte en mode administrateur, localement sur le noeud primaire de la ferme ADFS et avec un compte du domaine disposant des permissions d’administrateur local et d’administrateur ADFS.

Après quelques recherches, il s’avère que c’est la présence de ce compte dans le groupe Active Directory Protected Users qui cause ce problème, probablement parce que « localhost » n’est pas un nom DNS ni un SPN valide pour une authentification Kerberos à laquelle les membres de Protected Users sont soumis.

Il aurait été possible de sortir temporairement l’utilisateur de ce groupe mais cela aurait entrainé une dégradation temporaire de la posture de sécurité ainsi qu’une alerte auprès du SOC; la solution qui a donc finalement été retenue à été l’utilisation du compte administrateur local géré par LAPS pour exécuter cette commande, cette fois sans encombre.

Sécuriser votre PC – Secure Boot 2023 : Script de collecte et conformité (Mise à jour)

Cet article fait suite au guide :
« Sécuriser votre PC – Guide étape par étape pour la mise à jour des certificats Secure Boot 2023 – Partie 1 ».

Dans cette mise à jour, nous ajoutons un script PowerShell de collecte permettant d’évaluer automatiquement la conformité d’un poste Windows avant (ou après) la mise à jour des certificats Secure Boot 2023.

Ce script est particulièrement utile dans des contextes Intune / MECM / scripts de conformité.

Objectif du script :

Le script permet de déterminer si une machine est conforme concernant Secure Boot 2023, en vérifiant :

  • l’activation de Secure Boot,
  • la présence du certificat Windows UEFI CA 2023,
  • l’état des clés Secure Boot côté registre,
  • la présence de l’événement TPM ID 1808,
  • les informations BIOS (fabricant / version).

Il retourne :

  • un résultat JSON exploitable,
  • un code de sortie compatible avec les règles de conformité (0 = conforme, 1 = non conforme).

Script PowerShell de collecte Secure Boot 2023 :

$IsCompliant = $true
$FailureReason = @()

# STEP 1: Secure Boot
try {
    if (-not (Confirm-SecureBootUEFI)) {
        $IsCompliant = $false
        $FailureReason += "SecureBootDisabled"
    }
}
catch {
    $IsCompliant = $false
    $FailureReason += "LegacyBIOS"
}

# STEP 2: Secure Boot CA 2023
$SBCA2023 = "NOTPresent"
try {
    $db = Get-SecureBootUEFI -Name db -ErrorAction Stop
    $dbText = [System.Text.Encoding]::ASCII.GetString($db.Bytes)
    if ($dbText -match "Windows UEFI CA 2023") {
        $SBCA2023 = "Present"
    }
}
catch {}

if ($SBCA2023 -ne "Present") {
    $IsCompliant = $false
    $FailureReason += "SBCA2023Missing"
}

# STEP 3: Registry
$regPath = "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing"
$UEFIStatus = "UNKNOWN"
$UEFICapableMeaning = "Unknown"
$UEFIError = "NotPresent"
$UEFIErrorEvent = "NotPresent"

if (Test-Path $regPath) {
    $props = Get-ItemProperty $regPath -ErrorAction SilentlyContinue
    $UEFIStatus = $props.UEFICA2023Status
    $UEFIError = $props.UEFICA2023Error
    $UEFIErrorEvent = $props.UEFICA2023ErrorEvent

    switch ([int]$props.WindowsUEFICA2023Capable) {
        0 { $UEFICapableMeaning = "CA2023NOTInDB" }
        1 { $UEFICapableMeaning = "CA2023InDB" }
        2 { $UEFICapableMeaning = "BootedWith2023" }
    }
}

if ($UEFIStatus -ne "Updated") {
    $IsCompliant = $false
    $FailureReason += "UEFICA2023NotUpdated"
}

# STEP 4: TPM Event 1808
$Event1808 = "NotPresent"
$event = Get-WinEvent -FilterHashtable @{LogName='System'; ID=1808} -MaxEvents 1 -ErrorAction SilentlyContinue
if ($event) {
    $Event1808 = "Present"
} else {
    $IsCompliant = $false
    $FailureReason += "TPM1808Missing"
}

# STEP 5: BIOS
$BIOSVersion = (Get-CimInstance Win32_BIOS).SMBIOSBIOSVersion
$BIOSMan = (Get-CimInstance Win32_BIOS).Manufacturer

# FINAL OUTPUT (IMPORTANT)
$result = [PSCustomObject]@{
    Compliance                   = $IsCompliant
    SBCA2023                     = $SBCA2023
    UEFICA2023Status             = $UEFIStatus
    TPMEvent1808                 = $Event1808
    WindowsUEFICA2023Capable     = $UEFICapableMeaning
    UEFICA2023Error              = $UEFIError
    UEFICA2023ErrorEvent         = $UEFIErrorEvent
    BIOSVersion                  = $BIOSVersion
    BIOSMan                      = $BIOSMan
    FailureReason                = ($FailureReason -join ",")
}

$result | ConvertTo-Json -Compress

if ($IsCompliant) { exit 0 } else { exit 1 }

Ce script peut être utilisé :

  • comme script de détection Intune,
  • dans MECM (baseline),
  • en exécution locale pour audit.

Conclusion :

Cette mise à jour complète la Partie 1 en apportant un outil concret de collecte et de conformité, indispensable pour préparer les environnements à l’échéance Secure Boot 2026.

Une prochaine mise à jour pourra couvrir :

  • l’automatisation du déploiement,
  • l’intégration Intune / MECM,
  • la remédiation automatique.