Bug 4801 - LSA lookup names does not handle lookup level 2 - 6
LSA lookup names does not handle lookup level 2 - 6
Status: RESOLVED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: Domain Control
3.0.25b
Other Linux
: P3 regression
: none
Assigned To: Michael Adam
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-19 09:03 UTC by John Janosik
Modified: 2009-05-17 17:48 UTC (History)
4 users (show)

See Also:


Attachments
Patch to 3.0.28 (7.11 KB, patch)
2007-12-13 04:06 UTC, Michael Adam
no flags Details
Addon patch correcting callers of lookup_name(). (5.77 KB, patch)
2007-12-17 06:50 UTC, Michael Adam
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description John Janosik 2007-07-19 09:03:42 UTC
After upgrading our Samba DCs from 3.0.20c to 3.0.25b we started getting DB2 authentication errors for IDs in the samba domain made from a windows member server in a trusted Active Directory domain.  The cause is that the AD DC is making an lsa lookup names 2 rpc to the Samba domain with the lookup level set to 3.  DB2 is not specifying the domain name of the user so the AD DC also does not specify the domain in the lookup names 2 rpc.

In rpc_server/srv_lsa_nt.c:_lsa_lookup_names2 the flags passed to passdb/lookup_sid.c:lookup_name() are left as zero unless the lookup level is set to 1.  It seems there needs to be more granular control over the behavior in passdb/lookup_sid.c:lookup_name() for the different lookup levels.

From the Samba4 code:
<jmcd>  /* Level 1: Ask everywhere
<jmcd>   * Level 2: Ask domain and trusted domains, no builtin and wkn
<jmcd>   * Level 3: Only ask domain
<jmcd>   * Level 4: W2k3ad: Only ask AD trusts
<jmcd>   * Level 5: Only ask transitive forest trusts
<jmcd>   * Level 6: Like 4

We can't upgrade to 3.0.25b until at least lookup level 3 is handled properly.
Comment 1 Michael Adam 2007-11-30 08:38:24 UTC
I am working on a fix for this one.
Comment 2 Michael Adam 2007-12-13 04:01:54 UTC
I have pushed a first fix for this upstream 
to v3-0-test (120f2c05a36a59fe6829cc73f20c269ffef134ad and 821de8a047eea10fefb0851792a9e4633c16d871)
and v3-2-test (dd320c0924ce393a89b1cab020fd5cffc5b80380 and 537b12647e25adcb7da3581f18d2e9feca1caf0c).

What is not implemented yet is the traversal of trusted domains by winbindd, when asked for an unqualified domain, that can not be locally resolved.

Michael
Comment 3 Michael Adam 2007-12-13 04:06:55 UTC
Created attachment 3045 [details]
Patch to 3.0.28

Attached find a patch agains 3.0.28.                                                  
This also applies to 3.0.25, 3.0.26, ...
Comment 4 Michael Adam 2007-12-17 02:19:36 UTC
Patch needs more testing for v3-2-test: It breaks "make test" and has been reverted.
Comment 5 Michael Adam 2007-12-17 06:49:25 UTC
Fix has been submitted to v3-2-test again, along with corrections that remedy make test. Corrections have also gone to v3-0-test.

The problem was that the flags that some direct caller of lookup_name() were passing in, were not correct according to the new, more strict interpretation...

Cheers, Michael
Comment 6 Michael Adam 2007-12-17 06:50:18 UTC
Created attachment 3048 [details]
Addon patch correcting callers of lookup_name().
Comment 7 Michael Adam 2008-03-20 17:15:07 UTC
Any test results on this one?

I think except for the one mentioned point (traversal of trusted domains by winbindd, when asked for an unqualified domain that can not be locally resolved) this should be ok now. That point is on the one hand side somewhat complicated to implement, since a decent async mechanism has to be used, and on the other hand in practice not very important.

Comments?

Cheers, Michael
Comment 8 Michael Adam 2009-05-17 17:48:02 UTC
Since there were no complaints any more since more than a year,
I am closing this bug as fixed.

Please feel free to re-open, if problems persist.

Michael