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.
Related
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.
Using WSO2 IS (5.0.0.SP1 or 5.1.0) - is it possible to disable the default basic authenticator?
The reason is - at the client a custom authenticator is used to provide additional security measures (one time password, client certificate, ..).
Once the user forces use of the basic authenticator authentication (e.g. using /samlsso?spEntityID=any_invalid_data_here), the user is authenticated only with its username and password skipping any additional authentication. Once authenticated, the IS won't validate other security measures (assuming the username and password is not always enough and additional authentication is required by the client or even sec standards).
Seeing the application-authentication.xml config file, I've tried to disable the basic authenticator there or replace it in the default Sequence config with no success.
To close the question: IdP-initiated SSO with invalid issuer seems fixed in 5.1.0, where the authenticator chain is better enforced
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
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.
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.