Question posted in
Some documentation to get you started can be found here.

How to authorize a user belonging to a group that contains hashes – Apache

I’m trying to authorize a user depending on his group membership.

Apache is configured as follows: 

AuthLDAPURL "ldap://DOMAIN.COM/DC=FOO,DC=COM?CN?SUB?(objectClass=user)" NONE
AuthLDAPBindDN "CN=..."
AuthLDAPBindPassword "..."
Require ldap-group CN=##SOMETEXT,OU=GSI,OU=DMM,OU=DDSIS,OU=Admin_Exchange,DC=DOMAIN,DC=com

The problem comes from the two hashes that appear in the CN.
I tried with and without quotes, with two backslashes and no backslashes, URL encode, but nothing worked.

I always get the following error message.

[Thu Feb 13 18:40:56.728349 2020] [authnz_ldap:debug] [pid 17154] mod_authnz_ldap.c(922): [client 10.255.180.148:65050] AH01719:
auth_ldap authorize: require group
“CN=##SOMETEXT,OU=GSI,OU=DMM,OU=DDSIS,OU=Admin_Exchange,DC=DOMAIN,DC=com”: didn’t match with attr Comparison complete [member][34 – Invalid DN
syntax]

When i remove the hashes, i get a no such object error, that confirms the problem comes from the hashes.

EDIT:

As suggested in the answer, I tried to write the octal representation of the hash character 43 but it gave me the exact same error:

“CN=##SOMETEXT, …Invalid DN syntax]

So that doesn’t seem to change what Apache sends to LDAP

Tags:

2

Answers


  1. 0

    You typically can get around these type of issues with something like:

    CN=2323SOMETEXT,OU=GSI,OU=DMM,OU=DDSIS,OU=Admin_Exchange,DC=DOMAIN,DC=com

    As described in RFC 4514 and Characters to Escape

    However, different applications may be trying to parsing these parameters for you and may interfere with the escaping process.

    The RIGHT thing to do is rename the group.

    The problem you are encountering will persist with other application in the future. Best Practices for LDAP imply all Relative Distinguished Names be "URL Safe" and not require escaping.

    Login or Signup to reply.
  2. 0

    You will need to escape the string according to RFC 4515 String Representation of Search Filters

    Generally, you need to escape the items listed in RFC 4515 String Representation of Search Filters and I would suggest, also any non-UTF8 character.

    I also found some methods that may be helpful to get you started.

    I believe the proper escaped value you are trying to find is: All in 463″567y5c22″c2a4&/2#%&! Test Group

    Finally, quit it. Start populating a searching for Description or some other non-naming attribute. (any attribute that is not part of the DN) Make your DNs never changing. No user should ever see a DN which should be only a path to an entry. You will have issues with many “off-the-shelve” tools if you continue this practice.

    I tried and was not even able to create an entry in two different vendors’ tools.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search