When Windows populates its list of available users/groups for assigning file security, it performs a wholeSubtree LDAP search on e.g DC=smb4,DC=internal,DC=id10ts,DC=net with a filter of (groupType=2147483653). This query from a W2K3 client against an S4 DC does not return any results, while a W2K3 client querying against a W2K3 DC returns 17 results. This causes users/groups such as "Administrators" and "Server Operators" to not appear in the results. When we provision a new S4 server, the groupType attribute for "Administrators" and "Server Operators" is set to "-2147483643". Note that both 2147483653 and -2147483643 result in the same 32-bit field (0x80000005). The Windows LDAP server returns the same 17 results using either number (2147483653 or -2147483643) as the groupType search filter. The following ldapsearch commands were used to test this: 1) ldapsearch -H ldap://192.168.5.179 -D cn=administrator,cn=users,dc=ads,dc=internal,dc=id10ts,dc=net -x -w password -b dc=ads,dc=internal,dc=id10ts,dc=net "(groupType=2147483653)" 2) ldapsearch -H ldap://192.168.5.179 -D cn=administrator,cn=users,dc=ads,dc=internal,dc=id10ts,dc=net -x -w password -b dc=ads,dc=internal,dc=id10ts,dc=net "(groupType=-2147483643)" Testing with ldapsearch against S4 gives 17 results when using -2147483643 as the filter, but no results when using 2147483653 as the filter. The following ldapsearch commands were used to test this: 1) ldapsearch -H ldap://amd64 -D cn=administrator,cn=users,dc=smb4,dc=internal,dc=id10ts,dc=net -x -w password -b dc=smb4,dc=internal,dc=id10ts,dc=net "(groupType=2147483653)" 2) ldapsearch -H ldap://amd64 -D cn=administrator,cn=users,dc=smb4,dc=internal,dc=id10ts,dc=net -x -w password -b dc=smb4,dc=internal,dc=id10ts,dc=net "(groupType=-2147483643)" Note: I may be seeing this because I am running S4 on a 64-bit Linux system. I am setting up a 32-bit VM to test in & will add another comment once I am done with that testing.
Created attachment 3951 [details] Packet capture of W2K3 client querying W2K3 DC
Created attachment 3952 [details] Packet capture of W2K3 client querying S4 DC
I just finished testing in a 32-bit VM, and the same behaviour occurs as was originally seen when running S4 under 64-bit Linux.
We need to add a new '32 bit integer' syntax, handling this rollover to: lib/ldb-samba/ldif_handlers.c And we need to use the OID allocated for that in: static const struct dsdb_syntax dsdb_syntaxes[] in dsdb/schema/schema_syntax.c
Okay, I try to find a solution for this issue. It seems that it solely happens without an LDAP backend (plain LDB).
Created attachment 4282 [details] Patch to enable correct behaviour on "groupType", "userAccountControl" and "sAMAccountType" - Change some "int" and "unsigned int" variables to int32_t or uint32_t to make sure that the behaviour is the same on all platforms! - Introduce the right conversion mechanisms for lookups on "groupType", "userAccountControl" and "sAMAccountType" in the "samldb" module. Therefore, all possible backends can now benefit from it. - Remove the conversion code from the "simple_ldb_map" module which was only used for LDB LDAP backends.
Comment on attachment 4282 [details] Patch to enable correct behaviour on "groupType", "userAccountControl" and "sAMAccountType" This should we fix in another way.
Created attachment 4290 [details] Patch to handle integer 32bit attributes correctly Now I wrote a much better patch which should solve the problem for "groupType" but also for all integer attributes in general. I followed Andrew's guidelines and so this patch should comply.
That looks much better. Comments: Please don't rename the fucntions to ldb_ as that namespace should be reserved for the 'real' ldb. (we need a better prefix than ldif_, but it will do for now). To actually hook it in, see the table in schema_syntax.c and add a new .ldb_syntax = "LDB_SYNTAX_SAMBA_INT32" for it. Finally, we just need tests. This is really good work. Thank you very much!
Created attachment 4292 [details] New patch to handle integer 32bit attributes correctly - The first patch wasn't complete - I changed now all methods to "ldif_" prefix in the ldif handlers - Made changes in "schema_syntax.c" were appropriate - Removed code from "simple_ldap_map.c" - shouldn't be necessary anymore. Question: Since this module seems very old - Does it still have the task to convert certain attributes? - Haven't we now the ldif handlers who do this for all backends (and not only LDB_LDAP)?
The simple_ldap_map code is indeed old in this respect, it certainly could handle the conversions by looking at the schema. However, at the moment it isn't written that way, and only ldb_tdb will use the schema code to normalise integers. Therefore, please remove the simple_ldap_map.c code from the patch. In syntax_map.c, don't change the .ldap_oid (as it must still be the LDB_SYNTAX_INTEGER), but instead add a .ldb_syntax = LDB_SYNTAX_INT32 element. It seems you are getting very close. We should soon be able to apply the patch.
Created attachment 4300 [details] New patch to handle 32bit integer attributes correctly - Undo the changes on the parameter ".ldap_oid" and added parameters ".ldb_syntax" in "schema_syntax.c" - Refactored the conversion function in "simple_ldap_map.c" (it looked a bit ugly in my eyes)
Matthias, can you put that in your git tree, or re-attach as a git-format-patch? This version is good! (otherwise I'll make up a commit message for you)
Also, any chance of an extension to ldap.py to test this behaviour? Andrew Bartlett
Fixed
I've to reopen the bug since the problem shows up again.
This problem should now be finally fixed. I substituted the "strtol" with "strtoll" since with the you got always LONG_MAX on conversions (due to the intended overflows). This didn't happen earlier when I wrote the first patch - I think my glibc had a bug.