Hi,
We are currently evaluating FreeIPA (again) for our environment. Our IPA has one-way trusts with two AD domains from two different forests. Most things seem to be working ok so far.
I'm now looking into setting up a samba server on an IPA-joined machine following the instructions in the documentation. This works okay for kerberos authentication (as documented), but not (yet) for username/password authentication.
Is this something that is being worked on? Is it on the roadmap for a specific version? Is it technically impossible?
It seems that we are in a situation where none of the direct/indirect options seem to work for us :-(. - direct integration with sssd does not support one-way AD trusts from different forests - direct integration with winbind also does not seem to support one-way AD trusts from different forests as it seems to try to use the machine credentials to connect to the domain controllers of the trusted domain but this fails as there is no trust in the other direction. I hoped this would work with idmap_rid but that does not seem to be the case? - indirect integration with ipa is what gets us as close to what we want to achieve as possible, except for this samba issue. Unfortunately this is somewhat of a blocker for us.
I don't think our setup is that special, so I'm wondering how other (freeIPA) users are handling this type of setup.
Regards, Rik
On pe, 05 helmi 2021, Rik Theys via FreeIPA-users wrote:
Hi,
We are currently evaluating FreeIPA (again) for our environment. Our IPA has one-way trusts with two AD domains from two different forests. Most things seem to be working ok so far.
I'm now looking into setting up a samba server on an IPA-joined machine following the instructions in the documentation. This works okay for kerberos authentication (as documented), but not (yet) for username/password authentication.
Is this something that is being worked on? Is it on the roadmap for a specific version? Is it technically impossible?
Please look at previous discussions on this list. For example, https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
It seems that we are in a situation where none of the direct/indirect options seem to work for us :-(.
- direct integration with sssd does not support one-way AD trusts from
different forests
- direct integration with winbind also does not seem to support one-way
AD trusts from different forests as it seems to try to use the machine credentials to connect to the domain controllers of the trusted domain but this fails as there is no trust in the other direction. I hoped this would work with idmap_rid but that does not seem to be the case?
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.
While it is visible in the case you have more than one domain in a trusted forest with a lot of DCs across multiple locations that aren't easily reachable, it can also affect non-IPA use case and we saw such reports for a basic file server too, like in this thread on samba-technical@ upstream: https://lists.samba.org/archive/samba-technical/2021-January/136246.html
A comprehensive fix was worked on in https://gitlab.com/samba-team/samba/-/merge_requests/1573 but it got stalled late last year for various reasons.
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.
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).
- 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
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.
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Rik Theys