SSO works only for high level Active Directory UO #282

marcoriccine · 2022-11-18T14:24:33Z

marcoriccine
Nov 18, 2022

Hallo,
I'd like to setup a SSO authentication using mod_auth_gssapi to the intranet webserver.
With the AD structure like this one:

XXX.LOCAL
    ADMINS
    GROUP1
       LOCATION1
          OFFICE1
    GROUP2
       LOCATION2
          OFFICE2

And a test user test@XXX.LOCAL,
if the user belongs to a first level UO (like ADMINS, GROUP1 or GROUP2) SSO works, the page is opened the username is passed to $_SERVER["REMOTE_USER"] php variable.
if the user belongs to a lower level UO (like LOCATION1, OFFICE1 etc.) a popup for credential input is showed, the page is correctly opened on putting the right credentials.

Here the apache conf snippet:

 <Directory "/dati/segreto/">
     AuthType GSSAPI
     AuthName "intranet Riccione"
     GssapiBasicAuth On
     GssapiLocalName On
     GssapiCredStore keytab:/etc/winkerberos.keytab
    require valid-user
 </Directory>

Setting GssapiBasicAuth Off, if the test user is in a lower level UO no popup is showed, but i get this error "Unauthorized
This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required."

I'm looking around to find how to resolve.
Thanks,
Marco

simo5 · 2022-11-18T16:36:16Z

simo5
Nov 18, 2022
Maintainer

Can you provide an example of what the UPN for allowed and disallowed users look like?

Use use GssapiLocalName On this means you are telling mod_auth_gssapi to ask libkrb5 to verify that the principal name received has an actual mapping to a local user.

What does your auth_to_local krb5.conf option look like?

If you do not care for mapping to local users and just want to allow any principal in the XXX.LOCAL realm do not set GssapiLocalName On

Description of the option from the README.md file:

GssapiLocalName

Tries to map the client principal to a local name using the gss_localname() call. This requires configuration in the /etc/krb5.conf file in order to allow proper mapping for principals not in the default realm (for example a user coming from a trusted realm). See the 'auth_to_local' option in the [realms] section of krb5.conf(5)

When GssapiLocalName is set to on, mod_auth_gssapi will set the REMOTE_USER variable to the resolved user name. mod_auth_gssapi will also set the GSS_NAME variable to the complete client principal name.

6 replies

simo5 Nov 21, 2022
Maintainer

Need more debugging info probably but I see two possibilities:

location1 belongs to a different AD domain in a forest, therefore the realm does not match
machines in location1 fail to do kerberos and they fall back to ntlm authentication, which you do not support in your mod_auth_gssapi configuration

You can set apache logs to debug level to see what mod_auth_gssapi says about these authentication attempts, they should give you more clues hopefully.

marcoriccine Nov 22, 2022
Author

Hi Simo5,
Thank's for help.

location1 belongs to a different AD domain in a forest, therefore the realm does not match

We have only one AD domain

machines in location1 fail to do kerberos and they fall back to ntlm authentication, which you do not support in your mod_auth_gssapi configuration

may be, when the user belongs to a low level UO (LOCATION1), whe have a fail back to ntlm... how should i configure mod_auth_gssapi?

Here a screenshot from AD users and computers

I move the test user between the INTRANET UO (SSO works) and the CANILE SSO (SSO fails)

You can set apache logs to debug level to see what mod_auth_gssapi says about these authentication attempts, they should give you more clues hopefully.

I had setted up debug level, but it didn't helped me.
This is the debug log when the user is in the CANILE UO

utente@intranet:/etc/apache2/sites-enabled$ tail /var/log/apache2/https443_error.log -f | grep aut
[Tue Nov 22 10:52:29.731771 2022] [authz_core:debug] [pid 33440] mod_authz_core.c(817): [client 172.16.0.79:53125] AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[Tue Nov 22 10:52:29.731803 2022] [authz_core:debug] [pid 33440] mod_authz_core.c(817): [client 172.16.0.79:53125] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[Tue Nov 22 10:52:29.731835 2022] [auth_gssapi:debug] [pid 33440] mod_auth_gssapi.c(895): [client 172.16.0.79:53125] URI: /topsecret/info.php, no main, no prev
[Tue Nov 22 10:52:29.731874 2022] [auth_gssapi:info] [pid 33440] [client 172.16.0.79:53125] NO AUTH DATA Client did not send any authentication headers
----waiting for credential ------------------
[Tue Nov 22 10:55:25.671326 2022] [authz_core:debug] [pid 33444] mod_authz_core.c(817): [client 172.16.0.79:53268] AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[Tue Nov 22 10:55:25.671365 2022] [authz_core:debug] [pid 33444] mod_authz_core.c(817): [client 172.16.0.79:53268] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[Tue Nov 22 10:55:25.671407 2022] [auth_gssapi:debug] [pid 33444] mod_auth_gssapi.c(895): [client 172.16.0.79:53268] URI: /topsecret/info.php, no main, no prev
[Tue Nov 22 10:55:25.827174 2022] [authz_core:debug] [pid 33444] mod_authz_core.c(817): [client 172.16.0.79:53268] AH01626: authorization result of Require valid-user : granted
[Tue Nov 22 10:55:25.827225 2022] [authz_core:debug] [pid 33444] mod_authz_core.c(817): [client 172.16.0.79:53268] AH01626: authorization result of <RequireAny>: granted
[Tue Nov 22 10:55:25.827256 2022] [auth_gssapi:debug] [pid 33444] mod_auth_gssapi.c(727): [client 172.16.0.79:53268] GSSapiImpersonate not On, skipping impersonation.
[Tue Nov 22 10:55:25.950292 2022] [authz_core:debug] [pid 33444] mod_authz_core.c(817): [client 172.16.0.79:53268] AH01626: authorization result of Require all granted: granted, referer: https://intranet.zzz.it/topsecret/info.php
[Tue Nov 22 10:55:25.950314 2022] [authz_core:debug] [pid 33444] mod_authz_core.c(817): [client 172.16.0.79:53268] AH01626: authorization result of <RequireAny>: granted, referer: https://intranet.zzz.it/topsecret/info.php
[Tue Nov 22 10:55:25.950334 2022] [auth_gssapi:debug] [pid 33444] mod_auth_gssapi.c(727): [client 172.16.0.79:53268] GSSapiImpersonate not On, skipping impersonation., referer: https://intranet.zzz.it/topsecret/info.php

This is the debug log when the user is in the INTRANET UO

utente@intranet:/etc/apache2/sites-enabled$ tail /var/log/apache2/https443_error.log -f | grep aut
[Tue Nov 22 11:19:57.701894 2022] [authz_core:debug] [pid 33441] mod_authz_core.c(817): [client 172.16.0.79:54661] AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[Tue Nov 22 11:19:57.701939 2022] [authz_core:debug] [pid 33441] mod_authz_core.c(817): [client 172.16.0.79:54661] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[Tue Nov 22 11:19:57.702121 2022] [auth_gssapi:debug] [pid 33441] mod_auth_gssapi.c(895): [client 172.16.0.79:54661] URI: /topsecret/info.php, no main, no prev
[Tue Nov 22 11:19:57.702220 2022] [auth_gssapi:info] [pid 33441] [client 172.16.0.79:54661] NO AUTH DATA Client did not send any authentication headers
[Tue Nov 22 11:19:57.731180 2022] [authz_core:debug] [pid 33441] mod_authz_core.c(817): [client 172.16.0.79:54661] AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[Tue Nov 22 11:19:57.731197 2022] [authz_core:debug] [pid 33441] mod_authz_core.c(817): [client 172.16.0.79:54661] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[Tue Nov 22 11:19:57.731210 2022] [auth_gssapi:debug] [pid 33441] mod_auth_gssapi.c(895): [client 172.16.0.79:54661] URI: /topsecret/info.php, no main, no prev
[Tue Nov 22 11:19:57.732479 2022] [authz_core:debug] [pid 33441] mod_authz_core.c(817): [client 172.16.0.79:54661] AH01626: authorization result of Require valid-user : granted
[Tue Nov 22 11:19:57.732504 2022] [authz_core:debug] [pid 33441] mod_authz_core.c(817): [client 172.16.0.79:54661] AH01626: authorization result of <RequireAny>: granted
[Tue Nov 22 11:19:57.732533 2022] [auth_gssapi:debug] [pid 33441] mod_auth_gssapi.c(727): [client 172.16.0.79:54661] GSSapiImpersonate not On, skipping impersonation.
[Tue Nov 22 11:19:57.857490 2022] [authz_core:debug] [pid 33441] mod_authz_core.c(817): [client 172.16.0.79:54661] AH01626: authorization result of Require all granted: granted, referer: https://intranet.zzz.it/topsecret/info.php
[Tue Nov 22 11:19:57.857516 2022] [authz_core:debug] [pid 33441] mod_authz_core.c(817): [client 172.16.0.79:54661] AH01626: authorization result of <RequireAny>: granted, referer: https://intranet.zzz.it/topsecret/info.php
[Tue Nov 22 11:19:57.857536 2022] [auth_gssapi:debug] [pid 33441] mod_auth_gssapi.c(727): [client 172.16.0.79:54661] GSSapiImpersonate not On, skipping impersonation., referer: https://intranet.zzz.it/topsecret/info.php

The only difference is the tail log stops waiting for credential input
Any idea?

EDIT:
to verify if fallback to NTLM occours, tried GssapiAllowedMech directive:
with GssapiAllowedMech krb5 nothing changes
with GssapiAllowedMech ntlmssp the credential popup always appears, but cannot login
This should mean no fallback to NTLM, isn't it?

simo5 Nov 22, 2022
Maintainer

Configuring NTLM authentication is not simple, it requires installing the gssntlmssp package as well as joining the machine to the AD domain with Winbind (samba).

In general it is better to figure out why the authentication fails and fix it AD side.

For example you could have Domain Policies in the OU that do not allow users to get a ticket for the HTTP server where mod_auth_gssapi is installed even if the user is using Kerberos to authenticate to AD.

To me this is clearly an AD side issue, configuration or otherwise, as mod_auth_gssapi has no visibility into OUs or groups or anything like that.

marcoriccine Nov 22, 2022
Author

i think you right seems a Active Directory issue.
New try: created a brand new YOU, hoping it avoid Domain Policies setting, the SSO works if the OU is at first level, asks credential otherwise
I restart googoling for AD info.
Thank's for help!

marcoriccine Nov 25, 2022
Author

Finally i found a difference between the situation, in the request header
When the SSO works

Connection: Keep-Alive
Content-Encoding: gzip
Content-Length: 25556
Content-Type: text/html; charset=UTF-8
Date: Fri, 25 Nov 2022 13:32:52 GMT
Keep-Alive: timeout=5, max=99
Server: Apache/2.4.41 (Ubuntu)
Vary: Accept-Encoding
WWW-Authenticate: Negotiate oYG2MIGzoAMKAQChCwYJKoZIgvcSAQICooGeBIGbYIGYBgkqhkiG9xIBAgICAG+BiDCBhaADAgEFoQMCAQ+ieTB3oAMCARKicARuAzc+FBeiORnXRoF4wTs6YDoBqo3VZOh2OLfOFmOV16JpREwxpassraj356pdag8J8QZWXIDuAcsdfxsYM+rvKIk66XBoseW8qifoCFtHaadf345+Yc=

when SSO fail

Connection: Keep-Alive
Content-Length: 478
Content-Type: text/html; charset=iso-8859-1
Date: Fri, 25 Nov 2022 13:35:51 GMT
Keep-Alive: timeout=5, max=100
Server: Apache/2.4.41 (Ubuntu)
WWW-Authenticate: Negotiate
WWW-Authenticate: Basic realm="intranet yyy"

Don't know if it can help...

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

SSO works only for high level Active Directory UO #282

{{title}}

Replies: 1 comment 6 replies

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

Select a reply

SSO works only for high level Active Directory UO #282

marcoriccine Nov 18, 2022

Replies: 1 comment · 6 replies

simo5 Nov 18, 2022 Maintainer

GssapiLocalName

simo5 Nov 21, 2022 Maintainer

marcoriccine Nov 22, 2022 Author

simo5 Nov 22, 2022 Maintainer

marcoriccine Nov 22, 2022 Author

marcoriccine Nov 25, 2022 Author

marcoriccine
Nov 18, 2022

Replies: 1 comment 6 replies

simo5
Nov 18, 2022
Maintainer

simo5 Nov 21, 2022
Maintainer

marcoriccine Nov 22, 2022
Author

simo5 Nov 22, 2022
Maintainer

marcoriccine Nov 22, 2022
Author

marcoriccine Nov 25, 2022
Author