Lastly I tested three LDAP editors and both have some problems with the SAMBA 4 LDAP backend. For comparison I made the tests also again Fedora Directory Server, where the things worked. In the first program "LDAP Admin" I noticed a crash when I wanted to edit an entry. In the second "LUMA" there was displayed a message telling something about invalid entries in some cases when I was going to try to change something. The third app "JXplorer" wasn't even able to show me the tree. I believe that all is caused by schema and schema checking problems.
OK, it looks like this will be a bit of a challenge. We need to fix up Samba4's use of things like 'unixName', and see why these tools fail. I've installed gq and luma, so can check this more in future.
Andrew, any results on your test?
phpldapadmin seems to work fine (but is clearly not a tool targeted at AD) gq crashes (but then again, this is far from unusual...) luma complains 'could not parse template file' (but I can't even get it to bind against real AD) The comparison needs to be against AD, as the way schema is deployed in both directories differs, and these tools do a lot of schema introspection.
Now I retested SAMBA 4 with LdapAdmin and discovered, that the critical point seems to be a certain look up to "cn=Aggregate,cn=Schema,cn=Configuration,<domain>". Have we there everything right in comparison with Windows Server?
*** Bug 5496 has been marked as a duplicate of this bug. ***
I've to say that here we've improved greatly. - With LDAP Admin the editing still isn't possible but that could be due the Active Directory schema - LUMA seems much more stable against SAMBA 4 - JXplorer is able to see the tree and the navigation works Maybe it is worth to close now the bug, since we can't be completely RFC-LDAP compatible because of Active Directory.
Now the various clients seem to work due to the new Microsoft AD schema. Thanks to everyone who has helped to achieve this!