Kerberos auth ok, but not Single Sign On

[taumeister]

Hello,
thanks for your work an this module.
We try to enable SSO for Kanboard for our Company.
Compiling and stuff is all ok.
Debugging on general kerberos ticket and things ok, means it works.
Keytab and things all in place and work too ( with apache SSO is no problem )
IF enabling your module, I am getting a popup auth window, where i can authenticate with kerberos and
then I have access to the website ( kanboard Login, or plain nginx welcome screen if no app is installed ).
But this is only some kind of kerberos auth, not SSO.
It looks like as if the information is not properly forwarded to the backend ( my own assumption, sorry ).

Can you tell me what I have to configure to get real SSO with your module and nginx,
maybe special settings in nginx.conf or site.conf?

Any help is much appreciated,
thanks a lot
Greetings
Thomas

[jcrreis]

Hello @taumeister , could you solve this issue? I'm having trouble too getting SSO working for this module..

[taumeister]

No sorry, in the end, I did it with apache, keytab.

[jcrreis]

@stnoonan any idea how to get SSO working with this module? is it not possible?

[jheiss]

I believe what you mean when you say SSO is authenticating to the nginx web server with a Kerberos ticket, rather than username and password. This module definitely supports that, and is indeed its primary purpose. Authenticating to nginx with a username and password (where this module then passes the username and password to Kerberos to validate) is what is enabled by the auth_gss_allow_basic_fallback setting. You mentioned "getting a popup auth window", which would be indicative of falling back to username/password auth.

As for getting ticket or SSO authentication working, the basic settings are covered in the README. auth_gss and auth_gss_keytab should be all you need for basic functionality. Unfortunately debugging Kerberos if you're not familiar with it can be a bit challenging. At a minimum I would suggest double-checking that the Kerberos principal in your keytab matches the name you're using on the client side. E.g. if you're running curl --negotiate -u: https://foo.example.com/ then you need to make sure your keytab has an entry for HTTP/foo.example.com. And after running curl you can check that klist on the client shows that the client got a ticket for HTTP/foo.example.com. If you get that far you've probably got the credential parts working and then it would be a matter of looking at nginx logs to see what is going on.

[jcrreis]

@jheiss Hello, whenever i try to run curl --negotiate -u: http://foo.example.com:8080/api/user/ I get a 401 Unauthorized as a response. However when i run klist i get:

Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: HTTP/foo.example.com@EXAMPLE.COM

Valid starting Expires Service principal
10/24/22 14:25:44 10/25/22 00:25:44 krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 10/25/22 14:25:44

So I have the kerberos ticket for HTTP/foo.exajmple.com but it isn't working when negotiating the kerberos ticket.

In my nginx conf i have:

proxy_pass http://127.0.0.1:8000;
auth_gss on;
auth_gss_keytab /etc/krb5.keytab;
proxy_set_header Authorization "";
proxy_set_header REMOTE_USER $remote_user;

I think I have all configured the right way, but still can't get SSO working, only works when the user put their right credentials in the window popup...

[jheiss]

Anything relevant in your nginx logs? If you add -i to curl does it show nginx prompting with WWW-Authenticate: Negotiate and the client responding with a token?

[jcrreis]

Hello,

NGINX logs

2022/10/27 11:53:07 [debug] 11161#11161: *2 SSO auth handling IN: token.len=0, head=0, ret=401
2022/10/27 11:53:07 [debug] 11161#11161: *2 Begin auth
2022/10/27 11:53:07 [debug] 11161#11161: *2 Detect basic auth
2022/10/27 11:53:07 [debug] 11161#11161: *2 Detect SPNEGO token
2022/10/27 11:53:07 [debug] 11161#11161: *2 SSO auth handling OUT: token.len=0, head=1, ret=401
2022/10/27 11:53:07 [debug] 11161#11161: *2 http finalize request: 401, "/api/user/?" a:1, c:1
2022/10/27 11:53:07 [debug] 11161#11161: *2 http special response: 401, "/api/user/?"
2022/10/27 11:53:07 [debug] 11161#11161: *2 http set discard body
2022/10/27 11:53:07 [debug] 11161#11161: *2 xslt filter header
2022/10/27 11:53:07 [debug] 11161#11161: *2 HTTP/1.1 401 Unauthorized
Server: nginx/1.14.0 (Ubuntu)
Date: Thu, 27 Oct 2022 10:53:07 GMT
Content-Type: text/html
Content-Length: 204
Connection: keep-alive
WWW-Authenticate: Negotiate
WWW-Authenticate: Basic realm=""

(venv) joao@:~/exampleproj$ curl --negotiate -i -u: http://foo.example.com:8080/api/user/
HTTP/1.1 401 Unauthorized
Server: nginx/1.14.0 (Ubuntu)
Date: Thu, 27 Oct 2022 10:53:07 GMT
Content-Type: text/html
Content-Length: 204
WWW-Authenticate: Negotiate
WWW-Authenticate: Basic realm=""
Cache-Control: proxy-revalidate
Proxy-Connection: Keep-Alive
Connection: Keep-Alive
Proxy-support: Session-based-authentication

<html>
<head><title>401 Authorization Required</title></head>
<body bgcolor="white">
<center><h1>401 Authorization Required</h1></center>
<hr><center>nginx/1.14.0 (Ubuntu)</center>
</body>
</html>

[jheiss]

The curl output indicates that nginx offered Negotiate and Basic authentication to curl, and (presuming that's the complete output) curl didn't respond with either one. (In fact curl didn't respond at all, it just gave up.) I guess I'd double-check that your curl has negotiate support by running curl -V and checking that it lists SPNEGO as a Feature.

[jcrreis]

Hello,

My curl have indeed SPNEGO GSSAPI and Kerberos listed as features.

curl 7.58.0 (x86_64-pc-linux-gnu) libcurl/7.58.0 OpenSSL/1.1.1 zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
Release-Date: 2018-01-24
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL