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.

Der Beitrag Intune – Custom Compliance-Policy erschien zuerst auf M365 Blog - Julian Stabentheiner.

CKT ist die aktuell letzte Ausbaustufe der Single-Sign-On (SSO) Lösungen für Windows Clients.

In diesem ersten Artikel zum Thema Cloud Kerberos Trust möchte ich zunächst die Grundlagen beschreiben und etwas in die Tiefe gehen. Im zweiten Teil geht es dann um die Einrichtung. Im letzten Part des Artikels beschäftige ich mich mit ein paar Problemen und wie man das Troubleshooting am effektivsten gestaltet (Folgt).

Windows Hello for Business? Was ist das überhaupt?

Windows Hello for Business (WHfB) ist eine im Unternehmensumfeld genutzte Technologie, um die Anmeldung an einem Windows Client für den Benutzer möglichst einfach und sicher zu gestalten.

Es gibt einige Gemeinsamkeiten mit dem im Consumer-Bereich genutzten Windows Hello (WH). Diese beschränken sich jedoch überwiegend auf die für den Benutzer sichtbaren Authentifizierungsmethoden.

Hauptmerkmale von Windows Hello (for Business)

Grundsätzlich basieren WHfB sowie WH auf folgende vier Hauptmerkmalen:

1. Biometrische Authentifizierung: Benutzer können sich per Fingerabdruck oder Kamera am Client anmelden.
2. Komfort und Benutzerfreundlichkeit: Die Anmeldung und das Entsperren des Clients ist für den User sehr bequem.
3. Sicherheit: Biometrische Daten werden lokal auf dem Gerät (muss eine TPM-Chip haben) gespeichert und nicht in die Cloud hochgeladen. Passwörter können bei der Anmeldung am Client nicht abgegriffen werden. Sogenanntes Shoulder Surfing (Abgreifen von Informationen durch direktes Zuschauen) wird damit großteils unterbunden, da sich der Benutzer nur biometrisch am Client anmeldet.
4. Integration: Windows Hello ist vollständig in Windows 10/11 integriert und muss nicht gesondert installiert, sondern nur konfiguriert werden.

Skepsis gegenüber Biometrischer Authentifizierung

Häufig begegnet mir die Sorge von Kunden, dass biometrische Daten bei WHfB abgegriffen werden könnten. Diese Angst führt oft dazu, dass weiterhin auf die weniger sichere Anmeldung mittels Benutzername und Passwort gesetzt wird.

Diese Bedenken sind unbegründet, da biometrische Daten bei WHfB verschlüsselt im TPM-Chip des Geräts gespeichert werden, was insgesamt eine höhere Sicherheit bietet. Es bedarf oft zusätzlicher Erklärungen, um diese Vorteile verständlich zu machen und Vorbehalte abzubauen. Sobald jedoch die Funktionsweise und Sicherheitsvorteile von WHfB klar sind, entscheiden sich die meisten Kunden für dessen Einsatz.

Erweiterte Features für Unternehmen

Die oben genannten Funktionen werden durch den Zusatz „for Business“ so ergänzt, dass die speziellen Anforderungen für Unternehmen bedient werden und eine passwortlose Anmeldung am Client ermöglicht wird. Folgende Zusatzfeatures bietet WHfB zusätzlich:

1. Multifaktor-Authentifizierung: Die biometrischen Daten werden durch einen PIN-Code ergänzt, um eine starke Authentifizierung zu gewährleisten. Eine Anmeldung an einem Unternehmensgerät mittels WHfB ist gleichzusetzen mit einer Anmeldung mittels MFA.
2. Zentrale Verwaltung: Alle relevanten Einstellungen für WHfB können zentral über Intune verwaltet werden.
3. Integration ins Unternehmensnetzwerk: WHfB ist so konzipiert, dass es nahtlose Anbindung ans Active Directory und andere Unternehmensressourcen ermöglicht.
4. Schlüsselbasierte Authentifizierung: Anstelle von Passwörtern verwendet WHfB asymmetrische Schlüsselpaare, um die Identität des Benutzers zu bestätigen. Diese Schlüsselpaare werden auf dem TPM-Chip des Rechners gespeichert. Der private Schlüssel verlässt niemals das Gerät und ist einmalig für jedes Gerät erstellt. Das macht WHfB so sicher.

Grundsätzlich kann man sagen, dass Passwörter unsicher sind. Identitätsdiebstahl spielt eine immer größere Rolle und ist gerade im Unternehmensumfeld eine der höchsten Sicherheitsherausforderungen.

WHfB ermöglicht es den Usern sich stets mit einer „starken“ Authentifizierung am Gerät anzumelden, ohne sich der ständigen Gefahr des Passwortdiebstahls auszusetzen. Selbst wenn der PIN gestohlen werden würde, würde dieser nur an diesem Gerät funktionieren und nicht wie das Passwort von überall. In einem solchen Fall kann gezielt nur die Authentifizierungsmethode des gestohlenen Clients deaktiviert werden.

Der Identityprovider (IDP) – hier Microsoft Entra – hat stets einen Teil des öffentliches Schlüssels, der bei der Einrichtung von WHfB zum Useraccount zugeordnet wird. Jeder durch den IDP ausgestellte Token funktioniert somit nur für das Gerät, für den er ausgestellt wurde. Sollte dieser abgefangen werden, ist dieser für den Angreifer nutzlos. WHfB ist dadurch „Phishing Resistent“ im Gegensatz zu einfachen One Time Passwords, die auch (kurzfristig) für andere Anmeldungen genutzt werden können, sofern Benutzername und Passwort ebenfalls bekannt sind.

WHfB ist eine sehr sichere Alternative zu Passwörtern. Es muss allerdings darauf geachtet werden, dass WHfB auch passend konfiguriert wird. Auch muss die Nutzungsrichtlinie den Nutzern vorschreiben, dass biometrische Methoden vorzugsweise genutzt werden. Denn wer immer die PIN benutzt, und vielleicht auch noch auf all seinen Geräten dieselbe PIN verwendet, der macht das Gerät wieder anfällig für „Shoulder Surfing“, wenn gleichzeitig das Gerät entwendet wird (z.B. im Zug). Die PIN sollte zudem nicht nur vier Nummern lang sein. Das kann aber in der WHfB Policy definiert werden.

SSO mit WHfB – Der Trust

Richtig interessant wird WHfB, wenn noch On-premises Ressourcen genutzt werden sollen. Dann stellt sich nämlich die Frage, wie der Client bzw. Benutzer ein Kerberos-Ticket bekommt, um sich z.B. an einem Fileserver, Proxyserver oder Printserver zu authentifizieren.

Unterschiede zu herkömmlicher Kerberos-Authentifizierung

1. Klassische Kerberos Anmeldung: Um an ein Kerberos Ticket zu kommen, muss der Client bei der klassischen Anmeldung seine Benutzername/Passwort-Kombination einem Domaincontroller präsentieren, um von ihm ein Kerberos Ticket ausgestellt zu bekommen. Dieses Token kann nun genutzt werden, um sich an weiteren Diensten im Netzwerk anzumelden.
2. WHfB Anmeldung: Wird der Client allerdings für WHfB konfiguriert ist, dann gibt der User beim Login nicht mehr seine Benutzername/Passwort-Kombination ein, sondern authentifiziert sich per biometrischem Merkmal bzw. als Fallback mit PIN. WHfB erstellt dann ein Schlüsselpaar, dass zur Authentifizierung an Entra genutzt werden kann. Mit diesen Daten kann der Domaincontroller nichts anfangen. Wir benötigen also eine Möglichkeit, an ein Kerberos Ticket zu kommen. Hier kommt der Trust ins Spiel. Mit dem zuvor ausgestellten Schlüsselpaar kann der User über Entra ein Kerberos-Ticket vom Domaincontroller der On-premises Infrastruktur ausgestellt bekommen und sich gleichermaßen an Cloud sowie On-premises Ressourcen anmelden, ohne dass der Benutzer sein Passwort eingeben muss. Details zur Funktionsweise und den unterschiedlichen Trust Typen folgen später.

Vorteile von Windows Hello for Business bei der Nutzung von SSO

Windows Hello for Business bietet erhebliche Vorteile, wenn es um die Integration von Single Sign-On (SSO) in Unternehmensumgebungen geht, die sowohl Cloud-basierte als auch On-Premises Ressourcen nutzen:

1. Gleichzeitige Integration mit Entra ID (Azure ID) und Active Directory: Am Client meldet man sich mit seinem (Hybrid) Entra Account an und bekommt für beide Directorys Authentifizierungsmerkmale ausgestellt.
2. Erhöhte Sicherheit: WHfB entspricht einer Multi-Faktor-Authentifizierung und bietet somit eine zusätzliche Sicherheitsebene für die Ausstellung eines Kerberos-Tickets. Klassisches Kerberos ist durch kompromittierte Passwörter anfällig für Angriffe.
3. Komfort: Es ist keine Zusätzliche Anmeldung an On-premises Diensten mehr nötig und die User können effektiver arbeiten.

Voraussetzungen für den Trust

Um einen Trust einzurichten, benötigen wir synchronisierte Hybrid-Identitäten. Das bedeutet, Entra Accounts, die mittels Entra Connect vom Active Directory Richtung Entra synchronisiert wurden. Dies wird benötigt, damit ein Kerberos-Ticket für den On-Premises AD Account ausgestellt werden kann.

WHfB mit Key Trust – Ein Rückblick

Einige Firmen haben in Vergangenheit bereits die inzwischen durch Cloud Kerberos Trust abgelöste Technologie Key Trust eingesetzt. Bei dieser Technik liegt das größte Problem bei der Ersteinrichtung und dem komplexeren technischen Hintergrund.

Bei der Inbetriebnahme von WHfB finden im Hintergrund einige Tasks statt, von denen der User nichts mitbekommt. Durch den Entra Connect Sync vergeht etwas Zeit, bis sich der Benutzer nach Einrichtung an lokalen Ressourcen anmelden kann. Dies liegt daran, da die im Entra ausgestellten Next Generation Credentials (NGC) erst beim nächsten Sync (dieser läuft im Standard alle 30 Minuten) Richtung Active Directory synchronisiert werden. Das zuständige Attribut heißt msDS-KeyCredentialLink. Solange dies noch nicht gefüllt ist, wird kein Kerberos Ticket auf dem Client landen.

Um den Ablauf aber besser zu verstehen, schauen wir uns nachfolgendes Diagramm an:

Neben Key Trust wurde auch Certificate Trust eingesetzt. Darauf möchte ich aber nicht genauer eingehen. Die Ausführungen zu Key Trust sollen lediglich die Probleme des Systems zeigen, um die Unterschiede zu Cloud Kerberos Trust zu verstehen und sind recht ähnlich beim Certificate Trust vorhanden.

Key Trust Probleme

Es ergeben sich folgende Nachteile des veralteten Key Trust:

• Domänencontroller benötigen spezielle Zertifikate für die Authentifizierung, die verteilt und verwaltet werden müssen.
• Die öffentlichen Schlüssel müssen zwischen Entra ID und Active Directory synchronisiert werden, was zu Verzögerungen führt.
• SSO funktioniert nicht unmittelbar nach dem ersten Login des Users, sondern erst nach dem nächsten Entra Connect Sync (standardmäßig 30 Minuten).

Hinweis: Certificate Trust hat ähnliche Probleme, benötigt aber zusätzlich eine vollständige PKI-Infrastruktur mit Certificate Authority (CA) und Certificate Revocation List (CRL).

Cloud Kerberos Trust – Der Goldstandard

Die vorangegangene Authentifizierungsmethoden haben alle Ihre Nachteile. Das wusste auch Microsoft und hat eine Methode entwickelt, die für den User und Admin möglichst einfach zu konfigurieren ist.

Eine Herausforderung lag darin, die Abhängigkeit von der Synchronisierung der Anmeldeinformationen aufzulösen und die Konfiguration der vielen Komponenten zu vereinfachen.

Entra Kerberos (vormals Azure AD Kerberos)

Entra Kerberos wurde eingeführt, um FIDO2 Authentifizierung an Hybrid Azure AD Joined (HAADJ) zu ermöglichen. Es wird ein Kerberos-Ticket von Entra statt dem On-Premises AD ausgestellt. Somit erhält der Client ein Ticket Granting Ticket (TGT) inklusive Primary Refresh Token (PRT) von Entra.

Daraus resultieren folgende Vorteile:

• Es müssen keine öffentliche Schlüssel mehr zwischen Entra und AD synchronisiert werden. Demnach keine Verzögerung nach der Inbetriebnehme.
• Es muss keine PKI dafür erstellt oder erweitert werden.
• Passwortlose Anmeldung an allen Ressourcen ohne Verzögerungen wird mit wenigen Konfigurationsschritten erstmals möglich.
• Die On-premises DCs werden stark entlastet, da die Ticketausstellung nun von Entra übernommen wird. Das zeigt überwiegend in größeren Firmen einen Effekt, da weniger DCs benötigt werden.

Wir haben also eine Vertrauenskette, die als Kernkomponente Entra (Azure AD) hat. Es wird also kein Kerberos Ticket mehr vom On-premises AD selbst ausgestellt, sondern die On-premises Ressourcen vertrauen jetzt dem Entra Kerberos Ticket.

Vergleich der Trust Typen

Für die bessere Übersichtlichkeit kann man in der nachfolgenden Tabelle die Unterschiede zusammengefasst vergleichen.

Trust Type	Beschreibung
Cloud Kerberos Trust	Benutzer authentifizieren sich bei Active Directory, indem sie ein TGT von Microsoft Entra ID unter Verwendung von Microsoft Entra Kerberos anfordern. Die lokalen Domänencontroller sind nach wie vor für die Kerberos-Diensttickets und die Autorisierung zuständig. Cloud Kerberos Trust nutzt dieselbe Infrastruktur, die für die Anmeldung mit FIDO2-Sicherheitsschlüsseln erforderlich ist, und kann für neue oder bestehende Windows Hello for Business-Bereitstellungen verwendet werden.
Key Trust	Benutzer authentifizieren sich beim lokalen Active Directory mit einem gerätegebundenen Schlüssel (Hardware oder Software), der während der Windows Hello-Bereitstellung erstellt wird. Es ist erforderlich, Zertifikate an Domänencontroller zu verteilen.
Certificate Trust	Der Certificate Trust stellt Authentifizierungszertifikate für Benutzer aus. Benutzer authentifizieren sich mit einem Zertifikat, das mit einem gerätegebundenen Schlüssel (Hardware oder Software) angefordert wurde, der während der Windows Hello-Bereitstellung erstellt wurde.

WHfB Cloud Kerberos Authentifizierungsworkflow

Wollen wir uns nun einmal in der Tiefe ansehen, wie die Authentifizierung im Endausbau funktioniert. Sobald ein User versucht auf eine On-premises Ressource zuzugreifen, läuft folgender Prozess ab:

• Da der User weiterhin ein synchronisierter Hybrid User sein muss, sind die Informationen zur On-premises Domain im Useraccount enthalten. Diese Information wird benötigt, um den Domainnamen für das Anfordern von Tickets vom KDC zu identifizieren.
• Der Prozess startet erst, wenn der User das erste mal versucht auf eine On-premises Ressource zuzugreifen.
• Mit den Metadaten aus dem WHfB Schlüssel kann der Domainname identifiziert werden.
• Über den DCLocator Service kann nun der nächstgelegene Domaincontroller mit KDC Dienst identifiziert werden.
• Mit dem von Entra erstellten partiellen TGT wendet sich der Client nun an den Domain Controller.
• Dieses partielle TGT ist von Entra signiert und enthält die SID des Users.
• Der Domain Controller verfiziert nun, ob das partielle TGT valide ist.
• Ist die Prüfung erfolgreich, wird vom Domain Controller ein vollwertiges TGT für den User ausgestellt und dieser kann sich damit an anderen On-premises Diensten anmelden.

Zusammengefasst erstellt Entra ein partielles TGT für den User. Dieses kann nun an einem KDC gegen ein vollwertiges TGT eingetauscht werden mit dem dann Service Tickets an den einzelnen Diensten ausgestellt werden können.

Zusammenfassung

Wir haben gelernt, was Windows Hello for Business vom Consumer Produkt Windows Hello unterscheidet und wie es im Detail funktioniert. Zusätzlich wurde die genaue Funktionsweise von WHfB erklärt und die Evolution der verschiedenen Trust Typen aufgezeigt.

Im zweiten Teil dieser Serie beschäftige ich mich genauer mit der Einrichtung und Konfiguration von WHfB Cloud Kerberos Trust.

Referenzen und weiterführende Links

Dieser Artikel basiert auf den offiziellen Microsoft Learn Dokumentationen und Praxiserfahrungen:

• Plan a Windows Hello for Business Deployment – Planungsleitfaden und Übersicht der Trust-Typen
• Windows Hello for Business cloud Kerberos trust deployment guide – Offizielle Deployment-Anleitung
• Introduction to Microsoft Entra Kerberos – Technische Details zu Microsoft Entra Kerberos
• Windows Hello for Business Overview – Allgemeine Übersicht und Features

Der Beitrag Windows Hello for Business SSO – Cloud Kerberos Trust – Part 1 erschien zuerst auf M365 Blog - Julian Stabentheiner.

Das Problem

Ein Kennwort für alle Clients (z.B. über das Aufspielen eines Masterimages) stellt ein erhebliches Sicherheitsrisiko dar. Es kennen zu viele Personen und es muss ein Prozess zum regelmäßigem Ändern existieren. Für jeden Client von Hand ein eigenes Administratorkennwort festzulegen, erfordert einen (zu) hohen Verwaltungsaufwand.

Die Lösung

Dieses Problem löst die Local Administrator Passwort Solution (LAPS). LAPS existiert schon seit 2015 in der On-Prem Welt. Damit kann über Gruppenrichtlinien Objekte (GPO) der lokale Administrator Account auf Windows Geräten in der Active Directory Domäne gesteuert werden. Es wird aber nicht einfach nur ein „Masterpasswort“ auf alle Clients verteilt, sondern für jeden Client ein nur für diesen generiertes Passwort. Dieses Passwort wird anschließend vom Client in das AD Objekt des Clients geschrieben und kann dort verwaltet und von privilegierten Accounts eingesehen werden. Dazu musste bis April 2023 LAPS noch auf den Clients installiert werden und der Implementationsaufwand war dadurch recht hoch. Inzwischen ist LAPS Bestandteil vom Betriebssystem. Die Passwörter werden seit dem verschlüsselt im AD (bzw. Entra) abgelegt.

Auch die Installation im Active Directory bestand aus einigen ToDo’s. Es mussten Schemaerweiterungen gemacht werden und Snap-Ins auf den Maschinen installiert werden, von denen auf die Attribute zugegriffen werden sollte.

Seit einigen Monaten steht LAPS für Intune bzw. Entra ID Only und Hybrid Clients zur Verfügung. Wie LAPS für Intune einzurichten ist und was es für Möglichkeiten gibt, zeige ich dir hier. Spoiler: Es ist deutlich einfacher geworden.

LAPS im M365 Tenant aktivieren

Um LAPS überhaupt nutzen zu können, muss es zunächst im Tenant aktiviert werden. Dies erfolgt im Entra ID (Azure AD) Admincenter (https://entra.microsoft.com/) unter Devices > Overview > Device settings > Enable Microsoft Entra Local Administrator Password Solution (LAPS). Das setzen dieser Einstellung auf Yes führt dazu, dass alle nötigen Einstellungen im Entra gesetzt werden. Im AD LAPS mussten dafür noch einige Powershell-Scripte ausgeführt werden.

LAPS Richtlinie in Intune erstellen

Als nächsten Schritt müssen wir die Richtlinie erstellen, die LAPS auf dem Client konfiguriert. Dies erfolgt im Intune Admin Center (https://intune.microsoft.com/) über Endpoint security > Account Protection > Create Policy

Hier werden die relevanten Einstellungen für LAPS getätigt.

Backup Directory sollte auf Azure AD only gestellt werden.
Password Age Days definiert, in welchem Zyklus das lokale Passwort neu gesetzt werden soll. 30 Tage entspricht dabei dem Standardwert.
Administrator Account Name ist eine optionale Einstellung, mit der der Accountname des Administrator Accounts definiert werden kann.

ACHTUNG: Wird hier ein anderer Accountname festgelegt, so muss dieser separat erstellt bzw. der Build-In Administrator umbenannt werden. Diese Einstellung alleine erstellt keinen Account bzw. aktiviert auch nicht den bereits vorhandenen lokalen Administrator auf dem Client. Wie das gemacht wird, folgt gleich.

Password Complexity definiert, aus welchen Zeichen das generierte Passwort bestehen darf. Aus Sicherheitsgründen ist es ratsam, hier die möglichst höchste Stufe zu wählen.
Password Length definiert die Länge des Passwortes.
Post Authentication Actions definiert, wie verfahren wird, wenn das Kennwort genutzt wird. Ich habe hier die Standardeinstellung gewählt. Damit wird das Passwort nach der über Post Authentication Reset Delay Zeit von hier 24 Stunden neu gesetzt. Mit der Standardeinstellung wird das Kennwort anhand der definierten Regeln neu gesetzt und der Account ausgeloggt, sofern er noch am Rechner eingeloggt ist. Man hat hier also bis zu 24 Stunden Zeit, um mit dem LAPS Admin Account die nötigen Tasks zu erledigen. 24 Stunden sind die Standardzeit der Policy, falls die Einstellung nicht explizit geändert wird. Ich würde hier zu 8 Stunden raten, damit nach dem Arbeitstag das Kennwort neu gesetzt wird.

Als letzten Schritt müssen der Policy noch Clients zugewiesen werden. Grundsätzlich spricht nichts dagegen, hier All Devices zu wählen. Dies muss aber nach eigenen Anforderungen entschieden werden.

Administrator Account aktivieren

Im Standard ist der lokale Build-In Administrator deaktiviert und muss über eine zweite Richtlinie aktiviert werden. In diesem Schritt kann man auch den Administrator umbenennen. Dies bietet ein kleines bisschen zusätzliche Sicherheit. Wir erstellen eine neue Configuration Policy für Windows mit dem Typ Settings catalog.

Über den Settings picker unter Local Policies Security Options suchen wir die beiden Settings Accounts Enable Administrator Account Status und Accounts Rename Administrator Account raus und setzen die Einstellungen wie folgt:

Wie bereits erwähnt, ist das Umbenennen des Administratoraccounts optional und nicht zwingend nötig. Sollte jedoch der Administrator Account nicht aktiviert werden, kann LAPS auf dem Client nicht arbeiten. Dies bekommt man über den Event Viewer mit einer ziemlich eindeutigen Fehlermeldung quittiert.

Hat man in der zweiten Policy den Administrator Account nicht umbenannt, erhält man den Fehlercode 0x80070002, weil LAPS den konfigurierten Administratoraccount nicht finden kann.

Abrufen des Kennwortes über Entra und Intune

Sofern aber alles richtig konfiguriert ist, setzt der Client das Kennwort und pusht es Richtung Entra (Azure AD). Dort gibt mehrere Möglichkeiten, das Kennwort abzurufen.

Entra admin center

Im Entra admin center erhält man Zugriff auf alle gespeicherten LAPS Kennwörter. Auch der dazugehörige Accountname ist aufgeführt. Das Support-Team muss den pro Kunde individuell konfigurierten Accountnamen des Administrators nicht wissen. Auch wird hier die letzte und nächste Passwortrotation angezeigt. Neu setzen lassen kann man das Kennwort an dieser Stelle jedoch nicht.

Intune admin center

Im Intune admin center erhält man über das Device selbst über den Punkt Monitor > Local admin password Zugriff auf das Kennwort.

Rotation des Kennwortes über Intune

Wurde das Kennwort genutzt oder vielleicht sogar dem Anwender mitgeteilt, kann ein vorzeitiges Ändern des Kennwortes über Intune ausgelöst werden.

Nach der Bestätigung des nachfolgenden Dialogs wird der Client mit dem vorzeitigen Ändern des Passwortes beauftragt. Die Änderung erfolgt allerdings nicht direkt, sondern erst nach einem Neustart des Gerätes.

Ausblick

Das Thema LAPS steht bei Microsoft nicht still. Ab dem Windows 11 Insider Preview Build 26040 besteht die Möglichkeit, weitere Einstellungen zu setzen. Diese können aktuell allerdings nur über CSP-Settings per OMA-URI auf den Clients per Intune gesetzt werden.

Konkret wird vor allem das Thema Eingabe der Passwörter angegangen. Bei Kennwörtern ist oft das Problem, dass Zeichen wie 0 und O gerne vertauscht werden. Das führt vor allem dann zu Problemen bei der Eingabe, wenn das Kennwort nicht per Copy/Paste in einer Remotesitzung auf den Client kopiert werden kann und abgeschrieben bzw. jemandem durchgegeben werden muss.

Lesbarkeit von Passwörtern

Es kommt künftig eine fünfte Option für die PasswortComplexity dazu, bei der verwechselbare Zeichen für die Passwortvorgabe ausgeschlossen werden. Hier ein Auszug aus dem Microsoft Artikel dazu.

Wortlisten für Passphrasen

Um die Passworteingabe noch weiter zu erleichtern, können künftig auch Passphrasen als Kennwörter genutzt werden. Diese sind bei entsprechender Länger ähnlich sicher, aber deutlich schneller einzugeben. Ein Passwort für das Administratorkonto könnte dann z.B. so aussehen

SkiingProduceIdentifyStarlitOctaneDistress

Dass diese Settings ohne OMA-URI konfiguriert werden können, wird mit Verfügbarkeit im Windows 11 Current Branch soweit sein.

Automatic Account Management

Eine weitere neue Funktion ist das Automatische Account Management (Automatic Account Management). Damit wird der Administratoraccount mit einem Prefix und einer zufälligen Nummer generiert um die Sicherheit weiter zu erhöhen. Auch diese Funktion ist bereits im aktuellen Insider Build enthalten.

Fazit

Ob LAPS zum Einsatz kommt, muss individuell entschieden werden. Es bietet im Vergleich zur Entra Joined Device Local Administrator Rolle (Zuweisung über PIM vorausgesetzt) den Vorteil der sofortigen Verfügbarkeit der erhöhten Rechte und kann im Ernstfall auch offline genutzt werden. Eine dieser Varianten sollte allerdings in jedem Fall genutzt werden. Es gibt meiner Meinung nach keine Ausreden dafür. Teilweise kommen auch per Intune noch eigens gebaute PowerShell-Scripte zum Einsatz, die auf allen Clients ein „Masterkennwort“ auf den Clients setzen.

1. PIM: Microsoft Entra Privileged Identity Management ︎

Der Beitrag Einrichtung von LAPS mit Microsoft Intune erschien zuerst auf M365 Blog - Julian Stabentheiner.

Im Kern wird ein Script im user-context ausgeführt, welches nach der App in der Taskleiste sucht und dann im Kontextmenü den Klick auf Unpin from taskbar ausführt.

$apps = ((New-Object -Com Shell.Application).NameSpace('shell:::{4234d49b-0245-4df3-b780-3893943456e1}').Items())
foreach ($app in $apps) {
    $appname = $app.Name
    if ($appname -like "Microsoft Store") {
        $finalname = $app.Name
    }
}

((New-Object -Com Shell.Application).NameSpace('shell:::{4234d49b-0245-4df3-b780-3893943456e1}').Items() | ? { $_.Name -eq $finalname }).Verbs() | ? { $_.Name.replace('&', '') -match 'Unpin from taskbar' } | % { $_.DoIt(); $exec = $true }

Okay soweit. Es muss dann nur auf die deutsche Lokalisation von Windows angepasst werden – habe ich gedacht. Also flink Unpin from taskbar im Script durch Von Taskleiste lösen ersetzt.

Anschließen habe ich das Powershell-Script lokal auf meinem Client getestet und es funktionierte auch wie es sollte. Nach dem ersten Deployment auf meinem Testgerät kam allerdings die Ernüchterung… Es passiert leider nichts.

Ich habe dann das Script durch etwas Debugging erweitert und auf dem Client dann festgestellt, dass das ö in Von Taskleiste lösen es leider nicht bis auf dem Client schafft.

Also habe ich mir die Microsoft Docs dazu mal genauer angesehen:

• Script location: Browse to the PowerShell script. The script must be less than 200 KB (ASCII).

Quelle: https://learn.microsoft.com/en-us/mem/intune/apps/intune-management-extension#create-a-script-policy-and-assign-it

Microsoft verlang also explizit reinen ASCII Code im Powershell-Script. Ich musste es also schaffen, dass das ö erst auf dem Client erschaffen wird. Mit der Funktion [char] und des darauf folgenden ASCII-Wertes, kann man im Script das Zeichen erstellen. In meinem Fall das ö. Um die passende Nummer zu erhalten, kann man folgenden Befehl in Powershell ausführen

[byte][char]'ö'
246

Somit kann man dann im Script das ö in eine Variable schreiben und sich somit den String Von Taskleiste lösen zusammenbauen.

Ich habe das ganze noch durch eine Abfrage der aktuellen Systemsprache ergänzt, um das Script auch in Mischumgebungen sowie universell einsetzen zu können.

$winlanguage = Get-WinSystemLocale

If ($winlanguage.name -eq "de-DE") {
    $oe = [char]246
    $command = 'Von Taskleiste l' + $oe + 'sen'
}

Final sieht mein Script dann so aus.

################################################
### Author: Julian Stabentheiner
### Date: 26.01.2023
### Description: Unpin Apps from Taskbar
################################################

#Sleep Script after user logon
Start-Sleep -s 30

#List of Apps to unpin from Taskbar
$apps = "Microsoft Store" , "Mail"

#Get Windows System Language
$winlanguage = Get-WinSystemLocale

If ($winlanguage.name -eq "de-DE") {
    $oe = [char]246
    $command = 'Von Taskleiste l' + $oe + 'sen'
}
If ($winlanguage.name -eq "en-US") {
    $command = 'Unpin from taskbar'
}


foreach ($app in $apps) {
    ((New-Object -Com Shell.Application).NameSpace('shell:::{4234d49b-0245-4df3-b780-3893943456e1}').Items() | ? { $_.Name -eq $app }).Verbs() | ? { $_.Name.replace('&', '') -match $command } | % { $_.DoIt(); $exec = $true }
}

Sofern Clients in mehreren Sprachen vorhanden sind, müsste man das Script noch um eine Prüfung der Windows Sprache erweitern. Sollte ich diese Anforderung in Zukunft einmal haben, werde ich den Beitrag entsprechend anpassen.

Umsetzung der Policy

Der Vollständigkeit halber möchte ich hier noch die Erstellung des Scripts in Intune zeigen.

Als Assignment habe ich All users gewählt. Es können aber auch andere Varianten gewählt werden, je nach Anwendungsfall.

Alternative Ausführung über Proactive Remediations

Je nach vorhandener Lizenz, kann die Ausführung des Scripts als Proactive Remediation die bessere Lösung sein. In meinem Fall funktioniert es als Script allerdings wie gewollt und wenn ein User die Microsoft Store App doch wieder an die Taskleiste anpinnen möchte, kann er das auch tun. Die Proactive Remediation würde diese immer wieder entfernen.

Der Beitrag Intune Policy: „Unpin from Taskbar“ …Aber auf deutschem Windows erschien zuerst auf M365 Blog - Julian Stabentheiner.