Linux Container & Active Directory - Teil 3
Diese Blogeintrag-Serie erläutert wie einzelne LXC Container einer Domäne beitreten können. Außerdem wird aufgeführt, wie Nutzerbeschränkungen, Superuser-Rechte und SSH aktiviert und konfiguriert werden kann.
Blogserie:
Der Letze Teil dieser Blogserie erläutert, wie Nutzerbeschränkung über das Active Directory auch auf dem Linux Container möglich ist und wie die Vergabe von Root-Rechten möglich ist. Des Weiteren legt dieser Teil die benötigte Konfiguration für einen Fernzugriff über SSH dar.
Nutzerbeschränkung
Nutzer- und Anmeldebeschränkungen können über das Active Directory mithilfe von AD-Gruppen erstellt werden. So kann man das Anmelden am Container auf Nutzer einer oder mehrerer Gruppen beschränken. Hierzu kann eine Gruppe im Active Directory erstellt werden, welche nur Nutzer beinhaltet, denen der Zugriff auf den Container gestattet ist. Dann erstellt man eine Gruppenrichtlinie, welche auf den Container greift. Damit sich nun nur Nutzer der Gruppe am Container anmelden dürfen, müssen die „Lokal anmelden zulassen“ und „Anmelden über Remotedesktopdienste zulassen“ Richtlinien unter Computer Konfiguration -> Richtlinien -> Windows Einstellungen -> Sicherheitseinstellungen -> Lokale Richtlinien -> Zuweisen von Benutzerrechten aktiviert und die gewünschte(n) Gruppen hinterlegt sein. Die Richtlinie „Lokal anmelden zulassen“ kann nur aktiviert werden, wenn auch die Gruppe „Administrators“ zugelassen wird. Nach dem Erstellen der Richtlinie ist es empfohlen, über eine administrative Eingabeaufforderung am DC den Befehl gpupdate /force auszuführen.
Im Fall, dass sich nun ein nicht berechtigter Nutzer am Container anmelden möchte, erscheint jetzt eine Fehlermeldung.
Root-Rechte
Standardmäßig besitzt kein Nutzer der Domäne Root-/Sudo-Rechte. Auch dies kann mithilfe von Gruppen des Active Directory eingestellt und so auf bestimmte Nutzer beschränkt werden. Dies ist möglich, da ein AD-Nutzer auch im Container alle Gruppen, in denen er sich befindet, besitzt.
Abhilfe verschafft hier das bereits vorinstallierte Paket sudo. Sudo überwacht, welche Nutzer oder Gruppen Befehle mit Root-Rechten ausführen dürfen, diese sind in /etc/sudoers festgehalten. Da die AD-Gruppen auch in Linux bekannt sind, können wir so weitere AD-Gruppen in die Konfiguration von sudo hinzufügen. Es ist unbedingt zu beachten, dass eine Fehlkonfiguration von sudo jegliche Nutzung des Befehles $sudo verhindert. Einer AD-Gruppe kann die Nutzung von $sudo durch das Hinzufügen der Zeile %<GruppenName>@<Domäne> ALL=(ALL:ALL) ALL erlaubt werden. Besitzt der Gruppenname Leerzeichen, können diese mit einem umgedrehten Schrägstrich befreit (escape) werden. Weiter möchte ich hier nicht auf die Konfiguration von sudo eingehen, da dies nicht den Schwerpunkt dieses Blogeintrags darstellen soll.
Nutzer, welche keine Sudo-Rechte besitzen, können den Befehl $sudo weiterhin nutzen, jedoch erhalten diese eine Fehlermeldung und die Nutzung wird verweigert.
Fernzugriff
Der Zugriff zu dem Container ist meist nicht vom Host-System gewünscht, sondern über einen Fernzugriff. In Linux wird der Fernzugriff über SSH, der Secure Shell, angeboten. Damit diese genutzt werden kann, muss sie zuerst mit $apt install openssh-server installiert werden. Die Standardkonfiguration von SSH erlaubt jedoch das Anmelden mittels eines Passworts nicht. Dieses Verhalten kann in der Konfigurationsdatei /etc/ssh/sshd_config angepasst werden. In der Konfigurationsdatei befindet sich die Zeile „#PasswordAuthentication no“. Diese muss durch das Entfernen vom Zeichen „#“ und abändern von „no“ zu „yes“ aktiviert werden.
Des Weiteren ist empfohlen, den Port zu einem beliebigen, noch nicht genutzten Port zu ändern. So kann später das Anmelden an mehreren Containern auf einem Host-System ermöglicht werden. Ansonsten kann nicht eindeutig auf einen Container zugegriffen werden und der SSH-Login schlägt fehl. Zuletzt muss der SSH-Dienst zum Übernehmen der Konfiguration mit $service sshd restart neugestartet werden.
Mit der bisherigen Konfiguration ist der Zugriff über SSH auf den Container nur innerhalb des Containers möglich. Damit man aus dem Intranet auf den Container zugreifen kann, muss am Host-System ein statisches Routing angelegt werden. Hiermit wird der Datenverkehr eines bestimmten Ports auf einen bestimmten Container weitergeleitet. Diese Konfiguration muss für jeden Container auf dem Host-System einzeln ausgeführt werden. Falls man sich noch innerhalb des Containers befindet, kann man diesen mit $exit verlassen.
Als erstes muss die IP-Adresse des Containers im LXC-Netz ermittelt werden. Hierzu kann $lxc info <ContainerName> genutzt werden. Unter „Ips:“ befindet sich dann die dem Container zugewiesene IP-Adresse.
Ist diese bekannt, kann nun mit der iptables Funktion von Linux ein statisches Routing erstellt werden. Der Befehl $sudo iptables -t nat -A PREROUTING -i <AdapterName> -p tcp --dport <EingestellterPort> -j DNAT --to <ContainerIP>:<EingestellterPort> erstellt ein statisches Routing für den vorhin eingestellten Port zu der Container-IP. Sollen mehrere Container auf einem Host-System ausgeführt werden, muss dies für jeden Container einzeln ausgeführt werden. Beachtet werden muss außerdem, dass kein Port mehrfach verwendet wird.
Nach Ausführung des Befehls kann die Konfiguration mit $sudo iptables -t nat -L ausgegeben werden.
Nun ist das Anmelden über SSH (z.B. per PuttY) über die IP des Host-Systems und Angabe des korrekten Ports möglich.
Bei Fragen stehen wir gerne unter https://www.escde.net/kontakt zur Verfügung.
MEHR BLOG-KATEGORIEN
- ASP.NET
- Active Directory
- Administration Tools
- Allgemein
- Backup
- ChatBots
- Configuration Manager
- DNS
- Data Protection Manager
- Deployment
- Endpoint Protection
- Exchange Server
- Gruppenrichtlinien
- Hyper-V
- Intune
- Konferenz
- Künstliche Intelligenz
- Linux
- Microsoft Office
- Microsoft Teams
- Office 365
- Office Web App Server
- Powershell
- Remote Desktop Server
- Remote Server
- SQL Server
- Sharepoint Server
- Sicherheit
- System Center
- Training
- Verschlüsselung
- Virtual Machine Manager
- Visual Studio
- WSUS
- Windows 10
- Windows 8
- Windows Azure
- Windows Client
- Windows Server
- Windows Server 2012
- Windows Server 2012R2
- Windows Server 2016
- Windows Server 2019
- Windows Server 2022
- Zertifikate