BitLocker per Startup-Skript aktivieren

[EmmKay 1]

Hallo Zusammen.

 

Per Startup-Skript möchte ich gerne die BitLocker-Laufwerksverschlüsselung aktivieren, da sich sämtliche Rechner außerhalb meines Standortes befinden.

#Requires -RunAsAdministrator

$directory = '\\Server\Share$'
$filename  = 'Transcript-{0}.txt' -f $env:COMPUTERNAME
Start-Transcript -Path $(Join-Path -Path $directory -ChildPath $filename)

if( (Get-Tpm).TpmPresent ) {
    $volume = Get-BitLockerVolume -MountPoint $env:SystemDrive
    if ( $volume.ProtectionStatus -eq 'Off' ) {
        if ( ($volume.KeyProtector | Where-Object KeyProtectorType -eq 'RecoveryPassword').Length -eq 0 ) {
            Add-BitLockerKeyProtector -MountPoint $env:SystemDrive -RecoveryPasswordProtector
        }
        Enable-BitLocker -MountPoint $env:SystemDrive -EncryptionMethod XtsAes256 -TpmProtector
    } else {
        'BitLocker ist aktiviert.'
    }
}

Stop-Transcript

 

Per Gruppenrichtlinie wird der Wiederherstellungsschlüssel in der Domäne gespeichert. Wird das Skript per Domänenadmin ausgeführt, wird die Laufwerksverschlüsselung aktiviert und der Wiederherstellungsschlüssel in der Domäne gespeichert. Sobald das Skript beim Starten der Rechners aufgeführt wird, kommt es zum Fehler:  Dem Client fehlt ein erforderliches Recht. (Ausnahme von HRESULT: 0x80070522)

Hier ist das vollständige Transcript:

 

Welches Recht fehlt dem Rechner? Ich gehe davon aus, dass dem Computer Rechte im Active Directory fehlen. Diese habe ich auch schon (ohne Erfolg) angepasst.

 

In dieser Angelegenheit würdet Ihr mir sehr helfen.

 

M

 

 

[zahni 521]

Ich glaube, so einfach geh das nicht. Dieses Property ist explizit nur für Domain-Admins lesbar und beschreibbar, damit andere User die Recovery-Keys nicht auslesen können.

 

 

[daabm 1.185]

Das ginge schon, aber SELF braucht dann auch Vollzugriff auf das untergeordnete neue Recovery-Objekt. Und nicht auf untergeordnete Computerobjekte.

[EmmKay 1]

vor 22 Stunden schrieb daabm:

Das ginge schon, aber SELF braucht dann auch Vollzugriff auf das untergeordnete neue Recovery-Objekt. Und nicht auf untergeordnete Computerobjekte.

Das funktioniert leider auch nicht? Dem Client fehlt immer noch ein erforderliches Recht.

 

Danke für Eure Hilfe.

 

M

[zahni 521]

vor 22 Stunden schrieb daabm:

aber SELF braucht dann auch Vollzugriff auf das untergeordnete neue Recovery-Objekt.

Hä? Der Recovery-key ist doch nur ein Property im Computer-Objekt.

[Sunny61 773]

Lt. Beschreibung ist e zwar nicht nötig, aber probieren kannst Du das Script trotzdem: https://learn.microsoft.com/en-us/previous-versions/orphan-topics/ws.10/cc749026(v=ws.10)?redirectedfrom=MSDN

[daabm 1.185]

vor 49 Minuten schrieb zahni:

Hä? Der Recovery-key ist doch nur ein Property im Computer-Objekt.

 

Das hängt von irgendwas ab. Ich kannte das auch so, aber irgendwann/irgendwie wurden das untergeordnete Objekte.

[zahni 521]

vor 16 Stunden schrieb daabm:

Das hängt von irgendwas ab

Ich habe mal ein wenig bei uns geguckt und gegoogelt. Ich tippe darauf, dass der im "ntsecuritydescriptor" gespeichert wird. Das Attribut zeigt die normale MMC von Windows nicht an. Nur ein Zusatztool von uns.

In der MMC ist eine Funktion implementiert, die dann im Reiter Bitlocker Wiederherstellungsschlüssel den Schlüssel anzeigt.

 

Hier habe ich dazu eine längere Diskussion gefunden. Ich warne aber davor, hier irgendwelche Rechte zu verstellen:

https://administrator.de/forum/bitlocker-wiederherstellungsschluessel-werden-nicht-im-ad-gespeichert-343431.html 

 

  

[EmmKay 1]

vor 19 Stunden schrieb Sunny61:

Lt. Beschreibung ist e zwar nicht nötig, aber probieren kannst Du das Script trotzdem: https://learn.microsoft.com/en-us/previous-versions/orphan-topics/ws.10/cc749026(v=ws.10)?redirectedfrom=MSDN

Das Skript Add-TPMSelfWriteACE.vbs habe ich ausgeführt.

 

Mein Skript habe ich leicht erfolgreich angepasst

<#
#Requires -RunAsAdministrator
#>

$directory = '\\server\share'
$filename  = 'Transcript-{0}.txt' -F $env:COMPUTERNAME
Start-Transcript -Path $(Join-Path -Path $directory -ChildPath $filename)

if( (Get-Tpm).TpmPresent ) {
    $bl_volume     = Get-BitLockerVolume -MountPoint $env:SystemDrive
    $bl_status     = $bl_volume.VolumeStatus
    $bl_protection = $bl_volume.ProtectionStatus

    if (($bl_status -eq 'FullyDecrypted') -or ($bl_protection -eq 'Off')) {
        #TODO: Error handling
        Enable-BitLocker -MountPoint $env:SystemDrive -EncryptionMethod XtsAes256 -RecoveryPasswordProtector -SkipHardwareTest

        #TODO: Check status
    } else {
        "'$($env:SystemDrive)' wurde mit BitLocker verschlüsselt."
    }
}

Stop-Transcript

 

Leider kommt es immer noch zu diesem Fehler:

Add-TpmProtectorInternal : Dem Client fehlt ein erforderliches Recht. (Ausnahme von HRESULT: 0x80070522)
In C:\Windows\system32\WindowsPowerShell\v1.0\Modules\BitLocker\BitLocker.psm1:2095 Zeichen:31
+ ...   $Result = Add-TpmProtectorInternal $BitLockerVolumeInternal.MountPo ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Write-Error], COMException
    + FullyQualifiedErrorId : System.Runtime.InteropServices.COMException,Add-TpmProtectorInternal
Add-TpmProtectorInternal : Dem Client fehlt ein erforderliches Recht. (Ausnahme von HRESULT: 0x80070522)

 

Zur Ausnahme von HRESULT 0x80070522 konnte ich noch nichts brauchbares finden. Vielleicht hat der Fehler auch nichts mit dem Speichern der Wiederherstellungsschlüssel im Verzeichnisdienst zu tun?

 

Vielen Dank für Eure Mithilfe.

 

M

 

[daabm 1.185]

# as an HRESULT: Severity: FAILURE (1), FACILITY_WIN32 (0x7), Code 0x522
# for hex 0x522 / decimal 1314
  ERROR_PRIVILEGE_NOT_HELD                                       winerror.h   
# A required privilege is not held by the client.

 

@zahni bei mir ist das kein Attribut, sondern ein Childobjekt (links ist ein Clientaccount ausgewählt):

[zahni 521]

Hm, in meiner MMC kann ich da nichts aufklappen. Wobei ich noch Windows 10 mit den 2019'er Tools habe. Vermutlich ist das nur eine andere Darstellung. Aber gut: Das Property heißt dann wirklich wie im Internet geheißen und man kann es auch mit Domain-Admin-Rechten nicht direkt in der Liste der Attribute sehen. mit den 2019'er MMC-Tools ist es komplett unsichtbar.

Und wenn MS das als "Child-Object" bezeichnet, ok. Auf diese Daten kann man aber eben nur via einer speziellen API zugreifen:

 

https://learn.microsoft.com/en-us/powershell/module/mbam/read-adrecoveryinformation?view=win-mdop2-ps

 

 

[NorbertFe 1.805]

vor 4 Minuten schrieb zahni:

Hm, in meiner MMC kann ich da nichts aufklappen.

 

[zahni 521]

Ah, ok. Noch nie gesehen oder benutzt. Kaum in meinen "Contoso"-Seminaren offenbar nicht vor. Sieht doch wie ein eigenen Objekt mit Attributen aus. Man lernt nie aus... 

Das ich ein einem Freitag nochmal das dazulerne

 

[NorbertFe 1.805]

vor 7 Minuten schrieb zahni:

Das ich ein einem Freitag nochmal das dazulerne

 

Und das in einer Console aus dem Jahr 1999 ;)

[EmmKay 1]

vor 1 Stunde schrieb daabm:

# as an HRESULT: Severity: FAILURE (1), FACILITY_WIN32 (0x7), Code 0x522
# for hex 0x522 / decimal 1314
  ERROR_PRIVILEGE_NOT_HELD                                       winerror.h   
# A required privilege is not held by the client.

 

Gibt es dafür einen Workaround wie ich die Laufwerksverschlüsselung beim Rechnerstart aktiviere? Mit Sicherheit bin ich nicht der Einzige, der versucht, per Startup-Skript BitLocker zu aktivieren.  Die Arbeit mich auf jedem Rechner remote zu verbinden, wollte ich mir ersparen?

 

Über Ideen und jede Art von Hilfe bin ich sehr dankbar.

 

M