☰

Autenticación Passthrough de Windows AD con LAMP GSSAPI/Kerberos

tag-icon • tag-icon active-directory lamp passthrough gssapi
Autenticación Passthrough de Windows AD con LAMP GSSAPI/Kerberos

Intentando poner en marcha un servidor LAMP en un Windows AD y hacer que funcione la autenticación PassThrough. Un problema (que puede que no sea tan importante como lo estoy haciendo), el nombre de host y la URL alojada NO coinciden: el nombre de host de LAMP es intranethost.mspca.org, la URL alojada eshttps://testintranet.mspca.org

AD es el nivel de bosque/dominio 2012R2.

LAMP es Debian 11.8 con mod_auth_gssapi instalado con Apache. LAMP NO tiene Samba instalado y NO es miembro del dominio AD (no estaba seguro si eso era necesario).

Creé un archivo de claves desde Windows DC con lo siguiente:

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

Mi reino se agregó correctamente en krb5.cnf, kinit de LAMP pasa con gran éxito.

Apache conf (basado en un tutorial enhttps://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>

De hecho, la autenticación en sí funciona, pero todavía aparece el mensaje de inicio de sesión inicial para el sitio. No transfiere los créditos actualmente conectados a la sesión. Agregué todas las permutaciones del sitio (http/s, nombre corto, FQDN) en un GPO para la página de nivel de seguridad de la intranet, pero Chrome todavía muestra obstinadamente el cuadro de diálogo de inicio de sesión. El único 'error' en los registros de Apache es el siempre útilNO AUTH DATA Client did not send any authentication headers

Al cambiar GssapiBasicAutha APAGADO se elimina el cuadro de diálogo, pero inmediatamente aparece un 401 No autorizado, por lo que es como si ni siquiera estuvieraintentandopara pasar los encabezados...

¿Alguna sugerencia?

Respuesta1

Este pequeño:

BrowserMatch Windows gssapi-no-negotiate

Lo juro, lo vimúltiples sitios"si no tienes esta línea, los clientes de Windows no funcionarán..."

tomé esa líneaafuera, ahora funciona al 100% como se esperaba. La autenticación pasa perfectamente desde los usuarios de Windows que han iniciado sesión actualmente (a través de Chrome hasta un host interno FQDN).

Por si acaso alguna búsqueda futura en Google lleva a alguien hasta aquí...

información relacionada