LDAPs Authentifikation
In der Regel haben wir zur Verwaltung der Nutzerdaten ein Backendsystem zur Verwaltung im Einsatz. Im folgendem Konfigurationsbeispiel werden wir uns nun gegen einen vorhandenen LDAP-Server authentifizieren.
Der Webserver NGiNX stellt von Haus aus keine Möglichkeit zur LDAP-Authentifikation zur Verfügung. Mit Hilfe der Erweiterung nginx-auth-ldap von Valery Komarov kann diese aber nachgerüstet werden. Eine entsprechende aktuell Version von NGiNX mit LDAP-Authentifizierungsunterstützung ist im Repository nausch.org enthalten:
WICHTIG:
Im Gegensatz zur LDAPs Authentifikation beim Apache Webserver, vertraut das LDAP-Modul für NGiNX jedem Server-Zertifikat. Das bedeutet, wir brauchen hier nicht die Root-Zertifikate der genutzten CA1) importieren und diesen unser Vertrauen aussprechen.
Dies ist beim Einsatz von NGiNX im sicherheitskritischen Umfeld zu beachten!
Konfiguration
Die Konfiguration der LDAPs Authentifikation beim Webserver NGiNX ist aufgeteilt, in zwei Abschnitte. Der erste Abschnitt definiert den Zugang zum LDAP-Server, der zweite Teil ist dann im Abschnitt server der NGiNX-Konfiguration und verweist dann auf einen Eiintrag des „ersten Abschnitts“.
Sehen wir uns das an folgendem Beispiel genauer an.
# vim /etc/nginx/conf.d/1st_ldap.conf
- /etc/nginx/conf.d/1st_ldap.conf
# Django : 2015-07-18 # Definition für die Anbindung unseres nginx Servers an den # OpenLDAP-Server für die Authentifikation des Users django ldap_server ldap_group_1 { url ldaps://openldap.dmz.nausch.org:636/ou=People,dc=nausch,dc=org?uid?sub?(objectClass=posixAccount); binddn "cn=Technischeruser,dc=nausch,dc=org"; binddn_passwd "e1n531f!D4xIi57n393I1354u!"; group_attribute uniquemember; group_attribute_is_dn on; #parse_require user "uid=django,ou=People,dc=nausch,dc=org"; require user "uid=django,ou=People,dc=nausch,dc=org"; require user "uid=icinga2_checkuser,ou=Daemon,dc=nausch,dc=org"; } # Definition für die Anbindung unseres nginx Servers an den # OpenLDAP-Server für die Authentifikation des Users michael ldap_server ldap_group_2 { url ldaps://10.0.0.37:636/ou=People,dc=nausch,dc=org?uid?sub?(objectClass=posixAccount); binddn "cn=Technischeruser,dc=nausch,dc=org"; binddn_passwd "e1n531f!D4xIi57n393I1354u!"; group_attribute uniquemember; group_attribute_is_dn on; require user "uid=michael,ou=People,dc=nausch,dc=org"; }
Wichtig:
Der Name der Konfigurationsdatei 1st_ldap.conf wurde mit Absicht so gewählt, da nginx beim Starten die Dateien in alphabetischer Reihenfolge einliest. Die Definition des ldap_server muss vor dem verweisen der Serverkonfiguration erfolgen, andernfalls würde bei einem Test der Konfiguration, z.B. folgender Fehler auftreten:
# nginx -t
nginx: [emerg] http_auth_ldap: Using "auth_ldap_servers" when no "ldap_server" has been previously defined (make sure that "auth_ldap_servers" goes after "ldap_server"s in your configuration file) in /etc/nginx/conf.d/default.conf:29 nginx: configuration file /etc/nginx/nginx.conf test failed
Nun können wir in der Serverkonfiguration auf die gerade eben angelegten ldap_server rückverweisen.
# vim /etc/nginx/conf.d/betterawstats.conf
- /etc/nginx/conf.d/betterawstats.conf
server { # Django : 2015-05-28 # auf welchem Port soll der Server lauschen (HTTP: 80)? listen 80; # auf welchen Servernamen (vHOST) soll der Server reagieren? server_name betterawstats.nausch.org; # Welches Access- und Error-Logfile soll beschrieben werden? access_log /var/log/nginx/betterawstats_access.log; error_log /var/log/nginx/betterawstats_errors.log; # HTTP auf HTTPS mit Statuscode 301 "moved permanently" umleiten return 301 https://$server_name$request_uri; } server { # Django : 2015-05-28 # auf welchem Port soll der Server lauschen (HTTPS: 443)? # neben TLS soll auch SPDY (http://de.wikipedia.org/wiki/SPDY) # angeboten werden. listen 443 ssl spdy; # auf welchen Servernamen (vHOST) soll der Server reagieren? server_name betterawstats.nausch.org; # Welches Access- und Error-Logfile soll beschrieben werden? access_log /var/log/nginx/betterawstats_access.log; error_log /var/log/nginx/betterawstats_errors.log; # Standard-Parameter für TLS-Verschlüsselung inkludieren include /etc/nginx/ssl_params; # Zertifikatsdatei inkl. ggf. notwendiger Zwischen- und Root-Zertifikaten # 1) Server-Zertifikat, 2) Intermediate-Root-Zertifikat und # 3) Root-Zertifikat der CA ssl_certificate /etc/pki/tls/certs/betterawstats.nausch.org.certificatechain_150113.pem; # Schlüsseldatei, mit der der CSR erstellt wurde ssl_certificate_key /etc/pki/tls/private/betterawstats.nausch.org.serverkey.pem; # Zugriffe erst nach erfolreicher Authentifizierung gestatten # Authentifikation des Benutzers django gegen den zentralen # OpenLDAP-Verzeichnisdienst auth_ldap "gesperrter Bereich bei nausch.org"; auth_ldap_servers ldap_group_2; # Welcher Inhalt soll angezeigt bzw. auf welchen Server sollen # die HTTP-Requests # weitergeleitet werden? root /usr/share/betterawstats/; index index.php index.html; location ~ \.php { fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } location ~* ^/(.+\.(gif|jp?eg|png|css|js|cgi|pl|ico|swf|flv|s?html|php|xap|py|xml|txt))$ { expires 1y; root /usr/share/betterawstats; allow all; } location ~ icons { allow all; } }
Achtung:
Prüft man mit Hilfe des Befehls nginx -t die Konfiguration, wird der folgende Fehler angezeigt.
# nginx -t
nginx: [emerg] http_auth_ldap: parse_require in /etc/nginx/conf.d/1st_ldap.conf:12 nginx: [emerg] http_auth_ldap: parse_require in /etc/nginx/conf.d/1st_ldap.conf:13 nginx: [emerg] http_auth_ldap: parse_require in /etc/nginx/conf.d/1st_ldap.conf:24 nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful
Dies ist ein bekannter Fehler2). NGiNX kann aber wie gewohnt ge(re)startet werden!
Damit unsere Änderungen aktiv werden bedarf es noch eines reloads unseres HTTP-Deamon.
# systemctl reload nginx.service
WICHTIG:
Damit die Anmeldedaten nicht von Dritten mitgelesen und abgefischt werden können, nutzen wir natürlich einen SSL-geschützten vHOST!
Test
Der Webserver wird nun den Zugang erst gestatten, sobald die Daten richtig eingegeben wurden.
Wird über den Menüpunkt [ Cancel ] die Eingabe abgebrochen, verweigert der Webserver den Zutritt zur betreffenden Anwendung!