Entschuldigt die naive Frage,
könnte man für einen Mirror nicht einen Server mit openLdap betreiben und die Daten mit
ldapsearch -x -h localhost -D "CN=global-binduser,OU=Management,OU=GLOBAL,DC=linuxmuster,DC=lan" -w [BIND_PASSWORD] -b "OU=SCHOOLS,DC=linuxmuster,DC=lan" -LL > linuxmuster.ldif
ldapadd -x -h [ZIEL_SERVER_ADRESSE] -D "cn=admin,dc=example,dc=com" -w [ZIEL_PASSWORT] -f linuxmuster.ldif
übertragen?
Hi.
Ich will mich auch dransetzen:
Hä?
VG, Tobias
P.S. ich bin zwingend noch auf lmn 7.1.
Sobald ich die Replikation am Laufen habe, kann ich auch das Upgrade auf 7.2 und den Downgrade auf einen RODC (statt einem DC) probieren.
Hallo @Heiko_Hoch ,
ich gehe nach Lektüre dieses und der anderen Threads zum Thema davon aus, dass in dem ldif in einer lmn7.x keine passwörter(hashes) mehr stehen, man also die Passwörter nicht so duplizieren kann. Vielleicht gibt es auch noch andere Gründe, warum das nicht so einfach mit einem openLDAP zu realisieren ist. Wenn du es dennoch hinkriegst: sag Bescheid!
VG, Tobias
Hi @Jesko,
darf ich einhaken und dein gitlab-README zitieren?
VPN-Tunnel vom externen Server zum Schulnetz (ich verwende Wireguard… tolles Teil
ok, off-topic für hier, aber ich finde auch hier in ASK bislang keinen richtigen Lösungsweg: Wo liegen denn die Endpunkte? In der OpnSense mit Plugin „os-wireguard-go“?
Fast egal wie… warum passiert das auf dem docker-host und nicht im Dockercontainer, spricht was dagegen? (ja, man muss wireguard erst dort im container installieren, damit hat man ein updateproblem mehr)
der Server muss an zwei Stellen einen DNS-Eintrag besitzen::
- im öffentlichen DNS
- im samba von linuxmuster.net (über die webui machbar, ansonsten mit sambatool dns add…)
ist das in beiden Fällen derselbe Eintrag? Also z.b.
Oder ist das intern bei dir ein anderer Name als extern, z.B.
INTERFACES: hier muss das Interface eingetragen sein, auf dem die LDAP-Anfragen eingehen und die IP-Adresse aus dem VPN
das gewünschte Docker-Netzwerk. (Bei mir eine Bridge. Vielleicht wäre es sinnvoll, da den host-modus zu verwenden.)
aus den beiden Erklärungen schließe ich:
0.0.0.0:636:636)Hab ich das so richtig verstanden?
LG, Tobias
Hallo zusammen,
auch ich habe es jetzt geschafft, einen externen Domänencontroller zu installieren.
Mein Vorgehen:
DNS intern habe ich zwar in der Schulkonsole vorher festgelegt: idm-ext.meineschule.de → 1.2.3.4, das wird aber nach dem Domainjoin dann geändert und a.) auf IDM-EXT → 172.31.0.12 (also eine unsinnige interne docker-IP) geändert und b.) weil ich intern eine andere Domäne als extern habe, lautet der Zoneneintrag dann auch „idm-ext.meineschule.intern“… Macht aber nix, scheint zu funktionieren.
Letsencrypt-Zertifikate für die Domäne machen (bei mir: auf dem docker-host certbot verwendet, speichert die zertifikate in /etc/letsencrypt/live/idm-ext.meineschule.de) und sicherstellen, dass das auch in Zukunft passiert. Andere machen das mit Hilfe eines Dockercontainers, wie traefik oder acme-companion. Ginge auch.
sich mit wireguard auseinandersetzen: Ich habe das Plugin „os-wireguard-go“ in OpnSense installiert und dort ein Netz 10.10.10.0/24 aufgespannt mit IP 10.10.10.1 auf der OpnSense und 10.10.10.3 auf der externen Seite, Dokus dazu: OpnSense Wireguard Site-to-site ist schwerer lesbar als Anfänger als OpnSense Road-Warrior Setup, aber es ging auch das hier mit ein: (Digitalocean)[How To Set Up WireGuard on Ubuntu 20.04 | DigitalOcean]. Ist bloß ziemlich lang, bis man es halb gerafft hat.
Am Ende gibt es ein OpnSense-Ende (alles enable setzen und apply nicht vergessen, es gibt dort auch ein frontend das die handshakes anzeigt), bei dem man einen beliebigen Port freischaltet (bei mir: 4137 für die IP 1.2.3.4)
und es gibt später im dockercontainer ein anderes Ende, dessen Config sieht bei mir so aus: (wg0.conf). Die OpnSense hat ja von außen auch einen externe IP, die wäre im Beispiel: 5.6.7.8
[Interface]
PrivateKey = xxxxxxxxxxxxxxxx=
#PublicKey dazu: HzAkNH02RZPOdwC2wVRivE3QNaM5O7RVW7csp12UaCM=
Address = 10.10.10.3/24
ListenPort = 51821
[Peer]
PublicKey = /HYTh1mPAgRhVWjq5BS34FGAP/Ap8iLCXeVAV94q43w=
AllowedIPs = 10.10.10.1/32,10.16.0.0/12
Endpoint = 5.6.7.8:4137
wer das checkt: bei Peer steckt der PublicKey der OpnSense drin. In der OpnSense steht im Endpoint der publickey der wg0.conf-Konfiguration. Wichtig ist bei „AllowedIPs“ in der „Peer“-Sektion auch 10.16.0.0/12, so dass ich später nicht nur auf 10.10.10.1 sondern auch auf meinen LMN-Server 10.16.1.1 zugreifen kann.
Diese wg0.conf kopiere ich in die docker-config, hier nach /srv/docker/idm-ext/config/wireguard
mkdir -p /srv/docker/idm-ext/config/wireguard
docker pull debian:stable-slim
docker run -it --cap-add=NET_ADMIN --volume /srv/docker/idm-ext/config/wireguard:/etc/wireguard debian:stable-slim /bin/bash
im Dockercontainer:
apt install samba wireguard winbind
#apt install net-tools procps iproute2 emacs-nox iputils-ping less
wg-quick up wg0 #test
wg show #test
ping 10.16.1.1 #test
außerhalb des dockercontainers:
docker ps -a # ID des laufenden (oder beendeten Containers herausbekommen: abcdef)
docker commit abcdef debian:wireguard-working
Damit habe ich einen Container mit Samba und wireguard.
Jetzt mach ich es fast wie Jesko und Dorian und tjordan: docker-compose.yml und Datenstrukturen, die die Konfigurationen enthalten.
config/wireguard/wg0.conf
config/var-lib-samba/
config/samba/
entrypoint.sh
samba-pw
docker-compose.yml
Die zugehörigen Dateien sind: samba-pw
BIND_USER=adminstrator
BIND_PASSWORD=strenggeheim
entrypoint.sh
#!/bin/sh -e
echo "Important Variables:"
echo "Bind User: $BIND_USER + Password: xxx"
echo "Wireguard configuration:"
cat /etc/wireguard/wg0.conf
echo "Firing up wireguard"
wg-quick up wg0
echo "Return value: $?"
sleep 3s
echo "Ping the server:"
ping -c 1 $SERVERIP
echo "TLS Konfiguration:"
echo "TODO: muss manuell in /etc/samba/smb.conf eingetragen werden, z.B. "
cat <<EOF
tls enabled = yes
tls keyfile = /etc/letsencrypt/live/$(hostname)/privkey.pem
tls certfile = /etc/letsencrypt/live/$(hostname)/fullchain.pem
tls cafile =
tls verify peer = no_check
EOF
if [ -z "$NETBIOS_NAME" ]; then
NETBIOS_NAME=$(hostname -s | tr [a-z] [A-Z])
else
NETBIOS_NAME=$(echo $NETBIOS_NAME | tr [a-z] [A-Z])
fi
REALM=$(echo "$REALM" | tr [a-z] [A-Z])
if [ ! -f /etc/timezone ] && [ ! -z "$TZ" ]; then
echo 'Set timezone'
cp /usr/share/zoneinfo/$TZ /etc/localtime
echo $TZ >/etc/timezone
fi
echo $REALM
if [ ! -f /var/lib/samba/registry.tdb ]; then
echo "Keine Registry in /var/lib/samba erkannt: versuche einen JOIN"
if [ "$BIND_INTERFACES_ONLY" = "yes" ]; then
# INTERFACE_OPTS="--option=\"bind interfaces only=yes\ --option=\"interfaces=$INTERFACES\""
INTERFACE_OPTS="--option=\"bind interfaces only=yes\""
fi
if [ -z "$SERVERIP" ]; then
SERVERIP=10.16.1.1
fi
SERVER_OPTS="--server=$SERVERIP"
if [ $DOMAIN_ACTION = "join" ]; then
PROVISION_OPTS="$REALM DC $SERVER_OPTS -U$BIND_USER --password='$BIND_PASSWORD'"
else
echo 'Only join actions are supported.'
exit 1
fi
rm -f /etc/samba/smb.conf /etc/krb5.conf
echo "samba-tool domain $DOMAIN_ACTION $PROVISION_OPTS $INTERFACE_OPTS \
--dns-backend=SAMBA_INTERNAL"
# This step is required for INTERFACE_OPTS to work as expected
echo "samba-tool domain $DOMAIN_ACTION $PROVISION_OPTS $INTERFACE_OPTS \
--dns-backend=SAMBA_INTERNAL" | sh
#mv /etc/samba/smb.conf /etc/samba/smb.conf.bak
echo 'root = administrator' > /etc/samba/smbusers
echo "Please add your TLS Konfiguration to smb.conf"
fi
mkdir -p -m 700 /etc/samba/conf.d
cp /var/lib/samba/private/krb5.conf /etc/
exec samba --model=standard -i </dev/null
und zuletzt docker-compose.yml
version: '3'
services:
##
## LDAP/AD Replikant
##
# host: idm-ext.meineschule.de
idm-ext:
dns:
- 10.16.1.1
image: debian:wireguard-working
restart: always
container_name: idm-ext
hostname: idm-ext.meineschule.de
entrypoint: ["/usr/local/bin/entrypoint.sh"]
#command: tail -f /dev/null
cap_add:
- NET_ADMIN
- SYS_MODULE
environment:
NETBIOS_NAME: "IDM-EXT"
REALM: "MEINESCHULE.DE"
TZ: "Europe/Berlin"
BIND_INTERFACES_ONLY: "yes"
DOMAIN_ACTION: "join"
SERVERIP: "10.16.1.1"
env_file:
- ./samba-pw
volumes:
- ./config/samba:/etc/samba
- ./config/wireguard:/etc/wireguard
- ./config/var-lib-samba:/var/lib/samba
- /etc/letsencrypt:/etc/letsencrypt:ro
- ./entrypoint.sh:/usr/local/bin/entrypoint.sh
ports:
- 127.0.0.1:389:389
- 636:636
- 127.0.0.1:135:135
Zuletzt passiert folgendes:
docker-compose up und schaut sich den output an. Im besten Fall funktioniert der wireguard tunnel und der Domain JOIN Befehl. Wenn das geklappt hat, ist /var/lib/samba/private gefüllt, ebenso gibt es eine /etc/samba/smb.conf, jeweils aus Sicht innerhalb des Containers. Sollte was nicht klappen, kann man diese Verzeichnisse auch wieder leeren und rumschrauben../config/samba/smb.conf eintragen wie es der output auch suggeriert: tls enabled = yes
tls keyfile = /etc/letsencrypt/live/idm-ext.meineschule.de/privkey.pem
tls certfile = /etc/letsencrypt/live/idm-ext.meineschule.de/fullchain.pem
tls cafile =
tls verify peer = no_check
openssl s_client -showcerts -connect idm-ext.meineschule.de:636 > 636.txt
Voil´a. Hoffentlich klappts auch bei euch.
docker exec -it idm-ext /bin/bash dem laufenden container beitreten. apt update && apt full-upgrade und danach wieder ein docker commit abcdef12 debian:wireguard-working absetzen.VG, Tobias
noch ein paar Hints:
samba-tool domain demote --remove-other-dead-server=IDM-EXT auch tatsächlich noch was gelöscht im AD. Vorsicht, dass man sein AD nicht killt!Anwendung:
ldaps://idm.meineschule.de:636;ldaps://idm-ext.meineschule.de:636
Hier sammle ich mal Symptome, die evtl. von der LDAP/AD Mirror Aktion kommen könnten:
------------------------------------------------------------
6) Line 15: SMB::$homedir_global/$directory_share/::root::root::0755::global-share.ntacl:::
ERROR: smb command
COMMAND:
/usr/bin/smbclient -U administrator%'******' //server/linuxmuster-global -c 'mkdir "/share"'
RETURN VALUE: 256
ERROR MESSAGE:
session setup failed: NT_STATUS_CONNECTION_DISCONNECTED
OK (0): smbcacls-NTACL on //server/linuxmuster-global /share
DONE with 6) Line 15: SMB::$homedir_global/$directory_share/::root::root::0755::global-share.ntacl:: ---
Herunterfahren des Replikant DC hilft nicht (zumindest nicht in dem kurzen Zeitfenster, in dem ich getestet habe). Nach Demotion des remote DC funktioniert sophomorix-update sofort klaglos. Der Zusammenhang scheint gegeben 
Hi Tobias,
Bei mir liegen die Endpunkte auf dem externen Server und auf dem dockerhost (bei beiden wireguard auf dem Blech)
In meinem Fall in erster Linie schlicht deshalb, weil ich auf beiden Hosts ohnehin wireguard installiert habe.
Wenn das nicht so gewesen wäre, hätte ich villeicht … nein. Während ich das schreibe merke ich, dass ich dann auch auf den beiden Servern Wireguard installiert hätte.
Allerdings war mir da noch nicht klar, dass es essenziell ist, dass ALLE Clients auch eine Route zum externen DC haben müssen. Deshalb würde ich dafür in Zukunft die OPNSense als Endpunkt wählen, damit sie sich drum kümmert, wenn die Clients nicht wissen wohin. Bei meiner Lösung muss man zusätzlich entweder jedem Client die Route über den dockerhost konfigurieren oder der Firewall die Route über den Dockerhost. Dann gibts aber einen hops mehr… Vermutlich wurscht. Aber halt eine Spur komplexer.
Ich denke es muss in jedem Netz ein DNS-Eintrag sein, der auf eine von dort erreichbare IP verweist.
ich hatte irgendwo gelesen (glaub ich), dass man den Host-Modus verwenden soll… das find ich aber auf die Schnelle nicht.
Wichtig an der Stelle ist: man möchte den Samba nicht im Internet öffentlich haben. Deshalb muss man die Ports an das Wireguard-Interface binden und unbedingt verhindern, dass sie von außen erreichbar sind.
Die eigentlich nette ufw taugt an der Stelle nicht: Docker und ufw - GNU/Linux.ch
Korrekt
weiß ich jetz t nicht aus dem Ärmel. War das nicht wg0? Die käme von wireguard…
Genau
genau.
LG Jesko
Hallo Jesko,
danke für die Antworten!
d.h. es reicht für die clients nicht aus, dass „idm-ext.meineschule.de“ doch im internetsteht und auf eine öffentliche IP aufgelöst wird? Vermutlich nicht, weil die clients nicht den LDAP auf 1.2.3.4:636 erreichen können müssen, sondern den DC, d.h. die Samba-Ports - und das soll über den Tunnel.
Daher frag ich mich auch, ob der externe DC für die internen clients eigentlich „idm-ext.meineschule.de“ heißt, oder „idm-ext.meineschule.linuxmuster.lan“ ? Oder ist das ist dem Umfeld wurscht und der heißt einfach nur IDM-EXT?
Falls du das schon hast, kannst du nachschauen, wie deine clients IDM-EXT auflösen? (IP des wireguard-tunnels des docker-hosts innen oder IP des docker-containers außen oder externe IP ?) Dementsprechend hast du oder musst du ja eine Route konfigurieren.
Nur noch eine kleine Frage:
die Schüler anlegen/versetzen können?VG,. Tobias
Das weiss ich nicht. Ich nutze ja intern die öffentliche Domäne. Das hat keine Nachteile und spart einem an vielen Stellen. -insbesondere bei Zertifikaten - eine Menge Nerven.
Ich hab das ja wieder rückgebaut und noch keine Zeit gehabt, es wieder einzurichten…
Kann ich nicht mehr sagen. Ich weiss nicht, ob das in der knappen Woche überhaupt versucht wurde .
Hallo.
Jetzt muss ich dieses Fass (leider) nochmal aufmachen, da wir seit heute Morgen ein größeres Problem mit unserem Provider haben: Unsere Glasfaserleitung ist schon den ganzen Tag tot. Das Problem liegt nicht bei uns sondern beim Provider (E.ON) – daher können wir nichts machen außer zu warten, bis es hoffentlich bald behoben wird.
Die Konsequenzen sind leider „dramatisch“: Niemand kann moodle, Nextcloud oder das MDM benutzen, da die Authentifizierung so natürlich nicht klappt. Daher nochmal die Frage in die Runde: Ist das Thema „LDAP/AD Mirror“ noch irgendwo auf der To-do-Liste? Es kommt mir ziemlich komplex vor…
Viele Grüße,
Michael
Ja, ist bei mir auf Todo.
Allerdings hoffe ich auch aus der Community hier, dass jemand das „readonly-Active directory“ Fass nochmal aufmacht, wo das Ubuntu 18.04 der lmn < 7.2 der Showstopper war.
Inzwischen bin ich bei lmn 7.2 und ubuntu 22.04 auf dem Server und würde auch gerne auf einen Readonly-AD-Mirror umsteigen, wenn jemand weiß, wie das geht.
Ich habe den externen Dienst im Dockercontainer wie hier: Externer LDAP/AD Mirror lmn 7.x - #86 von Tobias beschrieben laufen. Läuft, so viel ich sehen kann:
LDAPTLS_REQCERT=always ldapsearch -LLL -H ldaps://idm-ext.meine-schule.de -b "DC=linuxmuster,DC=meine-schule,DC=de" -D global-binduser@linuxmuster -x -w `cat /etc/linuxmuster/.secret/global-binduser` samAccountName=kuechel
auf dem Server liefert was es soll. Ebenso, wenn ich „idm-ext.meine-schule.de“ gegen „localhost“ austausche. Das gleiche kann man von Extern mal probieren.
Das alles hilft dir natürlich nicht akut: das muss vorher bestehen.
und ja: das war komplex:
ich hatte gehofft, dass sich mit einem einzigen dockercontainer schritt zwei und drei einfach in eine Anleitung packen lassen, daher auch meine Änderung das wireguard in den dockercontainer zu machen.
Die restlichen Schritte werden aber nicht vereinfachbar sein. Nur evtl. noch komplexer, wenn man noch einen Proxy einrichtet… das hat wohl der ein oder die andere.
VG, Tobias
Hallo Jesko,
dein Repo ist weg. Kommt das wieder?
oder:
Gibt es Bestrebungen jetzt mal einen RODC aufzusetzen?
Oder idealerweise auch noch beides: einen Load-balancer, der ldap.meine-schule.de als zentrale Anlaufstelle bereitstellt (und im Internet steht) und der dann je nach Lust und Laune und Verfügbarkeit den internen LDAP-Server oder sich selbst (den externen LDAP-Server) fragt.
Das ganze ist ja auch dann noch relevant, wenn man einen keycloak am Laufen hat, richtig? Auch für den ist ein zuverlässiger LDAP sinnvoll.
VG, Tobias
Richtig, auch federated IDP über Keycloak benötigt eine Verbindung zu deinem IDP.
Keine Hände, keine Kekse!
Pardon, sollte natürlich heißen keine Arme keine Kekse!
Ich habe jetzt beides ausführlich getestet. Meine Erfahrung:
mit zweitem (Read-write) DC geht sophomorix auf dem Server zufällig in Timeouts und damit ist sophomorix unbenutzbar. Zumindest bei mir, vielleicth ist es ein Netzwerkproblem, weil das wireguard aus einem docker-container heraus doch gewagt klingt. Aber prinzipiell funktioniert die Syncronisation und die Nutzung des zweiten DCs.
wenn man stattdessen mit einem zweiten RODC joined, sind die zufälligen Timeouts zwar weg, aber dafür funktionieren bestimmte Synchronisationsvorgänge nicht. z.B. lege ich ein Projekt an und auf dem SERVER ist alles ok, aber auf dem RODC fehlen alle „sophomorix*“ Attribute. Ebenso geht (vermutlich in Folge der unvollständigen Synchronisation) die komische NESTED GROUPS suche schief.
EDIT: Den Hinweis mit den „preload“ Credentials von Personen kann ich bestätigen wenn man einen RODC hat: wenn man das macht und danach keine Verbindung zum Primary DC existiert, dann kann man sich einloggen.
Für wen es interessiert, der zweite DC/RODC lief im Dockercontainer:
FROM debian:stable-slim
RUN apt-get update \
&& apt-get full-upgrade -y \
&& apt-get install -y samba samba-ad-provision samba-dsdb-modules wireguard winbind --no-install-recommends \
&& apt-get install -y net-tools procps iproute2 emacs-nox iputils-ping less --no-install-recommends
Das wäre das Dockerfile, das einen SAMBA-in-debian hält und das Skript von Jesko kann um „RO“ ergänzt werden, so dass man als RODC joined:
if [ $DOMAIN_ACTION = "join" ]; then
PROVISION_OPTS="$REALM RODC $SERVER_OPTS -U$BIND_USER --password='$BIND_PASSWORD'"
else
echo 'Only join actions are supported.'
exit 1
fi
Eine der Voraussetzung, die Jesko schreibt, sind DNS-Einträge. Das kann schon alles sein, dass das bei mir deswegen nicht tut, aber so sporadische Fehler sind kein Spaß und klingen nicht nach grundsätzlichen NEtzwerkverkonfiguration oder falscher DNS-Einträge…
Egal, bin frustriert.