Bitlocker Cmdlets und Folder Redirection
Hallo zusammen,
ich stehe gerade vor zwei kleinen Problemen bzgl. des Einsatzes von Bitlocker in einer AD-Umgebung.
Nachdem ein Einsatz von Bitlocker Network Unlock nicht praktikabel funktioniert, habe ich mir folgendes überlegt:
Rechner bekommen eine Partitionierung verpasst (C und D eben). Auf dem C-Laufwerk sollen nur Programme und OS liegen. Die Partition wird einfach per TPM verschlüsselt, so dass die Clients nach wie vor managebar sind (u.a. Feature Upgrades per WoL etc.).
Die zweite Partition soll die Daten des Users beinhalten und wird zum einen per Zufallspasswort und zum anderen per AD-Account (die SID eben) des, ich sage Mal "Hauptusers" verschlüsselt. Soll heißen, ich als Admin kenne das Passwort, das wird zufällig per Powershell generiert und nur für die IT einsehbar abgelegt. Oder eben der entsprechende User meldet sich an dem Rechner mit seinen AD-Credentials an.
Folgende Probleme habe ich nun:
1. Meldet sich der User einmal an, ist die Partition bis zum nächsten Shutdown entschlüsselt.
Dazu habe ich Tasks in der Aufgabenplanung angelegt, die die Partition wieder verschlüsseln, wenn sich der angemeldete User abmeldet oder den Rechner sperrt.
Mein Problem dabei ist allerdings, dass der Task, der die Partition beim Entsperren des Rechners wieder freigeben soll nicht funktioniert.
Beim Entsperren wird folgendes ausgeführt:
Eine SID o.Ä. kann ich ja nicht mitgeben, was bedeutet das Skript müsste mit den Berechtigungen des Users laufen. Dem wird der Zugriff aber verweigert. Lasse ich es als lokaler Admin oder lokales System laufen, gelingt der Zugriff aber die Entschlüsselung nicht.
Gibt es hier einen Weg das irgendwie hinzubekommen, dass der User nachdem er seinen Rechner ge- und entsperrt hat wieder Zugriff auf das Laufwerk bekommt ohne die IT nach dem PW zu fragen?
2. Der User kann in sein Userverzeichnis schreiben, das auf C liegt, was das ganze Unterfangen ad absurdum führen würde. Das Userverzeichnis umzuziehen ist eher nicht empfohlen von MS, ich kann allerdings die Unterordner wie AppData, Desktop, etc redirecten nach D, allerdings bleibt ja das Userverzeichnis auf C beschreibbar.
Gibt es hier eine Möglichkeit dem User die Möglichkeit zu nehmen überhaupt irgendwohin auf das C-Laufwerk zu schreiben, so dass er seine Daten auf das verschlüsselte D-Laufwerk ablegen muss, wenn er diese unbedingt lokal benötigt?
Ich hoffe ich konnte das Problem einigermaßen verständlich erklären.
ich stehe gerade vor zwei kleinen Problemen bzgl. des Einsatzes von Bitlocker in einer AD-Umgebung.
Nachdem ein Einsatz von Bitlocker Network Unlock nicht praktikabel funktioniert, habe ich mir folgendes überlegt:
Rechner bekommen eine Partitionierung verpasst (C und D eben). Auf dem C-Laufwerk sollen nur Programme und OS liegen. Die Partition wird einfach per TPM verschlüsselt, so dass die Clients nach wie vor managebar sind (u.a. Feature Upgrades per WoL etc.).
Die zweite Partition soll die Daten des Users beinhalten und wird zum einen per Zufallspasswort und zum anderen per AD-Account (die SID eben) des, ich sage Mal "Hauptusers" verschlüsselt. Soll heißen, ich als Admin kenne das Passwort, das wird zufällig per Powershell generiert und nur für die IT einsehbar abgelegt. Oder eben der entsprechende User meldet sich an dem Rechner mit seinen AD-Credentials an.
Folgende Probleme habe ich nun:
1. Meldet sich der User einmal an, ist die Partition bis zum nächsten Shutdown entschlüsselt.
Dazu habe ich Tasks in der Aufgabenplanung angelegt, die die Partition wieder verschlüsseln, wenn sich der angemeldete User abmeldet oder den Rechner sperrt.
Mein Problem dabei ist allerdings, dass der Task, der die Partition beim Entsperren des Rechners wieder freigeben soll nicht funktioniert.
Beim Entsperren wird folgendes ausgeführt:
Unlock-Bitlocker -MountPoint "D:" -AdAccountOrGroup Gibt es hier einen Weg das irgendwie hinzubekommen, dass der User nachdem er seinen Rechner ge- und entsperrt hat wieder Zugriff auf das Laufwerk bekommt ohne die IT nach dem PW zu fragen?
2. Der User kann in sein Userverzeichnis schreiben, das auf C liegt, was das ganze Unterfangen ad absurdum führen würde. Das Userverzeichnis umzuziehen ist eher nicht empfohlen von MS, ich kann allerdings die Unterordner wie AppData, Desktop, etc redirecten nach D, allerdings bleibt ja das Userverzeichnis auf C beschreibbar.
Gibt es hier eine Möglichkeit dem User die Möglichkeit zu nehmen überhaupt irgendwohin auf das C-Laufwerk zu schreiben, so dass er seine Daten auf das verschlüsselte D-Laufwerk ablegen muss, wenn er diese unbedingt lokal benötigt?
Ich hoffe ich konnte das Problem einigermaßen verständlich erklären.
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 484559
Url: https://administrator.de/forum/bitlocker-cmdlets-und-folder-redirection-484559.html
Ausgedruckt am: 28.04.2025 um 05:04 Uhr
13 Kommentare
Neuester Kommentar
Wow Okay keine Ahnung wie Du darauf gekommen bist, aber was spricht denn dagegen einfach den gängigen Standard zu verwenden?
Dieser nach meiner bescheidenden Meinung wäre:
Eine Partition reicht völlig, ggf durch Autodeploy installation. Diese wird automatisch per TPM entschlüsselt.
Benutzer dürfen halt NICHT Administrator sein.
Ein "Homelaufwerk" wird per GPO verbunden und Offline Dateien sind aktiviert damit ist das Laufwerk immer vorhanden.
Mit Ordnerumleitung Ordner wie Dokumente Bilder etc. auf dieses Laufwerk umleiten.
Per GPO kann man Benutzern verbieten weitere Ordner auf C: Anzulegen das verhindert Daten außerhalb der Profil Ordners.
Fazit: ein normaler Windows Client. Laufwerk ist verschlüsselt, Vollzugriff haben nur Administratoren. Der Benutzer wird nicht mit Partitionen oder Unnötigen Verschlüsselungen verwirrt. Der Bitlocker Key steht nur den Domain Admins zur Verfügung, ein evtl. schwaches Kennwort existiert gar nicht erst. Alle Benutzerdaten sind auf Wunsch in einer zentralen Datensicherung enthalten. Das gesamte vorgehen wird von MS Support und teilweise empfohlen. Und es gibt Anleitungen und Artikel dazu.
Dieser nach meiner bescheidenden Meinung wäre:
Eine Partition reicht völlig, ggf durch Autodeploy installation. Diese wird automatisch per TPM entschlüsselt.
Benutzer dürfen halt NICHT Administrator sein.
Ein "Homelaufwerk" wird per GPO verbunden und Offline Dateien sind aktiviert damit ist das Laufwerk immer vorhanden.
Mit Ordnerumleitung Ordner wie Dokumente Bilder etc. auf dieses Laufwerk umleiten.
Per GPO kann man Benutzern verbieten weitere Ordner auf C: Anzulegen das verhindert Daten außerhalb der Profil Ordners.
Fazit: ein normaler Windows Client. Laufwerk ist verschlüsselt, Vollzugriff haben nur Administratoren. Der Benutzer wird nicht mit Partitionen oder Unnötigen Verschlüsselungen verwirrt. Der Bitlocker Key steht nur den Domain Admins zur Verfügung, ein evtl. schwaches Kennwort existiert gar nicht erst. Alle Benutzerdaten sind auf Wunsch in einer zentralen Datensicherung enthalten. Das gesamte vorgehen wird von MS Support und teilweise empfohlen. Und es gibt Anleitungen und Artikel dazu.
Hi.
Eine Frage: warum möchtest Du die Partition denn bei Abmeldung sperren? (bitte schreibe nicht "entschlüsseln", denn es wird nie entschlüsselt, sondern lediglich entsperrt)
Eine Frage: warum möchtest Du die Partition denn bei Abmeldung sperren? (bitte schreibe nicht "entschlüsseln", denn es wird nie entschlüsselt, sondern lediglich entsperrt)
Der Gedanke kam daher, dass wir eben keine kritischen Daten ungeschützt auf den Laptops liegen haben wollen. Ist z.B. ein Kollege beim Kunden vor Ort mit sensiblen Informationen darauf, sollten diese geschützt sein.
Wenn wir den User ein Home Laufwerk mit Offline Daten zur Verfügung stellen, dann hat ein Angreifer, der das Gerät in die Finger bekommt noch immer die Möglichkeit das Gerät in einer abgeschotteten Umgebung zu booten und anschließend über das Netzwerk anzugreifen und bei Erfolg die Daten abzuziehen. Liegen die sensiblen Infos aber auf einer zweiten gesperrten Partition kommt er da erst Mal gar nicht ran.
Und diese Partition möchte ich bei der Abmeldung eben wieder sperren, da diese ja ansonsten entsperrt bleibt. Meldet sich User A, der Zugriff hat, von Rechner ab und User B, der keinen Zugriff haben soll, danach an, so ist die Partition entsperrt. Das sollte nicht sein.
Ich weiß, dass der sauberste Weg wäre die Mitarbeiter anzuleiten sensible Daten auf den Servern zu sichern und bei Vor-Ort-Terminen beim Kunden andere Möglichkeiten bereit gestellt werden sollten um von dort aus auf diese Daten zuzugreifen. Eine solche Lösung befindet sich im Aufbau, aber bis dahin muss eine andere Lösung gefunden werden. Außerdem sollen Laptops grundsätzlich bei uns per Bitlocker geschützt werden.
Wenn wir den User ein Home Laufwerk mit Offline Daten zur Verfügung stellen, dann hat ein Angreifer, der das Gerät in die Finger bekommt noch immer die Möglichkeit das Gerät in einer abgeschotteten Umgebung zu booten und anschließend über das Netzwerk anzugreifen und bei Erfolg die Daten abzuziehen. Liegen die sensiblen Infos aber auf einer zweiten gesperrten Partition kommt er da erst Mal gar nicht ran.
Und diese Partition möchte ich bei der Abmeldung eben wieder sperren, da diese ja ansonsten entsperrt bleibt. Meldet sich User A, der Zugriff hat, von Rechner ab und User B, der keinen Zugriff haben soll, danach an, so ist die Partition entsperrt. Das sollte nicht sein.
Ich weiß, dass der sauberste Weg wäre die Mitarbeiter anzuleiten sensible Daten auf den Servern zu sichern und bei Vor-Ort-Terminen beim Kunden andere Möglichkeiten bereit gestellt werden sollten um von dort aus auf diese Daten zuzugreifen. Eine solche Lösung befindet sich im Aufbau, aber bis dahin muss eine andere Lösung gefunden werden. Außerdem sollen Laptops grundsätzlich bei uns per Bitlocker geschützt werden.
Meldet sich User A, der Zugriff hat, von Rechner ab und User B, der keinen Zugriff haben soll, danach an, so ist die Partition entsperrt.
Dann setze bitte NTFS-Rechte passend und fertig. Nutzer B kommt dann zu keinem Zeitpunkt ran und hat keine Möglichkeit, das zu ändern.Wenn Du dagegen bist, es so zu machen (gute Gründe dagegen gibt es nicht, dass kann ich versichern), dann wäre folgender Workaround möglich:
Erstelle einen geplanten Task, der immer bei Abmeldung von User A das Laufwerk sperrt. Locktask wäre
manage-bde -lock d:Trigger: Abmeldung von User A.
Bei Anmeldung von A greift seine SID zum entsperren.
Ja genau das tue ich doch und das funktioniert auch.
Der User sperrt den Rechner oder meldet sich ab, in dem Moment läuft als System ein Task, der die Partition sperrt. Das funktioniert auch.
Meldet sich der User ab wird also gesperrt, meldet er sich wieder an, wird die Partition entsperrt. Alles gut, dieser Use Case funktioniert problemlos.
Sperrt der User den Rechner nur, wird die Partition auch gesperrt. Das funktioniert auch. Entsperrt der User seinen Rechner, läuft eben nicht sein üblicher Loginvorgang ab und die Partition bleibt entsperrt. Und genau das ist mein Problem.
Ich habe einen Task angelegt, der als Trigger "On Work Station unlock" hat, der läuft auch, tut aber nicht das, was er soll. Der Rechner kennt das Passwort nicht, soll er auch nicht, also soll er der Task wieder versuchen mit oben genanntem Skript die Partition wieder zu entsperren eben mit dem AdAccountOrGroup Protector. Und da hab ich das Problem, dass der User die Entsperrung nicht initiieren darf, er hat keine Berechtigung dazu, aber als Local System natürlich der Protector nicht greift, da dann der AdAccountOrGroup Parameter den Local System Account übergibt, welcher falsch ist.
NTFS Berechtigungen allein würden mir nicht helfen, da die Platte sonst ausgebaut und ausgelesen werden kann, da hier einfach der Besitz übernommen werden kann.
Es muss also ein Schutz her, der auch das abfängt. TPM lässt Bitlocker auf Non-OS-Partitionen nicht zu.
Der User sperrt den Rechner oder meldet sich ab, in dem Moment läuft als System ein Task, der die Partition sperrt. Das funktioniert auch.
Meldet sich der User ab wird also gesperrt, meldet er sich wieder an, wird die Partition entsperrt. Alles gut, dieser Use Case funktioniert problemlos.
Sperrt der User den Rechner nur, wird die Partition auch gesperrt. Das funktioniert auch. Entsperrt der User seinen Rechner, läuft eben nicht sein üblicher Loginvorgang ab und die Partition bleibt entsperrt. Und genau das ist mein Problem.
Ich habe einen Task angelegt, der als Trigger "On Work Station unlock" hat, der läuft auch, tut aber nicht das, was er soll. Der Rechner kennt das Passwort nicht, soll er auch nicht, also soll er der Task wieder versuchen mit oben genanntem Skript die Partition wieder zu entsperren eben mit dem AdAccountOrGroup Protector. Und da hab ich das Problem, dass der User die Entsperrung nicht initiieren darf, er hat keine Berechtigung dazu, aber als Local System natürlich der Protector nicht greift, da dann der AdAccountOrGroup Parameter den Local System Account übergibt, welcher falsch ist.
NTFS Berechtigungen allein würden mir nicht helfen, da die Platte sonst ausgebaut und ausgelesen werden kann, da hier einfach der Besitz übernommen werden kann.
Es muss also ein Schutz her, der auch das abfängt. TPM lässt Bitlocker auf Non-OS-Partitionen nicht zu.
Schließ' einfach aus, dass jemand fast user Switching benutzt: schalte es aus. Dann kann sich niemand anmelden, während die Partition entsperrt ist.
NTFS Berechtigungen allein würden mir nicht helfen, da die Platte sonst ausgebaut und ausgelesen werden kann, da hier einfach der Besitz übernommen werden kann.
Äh, Du hast da etwas nicht verstanden. Wenn ausgebaut, dann aktiviert sich der Bitlocker-Schutz von alleine, da Kabel abgezogen werden, und dann kommt niemand mehr an die NTFS-Rechte.
Moin,
Das verstehe ich, wie DWW, ebenfalls nicht:
Die Disk/ Partition ist verriegelt, wenn der Strom weg ist.
Aber mal eine andere Frage:
Was gedenkst du, soll geschehen, wenn jemand den Client gesperrt hat, aber noch agiles offen sind?
Bin kein Bitlocker-Experte, aber nach meinem Gusto würde Bitlocker die Partition nicht sperren können, oder!?
Bitte korrigieren, falls ich falsch liege. Aber wie gesagt, bin da kein Experte...
Das verstehe ich, wie DWW, ebenfalls nicht:
Die Disk/ Partition ist verriegelt, wenn der Strom weg ist.
Aber mal eine andere Frage:
Was gedenkst du, soll geschehen, wenn jemand den Client gesperrt hat, aber noch agiles offen sind?
Bin kein Bitlocker-Experte, aber nach meinem Gusto würde Bitlocker die Partition nicht sperren können, oder!?
Bitte korrigieren, falls ich falsch liege. Aber wie gesagt, bin da kein Experte...
Klar wäre die Partition gesperrt, wenn ich noch einen Protector drauf habe. Aber wie gesagt eine Non-OS-Partition kann ich nur per Passwort, AD Account o.Ä. sperren.
Meinte damit eben, dass nur NTFS Berechtigungen nicht genügen würden.
Wenn der User den Rechner sperrt und irgendetwas greift noch auf die Partition zu, wird diese nicht gesperrt. Ich kann den Lock aber auch mit dem ForceDismount Parameter laufen lassen, dann wird die Sperrung erzwungen.
Meinte damit eben, dass nur NTFS Berechtigungen nicht genügen würden.
Wenn der User den Rechner sperrt und irgendetwas greift noch auf die Partition zu, wird diese nicht gesperrt. Ich kann den Lock aber auch mit dem ForceDismount Parameter laufen lassen, dann wird die Sperrung erzwungen.
Nein, du probierst es jetzt bitte einmal aus, damit Du klar siehst.
Unterscheide bitte Bitlocker suspended und Bitlocker unlocked. Nur bei ersterem kann man die Platte einfach ausbauen und auslesen, nicht bei letzterem - völlig egal, was für ein Protektor im Einsatz ist. Die NTFS-Rechte reichen somit aus.
Wenn Du das mit dem Fast-User-Switching probieren möchtest (es wäre Deine Lösung), dann siehe https://www.technipages.com/windows-10-enable-or-disable-fast-user-switc ...
Das nimmt deinen Usern B,C,... die Möglichkeit, sich anzumelden, während A seine Sitzung gesperrt hat.
Unterscheide bitte Bitlocker suspended und Bitlocker unlocked. Nur bei ersterem kann man die Platte einfach ausbauen und auslesen, nicht bei letzterem - völlig egal, was für ein Protektor im Einsatz ist. Die NTFS-Rechte reichen somit aus.
Wenn Du das mit dem Fast-User-Switching probieren möchtest (es wäre Deine Lösung), dann siehe https://www.technipages.com/windows-10-enable-or-disable-fast-user-switc ...
Das nimmt deinen Usern B,C,... die Möglichkeit, sich anzumelden, während A seine Sitzung gesperrt hat.
Suspend schaltet den Bitlocker ab, dann kann. Ich die Platte ausbauen, ist mir klar. Habe ich gar keinen Bitlocker und nur NTFS Berechtigungen, dann geht das auch, das meinte ich damit.
Jeglicher Bitlocker Protector sperrt die Platte beim Ausbau, das ist mir klar.
Fast User Switching verbieten würde verhindern, dass sich ein zweiter User parallel abmeldet und die Partition auslesen kann, ja. Heißt aber auch, dass die Partition über die komplette Zeit der Sitzung immer entsperrt ist, auch wenn der User seinen Laptop gerade gesperrt hat. Dann habe ich in diesem Fall denselben Schutz, wie bei einem Schutz per TPM. Ausbauen nicht möglich, aber der Angriffsvektor Netzwerk würde bleiben.
Jeglicher Bitlocker Protector sperrt die Platte beim Ausbau, das ist mir klar.
Fast User Switching verbieten würde verhindern, dass sich ein zweiter User parallel abmeldet und die Partition auslesen kann, ja. Heißt aber auch, dass die Partition über die komplette Zeit der Sitzung immer entsperrt ist, auch wenn der User seinen Laptop gerade gesperrt hat. Dann habe ich in diesem Fall denselben Schutz, wie bei einem Schutz per TPM. Ausbauen nicht möglich, aber der Angriffsvektor Netzwerk würde bleiben.
Mein letzter Versuch.
Der "Angriffsvektor Netzwerk" muss doch überhaupt nicht bestehen. Warum bietet dein Client diesen? Welche Ports hat er denn offen?
Und warum kümmert dich dieser Angriffsvektorr nur dann, wenn der PC gesperrt ist? Bei Benutzung gilt der doch genau so.
--
Zurück zu
Der "Angriffsvektor Netzwerk" muss doch überhaupt nicht bestehen. Warum bietet dein Client diesen? Welche Ports hat er denn offen?
Und warum kümmert dich dieser Angriffsvektorr nur dann, wenn der PC gesperrt ist? Bei Benutzung gilt der doch genau so.
--
Zurück zu
Mein Problem dabei ist allerdings, dass der Task, der die Partition beim Entsperren des Rechners wieder freigeben soll nicht funktioniert.
Nimm als ausführendes Konto das Systemkonto zusammen mit dem Recoverykey und alles ist gut. Habe ich gerade eben hier so probiert und es läuft! Pack die Zeilemanage-bde -unlock d: -rp 591261-271997-...deinKey...-626967-102080-687071-440407-528561
in eine Batch, die Du nur für das Systemkonto lesbar machst.
Der Angriffsvektor interessiert mich, da doch der ein oder andere Port offen ist auf unseren Clients, da diese benötigt werden, sei es durchs Client Management System, dem Virenscanner oder eben die administrativen Freigaben (ja Berechtigungen dafür sind sauber gesetzt).
Wenn der Rechner gesperrt und nicht beaufsichtigt ist, möchte ich eben, dass diese Daten geschützt sind. Sitzt der User davor, klar dann wäre dieser Vektor zwar offen, aber arbeiten muss der User ja auch irgendwie.
Wie ich den Task ausführen könnte um die Entsperrung generell möglich zu machen, weiß ich. Ich hab mich durchaus mit den Cmdlets von Bitlocker beschäftigt.
In diesem Fall, die Partition per Rec Key zu entsperren, muss ich vorher aber Einschränkungen vornehmen. Entweder dürfen sich nur Admins und der Hauptuser am Rechner anmelden oder das Skript prüft vorher welcher User angemeldet ist und vergleicht dies damit ob er der richtige ist. Tue ich das nicht, kann ein eigentlich nicht berechtigter User sich anmelden, den Rechner sperren, ihn wieder entsperren und hat Zugriff. Heißt ich müsste neben dem Rec Key oder dem Passwort auch noch den berechtigten User in der Batchdatei hinterlegen.
Daran hatte ich auch schon gedacht, wollte aber erst ausloten ob es andere Möglichkeiten gibt, denn ich wollte keine Datei mit den potentiellen Entsperrungsdaten auf der C-Partition liegen haben, das würde für mich eine Lücke im Konzept darstellen (NTFS Berechtigungen hin oder her).
Scheinbar habe ich aber keine andere Möglichkeit.
Wenn der Rechner gesperrt und nicht beaufsichtigt ist, möchte ich eben, dass diese Daten geschützt sind. Sitzt der User davor, klar dann wäre dieser Vektor zwar offen, aber arbeiten muss der User ja auch irgendwie.
Wie ich den Task ausführen könnte um die Entsperrung generell möglich zu machen, weiß ich. Ich hab mich durchaus mit den Cmdlets von Bitlocker beschäftigt.
In diesem Fall, die Partition per Rec Key zu entsperren, muss ich vorher aber Einschränkungen vornehmen. Entweder dürfen sich nur Admins und der Hauptuser am Rechner anmelden oder das Skript prüft vorher welcher User angemeldet ist und vergleicht dies damit ob er der richtige ist. Tue ich das nicht, kann ein eigentlich nicht berechtigter User sich anmelden, den Rechner sperren, ihn wieder entsperren und hat Zugriff. Heißt ich müsste neben dem Rec Key oder dem Passwort auch noch den berechtigten User in der Batchdatei hinterlegen.
Daran hatte ich auch schon gedacht, wollte aber erst ausloten ob es andere Möglichkeiten gibt, denn ich wollte keine Datei mit den potentiellen Entsperrungsdaten auf der C-Partition liegen haben, das würde für mich eine Lücke im Konzept darstellen (NTFS Berechtigungen hin oder her).
Scheinbar habe ich aber keine andere Möglichkeit.
Du kannst im Task sagen: Trigger: bei Anmeldung von User X. Das ist doch, was Du suchst.
Zu deinen Ports: genereller Hinweis: diese Ports werden doch nicht generell geöffnet, sondern nur zu bestimmten IPs hin bzw. noch besser zu bestimmten Identitäten hin (Kerberos-Authentifizierung). Somit ist das in einem gesicherten Netzwerk kein Problem.
Zu deinen Ports: genereller Hinweis: diese Ports werden doch nicht generell geöffnet, sondern nur zu bestimmten IPs hin bzw. noch besser zu bestimmten Identitäten hin (Kerberos-Authentifizierung). Somit ist das in einem gesicherten Netzwerk kein Problem.
