Externer LDAP/AD Mirror lmn 7.x

Jesko · 9. Juli 2023 um 06:20

Ich war schon froher Hoffnung, weil gestern ruhe war.
Aber heute Nacht um 0:43 und heute Morgen um 5:05 gab es wieder eine Welle.

Und dann um 6:06 (?!?!?) gleich noch eine.

Ich verstehe das nicht.

LG

jochen · 9. Juli 2023 um 08:06

Hallo Jesko,

voll ins Hellblaue: könnte es sein, dass Dein LDAP immer nur dann versucht, etwas an den (nicht mehr vorhandenen) Backup-LDAP zu syncen, wenn es eine Änderung im AD gab und es dadurch zu dem globalen Aus- und wieder Eintragen in die Gruppen kommt? Z.B. Änderung eines Benutzerpassworts o.ä. Ok, des nächtens eher ungewöhnlich aber wer weiß…

Viele Grüße,
Jochen

Jesko · 9. Juli 2023 um 11:13

Leute, ich weiß noch nicht, wer der „Böse“ ist, aber ich hab neue Erkenntnisse, die vielleicht mit Schwarmintelligenz helfen, das Problem zu lösen.

Ich wollte mir gerade eine Testinstanz bauen und habe dazu im Verzeichnis data geschaut, ob da außer User-Homes (die ich nicht auf die Testinstanz übertragen möchte) noch wichtige Verzeichnisse liegen.

Dabei hab ich Verzeichnisse gefunden, die so da ganz sicher nicht hingehören:

drwxr-xr-x  9 www-data www-data      4096 Sep  9  2022  az
drwxr-xr-x  3 www-data www-data      4096 Jul  1 10:41 'az              '
drwxr-xr-x  3 www-data www-data      4096 Jul  2 00:51 'az               '

Offensichtlich wird durch irgendeinen Fehler zwischendurch ein neuer User angelegt, der bis auf die abschließenden Leerzeichen gleich heißt, wie der, den ich haben will…

Jetzt muss ich herausfinden, wo diese Leerzeichen herkommen.

Da das jetzt ganz sicher nichts mit dem externen LDAP-Mirror zu tun hat, lagere ich das mal in einen neuen Thread aus.

Siehe hier: Nutzerdatenbank irgendwie korrupt?

LG Jesko

Jesko · 9. Juli 2023 um 11:15

Das hat sehr wahrscheinlich nichts mit dem zusätzlichen Domaincontroller zu tun, sondern fiel nur zufällig zeitlich zusammen. Das Problem ~~hab ich noch nicht lokalisiert.~~ konnte ich mit einiger Sicherheit finden und die Lösung steht hier: Nutzerdatenbank irgendwie korrupt? - #36 von Jesko

Jesko · 17. Juli 2023 um 06:50

Von dem Forum dort bin ich einigermaßen enttäuscht. Da gibt es hunderte von Fragen, die gar keine Antwort bekommen und meine Anfrage hat auch nur EINEN Menschen dazu bewegt, sich Gedanken zu machen. Gelöst hab ich es am Ende doch alleine…
In solchen Fällen merke ich wieder mal, wie toll dieses Forum hier ist! Danke dafür an alle Diese Qualität ist nicht selbstverständlich!
Jesko

Heiko_Hoch · 2. August 2023 um 13:16

Dem kann ich mich völlig anschließen! Dieses Forum sucht Seinesgleichen!

Ist der LDAP Mirror nun wieder im Betrieb?

tjordan · 10. August 2023 um 05:48

Hallo Jesko,

ich stelle mir gerade die Frage was passiert, oder wie ich genau vorgehen muss, wenn ich die Lösung auf 7.2 update…muss ich vorher den zweiten DC demoten dann auch den Upgraden und dann wieder promoten, oder kann den einfach weiterhin laufen lassen und danach mit upgraden? Beim Upgrade auf 7.1 hats mit zumindest schon mal die DHCP-Redundanz zerrupft. Das wird noch ganz schön Gefriemel.

VG
Thomas

Heiko_Hoch · 10. August 2023 um 22:39

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?

Tobias · 4. September 2023 um 13:11

dorian:

Ich habe es in einem Ubuntu 18.04 Docker zum Laufen bekommen. Das ist aber sehr gebastelt und nicht wirklich dokumentierbar.

Aber hier meine Konfiguration:
/opt/samba-dc/docker-compose.yml
services:
  app:
    dns: 10.0.0.1
    image: instantlinux/samba-dc:latest

Hi.
Ich will mich auch dransetzen:

instantlinux/samba-dc:latest ist ein Samba 4.18.5
du sagst: „in einem Ubuntu 18.04 docker“ … das verstehe ich nicht: der dockerhost muss ja nicht ubuntu 18.04 sein. Und der samba im docker wird ja wohl auch nicht auf einem ubuntu 18.04 laufen…

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.

Tobias · 4. September 2023 um 14:43

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

Tobias · 4. September 2023 um 15:20

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.

idm-ext.meineschule.de (10.6.0.72 im internen Netz und die externe IP im öffentlichen DNS, z.B. 1.2.3.4 ?)

Oder ist das intern bei dir ein anderer Name als extern, z.B.

idm-ext.meineschule.linuxmuster.lan → 10.6.0.72
idm-ext.meineschule.de → 1.2.3.4

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:

im Dockercontainer muss der Tunnel-Endpunkt des wireguard-Netzwerks erreichbar sein (ping) und dadurch auch der DNS/LDAP/AD-Server (10.16.1.1 o.ä.)
du löst das durch eine Bridge (br0) - wo kommt die her? wer hat die erzeugt? (docker erstellt ja „docker0“ oder „br-abababab“ o.ä.)
von außen betrachtet muss aber auch eine IP erreichbar sein, also bei dir z.B. 1.2.3.4:636, das löst du, indem du den port 636 auch außerhalb des dockers veröffentlichst (a.k.a. 0.0.0.0:636:636)
das „NAT“-ting macht dann docker: vom internet erreicht man den service über port 636, docker übersetzt das in den docker-container. der Samba wiederum fragt dann über VPN-Tunnel-IP bei 10.16.1.1 nach

Hab ich das so richtig verstanden?

LG, Tobias

Tobias · 5. September 2023 um 11:23

Hallo zusammen,
auch ich habe es jetzt geschafft, einen externen Domänencontroller zu installieren.

Mein Vorgehen:

externen DNS für den neuen Host festlegen: idm.meineschule.de → 1.2.3.4

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)

grafik897×584 29.5 KB

grafik1171×519 72.2 KB

grafik1167×486 69.3 KB

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

einen Dockercontainer gebastelt. Das kann ich nicht in Vollständigkeit dokumentieren. Wichtig ist am Ende:

der Dockerhost muss bereits einen kernel haben, der Wireguard kann (ich habe ubuntu 20.04 mit kernel 5.4, ich denke, das ist das minimum).
der Dockercontainer braucht die NET_ADMIN capability (vllt. auch SYS_MODULE)

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:

letsencrypt wird der Einfachheit halber mit vollständigem Verzeichnis reingemountet, dann funktionieren auch die relativen Links von „live/domain/privkey.pem → …/…/archive… usw“
man startet einmal 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.

Danach sollte man TLS in ./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

Die TLS-Verbindung kann man von überall checken, auch im Vergleich mit dem Haupt-Server:
```
  openssl s_client -showcerts -connect idm-ext.meineschule.de:636 > 636.txt
```

Voil´a. Hoffentlich klappts auch bei euch.

Update des containers, falls niemand anderes eine bessere samba-wireguard kombi anbietet: 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

Tobias · 5. September 2023 um 11:43

noch ein paar Hints:

idealerweise macht man das mit docker besser als so händisch, aber ich fand instantlinux/samba-dc (der am aktuellsten gepflegte) wg. des alpine Umfeld zu umständlich zum experimentieren, evtl. geht das mit meiner Anleitung oben jetzt ganz schnell, da wireguard dazu zuinstallieren. wenn man sich das (Dockerfile)[https://github.com/instantlinux/docker-tools/blob/main/images/samba-dc/Dockerfile] anschaut: da sind ja massiv ports geöffnet… das muss man evlt. containen.
von der anderen Seite kommend: (Docker: linuxserver/wireguard)[Docker] war ebenso schwierig weil alpine genutzt wird und samba ja vermutlich mehr pflege braucht.
WireGuard - ArchWiki ist eine gute Quelle um wireguard zu verstehen.
ich habe ldapcmp mal laufen lassen: Samba-tool ldapcmp - SambaWiki und das ergebnis ist „ok“. Scheinbar sind nur spezielle sophomorix-werte (deactivation date, oder so) unterschiedlich zwischen den DC, warum auch immer.
Demoting habe ich auch gemacht: Demoting a Samba AD DC - SambaWiki. Und das hat auch auf dem Replika-Server eine Fehlermeldung gebracht, deswegen hat auf dem LMN-Server 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:

bei Nextcloud gibt es für die Hauptkonfiguration von LDAP/AD einen Backup-server + port eintrag. Das funktioniert tatsächlich: man kann den Hauptserver abklemmen und per Backup einloggen. Also funktionierendes Fallover. Wenn ich eine zweite LDAP-Konfig dagegen eintrage und der Haupt-ADserver ausfällt, funktioniert die NC auch nicht mehr. Wer da Angst vor dem Rumspielen hat: The LDAP configuration API — Nextcloud latest Administration Manual latest documentation
Bei Moodle habe ich ~~nur gefunden, dass ich den Servername ändere. Keinen Backup oder zweit-konfiguration möglich.~~ dank @baumhof gefunden, dass man die Server im entsprechenden Feld nacheinander mit Semikolon getrennt eintragen kann, dann soll ein Failover funktionieren. ldaps://idm.meineschule.de:636;ldaps://idm-ext.meineschule.de:636
Bei Webuntis hab ich noch nicht geschaut, kann ja jemand ergänzen.
Schlau wäre auch, einen LDAPS - Proxy aufzusetzen, der a.) außerhalb der Schule steht und b.) sowohl in die Schule hinein als auch zum Replikant ein load-balancing oder failover macht.

Tobias · 5. September 2023 um 17:45

Downsides

Hier sammle ich mal Symptome, die evtl. von der LDAP/AD Mirror Aktion kommen könnten:

[Showstopperlevel hoch] Hänger bei smbclient-Befehlen: sophomorix-check läuft durch, sophomorix-add oder sophomorix-update läuft bis irgendwann der Befehl nicht funktioniert, nach Timeout kommt z.B. die Fehlermeldung

------------------------------------------------------------
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

Jesko · 13. September 2023 um 15:38

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

Tobias · 14. September 2023 um 08:27

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:

hast du ohne Probleme bei laufendem externen DC (und nicht demotet die Schüler anlegen/versetzen können?
Bei mir klappt das nicht, sophomorix steigt irgendwann in einen timeout, fehlermeldung s.o.

VG,. Tobias

Jesko · 14. September 2023 um 13:16

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 .

Michael · 28. November 2023 um 15:54

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

Tobias · 29. November 2023 um 10:46

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 TODO neben einem readonly-mirror ist, das der Docker-container modifiziert ist und die Aktualisierung momentan noch manuell geschieht. Das muss ich noch Automatisieren.
ein Problem mit „sophomorix-check“, das ich oben beschrieb ist momentan nicht mehr aufgetaucht, aber ich habe auch nicht mehr als ein oder zwei Änderungen pro „sophomorix-update“ bislang gehabt. Kann sein, dass das noch relevant ist.

Das alles hilft dir natürlich nicht akut: das muss vorher bestehen.

Tobias · 29. November 2023 um 10:56

und ja: das war komplex:

wireguard intern einrichten
wireguard extern einrichten
Mirror extern konfigurieren und erstellen
Mirror in die diversen Dienste einpflegen (geht nicht überall)
testen, ob es auch mit gekapptem Glasfaserkabel läuft

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