On pe, 05 helmi 2021, Rik Theys via FreeIPA-users wrote:
Hi Alexander,
Thank you for the detailed response!
> On pe, 05 helmi 2021, Rik Theys via FreeIPA-users wrote:
>
> Please look at previous discussions on this list.
> For example,
>
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>
Very interesting read. If I understand it correctly:
- In order for a Samba member server to process NTLM authentications,
it needs access to the RC4 hash of the account. If the account is an
IPA account, it gets it from ipaNTHash, which may not exist due to
no-RC4 policy. What happens if the account that tries to use NTLM is
from a trusted AD domain? Will Samba try to fetch the RC4 hash from the
domain controller (directly)? If that domain controller does have the
NT hash it should be possible, no? (I'm leaving out the part where RC4
is deprecated now).
Samba will use so-called proxy authentication request to a domain
controller of the user's domain. This is where winbindd comes into play.
It needs to know how to route this request through a trusted DC.
For a domain member it should always be its own domain controller which
then should find a trusted domain to which DCs it could route the
request and so on. This requires two-way trust all the way down to the
user's domain.
- NTLM needs RC4 which is deprecated. Does this mean that Samba in RHEL
8.4 with the default crypto-policy configuration will no longer
allow/support NTLM auth (even without IPA in play)? With the lack of
NTLM, there's currently no way for a user using a BYOD device to access
a samba share using his username/password? To have this capability
again would require the NegoEX extension? Until this is all
implemented, the only way to allow username/password auth is with NTLM
by configuring the AD-SUPPORT crypto-policy?
Correct AD-SUPPORT subpolicy is required to all this to work, along with
what I described above.
> You are mixing up identity mapping methods which are independent of
> trusted domains' handling in winbindd. These are at different layers and
> aren't directly related. winbindd has a bug where internal operations
> across multiple trusted domains (whether directly or via others) aren't
> fully asynchronous. As a result, in some scenarios an attempt to resolve
> a DC name and contact it for some trusted domain might block other
> operations related to the same forest. That leads to a timeout that is
> then interpreted as the whole domain is offline and thus rejecting some
> upper layer requests.
In my "direct integration with winbind (using idmap_rid for the one-way
trusted domain)" test, I was able to do a "getent
username@trusted-ad-realm" (could also have been an "id
username@trusted-ad-realm") and get a response. But I was unable to
login as that user as it seemed some part of the PAM stack could not
resolve the user. I don't think the domain was considered offline at
that time. From what I could tell from the logs, the client was using
his machine credentials (joined to domain A) to contact the domain
controller of domain B but these are not allowed as it's a one-way
trust. If samba knows the trust is one-way, should it not route those
type of requests through the domain controller of its own domain?
Looking at the verbose output of wbinfo --trusted-domains, it does say
"routed". Is that not what it (should) mean? Or is that the same bug
you are referring to?
No, this is the other part of the problem -- as I said, you need two-way
trust to get this all working with direct integration with winbindd
becase there should be some way to reach out to a DC of that user's
domain. A proxy authentication/proxy identity request can be done by
winbindd against its own DC (they always have mutual trust, domain
member and domain controller in the same domain), but that DC has to be
able to talk to the domain controller of the next trusted domain in the
chain to reach the user domain's DC. For pure LSA requests it should
work with one-way trust but if winbindd has to use LDAP to pull the data
(e.g. with idmap_ad or alike), it would need to authenticate to the
domain controllers in the user's domain directly, thus a need for
two-way trust to be able to request a service Kerberos ticket towards
*that* DC's LDAP service. In such case SSSD would work too.
But in the first place winbindd need to know it doesn't have to talk to
a non-directly trusted domain controller directly and this is one thing
not fully done, as I said, for IPA environments.
> On top of that, IPA was not correctly supplying topology information to
> winbindd where required which led it to attempt to contact trusted
> domains it couldn't talk to as it missed trusted object credentials
> towards those domains. This is partially fixed in FreeIPA 4.9.1 as we
> now store the binary blob expected by winbind and return it properly but
> still there is something preventing winbindd to reuse it. This is due to
> IPA Samba integration being a Frankenstein-like mixture of a traditional
> NT domain controller and Active Directory domain controller but not
> fully the latter. I am working at the moment on fixing this, though it
> will most likely take more time to get it fully addressed than I
> expected.
This sounds like it could explain why I could not see the resolved
names in the "Security" tab of a file when accessing it over Samba
(joined to IPA domain) as an AD user. It only showed the SID. I'm
running my tests on FreeIPA 4.8 from CentOS 8.
No, this is a different story ;) It needs more than that. FreeIPA 4.9.1
merged *some* of the code for the identity resolution from our Global
Catalog work in progress _and_ you'd need Samba with additional patches
(part of 4.14rc1+ or Samba in Fedora 33+ and CentOS 8 Stream) to make
that SID resolution working.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland