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.
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......
Is there a tool to fix the algorithmic rid base? A manual edit of my ldap database would entail a lot of work.
(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.
John, could you please add your smb.conf file? Thanks!
Created attachment 3348 [details] smb.conf file. Example (real) smb.conf file.
Just wondering if there has been any followup on this bug. Is there anything I can do to help this one along? - John T.
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 ?
(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.
Note: These issues affect Samba 3.0.26-3.0.31 and 3.2.0+. - John T.
John, please open a separate bug for the algorithmic base issues.
(In reply to comment #10) > John, > please open a separate bug for the algorithmic base issues. > Will do.
Closing due to the level of code change since bug was reported. Will need to review this later in 3.3.x series.
(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?