Kerberos config when AD domain and REALM are different

[Rich_Faust]

Kerberos is supposed to be a 3-headed dog, but I think it’s a bear…

I’m working with a customer who has a production AD this is also the user directory in their non-production dev and test environments.  My immediate challenge is to demonstrate Kerberos in the DEV environment.  I was hoping the Communities could lend some insight given this is a non-standard configuration that is not addressed in the Kerberos documentation and the internet searches I have conducted.

• Policy Server:  SiteMinder r12.52 sp01 cr05 on Linux 64-bit, hostname=smps01.dev.company.com
• Login Server:  IIS 7.5 on Windows 2008 R2, hostname=login.ad.company.com
• User Directory:  AD on Windows 2008 R2, hostname=msad.corp.company.com

I want to establish a configuration in the DEV environment that is distinct from what will eventually be TEST and PROD Kerberos realms using the same AD infrastructure, i.e., someone who has authenticated to a DEV application does not gain access to TEST or PROD apps.

 

I have the following SPN’s:

• Web agent:        HTTP/[e-mail]
• Policy server:     smps/[e-mail]

 

I have tried various combinations of settings in krb5.conf, each yielding different errors which I have tried to research.  This configuration of  krb5.conf and the resulting error when I try kinit seems the most promising, so I’ll start here:

 

[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

    dns_lookup_kdc = false

    ticket_lifetime = 24h

    renew_lifetime = 7d

    forwardable = true

    rdns = false

    default_realm = DEV.COMPANY.COM

    default_ccache_name = KEYRING:persistent:%{uid}

    default_keytab_name = /home/smuser/krb5/krbsvc-dev-smps.keytab

    default_tkt_enctypes = aes256-cts-hmac-sha1-96

    default_tgs_enctypes = aes256-cts-hmac-sha1-96

 

[realms]

    DEV.COMPANY.COM = {

        kdc            = msad.ad.company.com

        admin_server   = msad.ad.company.com

        default_domain = dev.company.com

    }

 

[domain_realm]

    .ad.company.com        = DEV.COMPANY.COM

    ad.company.com         = DEV.COMPANY.COM

    .dev.company.com       = DEV.COMPANY.COM

    dev.company.com        = DEV.COMPANY.COM

               

 The 'kinit' command fails as shown below:

[smuser@smps01 krb5]$ kinit krbsvc-dev-smps -V

Using default cache: /home/smadmin/krb5/cache/krb5cc

Using principal: [e-mail]

kinit: Realm not local to KDC while getting initial credentials

[smuser@smps01 krb5]$

 

Comments?

[Stephen McQuiggan]

Do they have domain for environment?

 

The Kerberos <REALM> is the DNS domain in upper case. For example, DEV.COMPANY.COM

This this resolvable DNS

[Rich_Faust]

AD.COMPANY.COM and DEV.COMPANY.COM are both valid domain names.  I don't understand the intent of "This this resolvable DNS"

[Stephen McQuiggan]

In the authentication scheme you can map multiple windows domain to Kerberos realms, however the error you received is not SSO but Kerberos specific

kinit: Realm not local to KDC while getting initial credentials

Good resource for multiple kerberos realms

https://web.mit.edu/kerberos/krb5-1.12/doc/admin/realm_config.html

 

Kerberos dependencies

• Names

• Domain Name System (DNS)
  • “Forward” address (A) records: Name to IP address
  • “Reverse” pointer (PTR) records: IP address to name
  • Service (SRV) records: server name and port of a named service

[Rich_Faust]

I saw that post when doing my initial research and didn't think it helped me any:  in their example, all domains and realms end with a variation of [something.]something.example.com.  The approach from my initial post was to use keytab issued to a principal at DEV.COMPANY.COM to obtain a ticket from AD.COMPANY.COM.  I am shifting my approach and trying a principal  smps/[e-mail].  I'll report results as I have them.

[Rich_Faust]

I was able to get a ticket after changing the principal name to HTTP/[e-mail].  Hubert Dennis also found two other issues:  a) the encryption type of the tickets created by the KDC was not correct, and b) DNS was returning the CNAME of the VIP rather than the A name.  Basic Kerberos authentication is working now that those issues are resolved.