What would be a good solution to add systems where the FQDN cannot be changed?
Would it make sense to add a second DNS A Record in the IPA domain for each of these systems?
Is there any experience on how to deal with such a situation?
Thanks a lot in advance!
Cheers, Ronald
On Mon, Jan 28, 2019 at 12:20 PM Ronald Wimmer via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
What would be a good solution to add systems where the FQDN cannot be changed?
It's a pretty generic question, could you be more specific?
For instance, does that legacy system live in a zone controlled by AD?
Would it make sense to add a second DNS A Record in the IPA domain for each of these systems?
Is there any experience on how to deal with such a situation?
Depending on the actual use-case, you might want to add a DNS zone matching the one for the legacy client, and a realm domain ( https://www.freeipa.org/page/V3/Realm_Domains ) for that as well. Then you should be set. But again it is hard to make sure this fits your use case without at least an example. Also see the caveats in https://www.freeipa.org/page/DNS
Regards, François
Thanks a lot in advance!
Cheers, Ronald _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
On 28.01.19 12:36, François Cami wrote:
On Mon, Jan 28, 2019 at 12:20 PM Ronald Wimmer via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
What would be a good solution to add systems where the FQDN cannot be changed?
It's a pretty generic question, could you be more specific?
Legacy systems are in an AD domain. IPA has a trust setup to mydomain.at which includes the subdomains a.mydomain.at as well as b.mydomain.at. (AD systems can reside in mydomain.at, a.mydomain.at or b.mydomain.at)
DNS is a separate system.
[...] Depending on the actual use-case, you might want to add a DNS zone matching the one for the legacy client, and a realm domain ( https://www.freeipa.org/page/V3/Realm_Domains ) for that as well.
As stated above the legacy systems already are in a REALM controlled by AD.
Cheers, Ronald
On Mon, Jan 28, 2019 at 12:52 PM Ronald Wimmer ronaldw@ronzo.at wrote:
On 28.01.19 12:36, François Cami wrote:
On Mon, Jan 28, 2019 at 12:20 PM Ronald Wimmer via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
What would be a good solution to add systems where the FQDN cannot be changed?
It's a pretty generic question, could you be more specific?
Legacy systems are in an AD domain. IPA has a trust setup to mydomain.at which includes the subdomains a.mydomain.at as well as b.mydomain.at. (AD systems can reside in mydomain.at, a.mydomain.at or b.mydomain.at)
DNS is a separate system.
[...] Depending on the actual use-case, you might want to add a DNS zone matching the one for the legacy client, and a realm domain ( https://www.freeipa.org/page/V3/Realm_Domains ) for that as well.
As stated above the legacy systems already are in a REALM controlled by AD.
Then please review: https://rhelblog.redhat.com/2016/07/13/i-really-cant-rename-my-hosts/
Cheers, Ronald
On ma, 28 tammi 2019, Ronald Wimmer via FreeIPA-users wrote:
What would be a good solution to add systems where the FQDN cannot be changed?
Would it make sense to add a second DNS A Record in the IPA domain for each of these systems?
Is there any experience on how to deal with such a situation?
Really depends on where these existing clients are located and what is their function. Do they belong to some other Kerberos realm already? Like some Active Directory domain?
Some scenarios are covered by https://rhelblog.redhat.com/2016/07/13/i-really-cant-rename-my-hosts/ and related articles linked from that blog.
On 28.01.19 12:42, Alexander Bokovoy wrote:
On ma, 28 tammi 2019, Ronald Wimmer via FreeIPA-users wrote: [...]
Is there any experience on how to deal with such a situation?
Really depends on where these existing clients are located and what is their function. Do they belong to some other Kerberos realm already? Like some Active Directory domain?
Some scenarios are covered by https://rhelblog.redhat.com/2016/07/13/i-really-cant-rename-my-hosts/ and related articles linked from that blog.
It looks like option 3b from your link would work. I do not care if I lose Kerberos functionality. What I do care about is if I still have the possibility to use
- IPA users for logging in on these systems - users coming form AD - sudo rules - HBAC rules
Cheers, Ronald
On Mon, Jan 28, 2019 at 1:02 PM Ronald Wimmer via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On 28.01.19 12:42, Alexander Bokovoy wrote:
On ma, 28 tammi 2019, Ronald Wimmer via FreeIPA-users wrote: [...]
Is there any experience on how to deal with such a situation?
Really depends on where these existing clients are located and what is their function. Do they belong to some other Kerberos realm already? Like some Active Directory domain?
Some scenarios are covered by https://rhelblog.redhat.com/2016/07/13/i-really-cant-rename-my-hosts/ and related articles linked from that blog.
It looks like option 3b from your link would work. I do not care if I lose Kerberos functionality. What I do care about is if I still have the possibility to use
- IPA users for logging in on these systems
- users coming form AD
- sudo rules
- HBAC rules
The thing is, if I'm not mistaken Kerberos is required for sudo and HBAC to work.
Cheers, Ronald _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
On ma, 28 tammi 2019, François Cami wrote:
On Mon, Jan 28, 2019 at 1:02 PM Ronald Wimmer via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On 28.01.19 12:42, Alexander Bokovoy wrote:
On ma, 28 tammi 2019, Ronald Wimmer via FreeIPA-users wrote: [...]
Is there any experience on how to deal with such a situation?
Really depends on where these existing clients are located and what is their function. Do they belong to some other Kerberos realm already? Like some Active Directory domain?
Some scenarios are covered by https://rhelblog.redhat.com/2016/07/13/i-really-cant-rename-my-hosts/ and related articles linked from that blog.
It looks like option 3b from your link would work. I do not care if I lose Kerberos functionality. What I do care about is if I still have the possibility to use
- IPA users for logging in on these systems
- users coming form AD
- sudo rules
- HBAC rules
The thing is, if I'm not mistaken Kerberos is required for sudo and HBAC to work.
No. id_provider=ipa is required but that means SSSD would by default use host/... Kerberos principal to talk to IPA masters. That's all enabled and will work just fine if krb5.conf on the client maps to hostname of this machine to IPA realm. What will not work is Kerberos (GSSAPI) authentication from Windows clients to these machines because at that point Windows systems will rely on AD DCs' knowledge of where host/... belongs to (which realm) and those will see a host from *.mydomain.at and consider it is only belonging to AD DC. They also will not find the host in AD (since it is not really enrolled in AD) and thus will deny any Kerberos service ticket to services hosted on that machine. At no point they will be considering that this host belongs to some other realm (IPA).
Cheers, Ronald _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
I sucessfully registered my server server5.mydomain.at. After setting up an appropriate HBAC rule as well as setting the default domain in the sssd.conf to a.mydomain.at I tried to connect to the server via SSH using:
myusername@MYDOMAIN.AT
This fails because the UPN seems to be picked:
[sssd[krb5_child[24704]]]: Client 'ronald.wimmer@MYDOMAIN.AT' not found in Kerberos database
(After the migration to Office365 the UPN looks like name.surname@mydomain.at.)
On other IPA clients the correct user is taken. (employeeNumber@a.mydomain.at)
My /etc/krb5.conf looks like this:
[libdefaults] default_realm = MYDOMAIN.AT dns_lookup_realm = false dns_lookup_kdc = false rdns = false dns_canonicalize_hostname = false ticket_lifetime = 24h forwardable = true udp_preference_limit = 0 default_ccache_name = KEYRING:persistent:%{uid}
[realms] LINUX.MYDOMAIN.AT = { kdc = ipa2.linux.mydomain.at:88 master_kdc = ipa2.linux.mydomain.at:88 admin_server = ipa2.linux.mydomain.at:749 kpasswd_server = ipa2.linux.mydomain.at:464 default_domain = linux.mydomain.at pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
} MYDOMAIN.AT = { kdc = ipa2.linux.mydomain.at:88 master_kdc = ipa2.linux.mydomain.at:88 admin_server = ipa2.linux.mydomain.at:749 kpasswd_server = ipa2.linux.mydomain.at:464 default_domain = mydomain.at pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
}
[domain_realm] .linux.mydomain.at = LINUX.MYDOMAIN.AT linux.mydomain.at = LINUX.MYDOMAIN.AT server5.mydomain.at = LINUX.MYDOMAIN.AT .mydomain.at = MYDOMAIN.AT
Why is this happening and what could I try?
Cheers, Ronald
On ti, 29 tammi 2019, Ronald Wimmer via FreeIPA-users wrote:
I sucessfully registered my server server5.mydomain.at. After setting up an appropriate HBAC rule as well as setting the default domain in the sssd.conf to a.mydomain.at I tried to connect to the server via SSH using:
myusername@MYDOMAIN.AT
This fails because the UPN seems to be picked:
[sssd[krb5_child[24704]]]: Client 'ronald.wimmer@MYDOMAIN.AT' not found in Kerberos database
(After the migration to Office365 the UPN looks like name.surname@mydomain.at.)
On other IPA clients the correct user is taken. (employeeNumber@a.mydomain.at)
My /etc/krb5.conf looks like this:
I think you need to tune sssd configuration here. Sumit or Jakub may have more details on what exact options should be used.
On 29.01.19 12:28, Alexander Bokovoy via FreeIPA-users wrote:
[...] I think you need to tune sssd configuration here. Sumit or Jakub may have more details on what exact options should be used.
Should I contact them directly or are they gonna read this here anyway?
I tested an IPA user - that worked perfectly.
Cheers, Ronald
On ti, 29 tammi 2019, Ronald Wimmer via FreeIPA-users wrote:
On 29.01.19 12:28, Alexander Bokovoy via FreeIPA-users wrote:
[...] I think you need to tune sssd configuration here. Sumit or Jakub may have more details on what exact options should be used.
Should I contact them directly or are they gonna read this here anyway?
I think they both read this list.
I tested an IPA user - that worked perfectly.
It is not IPA thing -- supporting AD UPNs a bit more complex than supporting aliases in IPA case. Unfortunately, I cannot find consistent user-level documentation for that.
On Tue, Jan 29, 2019 at 11:19:22AM +0100, Ronald Wimmer via FreeIPA-users wrote:
I sucessfully registered my server server5.mydomain.at. After setting up an appropriate HBAC rule as well as setting the default domain in the sssd.conf to a.mydomain.at I tried to connect to the server via SSH using:
myusername@MYDOMAIN.AT
This fails because the UPN seems to be picked:
[sssd[krb5_child[24704]]]: Client 'ronald.wimmer@MYDOMAIN.AT' not found in Kerberos database
(After the migration to Office365 the UPN looks like name.surname@mydomain.at.)
Since you redirected MYDOMAIN.AT to the IPA server in krb5.conf the client cannot properly send the UPN to an AD DC.
You can disable UPN handling by setting 'ldap_user_principal = noSuchAttr' in the domain section of sssd.conf on the IPA servers. You have to wait until the SSSD cache on the server and the client are updated before the client would start using employeeNumber@a.mydomain.at.
But I wonder if the redirection to the IPA server is needed in krb5.conf at all ...
On other IPA clients the correct user is taken. (employeeNumber@a.mydomain.at)
My /etc/krb5.conf looks like this:
[libdefaults] default_realm = MYDOMAIN.AT dns_lookup_realm = false dns_lookup_kdc = false rdns = false dns_canonicalize_hostname = false ticket_lifetime = 24h forwardable = true udp_preference_limit = 0 default_ccache_name = KEYRING:persistent:%{uid}
[realms] LINUX.MYDOMAIN.AT = { kdc = ipa2.linux.mydomain.at:88 master_kdc = ipa2.linux.mydomain.at:88 admin_server = ipa2.linux.mydomain.at:749 kpasswd_server = ipa2.linux.mydomain.at:464 default_domain = linux.mydomain.at pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
} MYDOMAIN.AT = { kdc = ipa2.linux.mydomain.at:88 master_kdc = ipa2.linux.mydomain.at:88 admin_server = ipa2.linux.mydomain.at:749 kpasswd_server = ipa2.linux.mydomain.at:464 default_domain = mydomain.at pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
}
[domain_realm] .linux.mydomain.at = LINUX.MYDOMAIN.AT linux.mydomain.at = LINUX.MYDOMAIN.AT server5.mydomain.at = LINUX.MYDOMAIN.AT .mydomain.at = MYDOMAIN.AT
If you replace this line with
.mydomain.at = LINUX.MYDOMAIN.AT
I would expect that libkrb5 will use the LINUX.MYDOMAIN.AT realm whenever there is a DNS hostname from .mydomain.at is used. This way it should be possible to add AD DCs to the MYDOMAIN.AT section so that request which contain the realm explicitly like 'ronald.wimmer@MYDOMAIN.AT' would be send to an AD DCs.
Please let me know if you have a chance to test this and let me know the result.
HTH
bye, Sumit
Why is this happening and what could I try?
Cheers, Ronald _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
On Tue, Jan 29, 2019 at 11:19:22AM +0100, Ronald Wimmer via FreeIPA-users wrote: ... https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/WV4DGJV66P3YPQLLO7FV3BMFXMW7B7JJ/# Since you redirected MYDOMAIN.AT to the IPA server in krb5.conf the client cannot properly send the UPN to an AD DC. You can disable UPN handling by setting 'ldap_user_principal = noSuchAttr' in the domain section of sssd.conf on the IPA servers. You have to wait until the SSSD cache on the server and the client are updated before the client would start using employeeNumber(a)a.mydomain.at. But I wonder if the redirection to the IPA server is needed in krb5.conf at all ... ... https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/WV4DGJV66P3YPQLLO7FV3BMFXMW7B7JJ/# If you replace this line with .mydomain.at = LINUX.MYDOMAIN.AT I would expect that libkrb5 will use the LINUX.MYDOMAIN.AT realm whenever there is a DNS hostname from .mydomain.at is used. This way it should be possible to add AD DCs to the MYDOMAIN.AT section so that request which contain the realm explicitly like 'ronald.wimmer(a)MYDOMAIN.AT' would be send to an AD DCs.
Unfortunately, setting ldap_user_principal to NoSuchAttr was not enough in order to make AD user login work. What else could I try? Which logs are relevant here?
Cheers, Ronald
On Wed, Apr 08, 2020 at 07:45:35AM +0200, Ronald Wimmer via FreeIPA-users wrote:
On Tue, Jan 29, 2019 at 11:19:22AM +0100, Ronald Wimmer via FreeIPA-users wrote: ... https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/WV4DGJV66P3YPQLLO7FV3BMFXMW7B7JJ/# Since you redirected MYDOMAIN.AT to the IPA server in krb5.conf the client cannot properly send the UPN to an AD DC. You can disable UPN handling by setting 'ldap_user_principal = noSuchAttr' in the domain section of sssd.conf on the IPA servers. You have to wait until the SSSD cache on the server and the client are updated before the client would start using employeeNumber(a)a.mydomain.at. But I wonder if the redirection to the IPA server is needed in krb5.conf at all ... ... https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/WV4DGJV66P3YPQLLO7FV3BMFXMW7B7JJ/# If you replace this line with  .mydomain.at = LINUX.MYDOMAIN.AT I would expect that libkrb5 will use the LINUX.MYDOMAIN.AT realm whenever there is a DNS hostname from .mydomain.at is used. This way it should be possible to add AD DCs to the MYDOMAIN.AT section so that request which contain the realm explicitly like 'ronald.wimmer(a)MYDOMAIN.AT' would be send to an AD DCs.
Unfortunately, setting ldap_user_principal to NoSuchAttr was not enough in order to make AD user login work. What else could I try? Which logs are relevant here?
Hi,
thanks for you patience. Can you send the SSSD domain and krb5_child.log with debug_level=9 in the [domain/...] section to understand why using 'ldap_user_principal = noSuchAttr' on the IPA servers does not help?
Have you tried the changes to the domain realm mapping in krb5.conf?
bye, Sumit
Cheers, Ronald
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
On 13.05.20 15:08, Sumit Bose via FreeIPA-users wrote:
On Wed, Apr 08, 2020 at 07:45:35AM +0200, Ronald Wimmer via FreeIPA-users wrote:
On Tue, Jan 29, 2019 at 11:19:22AM +0100, Ronald Wimmer via FreeIPA-users wrote: ... https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/WV4DGJV66P3YPQLLO7FV3BMFXMW7B7JJ/# Since you redirected MYDOMAIN.AT to the IPA server in krb5.conf the client cannot properly send the UPN to an AD DC. You can disable UPN handling by setting 'ldap_user_principal = noSuchAttr' in the domain section of sssd.conf on the IPA servers. You have to wait until the SSSD cache on the server and the client are updated before the client would start using employeeNumber(a)a.mydomain.at. But I wonder if the redirection to the IPA server is needed in krb5.conf at all ... ... https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/WV4DGJV66P3YPQLLO7FV3BMFXMW7B7JJ/# If you replace this line with  .mydomain.at = LINUX.MYDOMAIN.AT I would expect that libkrb5 will use the LINUX.MYDOMAIN.AT realm whenever there is a DNS hostname from .mydomain.at is used. This way it should be possible to add AD DCs to the MYDOMAIN.AT section so that request which contain the realm explicitly like 'ronald.wimmer(a)MYDOMAIN.AT' would be send to an AD DCs.
Unfortunately, setting ldap_user_principal to NoSuchAttr was not enough in order to make AD user login work. What else could I try? Which logs are relevant here?
Hi,
thanks for you patience. Can you send the SSSD domain and krb5_child.log with debug_level=9 in the [domain/...] section to understand why using 'ldap_user_principal = noSuchAttr' on the IPA servers does not help?
When I set ldap_user_principal to noSuchAttr on an IPA server and do a "id myusername" it seems I am waiting forever. Would realm mapping in krb5.conf be sufficient in an IPA client's krb5.conf file or would i have to do that on an IPA server as well?
Cheers, Ronald
On Tue, May 26, 2020 at 05:06:21PM +0200, Ronald Wimmer via FreeIPA-users wrote:
On 13.05.20 15:08, Sumit Bose via FreeIPA-users wrote:
On Wed, Apr 08, 2020 at 07:45:35AM +0200, Ronald Wimmer via FreeIPA-users wrote:
On Tue, Jan 29, 2019 at 11:19:22AM +0100, Ronald Wimmer via FreeIPA-users wrote: ... https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/WV4DGJV66P3YPQLLO7FV3BMFXMW7B7JJ/# Since you redirected MYDOMAIN.AT to the IPA server in krb5.conf the client cannot properly send the UPN to an AD DC. You can disable UPN handling by setting 'ldap_user_principal = noSuchAttr' in the domain section of sssd.conf on the IPA servers. You have to wait until the SSSD cache on the server and the client are updated before the client would start using employeeNumber(a)a.mydomain.at. But I wonder if the redirection to the IPA server is needed in krb5.conf at all ... ... https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/WV4DGJV66P3YPQLLO7FV3BMFXMW7B7JJ/# If you replace this line with ÃÂ .mydomain.at = LINUX.MYDOMAIN.AT I would expect that libkrb5 will use the LINUX.MYDOMAIN.AT realm whenever there is a DNS hostname from .mydomain.at is used. This way it should be possible to add AD DCs to the MYDOMAIN.AT section so that request which contain the realm explicitly like 'ronald.wimmer(a)MYDOMAIN.AT' would be send to an AD DCs.
Unfortunately, setting ldap_user_principal to NoSuchAttr was not enough in order to make AD user login work. What else could I try? Which logs are relevant here?
Hi,
thanks for you patience. Can you send the SSSD domain and krb5_child.log with debug_level=9 in the [domain/...] section to understand why using 'ldap_user_principal = noSuchAttr' on the IPA servers does not help?
When I set ldap_user_principal to noSuchAttr on an IPA server and do a "id myusername" it seems I am waiting forever. Would realm mapping in krb5.conf be sufficient in an IPA client's krb5.conf file or would i have to do that on an IPA server as well?
Hi,
the '.mydomain.at = LINUX.MYDOMAIN' change in the [domain_realm] section and the change of the MYDOMAIN.AT from [realms] to point to an AD DC can be done on the clients only. But if you want to let AD users authenticate on the IPA servers you might need similar changes as well.
Btw, if you set 'dns_lookup_kdc = true' you can remove the MYDOMAIN.AT section from [realms] at all.
bye, Sumit
Cheers, Ronald _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
Hello,
Pardon me if this reply is off the mark, but I've only glanced at this thread and noticed that there was a similar vein with our legacy IPA clients (RHEL 6.x).
Our AD logins also were failing and it was traced down to the two quoted items below.
Unfortunately, setting ldap_user_principal to NoSuchAttr was not enough in order to make AD user login work. What else could I try? Which logs are relevant here?
&
Btw, if you set 'dns_lookup_kdc = true' you can remove the MYDOMAIN.AT section from [realms] at all.
Our configuration required the following items to be set within krb5.conf:
dns_lookup_realm = true dns_lookup_kdc = true
And the following item within the [domain] section within sssd.conf had to be present:
krb5_use_enterprise_principal = true
Once all of these changes were set, AD logins on client nodes functioned without an issue.
HTH, John DeSantis
Il giorno mer 27 mag 2020 alle ore 02:23 Sumit Bose via FreeIPA-users freeipa-users@lists.fedorahosted.org ha scritto:
On Tue, May 26, 2020 at 05:06:21PM +0200, Ronald Wimmer via FreeIPA-users wrote:
On 13.05.20 15:08, Sumit Bose via FreeIPA-users wrote:
On Wed, Apr 08, 2020 at 07:45:35AM +0200, Ronald Wimmer via FreeIPA-users wrote:
On Tue, Jan 29, 2019 at 11:19:22AM +0100, Ronald Wimmer via FreeIPA-users wrote: ... https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/WV4DGJV66P3YPQLLO7FV3BMFXMW7B7JJ/# Since you redirected MYDOMAIN.AT to the IPA server in krb5.conf the client cannot properly send the UPN to an AD DC. You can disable UPN handling by setting 'ldap_user_principal = noSuchAttr' in the domain section of sssd.conf on the IPA servers. You have to wait until the SSSD cache on the server and the client are updated before the client would start using employeeNumber(a)a.mydomain.at. But I wonder if the redirection to the IPA server is needed in krb5.conf at all ... ... https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/WV4DGJV66P3YPQLLO7FV3BMFXMW7B7JJ/# If you replace this line with  .mydomain.at = LINUX.MYDOMAIN.AT I would expect that libkrb5 will use the LINUX.MYDOMAIN.AT realm whenever there is a DNS hostname from .mydomain.at is used. This way it should be possible to add AD DCs to the MYDOMAIN.AT section so that request which contain the realm explicitly like 'ronald.wimmer(a)MYDOMAIN.AT' would be send to an AD DCs.
Unfortunately, setting ldap_user_principal to NoSuchAttr was not enough in order to make AD user login work. What else could I try? Which logs are relevant here?
Hi,
thanks for you patience. Can you send the SSSD domain and krb5_child.log with debug_level=9 in the [domain/...] section to understand why using 'ldap_user_principal = noSuchAttr' on the IPA servers does not help?
When I set ldap_user_principal to noSuchAttr on an IPA server and do a "id myusername" it seems I am waiting forever. Would realm mapping in krb5.conf be sufficient in an IPA client's krb5.conf file or would i have to do that on an IPA server as well?
Hi,
the '.mydomain.at = LINUX.MYDOMAIN' change in the [domain_realm] section and the change of the MYDOMAIN.AT from [realms] to point to an AD DC can be done on the clients only. But if you want to let AD users authenticate on the IPA servers you might need similar changes as well.
Btw, if you set 'dns_lookup_kdc = true' you can remove the MYDOMAIN.AT section from [realms] at all.
bye, Sumit
Cheers, Ronald _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
François Cami -
John Desantis -
Ronald Wimmer -
Sumit Bose