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

[n***@nathanpeters.com]

I am having some strange issues after upgrade from FreeIPA 4.1.2 to
4.1.3/4.1.4 on CentOS 7.

Here is my setup:
FreeIPA domain : ipadomain.net
Trusted AD domain : sub.addomain.net

In my AD domain, we have our UPN set to addomain.net so users typically
login as ***@addomain.net instead of ***@sub.addomain.net.

In my /etc/sssd/sssd.conf on the ipa dc I have the following values set:
use_fully_qualified_names = True
[sssd]
default_domain_suffix = sub.addomain.net


This is what I see in the logs when I attempt to login as 'username' (with
do domain):

May 05 15:36:51 ipadc1.ipadomain.net [sssd[krb5_child[4376]]][4376]:
Cannot find KDC for realm "ADDOMAIN.NET"
May 05 15:36:51 ipadc1.ipadomain.net [sssd[krb5_child[4376]]][4376]:
Cannot find KDC for realm "ADDOMAIN.NET"
May 05 15:36:51 ipadc1.ipadomain.net sshd[4373]: pam_sss(sshd:auth):
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.5.5.57 user=username
May 05 15:36:51 ipadc1.ipadomain.net sshd[4373]: pam_sss(sshd:auth):
received for user username: 4 (System error)
May 05 15:36:53 ipadc1.ipadomain.net sshd[4373]: Failed password for
username from 10.5.5.57 port 53118 ssh2

However, if in AD I switch the UPN on 'username' to the default of
'sub.addomain.net' I get a successful login:

May 04 23:10:57 ipadc1.ipadomain.net sshd[2293]: pam_unix(sshd:auth):
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.5.5.57 user=username
May 04 23:10:58 ipadc1.ipadomain.net sshd[2293]: pam_sss(sshd:auth):
authentication success; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.5.5.57 user=username
May 04 23:11:01 ipadc1.ipadomain.net sshd[2293]: Accepted password for
username from 10.5.5.57 port 46077 ssh2
May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Starting
user-1539201103.slice.
May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Created slice
user-1539201103.slice.
May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Starting Session 3 of
user ***@sub.addomain.net.
May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Started Session 3 of user
***@sub.addomain.net.
May 04 23:11:01 ipadc1.ipadomain.net systemd-logind[716]: New session 3 of
user ***@sub.addomain.net.
May 04 23:11:02 ipadc1.ipadomain.net sshd[2293]: pam_unix(sshd:session):
session opened for user username by (uid=0)

As a temporary workaround I set dns_lookup_kdc = false in my
/etc/krb5.conf file and that worked to allow me to login with just
'username' but even after a successful login, I was seeing those 'cannot
find KDC for realm' message in the log.

Is there a proper way to allow people from a trusted AD domain to login
with their alternative UPNs?

[Sumit Bose]

Post by n***@nathanpeters.com
I am having some strange issues after upgrade from FreeIPA 4.1.2 to
4.1.3/4.1.4 on CentOS 7.
FreeIPA domain : ipadomain.net
Trusted AD domain : sub.addomain.net
In my AD domain, we have our UPN set to addomain.net so users typically
use_fully_qualified_names = True
[sssd]
default_domain_suffix = sub.addomain.net
This is what I see in the logs when I attempt to login as 'username' (with
Cannot find KDC for realm "ADDOMAIN.NET"
Cannot find KDC for realm "ADDOMAIN.NET"
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.5.5.57 user=username
received for user username: 4 (System error)
May 05 15:36:53 ipadc1.ipadomain.net sshd[4373]: Failed password for
username from 10.5.5.57 port 53118 ssh2
However, if in AD I switch the UPN on 'username' to the default of
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.5.5.57 user=username
authentication success; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.5.5.57 user=username
May 04 23:11:01 ipadc1.ipadomain.net sshd[2293]: Accepted password for
username from 10.5.5.57 port 46077 ssh2
May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Starting
user-1539201103.slice.
May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Created slice
user-1539201103.slice.
May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Starting Session 3 of
May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Started Session 3 of user
May 04 23:11:01 ipadc1.ipadomain.net systemd-logind[716]: New session 3 of
session opened for user username by (uid=0)
As a temporary workaround I set dns_lookup_kdc = false in my
/etc/krb5.conf file and that worked to allow me to login with just
'username' but even after a successful login, I was seeing those 'cannot
find KDC for realm' message in the log.
Is there a proper way to allow people from a trusted AD domain to login
with their alternative UPNs?

I'm afraid currently the only way doing this is by adding a ADDOMAIN.NET
section to the realms section of /etc/krb5.conf to all IPA clients and
servers.

Although SSSD as a client in a AD domain can handle those UPNs there is
a missing part on the FreeIPA server side which is needed to make it
work. The item is tracked in
https://fedorahosted.org/freeipa/ticket/3559 .

Since the UPN-suffix can be freely chosen, i.e. it does not have to be a
DNS domain, the client will ask it's local KDC with a special so called
enterprise principal if it knows about this UPN suffix and if the KDC
knows about it it will tell the client where to ask for it. IF ticket
#3559 gets implemented the entry in /etc/krb5.conf would not be needed
anymore.

HTH

bye,
Sumit

Post by n***@nathanpeters.com
--
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[n***@nathanpeters.com]

Hmm, so if this is the [realms] section of my /etc/krb5.conf what do I
have to do ?

[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](^.*@SUB.ADDOMAIN.NET$)s/@SUB.ADDOMAIN.NET/@sub.addomain.net/
auth_to_local = DEFAULT
}

Would I just literally copy that section and change the names?
eg:

SUB.ADDOMAIN.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](^.*@SUB.ADDOMAIN.NET$)s/@SUB.ADDOMAIN.NET/@sub.addomain.net/
auth_to_local = DEFAULT
}

Post by Sumit Bose

Post by n***@nathanpeters.com
I am having some strange issues after upgrade from FreeIPA 4.1.2 to
4.1.3/4.1.4 on CentOS 7.
FreeIPA domain : ipadomain.net
Trusted AD domain : sub.addomain.net
In my AD domain, we have our UPN set to addomain.net so users typically
use_fully_qualified_names = True
[sssd]
default_domain_suffix = sub.addomain.net
This is what I see in the logs when I attempt to login as 'username' (with
Cannot find KDC for realm "ADDOMAIN.NET"
Cannot find KDC for realm "ADDOMAIN.NET"
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.5.5.57 user=username
received for user username: 4 (System error)
May 05 15:36:53 ipadc1.ipadomain.net sshd[4373]: Failed password for
username from 10.5.5.57 port 53118 ssh2
However, if in AD I switch the UPN on 'username' to the default of
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.5.5.57 user=username
authentication success; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.5.5.57 user=username
May 04 23:11:01 ipadc1.ipadomain.net sshd[2293]: Accepted password for
username from 10.5.5.57 port 46077 ssh2
May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Starting
user-1539201103.slice.
May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Created slice
user-1539201103.slice.
May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Starting Session 3 of
May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Started Session 3 of user
May 04 23:11:01 ipadc1.ipadomain.net systemd-logind[716]: New session 3 of
session opened for user username by (uid=0)
As a temporary workaround I set dns_lookup_kdc = false in my
/etc/krb5.conf file and that worked to allow me to login with just
'username' but even after a successful login, I was seeing those 'cannot
find KDC for realm' message in the log.
Is there a proper way to allow people from a trusted AD domain to login
with their alternative UPNs?

I'm afraid currently the only way doing this is by adding a ADDOMAIN.NET
section to the realms section of /etc/krb5.conf to all IPA clients and
servers.
Although SSSD as a client in a AD domain can handle those UPNs there is
a missing part on the FreeIPA server side which is needed to make it
work. The item is tracked in
https://fedorahosted.org/freeipa/ticket/3559 .
Since the UPN-suffix can be freely chosen, i.e. it does not have to be a
DNS domain, the client will ask it's local KDC with a special so called
enterprise principal if it knows about this UPN suffix and if the KDC
knows about it it will tell the client where to ask for it. IF ticket
#3559 gets implemented the entry in /etc/krb5.conf would not be needed
anymore.
HTH
bye,
Sumit

Post by n***@nathanpeters.com
--
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

--
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Sumit Bose]

Post by n***@nathanpeters.com
Hmm, so if this is the [realms] section of my /etc/krb5.conf what do I
have to do ?
[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 =
auth_to_local = DEFAULT
}
Would I just literally copy that section and change the names?
SUB.ADDOMAIN.NET = {
kdc = dc1.ipadomain.net:88
master_kdc = dc1.ipadomain.net:88
admin_server = dc1.ipadomain.net:749
default_domain = ipadomain.net

you should add the AD DC and AD realm here

The following lines you can just drop.

HTH

bye,
Sumit

Post by n***@nathanpeters.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
auth_to_local =
auth_to_local = DEFAULT
}

Post by Sumit Bose

Post by n***@nathanpeters.com
I am having some strange issues after upgrade from FreeIPA 4.1.2 to
4.1.3/4.1.4 on CentOS 7.
FreeIPA domain : ipadomain.net
Trusted AD domain : sub.addomain.net
In my AD domain, we have our UPN set to addomain.net so users typically
use_fully_qualified_names = True
[sssd]
default_domain_suffix = sub.addomain.net
This is what I see in the logs when I attempt to login as 'username' (with
Cannot find KDC for realm "ADDOMAIN.NET"
Cannot find KDC for realm "ADDOMAIN.NET"
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.5.5.57 user=username
received for user username: 4 (System error)
May 05 15:36:53 ipadc1.ipadomain.net sshd[4373]: Failed password for
username from 10.5.5.57 port 53118 ssh2
However, if in AD I switch the UPN on 'username' to the default of
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.5.5.57 user=username
authentication success; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.5.5.57 user=username
May 04 23:11:01 ipadc1.ipadomain.net sshd[2293]: Accepted password for
username from 10.5.5.57 port 46077 ssh2
May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Starting
user-1539201103.slice.
May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Created slice
user-1539201103.slice.
May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Starting Session 3 of
May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Started Session 3 of user
May 04 23:11:01 ipadc1.ipadomain.net systemd-logind[716]: New session 3 of
session opened for user username by (uid=0)
As a temporary workaround I set dns_lookup_kdc = false in my
/etc/krb5.conf file and that worked to allow me to login with just
'username' but even after a successful login, I was seeing those 'cannot
find KDC for realm' message in the log.
Is there a proper way to allow people from a trusted AD domain to login
with their alternative UPNs?

I'm afraid currently the only way doing this is by adding a ADDOMAIN.NET
section to the realms section of /etc/krb5.conf to all IPA clients and
servers.
Although SSSD as a client in a AD domain can handle those UPNs there is
a missing part on the FreeIPA server side which is needed to make it
work. The item is tracked in
https://fedorahosted.org/freeipa/ticket/3559 .
Since the UPN-suffix can be freely chosen, i.e. it does not have to be a
DNS domain, the client will ask it's local KDC with a special so called
enterprise principal if it knows about this UPN suffix and if the KDC
knows about it it will tell the client where to ask for it. IF ticket
#3559 gets implemented the entry in /etc/krb5.conf would not be needed
anymore.
HTH
bye,
Sumit

Post by n***@nathanpeters.com
--
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

--
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[n***@nathanpeters.com]

I'm a little confused by that.

If I add the AD dc, will my client try to contact AD directly to get a
ticket?

Doesn't it have to do get the ticket through FreeIPA by proxy somehow?

And to confirm what you meant by add the AD dc and realm, it would be like
this ?

SUB.ADDOMAIN.NET = {
kdc = dc1.addomain.net:88
}

I don't need the master_kdc, admin_server, default_domain entries?

Post by Sumit Bose

Post by n***@nathanpeters.com
Hmm, so if this is the [realms] section of my /etc/krb5.conf what do I
have to do ?
[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 =
auth_to_local = DEFAULT
}
Would I just literally copy that section and change the names?
SUB.ADDOMAIN.NET = {
kdc = dc1.ipadomain.net:88
master_kdc = dc1.ipadomain.net:88
admin_server = dc1.ipadomain.net:749
default_domain = ipadomain.net

you should add the AD DC and AD realm here
The following lines you can just drop.
HTH
bye,
Sumit

[Jakub Hrozek]

Post by n***@nathanpeters.com
I'm a little confused by that.
If I add the AD dc, will my client try to contact AD directly to get a
ticket?
Doesn't it have to do get the ticket through FreeIPA by proxy somehow?

No, authentication is always performed against an AD DC directly.

Post by n***@nathanpeters.com
And to confirm what you meant by add the AD dc and realm, it would be like
this ?
SUB.ADDOMAIN.NET = {
kdc = dc1.addomain.net:88
}
I don't need the master_kdc, admin_server, default_domain entries?

With a recent version of libkrb5 I don't think you need to set
master_kdc, libkrb5 should be able to follow referrals itself.
admin_servre, if unset, defaults to KDC. default_domain doesn't need to
be set either.

[Nathan Peters]

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/active-directory-trust.html#comp-trust-krb

The diagram in that section shows the client communicating with FreeIPA and
FreeIPA contacting AD.

So why are you saying the client authenticates with the AD DC directly?

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?

-----Original Message-----
From: Jakub Hrozek
Sent: Tuesday, May 05, 2015 8:43 PM
To: freeipa-***@redhat.com
Subject: Re: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD
trust and UPN issues

Post by n***@nathanpeters.com
I'm a little confused by that.
If I add the AD dc, will my client try to contact AD directly to get a
ticket?
Doesn't it have to do get the ticket through FreeIPA by proxy somehow?

No, authentication is always performed against an AD DC directly.

Post by n***@nathanpeters.com
And to confirm what you meant by add the AD dc and realm, it would be like
this ?
SUB.ADDOMAIN.NET = {
kdc = dc1.addomain.net:88
}
I don't need the master_kdc, admin_server, default_domain entries?

With a recent version of libkrb5 I don't think you need to set
master_kdc, libkrb5 should be able to follow referrals itself.
admin_servre, if unset, defaults to KDC. default_domain doesn't need to
be set either.

[Sumit Bose]

Post by Nathan Peters
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/active-directory-trust.html#comp-trust-krb
The diagram in that section shows the client communicating with FreeIPA and
FreeIPA contacting AD.
So why are you saying the client authenticates with the AD DC directly?

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.

Post by Nathan Peters
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

Post by Nathan Peters
-----Original Message----- From: Jakub Hrozek
Sent: Tuesday, May 05, 2015 8:43 PM
Subject: Re: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET" - AD
trust and UPN issues

Post by n***@nathanpeters.com
I'm a little confused by that.
If I add the AD dc, will my client try to contact AD directly to get a
ticket?
Doesn't it have to do get the ticket through FreeIPA by proxy somehow?

No, authentication is always performed against an AD DC directly.

Post by n***@nathanpeters.com
And to confirm what you meant by add the AD dc and realm, it would be like
this ?
SUB.ADDOMAIN.NET = {
kdc = dc1.addomain.net:88
}
I don't need the master_kdc, admin_server, default_domain entries?

With a recent version of libkrb5 I don't think you need to set
master_kdc, libkrb5 should be able to follow referrals itself.
admin_servre, if unset, defaults to KDC. default_domain doesn't need to
be set either.
--
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
--
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[n***@nathanpeters.com]

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 ***@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
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

Post by Sumit Bose
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.

Post by Nathan Peters
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

[Dmitri Pal]

Post by n***@nathanpeters.com
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
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.
default_domain_suffix = corp.addomain.net

I am not by any mean a specialist here but shouldn't it be the actual
suffix that is appended to the user name, i.e.

default_domain_suffix = addomain.net

Post by n***@nathanpeters.com
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 =
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"
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 =
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
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
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

Post by Sumit Bose
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.

Post by Nathan Peters
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

--
Thank you,
Dmitri Pal

Director of Engineering for IdM portfolio
Red Hat, Inc.

[n***@nathanpeters.com]

Post by Dmitri Pal

Post by n***@nathanpeters.com
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
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.
default_domain_suffix = corp.addomain.net

I am not by any mean a specialist here but shouldn't it be the actual
suffix that is appended to the user name, i.e.
default_domain_suffix = addomain.net

I don't think so. I think it is technically supposed to be the actual
domain, since the upn is just an alias at the username level. When I try
with addomain.net instead of the actual domain corp.addomain.net it
doesnt' even recognize the username or try to contact any kdc. Here is
the log entry:

May 07 04:38:24 dc1.ipadomain.net sshd[9893]: Invalid user adusername from
10.5.5.57
May 07 04:38:24 dc1.ipadomain.net sshd[9893]: input_userauth_request:
invalid user adusername [preauth]
May 07 04:38:27 dc1.ipadomain.net sshd[9893]: pam_unix(sshd:auth): check
pass; user unknown
May 07 04:38:27 dc1.ipadomain.net sshd[9893]: pam_unix(sshd:auth):
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.5.5.57
May 07 04:38:28 dc1.ipadomain.net sshd[9893]: Failed password for invalid
user adusername from 10.5.5.57 port 10921 ssh2

Post by Dmitri Pal

Post by n***@nathanpeters.com
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 =
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"
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 =
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
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
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

Post by Sumit Bose
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.

Post by Nathan Peters
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

--
Thank you,
Dmitri Pal
Director of Engineering for IdM portfolio
Red Hat, Inc.
--
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Sumit Bose]

Post by n***@nathanpeters.com
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
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.
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 =
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"
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 =
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

Post by n***@nathanpeters.com
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
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

Post by Sumit Bose
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.

Post by Nathan Peters
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

[n***@nathanpeters.com]

Post by Sumit Bose

Post by n***@nathanpeters.com
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
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.
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 =
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"
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 =
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 ***@corp.adupnalias.net.
May 07 18:31:19 ipadc1.ipadomain.net systemd[1]: Started Session 4 of user
***@corp.adupnalias.net.
May 07 18:31:19 ipadc1.ipadomain.net systemd-logind[718]: New session 4 of
user ***@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)

[Dmitri Pal]

Post by Nathan Peters
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/active-directory-trust.html#comp-trust-krb
The diagram in that section shows the client communicating with
FreeIPA and FreeIPA contacting AD.
So why are you saying the client authenticates with the AD DC directly?

You are looking at the older documentation. It is for RHEL6. Please use
RHEL7.1 docs to get the latest info about 4.1 functionality.

Post by Nathan Peters
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?
-----Original Message----- From: Jakub Hrozek
Sent: Tuesday, May 05, 2015 8:43 PM
Subject: Re: [Freeipa-users] Cannot find KDC for realm "MYDOMAIN.NET"
- AD trust and UPN issues

Post by n***@nathanpeters.com
I'm a little confused by that.
If I add the AD dc, will my client try to contact AD directly to get a
ticket?
Doesn't it have to do get the ticket through FreeIPA by proxy somehow?

No, authentication is always performed against an AD DC directly.

Post by n***@nathanpeters.com
And to confirm what you meant by add the AD dc and realm, it would be like
this ?
SUB.ADDOMAIN.NET = {
kdc = dc1.addomain.net:88
}
I don't need the master_kdc, admin_server, default_domain entries?

With a recent version of libkrb5 I don't think you need to set
master_kdc, libkrb5 should be able to follow referrals itself.
admin_servre, if unset, defaults to KDC. default_domain doesn't need to
be set either.

--
Thank you,
Dmitri Pal

Director of Engineering for IdM portfolio
Red Hat, Inc.

[n***@nathanpeters.com]

Post by Dmitri Pal

Post by Nathan Peters
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/active-directory-trust.html#comp-trust-krb
The diagram in that section shows the client communicating with
FreeIPA and FreeIPA contacting AD.
So why are you saying the client authenticates with the AD DC directly?

You are looking at the older documentation. It is for RHEL6. Please use
RHEL7.1 docs to get the latest info about 4.1 functionality.

Well according to the 7 docs here
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/active-directory-trust.html

it still shows in section 5.1.3.1 of that page that the sssd sends the
request on behalf of the client and the client never directly connects to
the AD dc.

Both the 6 and 7 docs show the exact same diagram.

[n***@nathanpeters.com]

FYI, this is what I get when I added another realm section to my
/etc/krb5.conf

May 05 18:00:26 dc1.ipadomain.net [sssd[krb5_child[2792]]][2792]: Looping
detected inside krb5_get_in_tkt
May 05 18:00:26 dc1.ipadomain.net [sssd[krb5_child[2792]]][2792]: Looping
detected inside krb5_get_in_tkt
May 05 18:00:26 dc1.ipadomain.net sshd[2789]: pam_sss(sshd:auth):
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.5.5.57 user=username
May 05 18:00:26 dc1.ipadomain.net sshd[2789]: pam_sss(sshd:auth): received
for user username: 4 (System error)
May 05 18:00:27 dc1.ipadomain.net sshd[2789]: Failed password for username
from 10.5.5.57 port 54775 ssh2

Here is what I added

ADDOMAIN.NET = {
kdc = dc1.ipadomain.net:88
master_kdc = dc1.ipadomain.net:88
admin_server = dc1.ipadomain.net:749
}

Post by Sumit Bose

Post by n***@nathanpeters.com
I am having some strange issues after upgrade from FreeIPA 4.1.2 to
4.1.3/4.1.4 on CentOS 7.
FreeIPA domain : ipadomain.net
Trusted AD domain : sub.addomain.net
In my AD domain, we have our UPN set to addomain.net so users typically
use_fully_qualified_names = True
[sssd]
default_domain_suffix = sub.addomain.net
This is what I see in the logs when I attempt to login as 'username' (with
Cannot find KDC for realm "ADDOMAIN.NET"
Cannot find KDC for realm "ADDOMAIN.NET"
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.5.5.57 user=username
received for user username: 4 (System error)
May 05 15:36:53 ipadc1.ipadomain.net sshd[4373]: Failed password for
username from 10.5.5.57 port 53118 ssh2
However, if in AD I switch the UPN on 'username' to the default of
authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.5.5.57 user=username
authentication success; logname= uid=0 euid=0 tty=ssh ruser=
rhost=10.5.5.57 user=username
May 04 23:11:01 ipadc1.ipadomain.net sshd[2293]: Accepted password for
username from 10.5.5.57 port 46077 ssh2
May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Starting
user-1539201103.slice.
May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Created slice
user-1539201103.slice.
May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Starting Session 3 of
May 04 23:11:01 ipadc1.ipadomain.net systemd[1]: Started Session 3 of user
May 04 23:11:01 ipadc1.ipadomain.net systemd-logind[716]: New session 3 of
session opened for user username by (uid=0)
As a temporary workaround I set dns_lookup_kdc = false in my
/etc/krb5.conf file and that worked to allow me to login with just
'username' but even after a successful login, I was seeing those 'cannot
find KDC for realm' message in the log.
Is there a proper way to allow people from a trusted AD domain to login
with their alternative UPNs?

I'm afraid currently the only way doing this is by adding a ADDOMAIN.NET
section to the realms section of /etc/krb5.conf to all IPA clients and
servers.
Although SSSD as a client in a AD domain can handle those UPNs there is
a missing part on the FreeIPA server side which is needed to make it
work. The item is tracked in
https://fedorahosted.org/freeipa/ticket/3559 .
Since the UPN-suffix can be freely chosen, i.e. it does not have to be a
DNS domain, the client will ask it's local KDC with a special so called
enterprise principal if it knows about this UPN suffix and if the KDC
knows about it it will tell the client where to ask for it. IF ticket
#3559 gets implemented the entry in /etc/krb5.conf would not be needed
anymore.
HTH
bye,
Sumit

Post by n***@nathanpeters.com
--
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

--
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project