Bug 6081 - Pdbedit -U option does not work with machine accounts
Pdbedit -U option does not work with machine accounts
Status: RESOLVED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: User/Group Accounts
3.0.34
x86 Linux
: P3 major
: none
Assigned To: Simo Sorce
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-02 06:49 UTC by rvjcallanan
Modified: 2009-05-30 10:26 UTC (History)
0 users

See Also:


Attachments
Script to set next RID for a Samba PDC (357 bytes, text/plain)
2009-02-04 12:48 UTC, rvjcallanan
no flags Details
fix: allows to change a machine sid (9.23 KB, patch)
2009-05-30 10:26 UTC, Simo Sorce
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description rvjcallanan 2009-02-02 06:49:41 UTC
I refer to bug https://bugzilla.samba.org/show_bug.cgi?id=955

The somewhat optimistic response to this report was:
New design in 3.0.32.  Closing.

I have now installed the latest 3.0.34-37 Sernet RPM build for Redhat/CentOS 5
The problem is still there (at least with a tdbsam backend)

This is a serious issue as, by default, pdbedit generates RIDs starting at 1000 and incrementing indefinitely. There is no way to reset this sequence or pre-empt the next available RID. While I can force RIDs for user accounts, I am reduced to accepting this default behaviour for machine accounts.

The background to all of this is that I prefer to use 1-to-1 Host UID to RID mappings and have divided UIDs/RIDs into ranges to avoid conflicts. It would be great to have a global smb.conf directive to force 1-to-1 mappings for new accounts - it would make life much easier for the many folks that take this approach.
Comment 1 Francis Kelly 2009-02-02 12:54:30 UTC
(In reply to comment #0)
> I refer to bug https://bugzilla.samba.org/show_bug.cgi?id=955
> 
> The somewhat optimistic response to this report was:
> New design in 3.0.32.  Closing.
> 
> I have now installed the latest 3.0.34-37 Sernet RPM build for Redhat/CentOS 5
> The problem is still there (at least with a tdbsam backend)
> 
> This is a serious issue as, by default, pdbedit generates RIDs starting at 1000
> and incrementing indefinitely. There is no way to reset this sequence or
> pre-empt the next available RID. While I can force RIDs for user accounts, I am
> reduced to accepting this default behaviour for machine accounts.
> 
> The background to all of this is that I prefer to use 1-to-1 Host UID to RID
> mappings and have divided UIDs/RIDs into ranges to avoid conflicts. It would be
> great to have a global smb.conf directive to force 1-to-1 mappings for new
> accounts - it would make life much easier for the many folks that take this
> approach.
> 

Happens with me too!
There seems to be a number of serious issues with pdbedit e.g.
https://bugzilla.samba.org/show_bug.cgi?id=2965

Also, if you try to modify a previously added machine or user account RID using -U option, it seems to work BUT corrupts the database evidenced by strange error messages appearing afterwards from time to time.

Please do not tell me that Samba has grown so much with Winbind, LDAP support etc that the basic tdbsam backend and pdbedit have fallen into dis-repair.

It would be great if somebody with experience of pdbedit code could take some time to get it to a reasonable state of functionality/reliability. I am more than willing to help with testing as it is still the cornerstone of many Samba installations.

TIA
Comment 2 rvjcallanan 2009-02-03 15:51:55 UTC
On further investigation, I agree with Francis. If I do a bug search with keyword "pdbedit", the results give me the distinct impression that this area is not receiving the attention it deserves. I too am willing to help out on the testing side to help sort out these niggles.
Comment 3 rvjcallanan 2009-02-04 12:48:58 UTC
Created attachment 3913 [details]
Script to set next RID for a Samba PDC

This script sets the next RID for a Samba PDC using tdbsam backend allowing administrator to control allocation of RIDs. Suitable for stand-alone PDC only using tdbsam backend. You may need to change the path to the RID_COUNTER trivial database file as the path and filename are likely to change between Samba versions.
Comment 4 rvjcallanan 2009-02-04 13:12:46 UTC
I have posted a setrid script that allows the Samba administrator to control the next RID that will be allocated by Samba. I think it's a pretty safe workaround at least in the context of a standalone PDC using a tdbsam backend. I would not use this approach in more complex scenarios

This script changes the RID_COUNTER in the winbindd_idmap.tdb file to the desired value. It does seems weird that the Samba developers have placed the RID counter in this file as I'm using the tdbsam backend and am not using winbind. This fact alone may be indicative of a need to take a long hard look at some of this code.

If you execute this script prior to issuing your pdbedit command, you will get the result you desire e.g.

setrid 6000
pdbedit -a -m hp01

You will notice that the new machine account will have an RID of 6000. 
If 6000 was already taken, pdbedit will increment until it finds a free RID, so you need to take care of clashes yourself.

This is a workaround - not a fix!!!
Comment 5 Simo Sorce 2009-05-30 10:26:00 UTC
Created attachment 4221 [details]
fix: allows to change a machine sid

add ability to change sid for machine accounts
Comment 6 Simo Sorce 2009-05-30 10:26:55 UTC
I committed to master the attached patch, it depends on the patches attached to bug #6333