Samba4: ID mapping is hard

[Matthias Dieter Wallnöfer]

Andrew,

in my personal "master" branch you can find the necessary changes ready 
for review. Also the "dn" branch has been finished as well.

Thanks,
Matthias

Andrew Bartlett schrieb:
> On Sun, 2012-03-25 at 09:46 +0200, steve wrote:
>> El 24/03/12 01:20, Andrew Bartlett escribió:
>>> On Fri, 2012-03-23 at 23:54 +0100, steve wrote:
>>>
>>>> What is working well for us in tests is giving Domain Users a uid, gid,
>>>> setting their primaryGroupID to that of a posix-ified security group and
>>>> storing these attributes in their entry in sam.ldb. The only problem I
>>>> have with this is that adding the posixGroup objectClass to a security
>>>> group removes the ability to be able to list its members in ADUC and it
>>>> is really unfortunate that I can't test this against a windows server.
>>>> Because I don't have one.
>>> Trial copies of Windows are available for download:
>>>
>>> https://www.microsoft.com/en-us/server-cloud/windows-server/2008-r2-trial.aspx
>> There is already a bugzilla which confirms that s4 does not handle the
>> posixGroup attribute correctly. Adding the posixGroup attribute on a ms
>> 2008 server works correctly. The membership tabs under ADCU appear
>> correctly.
>>
>> Please see:
>> https://bugzilla.samba.org/show_bug.cgi?id=8635
>> comment 43 onwards.
> Steve,
>
> I would be most helpful if you could:
>   - file a new bug with a clear description of only the objectClass
> ordering issue
>   - determine how the objectclass ordering algorithm works on Windows to
> allow this auxillary class to be added.  The WSPP documentation may be
> of assistance here. MS-ADTS in particular:
> http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-ADTS%5D.pdf
>   - provide a patch to source4/dsdb/tests/python/ldap.py to demonstrate
> the correct objectClass ordering behaviour
>   - provide a patch to source4/dsdb/samdb/ldb_modules/sobjectclass_sort.c
> to implement the correct sorting.
>
> Only this process will get this issue fixed.
>
> I've CC'ed Matthias, who has worked on many of our LDAP behaviour issues
> in the past, and who may be able to provide some further assistance, as
> I'm currently too far stuck in IDMAP for s3fs to try and take this on in
> the near future.
>
> Thanks,
>
> Andrew Bartlett
>