samba-tool posix user/group improvements

[Alexander Bokovoy]

Hi Rowland,


On Wed, Oct 9, 2013 at 11:23 PM, Rowland Penny <repenny241155 at gmail.com>wrote:

> On 09/10/13 20:29, 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')
>>>
>> This is a distinct issue from the rest of the patch, because this patch
>> follows the pattern already established.  Adding these values improves
>> compatibility with LDAP clients, because many do (correctly) filter on
>> this objectclass.
>>
> Just because it an established way of doing things, does not make it
> right. As for ldap clients filtering on the posix objectclasses, would they
> do this against a windows server and more to the point would it work ?
>
>  The reason this is set on posixAccount is that, as I read the schema,
>> otherwise you simply can't set for example gecos or loginShell on the
>> account.  Have you tested your proposed modification and shown that
>> everything sill works?
>>
> Dont know about the gecos attribute, but here is a user created through
> ADUC, using msSFU30MaxUidNumber:
>
> # Test User, Users, example.com
> dn: CN=Test User,CN=Users,DC=example,DC=**com
> objectClass: top
> objectClass: person
> objectClass: organizationalPerson
> objectClass: user
> cn: Test User
> sn: User
> givenName: Test
> instanceType: 4
> whenCreated: 20131003143825.0Z
> displayName: Test User
> uSNCreated: 3899
> name: Test User
> objectGUID:: hWsXjePINUupa6KtGBtMsQ==
> badPwdCount: 0
> codePage: 0
> countryCode: 0
> badPasswordTime: 0
> lastLogoff: 0
> lastLogon: 0
> primaryGroupID: 513
> objectSid:: AQUAAAAAAAUVAAAA5aGURJHhLId0AF**+HVwQAAA==
> accountExpires: 9223372036854775807
> logonCount: 0
> sAMAccountName: testuser1
> sAMAccountType: 805306368
> userPrincipalName: testuser1 at example.com
> objectCategory: CN=Person,CN=Schema,CN=**Configuration,DC=example,DC=**com
> pwdLastSet: 130252847060000000
> userAccountControl: 512
> msSFU30NisDomain: example
> uidNumber: 10002
> loginShell: /bin/sh
> unixexampleDirectory: /example/testuser1
> gidNumber: 100
> msSFU30Name: testuser1
> unixUserPassword: ABCD!efgh12345$67890
> uid: testuser1
> whenChanged: 20131003143924.0Z
> uSNChanged: 3904
> distinguishedName: CN=Test User,CN=Users,DC=example,DC=**com
>
> Oh look, the loginShell attribute is there, but there is definitely no
> posixAccount objectClass
>
>
>
>> Samba certainly shouldn't require the posixAccount or posixGroup
>> attributes to get uid and gid values, and we fixed that up in the
>> idmap_ldb:use rfc2307 code a while back, but adding these seems
>> beneficial for a number of use cases.
>>
> The posix objectClasses do not need to be added at all, try looking at the
> 'user' objectClass, it has an auxiliaryClass!
>
Since user object class has posixAccount already included, your user
definition is allowed to contain attributes from posixAccount object class.
Without it adding an attribute from posixAccount class that is not present
in any other class would cause an error on LDAP/LDB side.

So your schema already includes implicitly posixAccount, thus no need to
include it explicitly. But posixAccount is still there and in use.

-- 
/ Alexander Bokovoy