If I connect using ADSI Edit to the domain global catalog, I can see all objects without problems. But if I would like to watch the properties of one of them I get on the client side "Illegal submitted directory path". On the server side I see in the valgrind log an error in module ldb_msg.c function ldb_msg_add on line 169. ==17305== Invalid read of size 4 ==17305== at 0x85FE45A: ldb_msg_add (ldb_msg.c:169) ==17305== by 0x85FF6C5: ldb_msg_copy_attr (ldb_msg.c:731) ==17305== by 0x86237EE: operational_search_post_process (operational.c:143) ==17305== by 0x862396D: operational_callback (operational.c:198) ==17305== by 0x861360D: show_deleted_search_callback (show_deleted.c:76) ==17305== by 0x8618D33: ltdb_index_filter (ldb_index.c:797) ==17305== by 0x8619058: ltdb_search_indexed (ldb_index.c:877) ==17305== by 0x8616A3F: ltdb_search (ldb_search.c:496) ==17305== by 0x8600CA0: ldb_next_request (ldb_modules.c:393) ==17305== by 0x8611A0F: partition_replicate (partition.c:343) ==17305== by 0x8611C1A: partition_search (partition.c:399) ==17305== by 0x8600CA0: ldb_next_request (ldb_modules.c:393) ==17305== Address 0x467D2A0 is 128 bytes inside a block of size 192 free'd ==17305== at 0x401D89D: realloc (vg_replace_malloc.c:306) ==17305== by 0x88D2AE6: _talloc_realloc (talloc.c:795) ==17305== by 0x88D3840: _talloc_realloc_array (talloc.c:1303) ==17305== by 0x85FE318: ldb_msg_add_empty (ldb_msg.c:132) ==17305== by 0x85FE434: ldb_msg_add (ldb_msg.c:165) ==17305== by 0x85FF6C5: ldb_msg_copy_attr (ldb_msg.c:731) ==17305== by 0x86237EE: operational_search_post_process (operational.c:143) ==17305== by 0x862396D: operational_callback (operational.c:198) ==17305== by 0x861360D: show_deleted_search_callback (show_deleted.c:76) ==17305== by 0x8618D33: ltdb_index_filter (ldb_index.c:797) ==17305== by 0x8619058: ltdb_search_indexed (ldb_index.c:877) ==17305== by 0x8616A3F: ltdb_search (ldb_search.c:496)
Thankyou again for the very useful bug report. I think I've fixed this in -r 23993.
I have now tested the latest SVN and the bug ldb_msg_add line 169 is fixed, but the other problem isn't. In my tests the ADSI Edit seems to work now properly when using LDAP connection method. But when I am using the Global Catalog, I see again the same problem: I can see all objects in the AD, but when I doubleclick one to see the properties, either the app does nothing or it displays the message "Illegal submitted directory path". In the SAMBA log I see the ldb requests, like "ldb_request BASE dn=Attribute-Schema,CN=Schema,CN=Configurations,DC=wallnoefer2,DC=local filter=(objectClass=*)" but it's like SAMBA can't return the correct data.
I've reproduced this behaviour. Very interesting...
Another problem found in ADSI Edit: when renaming an object that has subobjects, then the DN's of these aren't updated and so they are going to be invisible.
I've now reproduced the bug also in ADUC. I think it's a general problem.
Can you file the subtree rename issue as a seperate bug? This will require much more major work to LDB.
Yes, I've listed the same issues in bug 4818 (I think that are all LDB things).
> When I am using the Global Catalog, I see this problem: I can see all objects > in the AD, but when I doubleclick one to see the properties, either the app > does nothing or it displays the message "Illegal submitted directory path". > In the SAMBA log I see the ldb requests, like "ldb_request BASE > dn=Attribute-Schema,CN=Schema,CN=Configurations,DC=wallnoefer2,DC=local > filter=(objectClass=*)" but it's like SAMBA can't return the correct data. Andrew, did you make some further investigation here? I didn't find a cause.
I add also metze to this bug, because he wrote most of the ldap server (and therefore also most of the global catalog service) in SAMBA 4. For repetition, the problems are reproducible with the MS MMC tool "ADSI Edit" using the "global catalog" option.
Seems also to be fixed through the latest schema patch by Andrew.