Assume an application that can be configured to use an LDAP server - be it ActiveDirectory, or OpenLDAP etc. - for authenticating its users and retrieving some additional information about them for authorization purposes. The way the application binds to the LDAP server is also configurable - it can use a simple or a SASL bind, depending on what the LDAP server supports and the overall security requirements.
It's assumed that if a bind succeeds with whatever credentials the user provided, then it must mean that those credentials are valid. However, that's not always the case; it can happen that a simple bind succeeds even though an empty password was provided where a non-empty one was in fact expected. According to the RFC about LDAP authentication methods a simple bind with a non-empty username and an empty password is interpreted as an intention to establish an unauthenticated connection, with anonymous authorization. The server can be configured to fail such attempts with unwillingToPerform, but it can also allow them.
The question is: in such a scenario, where an application can be configured to use a variety of LDAP servers, and bind in a configurable way - simple or over SASL - is there a way to unequivocally check the credentials the user entered against that particular LDAP server, other than trying to bind with those credentials, given that a simple bind can lead to false positives?
Thank you and I look forward to your replies.
Surely all you have to do is disallow, or maybe even just remember, cases where the password was empty?
In PHP, at least, you just have to do this:
<?php
$ds = ldap_connect($ip_address);
if(#ldap_bind($ds, $username, $password) {
// Login successful!
} else {
// Login unsuccessful :(
}
?>
Your mileage may vary with other languages, but this has worked for me.
Related
I have setauth_password_format: scram in ejabberd.yml and ldap auth method.
LDAP authentication works only for passwords in plaintext.
I can even set scram hash value as a password in my xmpp client and successfully login, since ejabberd checks it as a plain text against LDAP record, but how do I make ejabberd hash the password with scram before checking it against the LDAP record?
I thought auth_password_format would do that, but apparently it still thinks userPassword attribute in the LDAP record is in plain text.
Is there some additional check that ejabberd preforms on the userPassword value to see if it is indeed scram and then fails for some reason? Or is it ignoring auth_password_format option when ldap is set as auth method? Or something else entirely?
Is there a way as a non-erlang developer that I can make this work? The only idea I have is to use external auth scripts if ejabberd cant use scram and ldap together for some reason, but I would really like it if I can just set this up in the configuration file instead.
Looking at the ejabberd source code, scram is mentioned in ejabberd_auth.erl, ejabberd_auth_mnesia.erl and ejabberd_auth_sql.erl. There is no mention to scram in the other authentication methods, which points to what you concluded.
In this sense, I later noticed that the SCRAM section mentions only internal (Mnesia) and SQL auth methods:
https://docs.ejabberd.im/admin/configuration/authentication/#scram
I would say that external auth will not support it either.
I configured freeradius which use ldap as a backend database.(in ldap, i stored password in ssha)
Because ldap does not support mschap, I Use eap-ttls with pap for authentication.
In freeradius server, when I run freeradius in debug mode, I see username and password of client in cleartext.freeradius output
so, as I said before, because I use ldap as a backend database, I can't use mschap (which is the only secure way I know for client to send his password). I just want to know is there another way to send password that is not visible in output of freeradius?
I Found this options in windows, but I don't know if they are useful for my case or not.
windows interface configuration
Thanks.
Im using LDAP Admin Tool Professional 6.0
When i try to add an entry or try to add an attribute to an existing record,I get this error:
Strong Authentication Required
LDAPException: Strong Authentication Required (8) Strong Authentication Required
LDAPException: Server Message: modifications require authentication
LDAPException: Matched DN:
What could be wrong?
"modifications require authentication" indicates that you did not authenticate to the LDAP server at all, but doing an anonymous bind. While you may read a lot of things as anonymous user, depending on the ACL of the server, all server implementations I know do not allow write operations without authentication.
So you need to specify "Bind DN" and "Bind Password" in your LDAP client software to make any modifications to the data stored in the LDAP directory.
The message is very clear. The administrators require a stronger authentication scheme. Use something stronger with the correct credentials and the authentication will succeed - assuming you are trying to authenticate before the add. If you are trying to add entries without authenticating at all, note that directory server administrators may forbid it.
I don't know about your "Admin Tool Professional 6.0" but LDAP is not accepting your login.
Check your DN
I am in the preparation phase of testing an application that will be using LDAP for user authentication. What are some tips or advice you might have for this endeavor?
I don't have a great understanding of LDAP but I believe all that will be used is the application client calls to LDAP with a username and sees if the password matches. Is that an accurate description? Also, what are some edge cases to test? Thanks.
LDAP authentication is often (but not always) a 2-step process: first the application does an LDAP query to locate the "distinguished name" (dn) of the account the user's trying to authenticate to, then it tries to log in ("bind", in LDAP parlance) as that dn, using the user-supplied password.
If the "bind" attempt works, the application knows the password is correct. (The LDAP server is likely not configured to allow the application to actually extract the password and do the comparison itself, for obvious security reasons).
An LDAP-enabled application will typically require a way to configure:
hostname/port of LDAP server
search base (e.g., dc=mycompany,dc=org)
user search filter (e.g. "(|(cn=%userid)(mail=%userid))")
application credentials for the initial LDAP query (unless the server allows anonymous queries)
You will most likely need to support SSL, so you don't send the user's password to the LDAP server in cleartext.
This strongly depends on your technology.
If you are directly querying the ldap you have to care about performance e.g. how fast are your queries, how often you have to do them and if you server is sized appropriately.
If you are using some kind of container that it providing SSO then these will usually have some caching features, etc.. There you have to check if everything is working properly.
You would need ldap_connect and ldap_bind functions. Also once you are binded with the ldap server you can search for entries on the ldap and get the user information.
You should surely check if encodings are handled properly (try umlauts or other weird stuff in passwords).
And take care to test with the LDAP servers you care about, Active Directory, OpenLdap, Apaches LDAP Server, and a few others, they might show different behaviours.
Also check if the client handles 'referrals' correct, e.g. when you try to lookup users in a different domain (e.g. two AD forrests with forrest trust installed).
I have a web application (PHP, but doesn't matter). It uses LDAP for authentication (already working), and it allows users to search LDAP (already working).
But when searching, I use a generic process account to bind() and then run the search().
What I would like is to use the LDAP account that logs in to be the same account that binds for the searching. But the only way I see to do that is to store the user's credentials in the sessions (bad!).
Nutshell: can I get a "state/session/??" token from LDAP, to bind() and then search() on subsequent http requests?
(btw, using Active Directory.)
Basic LDAP doesn't provide anything like this. The credentials that you present when binding are used for the rest of the connection, so if you could keep an LDAP connection open across multiple HTTP requests (and share LDAP connections among however many server jobs you have running), then you could avoid saving credentials.
There are various extensions to LDAP floating around (including several within Active Directory), so it's possible that one of those adds sessions-across-connections, but if so, I'm not aware of it.
As a sort-of-workaround, because Active Directory supports GSSAPI and because of how Kerberos works, you ought to be able to use the user's credentials to request a Kerberos ticket for accessing LDAP then store that ticket as your "state/session/??" token. This Kerberos ticket would only be valid for accessing LDAP and would auto-expire, so this would avoid the pitfalls of storing the user's credentials in the session. I don't know if your LDAP library supports GSSAPI and would give you enough control to do this or not.