LDAP authentication - how to filter CN names containing escaped character and wildcard?

[anewell]

I am configuring LDAP authentication against Windows AD, where the users are in groups with names containing a hash character and an arbitrary string:

CN=\#CS foo,OU=division,DC=fabrikam,DC=com
CN=\#CS bar,...
CN=\#CS baz,...
CN=\#CS qux,...

I have a working Static Group Search filter that uses asterisk wildcards to capture the hash sign, and which requires the full name of the CN. Those upstream names occasionally change, and break authentication. It's also a hassle to maintain the long list of OR clauses, for example (|(*CS foo)(*CS bar)(*CS baz)(*CS qux))is ugly but it works.

I would like to capture #CS * "Hash-Charlie-Sierra-space-Asterisk", but using common backslash or RFC4515 style escape chars, I am getting errors :
(CN=\#CS *) (CN=\#CS foo) and (CN=\23CS foo) returns "Encountered the following error while trying to update: Failed to retrieve a group with these settings."

Any help on crafting a suitable query filter would be warmly appreciated. Splunk Enterprise 7.0.1 on Linux, Windows AD version unknown, presumed old-ish.

[acharlieh]

Easy... # (U+0023) is not a character that requires escaping in a filter. If you look at the grammar in RFC4515 again it says as much:

valueencoding  = 0*(normal / escaped)
normal         = UTF1SUBSET / UTFMB
escaped        = ESC HEX HEX
UTF1SUBSET     = %x01-27 / %x2B-5B / %x5D-7F
                    ; UTF1SUBSET excludes 0x00 (NUL), LPAREN,
                    ; RPAREN, ASTERISK, and ESC.

I actually went the route of making a few test groups in my AD, and grabbing Apache Directory Studio to try out some raw LDAP searching (Ok I also needed this stackoverflow answer due to ADS being based on Eclipse and I don't have a Java < 9 installed ).

And so I then used (CN=#CS *) as a group filter in my local (7.1.1) Splunk UI and it seems to work just fine. (CN=\23CS *) also works just fine but (CN=\#CS *) is an invalid filter and will not work.

Now one other thing to note, is that in order for a group to show up in the UI for group mapping and for saving the connection, it must have qualifying members. If it does not, the search that is being used will not return these empty groups to the group mapping page. (So if your #CS foo group has no members, a filter of (CN=\23CS foo), despite being valid would also fail to return a group and cause you the described issues).