19.11.2019, aktualisiert am 30.12.2019

13616

Samba-ActiveDirectory mit FreeRADIUS, CheckMK, Nextcloud, OpenVPN, ProxmoxVE und mehr

Ich habe die letzten Wochen (Monate) damit verbracht mit in das Thema ActiveDirectory und Samba einzuarbeiten. Dabei habe ich teils sehr lange und ausgiebig suchen müssen, weswegen ich mein gesammeltes Wissen bzw. Erkenntnisse hier als Anleitung zusammengeschrieben habe.

Die Einrichtung ist wahrlich nicht so einfach Klick-Klick-Fertig wie ein Windows Server mit Domänendiensten... Aber der kostet ja auch Geld und braucht Resourcen... Von der Performance sollte hier auch ein bzw. zwei Raspberry Pis ausreichen.

Was ich haben wollte:
Eine zentrale Speicherung von Benutzern, Passwörtern, Berechtigungsgruppen, sodass ich dann die lokalen Benutzerverwaltungen folgender Programme dadurch ersetzen kann. Besonders das Passwort ändern in jedem Dienst sollte zur Vergangenheit gehören. Damit es auch "lange bei mir lebt":

eine kostenlose Lösung, Linuxbasiert (Debian) -> KEIN Windows Server
Verwaltungstool zum Anlegen / Ändern von Benutzern und Gruppen auf der CLI als auch unter Windows
2 DomainController mit Replication als Ausfallsicherheit

Folgende Dienste habe ich in der Anleitung angedeckt:

FreeRADIUS
Nextcloud
Check_MK
Apache2 Basic-Auth
OpenVPN (kein Access-Server)
Clients (Windows, macOS, Linux)

grundsätzlich können alle Dienste eingebunden werden, welche LDAP als Backend unterstützen oder auch Kerberos verwenden

Meine Umgebung:

1. DC: Debian 10.1 als LXC auf einem Proxmox 6.0-15-Host
2. DC: Debian 10.1 als VMware VPS in der Cloud mit VPN-Anbindung
Samba aus dem Debian Repo (4.9.5-Debian)

Grundsätzlich könnt ihr statt Debian auch z.B. Ubuntu, Arch, CentOS oder Anderes verwenden, ich werde mich wahrscheinlich mal an Alpine Linux um die notwendigen Resourcen noch einmal zu unterbieten ^^

Vorbereitungen
Ich habe meinen 2. DC auf einem VPS installiert, da ich auch einige Dienste auf anderen RZ-Systemen habe, welche diesen dann verwenden. Solltet ihr ein ähnliches Setup vorhaben solltet ihr vor der Installation des DCs sicherstellen, dass beide DC-Systeme miteinander reden können. Ich habe bei mir auf den Routern Zuhause und im RZ eine VPN-Strecke, welche die DCs dann mitnutzen. Das kann man sicherlich auf bestimmte Ports beschränken, ich habe bei mir einfach eine ANY-Regel für die Kommunikation der Beiden eingefügt. Dann einfach schauen sich die Hosts über die internen IPs pingen können. Niemals gehört ein Samba-DC via Portfreigabe einfach ins Internet!

Setup DomainController
Wichtiger Hinweis zu unpriviledged LXC-Containern: Samba hat hier Probleme Domänen zu erstellen / beizutreten. Verwendet daher hier entweder einen LXC-Container priviledged (ggf. unsicher) oder eben eine VM. Da ich bei mir mehr die Funktionen segmentieren will als Sicherheitsbedenken bzgl. Übergriff aus einem Container habe ist das für mich okay. Wenn das für jemanden ein Problem sein sollte einfach statt LXC eine VM verwenden.

Vor Einrichtung dem System eine statische IP vergeben und auf aktuellen Patchstand bringen.
Während Debian 9 diverse Probleme mit Paketinstallationen/-updates von winbind im DC-Betrieb hatte geht dies nun ohne Probleme

Wir beginnen mit der Installation der notwendigen Pakete für den Samba-DC:

apt install samba

Als erstes können wir die initiale Samba-Konfiguration in unseren Benutzerordner verschieben:

mv /etc/samba/smb.conf ~

Mittels folgendem Befehl erzeugen wir nun die Domänenstruktur und stufen Samba zum DomainController hoch:

samba-tool domain provision

Dieser Befehl fragt nun die Eckdaten der neuen Umgebung ab. Hier solltet ihr euch Gedanken machen, wie ihr Samba in eure DNS-Infrastruktur einbinden wollt. Am einfachsten ist es wohl diesen einfach als Haupt-DNS auf allen Geräten zu verwenden, alternativ könnt ihr die Zone auch einfach von eurem bestehenden DNS-Server weiterleiten lassen, siehe unten. Ihr könnt auch NONE als DNS-Server angeben, in diesem Fall müsstet ihr die notwendigen SRV-Einträge manuell setzen, auch ist so nur ein DC möglich!

Nachdem die Erstellung durchgelaufen ist kommt bei vielen (bei mir damals auch) Verwunderung auf: Denn der eben erstellte DC läuft noch nicht bzw. startet auch noch nicht wenn man ihn manuelle mit dem Befehel "samba" startet. Grund dafür ist, dass die Dienste smbd und nmbd noch laufen. Daher beenden wir diese und deaktivieren diese, demaskieren den DC-Dienst und setzen ihn in den Autsrtart:

systemctl stop smbd nmbd
systemctl disable smbd nmbd
systemctl unmask samba-ad-dc
systemctl enable samba-ad-dc

Ein Neustart ist aber dennoch notwendig, da winbind hier noch Fehlermeldungen wirft, wenn ihr samba startet.

Hier ein paar Anlaufstellen für Problemdiagnose

samba -i #Samba im Vordergrund starten um Loggingmeldungen live zu sehen
netstat -tulpen | grep samba #Überprüfen ob Samba läuft
tail -f /var/log/samba/log.samba #Samba-Logdatei
ntlm_auth --username Administrator #NTLM-Anmeldung testen

Eigene Zertifikate
Was nicht notwendig ist, aber zumindest mir das Leben erleichtert hat: Gebt Samba bzw. dem LDAP-Server ein eigenes Zertifikat, idealerweise von einer eigenen CA. Diese importiert ihr dann auf den Servern, welche LDAP-Anbindung brauchen. Gerade Check_MK und FreeRADIUS sind da recht pingelig, bzgl. Self-Signed-Zertifikaten, die es "nicht kennt". Ich habe bei mir daher einfach via Easy-RSA eine kleine CA aufgesetzt, Servernamen einfach wie der FQDN gesetzt.

Diese dann unter /var/lib/samba/private/tls mit einem eigenen Namen abgelegt und in der smb.conf darauf verwiesen:

tls enabled  = yes
tls keyfile  = tls/dc1.key
tls certfile = tls/dc1.crt
tls cafile   =

Die CA dann importieren mit:

cp /patch/to/ca.crt /usr/local/share/ca-certificates/extra/
update-ca-certificates

Benutzerverwaltung vom Client aus
Viele Vorgänge wie Benutzer erstellen, ändern oder löschen könnt ihr direkt via samba-tool-Befehlen machen. Für die grafische Verwaltung von Benutzern und Gruppen könnt ihr nun beispielsweise einen Windows-Client in die Domäne holen und auf diesem via Removeserver-Administrationstools (RSAT) verwalten. Diese gibt es bei Windows 10 mittlerweile unter Einstellungen > Apps > optionale Features > "RSAT: Tools für ActiveDirectory Domain Services und Lightweight Directory Services". Alternativ könnt ihr dies aber auch über einen LDAP-Viewer durchführen, ich verwende dafür LDAPAdmin: http://www.ldapadmin.org/

DNS-Weiterleitung von Bestands-DNS
Normalerweise gibt man an den Domänengeräten einfach den DC als DNS an und gut ist. Allerdings habe ich bereits Pi-Hole als DNS-Server laufen, auch verwalte ich meine DNS-Zone bereits darüber und möchte dies nicht im Samba-AD tun. Daher gibt es nun mehrere Möglichkeiten:

Sofern ihr für eure Domäne einen eigenen FQDN habt könnt ihr diesen via DNS-Weiterleitung an den Samba-DNS weitergeben lassen
Wenn ihr den gleichen Namen verwendet müsst ihr ein wenig mehr weiterleiten, ich habe hier mal in meinem Pi-Hole geschaut was denn alles an Anfragen an die Domäne kommt: Ich würde zur Sicherheit auch die DC-Namen weiterleiten, falls sich hier Einträge ändern wird Samba diese auch anpassen.

_msdcs.binarybear.lab
_tcp.binarybear.lab
_udp.binarybear.lab
_udp.binarybear.lab
_kerberos.binarybear.lab
dc1.binarybear.lab
dc2.binarybear.lab

Unter DNSmasq bzw. Pi-Hole könnt ihr eine Konfigurationsdatei mit den Weiterleitungen unter /etc/dnsmasq.d/ ablegen. IPs und Domänennamen bitte austauschen. Ich leite diese hier auch nur an einen der beiden DCs weiter, sollte aber soweit auch ausreichen.
/etc/dnsmasq.d/dns-forwarding.conf:

server=/_msdcs.binarybear.lab/192.0.2.2
server=/_tcp.binarybear.lab/192.0.2.2
server=/_udp.binarybear.lab/192.0.2.2
server=/_udp.binarybear.lab/192.0.2.2
server=/_kerberos.binarybear.lab/192.0.2.2
server=/dc1.binarybear.lab/192.0.2.2
server=/dc2.binarybear.lab/192.0.2.3

2. DC aufsetzen
Gleiches Spiel wie beim ersten, erstmal alle Pakete installieren, smb.conf verschieben und der Domäne als DC beitreten

apt install samba
mv /etc/samba/smb.conf ~
samba-tool domain join binarybear.lab dc -UAdministrator

Dienste stoppen und System dann einmal neustarten

systemctl stop smbd nmbd
systemctl disable smbd nmbd
reboot

Nun noch Samba in den Autostart packen, fertig.
Den Replikationsprozess könnt ihr dann via folgenden Befehl checken:

samba-tool drs showrepl

Wichtig sind die Meldungen "Last attempt @ NTTIME(0) was successful"

NAGIOS / Check_MK-Check
Es gibt auch ein entsprechendes Monitoring-Plugin für NAGIOS / Check_MK. Ich lasse dies als lokalen Check alle 15 Minuten laufen: https://exchange.nagios.org/directory/Plugins/System-Metrics/File-System ...

FreeRADIUS mit Gruppenüberprüfung / VLAN-Zuordnung
Viele Anleitungen im Netz zeigen bereits wie ihr mit FreeRADIUS grundsätzlich Benutzer gegen das AD authentifiziert, einige auch wie man die Benutzer zusätzlich gegen eine Gruppe filtert. Für die meisten wird dies ausreichen, allerdings möchte ich bei mir Gruppen wie z.B. "WLAN-Intern" als auch "WLAN-Gast" verwenden um Benutzer gleich in das richtige VLAN zu stecken. Das müssen natürlich die APs kennen, ist unter Geräten für Unternehmen wie z.B. UniFi-AccessPoints oder OpenWrt aber ohne viel Aufwand möglich.

FreeRADIUS wird daher so konfiguriert, dass es zuerst den Benutzer und Passwort via MSCHAP bzw. ntlm_auth-Modul überprüft. Läuft dies erfolgreich erfolgt eine Gruppen-Abfrage des Benutzers via LDAP. So können auch mehrere Gruppen für die Authentifizierung berechtigt sein bzw. Unterschiedliche Eigenschaften wie VLANs oder auch Einschränkungen auf SSIDs erhalten.

Hier ersteinmal die Installation der notwendigen Pakete: winbind wirdich installiere FreeRADIUS mit --no-install-recommends da hier sonst Dependencies wie Icon-Themes und weiteres mitinstalliert wird - brauch ich nicht.. Winbind wird für das Paket ntlm_auth benötigt, FreeRADIUS-Utils bringt das Tool "radtest" mit zum Testen der Authentifizierung, FreeRADIUS-LDAP entsprechenden LDAP-Support.

apt install winbind &&apt install freeradius freeradius-utils freeradius-ldap --no-install-recommends

Zuerst müssen wir jedoch Samba vorbereiten. So ist die NTLM-Authentifizierung standardmäßig abgeschaltet. Auch LDAP ist nur in der Verschlüsselten Variante nutzbar! Dies ist für den Produktivbetrieb sicherlich auch gut so, allerdings solltet ihr dies für die Einrichtung abschalten, da ihr so zumindest Fehlerquellen ausschließen könnt. Wenn dann alles steht entsprechend auf LDAP mit SSL bzw. STARTTLS umstellen und die Einstellung im Samba zurücksetzen, NTLM-Auth muss allerdings aktiv bleiben!

Folgende Zeilen unter [global] in die /etc/samba/smb.conf einfügen:

ntlm auth = yes
ldap server require strong auth = no

Damit FreeRADIUS NTLM verwenden kann muss zudem folgender Ordner für den FreeRADIUS-Benutzer (unter Debian "freerad") freigeschaltet werden.
Gruppen-Berechtigung einfach auf die winbindd_priviledged-Gruppe setzen und freerad in diese aufnehmen:

chown root:winbindd_priv /var/lib/samba/winbindd_privileged/
gpasswd -a freerad winbindd_priv

Erste Konfiguration erledigen wir in der Datei /etc/freeradius/3.0/mod-enabled/mschap:
Entsprechende Optionen sind bereits als Kommentar vorhanden, diese am besten einfach gültig machen und entsprechend abändern

require_encryption = yes
require_strong = yes
ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00}"  

Wenn ihr dies nur auf eine Gruppe beschränken wollt einfach ein --require-membership-of="DOMAIN\Gruppe" angeben

INFO: Ich musste das System hiervor neustarten, da im FreeRADIUS-Log "'Reading winbind reply failed!"-Einträge auftauchten!
Nach dem Neustart bitte auch vor langer Fehlersuche überprüfen ob samba läuft bzw. eine NTLM-Anmeldung möglich ist:

Nun ist es Zeit das einmal zu Testen, dafür sind 2 Terminals bzw. Sitzungen hilfreich:

freeradius -X
radtest -t mschap Administrator PasswortVomAdmin 127.0.0.1 1812 testing123

Es sollte ein Access-Accept zurückkommen. Sofern nicht waren bei mir die wichtigen Meldungen meist die Roten mit dem mschap-Modul ;)

Dann richten wir noch das LDAP-Modul ein, Konfig-Datei ist /etc/freeradius/3.0/mods-enabled/ldap
WICHTIG: Für die LDAP-Binds muss ein Benutzerkonto angegeben werden! Bitte im produktiven Betrieb hier nicht den Domänenadmin verwenden!
Ich habe bereits eine OU "ActiveDirectory" angelegt und darunter die OUs "Benutzer", "Gruppen" und "Dienstkonten". Ihr könnt das aber auch stumpf alles auf den base_dn stellen, dann sucht er alle OUs durch. Die DNs kann man mit dem LdapAdmin übrigens einfach mit einem Rechtsklick auf dem jeweiligen Objekt kopieren.

ldap {
        server = 'dc1.binarybear.lab'  
        port = 389
        identity = 'cn=ldap.freeradius,ou=Dienstkonten,ou=ActiveDirectory,dc=binarybear,dc=lab'  
        password = *********
        base_dn = 'dc=binarybear,dc=lab'  
        user {
                base_dn = "ou=ActiveDirectory,dc=binarybear,dc=lab"  
                        filter = "(sAMAccountName=%{%{Stripped-User-Name}:-%{User-Name}})"  
                }
        group {
                filter = '(objectClass=group)'  
                base_dn = "ou=ActiveDirectory,dc=binarybear,dc=lab"  
                membership_attribute = 'memberof'  
        }
}

Die Site-Konfiguration muss nun auch noch angepasst werden, damit bei einer RADIUS-Anfrage die korrekten Module angesprochen werden. Daher hier die Blöcke authorize und authenticate der Datei /etc/freeradius/3.0/sites-enabled/default: Ich habe diese mit Absicht auf MSCHAP-Auth reduziert, da ich weniger sichere Methoden wie PAP so gleich außen vor lassen kann.

authorize {
        filter_username
        mschap
        eap {
                ok = return
        }
}

authenticate {
        Auth-Type MS-CHAP {
                mschap
        }
        mschap
        eap
}

Die LDAP-Abfragen bauen wir nun in den inner-tunnel ein. Warum?
PEAP mit MSCHAPv2 tunnelt die eigentliche Authentifizierung in genau diesem. Wenn ihr diese in die default-Site packt überprüft ihr die regulären Benutzerdaten, allerdings dann die Anonyme Identität gegen die LDAP-Abfragen. Will meinen, dass ich mit ein wenig Geschick die LDAP-Abfrage aushebeln könnte, indem man einen gültige Benutzerdaten angibt, dann als anonyme Identität aber einfach einen anderen gültigen Benutzernamen mit anderen Rechten bzw. anderem VLAN.
Hier ein Beispiel, welches die Gruppen WLAN-Intern und WLAN-Gast verwendet und diese in VLAN 10 und 11 zuweist. Benutzer ohne Zuordnung werden abgelehnt.
/etc/freeradius/3.0/sites-enabled/inner-tunnel

authorize {	
	if (LDAP-Group == WLAN-Intern) {
		update reply {
			&Tunnel-Type = VLAN
			&Tunnel-Medium-Type = IEEE-802
			&Tunnel-Private-Group-Id = 10
		}
	}
	elsif (LDAP-Group == WLAN-Gast) {
		update reply {
			&Tunnel-Type = VLAN
			&Tunnel-Medium-Type = IEEE-802
			&Tunnel-Private-Group-Id = 11
		}
	}
	else {
		reject
		}

Auch hier final einmal testen, das Debug-Log von FreeRADIUS hilft da recht gut weiter. Ich hatte erst Probleme mit dem memberOf-Attribut vom LDAP-Modul, so wie es oben steht funktioniert es aber dann auch mit ActiveDirectory.

Einbindung OpenVPN
OpenVPN kann mit einer zusätzlichen Benutzername/Kennwort-Authentifizierung versehen werden, beispielsweise gegen PAM aber eben auch gegen ein LDAP mit Gruppenbeschränkung.

Paket für LDAP-Integration nachinstallieren:

apt install openvpn-auth-ldap

In der Server-Konfiguration dann folgende Zeile einfügen:

plugin /usr/lib/openvpn/openvpn-auth-ldap.so /etc/openvpn/auth/auth-ldap.conf login

Ordner erstellen und Datei /etc/openvpn/auth/auth-ldap.conf anlegen. Auch hier ist ein eigener LDAP-Benutzer sinnvoll!
Auch wenn RequireGroup auf False steht: Der Benutzer-Filter übernimmt diese Funktion.

<LDAP>
        URL             ldap://dc1.binarybear.lab
        BindDN          cn=ldap.openvpn,ou=dienstkonten,ou=activedirectory,dc=binarybear,dc=lab
        Password        ********
        Timeout         5
        FollowReferrals yes
</LDAP>

<Authorization>
        BaseDN          "OU=Benutzer,OU=ActiveDirectory,DC=binarybear,DC=lab"  
        SearchFilter    "(&(sAMAccountName=%u)(memberOf=CN=OpenVPN-Benutzer,OU=Gruppen,OU=ActiveDirectory,DC=binarybear,DC=lab))"  
        RequireGroup    false
</Authorization>

WICHTIG: Das Plugin kann leider kein STARTTLS, weswegen ich hier leider noch Plaintext-Auth machen muss...

Am Client muss dann noch ein "auth-user-pass" in die Konfiguration.

Einbindung Check_MK
Anleitung von Check_MK: https://checkmk.de/cms_ldap.html
Die LDAP-Schnttstelle ist bereits in der Raw-Edition vorhanden und kann unter Benutzer > LDAP connections gefunden werden.
WICHTIG: Plaintext verwenden oder CA importieren - Check_MK mag keine untrusted certificates!

Standardmäßig aktzeptiert Check_MK *alle* AD-Benutzer, ich habe dies hier mit dem Filter wieder auf eine Gruppe beschränkt: Check_MK-Benutzer

ID: binarybear.lab (beliebig wählbar!)
Directory Type: Active Directory
Manually specify list of LDAP servers (bei Weiterleitung der Zone auch gerne automatisch, dann kann man aber keine Prio angeben!)
LDAP-Server: dc1.binarybear.lab
Failover: dc2.binarybear.lab
Bind DN: cn=ldap.checkmk,ou=dienstkonten,ou=activedirectory,dc=binarybear,dc=lab
Bind Password:
Use SSL: YES
User Base DN: ou=benutzer,ou=activedirectory,dc=binarybear,dc=lab
Filter (&(objectclass=user)(objectcategory=person) (memberof=cn=check_mk-benutzer,ou=gruppen,ou=activedirectory,dc=binarybear,dc=lab))

Es sind zudem auch noch Zuweisungen von Rollen aus Check_MK anhand von AD-Gruppen möglich, dort dann den vollständigen DN zu der Gruppe angeben. Auch diese Benutzer müssen aber auch Mitglied der Gruppe Check_MK-Benutzer sein, da sie sonst vom Filter ignoriert werden!

Einbindung Apache2
Mein persönlicher Favorit, da ich so meine ReverseProxy absichern kann. Sofern BasicAuth vorher im Einsatz war dies einfach austauschen:

AuthName "AD-Auth"  
AuthBasicProvider ldap
AuthType Basic
AuthLDAPGroupAttribute member
AuthLDAPGroupAttributeIsDN On
AuthLDAPURL "ldaps://dc1.binarybear.lab/dc=binarybear,dc=lab?cn?sub?(objectClass=*)"  
AuthLDAPBindDN "cn=ldap.apache2,ou=dienstkonten,ou=activedirectory,dc=binarybear,dc=lab"  
AuthLDAPBindPassword "**********"  
Require ldap-group CN=Apache2-Benutzer,OU=Gruppen,OU=ActiveDirectory,DC=BinaryBear,DC=lab
</RequireAny>

Ich arbeite bei mir eigentlich nur noch mit sog. Macros, sprich Template-Dateien auf welche man dann verweisen kann. Sieht dann so aus:

/etc/apache2/conf-enabled/macro-le-rproxy.conf

<Macro LE-RProxy $proto $host $ip $port>
        <VirtualHost *:80>
                Use RedirectHTTP2HTTPS $host
        </VirtualHost>

        <VirtualHost *:443>
                Use LE-VHost-HTTPS $host
                ProxyPass / $proto://$ip:$port/
                ProxyPassReverse / $proto://$ip:$port/
                SSLProxyEngine On
                SSLProxyEngine On
                SSLProxyVerify none
                SSLProxyCheckPeerCN off
                SSLProxyCheckPeerName off
                SSLProxyCheckPeerExpire off
                ProxyPass /.well-known !
                DocumentRoot /var/www/catchall
                <Directory /var/www/catchall/.well-known>
                        Order Deny,Allow
                        Allow from All
                </Directory>
                <Location />
                        AuthName "Proxy-Auth"  
                        AuthBasicProvider ldap
                        AuthType Basic
                        AuthLDAPGroupAttribute member
                        AuthLDAPGroupAttributeIsDN On
                        AuthLDAPURL "ldaps://dc1.binarybear.lab/dc=binarybear,dc=lab?cn?sub?(objectClass=*)"  
                        AuthLDAPBindDN "cn=ldap.apache2,ou=dienstkonten,ou=activedirectory,dc=binarybear,dc=lab"  
                        AuthLDAPBindPassword "**********"  
                        Require ldap-group cn=RP_$host,ou=gruppen,ou=activedirectory,dc=binarybear,dc=lab
                </Location>
        </VirtualHost>
</Macro>

Entsprechende Sites kann man dann mit wenigen Parametern in einem One-Liner abfertigen:
/etc/apache2/sites-enabled/reverseproxy.conf

Use LE-RProxy https external.domain.de 192.0.2.3 443
Use LE-RProxy http external2.domain.de 192.0.2.4 80

Im AD dann die Gruppe erstellen so wie der VHost heißt, bei mir habe ich noch ein RP_ als Präfix: z.B. RP_external.domain.de

weitere Links: https://wiki.pratznschutz.com/index.php/Apache_2_mit_LDAP/AD_Authentifik ...

Einbindung Nextcloud
http://www.techspacekh.com/integrating-nextcloud-user-authentication-wi ...

Einbindung Proxmox VE
Hier müssen die Benutzerkonten vorher explizit erstellt werden und dann in die gewollte Gruppe gepackt werden, ein automatischer Sync kann das Ding leider nicht...
https://www.jamescoyle.net/how-to/43-setup-active-directory-authenticati ...

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 516502

Url: https://administrator.de/contentid/516502

Ausgedruckt am: 23.11.2024 um 10:11 Uhr

1 Kommentar

Hallo BinaryBear,

ohne dass ich jetzt schon wüsste, ob ich deine Anleitung mal konkret brauchen werde, dennoch ein Dank für diese Arbeit!

Zwei Hinweise dazu, aus langjähriger Erfahrung mit "sowas" im www:

a) eine kurze Einführung ganz am Anfang, was genau dein Ziel ist und warum (was für ein Unternehmen, Bezug zu vorhandenem Netzwerk etc.pp.) , hilft ungemein!

b) Versionen (Debian, Samba, LXC etc.) mit nennen! Das hilft bei späteren Überarbeitungen, aber auch all denen, die in ein, zwei Jahren den thread finden!

Ansonsten ist es ein Artikel der Art, die ich sehr schätze!!

HPSchkola

Anleitung Linux Linux Userverwaltung

Mehr von BinaryBear

Debian 10: Arbeitsspeicher läuft langsam vollBinaryBear - 9 Kommentare

Reverse-VPN für entferntes NetzwerkBinaryBear - 10 Kommentare

OpenVPN: Login der Benutzer mit dem passenden ZertifikatBinaryBear - 11 Kommentare

UniFi AP AC LITE: Fragen über FragenBinaryBear - 6 Kommentare

Heiß diskutiert