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.
(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
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.
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.
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!!!
Created attachment 4221 [details] fix: allows to change a machine sid add ability to change sid for machine accounts
I committed to master the attached patch, it depends on the patches attached to bug #6333