Bug 9039 - 'map untrusted to domain' treats WORKSTATION as bogus domain
Summary: 'map untrusted to domain' treats WORKSTATION as bogus domain
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.5
Classification: Unclassified
Component: User & Group Accounts (show other bugs)
Version: 3.5.15
Hardware: All All
: P5 normal
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-13 14:38 UTC by Daniel Kobras (dead mail address)
Modified: 2013-03-04 09:27 UTC (History)
2 users (show)

See Also:


Attachments
never try to map global SAM name (955 bytes, patch)
2012-07-13 14:38 UTC, Daniel Kobras (dead mail address)
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 (dead mail address) 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
  WORKSTATION\user2 -> WORKSTATION\user2

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
  WORKSTATION\user2 -> WORKSTATION\user2

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.

Thanks,

Jeremy.
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.

Jeremy.
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.

Thanks!