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

You typically can get around these type of issues with something like:
CN=\23\23SOMETEXT,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.

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"567y\5c22"\c2\a4&/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.

Related

ms sql connection string with semi colon in password failing to connect

Am working on anypoint studio 6.6.8 with runtime 3.9.4EE.
I have the following mssql generic database connection string.
jdbc:sqlserver://ABC.org:59000;databaseName=master;username=nrp;password=*37n%3b#wu;5r:;_1z~(f{1y{j
Test connection gives me the following error:
Test connection failed:
org.mule.module.db.internal.domain.connection.ConnectionCreationException: Cannot get connection for URL jdbc:sqlserver://ABC.org:59000;databaseName=master;username=nrp;password=<<credentials>>;5r:;_1z~(f{1y{j: The connection string contains a badly formed name or value
PS: I have 2 semi colons in password
I have seen similar question raised here earlier a few times, hence my question might look repetitive.
however I tried the following solutions given in the replies. none of them worked. Please let me know if you have any alternate solution.
Enclosing the password in single quotes.
adding \ in front of ;
Enclosing password within double quotes or {}
Am not the admin hence removing ; from password cannot be done.
The connection string is in a format known as JAVA JDBC URL. It is similar to a normal URL. Many characters are not allowed in URLs and have to be encoded with the URL encoding method. Try using URL encoding for the entire URL. You can do it with most languages or online pages, though you might want to avoid public pages for sensitive information like passwords.
Example in Groovy: https://stackoverflow.com/a/10187493/721855.
Example in Python: https://stackoverflow.com/a/5607708/721855.
Thank you #aled
So the {} did work. I was doing it the wrong way.
I was encrypting the password & later concatenating {} to the decrypted password right b4 passing the connection string.
What worked was that I enclosed the password in {} first & then encrypted it.

Invalid username format in Azure database connection

I am unable to connect with database using psycopg2 module. This may be due to the # character needing escaping, but I have already tried this. Also, it could be related to my password having the "/" character, or the hostname having the "-" character, and I don't know how to escape it (I've already tried escaping using %2f and %2D).
This is the code I have tried with a edited password, so you can see the "special" characters it has, and also the "-" characters in the hostname. Most likely I am doing this wrong.
engine = create_engine('postgresql://username:asd/32foo/T123%40sql-is-a232#sql-is-a232.database.windows.net:5432/database')
The username here is: username,
The password here is: asd/32foo/T123,
The hostame (I think this is) here is: sql-is-a232,
The server here is: sql-is-a232.database.windows.net,
The database name here is: database.
Any help would be greatly appreciated!
Please reference this document: Database Urls:
As the URL is like any other URL, special characters such as those that may be used in the password need to be URL encoded. Below is an example of a URL that includes the password "kx%jj5/g":
postgresql+pg8000://dbuser:kx%25jj5%2Fg#pghost10/appdb
The encoding for the above password can be generated using urllib:
>>> import urllib.parse
>>> urllib.parse.quote_plus("kx%jj5/g")
'kx%25jj5%2Fg'
Examples for common connection styles follow below. For a full index of detailed information on all included dialects as well as links to third-party dialects, see Dialects.
Hope this helps.

OpenAM / OpenDJ custom username field works with less than 4000 users

I am currently working on a project that uses OpenAM 12.0.2 with OpenDJ 2.6
We had a requirement to make the username editable. So, we ended up creating a custom ldap attribute called loginId and updating OpenAM config to use this attribute instead of uid.
When I import less than 4000 users, login works fine. When I import 4000+ users login doesn't work for any user, even 1 of the first 4000 users in the directory.
I can manually ldapsearch for the users and they exist in the directory, but I can't login with any of them.
We get an "Authorization failed!!" error, which is different to the usual username/password doesn't match error.
If anyone could shed any light on this, I would appreciate it.
Thanks
Edit
Here is the attribute definition I am now using.
attributeTypes: ( 1.3.6.1.4.1.37238.2.9 NAME 'loginId' DESC 'username (that can be updated)' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'project schema')
I have rebuilt the indices and still having the same problem :(
That is probably because your instance of OpenDJ is configured to reject unindexed search request and you haven't defined and built an index for the loginID attribute.

Freeradius users operators

I faced with one issue, which I can't understand in Freeradius users file.
My goal is just authenticate external user "shad" with password "test".
I added line in /etc/raddb/users the following line:
shad Cleartext-Password == "test"
Result was Reject. If I change "==" operator to ":=" Authentication is successful.
So my question is the following:
Why I can't use "==" operator while FreeRadius documentation tells:
"Attribute == Value
As a check item, it matches if the named attribute is present in the request, AND has the given value."
And one more question.
In some resourses I faced with such lines:
shad Auth-Type := Local, User-Password == "test"
I tried and it doesn't work. Responce is Reject with log:
[pap] WARNING! No "known good" password found for the user. Authentication may fail because of this.
How the users file works
For the answer below, pairs is referring to Attribute Value Pairs (AVPs), that is, a tuple consisting of an attribute an operator and a value.
There are three lists of attribute(s) (pairs) that are accessible from the users file. These are bound to the request the server is currently processing, and they don't persist across multiple request/response rounds.
request - Contains all the pairs from the original request received from the NAS (Network Access Server) via the network.
control - Initially contains no pairs, but is populated with pairs that control how modules process the current request. This is done from the users file or unlang (the FreeRADIUS policy language used in virtual servers).
reply - Contains pairs you want to send back to the NAS via the network.
The users file module determines the list it's going to use for inserting/searching, by where the pair is listed in the entry, and the operator.
The first line of the entry contains check pairs that must match in order for the entry to be used. The first line also contains control pairs, those you want to be inserted into the control list if all the check pairs match.
Note: It doesn't matter which order the pairs are listed in. control pairs will not be inserted unless all the check pairs evaluate to true.
check and control pairs are distinguished by the operator used. If an assignment operator is used i.e. ':=' or '=' then the pair will be treated as a control pair. If an equality operator such as '>', '<', '==', '>=', '<=', '=~' is used, the pair will be treated as a check pair.
Subsequent lines in the same entry contain only reply pairs. If all check pairs match, reply pairs will be inserted into the reply list.
Cleartext-Password
Cleartext-Password is strictly a control pair. It should not be present in any of the other lists.
Cleartext-Password is one of a set of attributes, which should contain the 'reference' (or 'known good') password, that is, the local copy of the users password. An example of another pair in this set is SSHA-Password - this contains a salted SHA hash of the users password.
The reference password pairs are searched for (in the control list) by modules capable of with authenticating users using the 'User-Password' pair. In this case that module is 'rlm_pap'.
User-Password
User-Password is strictly a request pair. It should not be present in any of the other lists.
User-Password is included in the request from the NAS. It contains the plaintext version of the password the user provided to the NAS. In order to authenticate a user, a module needs to compare the contents of User-Password with a control pair like Cleartext-Password.
In a users file entry when setting reference passwords you'll see entries like:
my_username Cleartext-Password := "known_good_password"
That is, if the username matches the value on the left (my_username), then insert the control pair Cleartext-Password with the value "known_good_password".
To answer the first question the reason why:
shad Cleartext-Password == "test"
Does not work, it is because you are telling the files module to search in the request list, for a pair which does not exist in the request list, and should never exist in the request list.
You might now be thinking oh, i'll use User-Password == "test" instead, and it'll work. Unfortunately it won't. If the password matches then the entry will match, but the user will still be rejected, see below for why.
Auth-Type
Auth-Type is strictly a control pair. It should not be present in any of the other lists.
There are three main sections in the server for dealing with requests 'authorize', 'authenticate', 'post-auth'.
authorize is the information gathering section. This is where database lookups are done to authorise the user, and to retrieve reference passwords. It's also where Auth-Type is determined, that is, the type of authentication we want to perform for the user.
Authenticate is where a specific module is called to perform authentication. The module is determined by Auth-Type.
Post-Auth is mainly for logging, and applying further policies, the modules run in Post-Auth are determined by the response returned from the module run in Authenticate.
The modules in authorize examine the request, and if they think they can authenticate the user, and Auth-Type is not set, they set it to themselves. For example the rlm_pap module will set Auth-Type = 'pap' if it finds the User-Password in the request.
If no Auth-Type is set the request will be rejected.
So to answer your second question, you're forcing pap authentication, which is wrong, you should let rlm_pap set the Auth-Type by listing pap after the files module in the authorize section.
When rlm_pap runs in authenticate, it looks for a member of the set of 'reference' passwords described above, and if it can't find one, it rejects the request, this is what's happening above.
There's also a 'magic' Auth-Type, 'Accept', which skips the authenticate section completely and just accepts the user. If you want the used to do cleartext password comparison without rlm_pap, you can use:
shad Auth-Type := Accept, User-Password == "test"

JNDI & AD bind error when special characters like &,%,$ present in UserDN

I have implemented a java code which connects to the given host ip with username and password of the AD server.(using JNDI)
Now when I use a username which has no special character it works fine. But when I use symbols like $, #, &, etc in the username it gives me Auth. Error.
I am surprised to see this because &,$, and # are not used in userdn format by AD.
Can anyone explain what the problem and what can be the solution for this.
Thanks
I cannot be sure (I have very little information to judge), but there may be a problem with the "7-bit-check-plugin". It is a LDAP plugin, which is responsible for rejection of data that are coded with more than 7 bits. This includes characters as %, $, # as well as some German characters, middle and east European characters, etc.
Please try to check if you have enabled 7-bit-check-plugin. If so, try to disable it and use that data again.