Bug 9039 - 'map untrusted to domain' treats WORKSTATION as bogus domain
'map untrusted to domain' treats WORKSTATION as bogus domain
Product: Samba 3.5
Classification: Unclassified
Component: User & Group Accounts
All All
: P5 normal
: ---
Assigned To: Karolin Seeger
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2012-07-13 14:38 UTC by Daniel Kobras
Modified: 2013-03-04 09:27 UTC (History)
2 users (show)

See Also:

never try to map global SAM name (955 bytes, patch)
2012-07-13 14:38 UTC, Daniel Kobras
no flags Details
git-am fix that went into master (1.21 KB, patch)
2013-02-28 01:28 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Kobras 2012-07-13 14:38:21 UTC
Created attachment 7701 [details]
never try to map global SAM name

(I'm filing this bug against Samba 3.5.15 because that's the version I've actually tested. From reading the code, the report should also apply to current heads in v3-4-stable, v3-5-stable, and v3-6-stable.)

On member server in a Samba3 domain, we run setup where both local and domain users are able to log in. We also rely on the automated mapping of users from unknown domains to the local domain.

In this scenario, Samba 3.2 maps as follows on a member server WORKSTATION in domain DOMAIN:

  BOGUS\user1 -> DOMAIN\user1

Now we're trying to reproduce this behaviour in Samba 3.5.15. With the default of 'map untrusted to domain = no', we see the documented change of behaviour

  BOGUS\user1 -> WORKSTATION\user1

According to the docs, 'map untrusted to domain = yes' is meant to reinstate the 3.2 mapping behaviour, but instead we get

  BOGUS\user1 -> DOMAIN\user1
  WORKSTATION\user2 -> DOMAIN\user2

So WORKSTATION is now treated like an unknown/untrusted domain. This looks like an involuntary diversion from 3.2 behaviour to me (possibly related to commit dc3a90cf21813526854c12db126d08ebf32f8ae5, but I'm not sure if wb_is_trusted_domain() lists the same domains as wbinfo --trusted-domains). I'm also wary to change semantics of is_trusted_domain(), so I'm proposing the attached minimal patch to reinstate 3.2 mapping behaviour with 'map untrusted to domain = yes'. It was generated in v3-5-stable, but should apply to any 3.x branch since 3.4.
Comment 1 Jeremy Allison 2013-02-23 00:21:43 UTC
Absolutely correct! It's a side effect of commit dc3a90cf21813526854c12db126d08ebf32f8ae5 for sure.

The only other place this is used is in:

source3/rpc_server/netlogon/srv_netlog_nt.c where we have:

1666                 /* If we don't know what this domain is, we need to
1667                    indicate that we are not authoritative.  This
1668                    allows the client to decide if it needs to try
1669                    a local user.  Fix by jpjanosi@us.ibm.com, #2976 */
1670                 if ( NT_STATUS_EQUAL(status, NT_STATUS_NO_SUCH_USER)
1671                      && !strequal(nt_domain, get_global_sam_name())
1672                      && !is_trusted_domain(nt_domain) )
1673                         *r->out.authoritative = false; /* We are not authoritative */

Your change adds the same check. I'll get this reviewed and in master.


Comment 2 Jeremy Allison 2013-02-28 01:28:54 UTC
Created attachment 8595 [details]
git-am fix that went into master

NB. This patch already has 2 samba-team reviewers.
Comment 3 Jeremy Allison 2013-02-28 01:29:26 UTC
Re-assigning to Karolin for inclusion. This fix applies cleanly to 4.0.next and also 3.6.next.

Comment 4 Karolin Seeger 2013-03-01 15:41:16 UTC
Pushed to v3-6-test and autobuild-v4-0-test.
Comment 5 Karolin Seeger 2013-03-04 09:27:28 UTC
Pushed to v4-0-test.
Closing out bug report.