Bug 5391 - make ldapsam easier to set up right and its problems easier to debug
make ldapsam easier to set up right and its problems easier to debug
Product: Samba 3.0
Classification: Unclassified
Component: User/Group Accounts
x86 Linux
: P3 major
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2008-04-12 09:17 UTC by Josip Rodin
Modified: 2017-01-16 22:57 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Josip Rodin 2008-04-12 09:17:37 UTC
It appears that once you set a Samba server to be a primary domain
controller that authenticates via a back-end LDAP server, it can no longer
serve as a meaningful file server, because the 'valid users' setting
simply doesn't work any more. It works on the normal Sambas which are
set to use 'security = domain' with the Samba PDC, but not on the
controller itself, for some reason.

This behaviour may not be a bug in itself (I don't have any idea about the
motivation, I suppose it could be sensible), but it is not documented in
the manual page or the HOWTO, and the code doesn't warn me that the
'valid users' setting was ignored intentionally (if it has). It allows for
information disclosure (shares that are accessible to the wrong users,
even though you set them not to be), so it's a security problem, really.

I've posted some extra debugging info at http://bugs.debian.org/474108
but I've only come as far as determining that my username somehow magically appears in the 'valid users' data structure, I haven't had the time to investigate further (I just moved the PDC functionality to a server which doesn't have critical shares so that my users' data is safe).

The smbd.conf at the PDC has these extra settings:

   workgroup = FOO
   domain logons = yes
   domain master = yes
   passdb backend = ldapsam:"ldap://ldap1.foo.hr ldap://ldap2.foo.hr"
   ldap suffix = dc=foo,dc=hr  
   ldap user suffix = ou=users
   ldap group suffix = ou=groups
   ldap machine suffix = ou=machines
   ldap admin dn = cn=admin,dc=foo,dc=hr
   ldap delete dn = no

I think that's it. The share on it, to which I should not have access, looks like this:

  comment = Nagios test
  path = /tmp
  browsable = no
  writable = no
  printable = no
  public = no
  guest ok = no
  valid users = nagios

And this happens:

% smbclient -W FOO -U joy //thepdc/nagios
Password: [wrong password entered]
session setup failed: NT_STATUS_LOGON_FAILURE
% smbclient -W FOO -U joy //thepdc/nagios
Password: [correct password entered]
Domain=[IMAGO] OS=[Unix] Server=[Samba 3.0.24]
smb: \> 

So it authenticates, but it doesn't authorize properly... do you want the detailed logs, which log level?
Comment 1 Josip Rodin 2009-06-27 17:42:51 UTC
In the meantime I upgraded the entire domain to the newer Samba 3.2 - it was
painful in the process because the old 3.0 servers started somehow applying
new access logic towards the first 3.2 BDC and users complained about not
being able to access. The new Samba, however, had considerably more useful
logs and based on reading them I think I found the original problem:

My users had something like this in LDAP:

dn: cn=Pero Peric,ou=users,dc=imago,dc=hr
uid: pperic
sambaSID: S-1-5-21-145766654-2861277506-3272706772-
sambaPrimaryGroupSID: S-1-5-21-145766654-2861277506-3272706772-513

As it turns out, this was a blatant lack of understanding of what the
sambaSID field is supposed to be - a unique identifier of the *user* object,
*NOT* simply a pointer to the unique identifier of the domain object.
This faulty mapping seemed to cause the Samba servers to think that all
users had all the privileges of the root object, probably related to the
fact that I had a cn=root user in LDAP with sambaSID
S-1-5-21-145766654-2861277506-3272706772-0 - I no longer have the exact
logs to demonstrate, sorry. In particular this new debugging helped me:

[2009/06/12 10:48:43,  3] lib/util_seaccess.c:se_access_check(252)
  se_access_check: user sid is S-1-5-21-145766654-2861277506-3272706772-1001000
  se_access_check: also S-1-22-2-1000
  se_access_check: also S-1-1-0
  se_access_check: also S-1-5-2
  se_access_check: also S-1-5-11
  se_access_check: also S-1-22-2-4
  se_access_check: also S-1-22-2-20
  se_access_check: also S-1-22-2-24
  se_access_check: also S-1-22-2-25
  se_access_check: also S-1-22-2-29
  se_access_check: also S-1-22-2-40
  se_access_check: also S-1-22-2-44
  se_access_check: also S-1-22-2-46
  se_access_check: also S-1-22-2-100
  se_access_check: also S-1-22-2-2000

(This is from a current, fixed session... hopefully! :)

The origin of this mistake was in the blatant inadequacy of the Samba
documentation. After some more Googling, I found this very helpful page:


From there I was able to infer exactly where my LDAP data was faulty,
and what I needed to fix in order to get Samba working properly.

Now I rechecked the official HOWTO, and I see something like that in
chapter 11 "Account Information Databases", section "Password Backends -
ldapsam". This absolutely needs to be better integrated. For example,
the chapter 4 "Domain Control" has very few references to LDAP at all;
the chapter 5 "Backup Domain Control" surprisingly does have a few
references to LDAP (which are out of place, really), but no actual links
to the ldapsam description in chapter 11.

So in conclusion, for this bug to be properly closed, I think it would be
good to have two things:
* more explicit warnings in code that interprets sambaSID entries
  in order to help debug broken ldapsam backends
* more cross-references between the documentation sections in order
  to help the reader in actually finding the proper information
Comment 2 Karolin Seeger 2009-12-11 09:05:20 UTC
Closing out bug report.

Comment 3 Josip Rodin 2009-12-11 13:28:36 UTC
How is this fixed again?
Comment 4 Josip Rodin 2011-03-12 19:01:57 UTC
(In reply to comment #2)
> Closing out bug report.
> Thanks!

I stated explicitly what still needs to be fixed and it was not contested, but the bug was marked as "resolved" with this. I'm undoing that now as it was apparently a mistake.

For example, I quoted lib/util_seaccess.c messages that were necessary to
see in order to debug these problems. That file doesn't even have a custom
DBGC_CLASS defined in 3.2.5 that I had last checked. I now checked
3.5.6 and in its source3/lib/util_seaccess.c the situation
is unchanged. That means that to see level 3 debug messages generated from
that file, you have to turn the *general* log level to 3 or more.

And do you know what that does to a person? :) The vgrep becomes painful
because of the other level 3 debug messages from everywhere else,
the likes of:

  init_oplocks: initializing messages.
  Linux kernel oplocks enabled

  Transaction 0 of length 194 (0 toread)
  switch message SMBnegprot (pid 14015) conn 0x0
  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0

  call_trans2findfirst: dirtype = 16, maxentries = 1366, close_after_first=1, close_if_end = 1 requires_resume_key = 1 level = 0x104, max_data_bytes = 16384
  creating new dirptr 256 for path ./, expect_close = 1

And the list goes on and on. It's simply not debugging the authentication
process any more, it's a huge mess.

Please make a modicum of effort to make these Samba problems not horribly
difficult to debug, and that will actually resolve the issue.
Comment 6 Björn Jacke 2017-01-16 21:26:38 UTC
if you have specific documentation patches to propose please send them to the samba mailing list. "Something is hard to debug" or "Documention in gerneal is not easy to read" or so is useful bug report. This bug will be closed, please don't reopen it. If you have specific documentation patches to propose please send them to the samba mailing list (or contribute to the samba wiki).
Comment 7 Josip Rodin 2017-01-16 22:57:46 UTC
If you want people to do more work, ignoring specific suggestions for nine years and then pretending they're not specific enough, is not useful. In fact, it is quite reprehensible, and will serve as a supremely shameful example.