GSSAPI and multiple domains in the same forest

[nestle2377]

I've an apache 2.4 on redhat with gssapi mod.

the active directory has multiple domain in the same forest and I've problem to authenticate, I would like to know if is possible to use the gssapi in this scenario.

I've 3 domain in the same forest, the keytab file is made on the PRIMO domain like is possible to see with kutil:

ktutil:  read_kt server.keytab
ktutil:  list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
3 HTTP/[email protected]

this is my krb5.conf (I haven't configure it by my self, I've it from the AD group):

 [libdefaults]
default_realm = PRIMO.GROUP
dns_lookup_kdc = true
dns_lookup_realm = false
ticket_lifetime = 86400
renew_lifetime = 604800
forwardable = true
default_tgs_enctypes = aes256-cts rc4-hmac
default_tkt_enctypes = aes256-cts rc4-hmac
permitted_enctypes = aes256-cts rc4-hmac
udp_preference_limit = 1
kdc_timeout = 3000
 
[realms]
PRIMO.GROUP = {
kdc = sisvrdc01.PRIMO.group
admin_server = sisvrdc01.primo.group
kdc = sisvrdc02.primo.group
kdc = sisnodc01.primo.group
kdc = sisnodc02.primo.group
}
 
[domain_realm]
[capaths]
SECONDO.GROUP = {
PRIMO.GROUP = KRONOS.GROUP
}

this is my config inside apache:

AuthType GSSAPI
   AuthName "GSSAPI Single Sign On Login"
   AuthzSendForbiddenOnFailure On
   GssapiBasicAuth On
   GssapiBasicAuthMech krb5
   #GssapiAllowedMech krb5
   GssapiUseSessions On
   GssapiNegotiateOnce On
   GssapiLocalName On
   GssapiSessionKey key:<RANDOM>
   Session On
   SessionCookieName gssapi_session path=/dominio;domain=red.it;httponly;secure;   
   GssapiCredStore keytab:/var/www/html/rf002/conf/server.keytab

   Require valid-user

when the user enter in the domain with windows it uses SECONDO.GROUP domain.
so, the keytab is made on PRIMO.GROUP but the user is on SECONDO.GROUP, the two domain are inside the same forest.

the autentication doesn't works and even with the basic I've this error:
[Fri Feb 26 11:50:22.892191 2021] [auth_gssapi:error] [pid 84426:tid 140162875389696] [client 10.211.30.219:63189] GSS ERROR In Basic Auth: gss_acquire_cred_with_password() failed: [Unspecified GSS failure. Minor code may provide more information (Client '[email protected]' not found in Kerberos database)]

is there a way to use the gssapi with multiple domains in the same forest with the keytab generated on a domain that is not the domain where the user is present?

thanks

[simo5]

I see no way for GSSAPI to find the KDCs for the "SECONDO.GROUP" domain, I also do not see that the user is from that domain given you have Client '[email protected]'

So here you are performing Basic Auth instead of a Negotiate.
In order to authenticate a user against users of a non-default domain you will have to enter the fully qualified user name, eg [email protected] at the password prompt, at the very least. If just ES06326 is entered, then the code assumes the realm of the default domain.

If all your users are in the SECONDO.GROUP domain, you may want to change the default_realm in krb5.conf accordingly.

[nestle2377]

Thanks for reply!
I'm performing basic auth since the sso between browser and apache doesn't work.
in basic auth now I've try like you suggest @secondo.group and the error change in:

(Request ticket server HTTP/[email protected] kvno 3 found in keytab but not with enctype rc4-hmac),

the encryption type of my keytab is

slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    3 HTTP/[email protected] (aes256-cts-hmac-sha1-96)

i've to change something in my httpd.conf file to use the correct enctype?

to work without basic auth, do you suggest to change de default ream in krb5.conf? and if my user will be in more than one domain?

thanks for support!

[simo5]

Thanks for reply!
I'm performing basic auth since the sso between browser and apache doesn't work.

You should probably investigate why that is, I assume the error below is the cause as well.

in basic auth now I've try like you suggest @secondo.group and the error change in:

(Request ticket server HTTP/[email protected] kvno 3 found in keytab but not with enctype rc4-hmac),

the encryption type of my keytab is

slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    3 HTTP/[email protected] (aes256-cts-hmac-sha1-96)

What's happening here is bad configuration.

Your admin created a service account in AD, it did not set what enctypes are allowed so the defaults apply (rc4 and aes), however they then proceeded to give you a key with only AES256-CTS enctype in them.

A client in the realm for some reason is using only the old RC4-HMAC enctype (it can be also the Basic Auth itself with validation, where the user account has only RC4 keys enabled), and then requesting a ticket from the KDC to contact your server. The server see the client supports only RC4 and provides them with that key because they know the server account supports RC4.
But because the keytab was trimmed to remove the RC4 keys, now the server does not have the necessary key.

The misconfiguration here is that there is a mismatch between what keys the KDC believes the service has, and what keys were actually given to the service.

i've to change something in my httpd.conf file to use the correct enctype?

No you have to either change the service configuration in AD, or you have to issue correct key types in the keytab. No amount of configuration for httpd will fix this issue, as service ticket issueance happens before httpd is contacted by the client.

to work without basic auth, do you suggest to change de default ream in krb5.conf?

If you do not want to use basic auth you do not need to change anything wrt default_realm as the tickets sent by the user already contain the full credentials needed.

and if my user will be in more than one domain?

If using basic auth this means users need to identify themselves with the full principal name, not just with the username, for all non-default realms they belong too.
In general I advise against using basic auth and instead fixing SSO negotiation as it makes it much easier to use for users, avoids passwords being sotred in the browser and resent at each connection.

thanks for support!

[nestle2377]

thanks for your quick reply!

my goal is to authenticate user on apache without basic (or use basic only if the client is not on domain).

if I have well understand your explanation the problem could be related to the keytab that is not containing the RC4 key and so, since the client is using this key, is impossible to comunicate to server to authenticate.

I could try to ask to generate a new keytab with all encryption type and in this way the authentication should work with and without basic.

is correct?

thanks again ;)

[nestle2377]

Just to inform that I've solved. the problem was on DNS side, the DNS record of the webserver was registered like cname (alias) and not like record HOST. Registering like HOST solved the problem.
thanks