[Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD trust and UPN issues
Sumit Bose
sbose at redhat.com
Thu May 7 16:43:30 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
> May 06 16:48:32 dc1.ipadomain.net sshd[7542]: pam_sss(sshd:auth):
> authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=10.5.5.57 user=adusername
> May 06 16:48:32 dc1.ipadomain.net sshd[7542]: pam_sss(sshd:auth): received
> for user adusername: 4 (System error)
> May 06 16:48:34 dc1.ipadomain.net sshd[7542]: Failed password for
> adusername from 10.5.5.57 port 1870 ssh2
>
> ---- configuration 3 -----
> Notes : Since the eror message given in the second try indicated that the
> realm wasn't local, I thought it might need both variations to recognize
> it as local.
>
> [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
> }
> ADDOMAIN.NET = {
> kdc = dc3.corp.addomain.net:88
> master_kdc = dc3.corp.addomain.net:88
> }
>
> 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
> addomain.net = ADDOMAIN.NET
> .addomain.net = ADDOMAIN.NET
> corp.addomain.net = CORP.ADDOMAIN.NET
> .corp.addomain.net = CORP.ADDOMAIN.NET
>
> May 06 16:56:25 dc1.ipadomain.net [sssd[krb5_child[7664]]][7664]: Realm
> not local to KDC
> May 06 16:56:25 dc1.ipadomain.net [sssd[krb5_child[7664]]][7664]: Realm
> not local to KDC
> May 06 16:56:25 dc1.ipadomain.net sshd[7660]: pam_sss(sshd:auth):
> authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=10.5.5.57 user=adusername
> May 06 16:56:25 dc1.ipadomain.net sshd[7660]: pam_sss(sshd:auth): received
> for user adusername: 4 (System error)
> May 06 16:56:28 dc1.ipadomain.net sshd[7660]: Failed password for
> adusername from 10.5.5.57 port 1964 ssh2
>
>
>
> > If you want to look up user data like e.g. the UID or the home
> > directory the IPA client will talk to the IPA server exclusively, if the
> > server does not know about the requested AD user it will try to get this
> > information from a AD DC.
> >
> > For authentication this is different, because only the AD DC should know
> > the password of the user. Hence authentication ans password changes as
> > well are done directly with the AD DC.
> >
> >>
> >> Also this page here :
> >> https://www.freeipa.org/page/Active_Directory_trust_setup
> >>
> >> does not list having to add the AD domain in the krb5.conf. Is that not
> >> necessary in the example because they are not using a different UPN for
> >> their users like we are?
> >
> > yes, it is because of the UPN in your case. As I said before this
> > special entry in krb5.conf would not be needed anymore if the IPA KDC
> > supports the Kerberos client referrals for the trusted domains. Adding
> > the entry to krb5.conf in only a work-around here.
> >
> > bye,
> > Sumit
>
>
More information about the Freeipa-users
mailing list