Bug 5535 - Conflicting RID creation - Affects all version from 3.0.23 including 3.2.x series.
Summary: Conflicting RID creation - Affects all version from 3.0.23 including 3.2.x se...
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: User/Group Accounts (show other bugs)
Version: 3.0.30
Hardware: Other Linux
: P3 normal
Target Milestone: none
Assignee: Simo Sorce
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-10 22:39 UTC by John H Terpstra (mail address dead(
Modified: 2009-04-22 05:19 UTC (History)
4 users (show)

See Also:


Attachments
smb.conf file. (3.43 KB, text/plain)
2008-06-17 07:18 UTC, John H Terpstra (mail address dead(
no flags Details
Fix user creation and make it consistent across all code paths (957 bytes, patch)
2008-07-12 21:51 UTC, Simo Sorce
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description John H Terpstra (mail address dead( 2008-06-10 22:39:28 UTC
When a sambaSAM account (in LDAPsam backend) is created for a user the RID that we use is inconsistently derived depending on the tool used to add the account.

How to reproduce the example:

1) Add the POSIX user account to the LDAP directory using your method of choice
In my example the user account for "joe" has (getent passwd joe):
joe:x:1795:513:System User:/data/users/joe:/bin/bash

2) Add the sambaSAM account info by executing: smbpasswd -a joe

3) pdbedit -Lv joe
merlin:~ # pdbedit -Lv joe
Unix username:        joe
NT username:          joe
Account Flags:        [U          ]
User SID:             S-1-5-21-726309263-4128913605-1168186429-4590
Primary Group SID:    S-1-5-21-726309263-4128913605-1168186429-513
Full Name:            System User
Home Directory:       \\merlin\joe
HomeDir Drive:        H:
Logon Script:         scripts\logon.bat
Profile Path:         \\merlin\profiles\joe
Domain:               MIDEARTH
Account desc:
Workstations:
Munged dial:
Logon time:           0
Logoff time:          never
Kickoff time:         never
Password last set:    Tue, 10 Jun 2008 21:56:20 CDT
Password can change:  Tue, 10 Jun 2008 21:56:20 CDT
Password must change: Sun, 07 Dec 2008 20:56:20 CST
Last bad password   : 0
Bad password count  : 0
Logon hours         : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF


4) Now remove the sambaSAM account by executing: smbpasswd -x joe

5) Now add the sambaSAM account by executing: net rpc user add joe

6) pdbedit -Lv joe
Unix username:        joe
NT username:          joe
Account Flags:        [DU         ]
User SID:             S-1-5-21-726309263-4128913605-1168186429-401064
Primary Group SID:    S-1-5-21-726309263-4128913605-1168186429-513
Full Name:            System User
Home Directory:       \\merlin\joe
HomeDir Drive:        H:
Logon Script:         scripts\logon.bat
Profile Path:         \\merlin\profiles\joe
Domain:               MIDEARTH
Account desc:
Workstations:
Munged dial:
Logon time:           0
Logoff time:          never
Kickoff time:         never
Password last set:    0
Password can change:  0
Password must change: 0
Last bad password   : 0
Bad password count  : 0
Logon hours         : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF


5) Please note that the RID when using "smbpasswd -a joe" is equal to:
RID = UID*2 + RID_base

6) Please note that the RID when using "net rpc user add joe" is equal to the value of the undocumented sambaNextRid value that is stored under the sambaDomainName=DOMAIN entry in LDAP. The sambaNextRid is incremented after adding the account.


7) When adding a machine account from the Windows client the sambaNextRid is used.

8) When adding a machine account using: smbpasswd -a -m machine_name, RID = UID*2 + RID_base.


9) These are examples of inconsistent behavior.  The minimum action we must take is to document the behavior.

10) We must also provide a tool to query (get) and set the value of sambaNextRid.  If we do not do this, what level of warning should be documented to advise our samba admins what they MUST do to avoid creation of conflicting RIDs?

Since the default behavior is to start with sambaNextRid = 0, and then increment it; and since the RID = sambaNextRid, the first RID will be 1000 - the very value that will exist for the first account that was created under Windows NT and then imported into Samba's ldapsam.

Please let me know how we want this documented. Thanks.

11) Change the value of sambaAlgorithmicRidBase in the SambaDomainName account, and then execute: pdbedit -Lw
The value of 'algorithmic RID base' has changed since the LDAP
database was initialised.  Aborting.
pdb backend ldapsam:ldap://merlin.terpstra-world.org did not correctly init (error was NT_STATUS_UNSUCCESSFUL)
PANIC (pid 2045): pdb_get_methods_reload: failed to get pdb methods for backend ldapsam:ldap://merlin.terpstra-world.org

BACKTRACE: 7 stack frames:
 #0 pdbedit(log_stack_trace+0x1c) [0x5555555e033c]
 #1 pdbedit(smb_panic+0x43) [0x5555555e0423]
 #2 pdbedit [0x55555559adf7]
 #3 pdbedit(initialize_password_db+0x9) [0x55555559ae29]
 #4 pdbedit(main+0x105) [0x5555555867c5]
 #5 /lib64/libc.so.6(__libc_start_main+0xf4) [0x2ae1a7962b54]
 #6 pdbedit [0x5555555854f9]
smb_panic(): calling panic action [/bin/sleep 90000]
smb_panic(): action returned status 0
Aborted

12) Do NOT change the value of sambaAlgorithmicRidBase in the SambaDomainName record, but just insert into smb.conf [globals]:
   algorithmic rid base = 7000

13) Now execute: pdbedit -Lw
The value of 'algorithmic RID base' has changed since the LDAP
database was initialised.  Aborting.
pdb backend ldapsam:ldap://merlin.terpstra-world.org did not correctly init (error was NT_STATUS_UNSUCCESSFUL)
PANIC (pid 2309): pdb_get_methods_reload: failed to get pdb methods for backend ldapsam:ldap://merlin.terpstra-world.org

BACKTRACE: 7 stack frames:
 #0 pdbedit(log_stack_trace+0x1c) [0x5555555e033c]
 #1 pdbedit(smb_panic+0x43) [0x5555555e0423]
 #2 pdbedit [0x55555559adf7]
 #3 pdbedit(initialize_password_db+0x9) [0x55555559ae29]
 #4 pdbedit(main+0x105) [0x5555555867c5]
 #5 /lib64/libc.so.6(__libc_start_main+0xf4) [0x2b77140fbb54]
 #6 pdbedit [0x5555555854f9]
smb_panic(): calling panic action [/bin/sleep 90000]


So, unless I have messed up, this is another bug we ought to fix. Correct?


- John T.
Comment 1 Douglas Sterner 2008-06-12 13:17:20 UTC
so this is why my user accounts are so hosed up. Any chance we could fix this before releasing more versions. I'm experiencing this exact situation on my large enterprise network. I know I left that windows CD somewhere......
Comment 2 Douglas Sterner 2008-06-12 13:23:56 UTC
Is there a tool to fix the algorithmic rid base? A manual edit of my ldap database would entail a lot of work.
Comment 3 John H Terpstra (mail address dead( 2008-06-12 13:37:58 UTC
(In reply to comment #2)
> Is there a tool to fix the algorithmic rid base? A manual edit of my ldap
> database would entail a lot of work.
> 

Thanks for the feedback, we do understand that this may be inconvenient, but we need time to address this.

It is not possible to change it on a running system.  If you edit the algorithmic rid base using an LDAP editor, tools such as pdbedit will crash.

Setting the "algorithmic rid base" parameter in smb.conf will not result in the value of sambaAlgorithmicRidBase being updated in the sambaDomainName="your_domain" record in LDAP.  In fact, it will cause pdbedit to crash.

There should be a way to edit the value of the "algorithmic rid base" and the sambaNextRid value without requiring major surgery to the whole Samba installation.

Please give the assigned Samba team member time to respond to this bug report.  I will document this in the HOWTO when we have reached a concensus on this report.
Comment 4 Karolin Seeger 2008-06-17 03:13:34 UTC
John, could you please add your smb.conf file?

Thanks!
Comment 5 John H Terpstra (mail address dead( 2008-06-17 07:18:28 UTC
Created attachment 3348 [details]
smb.conf file.

Example (real) smb.conf file.
Comment 6 John H Terpstra (mail address dead( 2008-07-07 13:16:18 UTC
Just wondering if there has been any followup on this bug.  Is there anything I can do to help this one along?

- John T.
Comment 7 Simo Sorce 2008-07-12 21:51:49 UTC
Created attachment 3405 [details]
Fix user creation and make it consistent across all code paths

The attacched patch should fix the inconsistent behavior of smbpasswd -a and make it consistent with pdbedit -a and net rpc user add
Can you test it and report back ?
Comment 8 John H Terpstra (mail address dead( 2008-07-22 19:32:11 UTC
(In reply to comment #7)
> Created an attachment (id=3405) [edit]
> Fix user creation and make it consistent across all code paths
> 
> The attacched patch should fix the inconsistent behavior of smbpasswd -a and
> make it consistent with pdbedit -a and net rpc user add
> Can you test it and report back ?
> 

Simo,

This patch is good to go in. It does indeed make user addition via smbpasswd, pdbedit and "net rpc user add" all work the same way.  I recommend that this patch should be applied to 3.0.31+, 3.2.1+ and 3.3+.

Should I file a new bug report for the remaining issues reported in 5535?  We still have no way to querry or set the SambaNextRID value.  

Also, after a Samba server using LDAP has been setup it is not possible to change the "algorithmic rid base" in smb.conf, or to change the LDAP sambaAlgorithmicRidBase object value in the SambaDomainName container.  In any of these cases Samba's tools will segfault.

Thanks.
- John T.
Comment 9 John H Terpstra (mail address dead( 2008-07-22 19:33:42 UTC
Note:

These issues affect Samba 3.0.26-3.0.31 and 3.2.0+.

- John T.
Comment 10 Simo Sorce 2008-07-23 09:49:55 UTC
John,
please open a separate bug for the algorithmic base issues.
Comment 11 John H Terpstra (mail address dead( 2008-07-23 12:02:13 UTC
(In reply to comment #10)
> John,
> please open a separate bug for the algorithmic base issues.
> 

Will do.
Comment 12 John H Terpstra (mail address dead( 2009-01-21 09:36:40 UTC
Closing due to the level of code change since bug was reported. Will need to review this later in 3.3.x series.
Comment 13 Christian Setzer 2009-04-22 05:19:55 UTC
(In reply to comment #12)
> Closing due to the level of code change since bug was reported. Will need to
> review this later in 3.3.x series.
> 

is this fixed in 3.3?