Configuring Kerberos krb5.conf file to handle primary and a secondary 'cloned' domain

Question

(Obligatory newbie prefix: never played much with Kerberos so treat me gently here!)

We have two domains foo.local and .test.

.test was cloned from foo.local and, once logged on to a server inside .test the domain thinks it is the foo.local domain.

e.g. myserver.foo.local has an IP address of 10.250.20.10 and myserver.test has an IP address of 10.253.20.10 when inside the foo.local domain, but sees itself as 10.250.20.10 when inside the .test domain.

In addition myserver.foo.local can reach out to myserver.test but the opposite is not true.

Also, myserver.foo.local when reaching out to myothersever.foo.local does indeed hit a server that is inside the foo.local domain, however when myserver.test connects to myotherserver.foo.local then it remains stuck inside the .test domain.

This all said, here's my /etc/krb5.conf file (which I'm more than happy to learn is badly configured):

[libdefaults]
  default_realm = FOO.LOCAL

[realms]
    FOO.LOCAL = {
        kdc = foo-dc01.foo.local
    }

    TEST = {
        kdc = foo-dc02.test
    }

Life is good when connecting to servers inside foo.local and indeed my kinit works a treat. Test not so much.

myLogin$ kinit -V  mylogin@test
mylogin@test's password: 
kinit: krb5_get_init_creds: unable to reach any KDC in realm test, tried 0 KDCs

So, questions:

1) What steps am I missing to authenticate against the test domain - how do I configure kinit to use the foo-dc02.test domain server to authenticate (or even, do I given that my Windows LoginId and password are the same)?

2) Once done, how do I ensure that when connecting to myserver.test it uses the token derived from the kinit mylogin@test when attempting a connection?

System Info: All AD servers are Windows, right now my POC tests are from my MacBook but clients running on Windows, Macs and Linux will all need to work eventually.

Answer 1

e.g. myserver.foo.local has an IP address of 10.250.20.10 and myserver.test has an IP address of 10.253.20.10 when inside the foo.local domain, but sees itself as 10.250.20.10 when inside the .test domain.

Addressing is generally irrelevant to Kerberos, as long as clients are able to resolve the DNS names and speak to the servers (send/receive IP packets).

myLogin$ kinit -V mylogin@test
mylogin@test's password:
kinit: krb5_get_init_creds: unable to reach any KDC in realm test, tried 0 KDCs

You are trying to authenticate to the test realm. To Kerberos, this is not the same as the TEST realm which you have in krb5.conf – unlike DNS domains or AD domains, a Kerberos realm name is case-sensitive.

Because the lowercase test realm is not in [realms] in your krb5.conf, kinit uses other methods to find the KDC server – it looks for DNS SRV _kerberos._udp.<realm> records after translating the realm back to a DNS domain.

For example, when you're authenticating against …@test or …@TEST and there is no matching [realms] subsection, you will need SRV records at _kerberos._udp.test at minimum. (Active Directory should add these automatically.)

Either use kinit mylogin@TEST with the correct case, or adjust the [realms] configuration, or ensure that there are SRV records in your test DNS domain pointing to the domain controller.

(Additionally: If you choose to use the lowercase kinit mylogin@test, Active Directory KDCs will recognize the lowercase form but the returned tickets have the realm in canonical uppercase anyway and most kinit versions will reject the mismatching response. You will allow canonicalization using kinit -C.)

If your client software is MIT Krb5, use export KRB5_TRACE=/dev/stderr to obtain more information about what exactly it is doing. (macOS probably uses Heimdal though.)

2) Once done, how do I ensure that when connecting to myserver.test it uses the token derived from the kinit mylogin@test when attempting a connection?

Check what credential cache type is being used (as shown by klist in "Ticket cache" or set in the $KRB5CCNAME environment variable).

The traditional "FILE:" credential cache can only have tickets for one client principal in the first place. If you kinit as mylogin@TEST, you will always be using tickets for mylogin@TEST. In this case you will have to manually switch between different caches, by setting $KRB5CCNAME to different paths.

$ export KRB5CCNAME="FILE:/tmp/krb5cc_1000_prod" && kinit user@PROD && klist
$ export KRB5CCNAME="FILE:/tmp/krb5cc_1000_test" && kinit user@TEST && klist

$ kset() { export KRB5CCNAME="FILE:/tmp/krb5cc_$(id -u)_$1"; }
$ kset prod && kinit user@PROD && klist

When using MIT Krb5, the "DIR:" and (on Linux) "KEYRING:" credential caches support multiple client principals at once. You can simply kinit multiple times, then switch the 'active' principal using kswitch or even define custom rules in the ~/.k5identity file (man 5 k5identity).

Unfortunately, some important programs (such as smbclient or Apache Directory Studio) do not understand "DIR:" caches yet (or anything except FILE: actually).

When using macOS, the same as above applies, but I believe the default credential cache type is "KCM:" which can probably hold multiple client principals. Or maybe not ¯\_(ツ)_/¯

Windows works differently; the ticket cache is tightly bound to your login session and (again) only supports one client principal. To start programs as another principal without a full logout/login, use runas /netonly:

runas /netonly /user:mylogin@test cmd