Authenticating Apache HTTPServer 2.4.x with mod_auth_gssapi using Microsoft Active directory

Question

I'm looking for below configurations for GSSAPI authentication with Apache 2.4 for Active directory:

1. How to configure Apache HTTPServer 2.4.x with mod_auth_gssapi using Microsoft Active directory? Is there any documentation OR POC example stating the required configuration to do in Apache HTTPServer 2.4.x for GSSAPI, So as to authenticate using GSSAPI mechanism with Microsoft Active directory?

2. Does mod_auth_gssapi provides Integrity & Confidentiality security services? If yes then what configuration is required to do in Apache HTTPServer? Reference for Integrity & Confidentiality in GSSAPI.

As per my analysis, the Active directory supports GSSAPI SASL mechanism. But, Apache HTTPserver does not support GSSAPI as an out of box configuration. However, using mod_auth_gssapi it's possible for Apache HTTPServer to lookup for users & their credentials in Active directory and thereby authenticate using GSSAPI mechanism.

Currently, I'm having Basic authentication provider configured as below in Apache HTTPServer, which needs to be replaced with mod_auth_gssapi to implement gssapi authentication mechanism:

# Basic Authentication provider

<AuthnProviderAlias ldap MyEnterpriseLdap>
  AuthLDAPURL "ldap://machine1.abcd.com:389/CN=Users,DC=abcd,DC=com?sAMAccountName?sub?(objectClass=*)"
  AuthLDAPBindDN "CN=rohit,CN=Users,DC=abcd,DC=com"
  AuthLDAPBindPassword "abc123"
  LDAPReferrals Off
</AuthnProviderAlias>

# Authenticated resources

<LocationMatch ^/+WebApp/+(;.*)?>
  AuthName "WebApp"
  AuthType Basic
  AuthBasicProvider MyEnterpriseLdap 
  Require valid-user
</LocationMatch>

Thanks.

score 2 · Answer 1 · answered Sep 21 '21 at 12:46

I managed to make GSSAPI work using the following tutorial: http://www.jfcarter.net/~jimc/documents/bugfix/41-auth-kerb.html

What I did (I'm on Debian)

Join the domain

Install packages:

apt-get install --no-install-recommends winbind smbclient krb5-config krb5-user libldap-common

In /etc/krb5.conf:

[libdefaults]
    kdc_timesync = 1
    ccache_type = 4
    forwardable = true
    proxiable = true
    fcc-mit-ticketflags = true

    ### My changes ###
    default_realm = MY-DOMAIN.FR
    default_keytab_name = FILE:/etc/krb5.keytab
    ticket_lifetime = 24h
    dns_lookup_realm = false
    dns_lookup_kdc = false
    # AD in 2008+? Using AES
    default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
    default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
    permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
    ### end ###

[realms]
    MY-DOMAIN.FR = {
        kdc = ad1.my-domain.fr
        kdc = ad2.my-domain.fr
        master_kdc = ad1.my-domain.fr
        admin_server = ad1.my-domain.fr
        default_domain = my-domain.fr
        # Hack to remove the '@my-domain.fr' part of the user login, to only keep the prefix (facultative. Used to simplify my PHP auth mechanism)
        # Source: http://comp.protocols.kerberos.narkive.com/57JV8mmf/libapache2-mod-auth-kerb-and-cross-realm
        #       (Greg Hudson)
        auth_to_local = RULE:[1:$1@$0](.*@my-domain.fr)s/@my-domain.fr$//
        auth_to_local = DEFAULT
    }

[domain_realm]
    .my-domain.fr = MY-DOMAIN.FR
    my-domain.fr = MY-DOMAIN.FR

In /etc/samba/smb.conf:

[global]
    workgroup           = MY-DOMAIN
    realm               = MY-DOMAIN.FR
    security            = ADS
    encrypt passwords   = yes
    password server     = ad1.my-domain.fr
    kerberos method     = system keytab

(the rest of the file is unmodified)

Disable referrals for LDAP calls:

/bin/echo 'REFERRALS off' >> /etc/ldap/ldap.conf

Join the domain:

kinit administrateur
  # (use an admin AD account)

net ads join -U administrateur createcomputer=OU=Member\ servers,DC=my-domain,DC=fr
  # (specify where you want to store the object in your AD.
  # I translated the name in English, so 'Member Servers' is just an example

Keytab for http

Create a keytab in /etc/krb5.keytab:

net ads keytab add HTTP -U administrateur

Protect it: (in my case, www-data is the Unix user used for serving web pages)

chmod 640 /etc/krb5.keytab
chown root:www-data /etc/krb5.keytab

I added a script in the crontab to renew this keytab once a day. Not sure it is still needed, but on previous versions of Debian I had some bugs when the file was outdated. So I made a script in Expect calling net ads keytab add HTTP -U my-linux.ad-account for me. And it is still there :)

Configure Apache

Get GSSAPI for Apache:

apt-get install --no-install-recommends libapache2-mod-auth-gssapi

Activating session cookies (to avoid reauthenticate user on each page) - facultative

a2enmod session
a2enmod session_cookie

In your Apache site config (eg. /etc/apache2/sites-available/000-default.conf)

<VirtualHost *:443>
    SSLEngine on
    DocumentRoot /your/web/root

    <Directory /your/web/root>
        AuthType                GSSAPI
        AuthName                "My Domain"
        GssapiCredStore         keytab:/etc/krb5.keytab
        GssapiAcceptorName      HTTP
        GssapiBasicAuth         On
        GssapiNegotiateOnce     On
        GssapiSSLonly           On
        GssapiLocalName         On
        # Use a cookie to keep the session, avoid reauthenticate user on each page
        # (facultative)
        GssapiUseSessions       On
        GssapiDelegCcacheDir    /run/apache2/clientcaches
        <IfModule mod_session.c>
            Session on
        </IfModule>
        <IfModule mod_session_cookie.c>
            SessionCookieName gssapi_session path=/;httponly;secure;
        </IfModule>

        Require valid-user
    </Directory>

    ....
</VirtualHost>

Restart Apache and pray

service apache2 restart

I hope I didn't forget anything.

Footing notes: the web clients won't delegate their credentials (and the SSO will not work) if:

your webserver is not in TLS (SSLEngine on)
your webserver is not in the clients trusted sites ("Intranet Sites" of your Internet settings, for example)

SSO should be completely independent from credential delegation. Only in RDP they're tied together, elsewhere in Kerberos they aren't. (Requiring unconstrained delegation to any random webserver is somewhat of a security risk, too...) — user1686, Sep 21 '21 at 18:09
Regarding keytab updates, it might be because you're using the "machine" keys for the webserver. (Again not a very good idea.) Like Windows, Samba will change the machine account's password every month or so, which makes the old keytab invalid. You can however configure smb.conf to automatically provide a keytab (iirc, the "kerberos method" option). Still, a better approach would be to create a separate *user* account in AD that'll represent the web server; assign the HTTP/foo SPN to it; and make a keytab for that account – independent from the machine. Wouldn't even require the domain join. — user1686, Sep 21 '21 at 18:13
Ohh. Thanks for your advices. I'll try, and will update my answer if I manage to make it work. Thanks! — Worst, Sep 22 '21 at 08:13
I managed to make it work with a user account, activating delegation on it (and do not use samba anymore). But as the Linux web server is not in the domain anymore, I have to allow delegation for "all services (Kerberos only)". (I can't restrict the delegation to a specific HTTP service on a specific host). So I'm not sure it is more secure. What would be the "state of the art" way of doing this? — Worst, Sep 27 '21 at 07:46
Ah, so you *were* specifically using constrained delegation when you had the "full domain join" method. I didn't realize that. Regardless, I'd say the answer is to not use delegation _at all_... there's nothing in this entire thread that would indicate delegation being necessary. — user1686, Sep 27 '21 at 11:34

Authenticating Apache HTTPServer 2.4.x with mod_auth_gssapi using Microsoft Active directory

1 Answers1

Join the domain

Keytab for http

Configure Apache