☰

Passthrough-Windows-AD-Authentifizierung mit LAMP GSSAPI/Kerberos

tag-icon • tag-icon active-directory lamp passthrough gssapi
Passthrough-Windows-AD-Authentifizierung mit LAMP GSSAPI/Kerberos

Ich versuche, einen LAMP-Server auf einem Windows AD einzurichten und die Passthrough-Authentifizierung zum Laufen zu bringen. Ein Problem (das vielleicht nicht so schlimm ist, wie ich es mache), der Hostname und die gehostete URL stimmen NICHT überein: LAMP-Hostname ist intranethost.mspca.org, gehostete URL isthttps://testintranet.mspca.org

AD ist auf Gesamtstruktur-/Domänenebene 2012R2.

LAMP ist Debian 11.8 mit mod_auth_gssapi, das mit Apache installiert wurde. Auf LAMP ist Samba NICHT installiert und es ist KEIN Mitglied der AD-Domäne (ich war nicht sicher, ob das notwendig ist).

Es wurde eine Keyspan-Datei vom Windows DC mit folgendem Inhalt erstellt:

ktpass -princ HTTPS/[email protected] -mapuser [email protected] -pass ******** -ptype KRB5_NT_PRINCIPAL -out testintranet-spn.keytab

Mein Realm wurde korrekt zu krb5.cnf hinzugefügt, kinit von LAMP besteht mit Bravour.

Apache conf (basierend auf einem Tutorial unterhttps://www.jfcarter.net/%7Ejimc/documents/bugfix/41-auth-kerb.html):

<IfModule !mod_auth_gssapi.c>
    LoadModule auth_gssapi_module /usr/lib64/httpd/modules/mod_auth_gssapi.so
</IfModule>

<VirtualHost *:80>
        ServerName testintranet.mspca.org
#       Redirect permanent / https://testintranet.mspca.org/
</VirtualHost>

<VirtualHost *:443>
        SSLEngine On
        SSLCertificateFile /etc/ssl/certs/star_mspca_org.crt
        SSLCertificateKeyFile /etc/ssl/private/star_mspca_org.key
        ServerAdmin [email protected]
        ServerName testintranet.mspca.org
        DocumentRoot /var/www/html/wordpress/

        <Directory "/var/www/html/wordpress/">
                AllowOverride All
                AuthType GSSAPI
                AuthName "GSSAPI Single Sign On Login"
                GssapiSSLonly On
                GssapiAllowedMech krb5
                GssapiBasicAuth On
                GssapiCredStore keytab:/etc/apache2/testintranet-spn.keytab
                GssapiLocalName On
                BrowserMatch Windows gssapi-no-negotiate
                Require valid-user
                GssapiNegotiateOnce on
        </Directory>

        ErrorLog ${APACHE_LOG_DIR}/wordpress.error.log
        CustomLog ${APACHE_LOG_DIR}/wordpress.access.log combined
        LogLevel info auth_gssapi:debug ssl:warn
</VirtualHost>

Die Authentifizierung selbst funktioniert zwar, aber ich erhalte immer noch die erste Anmeldeaufforderung für die Site. Die aktuell angemeldeten Anmeldeinformationen werden nicht in die Sitzung übertragen. Ich habe jede Permutation der Site (http/s, Kurzname, FQDN) in ein GPO für die Seite mit der Intranet-Sicherheitsstufe aufgenommen, aber Chrome zeigt immer noch hartnäckig den Anmeldedialog an. Nur „Fehler“ in den Apache-Protokollen ist die immer hilfreicheNO AUTH DATA Client did not send any authentication headers

Wenn ich es auf OFF schalte, GssapiBasicAuthwird der Dialog eliminiert, aber ich bekomme sofort eine 401 Unauthorized, also ist es, als wäre es nicht einmalversuchenum die Header zu übergeben...

Irgendwelche Vorschläge?

Antwort1

Dieser kleine Kerl:

BrowserMatch Windows gssapi-no-negotiate

Ich schwöre, ich sah aufmehrere Seiten„Wenn Sie diese Zeile nicht haben, funktionieren Windows-Clients nicht …“

Ich habe diese Linieaus, jetzt funktioniert es 100 % wie erwartet. Die Authentifizierung wird von den aktuell angemeldeten Windows-Benutzern (über Chrome zu einem internen FQDN-Host) problemlos durchgeführt.

Nur für den Fall, dass eine zukünftige Google-Suche jemanden hierher führt …

verwandte Informationen