Schlagwort-Archive: LDAP

Software

Windows Server 2012R2: „Ereignisdaten können nicht abgerufen werden“ durch LDS-Rolle

Ein Kommentar

Eigentlich ist der Server Manager ja eine tolle Idee: Windows-Server können hiermit auch von Personen ohne Textkonsolenaffinität in großen Teilen zentral verwaltet werden. Dumm nur, wenn entscheiderabweisende, rote Fehlermeldungen das Dashboard zieren. Klickt man eine dieser Warnungen an erscheint als Serverstatus

Online – Ereignisdaten können nicht abgerufen werden

Auch die Details sind nicht wesentlich aussagekräftiger:

Ereignisse aus adam.events.xml konnten nicht aufgezählt werden

Ursache in meinem Fall: Microsoft Active Directory Lightweight Directory Services (AD LDS). Diesen hatte ich seinerzeit,in der Vermutung, dass er für einen LDAP-Zugriff auf das AD notwendig wäre, mit angeklickt. Knackpunkt: Er wurde nie fertig eingerichtet. Der hierzu nötige Wizzard ist nur im Startmenü zu finden und wird nicht, wie bei anderen Rollen üblich, direkt im Servermanager verlinkt. Durch die fehlende Konfiguration wird eine Warnung generiert, welche ihrerseits wegen eines Fehlers im Servermanager nicht korrekt angezeigt wird.

Als Lösung kann man entweder die LDS-Rolle über das Startmenü fertig konfigurieren oder – wenn man sie wie ich wegen falscher Vermutungen installierte – einfach entfernen. Ein LDAP-Zugriff auf das AD ist auch ohne sie möglich.

Software

Apache Reverse Proxy mit LDAP absichern

Schreibe einen Kommentar

Apache als Reverse Proxy hatten wir jetzt ja schon öfter, jedoch immer nur als 1:1-Druchlass. Ab und an möchte man jedoch Systeme nur einem beschränken Nutzerkreis verfügbar machen. Der Vorteil einer Filterung auf dem Proxy selbst: Dieser ist meist sicherer als die nachgeschalteten Systeme und hat durch seine Position innerhalb der DMZ bei einem Einbruch weniger Zugriffe auf die internen Systeme als die endgültig erreichten Systeme. Als Nutzerdatenbank ist LDAP, z.B. bei der Nutzung von Microsofts „Active Directory“ sehr verbreitet.

Um den Ordner /test abzusichern lässt sich folgender Codeblock nutzen, welcher das vorherige ProxyPass/ProxyPassReverse ersetzt. Ohne Proxy ist der Block natürlich auch zur Absicherungen „normaler“ Webseiten nutzbar.

 #Test LDAP
<Location /testldap>
    Require all denied
    ProxyPass http://intern.adlerweb.info/test
    ProxyPassReverse http://intern.adlerweb.info/test
    AuthLDAPBindDN "CN=apacheuser,OU=Systemaccounts,OU=Intern,DC=Adlerweb;DC=info"
    AuthLDAPBindPassword "1234"
    AuthLDAPURL "ldap://dc1.intern.adlerweb.info/ou=Intern,dc=Adlerweb,dc=info?sAMAccountName?sub?(objectClass=*)"
    AuthType Basic
    AuthName "Adlerweb ADS Auth"
    AuthBasicProvider ldap
    # Important, otherwise "(9)Bad file descriptor: Could not open password file: (null)"
    AuthUserFile /dev/null
    require valid-user
</Location>

Hiermit dürfen alle Nutzer in der Organisationseinheit „Intern“ der Domäne „Adlerweb.info“ auf die Ressourcen zutreffen (valid-user).

Es sind auch spezifischere Zuweisungen möglich – über den Nutzernamen:

Require ldap-user "adlerweb"

…über die DN

Require ldap-dn CN=adlerweb,OU=Intern,dc=Adlerweb,dc=info

Für Gruppen gibt es mehrere Möglichkeiten: 

Require ldap-group CN=Testgruppe,OU=Intern,dc=Adlerweb,dc=info

ist die klassische Methode, macht jedoch mit Active Directory Probleme: Nutzer in der genannten Gruppe haben fehlerfrei Zugriff, sind jedoch rekursive Gruppen vorhanden schlägt die Authentifizierung fehl. Als Ausweg kann man hier einen LDAP-Filter verwenden – nicht ganz so schön, dafür funktionierend:

Require ldap-filter memberof:1.2.840.113556.1.4.1941:=CN=Testgruppe,OU=Intern,dc=Adlerweb,dc=info

Quellen:
http://serverfault.com/a/424706