für den IT-Administrator

Redaktion IT-Administrator

In jeder Ausgabe präsentiert Ihnen IT-Administrator Tipps, Tricks und Tools zu den aktuellen Betriebssystemen und Produkten, die in vielen Unternehmen im Einsatz sind. Wenn Sie einen tollen Tipp auf Lager haben, zögern Sie nicht und schicken Sie ihn per E-Mail an tipps@it-administrator.de.

Wir setzen im Unternehmen auf Microsoft 365, wollen aber nicht ausschließlich von Microsofts Endpoint Manager respektive Intune Gebrauch machen, um die Endgeräte der Anwender abzusichern und zu verwalten. Ist es möglich, die MDM-Werkzeuge anderer Anbieter mit Endpoint Manager zu verzahnen, und welche Voraussetzungen gilt es dabei zu beachten?

Die Intune-Funktionen im Endpoint Manager können auf Funktionen von externen Systemen zugreifen, um die Konformität von Endgeräten zu steuern. Das heißt, Unternehmen, die ein MDM-System nutzen, das kompatibel mit Microsoft 365 und Azure ist, können auch mit Microsoft Endpoint Manager arbeiten. Dabei kommen die Konformitätsregeln des externen Systems zum Einsatz. Hier ist es durchaus möglich, mehrere externe MDM-Systeme anzubinden, zum Beispiel eines für Android und ein anderes für iOS. Was hingegen nicht geht: an Endpoint Manager zwei Systeme anzubinden, die die gleiche Plattform nutzen. Es ist aber möglich, die MDM-Funktionen von Endpoint parallel zu den Funktionen des externen Systems zu nutzen. Hier definieren Sie über eine Priorität die Reihenfolge, in der die Richtlinien-Prüfung stattfinden soll.

Die Konformitätsregeln des externen MDM-Systems können auf dieser Basis als Grundlage für Richtlinien zum bedingten Zugriff auf Microsoft 365 und andere Azure-Ressourcen zum Einsatz kommen. So lassen sich etwa Geräte mit iOS/iPadOS und Android über ein externes Werkzeug an Microsoft Endpoint Manager anbinden und gemeinsam mit Computern auf Basis von Windows 10 und 11 sicher betreiben. Ebenso lässt sich macOS über diesen Weg steuern.

Für die Anbindung nutzt das externe MDM-Tool standardisierte APIs, die Microsoft in Endpoint Manager zur Verfügung stellt. Auch Endpoint Manager kann iOS und Android als MDM-System verarbeiten. Binden Sie ein weiteres System an, zum Beispiel MobileIron, legen Sie Prioritäten fest, worüber Sie steuern, welche Plattform Vorrang genießt bei der Auswertung, also Endpoint Manager oder das externe System. Aktuell unterstützt Endpoint Manager unter anderem folgende externe MDM-Systeme:

- Citrix Workspace Device Compliance

- MobileIron Device Compliance Cloud

- MobileIron Device Compliance On-Prem

- VMware Workspace ONE UEM (früher AirWatch)

Unter Umständen lassen sich noch weitere Systeme anbinden. Hier müssen Sie etwas experimentieren oder beim Hersteller nachfragen. Schlussendlich ist es wichtig, dass das externe MDM-System in der Lage ist, den Zustand der angebundenen Endgeräte an Endpoint zu senden. Microsoft erweitert die Liste der unterstützten Umgebungen ständig. Am einfachsten überprüfen Sie im Endpoint Admin Center bei "Mandantenverwaltung" über "Connectors und Token" und "Partnerkonformitätsverwaltung" den Menüpunkt "Konformitätspartner hinzufügen". Hier sehen Sie alle kompatiblen Systeme.

In unserem Unternehmen sind wir auf einen zuverlässigen Datenzugriff auf die Informationen in der AWS-Cloud angewiesen. Allerdings besteht durch die "Schwachstelle Mensch" stets das Risiko, dass Anmeldedaten kompromittiert werden und Hacker sich Zugang zu geschäftskritischen Daten verschaffen können. Wie lässt sich der Datenbestand schützen und verhindern, dass Cyberkriminelle Backups löschen oder manipulieren?

Datensicherheit ist eine essenzielle Anforderung an die IT-Infrastruktur. Daher legen besonders stark regulierte Branchen großen Wert auf ein WORM-Konzept (Write-Once-Read-Many) für Backups und Archive. Damit lassen sich unveränderliche Backups erstellen, sodass Firmen immer eine Sicherheitskopie zur Verfügung haben. Auf diese Weise ist eine Datenwiederherstellung auch nach Löschungen von Informationen möglich.

AWS-Nutzer werden beim Erstellen eines WORM-Backups durch AWS Backup unterstützt. Der vollständig verwaltete Service hilft dabei, die Datensicherung von AWS-Diensten zu zentralisieren und zu automatisieren – für sämtliche Archive und Datenbanken. In Verbindung mit AWS Organizations lassen sich zudem die Datenschutzrichtlinien zentral verwalten. Zudem können Firmen ihre Sicherungsaktivitäten über alle Regionen und Konten hinweg konfigurieren, verwalten und steuern.

Melden Sie sich zunächst bei der AWS-Managementkonsole an. Geben Sie dort in der Suchleiste "AWS Backup" ein und wählen Sie im Anschluss die "AWS Backup console" aus. Entscheiden Sie sich im Abschnitt "My account" für die Option "Backup Vaults" und danach für "Create Backup vault". Geben Sie nun einen "Backup vault name" und einen "Encryption key" an. Bestätigen Sie mit "Create Backup vault". Sobald Ihr Vault erfolgreich erstellt wurde, erscheint die Meldung: "Backup vault 'WORM_vault' has been created successfully".

Auch Backups mit automatischem Zyklus stellen kein Problem dar – im folgenden Beispiel erstellen wir eine Amazon RDS-Instanz (Amazon Relational Database Service) und eine On-Demand-Sicherung mit einer Aufbewahrungszeit von zwei Tagen. Diese Sicherung speichern wir im neu erstellten Sicherungsdepot "WORM_vault" und verändern zur Übung danach den Aufbewahrungszeitraum auf einen Tag:

1. Sobald der Datenspeicher für das Backup erstellt ist, gelangen Sie auf die Detail-Seite des Datenspeichers. Klicken Sie hier auf "Create on-demand backup".

2. Wählen Sie unter "Resource type" "RDS" und unter "Database name" "database-2".

3. Die "Retention period" setzen Sie auf "Days 2".

4. Nun wählen Sie unter "Backup vault" "WORM_vault" und als "IAM role" kommt "Default role" zum Einsatz.

5. Bestätigen Sie die Einstellungen mit "Create on-demand backup". Wichtig: Zu diesem Zeitpunkt haben Sie AWS Backup Vault Lock noch nicht aktiviert. Änderungen sind also weiterhin möglich.

6. Kehren Sie in den Backup-Vault zurück und wählen Sie dann den "Recovery point" im Bereich "Backups" aus.

7. Nachdem Sie auf "Edit" geklickt haben, gelangen Sie auf die "Recovery point detail page".

8. Klicken Sie unter "Backup summary" auf "Edit". Danach verändern Sie den Zeitraum von "Days 2" auf "Days 1". Bestätigen Sie mit "Save".

Bei der Neuinstallation eines Proxmox Singlehosts braucht es ja eigentlich ein Backup der Hypervisor-Ressourcen. Gibt es aber nicht vielleicht eine Möglichkeit, den Proxmox-Host neu zu installieren, ohne dass wir die VMs und Container vorher sichern müssen? Wir haben ZFS als Data-Pool im Einsatz und können eine kurze Downtime somit verkraften.

Beachten Sie, dass der folgende Lösungsweg nur funktioniert, wenn VMs und Container nicht auf den selben Devices liegen wie der Proxmox-Boot-Pool (rpool). Das Ausgangsszenario für unseren Tipp sieht dann folgendermaßen aus:

- Proxmox ZFS Singlehost mit VMs und Container

- 1x ZFS Mirror Pool für Proxmox OS (2x SSD)

- 1x ZFS RAIDZ2 Pool "zfs-data" für die VMs und Container (Ressourcen) (4x NVMe)

Folgende Punkte müssen Sie nun abarbeiten, damit Sie den Host neu installieren können: Zunächst bedarf es eines Backups der VM/LXC-Konfigurationen. Sichern Sie dazu sämtliche Konfigurationsdateien in diesen Pfaden:

Diese Dateien stellen die Konfigurationsdateien der Ressourcen dar. Dort ist unter anderem enthalten, wie die VMs / Container heißen, welche virtuelle Hardware diese verwenden und wie die virtuellen Festplatten benannt sind. Sichert man diese Dateien nicht, so fehlen alle "Hüllen" der VMs und Container. Sonstige Backups, die eventuell sinnvoll notwendig sein könnten, beziehen sich auf die Ordner "/etc/network/interfaces", "/etc/hosts" und "/etc/pve/storage.cfg".

Vor der Neuinstallation sollten Sie alle Ressourcen herunterfahren, damit die Daten persistent und konsistent sind. Nach dem Shutdown der VMs können Sie den Host herunterfahren und neu installieren. Beachten Sie hier, dass Sie auf keinem Fall die Datenträger des ZFS-DATA-Pools auswählen dürfen. Bei der Auswahl ist also besonders genau darauf zu achten, dass Sie die richtige(n) Festplatte(n) auswählen für den ZFS-Mirror – in unserem Fall zwei SSDs. Entscheiden Sie sich hier für die falschen Disks, kann es zu Datenverlust kommen, weil Proxmox die Festplatten, die Sie hier festlegen, löscht und mit PVE 7.X überschreibt. Nach der Installation von Proxmox VE importieren Sie den alten ZFS-Pool, indem Sie folgendes Kommando eingeben:

Nun müssen Sie noch mit einem geeigneten Tool (etwa SCP oder WINSCP) die Konfigurationsdateien wieder in den richtigen Verzeichnissen ablegen. Für VMs ist das "/etc/pve/qemu-server" und für Container "/etc/pve/lcx". Der Pool ist nun importiert, die VMs lassen sich aber noch nicht starten, weil noch die Storage-Definition fehlt. Deswegen müssen Sie den importierten ZFS-Pool "zfs-data" nun via GUI noch als Datastore hinterlegen. Alternativ können Sie den Definitions-Part aus "/etc/pve/storage.cfg" (siehe Bild) wieder hinzufügen, sofern Sie diese Datei im vorherigen Schritt gesichert haben. Jetzt sollten die VMs wieder lauffähig sein und sich wieder starten lassen. Ein Rechtsklick auf den Host und die Auswahl von "Bulk Start" sorgt für ein schnelles Anfahren aller VMs.

Damit sich ein importierter ZFS-Pool nutzen lässt, ist dieser zunächst wieder als Datastore zu hinterlegen.

Viele weitere Tipps und Tricks zum Servermanagement, Virtualisierung und Linux finden Sie im Thomas-Krenn-Wiki unter https://www.thomas-krenn.com/de/wiki/Hauptseite.

Beim Einsatz der NTFS-Berechtigungen auf Windows-Dateiservern kann es zu mannigfaltigen Problemen kommen, deren Ursache der Admin nicht immer auf den ersten Blick ausmachen kann. Sei es in Sachen Vererbung von Rechten oder auch Listenrechte, die eigentlich berechtigten Nutzern den Zugang zu Unterordnern verwehren. Zudem sind NTFS-Rechte ein Feld, bei dem IT-Verantwortliche zahlreiche Details in der Planung berücksichtigen müssen und das recht anfällig für manuelle Fehler bei der Verwaltung ist. Ist dann einmal etwas schiefgelaufen, macht es NTFS dem Admin nicht immer einfach, die Ursache zu ermitteln. Das freie "GNU ls for Microsoft Windows" adaptiert das ls-Kommandozeilenwerkzeug aus der Linux-Welt für Windows-Rechner und erlaubt so detaillierte Analysen der Dateirechte.

GNU ls for Microsoft Windows (kurz ls) hat nur eine Aufgabe: dem IT-Verantwortlichen alle Informationen zu Windows-Files bereitzustellen. Da es auf dem Linux-ls-Utility basiert und wie erwähnt den gleichen Job erledigt, haben die Entwickler in der Windows-Version diesen Namen einfach beibehalten. Gleichzeitig weisen sie ausdrücklich darauf hin, dass ihre Software nur von Personen genutzt werden sollte, die sich sehr gut mit NTFS auskennen.

Das ls-Tool liefert Dateiinformationen hinsichtlich ACL (DACL/SACL), Integritäts-Level, Wiederholungspunkte, Shortcuts, Hard und Symbolic Links, Zusatzinfos in NTFS-Rechten (hidden streams), Verschlüsselung, Virtualisierung, Object Tracking Identifier und dem Offline-Status. Die einzelnen Dateitypen zeigt ls in der Kommandozeilenausgabe in unterschiedlichen Farben an – normale Dateien in Weiß, Verzeichnisse in Grün, ausführbare Files in Gelb und so weiter. Was das Tool jedoch besonders auszeichnet, ist seine Geschwindigkeit. Durch die Nutzung der nativen Windows-API greift ls sehr schnell auf die angeforderten Infos zu. So soll sich beispielsweise der Ordner "Windows / System32" mit mehreren tausend Dateien über ein LAN in wenigen Sekunden auflisten lassen. Die für die

Files vergebenen Berechtigungen listet das Werkzeug ebenfalls auf, hier stehen "r", "w" und "x" für Lese-, Schreib- oder Ausführungsrechte. Diese vereinfachte Darstellung der NTFS-Rechte lässt sich mit dem Schalter "--view-security" erweitern, um die komplette ACL-Landschaft einer Datei einzusehen. Zudem zeigt es die Vererbung von Rechten an und berichtet dabei auch darüber, wie weit diese Vererbung in komplexen Ordnerstrukturen geht. GNU ls for Microsoft Windows bringt noch zahlreiche weitere Schalter zur NTFS-Analyse mit, die sich von der Dokumentation auf der Homepage des Tools erläutern lassen.

Link-Code: https://u-tools.com/msls/

Die Steuerung von Zugriffsrechten ist in jeder IT-Infrastruktur eine Herausforderung. Das gilt besonders für die Cloud, wo beispielsweise Externen Zugang gewährt werden soll oder auch, um Dienste wie Webserver vor unautorisierten Zugriffen zu schützen. An dieser Stelle ist es für IT-Verantwortliche sehr hilfreich, wenn sie für hybride Cloudinfrastrukturen ein einheitliches Regelwerk hinterlegen können. Genau dies ermöglicht das kostenlose Open-Source-Tool "Ory Oathkeeper".

Ory Oathkeeper kümmert sich um eingehende HTTP-Requests. Es kann als zentraler Punkt zur Umsetzung von Policies in Cloudarchitekturen arbeiten, beispielsweise als Reverse-Proxy vor einem Webserver. Die Software ist aber zudem in der Lage, sich in andere Gateways wie Kong, Nginx, Envoy, AWS-API-Gateway als Plug-in für die gleiche Aufgabe zu integrieren. Dabei bringt das Tool keinerlei Abhängigkeiten von anderen Diensten mit sich und benötigt keine eigene Datenbank oder sonstigen persistenten Storage. Auch bei der Konfiguration ist Oathkeeper flexibel, hier kann der Admin mit YAML- oder JSON-Dateien sowie Umgebungsvariablen arbeiten.

Ziel dieser Konfigurationen ist die "Decision Engine" der Software, die entscheidet, wie mit einer HTTP-Anfrage zu verfahren ist. Der Autorisierungsprozess besteht dabei aus vier Stufen:

1. Überprüfung der Zugangsregel: An dieser Stelle erfolgt ein Check, ob alle Parameter der Zugriffsanfrage den vom IT-Verantwortlichen gesetzten Regeln entsprechen. Schon an dieser Stelle lässt sich der Zugriff zurückweisen, wenn es zu wenig Übereinstimmungen gibt. Die an dieser Stelle ermittelten Daten wandern dann in die nächste Stufe.

2. Authentifizierung: Hier prüft Oathkeeper Credentials mit einer Reihe definierbarer Methoden.

3. Autorisierung: Diese vergibt auf Basis der Anmeldedaten die Berechtigungen zu Ressourcen. Benötigt ein API-Zugriff in einem sehr einfachen Beispiel Admin-Rechte, prüft die Software an dieser Stelle, ob die zuvor geprüften Credentials über derlei Rechte verfügen.

4. Mutation: An dieser Stelle kann das Regelwerk dem gewährten Zugriff noch spezielle Daten für diese Session übergeben. Und abschließend ist auch der gezielte Umgang mit Fehlern möglich und es lässt sich Oathkeeper mitteilen, wie zu verfahren ist, wenn in einem der vier Schritte etwas nicht funktioniert hat.

Das Tool läuft nach Angaben des Anbieters auf jedem Betriebssystem (FreeBSD, macOS, Linux, Windows et cetera) und unterstützt alle wichtigen CPU-Plattformen (ARM64, ARMv7, x86_64, x86). Ory Oathkeeper ist als Binary und als Docker-Image verfügbar.

Link-Code: https://www.ory.sh/docs/oathkeeper/

So hilfreich Gruppenrichtlinien bei der Verwaltung von Windows-Clients sind – läuft einmal etwas nicht wie gewünscht, kann die Ursachensuche schnell sehr aufwendig werden. Denn die Umsetzung der per GPO vergebenen Anweisungen erfolgt durch Einträge in die Windows-Registry. Und dies manuell zu prüfen, kostet den IT-Verantwortlichen Zeit und Nerven. Dies will das kostenlose "GPO Viewer" zu vermeiden helfen.

Die Grundfunktion von GPO Viewer besteht darin anzuzeigen, welche Gruppenrichtlinien auf eine Workstation angewandt wurden. Dies ermittelt die Software aus den Registry-Einträgen der jeweiligen Maschine. Dabei arbeitet das Tool auch remote und parallel, es lässt sich also die Registry von entfernten PCs auslesen und dabei mehrere Zielrechner gleichzeitg in der GPO-Viewer-GUI anzeigen. Zusätzlich listet das Tool die unterschiedlichen Anwender, die sich auf der Maschine eingeloggt haben. Alle Ergebnisse lassen sich zudem abspeichern, um sie entweder zu einem späteren Zeitpunkt einer genauen Analyse zu unterziehen oder um sie im zeitlichen Verlauf vergleichend zu betrachten.

Stößt der Nutzer eine GPO-Analyse mit GPO Viewer an, liefert die Software die Ergebnisse in zwei Sektionen zurück, getrennt nach Maschinen- und Nutzer-Policies. Beide Fenster zeigen ähnliche Inhalte und wie der Name schon andeutet, zeigt das Maschinen-Fenster GPO-Einstellungen, die auf diesen Rechner wirken. Im Nutzer-Fenster findet der Admin die unterschiedlichen Accounts, die sich auf diesem Gerät angemeldet haben, und welche Gruppenrichtlinien diese jeweils mitgebracht haben.