Created attachment 7144 [details] Patch for 3.5 Winbind is member of Domain A. A has a one-way trust to domain B.COM. B.COM has a transitive trust to domain C.B.COM. winbind can't authenticate C\\username, because C does not show up in wbinfo -m (our domain list). We can't authenticate against B.COM, that's why we can't ask B.COM for its trusts. With the attached patchset against 3.5 (later versions have the same problem) I successfully tested an smbclient connection to Samba in domain A with C\\username. Comments? Volker
Comment on attachment 7144 [details] Patch for 3.5 Un-asked ACK. We need this.
Ups, just learned that the patch is not complete yet.
This requires a significant amount of cleanup work that might eventually be done by the maintainer of the Samba authentication subsystem.
More info needed Michael. What isn't complete ? Can you dump everything you know into this bug so we have a place to track please ? Jeremy.
Simple: The patch as it stands right now only works if wbinfo -a was done directly. The whole "map untrusted to domain" logic is flawed, we need to try our DC first and if it gave a non-authoritative error we need to fall back to the local SAM. Andrew Bartlett has taken over this task, see the private mail thread between Andrew and Steven.
Given the "half-a-loaf-is-better-than-none" meme, isn't this patch part of the way to a solution ? Is this in master yet ? Even with the restriction that it only works when wbinfo -a has been done, this is still an improvement on existing functionality (and there are some sites that run like this). Jeremy.
Created attachment 7321 [details] Patch for 3.6 For completeness, this is the patchset I have in production for 3.6 at a customer site. The last piece is the critical one that is not upstreamable right now. I really don't want to step on abartlet's toes who is actively working on this topic right now by just pushing it to master.
Comment on attachment 7321 [details] Patch for 3.6 The last patch in the series breaks stand-alone servers How about something like this for 3.6? # git di source3/auth/auth_util.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/source3/auth/auth_util.c b/source3/auth/auth_util.c index fbf730b..30e012b 100644 --- a/source3/auth/auth_util.c +++ b/source3/auth/auth_util.c @@ -120,7 +120,8 @@ NTSTATUS make_user_info_map(struct auth_usersupplied_info **user_info, * non-domain member box will also map to WORKSTATION\user. * This also deals with the client passing in a "" domain */ - if (!is_trusted_domain(domain) && + if (lp_server_role() == ROLE_STANDALONE && + !is_trusted_domain(domain) && !strequal(domain, my_sam_name())) { if (lp_map_untrusted_to_domain()) We definitely should redesign how trusted domains are handled, the trustdom cache does not seem to be the correct solution
Assigning to Andrew.. Andrew what should we do with this? The descussion about it recently popped up again...
https://irclog.samba.org/2012/04/20120428-Sat.log has some details on what needs to be done.
Volker, I think we should target this one again for 4.0 again. Let me prepare a new patchset (including the additional patches I have done to make template shell and so on work again)
(In reply to comment #11) > Volker, I think we should target this one again for 4.0 again. > > Let me prepare a new patchset (including the additional patches I have done to > make template shell and so on work again) Christian, are there any news on this one?
For my part, I never got the chance to pick up the ball on this one again. There are multiple parts to this challenge, but for the auth part, it isn't as simple in my view as just the changes in: [PATCH 8/8] s3: Do not map to SAM at all. Needs further testing I would have loved to get this fixed for 4.0, but it seems just too late at this point. I recommend this be for 4.1 - I'm very happy to pick up working on this with someone else. (I'll probably remain swamped with other things, and so working with someone will get this done faster). For the auth parts, what I want to do is catch the 'authoritative' flag on the NO_SUCH_USER reply from our DC, and transform that into (the behaviour of) NT_STATUS_NOT_IMPLEMENTED, so we fall back to the local domain in that case only.
changed my mind :) removed as blocker of 4.0 again, let's re-attack this for 4.x
(In reply to comment #14) > changed my mind :) > removed as blocker of 4.0 again, let's re-attack this for 4.x (In reply to comment #11) > Volker, I think we should target this one again for 4.0 again. > > Let me prepare a new patchset (including the additional patches I have done to > make template shell and so on work again) Ok, what other patches do you have here? I'm prepared to lend a hand.
Should this one be addressed with 4.1?
Created attachment 8960 [details] follow-up patches for 3.6 Instead of the last one in Volker's set, the following two patches can be used (that let stand-alone setups continue working and fix up template shell support)
Comment on attachment 8960 [details] follow-up patches for 3.6 Don't we need to call nss_get_info_cached() in order to fill homedir and shell?
(In reply to comment #18) > Comment on attachment 8960 [details] > follow-up patches for 3.6 > > Don't we need to call nss_get_info_cached() in order to fill homedir and shell? Ok, at that point (in the parent) it would be bad to call this...
(In reply to Stefan Metzmacher from comment #19) There're some improvements in 4.7, but I'm not sure if this is completely fixed...
Metze: I think this should be working now and the bug could be closed, right?
(In reply to Björn Jacke from comment #21) I don't know. The "map untrusted to domain" problem is gone. And everything should work, at least with a default configuration using just idmap autorid, but I'm not sure about about other setups with special setups using any LDAP based idmap backend. I'm also unsure regarding the "winbind nss info" interaction.
looks like we can close this as fixed.