Patch submission version 4

Rowland Penny repenny241155 at
Mon Dec 2 06:30:57 MST 2013

On 02/12/13 10:56, Jelmer Vernooij wrote:
> On Mon, Dec 02, 2013 at 08:58:51AM +0000, Rowland Penny wrote:
>> On 01/12/13 22:59, Jelmer Vernooij wrote:
>>> On Sun, Dec 01, 2013 at 09:36:10PM +0000, Rowland Penny wrote:
>>>> On 01/12/13 20:51, Andrew Bartlett wrote:
>>>>> On Wed, 2013-10-09 at 11:35 +0100, Rowland Penny wrote:
>>>>>> HI, I will say this once again, anything Samba does to the AD database
>>>>>> should match what Windows does.
>>>>>> Windows does NOT add either the 'posixAccount' or 'posixGroup'
>>>>>> attributes so Stephanes patch should not add this line:
>>>>>> +            ldbmessage2["objectClass"] =
>>>>>> ldb.MessageElement('posixGroup', ldb.FLAG_MOD_ADD, 'objectClass')
>>>>>> it should be removing this line:
>>>>>>                ldbmessage2["objectClass"] =
>>>>>> ldb.MessageElement('posixAccount', ldb.FLAG_MOD_ADD, 'objectClass')
>>>>> For the time-being, I'm going to accept being consistent with the
>>>>> existing code over making this change to the old code, in a patch series
>>>>> that is adding new functionality.
>>>> Just because something was created wrong in the first place is not a
>>>> good reason for continuing the error, all I am asking is that the
>>>> totally un-needed posix objectclasses are removed from samba-tool.
>>>> posixAccount and posixShadow are both auxillaries of the 'users'
>>>> objectclass, posixGroup is the auxillary of the 'group' objectclass.
>>>> What this means is that the 'user' & 'group' objectclasses inherit
>>>> all the attributes from the posix objectclasses, this is why windows
>>>> does not add the objectclasses 'posixAccount' & 'posixGroup'.
>>>> You would not even need any tests for the removal of these
>>>> objectclasses, I mean how do you test for something that should not
>>>> be there, if you test for the attributes the posix objectclasses
>>>> hold, they can still be there.
>>>> As a last thought, if you insist on allowing the adding of the posix
>>>> objectclasses then you should stop recommending the use of ADUC or
>>>> any windows tools to add users & groups, because no windows tools
>>>> will add the posix objectclasses.
>>> samba-tool is not the Samba equivalent of ADUC. They have a different
>>> UI. They can both add users and groups to an Active Directory domain
>>> among other things - but they can each also do much, much more that
>>> the other can't.
>>> It makes sense to be consistent with ADUC where that is
>>> reasonable, as more consistency will lead to more predictable
>>> behaviour and thus less confusion for users.
>>> We can consider adding an option (--posix?) that enables the
>>> the posixGroup objectClass, and have that option disabled by default.
>>> I don't have a strong opinion about what the default should be.
>>> Addressing that is outside of the scope of Stephane's patch.
>>> There is nothing fundamentally wrong with samba-tool having
>>> the ability to add posix{Account,Group} objectClasses, just like it
>>> can already do so many other things that ADUC can't.
>> Why would you need the posix objectClasses?
>> I was of the opinion that the whole idea behind Samba 4 was to
>> create a clone of a windows AD server. If this is correct then the
>> samba tools should work basically in the same way as ADUC.
> Samba 4 is an implementation of Active Directory. It is not a Windows AD
> server "clone". The architecture is different, the tools around it are different
> and the platforms it runs on are different. Integration with
> existing POSIX systems is one of the strengths of Samba.
Now you are arguing about words, by clone I meant it is supposed to work 
in the same way as an active directory server, doesn't 'implementation 
of Active Directory' mean the same?
I also agree that S4 in AD mode needs to integrate with POSIX systems 
but in the same that windows AD does, you cannot add anything to AD that 
windows does not, if you do, it is no longer an implementation of AD.

>> Let us take the case of a site that uses both Linux and windows
>> users and has two admins, Bill & Ben. Bill always uses Linux to
>> administrate the domain, Ben always uses ADUC.
>> Bill sets up the Linux part and creates all the Linux users with
>> samba-tool and they can connect to the domain.
>> Everything goes great until Bill is away from work and Ben has to
>> create a group of linux users, he of course uses ADUC, Ben is then
>> called away and when he comes back, he finds that non of the new
>> Linux users he created can log into any Linux machines. This is
>> traced to the fact that when Bill set up the Linux machines, he
>> relied on the posix objectClasses that samba-tool adds and ADUC
>> doesn't.
> What if there were two Linux admins that both created users and only one
> was aware of the complex process for creating users that didn't
> add posixAccount by default?
This is why samba-tool should not add the POSIX objectClasses
> It would be good to not surprise users. There are more
> ways in which we can do this; removing the functionality is one,
> and not the ideal as it makes most users' lives harder
Just how will it make users lives harder by not adding the POSIX 
objectClasses? every one of the POSIX objectClass Attributes will still 
be available, or do you not understand how auxiliary classes work in AD?


> Cheers,
> Jelmer

More information about the samba-technical mailing list