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 <abokovoy(a)redhat.com>
Reply: Alexander Bokovoy <abokovoy(a)redhat.com>
Date: 1. March 2024 at 08:29:34
To: Thomas Handler <cdth(a)gmx.net>
Cc: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
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.