When searching LDAP with objectSid filter, like
ldapsearch -b 'dc=example,dc=com' objectSid=s-1-5-32
there are no results (should be "cn=Builtin,dc=example,dc=com).
Attached patch fixes the bug.
Created attachment 10183 [details]
Patch ldif_comparision_objectSid_isString function to accept lower-case SIDs
As far as I'm aware, the objectSID=S-1-5-32 style filter is a Samba extension. Therefore I would prefer to keep it strict, for performance and consistency.
See http://blog.schertz.name/2008/03/searching-ad-for-a-user-account-with-a-sid/ for the contortions Micorsoft makes Windows admins to to search, and please accept using an upper case S.
Well, I cannot remember the exact scenario (hell, it's over 9000^W two years), but it was definitely a Microsoft product I was installing when I'd encountered the issue. It was some component of a Sharepoint 2013 farm.
To make sure, I've just installed a test AD on Windows Server 2012 R2 (with domain/forest functional level 2008) and tried an ldapsearch with objectSid=S-1-5-32 style filter against it. Both uppercase and lowercase filters work perfectly.
BTW, Novell DSfW (which we are using at the moment, while planning to migrate to Samba) also supports both upper- and lowercase objectSid searches.
It's not clear from the blog post mentioned, which AD version/functional level was being used. Might be that objectSid=S-1-5-32 style filters were only introduced in 2008.
Thanks. Sorry for the horribly long delay in even looking at these bugs properly.
I'll get this sorted out.
I didn't know DSfW still existed! I look forward to your migration to Samba.
Yeah, DSfW is still alive and moving! Will be too for quite some time, until the new management at Micro Focus finds out Samba is the way to the bright future ;)
Not blaming you for taking so long to look at the bug report, cause it was not too serious.
And yes, Andrew, thank you very much for all the work you've done and keep doing!
please close the bug accordingly if you agree that this is not a bug.
To be clear, thanks for the patch. Given the clarification I'm inclined to include it, or something similar. The only thing blocking it now is a test, so we don't regress.