samba-tool posix user/group improvements

[Rowland Penny]

On 10/10/13 07:01, Alexander Bokovoy wrote:
> Hi Rowland,
>
>
> On Wed, Oct 9, 2013 at 11:23 PM, Rowland Penny 
> <repenny241155 at gmail.com <mailto: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 <http://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
>     <mailto: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
Which is what I have been saying, windows will not add the objectClasses 
posixAccount & posixGroup to anything because it already has added them 
in the background, so no unix tools should either. Just think about it, 
if a user is created in ADUC and given the unix attributes, the 
posixAccount objectClass would not be added, but at present a samba-tool 
created user has the objectClass added. If a unix tool now did a search 
that relied on the posixAccount objectClass, only the user created by 
samba-tool would be found, even if there were hundreds of ADUC created 
users.

Rowland