Da durch BIOS-Updates oft schwerwiegende Sicherheitslücken geschlossen werden, gibt es die Anforderung, ein Gerät nur als Compliant zu taggen, wenn eine bestimmte BIOS Version installiert ist. Dies kann derzeit nicht mit den integrierten Funktionen von Intune überprüft werden. Dafür bedienen wir uns einer Custom Compliance-Richtlinie. Zusätzlich können auch weitere Anforderungen an die Compliance des Gerätes geprüft werden, was ich in diesem Beispiel ebenfalls zeigen möchte.
Es gibt natürlich auch Compliance-Richtlinien für andere Betriebssysteme, ich beziehe mich hier aber auf die Möglichkeiten unter Windows.
Dieser Artikel ist im Dezember 2024 mit der zu dem Zeitpunkt aktuellen Intune Version erstellt worden.
Wie funktioniert eine Custom Compliance-Richtlinie?
In den Einstellungen einer Compliance-Richtlinie ist dir sicher schon einmal der Punkt Custom Compliance aufgefallen. Genau diesen benötigen wir. Mit der Custom Compliance-Richtlinie haben wir die Möglichkeit, mittels PowerShell-Script alles Mögliche am Client auswerten zu können, um diese Daten für die Bewertung der Gerätecompliance zu verwenden.
Dafür müssen wir zwei Dateien vorbereiten. Einmal eine PowerShell-Datei, die uns die benötigten Daten direkt auf dem Client ausliest und diese dann an Intune liefert. Die zweite Datei ist eine JSON-Datei, die der Compliance-Richtlinie mitteilt, wie die Compliance zu bewerten ist. Konkret möchte ich in diesem Beispiel die BIOS-Version auslesen und unterhalb einer bestimmten Version das Gerät als NICHT compliant markieren.
PowerShell-Script zur Datenerfassung
Das folgende PowerShell-Script ermittelt die Informationen über das Gerät selbst und die BIOS-Version. Auch habe ich ein Beispiel zur Erkennung von installierter Software eingefügt. So kann man das Gerät als nicht compliant taggen, sofern z.B. die Software Steam installiert ist.
Zusätzlich werden die Informationen über den TPM abgefragt, welche ich in diesem Beispiel aber nicht weiter auswerten werde.
$WMI_ComputerSystem = Get-WMIObject -class Win32_ComputerSystem
$WMI_BIOS = Get-WMIObject -class Win32_BIOS
$TPM = Get-Tpm
#App Detection
$InstalledSoftware = Get-ChildItem "HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall"
if ($InstalledSoftware -like "*Steam*") {
$steam = "Detected"
}
else {
$steam = "Not Detected"
}
$hash = @{ Manufacturer = $WMI_ComputerSystem.Manufacturer; BiosVersion = $WMI_BIOS.SMBIOSBIOSVersion; TPMChipPresent = $TPM.TPMPresent; Steam = $steam}
return $hash | ConvertTo-Json -Compress
Nach dem Abrufen der Informationen wird ein Hash gebildet, der anschließend ins JSON-Format konvertiert wird, um diese Informationen an Intune zu liefern. Die Daten in der $hash Variable sehen dann wie folgt aus:
PS C:\Windows\system32> $hash Name Value ---- ----- TPMChipPresent True Steam Not Detected Manufacturer Dell Inc. BiosVersion 1.17.0
Nach der Konvertierung zu JSON erhalten wir Folgendes:
{"TPMChipPresent":true,"Steam":"Not Detected","Manufacturer":"Dell Inc.","BiosVersion":"1.17.0"}
Anschließend müssen wir das fertige Script im Intune als Compliance Discovery Script hinzufügen. Dies tun wir im Intune admin center unter Home > Endpoint Security > Device Compliance > Scripts > Add > Windows 10 and later
Nachdem wir dem Script einen Namen gegeben haben, können wir den Inhalt der PowerShell-Datei hinzufügen.
Definition der Custom Compliance
Die eigentliche Auswertung der Custom Compliance-Richtlinie wird über ein JSON File definiert. Für dieses Beispiel habe ich folgende Konfiguration erstellt, welche ich nachfolgend erläutern werde:
{
"Rules":[
{
"SettingName":"BiosVersion",
"Operator":"GreaterEquals",
"DataType":"Version",
"Operand":"1.19.0",
"MoreInfoUrl":"https://stabentheiner.de",
"RemediationStrings":[
{
"Language":"en_US",
"Title":"BIOS Version needs to be upgraded to at least 1.19.0. Value discovered was {ActualValue}.",
"Description": "BIOS must be updated. Please refer to the link above"
},
{
"Language":"de_DE",
"Title":"BIOS-Version muss auf mindestens 1.19.0 aktualisiert werden. Der erkannte Wert lautet {ActualValue}.",
"Description": "BIOS muss aktualisiert werden. Bitte beziehen Sie sich auf den obigen Link"
}
]
},
{
"SettingName":"Manufacturer",
"Operator":"IsEquals",
"DataType":"String",
"Operand":"Dell Inc.",
"MoreInfoUrl":"https://stabentheiner.de",
"RemediationStrings":[
{
"Language": "en_US",
"Title": "Only Dell devices are supported.",
"Description": "You are not currently using a Dell device."
},
{
"Language": "de_DE",
"Title": "Nur Dell-Geräte werden unterstützt.",
"Description": "Sie verwenden derzeit kein Dell-Gerät."
}
]
},
{
"SettingName":"Steam",
"Operator":"IsEquals",
"DataType":"String",
"Operand":"Not Detected",
"MoreInfoUrl":"https://stabentheiner.de",
"RemediationStrings":[
{
"Language": "en_US",
"Title": "Unsupported Application Detected",
"Description": "Steam has been detected on your device. Please uninstall this software to meet the compliance requirements."
},
{
"Language": "de_DE",
"Title": "Nicht unterstützte Anwendung erkannt",
"Description": "Steam wurde auf Ihrem Gerät erkannt. Bitte deinstallieren Sie diese Software um die Compliance Anforderungen zu erfüllen."
}
]
}
]
}
Es werden drei Variablen überprüft und dafür wird jeweils eine Regel erstellt. Regeln sind grundsätzlich so aufgebaut, dass zunächst das zu überprüfende Setting per SettingName definiert wird. Für die erste Regel lautet der Wert BiosVersion. Wir erinnern uns: Über das Detection Script wurde eine Variable mit diesem Namen geliefert. Danach habe ich den Operator GreaterEquals gewählt, denn ich möchte nicht nur auf eine genaue Bios Version prüfen, sondern eine Mindestversion voraussetzen. Durch das Setzen des DataType auf Version kann ich so den Operand auf 1.19.0 setzen, und alle BIOS-Versionen, welche mindestens der 1.19.0 entsprechen, würden ein positives Ergebnis zurückmelden. Also auch 1.21.1, jedoch nicht 1.9.0, da diese kleiner ist. Hätte man den DataType auf String gesetzt, ginge das nicht.
Die MoreInfoUrl kann dafür genutzt werden, um dem User eine Information bereitzustellen, wie er z.B. sein BIOS updaten kann, damit da Gerät wieder Compliant ist.
Zuletzt kann über die RemediationStrings eine Information an den User zurückgegeben werden, sofern die Prüfung negativ ausfällt. Man kann zusätzlich mehrere Sprachen definieren, sollte man Betriebssysteme mit unterschiedlichen Sprachen im Unternehmen einsetzen.
Was die zweite und dritte Regel macht, sollte nun selbsterklärend sein.
Anlegen der Custom Compliance-Richtlinie
Jetzt kann die eigentliche Compliance-Richtlinie angelegt werden. Diese erstellen wir unter Devices > Compliance > Create Policy
Wir geben der Policy einen zur gewählten Namensgebung passenden Namen und wechseln in den Konfigurationsblock Custom Compliance.
Dort wählen wir das Discovery Script aus und laden anschließend die eben erstellte JSON-Datei mit den Compliance-Settings hoch.
Abschließend wählen wir noch den Scope aus. Ich habe in diesem Fall All Devices gewählt, aber zusätzlich einen Filter für das Gerätemodell ausgewählt, bei dem ich genau diese Compliance Version prüfen möchte und diesen per Include einbezogen.
Die Actions for noncompliance sind individuell wie bei allen Compliance-Richtlinien zu wählen.
Auswertung der Compliance-Richtlinie
Schauen wir uns nun die Auswertung der Richtlinie an. In diesem Beispiel ist erst einer der Rechner als Compliant markiert. Dieser hat bereits die geforderte Version 1.19.0 installiert. Die Geräte, welche als Not compliant markiert sind, haben noch eine ältere BIOS-Version installiert. Und alle Geräte, welche im Status Not applicable stehen haben, entsprechen nicht dem Filter für die Modellnummer.
Die Version in der JSON-Datei kann so nach jedem BIOS-Release angepasst werden, um die BIOS-Version als Voraussetzung für einen positiven Compliance-Status zu verwenden.
Praxistipps
Eine Compliance-Richtlinie mit verschiedenen Prüfungen in nur einer Policy zu verpacken, wird in der Praxis eher nicht so gut funktionieren. Ich würde die Prüfung auf die BIOS Version in eine eigene Policy packen, um flexibler mit der Zuweisung zu sein und bei einer Änderung an zum Beispiel der App Detection nicht mehrere Policys anpassen zu müssen. Deshalb gilt es immer zu prüfen, welche Punkte in welcher Policy geprüft werden sollen.
