samba - Aug 2010 - Domain admin privileges: a strange bug in Samba?

I was in the process of setting up a new Samba 3.5.4 PDC with LDAP 
backend, over CentOS 5.5, when I came across a very strange behavior.

After executing the smbladp-populate script, I was trying to grant the 
needed privileges to the group "Domain Admins" in order no to use
"root"
to manage the Windows domain. After successfully granting rights to the 
"Admin" user, there was no way to make this user benefit from them.
Even
the command "net rpc rights list", if executed by -U Admin, always 
failed with the following result:

net rpc rights list Admin -U Admin

Enter Admin's password:
(I enter "Admin's password here")
Receiving SMB: Server stopped responding
Could not connect to server 127.0.0.1
Connection failed: NT_STATUS_END_OF_FILE

This was followed by a smb core dump.

The log then presents the following:

[2010/08/24 11:27:00.143535,  0] lib/fault.c:46(fault_report)
   ==============================================================[2010/08/24
11:27:00.143824,  0] lib/fault.c:47(fault_report)
   INTERNAL ERROR: Signal 11 in pid 19667 (3.5.4)
   Please read the Trouble-Shooting section of the Samba3-HOWTO
[2010/08/24 11:27:00.143927,  0] lib/fault.c:49(fault_report)

   From: http://www.samba.org/samba/docs/Samba3-HOWTO.pdf
[2010/08/24 11:27:00.144021,  0] lib/fault.c:50(fault_report)
   ==============================================================[2010/08/24
11:27:00.144100,  0] lib/util.c:1465(smb_panic)
   PANIC (pid 19667): internal error
[2010/08/24 11:27:00.151658,  0] lib/util.c:1569(log_stack_trace)
   BACKTRACE: 26 stack frames:
    #0 smbd(log_stack_trace+0x1a) [0x2ae9fd7622c5]
    #1 smbd(smb_panic+0x55) [0x2ae9fd7623c9]
    #2 smbd [0x2ae9fd753101]
    #3 /lib64/libc.so.6 [0x2aea005cf2d0]
    #4 smbd(sid_compare+0x22) [0x2ae9fd75db54]
    #5 smbd(add_sid_to_array_unique+0x39) [0x2ae9fd75e189]
    #6 smbd(create_token_from_username+0xd37) [0x2ae9fd7b1eeb]
    #7 smbd(create_local_token+0x4e) [0x2ae9fd7b231e]
    #8 smbd [0x2ae9fd7b550d]
    #9 smbd [0x2ae9fd5b8097]
    #10 smbd(ntlmssp_update+0x270) [0x2ae9fd5b7c86]
    #11 smbd(auth_ntlmssp_update+0x17) [0x2ae9fd7b5215]
    #12 smbd [0x2ae9fd52be5e]
    #13 smbd(reply_sesssetup_and_X+0x191) [0x2ae9fd52c18f]
    #14 smbd [0x2ae9fd560eb1]
    #15 smbd [0x2ae9fd563b4e]
    #16 smbd [0x2ae9fd564341]
    #17 smbd(run_events+0x1d6) [0x2ae9fd7711f8]
    #18 smbd(smbd_process+0x97c) [0x2ae9fd56337d]
    #19 smbd [0x2ae9fda6f4ca]
    #20 smbd(run_events+0x1d6) [0x2ae9fd7711f8]
    #21 smbd [0x2ae9fd771467]
    #22 smbd(_tevent_loop_once+0x84) [0x2ae9fd7717e9]
    #23 smbd(main+0xf83) [0x2ae9fda6f1ff]
    #24 /lib64/libc.so.6(__libc_start_main+0xf4) [0x2aea005bc994]
    #25 smbd [0x2ae9fd4ea5a9]
[2010/08/24 11:27:00.159996,  0] lib/fault.c:326(dump_core)
   dumping core in /var/log/samba/cores/smbd


Only "root" could obtain a successful answer, even if I gave
"Admin" the
same password that "root" has.

After many efforts I was stuck. I even downgraded to Samba 3.4.8 with 
the same result.

I then raised the log level to 2.

Suddenly, the results came:

SeMachineAccountPrivilege
SeTakeOwnershipPrivilege
SeBackupPrivilege
SeRestorePrivilege
SeRemoteShutdownPrivilege
SePrintOperatorPrivilege
SeAddUsersPrivilege
SeDiskOperatorPrivilege

I consulted the Samba logs and noticed the following:

[2010/08/24 11:00:23.397276,  2] auth/auth.c:304(check_ntlm_password)
   check_ntlm_password:  authentication for user [Admin] -> [root] -> 
[root] succeeded
[2010/08/24 11:00:23.397973,  2] passdb/pdb_ldap.c:572(init_sam_from_ldap)
   init_sam_from_ldap: Entry found for user: root

So, user Admin was being mapped to root, and this only worked if Admin 
had the same password as "root", as expected.

Since "username map = /etc/samba/smbusers" is the Samba default, I 
commented all the lines in /etc/samba/smbusers.

Now, the correct behavior was restored.

What is most strange here is that *the success of the connection depends 
on the log level being 2 or higher*. Everything less causes the 
connection to fail with the result:

Receiving SMB: Server stopped responding
Could not connect to server 127.0.0.1
Connection failed: NT_STATUS_END_OF_FILE


With all the lines commented out in /etc/samba/smbusers, privileges work 
as expected.

Thank you.

This raises the following question:

With the privileges system in place, isn't the use of the "username map
= /etc/samba/smbusers" somewhat of a historical relic?

Perhaps the "username map" default should be changed to "no
value". It
could then be used if needed by some users but the current default 
wouldn't upset the normal operation of other, more needed functions.