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/[email protected]... > 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). - 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? > 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? > 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. Regards, Rik _______________________________________________ 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]
