Connecting Nginx to LDAP/Kerberos

Joshua Schaeffer jschaeffer0922 at gmail.com
Wed Sep 14 16:13:06 UTC 2016


Okay, I've made some headway on this but I've hit a road block. I've setup
a test Nginx server and compiled the spnego-http-auth-nginx-module (
https://github.com/stnoonan/spnego-http-auth-nginx-module). I've updated
two location blocks in my site's configuration file to use the module to
authentication with Kerberos:

        # Test location
        location                        / {
                                                root /var/git;
                                                index index.html;

                                                # BASIC AUTH #
                                                #auth_basic
"Restricted";
                                                #auth_basic_user_file
/var/git/.htpasswd;

                                                # KERBEROS AUTH #
                                                auth_gss                on;
                                                auth_gss_realm
HARMONYWAVE.COM;
                                                auth_gss_keytab
/etc/krb5.keytab;
                                                auth_gss_service_name
http/mutalisk.harmonywave.com;
        }

        # Static repo files for cloning over https
        location                        ~ ^.*\.git/objects/([0-9a-f]+/[
0-9a-f]+|pack/pack-[0-9a-f]+.(pack|idx))$ {
                                                root
 /var/git;
        }

        # Requests that need to get to git-http-backend
        location                        ~ ^.*\.git/(HEAD|info/refs|
objects/info/.*|git-(upload|receive)-pack)$ {
                                                # BASIC AUTH #
                                                #auth_basic
"Restricted";
                                                #auth_basic_user_file
/var/git/.htpasswd;

                                                # KERBEROS AUTH #
                                                auth_gss                on;
                                                auth_gss_realm
HARMONYWAVE.COM;
                                                auth_gss_keytab
/etc/krb5.keytab;
                                                auth_gss_service_name
http/mutalisk.harmonywave.com;

                                                fastcgi_pass
 unix:/var/run/fcgiwrap.socket;
                                                fastcgi_param
SCRIPT_FILENAME         /usr/lib/git-core/git-http-backend;
                                                fastcgi_param   PATH_INFO
            $uri;
                                                fastcgi_param
GIT_PROJECT_ROOT        /var/git/;
                                                fastcgi_param
GIT_HTTP_EXPORT_ALL     "";
                                                fastcgi_param   REMOTE_USER
            $remote_user;
                                                include
fastcgi_params;
        }

When I try to access the "/" location block from a web browser from within
my network it works. The browser asks me for credentials and if I provide
them correctly then Nginx passes the index.html file. However when I try to
do a git clone to my test repo it always fails with invalid credentials.
I've collected two sets of logs and attached them. All the 01_* logs are
when I tried to do a git clone to my test repo (and failed). All the 02_*
logs are when I successfully logged into my test location ("/"). There are
four logs for each set of logs (Nginx - error.log and access.log, Kerberos
- krb5kdc.log, and LDAP - slapd.log)

Looking at the logs I see two interesting events. First comparing Nginx's
log file I see this:

   - Both logs show a "401 unauthorized" when requesting the respective
   resources (this is as expected)
   - After the 401 it looks like they Nginx is waiting for credentials
   (again, expected), however when I request my "/" block it calls
   the spnego-http-auth-nginx-module module and returns a successful
   authentication attempt, while when I run a git clone it doesn't (note that
   both my web browser and git actually ask me for my credentials):


​
Second, the Kerberos logs show a "LOOKING_UP_SERVER" error when I try to do
a git clone, while when try to just access the "/" block it successfully
issues a ticket (I'm assuming that it does that because the spnego module
is called successfully from Nginx).

   - 01_krb5kdc.log:

    Sep 14 08:26:15 immortal krb5kdc[1210](info): TGS_REQ (6 etypes {18 17
16 23 25 26}) 10.1.32.2: LOOKING_UP_SERVER: authtime 0,
jschaeffer at HARMONYWAVE.COM for HTTP/mutalisk.harmonywave.com at HARMONYWAVE.COM,
Server not found in Kerberos database
    Sep 14 08:26:15 immortal krb5kdc[1210](info): TGS_REQ (6 etypes {18 17
16 23 25 26}) 10.1.32.2: LOOKING_UP_SERVER: authtime 0,
jschaeffer at HARMONYWAVE.COM for HTTP/mutalisk.harmonywave.com at HARMONYWAVE.COM,
Server not found in Kerberos database


   - 02_krb5kdc.log:

    Sep 14 08:56:57 immortal krb5kdc[1210](info): AS_REQ (6 etypes {18 17
16 23 25 26}) 10.1.10.3: NEEDED_PREAUTH: jschaeffer at HARMONYWAVE.COM for
krbtgt/HARMONYWAVE.COM at HARMONYWAVE.COM, Additional pre-authentication
required
    Sep 14 08:56:57 immortal krb5kdc[1210](info): AS_REQ (6 etypes {18 17
16 23 25 26}) 10.1.10.3: ISSUE: authtime 1473865017, etypes {rep=18 tkt=18
ses=18}, jschaeffer at HARMONYWAVE.COM for krbtgt/
HARMONYWAVE.COM at HARMONYWAVE.COM
    Sep 14 08:56:57 immortal krb5kdc[1210](info): AS_REQ (6 etypes {18 17
16 23 25 26}) 10.1.10.3: NEEDED_PREAUTH: jschaeffer at HARMONYWAVE.COM for
krbtgt/HARMONYWAVE.COM at HARMONYWAVE.COM, Additional pre-authentication
required
    Sep 14 08:56:57 immortal krb5kdc[1210](info): AS_REQ (6 etypes {18 17
16 23 25 26}) 10.1.10.3: ISSUE: authtime 1473865017, etypes {rep=18 tkt=18
ses=18}, jschaeffer at HARMONYWAVE.COM for krbtgt/
HARMONYWAVE.COM at HARMONYWAVE.COM

I've looked around but I couldn't really find a good explanation of what
"LOOKING_UP_SERVER" error means in my situation and I've never seen the
error myself before.

I guess where I'm really stuck right now is why does my git block not call
this like my "/" block does:

    2016/09/14 08:56:57 [debug] 14254#14254: *3 Basic auth credentials
supplied by client
    2016/09/14 08:56:57 [debug] 14254#14254: *3 Attempting authentication
with principal jschaeffer
    2016/09/14 08:56:57 [debug] 14254#14254: *3 Setting $remote_user to
jschaeffer
    2016/09/14 08:56:57 [debug] 14254#14254: *3
ngx_http_auth_spnego_set_bogus_authorization: bogus user set
    2016/09/14 08:56:57 [debug] 14254#14254: *3 ngx_http_auth_spnego_basic:
returning NGX_OK
    2016/09/14 08:56:57 [debug] 14254#14254: *3 Basic auth succeeded

On Mon, Sep 12, 2016 at 1:52 PM, Joshua Schaeffer <jschaeffer0922 at gmail.com>
wrote:

>
> On Mon, Sep 12, 2016 at 1:37 PM, A. Schulze <sca at andreasschulze.de> wrote:
>
>>
>>
>> Am 12.09.2016 um 21:33 schrieb Joshua Schaeffer:
>>
>>> Any chance anybody has played around with Kerberos auth? Currently my SSO
>>> environment uses GSSAPI for most authentication.
>>>
>>
>> I compile also the module https://github.com/stnoonan/sp
>> nego-http-auth-nginx-module
>> but I've no time to configure / learn how to configure it
>> ... unfortunately ...
>
>
> I did actually see this module as well, but didn't look into it too much.
> Perhaps it would be best for me to take a closer look and then report back
> on what I find.
>
> Thanks,
> Joshua Schaeffer
>
>
Any help would be appreciated.

Thanks
Joshua Schaeffer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160914/bc5621f1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Nginx_kerberos_auth1.png
Type: image/png
Size: 137369 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160914/bc5621f1/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logs.tar.gz
Type: application/x-gzip
Size: 6329 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160914/bc5621f1/attachment.bin>


More information about the nginx mailing list