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.