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.

Bei der Kontrolle des Active Directory sind wir auf einige alte Accounts gestoßen, die ihr Passwort niemals ändern müssen. Gibt es eine Möglichkeit, Konten ohne Passwortablauf übersichtlich aufzulisten?

Obwohl der monatliche Wechsel von Passwörtern weit verbreitet ist, betrachten Fachleute diese Passwortrichtlinie mittlerweile als ein Sicherheitsrisiko: Ein schnelles Ablaufdatum führt dazu, dass Nutzer kurze, wenig komplexe und damit unsichere Passwörter verwenden. Für den Schutz vor unberechtigten Zugriffen spielen die Länge des Passworts, der Einsatz von Multifaktor-Authentifizierung und ein Berechtigungskonzept nach dem Least-Privilege-Prinzip eine weit wichtigere Rolle. Konten, bei denen der Passwortablauf unbeabsichtigt vergessen wurde, verdienen dennoch eine Kontrolle. Bestehen diese Accounts seit langem, erfüllt das derzeitige Passwort vermutlich nicht die empfohlenen Sicherheitsstandards. Bei alten Passwörtern besteht außerdem die Gefahr, dass diese aufgrund der mehrfachen Verwendung durch User in geleakten Passwortdatenbanken zu finden sind.

Der einfachste Weg, Konten ohne Passwortablauf zu finden, ist eine Software zur Benutzerverwaltung, die diese Einstellung automatisch erkennt. Eine Liste an entsprechenden Konten lässt sich aber auch über das PowerShell-Cmdlet "Get-ADUser" und den Filter "PasswordNeverExpires" erstellen. Alternativ kann das Cmdlet "Search-ADAccount" Verwendung finden. Ein fertiges Skript könnte zum Beispiel so aussehen:

Die PowerShell liefert nun eine Liste aller aktiven Konten, für deren Passwörter kein Ablaufdatum festgelegt ist. Der Parameter "-Properties PasswordLastSet" zeigt darüber hinaus an, wann das Passwort für ein Konto zuletzt geändert wurde. Der regelmäßige, beispielsweise jährliche Wechsel des Passworts wird etwa für Service Accounts empfohlen, um den Zugriff auf sensible Systeme abzusichern. Noch mehr Sicherheit bieten Managed Service Accounts, die ihre Passwörter automatisch tauschen.

Weitere Tipps zum Thema Active Directory finden Sie im IAM-Blog von tenfold unter https://tenfold-security.com/ratgeber//.

Bei blockbasiertem Storage lässt sich die I/O-Last mit verschiedenen Multipathing-Methoden über die verfügbaren Pfade verteilen. Was ist hier die beste Auswahl, um die Performance in einer VMware-ESXi-Umgebung zu optimieren?

Für Multipathing stehen mehrere Algorithmen zur Verfügung: Bei "Most Recently Used" wird für jede logische Festplatte (LUN) einer der verfügbaren Pfade gewählt. Fällt dieser aus, nutzt ESXi einen beliebigen anderen. Steht der ausgefallene Pfad wieder zur Verfügung, kommt er nicht wieder zum Einsatz, es sei denn, er ist der einzig mögliche. Somit ist dieser Algorithmus nicht wirklich gut geeignet, die Last über alle verfügbaren Pfade zu verteilen. Einen Vorteil bietet er allerdings: Er ist mit jedem Storage-System kompatibel.

Bei "Fixed" können Sie für jede LUN einen bevorzugten Pfad angeben. Fällt der bevorzugte Pfad temporär aus, fällt die Wahl auf einen anderen Pfad, bis der bevorzugte wieder zur Verfügung steht. Zwar haben Sie für jede einzelne LUN nur maximal die Geschwindigkeit eines einzelnen Pfades verfügbar, bei ausreichender Anzahl an LUNs lassen sich aber trotzdem alle Pfade einigermaßen gleichmäßig auslasten. Besteht ein Ungleichgewicht in der Auslastung, können Sie einzelne LUNs auch im laufenden Betrieb auf einen anderen bevorzugten Pfad verlegen.

"Round Robin" schließlich ist, was die Lastverteilung angeht, der eleganteste Algorithmus. Die Last wird für jede einzelne LUN über alle verfügbaren Pfade verteilt. Als Standardwert wechselt ESXi nach jeweils 1000 I/Os den Pfad der jeweiligen LUN. Ob hier der Wert von 1000 optimal ist, müssen Sie der Dokumentation des Herstellers entnehmen. Die Angaben reichen von "egal" bis zu "Pfadwechsel nach jedem I/O". Als Beispiel zeigt das Bild die nötigen Kommandos, um alle LUNs eines bestimmten Herstellers auf "Round Robin" mit dem vom Hersteller empfohlenen Wert des Pfadwechsels nach jeweils zehn I/Os zu stellen.

Während "Most Recently Used" mit jedem Storage-System kompatibel ist, müssen Sie bei Fixed und Round Robin in der Herstellerdokumentation überprüfen, ob das jeweilige Storage-System diese unterstützt. Hierbei sind unbedingt eventuelle Angaben zu benötigten Softwareständen des Storage-Systems zu beachten. Die Multipathing-Einstellungen den jeweiligen Herstelleranforderungen anzupassen, kann deutliche Vorteile bringen.

Bei über NFS angesprochenen Storage-Systemen findet die Lastverteilung auf der Netzwerkebene statt. Ein einzelner VMkernel-Port, der bevorzugt mit dem NFS-Storage-System im selben Netz (VLAN) liegt, ist hier ausreichend. Die für diesen VMkernel-Port verwendete Portgruppe stellen Sie auf "IP Hash Load Balancing" und das Storage-System versehen Sie mit mindestens so vielen IP-Adressen, wie auf den ESXi-Netzwerkkarten für den NFS-Zugriff zum Einsatz kommen. Dies erfordert allerdings eine Link Aggregation Group – statisch oder mit Link Aggregation Control Protocol – auf den physischen Switches, an die ESXi angeschlossen ist. Aus Redundanzgründen sollten Sie außerdem die Netzwerkkarten der ESXi-Hosts auf mindestens zwei physische Switches verteilen. Hierzu ist es nötig, Switches einzusetzen, die LAGs auch gehäuseübergreifend unterstützen.

(Torsten Mutayi/ln)

Gibt es einen leichten Weg, in unserer VMware-Umgebung eine Linked-Clone-VM in eine Standalone-VM zu konvertieren?

Ein verknüpfter Klon ist eine virtuelle Maschine, die sich die virtuellen Festplatten mit der übergeordneten virtuellen Maschine teilt. Durch diese Technologie können mehrere virtuelle Maschinen die Software nutzen, die auf der Festplatte der übergeordneten virtuellen Maschine installiert ist. Auf diese Weise können Benutzer Speicherplatz auf der Festplatte einsparen. Bislang gab es keine einfache Möglichkeit, eine geklonte virtuelle Maschine in eine eigenständige VM zu verwandeln. Das bedeutet bisher, dass Sie die verknüpfte Eltern-Maschine immer mitführen müssen. Doch je größer die virtuelle Maschine wird, desto mehr Datenlast gilt es zu speichern, da auch immer die gesamte verknüpfte Klonkette mitgedacht werden muss.

Es gibt komplizierte Lösungen, um beispielsweise mit einem Linux-Tool Partitionen zu kopieren oder den Rechner so "einzufangen", als ob er physisch wäre. Doch diese Prozesse sind kompliziert. Doch die neue Version Parallels Desktop 17 hat eine einfache Lösung für dieses Problem in der Pro und Business Edition eingeführt und ermöglicht die Konvertierung eines Linked Clones in eine Standalone-VM mit nur zwei Klicks. Dazu verwenden Sie entweder eine neue UI-Option oder Parallels Desktop CLI.

Wählen Sie dazu im Kontrollcenter die verknüpfte geklonte VM aus, die Sie von der übergeordneten VM entkoppeln wollen. Öffnen Sie mit der rechten Maustaste das Menü und klicken Sie auf die Schaltfläche "Unlink Clone". Mit diesen zwei Klicks wird die geklonte VM in eine eigenständige VM überführt. Ist der Prozess abgeschlossen, erhalten Sie eine Standalone-VM, die Sie ohne die Eltern-Maschine nutzen können.

Wir nutzen zum Monitoring unseres Netzwerks im Unternehmen die Software Paessler PRTG Network Monitor. In der Vergangenheit haben wir größtenteils Windows-Komponenten überwacht. Seit Kurzem haben wir aber auch Linux-Geräte im Einsatz. Jetzt möchten wir einige Dienste auf diesen Rechnern überwachen. Geht das mit PRTG, und falls ja, wie sollen wir am besten vorgehen?

Zum Monitoring und zur Meldung des aktuellen Status eines Linux-Diensts mittels PRTG gibt es in der Knowledge Base von Paessler ein fertiges Skript, das Sie frei verwenden können. Das Skript prüft, ob der gewünschte Dienst verfügbar ist oder nicht. Wenn der Dienst zur Verfügung steht, sendet das Skript den Status "1" (Dienst verfügbar) an PRTG. Das Skript kann außerdem auch Sensormeldungen übermitteln, wie "$service läuft", "$service ist ausgefallen", "$service wurde ordnungsgemäß neu gestartet" oder "$service kann nicht ordnungsgemäß neu gestartet werden". Das Ergebnis des Skripts läuft dazu an einen HTTP-Push-Data-Sensor in PRTG. Zur Einrichtung in PRTG benötigen Sie das Skript, das Sie in Ihrem Linux-System einrichten. Außerdem müssen Sie den erwähnten HTTP-Push-Data-Sensor in PRTG hinzufügen. In der Paessler Knowledge Base ist der komplette Vorgang Schritt für Schritt beschrieben. Dort können Sie auch das einsatzbereite Skript herunterladen. Den KB-Artikel finden Sie unter [Link-Code: https://kb.paessler.com/en/topic/70771-how-can-i-monitor-and-automatically-restart-a-service-on-a-linux-host/].

Für viele weitere Tipps und Tricks rund um das Thema Monitoring mit PRTG bietet Paessler unter [Link-Code: https://www.youtube.com/c/PRTGNetworkMonitorByPAESSLER?utm_source=itadministrator&utm_medium=referral&utm_campaign=tipps/] auch einen Youtube-Kanal mit Tutorials an.

In unserer AWS-Cloudumgebung befinden sich geschäftskritische Daten und Anwendungen, auf deren ständige Verfügbarkeit wir angewiesen sind. Dennoch lassen sich Störfälle nicht immer vollständig vermeiden. Wenn diese eintreten, gilt es, schnell die Ursache zu finden, sie zu beseitigen und den normalen Betrieb wiederherzustellen. Wie können wir solche Ereignisse zeitnah beheben?

Beim Verhindern von Störfällen in der Cloud und einer schnellen Reaktionsfähigkeit profitieren AWS-Nutzer vom AWS Cloud Adoption Framework. Dieser Service unterstützt die Reaktion auf einen Störfall mit einem automatisierten Werkzeug. Auf diese Weise lässt sich der oftmals große Umfang der betroffenen Ressourcen schnell filtern, und es fällt weniger repetitive Arbeit für das Team an. Ein Kernelement für das zeitnahe Lösen von Störfällen in der Cloud ist der Incident Manager – eine Unterfunktion des AWS Systems Managers. Damit lassen sich Anweisungen für die Reaktion auf Ereignisse vorab definieren – in Antwortplänen. Diese bringen die richtige Person (Eskalationspläne) mit den relevanten Informationen (Runbook und Metriken) zusammen. Damit können Unternehmen schnell reagieren und auf Grundlage vordefinierter Prozesse Gegenmaßnahmen einleiten. Sobald Sie Ihre Kontaktdetails angelegt haben, können Sie mit der Konfiguration eines Antwortplans beginnen:

1. Öffnen Sie dazu die Incident Manager Konsole unter dem AWS-Systems-Manager-Dienst und wählen Sie links "Reaktionspläne".

2. Klicken Sie anschließend auf "Reaktionsplan erstellen".

3. Geben Sie einen eindeutigen und identifizierbaren Namen für Ihren Plan ein.

4. Ergänzen Sie einen Vorfalltitel. Dieser hilft bei der Identifizierung des Vorfalls auf der Incident-Manager-Startseite.

5. Wählen Sie eine geeignete Auswirkung auf der Grundlage der potenziellen Störungsgröße aus.

6. Aktivieren Sie einen Chatkanal. Er unterstützt Ihr Sicherheitsteam bei der Kommunikation während der Problemlösung.

7. Bei Bedarf können Sie unter Einbindungen eine beliebige Anzahl von Kontakten und Eskalationsplänen markieren. Wählen Sie hierbei zum Beispiel den zuvor erstellten Kontakt aus.

8. Es ist zusätzlich möglich, ein Runbook zu erstellen. Damit können Sie die Eindämmung des Vorfalls und die Reaktion steuern.

9. Klicken Sie unter "Ausführungsberechtigungen" auf den Link "Erstellen einer neuen Rolle". Danach wählen Sie unter "Rollenname" die vorher erzeugte IAM-Rolle, die es dem Incident Manager erlaubt, SSM-Automatisierungsdokumente auszuführen. Klicken Sie zum Abschluss auf "Reaktionsplan erstellen".

In der heutigen IT müssen sich Admins immer häufiger per Fernzugriff auf Maschinen schalten, die nicht im physischen Zugriff stehen. Geht es dabei um den Support eines Kollegen im Home Office, sind Werkzeuge wie Teamviewer geeignet, doch in Infrastrukturen, die kritische Systeme umfassen, muss der IT-Verantwortliche auf hohe Sicherheit bedacht sein. Zumal mit dem Einsatz von Clouddiensten oder -infrastrukturen derartige sensible Rechner immer häufiger nur remote zu erreichen sind. HashiCorp stellt mit Boundary ein Open-Source-Werkzeug bereit, das sich um Identität und Authentifizierung für Remote Access kümmert. Praktischerweise klappt dies auch für alle im Unternehmen bekannten Endanwender.

Die kostenlose Boundary-Software arbeitet zur Authentisierung mit den Authentifizierungsdiensten des Azure Active Directory, AWS und vielen mehr zusammen. So soll laut HashiCorp ein Zero-Trust-Framework für den sicheren Fernzugriff auf Dienste, Anwendungen und Hosts bereitstehen. Das Tool umfasst granulare Zugriffsrechte, die auf den vertrauenswürdigen Identitäten eines Unternehmens basieren. Die enge Integration zwischen Boundary und Azure AD soll dabei für nahtloses automatisiertes Onboarding von Azure-Identitäten, -Zielen, -Rollen und -Berechtigungen in Boundary-Umgebungen sorgen.

Boundary authentifiziert und autorisiert jede Anfrage und ordnet die Benutzer den Services oder Hosts auf der Anwendungsebene zu. Das Besondere an dem Tool ist, dass keine VPN-Anmeldedaten oder SSH-Bastion-Host-Schlüssel zu verwalten sind, was die Integration der Nutzer vereinfacht und zudem das Risiko einer Kompromittierung der Anmeldedaten verringert. Boundary unterstützt neben dem Azure AD auch Identitätsdienste wie Okta, Ping oder andere, die OpenID Connect unterstützen.

Technisch gesehen ist Boundary ein Proxy-Host, leistet aber noch mehr und kann Mittler zwischen zwei beliebigen Netzwerken sein – Heimcomputer zu Unternehmensnetzwerk, DMZ zu intern, intern zu Internet. So erlaubt die Software es, Benutzern über eine Sicherheitsgruppe oder eine andere Methode Zugriff auf eine Anwendung zu gewähren, ohne dass der Anwender einen Benutzernamen oder ein Kennwort erhält. Er muss lediglich eine Verbindung zum Boundary-Server herstellen, dann auf die Anwendung klicken und Boundary überträgt die Verbindung bis zur Anwendung sowie transparente Authentifizierung und Anmeldung.

Link-Code: https://www.boundaryproject.io/

Mit in der Cloud verteilten Systemen steigt bei IT-Verantwortlichen auch der Bedarf nach der Sichtbarkeit des Gesundheitszustands. Um zu wissen, wie es um die IT-Ressourcen bestellt ist, gilt es natürlich in erster Linie im klassischen Sinne des Monitorings, die jeweiligen Daten von den Systemen abzuholen. Viel wichtiger ist im Zeitalter des Zeitmangels jedoch, dass der Admin keine Zeit damit verschwendet, erst einmal zu untersuchen, ob hier oder da wirklich etwa im Argen liegt, sondern dies auf einen Blick erkennen kann. Genau dies leistet das freie Netdata, das sogar als Clouddienst kostenlos verfügbar ist.

Netdata bietet Performance- und Health-Monitoring, wobei es besonderen Wert auf die hohe zeitliche Auflösung der Überwachung mit einem Event pro Sekunde legt. Dies geht einher mit einer architektonischen Spezialität, nämlich der Tatsache, dass Netdata per Default alle Daten im Speicher hält und nicht kontinuierlich auf die Festplatte schreibt. Nur beim Beenden speichert Netdata die aktuellen Daten, um beim Neustart nicht bei Null anzufangen.

Hinsichtlich der Echtzeitüberwachung ist die Software mit top oder sysstat vergleichbar, nur dass Netdata seine Daten ansprechend in Echtzeit im Browser präsentiert. Die darstellbaren Metriken sind dabei sehr umfassend und beinhalten diverse CPU-Kennzahlen, Speicherverbrauch, Netzwerkauslastung, Hardwareüberwachung und vieles mehr. Gleichzeitig erfasst das Tool Daten aus Containern und von Anwendungen wie Datenbanken oder E-Mail-Servern.

Mit diesem Daten lassen sich Alarme verknüpfen und so sicherstellen, dass kein Ausreißer übersehen wird. Langzeitanalysen erlaubt Netdata ebenso, doch dazu muss der Nutzer eine Zeitreihendatenbank wie Graphite oder InfluxDB an die Software anflanschen.

Link-Code: https://www.netdata.cloud/

Kommen im Unternehmen nur vereinzelte Clouddienste zum Einsatz, ist deren Verwaltung meist kein Problem. Doch wandern umfangreiche Eigenentwicklungen in die Cloud und laufen dort beispielsweise als Container-Instanzen auf Kubernetes, steigt die Komplexität exponentiell. Die Vorteile des von lokalen Umgebungen gewohnten Lebenszyklusmanagements von Applikationen drohen dabei auf der Strecke zu bleiben und reiner Konfigurationsarbeit zu weichen. Das Open-Source-Tool Juju verspricht, in großen und komplexen Anwendungsumgebungen Aufgaben wie Skalierung, Wartung und Deployment zu vereinfachen.

Das freie Juju beschreibt sich selbst als Werkzeug zur Applikationsmodellierung für Cloudinfrastrukturen. Dabei bedient es unter anderem Public Clouds wie AWS, Azure und GCP ebenso wie Private Clouds mit OpenStack oder vSphere. Juju kommt dabei jedoch immer lokal zum Einsatz und läuft auf ebensolcher Hardware. Die Bedienung ist via Kommandozeile ebenso möglich wie über die integrierte GUI. Der Juju-Client, mit dem der Nutzer arbeitet, ist für verschiedene Linux-Distributionen, macOS und Windows verfügbar.

Der Clou an Juju ist dessen Vereinfachung des Deployments von Applikationsinfrastrukturen: Der Store des Tools bietet eine Reihe von Best Practices zum Ausrollen definierter Anwendungen, die sich in Juju mit nur einem Klick in der eigenen Umgebung einsetzen lassen. So genügt dem IT-Verantwortlichen oft ein einziges Kommando, um ein neues Setup hochzuziehen. Erweitern lassen sich solche Umgebungen dann per Drag-and-Drop in der GUI.

Bestehende Applikationslandschaften lassen sich aber in der GUI auch überwachen. Dazu nutzt Juju sogenannte Charms. Charms sind kleine Anwendungen oder Skripte, die sich in nahezu jeder Programmiersprache erstellen lassen und die dann in den verschiedenen Komponenten einer komplexen Anwendung leben und von dort Daten liefern oder dort Aufgaben erledigen. So ist es beispielsweise möglich, Wartungsaufgaben zuverlässig ausführen zu lassen. Gleichzeitig ermöglichen die Charms eine Überwachung der Umgebung und zeigen dabei auch Abhängigkeiten an. Dabei muss der IT-Verantwortliche die Charms nicht selber entwickeln, für viele verbreitete Anwendungen liegen diese fertig im Juju-Store bereit.