LDAP/AD auth in wordpress in v7

Hi zusammen, speziell @maxim, @Sascha, @Lebowski und @baumhof,

ich versuchte vor kurzem eine Wordpress-instanz mit unserer v7 zu koppeln, so dass sich schüler an dem wordpress anmelden können.
Hat das jemand geschafft? Wenn ja, wie?

Meine Versuche bisher waren mit den Plugins:

Bei letzterem schien mir gar kein bind-user vorgesehen zu sein, also wird das auch nicht funktionieren. bei den beiden ersteren ist zwar so was wie ein binduser vorgesehen, aber nicht in der form cn=global-binduser,ou=management,.. usw sondern in der Form global-binduser@LINUXMUSTER, also admin@DOMÄNE. DAs hat allerdings nicht geklappt. Ich hoffe, jemand hat das Problem schon mal gehabt…

Referenzen für ähnliche Probleme:
[1] LML v7 und LDAP (Webuntis,Moodle,public html)
[2] LDAP - Authentifizierung extern

Vielen Dank für jegliche Hinweise,

Tobias

Achso, vergaß: Vielleicht kennt jemand ein kommerzielles Plugin? Open-Source sollte es trotzdem sein.
Danke.

Hi Tobias.
Wir haben (bisher nur mit v6.1) das Plugin „wpdirAuth“ installiert. Das auth. erfolgreich gegen ldaps. Mit v7 habe ich es noch nicht ausprobiert – hatte aber gehofft, dass da nur wenige Änderungen notwendig sein werden?!

Sehe aber gerade, dass das Plugin schon ne Weile kein Update erfahren hat:

Vielleicht läuft es ja trotzdem noch … auch mit nem AD?

… noch etwas: ich habe in meiner history auf dem Server nachgesehen. Die Syntax mit @ versteht der Server auch. Zumindest das hier hat funktioniert:

ldapsearch  -b "ou=default-school,ou=SCHOOLS,dc=linuxmuster,dc=meine-domain,dc=de" -H ldaps://server.linuxmuster.meine-domain.de:636 -x -D global-binduser@linuxmuster.meine-domain.org -w strenggeheim CN=einlogin

hth,
Michael

1 „Gefällt mir“

Hi Michael,

dank dir.
Es hat tatsächlich geklappt.
Grund: mal wieder das selbst signierte ZErtifikat im AD/LDAP.
Weitere Probleme machen das Leben schwer und ich dokumentiere hier mal meine ERfahrung:

  1. ldapsearch vs. ldbsearch: das ist seltsam, „ldbsearch“ auf dem Server (18.04) und auf dem wordpress-host (18.04) liefern unterschiedliche „–help“ ERgebnisse zurück, obwohl die selben Pakete installiert sind. Scheinbar ist auf dem Server noch etwas zusätzliches (samba/kerberos) aktiv, siehe:
server# ldbsearch -h
...
      --relax                                 pass relax control
      --cross-ncs                             search across NC boundaries
      --extended-dn                           show extended DNs

Help options:
  -?, --help                                  Show this help message
      --usage                                 Display brief usage message

Common Samba options:
  -d, --debuglevel=DEBUGLEVEL                 Set debug level
      --debug-stderr                          Send debug output to STDERR
...

während:

blog# ldbsearch -h
...
      --relax                     pass relax control
      --cross-ncs                 search across NC boundaries
      --extended-dn               show extended DNs

Help options:
  -?, --help                      Show this help message
      --usage                     Display brief usage message
ENDE
  1. wenn ich ldapsearch verwende, kann ich das TLS_REQCERT so "aus"schalten (never) oder auf "allow"schalten (allow):
LDAPTLS_REQCERT=ALLOW ldapsearch -H ldaps://server...

oder ich kann in /etc/ldap/ldap.conf eintragen: TLS_REQCERT allow

  1. wenn ich ldapsearch verwende, funktioniert unter der v7 folgender Befehl (nach Passworteingabe):
LDAPTLS_REQCERT=ALLOW ldapsearch -H ldaps://server.linuxmuster.meine-schule.de -D global-binduser@linuxmuster -b "DC=linuxmuster,DC=meine-schule,DC=de" -x -W  samAccountName=kuechel 

hier sind ide Kombinationen, und ob sie funktionieren:

... -D "CN=global-binduser,OU=Management,OU=GLOBAL,DC=linuxmuster,DC=meine-schule,DC=de" ... -> funktioniert 
... -D global-binduser@linuxmuster.meine-schule.de ... -> funktioniert
... -D global-binduser@linuxmuster ... -> funktioniert (!, linuxmuster ist die SAMBA-Domäne) 
... -D global-binduser ...  -> funktioniert nicht
  1. für PHP muss ich in /etc/ldap/ldap.conf das obige „allow“ oder „never“ eintragen, damit die Verbindung klappt (ich habe auf „never“ gestellt).

  2. sobald ich dem LDAP/AD in der v7 ein ordentliches Zertifikat unterjubeln kann, fällt der schritt oben weg und man ersetzt dann „never“ durch „always“ (glaub ich).

Jetzt hab ich dein Plugin wpDirAuth tatsächlich soweit gekriegt, dass ich mich anmelden kann. Vielen DAnk.

Ich werde die anderen noch probieren, kann mir nur vorstellen, dass die auch mitspielen.

VG, Tobias

Guck mal hier … das hatten wir schon mal:

Danke! Hab auch die Lösung gefunden.

Top!
Noch ein Nachtrag: Wenn es aufgrund eines fehlenden certs klemmt, kann man sich auch so helfen, indem man vor das ldapsearch das hier setzt:

LDAPTLS_REQCERT=never ldapsearch ....
Alternativ kann man es auch fest in der /etc/ldap/ldap.conf eintragen: TLS_REQCERT never

Hallo @Tobias.
Ich hole den Thread nochmal nach oben, da es hier jetzt ein merkwürdiges Problem mit dem Plugin gibt, das vorher nie aufgefallen ist. Wenn es neue Kollegen, die bisher nie unter Wordpress angemeldet waren, mit ihrem Login versuchen, erscheint eine Fehlermeldung:

Fehler: Der Benutzername <login> ist auf dieser Website nicht registriert. Falls du dir über deinen Benutzernamen unsicher bist, versuche es stattdessen mit deiner E-Mail-Adresse.

Könntest Du einen Screenshot Deiner Settings posten, so dass ich das abgleichen kann? Es ist hier so, dass alte/bekannte Logins sich anmelden können aber neue und noch nicht registrierte User scheitern.

Viele Grüße,
Michael