BitLocker Recovery Key Share - txt wird nicht erzeugt

[Wisi 12]

Hallo in die Runde,

 

wir führen gerade großflächig BitLocker ein (rein auf TPM Basis, damit die Platte ohne Hardware in Zukunft wertlos ist) und im Prinzip funktioniert auch schon alles. Nur eine Sache kriege ich irgendwie nicht hin und zwar, dass er die Recovery Keys auch als TXT im definierten Share ablegt.

Ich habe die Richtlinie "Standardordner für Wiederherstellungskennwort auswählen" gesetzt, einen Pfad auf unserem DFS dafür festgelegt und diesen kann ich auch beschreiben. Aus der Logik her habe ich dem Share selbst die Berechtigung "Authentifizierte Benutzer" gegeben und die NTFS Berechtigung im Dateisystem ist "Administratoren und System", da ich davon ausgehe, dass das System die Datei ablegen möchte und auch kein User das lesen braucht. Allerdings hat sich bis jetzt dort nie eine .txt gebildet, wenngleich die Verschlüsselung aktiviert ist und funktioniert.

 

Wo liegt der Fehler, bzw. wie muss dieses Share gesetzt sein, damit es funktioniert bei euch?

[MurdocX 950]

vor 3 Minuten schrieb Wisi:

Aus der Logik her habe ich dem Share selbst die Berechtigung "Authentifizierte Benutzer" gegeben und die NTFS Berechtigung im Dateisystem ist "Administratoren und System", da ich davon ausgehe, dass das System die Datei ablegen möchte und auch kein User das lesen braucht.

Das klingt interessant, dennoch sagt es nichts   Welche Berechtigung hast du denn vergeben (lesen/lesen & schreiben/ändern/vollzugriff)? 

 

Was denkst du mit welchem Benutzer das Betriebssystem denn auf das Share schreibt?

[NorbertFe 2.034]

vor 18 Minuten schrieb Wisi:

NTFS Berechtigung im Dateisystem ist "Administratoren und System

Und wer sollte NTFS technisch deiner Meinung nach "System" sein? ;)

vor 18 Minuten schrieb Wisi:

damit es funktioniert bei euch?

Wir lassen das ins AD schreiben. Ohne Verbindung zum AD gibts kein Bitlocker.

[Wisi 12]

vor 31 Minuten schrieb MurdocX:

Das klingt interessant, dennoch sagt es nichts   Welche Berechtigung hast du denn vergeben (lesen/lesen & schreiben/ändern/vollzugriff)? 

In der Tat wieder mal zu kurz gesprungen. Das kommt davon, wenn man schon länger damit rum macht und dann denkt jeder weiß wovon man redet...

 

Share - Authentifizierte Benuzter -> Vollzugriff

Ordner/NTFS - Administratoren/System -> Vollzugriff

vor 38 Minuten schrieb MurdocX:

Was denkst du mit welchem Benutzer das Betriebssystem denn auf das Share schreibt?

Das wäre meine Frage an euch Experten ;) Ich hätte vermutet "System", aber ich weiß es schlicht nicht, weil ich auch noch nirgends ein System habe, wo das funktioniert, sonst hätte ich mir es dort angeschaut, wer der Besitzer ist. Leider steht es auch in keinem einzigen Tutorial, jeder legt nur die Ordner an und verweist auf die Richtlinie. Was er konkret für Berechtigungen auf Share/Ordner gesetzt hat, verschweigen sie alle.

 

vor 27 Minuten schrieb NorbertFe:

Wir lassen das ins AD schreiben. Ohne Verbindung zum AD gibts kein Bitlocker.

Da lass ich es normal natürlich auch rein schreiben, oder alternativ erfasst unser Client Management die Standalone Clients und beim Job der Aktivierung von BitLocker schreibt er dann direkt den Recovery Key (nach Abruf über Powershell) in die Eigenschaften des Clients und schickt nach Möglichkeit auch von dort aus direkt noch eine Mail mit den Informationen über unser eigenes Gateway.

 

Insofern wollte ich das Share eigentlich mehr oder weniger als "doppelten" Boden für interne Clients haben.

[NilsK 2.934]

Moin,

 

ähem, liebe Kollegen - bitte seid doch einfach mal deutlich.

 

Also: "System" bezeichnet in Berechtigungen immer das lokale System. Bei einem Share wäre das also das Betriebssystem des Dateiservers. Also mit Sicherheit nicht die Instanz, die da zu schreiben versucht - das wäre ja das Betriebssystem des Clients. Diese Berechtigung passt also schon mal nicht.

 

Dann: Man sollte auf Share- und NTFS-Ebene nicht in dieser Form die Berechtigungen unterschiedlich halten. Da NTFS das leistungsfähigere Berechtigungssystem hat, sollten nur dort die Berechtigungen stehen. Das Share wird dann für "Jeder: Vollzugriff" berechtigt.

 

[Datei- und Freigabeberechtigungen in Windows | faq-o-matic.net]
https://www.faq-o-matic.net/2015/12/28/datei-und-freigabeberechtigungen-in-windows/

 

Ob der Mechanismus, den du beschreibst, den Sicherheitsanforderungen genügt, die man zur Ablage von Bitlocker-Schlüsseln haben sollte, kann ich nicht einschätzen. Seltsam klingt für mich, dass du die Keys von "Standalone-Clients" in das Share legen willst. Sind die nicht Mitglieder im AD? Dann wirst du dort kaum eine sinnvolle Berechtigung vergeben können.

 

Gruß, Nils

 

[Wisi 12]

vor 4 Minuten schrieb NilsK:

Also: "System" bezeichnet in Berechtigungen immer das lokale System. Bei einem Share wäre das also das Betriebssystem des Dateiservers. Also mit Sicherheit nicht die Instanz, die da zu schreiben versucht - das wäre ja das Betriebssystem des Clients. Diese Berechtigung passt also schon mal nicht.

Danke, Wald und Bäume, das klingt für mich in der Tat sehr logisch, hätte man selbst drauf kommen können. Aber eine Idee mit welchen Berechtigungen, bzw. welchem User etc. das Ding kommt, hast du auch nicht? Scheinen wohl eher wenige Leute zu verwenden.

 

vor 5 Minuten schrieb NilsK:

Dann: Man sollte auf Share- und NTFS-Ebene nicht in dieser Form die Berechtigungen unterschiedlich halten. Da NTFS das leistungsfähigere Berechtigungssystem hat, sollten nur dort die Berechtigungen stehen. Das Share wird dann für "Jeder: Vollzugriff" berechtigt.

Unser Dozent, als ich mit der Thematik vor zig Jahren angefangen habe, hat immer gepredigt, dass er "Jeder" nicht für so geeignet hält wie "Authentifizierte Benutzer". Das war beim Training für MCP Prüfungen in einem Testcenter, in dem nur geprüfte Trainer anwesend waren. Haben das bisher immer so beibehalten und uns darüber keine weiteren Gedanken beim Thema "Jeder" vs "Authentifizierte Benutzer". Was nicht heißt, dass man mal nach aktuellem Stand neu drüber nachdenken könnte, wenn der MVP schon drauf hinweist ;) Beim Rest keine Frage, so ist das bei uns auch, am Share wird nichts weiter abgefangen, es wird auf der NTFS Ebene berechtigt.

 

vor 7 Minuten schrieb NilsK:

Ob der Mechanismus, den du beschreibst, den Sicherheitsanforderungen genügt, die man zur Ablage von Bitlocker-Schlüsseln haben sollte, kann ich nicht einschätzen. Seltsam klingt für mich, dass du die Keys von "Standalone-Clients" in das Share legen willst. Sind die nicht Mitglieder im AD? Dann wirst du dort kaum eine sinnvolle Berechtigung vergeben können.

Nein, deshalb schrieb ich, das gilt für interne Clients als zweite Option. Bei den externen/Standalone machen wir das mit Mitteln unseres Client Managements, da dort eben keine Bordmittel greifen (können). Ich könnte theoretisch auch drauf verzichten und die internen Clients ebenso mit dem Client Management abfragen (was wir wohl auch umsetzen werden im weiteren Workflow). Man will aber ja trotzdem das Problem erfassen und lösen, bevor man es abhakt.

[NilsK 2.934]

Moin,

 

gut, dann dürfte der Principal "Domänencomputer" der richtige sein. Da ich keine Erfahrungen mit diesem Setup habe, würde ich versuchen, ob es ausreicht, dieser Gruppe Schreibrechte auf den Ordner zu geben. Leserechte würde ich nur einer Gruppe geben, die auf die Keys wirklich zugreifen darf.

 

Allerdings würde ich auch noch mal bewerten, ob diese "zweite Option" wirklich sinnvoll ist. Die Ablage im AD erfolgt mit einem anderen Mechanismus, der (vermutlich) besser abgesichert ist als ein Share. (So genau habe ich das noch nicht analysiert, aber in der Tendenz gehe ich davon aus.) Eine zweite Option hat immer einen grundsätzlichen Nachteil: In der Regel ist sie leichter anzugreifen als die primäre Option, mindestens aber eröffnet sie einen zusätzlichen Angriffsweg.

 

Gruß, Nils

 

bearbeitet 26. Februar 2020 von NilsK

[Harris 2]

Bei uns wird wird der Bitlocker Wiederherstellungsschlüssel sowohl ins AD geschrieben, als auch auf einen Share auf unserem Fileserver. Ins AD werden die Schlüssel immer in den Computerkonten hinterlegt. Auf dem Share konnte ich schon feststellen, dass es nicht immer geklappt hat.

 

Wir haben im PDQ Deploy extra ein Paket erstellt, bei dem wir einstellen können mit welchem AD User Account das Powershellscript ausgeführt wird und für den User haben wir die Berechtigungen auf dem Share entsprechend angepasst.

[Wisi 12]

vor 23 Stunden schrieb Harris:

Bei uns wird wird der Bitlocker Wiederherstellungsschlüssel sowohl ins AD geschrieben, als auch auf einen Share auf unserem Fileserver. Ins AD werden die Schlüssel immer in den Computerkonten hinterlegt. Auf dem Share konnte ich schon feststellen, dass es nicht immer geklappt hat.

Nachdem du ja .txt Dateien hast, schau mal bitte rein, wer der Owner von der Datei ist, bzw. wer die erstellt hat. Wird das tatsächlich über den jeweils angemeldeten Benutzer erzeugt?

[Harris 2]

Besitzer ist bei mir "Administratoren" . Deployed wurde mit einem speziellen Deploy User.