So in case someone is stumbling over the same problem I had I post the outcome to the list.
Alexander was so kind to donate a bunch of his time in spotting the problem for which am grateful. From the generated logs on the client (ums029 in my initial mail, later I had to change to a different machine ums038 for completeness) he saw that the client thought that the IPA and the AD domain both share example.com which clearly would not work. But IPA is running under ipa.example.com and Ad under example.com But in this special case a requirement with this customer was to have host resolve as <host>.example.com even if they are attached to IPA (instead of <host>.ipa.example.com) which was working fine without the Samba share requirement. So here is the final mail conversation I had with Alexander containing all the nitty gritty bits of complexity IPA handles for us: -- my last mail to Alexander -- One thing that might interfere: the customer requested that hosts should resolve with <host>.example.com and this was required also for hosts which are connected to IPA. I had already a question in the past (beginning of 2023) were I asked wether the IPA host itself requires to be in the same domain and your answer was yes. So IPA host resolves as ums012.ipa.example.com but all other hosts connected to IPA do not e.g. ums025.example.com Could this be the reason for samba problems now? —- and Alexander’s answer to it — Yes, it is the problem. Please read the page I referred to. (he referred to https://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain) Your SMB client asks for a service ticket to SMB server. Kerberos protocol is built in a such way that a service principal is constructed by using the DNS name of the machine, e.g. cifs/ums025.example.com is used and this principal belongs to AD namespace. The client, thus, asks AD DC about the service ticket. AD DC has no idea about this prinicipal and has no way to tell the client to talk to a different KDC to request a ticket. In AD there is a way to add namespaces routed to specific domains when there is a trust established between them. This is how AD DCs know they need to issue a referral to talk to IPA when a service principal is in ipa.example.com namespace. However, this mechanism does not work for individual hosts, only for DNS domain level. This is fundamental requirement and we cannot avoid it when interoperating with Active Directory, at least Microsoft implementation. For MIT Kerberos, there is a special support for per-host discovery of Kerberos realm the host belongs to. But with Windows systems being involved, this mechanism does not work, they simply have no support for it. And here AD DC is the Windows system that makes a decision. On Linux systems you can try to force client-side redirection with either per-host DNS TXT information or with explicit krb5.conf domain/realm mapping per host. All of that has their own limitations as well. Windows clients will always fail. You can also read https://vda.li/en/posts/2019/03/24/Kerberos-host-to-realm-translation/ for some of that complexity. Best regards, Thomas -----Original Message----- From: Alexander Bokovoy <[email protected]> Reply: Alexander Bokovoy <[email protected]> Date: 1. March 2024 at 08:29:34 To: Thomas Handler <[email protected]> Cc: FreeIPA users list <[email protected]> Subject: Re: [Freeipa-users] problem allowing Windows Active Directory users to access SMB shares on IPA client machine (IPA has trust with AD) > > On Чцв, 29 лют 2024, Thomas Handler wrote: > >Dear Alexander, > > > >thank you for your assistance this is greatly appreciated. > > > >Regarding the logs - the got quite big, not sure if I can attach > them > >here as a .tgz as I have 972k uncompressed. > > You can send to me directly or upload somewhere and send a link. -- _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
