8
XAMPP Apache 2.4.58 LDAP AD Authentifizierung
Hallo zusammen,
leider finde ich keine passenden Antworten hier oder überhaupt im Internet. Ja, es gibt Lösungsansätze zu diesem Problem, doch diese funktionieren bei mir leider nicht. Daher die Frage hier und evtl. hat jemand eine funktionale Lösung parat.
Problem
XAMPP bzw. Apache auf Windows 2.4.58
Es soll eine (beliebige) HTML Seite per .htaccess welche im Verzeichnis der zu schützende Seite liegt geschützt werden.
Per .htpasswd funktioniert das auch.
Nun soll das aber bitte über das AD eines Window Server 2019 erfolgen und zwar mittels einer Sicherheitsgruppe (meinegruppe), d.h. alle Nutzer in dieser Sicherheitsgruppe sind berechtigt sich mit ihrem User/Kennwort an der Seite anzumelden.
Im Apache ist das notwendige LDAP Modul geladen:
LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
Die Seite befindet sich im Verzeichnis
C:\xampp\htdocs\test
In diesem Verzeichnis befindet sich die .htaccess welche wie folgt aussieht
AuthType Basic
AuthName "Testseite - Anmeldung erforderlich"
#Methode to authent users
AuthBasicProvider ldap
#Serviceaccountuser to read LDAP
AuthLDAPURL "ldap://xxx.yyy.internaldomain:389/DC=zzz,DC=internaldomain?sAMAccountName?sub?(objectClass=*)"
AuthLDAPBindDN ldapservice@zzz.internaldomain
AuthLDAPBindPassword securesecret
LDAPReferrals Off
AuthLDAPGroupAttribute member
AuthLDAPGroupAttributeIsDN On
Require ldap-group CN=meinegruppe,OU=Nutzer,DC=zzz,DC=internaldomain
Der Serviceuser ldapservice ist auf dem Server angelegt und die Zugangsdaten sind korrekt.
Die Sicherheitsgruppe meinegruppe existiert ebenfalls im AD
Wenn nun die Seite aufgerufen wird quittiert der Apache dies mit dem Fehler
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator at admin@example.com to inform them of the time this error occurred, and the actions you performed just before this error.
More information about this error may be available in the server error log.
Im Log finde ich folgenden Eintrag dazu
[ldap:error] [pid 5624:tid 2004] (70023)This function has not been implemented on this platform: AH01277: LDAP: Unable to add rebind cross reference entry. Out of memory?
Diesen Fehler finde ich auch immer wieder bei diesem Problem in anderen Foren, jedoch passt keine beschriebene Lösung.
Hat jemand eine Lösung und eine Erklärung hierzu?
Nebenproblem ist, dass das Popup bei der Anmeldung im Browser nicht das wiedergibt, was nach dem Tag AuthName steht.
leider finde ich keine passenden Antworten hier oder überhaupt im Internet. Ja, es gibt Lösungsansätze zu diesem Problem, doch diese funktionieren bei mir leider nicht. Daher die Frage hier und evtl. hat jemand eine funktionale Lösung parat.
Problem
XAMPP bzw. Apache auf Windows 2.4.58
Es soll eine (beliebige) HTML Seite per .htaccess welche im Verzeichnis der zu schützende Seite liegt geschützt werden.
Per .htpasswd funktioniert das auch.
Nun soll das aber bitte über das AD eines Window Server 2019 erfolgen und zwar mittels einer Sicherheitsgruppe (meinegruppe), d.h. alle Nutzer in dieser Sicherheitsgruppe sind berechtigt sich mit ihrem User/Kennwort an der Seite anzumelden.
Im Apache ist das notwendige LDAP Modul geladen:
LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
Die Seite befindet sich im Verzeichnis
C:\xampp\htdocs\test
In diesem Verzeichnis befindet sich die .htaccess welche wie folgt aussieht
AuthType Basic
AuthName "Testseite - Anmeldung erforderlich"
#Methode to authent users
AuthBasicProvider ldap
#Serviceaccountuser to read LDAP
AuthLDAPURL "ldap://xxx.yyy.internaldomain:389/DC=zzz,DC=internaldomain?sAMAccountName?sub?(objectClass=*)"
AuthLDAPBindDN ldapservice@zzz.internaldomain
AuthLDAPBindPassword securesecret
LDAPReferrals Off
AuthLDAPGroupAttribute member
AuthLDAPGroupAttributeIsDN On
Require ldap-group CN=meinegruppe,OU=Nutzer,DC=zzz,DC=internaldomain
Der Serviceuser ldapservice ist auf dem Server angelegt und die Zugangsdaten sind korrekt.
Die Sicherheitsgruppe meinegruppe existiert ebenfalls im AD
Wenn nun die Seite aufgerufen wird quittiert der Apache dies mit dem Fehler
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator at admin@example.com to inform them of the time this error occurred, and the actions you performed just before this error.
More information about this error may be available in the server error log.
Im Log finde ich folgenden Eintrag dazu
[ldap:error] [pid 5624:tid 2004] (70023)This function has not been implemented on this platform: AH01277: LDAP: Unable to add rebind cross reference entry. Out of memory?
Diesen Fehler finde ich auch immer wieder bei diesem Problem in anderen Foren, jedoch passt keine beschriebene Lösung.
Hat jemand eine Lösung und eine Erklärung hierzu?
Nebenproblem ist, dass das Popup bei der Anmeldung im Browser nicht das wiedergibt, was nach dem Tag AuthName steht.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 32941279590
Url: https://administrator.de/contentid/32941279590
Printed on: April 27, 2024 at 05:04 o'clock
8 Comments
Latest comment
So funktioniert's bei mir
Manuel
#Benutzer und Passwort mit dem der Apache am AD anfragt
AuthLDAPBindDN "CN=ApacheLDAPAuth,OU=aaa,OU=bbb,DC=example,DC=com"
AuthLDAPBindPassword geheim
#URL zur LDAP-Abfrage
AuthLDAPURL "ldap://dchostname:389/OU=aaa,OU=bbb,DC=example,DC=com?sAMAccountName?sub?(objectClass=*)"
# AuthLDAPBindAuthoritative muss OFF sein. Ansonsten erzeugt der Apache einen Fehler 500
AuthLDAPBindAuthoritative off
LDAPReferrals off
AuthType Basic
AuthName "Bitte benutzen Sie Ihren Windows-Benutzernamen und Ihr Passwort um sich anzumelden."
AuthBasicProvider ldap
AuthUserFile /dev/null
#Benutzer muss Mitglied in der angegebenen AD-Gruppe sein
require ldap-group CN=erlaubtegruppe,OU=aaa,OU=bbb,DC=example,DC=comManuel
Super, vielen dank. Damit wirft Apache schon mal keinen Fehler.
Allerdings wird der Username nun nicht gefunden bzw. es wird anscheinend nicht in der Gruppe nachgesehen. An was kann das nun liegen
Im AD habe ich eine OU=Nutzer in welcher die Sicherheitsgruppe meinegruppe ist. Die Mitglieder dieser Gruppe sollen berechtigt sein. Die Nutzer selbst sind in derselben OU=Nutzer angelegt, dort wo auch die Sicherheitsgruppe meinegruppe steht.
Ich erhalte nun im Log den Fehler
[auth_basic:error] [pid 3432:tid 1968] [client xxx.xxx.xxx.xxx:yyyyy] AH01618: user blubb not found: /test/
Ich weiß jetzt allerdings auch nicht, ob es ein Fehler des Serviceusers ist, welcher sich ja mit dem AD verbindet, um die Informationen zu erhalten oder ob es daran liegt, dass der Serviceuser sich zwar verbindet, jedoch dann der Nutzer welcher sich an der Seite anmelden möchte nicht gefunden wird. Irgendwie alles doof.
Allerdings wird der Username nun nicht gefunden bzw. es wird anscheinend nicht in der Gruppe nachgesehen. An was kann das nun liegen
Im AD habe ich eine OU=Nutzer in welcher die Sicherheitsgruppe meinegruppe ist. Die Mitglieder dieser Gruppe sollen berechtigt sein. Die Nutzer selbst sind in derselben OU=Nutzer angelegt, dort wo auch die Sicherheitsgruppe meinegruppe steht.
Ich erhalte nun im Log den Fehler
[auth_basic:error] [pid 3432:tid 1968] [client xxx.xxx.xxx.xxx:yyyyy] AH01618: user blubb not found: /test/
Ich weiß jetzt allerdings auch nicht, ob es ein Fehler des Serviceusers ist, welcher sich ja mit dem AD verbindet, um die Informationen zu erhalten oder ob es daran liegt, dass der Serviceuser sich zwar verbindet, jedoch dann der Nutzer welcher sich an der Seite anmelden möchte nicht gefunden wird. Irgendwie alles doof.
Das ist der Pfad in dem deine Domänen-Benutzer gesucht werden und die Angabe, dass auf dem sAMAcountName verglichen werden soll:
Das ist der Pfad zur Gruppe in der die erlaubten Benutzer Mitglied sind
Und das hier ist der Benutzer der die LDAP-Abfrage macht:
In einem davon wirst du einen Fehler haben. Poste mal deine .htaccess
Manuel
AuthLDAPURL "ldap://dchostname:389/OU=aaa,OU=bbb,DC=example,DC=com?sAMAccountName?sub?(objectClass=*)" Das ist der Pfad zur Gruppe in der die erlaubten Benutzer Mitglied sind
require ldap-group CN=erlaubtegruppe,OU=aaa,OU=bbb,DC=example,DC=comUnd das hier ist der Benutzer der die LDAP-Abfrage macht:
AuthLDAPBindDN "CN=ApacheLDAPAuth,OU=aaa,OU=bbb,DC=example,DC=com In einem davon wirst du einen Fehler haben. Poste mal deine .htaccess
Manuel
Das ist meine .htaccess (exemplarisch) - wie sie auch ähnlich eingangs (1. post) zu sehen ist, allerdings mit der kleinen änderung, welche dann den 500er Fehler beseitigt.
AuthType Basic
AuthName "Testseite - Anmeldung erforderlich"
#Methode to authent users
AuthBasicProvider ldap
#Serviceaccountuser to read LDAP
AuthLDAPURL "ldap://xxx.yyy.internaldomain:389/DC=yyy,DC=internaldomain?sAMAccountName?sub?(objectClass=*)"
AuthLDAPBindDN ldapservice@yyy.internaldomain
AuthLDAPBindPassword securesecret
LDAPReferrals Off
AuthLDAPBindAuthoritative off
AuthLDAPGroupAttribute member
AuthLDAPGroupAttributeIsDN On
Require ldap-group CN=meinegruppe,OU=Nutzer,DC=yyy,DC=internaldomain
mit
xxx=Hostname
yyy=Domain
Nun ist es so, dass der Servicenutzer im AD unter Users steht und die Gruppe in welcher die Nutzungsmitglieder stehen in der OU Nutzer stehen.
AuthType Basic
AuthName "Testseite - Anmeldung erforderlich"
#Methode to authent users
AuthBasicProvider ldap
#Serviceaccountuser to read LDAP
AuthLDAPURL "ldap://xxx.yyy.internaldomain:389/DC=yyy,DC=internaldomain?sAMAccountName?sub?(objectClass=*)"
AuthLDAPBindDN ldapservice@yyy.internaldomain
AuthLDAPBindPassword securesecret
LDAPReferrals Off
AuthLDAPBindAuthoritative off
AuthLDAPGroupAttribute member
AuthLDAPGroupAttributeIsDN On
Require ldap-group CN=meinegruppe,OU=Nutzer,DC=yyy,DC=internaldomain
mit
xxx=Hostname
yyy=Domain
Nun ist es so, dass der Servicenutzer im AD unter Users steht und die Gruppe in welcher die Nutzungsmitglieder stehen in der OU Nutzer stehen.
Der User ist doch Mitglied der Gruppe und bezieht von der die Berechtigung.
Daher müsstest du den User berechtigen. --- "Users"
Daher müsstest du den User berechtigen. --- "Users"
Da wurde wohl etwas falsch verstanden.
Der in der Gruppe zur Berechtigung liegende User ist in der OU Nutzer nicht in dem schon vorhandenen Container Users.
Im schon vorhandenen Container steckt nur der Servicenutzer zur Anmeldung an das AD von aussen.
Die zu prüfenden User (oder auch auf deutsch Nutzer) sind in der OU Nutzer, ebenso die Sicherheitsgruppe, in welcher diese Nutzer dann zusammengefasst werden und genau diese soll ja ausgelesen werden, um zu prüfen ob der Nutzer da drin steckt und ob das übermittelte Kennwort passt. Nicht mehr, nicht weniger.
Die Frage ist nun, ob die Anmelde- und Abfragedaten, wie ich sie in der .htaccess hinterlegt habe, stimmen/passen oder ob hier ein Fehler vorliegt und falls ja wo und wie er zu beheben ist. Ich muss zugeben, dass ich so meine Schwierigkeiten im "Slang" von AD mit DC, OU, CN und was weiß ich noch habe.
Der in der Gruppe zur Berechtigung liegende User ist in der OU Nutzer nicht in dem schon vorhandenen Container Users.
Im schon vorhandenen Container steckt nur der Servicenutzer zur Anmeldung an das AD von aussen.
Die zu prüfenden User (oder auch auf deutsch Nutzer) sind in der OU Nutzer, ebenso die Sicherheitsgruppe, in welcher diese Nutzer dann zusammengefasst werden und genau diese soll ja ausgelesen werden, um zu prüfen ob der Nutzer da drin steckt und ob das übermittelte Kennwort passt. Nicht mehr, nicht weniger.
Die Frage ist nun, ob die Anmelde- und Abfragedaten, wie ich sie in der .htaccess hinterlegt habe, stimmen/passen oder ob hier ein Fehler vorliegt und falls ja wo und wie er zu beheben ist. Ich muss zugeben, dass ich so meine Schwierigkeiten im "Slang" von AD mit DC, OU, CN und was weiß ich noch habe.
Die Frage ist nun, ob die Anmelde- und Abfragedaten, wie ich sie in der .htaccess hinterlegt habe, stimmen/passen oder ob hier ein Fehler vorliegt und falls ja wo und wie er zu beheben ist.
Hast du evtl. einen Fehler im DN?
Wenn deine Domäne ad.firma.de heißt und die Benutzer dort in der OU Benutzer sind, dann heißt der DN dementsprechend OU=Benutzer,DC=ad,DC=firma,DC=de
Wenn dann deine Gruppe mit den erlaubten Benutzern in der OU Benutzer ist heißt der DN für diese Gruppe CN=ErlaubteBenutzer,OU=Benutzer,DC=ad,DC=firma,DC=de
Du kannst dir den DN für Objekte auch direkt ADUC anzeigen lassen und rauskopieren
Manuel
HURRA!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Freu und Jubeltanz es funktioniert. Vielen Dank.
Prinzipiell war es richtig.
Der Knackpunkt war eben der noch fehlende Eintrag
AuthLDAPBindAuthoritative off
GAAAAAANZ wichtig, sonst Fehler 500 out of memory bla.
Und ich hatte zwar bei require ldap-group alles richtig mit CN OU DC
Es fehlte aber die OU in welcher dann der User zu suchen ist bei AuthLDAPURL
Da hatte ich ursprünglich kein OU=.... eingetragen und daher konnte dann auch der User in der entsprechenden OU gefunden werden. Also User unbekannt. Eigentlich logisch.
Allerdings sollte doch dann bei fehlender OU im gesamten AD gesucht werden, wird es aber anscheind nicht.
Wie ist es denn mit Nutzern, welche unterhalb der OU=Nutzer hängen, also einen oder mehrere Ebenen drunter?
Wie werden User gefunden, welche sich in einer anderen OU befinden, also von derselbenen Ebene aus verzweigend?
Ich weiß, dass das Konzept strikt von oben nach unten geht.
DC=xxx, DC=localdomain, OU=Abteilung1
DC=xxx, DC=localdomain, OU=Abteilung2
DC=xxx, DC=localdomain, OU=Abteilung3
Bei der Suche würden dann - wenn man das so angibt - nur User in OU=Abteilung1 gefunden und nicht diejenigen, welche in Abteilung 2 und Abteilung 3 sich befinden. Wie geht das dann?
Würde die Suchanfrage auch User in den daran hängenden Unterebenen finden
DC=xxx, DC=localdomain, OU=Abteilung1
In der OU Abteilung 1 hängt noch die OU Abteilung 2 und Abteilung 3 dran. Würde man die User in Abteilung 3 dann auch finden, wenn die Abfrage heißt
DC=xxx, DC=localdomain, OU=Abteilung1
Freu und Jubeltanz es funktioniert. Vielen Dank.
Prinzipiell war es richtig.
Der Knackpunkt war eben der noch fehlende Eintrag
AuthLDAPBindAuthoritative off
GAAAAAANZ wichtig, sonst Fehler 500 out of memory bla.
Und ich hatte zwar bei require ldap-group alles richtig mit CN OU DC
Es fehlte aber die OU in welcher dann der User zu suchen ist bei AuthLDAPURL
Da hatte ich ursprünglich kein OU=.... eingetragen und daher konnte dann auch der User in der entsprechenden OU gefunden werden. Also User unbekannt. Eigentlich logisch.
Allerdings sollte doch dann bei fehlender OU im gesamten AD gesucht werden, wird es aber anscheind nicht.
Wie ist es denn mit Nutzern, welche unterhalb der OU=Nutzer hängen, also einen oder mehrere Ebenen drunter?
Wie werden User gefunden, welche sich in einer anderen OU befinden, also von derselbenen Ebene aus verzweigend?
Ich weiß, dass das Konzept strikt von oben nach unten geht.
DC=xxx, DC=localdomain, OU=Abteilung1
DC=xxx, DC=localdomain, OU=Abteilung2
DC=xxx, DC=localdomain, OU=Abteilung3
Bei der Suche würden dann - wenn man das so angibt - nur User in OU=Abteilung1 gefunden und nicht diejenigen, welche in Abteilung 2 und Abteilung 3 sich befinden. Wie geht das dann?
Würde die Suchanfrage auch User in den daran hängenden Unterebenen finden
DC=xxx, DC=localdomain, OU=Abteilung1
In der OU Abteilung 1 hängt noch die OU Abteilung 2 und Abteilung 3 dran. Würde man die User in Abteilung 3 dann auch finden, wenn die Abfrage heißt
DC=xxx, DC=localdomain, OU=Abteilung1