0

We have 2 forests/domains : ad.local (not managed by us) and ad2.local (managed by us)

We setup a two way trust between them.

Now let's say I have an app on a server joined to ad2.local : app.ad2.local

This app accepts LDAP or Kerberos (with apache)

From what I have read, it is not possible to query for trusted users over LDAP (correct me if I'm wrong) so we went with kerberos.

So far I have managed to login with users from ad2.local but not from ad.local.

When I try to login with users from ad.local I get these errors : 

[Thu Mar 19 11:07:48.155074 2020] [authz_core:debug] [pid 20267] mod_authz_core.c(809): [client IP:33274] AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[Thu Mar 19 11:07:48.155213 2020] [authz_core:debug] [pid 20267] mod_authz_core.c(809): [client IP:33274] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[Thu Mar 19 11:07:48.155248 2020] [auth_kerb:debug] [pid 20267] src/mod_auth_kerb.c(1954): [client IP:33274] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Thu Mar 19 11:07:55.188879 2020] [authz_core:debug] [pid 3421] mod_authz_core.c(809): [client IP:33346] AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[Thu Mar 19 11:07:55.188985 2020] [authz_core:debug] [pid 3421] mod_authz_core.c(809): [client IP:33346] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[Thu Mar 19 11:07:55.189019 2020] [auth_kerb:debug] [pid 3421] src/mod_auth_kerb.c(1954): [client IP:33346] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Thu Mar 19 11:07:56.083017 2020] [authz_core:debug] [pid 3421] mod_authz_core.c(809): [client IP:33346] AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[Thu Mar 19 11:07:56.083102 2020] [authz_core:debug] [pid 3421] mod_authz_core.c(809): [client IP:33346] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[Thu Mar 19 11:07:56.083137 2020] [auth_kerb:debug] [pid 3421] src/mod_auth_kerb.c(1954): [client IP:33346] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Thu Mar 19 11:07:56.083286 2020] [auth_kerb:debug] [pid 3421] src/mod_auth_kerb.c(1295): [client IP:33346] Acquiring creds for HTTP@APP_FQDN
[Thu Mar 19 11:07:56.087966 2020] [auth_kerb:debug] [pid 3421] src/mod_auth_kerb.c(1708): [client IP:33346] Verifying client data using KRB5 GSS-API
[Thu Mar 19 11:07:56.088023 2020] [auth_kerb:debug] [pid 3421] src/mod_auth_kerb.c(1724): [client IP:33346] Client didn't delegate us their credential
[Thu Mar 19 11:07:56.088038 2020] [auth_kerb:debug] [pid 3421] src/mod_auth_kerb.c(1752): [client IP:33346] Warning: received token seems to be NTLM, which isn't supported by the Kerberos module. Check your IE configuration.
[Thu Mar 19 11:07:56.088053 2020] [auth_kerb:debug] [pid 3421] src/mod_auth_kerb.c(1155): [client IP:33346] GSS-API major_status:00010000, minor_status:00000000
[Thu Mar 19 11:07:56.088182 2020] [auth_kerb:error] [pid 3421] [client IP:33346] gss_accept_sec_context() failed: An unsupported mechanism was requested (, Unknown error)

Here is my apache config : 

<Location /application>
  AuthType Kerberos
  AuthName "Kerberos Login"
  KrbMethodNegotiate On
  KrbMethodK5Passwd  On
  KrbSaveCredentials Off
  KrbAuthRealms AD.LOCAL AD2.LOCAL
  Krb5KeyTab /etc/kerberos.keytab
  KrbLocalUserMapping On
  require valid-user
</Location>

And etc/krb5.conf :

# Configuration snippets may be placed in this directory as well
includedir /etc/krb5.conf.d/

includedir /var/lib/sss/pubconf/krb5.include.d/
[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 dns_lookup_realm = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 rdns = false
 pkinit_anchors = /etc/pki/tls/certs/ca-bundle.crt
# default_realm = EXAMPLE.COM
 default_ccache_name = KEYRING:persistent:%{uid}

 default_realm = AD2.LOCAL
[realms]
# EXAMPLE.COM = {
#  kdc = kerberos.example.com
#  admin_server = kerberos.example.com
# }

 AD2.LOCAL = {
  kdc = dc.AD2.LOCAL
#  auth_to_local = RULE:[1:$1@$0](^.*@AD.LOCAL$)s/@AD.LOCAL/@ad.local/
#  auth_to_local = DEFAULT
 }

 AD.LOCAL = {
  kdc = master.ad.local
}

[domain_realm]
# .example.com = EXAMPLE.COM
# example.com = EXAMPLE.COM
 ad2.local = AD2.LOCAL
 .ad2.local = AD2.LOCAL
 ad.local  = AD.LOCAL
 .ad.local = AD.LOCAL

Does anyone know what might be the problem ?

Dave M
  • 4,494
  • 21
  • 30
  • 30
preguenga
  • 1
  • `received token seems to be NTLM` well, is it? – Greg Askew Mar 19 '20 at 12:29
  • @GregAskew I am indeed not using a laptop joined to neither of domains for testing... is that a problem ? – preguenga Mar 19 '20 at 12:43
  • It is a problem if you are configured to use Kerberos authentication but are sending an NTLM auth. – Greg Askew Mar 19 '20 at 12:59
  • It is indeed configured for kerberos auth, but it works with 1 domain and not the other when neither of domains are configured on my laptop. (its a testing lab). Why is that ? – preguenga Mar 19 '20 at 13:02
  • There are a lot of reasons a client would send an NTLM auth instead of Kerberos. Kerberos delegation across forests/external trusts is complicated enough, and it is further complicated here with this configuration. You really should consider using forms based authentication. Even if you managed to get this working, it would probably be a support nightmare. – Greg Askew Mar 19 '20 at 13:12
  • Hmm.... Indeed our configuration needs is complicated, with that saying if want to use "forms based auth" how can i do it with trusted domains ? Anyhow thanks for your help Greg ! – preguenga Mar 19 '20 at 13:30

1 Answers1

0

The issue is one of two things. Either the lab client couldn't resolve a DC in ad.local with the creds you typed in, so it fell back to NTLM. It was able to resolve a DC in ad2.local so it was able to do Kerberos. Or the request to ad.local didn't have enough information for it to know to refer you to the other domain.

On an unjoined Windows client, Windows will attempt to resolve domains by looking at the credential you typed in, and use the realm portion as a hint. If you type in user@ad.local it will try and locate a DC in using the DNS SRV _kerberos._tcp.ad.local. If you type in ad\user, the client (probably) doesn't have enough information to build a successful DNS query so it falls back to NTLM.

Assuming that succeeded and you were able to resolve ad.local correctly, that DC now needs to know what app it should issue a ticket to. Windows will use the requested host name and send that to ad.local. If the host name that's typed in is app, the DC won't find any records and return a service not found error (which causes the client to fall back to NTLM). If the typed in name is app.ad2.local then the DC should recognize the .ad2.local suffix (because it's configured on the trust) and kick off a referral to ad2.local which will then issue you a ticket to app.ad2.local.

Using the fully qualified names should help. If that doesn't work enabling forest search order on the ad.local domain can also help.

Otherwise I recommend doing a network trace (Wireshark) on the client machine and watch the traffic as it tries to communicate with the DCs.

Steve
  • 392
  • 2
  • 7