[Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD trust and UPN issues

Thu May 7 19:03:23 UTC 2015

> On Wed, May 06, 2015 at 11:15:15AM -0700, nathan at nathanpeters.com wrote:
>> Ok, I have attempted to set this up by adding the AD domain to my
>> configuration and it still isn't working.
>> I just want to confirm what I'm trying to accomplish here before I list
>> what I've done to troubleshoot this.
>>
>> We have an AD domain called corp.addomain.net.  We have UPNs set so AD
>> users login to the AD domain as adusername at addomain.net when they login
>> to
>> windows machines.
>>
>> The linux clients in our network are currently just using straight up
>> kerberos authentication against the domain and can currently login as
>> 'username' without entering any suffix.
>>
>> Because this means we can't control sudo policies centrally by our
>> current
>> direct kerberos connection, we want to switch to logging in through
>> FreeIPA.
>> I need to be clear that we want to maintain the current logins of just
>> 'username' on Linux servers.
>>
>> To accomplish this, I added the following line to the sssd.conf file:
>> default_domain_suffix = corp.addomain.net
>>
>> I have tried 3 different combinations of kerberos config to try to get
>> the
>> logins to work, but am running into errors in each case.  I have tried
>> to
>> follow the suggestions given earlier in this thread.  Here are the 3
>> krb.conf configurations I tried and the errors given on each try.
>>
>> -------------- configuration 1 -------------------
>>
>> [realms]
>>  IPADOMAIN.NET = {
>>   kdc = dc1.ipadomain.net:88
>>   master_kdc = dc1.ipadomain.net:88
>>   admin_server = dc1.ipadomain.net:749
>>   default_domain = ipadomain.net
>>   pkinit_anchors = FILE:/etc/ipa/ca.crt
>>   auth_to_local =
>> RULE:[1:$1@$0](^.*@CORP.ADDOMAIN.NET$)s/@CORP.ADDOMAIN.NET/@corp.addomain.net/
>>   auth_to_local = DEFAULT
>> }
>> CORP.ADDOMAIN.NET = {
>>   kdc = dc3.corp.addomain.net:88
>>   master_kdc = dc3.corp.addomain.net:88
>> }
>>
>> [domain_realm]
>>  .ipadomain.net = IPADOMAIN.NET
>>  ipadomain.net = IPADOMAIN.NET
>>  .corp.addomain.net = CORP.ADDOMAIN.NET
>>  corp.addomain.net = CORP.ADDOMAIN.NET
>>
>>
>> May 06 16:43:53 dc1.ipadomain.net [sssd[krb5_child[7512]]][7512]: Cannot
>> find KDC for realm "ADDOMAIN.NET"
>> May 06 16:43:53 dc1.ipadomain.net [sssd[krb5_child[7512]]][7512]: Cannot
>> find KDC for realm "ADDOMAIN.NET"
>> May 06 16:43:53 dc1.ipadomain.net sshd[7508]: pam_sss(sshd:auth):
>> authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
>> rhost=10.5.5.57 user=adusername
>> May 06 16:43:53 dc1.ipadomain.net sshd[7508]: pam_sss(sshd:auth):
>> received
>> for user adusername: 4 (System error)
>> May 06 16:43:55 dc1.ipadomain.net sshd[7508]: Failed password for
>> adusername from 10.5.5.57 port 1832 ssh2
>>
>> ----------- configuration 2 ----------------
>>
>> Notes : since the above error seemed to imply that I needed to add the
>> 'UPN realm' to the [realms] section I tried to add it.
>>
>> [realms]
>>  IPADOMAIN.NET = {
>>   kdc = dc1.ipadomain.net:88
>>   master_kdc = dc1.ipadomain.net:88
>>   admin_server = dc1.ipadomain.net:749
>>   default_domain = ipadomain.net
>>   pkinit_anchors = FILE:/etc/ipa/ca.crt
>>   auth_to_local =
>> RULE:[1:$1@$0](^.*@CORP.ADDOMAIN.NET$)s/@CORP.ADDOMAIN.NET/@corp.addomain.net/
>>   auth_to_local = DEFAULT
>>
>> }
>>  ADDOMAIN.NET = {
>>   kdc = dc3.corp.addomain.net:88
>>   master_kdc = dc3.corp.addomain.net:88
>> }
>>
>> [domain_realm]
>>  .ipadomain.net = IPADOMAIN.NET
>>  ipadomain.net = IPADOMAIN.NET
>>  addomain.net = ADDOMAIN.NET
>>  .addomain.net = ADDOMAIN.NET
>>
>> May 06 16:48:32 dc1.ipadomain.net [sssd[krb5_child[7546]]][7546]: Realm
>> not local to KDC
>> May 06 16:48:32 dc1.ipadomain.net [sssd[krb5_child[7546]]][7546]: Realm
>> not local to KDC
>
> hm, the AD DC requires that enterprise principal are used here, but we
> cannot enable them because as mentioned earlier the FreeIPA KDC
> currently does not support client referrals.
>
> Basically you are seeing the same as described in
> https://bugzilla.redhat.com/show_bug.cgi?id=1211631 . The
> userPrincipalName attribute in AD contains a value we currently cannot
> use. Unfortunately SSSD prefers this value if available and as described
> in the bugzilla tickets it is currently not possible to override the
> attribute name as well.
>
> There might be one ugly hack which might help you, but it is really ugly
> because you have to edit a executable file. The name of the attribute
> 'userPrincipalName' can be found exactly once in the IPA provider
> executable, you can check this with
>
>  strings /usr/{lib|lib64}/sssd/libsss_ipa.so | grep userPrincipalName
>
> if you replace a single letter in this string with a different one, e.g.
> 'userPrinXipalName' in this file on all of your IPA servers and flush
> the cache on all servers with 'sss_cache -E' and restart sssd on the
> servers then SSSD should not be able anymore to read the attribute from
> AD and will generate a principal on its own based on the user name and
> the domain name which is corp.addomain.net in your case. With the
> principal it should be possible to authenticate against AD. But as said,
> this is really ugly, not supported and has to be done again at the next
> update.
>
> I'm sorry but currently I cannot think of a different way to make it
> work with the current versions of SSSD and IPA.
>
> bye,
> Sumit

Hey I tried to lookup that bug but after I logged in I got :

"You are not authorized to access bug #1211631.
Most likely the bug has been restricted for internal development processes
and we cannot grant access."

I think I found a workaround that is an even uglier hack but appears to
work.  Perhaps you could tell me why this is working?

Basically, you make an entry for the UPN 'domain' in krb5.conf and give it
servers that don't exist.  I'm not sure why this is happening but here are
the logs and proof of successful login by intentionally breaking kerberos.

I have posted 2 attempts.  The first uses a valid syntax but fails.  The
second attempt uses non-existent servers but actually works.  Note that if
I do not include either a real or fake upn section, it fails.  Once again,
I could probably use this hack, but I need to know why it works so I can
be confident it won't break in the future.  We will be doing this on
several hundred machines.

Failed attempt using a valid ADUPNALIAS.NET section
-------------------------------------
/etc/krb5.conf extra realm section

ADUPNALIAS.NET = {
  kdc = dc3.corp.addomain.net:88
  master_kdc = c3.corp.addomain.net:88
  default_domain = adupnalias.net
}

May 07 18:40:09 ipadc1.ipadomain.net sshd[2437]: pam_unix(sshd:auth):
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.5.5.57  user=adusername
May 07 18:40:10 ipadc1.ipadomain.net [sssd[krb5_child[2440]]][2440]: Realm
not local to KDC
May 07 18:40:10 ipadc1.ipadomain.net [sssd[krb5_child[2440]]][2440]: Realm
not local to KDC
May 07 18:40:10 ipadc1.ipadomain.net sshd[2437]: pam_sss(sshd:auth):
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.5.5.57 user=adusername
May 07 18:40:10 ipadc1.ipadomain.net sshd[2437]: pam_sss(sshd:auth):
received for user adusername: 4 (System error)
May 07 18:40:11 ipadc1.ipadomain.net sshd[2437]: Failed password for
adusername from 10.5.5.57 port 18472 ssh2

Successful login using invalid ADUPNALIAS.NET section
-------------------------------------
/etc/krb5.conf extra realm section

ADUPNALIAS.NET = {
  kdc = someserverthatdoesnotexist.unreachabledomain.net:88
  master_kdc = someserverthatdoesnotexist.unreachabledomain.net:88
  default_domain = adupnalias.net
}

May 07 18:31:16 ipadc1.ipadomain.net sshd[2317]: pam_unix(sshd:auth):
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.5.5.57  user=adusername
May 07 18:31:17 ipadc1.ipadomain.net [sssd[krb5_child[2319]]][2319]:
Cannot contact any KDC for realm 'ADUPNALIAS.NET'
May 07 18:31:17 ipadc1.ipadomain.net [sssd[krb5_child[2319]]][2319]:
Cannot contact any KDC for realm 'ADUPNALIAS.NET'
May 07 18:31:17 ipadc1.ipadomain.net sshd[2317]: pam_sss(sshd:auth):
authentication success; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.5.5.57 user=adusername
May 07 18:31:19 ipadc1.ipadomain.net sshd[2317]: Accepted password for
adusername from 10.5.5.57 port 18346 ssh2
May 07 18:31:19 ipadc1.ipadomain.net systemd[1]: Starting
user-1539201103.slice.
May 07 18:31:19 ipadc1.ipadomain.net systemd[1]: Created slice
user-1539201103.slice.
May 07 18:31:19 ipadc1.ipadomain.net systemd[1]: Starting Session 4 of
user adusername at corp.adupnalias.net.
May 07 18:31:19 ipadc1.ipadomain.net systemd[1]: Started Session 4 of user
adusername at corp.adupnalias.net.
May 07 18:31:19 ipadc1.ipadomain.net systemd-logind[718]: New session 4 of
user adusername at corp.adupnalias.net.
May 07 18:31:19 ipadc1.ipadomain.net sshd[2317]: pam_unix(sshd:session):
session opened for user adusername by (uid=0)