Patch submission version 4

[Rowland Penny]

On 02/12/13 21:54, Jelmer Vernooij wrote:
> On Mon, Dec 02, 2013 at 01:30:57PM +0000, Rowland Penny wrote:
>> 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?
> It is a fundamental difference. A clone is nothing more than a copy of
> the original. It provides not just the same interface (e.g. network
> protocols/API) but has the same implementation too.
>
> Samba 4 and Windows AD DCs merely implement the same network
> protocols - and they both support other protocols that the other
> doesn't. That's where the similarities end.
Look, the whole idea of samba 4 was to provide an open source version of 
windows active directory and to take the place of an existing AD server, 
it hasn't quite got there yet but it is well on its way. No matter what 
you call it, clone or implementation, you know what I meant.


>
>> 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.
> I don't agree with that, so long as it does not interfere with AD.
I cannot disagree with that statement, but why add something that isn't 
needed?

>
>>> 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?
> Because a fair number will have to manually add the objectClasses
> later, outside of Samba.
Why? as far as I can see, the whole reason for objectClasses is to get 
the attributes, you get ALL the posix attributes without actually adding 
the posix objectClasses, this is because microsoft has already added 
them internally. Anybody who connects to an AD server should not have to 
stop and ask, 'is this a Samba 4 AD server or is it a windows AD 
server?' and base their connect search based on which ever it is. AD is 
NOT LDAP and as such any connection to Samba 4 AD should be based on the 
way that you would connect to a windows AD server.
If you tried to connect to a windows AD server expecting to find the 
objectclass posixAccount, the search would fail, so in my opinion, any 
similar search against a Samba 4 server should also fail.

I am not saying that the AD server cannot or should not be used in a 
similar way to LDAP, I am just saying that the way the info is collected 
needs to be modified i.e. use AD objectClasses instead of posix ones.

Rowland

> Cheers,
>
> Jelmer