New subject: AD trust user logins where their userPrincipalName does not match AD's DNS domain name

23 Jul 2020


      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'.
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/