On Thu, Jul 23, 2020 at 11:51:41AM -0000, Sam Morris via FreeIPA-users wrote:
I have a FreeIPA setup that trusts an Active Directory domain. I have users who exist in the AD domain, but who are unable to log into Linux systems.
The domains are:
ad.domain.examaple: the Active Directory domain
ipa.ad.domain.example: the FreeIPA domain
The user has a SAM-Account-Name of 'user.name' and a userPrincipalName of 'user.name@thirdparty.com'.
Hi,
which version of IPA are you using?
Is 'thirdparty.com' listed among the 'UPN suffixes' in the 'ipa trust-find' output?
bye, Sumit
Here are the log messages I see when one of them tries to log in:
==> krb5_child.log <== (Thu Jul 23 11:08:58 2020) [[sssd[krb5_child[2481132]]]] [get_and_save_tgt] (0x0020): 1704: [-1765328378][Client 'user.name@THIRDPARTY.COM@IPA.AD.DOMAIN.EXAMPLE' not found in Kerberos database] (Thu Jul 23 11:08:58 2020) [[sssd[krb5_child[2481132]]]] [map_krb5_error] (0x0020): 1833: [-1765328378][Client 'user.name@THIRDPARTY.COM@IPA.AD.DOMAIN.EXAMPLE' not found in Kerberos database]
==> sssd_ipa.ad.domain.example.log <== (Thu Jul 23 11:08:58 2020) [sssd[be[ipa.ad.domain.example]]] [krb5_auth_done] (0x0040): The krb5_child process returned an error. Please inspect the krb5_child.log file or the journal for more information
A bit of research brings me to https://docs.microsoft.com/en-us/windows/win32/ad/naming-properties which states:
A UPN suffix has the following restrictions:
It must be the DNS name of a domain, but does not need to be the name of the domain that contains the user.
It must be the name of a domain in the current domain forest, or an alternate name listed in the upnSuffixes attribute of the Partitions container within the Configuration container.
I believe the user account violates the second of these restrictions, in that its suffix (thirdparty.com) is neither in the AD forest, nor is it found in the upnSuffixes attribute of CN=Partitions,CN=Configuration,DC=ad,DC=domain,DC=example in AD.
Now the ugly part. I suspect this is just How Things Are Done around here and getting the user's userPrincipalName changed to ad.domain.example will not be particularly easy.
So in the meantime, is there any configuration I can do, either on the FreeIPA servers or on the machine where the user needs to log in, to work around the UPN suffix mismatch?
I am able to get a TGT for the user with 'kinit user.name@AD.DOMAIN.EXAMPLE', so I guess I'm looking for a hypothetical way to tell sssd to map the UPN suffix in the user's domain (thirdparty.com) to ad.domain.example when it tries to get a ticket during user login...
I can also ask to get thirdparty.com added to the AD domain's list of UPN suffixes. Can anyone confirm whether this would be sufficient to get sssd to be able to authenticate the user?
Thanks!
-- Sam Morris https://robots.org.uk/ _______________________________________________ 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...