4
Ein besserer Weg zur Delegation of Control für Bitlocker Recoverykeys
Will man Supportmitarbeitern ermöglichen, Bitlocker-Recoverykeys auszulesen, dann bietet sich eigentlich der Delegation of Control Wizard an.
Ich zeige zunächst mal, wie das gemacht würde:
Das Dumme ist nur: damit der Supporter hier etwas auslesen kann, braucht er „Full Control“!
Ebenso arbeitet der Wizard nur auf OU-Ebene und kann nicht granular pro Rechner Rechte setzen, falls gewünscht.
Er kann somit diese Keys nicht nur lesen, sondern (via ADSI-Edit oder Kommandos) auch löschen und somit (versehentlich) großen Schaden anrichten. Dass hier keine Leserechte ausreichen, liegt an einem interessanten Umstand: Microsoft benutzt zum Absichern der Recoverykeys das sogenannte „Confidentiality Bit“. Ich zitiere aus https://blog.nextxpert.com/2011/01/11/how-to-delegate-access-to-bitlocke ... :
Das ist nicht schön, denn der Delegation of Control Wizard kann dieses Bit nicht setzen oder entfernen, sprich: entweder, wir vergeben Vollzugriff, oder der Supporter kommt gar nicht ran - etwas dazwischen bietet der Wizard nicht!
Doch es gibt einen Ausweg:
Man kann die LDP.exe von 2019 Server nutzen, um Leserechte und „Control Access“ zu erteilen, so dass man genau das Gewünschte erreicht: „nur lesen, sonst nichts“.
Die LDP.exe von 2016 Server kann seltsamerweise hierzu nicht genutzt werden. Für diese Serverversion muss man ldp.exe aus diesem Download extrahieren und damit arbeiten: https://web.archive.org/web/20200803205237/https://download.microsoft.co ...
Ich liefere noch die passenden Screenshots. Zunächst LDP.exe starten, Connect – OK – Bind – OK – Tree (CTRL-T) – OK
Dann zur OU navigieren, auf die Rechte gesetzt werden sollen und dem folgenden Bild folgen:
Im Descriptor dann DACL anklicken und „add trustee“ und z.B. wie im Bild einstellen:
Dann OK und zuletzt "Update" klicken.
Damit haben wir „yourdom\someuser“ Leserechte auf die Recoverykeys aller Computer in der OU „Server“ gegeben.
Erfreulicherweise kann man über ldp.exe die OU weiter aufklappen und das Selbe auf Rechnerebene und sogar auf Partitionsebene/Keyebene machen. Sprich, man könnte einem Supporter den Zugriff auf den Recoverykey lediglich einer einzelnen Partition eines einzelnen Servers erteilen.
Ich zeige zunächst mal, wie das gemacht würde:
Das Dumme ist nur: damit der Supporter hier etwas auslesen kann, braucht er „Full Control“!
Ebenso arbeitet der Wizard nur auf OU-Ebene und kann nicht granular pro Rechner Rechte setzen, falls gewünscht.
Er kann somit diese Keys nicht nur lesen, sondern (via ADSI-Edit oder Kommandos) auch löschen und somit (versehentlich) großen Schaden anrichten. Dass hier keine Leserechte ausreichen, liegt an einem interessanten Umstand: Microsoft benutzt zum Absichern der Recoverykeys das sogenannte „Confidentiality Bit“. Ich zitiere aus https://blog.nextxpert.com/2011/01/11/how-to-delegate-access-to-bitlocke ... :
All objects created with the Confidentiality bit set to 1, are only available for users, who have full control access to that object. These objects are hidden for other users in Active Directory
Das ist nicht schön, denn der Delegation of Control Wizard kann dieses Bit nicht setzen oder entfernen, sprich: entweder, wir vergeben Vollzugriff, oder der Supporter kommt gar nicht ran - etwas dazwischen bietet der Wizard nicht!
Doch es gibt einen Ausweg:
Man kann die LDP.exe von 2019 Server nutzen, um Leserechte und „Control Access“ zu erteilen, so dass man genau das Gewünschte erreicht: „nur lesen, sonst nichts“.
Die LDP.exe von 2016 Server kann seltsamerweise hierzu nicht genutzt werden. Für diese Serverversion muss man ldp.exe aus diesem Download extrahieren und damit arbeiten: https://web.archive.org/web/20200803205237/https://download.microsoft.co ...
Ich liefere noch die passenden Screenshots. Zunächst LDP.exe starten, Connect – OK – Bind – OK – Tree (CTRL-T) – OK
Dann zur OU navigieren, auf die Rechte gesetzt werden sollen und dem folgenden Bild folgen:
Im Descriptor dann DACL anklicken und „add trustee“ und z.B. wie im Bild einstellen:
Dann OK und zuletzt "Update" klicken.
Damit haben wir „yourdom\someuser“ Leserechte auf die Recoverykeys aller Computer in der OU „Server“ gegeben.
Erfreulicherweise kann man über ldp.exe die OU weiter aufklappen und das Selbe auf Rechnerebene und sogar auf Partitionsebene/Keyebene machen. Sprich, man könnte einem Supporter den Zugriff auf den Recoverykey lediglich einer einzelnen Partition eines einzelnen Servers erteilen.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 491520
Url: https://administrator.de/contentid/491520
Ausgedruckt am: 26.11.2024 um 02:11 Uhr
4 Kommentare
Neuester Kommentar
Edit: ich musste eine Korrektur vornehmen: das letzte Bild war schlicht falsch und hätte nicht zum erwünschten Ergebnis geführt. Ich muss beim Testen verschiedene Screenshots gemacht haben und hatte hier den falschen eingefügt 
Hi, sorry for writing in English (I'm Russian and I've reached my language cap at English).
I found the link to this post on technet. And the original question involved PS. I've also read your article on Expert-Exchange - neither of them indicates the PS approach, though the EE one mentioned that it's possible with some complicated scripting.
Could you please nudge me in the right direction on how to replicate in PS what you describe for LDP.exe in your EE article?
Does the technet's OP have a correct idea:
The reasoning behind my question is that I need to enable this for 83 different OUs and you can imagine how unwilling one might be to do that in GUI, especially if you're so used to extensive use of foreach here and there.
I found the link to this post on technet. And the original question involved PS. I've also read your article on Expert-Exchange - neither of them indicates the PS approach, though the EE one mentioned that it's possible with some complicated scripting.
Could you please nudge me in the right direction on how to replicate in PS what you describe for LDP.exe in your EE article?
Does the technet's OP have a correct idea:
dsacls.exe "OU=Computers,$OrganizationalUnitDN" /G $prefixlocation-$type":RP;msFVE-RecoveryPassword;msFVE-RecoveryInformation" /I:S
Hi nekku.
I am willing to help you, but I suggest to open a question here.
You may write in english, no problem.
Please add a description why you are trying to automate this the way you do. Normally, this is used by admins that would like to delegate permissions to their holiday substitution and only for a few machines, not for several OUs, so no automation is needed.
I am willing to help you, but I suggest to open a question here.
You may write in english, no problem.
Please add a description why you are trying to automate this the way you do. Normally, this is used by admins that would like to delegate permissions to their holiday substitution and only for a few machines, not for several OUs, so no automation is needed.
Hi DerWoWusste,
Thank you! I've posted the question here: Bitlocker recovery key delegation via Powershell
Thank you! I've posted the question here: Bitlocker recovery key delegation via Powershell
