I am attempting to use LDAP with Shibboleth. I am nearly there, but I cannot authenticate. I followed these instructions, and my login.config file contains the following:
ShibUserPassAuth {
edu.vt.middleware.ldap.jaas.LdapLoginModule required
host="ldap://localhost:10389" base="ou=users,ou=system"
ssl="false" userField="uid";
};
I have tried several variations of the above.
I can use TestShib to reach my IdP's login page, but always receive "Login failed. Double-check your username and password" when I attempt to authenticate.
This might be easier to debug myself if I could manage to get any authentication log messages, but I can't seem to get those working either.
Note that the following ldapsearch command works perfectly fine:
ldapsearch -h "ldap.example.com:10389" -w testpass -x -D "uid=testuser,ou=users,ou=system" -b "dc=example,dc=com" '(objectclass=*)'
If you could tell me what my problem might be, or at least how to enable logging, that would be very helpful.
I have this working locally. I have taken my working config and replaced my LDAP host and base path with yours from the question above.
ShibUserPassAuth {
edu.vt.middleware.ldap.jaas.LdapLoginModule required
ldapUrl="ldap://localhost:10389"
baseDn="ou=users,ou=system"
userFilter="uid={0}";
};
Related
I'm trying to get a simple ldapsearch query working against Google Secure LDAP without using client certificate. I'm using Ubuntu 22.04 ldap-utils.
Am I doing something obviously wrong with my query below? Assume username generated by Google is LDAPUser1 and password is RAND123 and my domain is example.com:
ldapsearch -D "LDAPUser1" -w RAND123 -b "ou=Users,dc=example,dc=com" -H ldaps://ldap.google.com:636
Whenever I run it, I get the following error:
ldap_bind: Invalid credentials (49)
additional info: Incorrect password
I've copied the username and password verbatum from the Google Secure LDAP "Access Credentials" section. It's directly below the "Certificates" section.
My user authenticates fine through OpenVPN AS, using LDAP authentication over FreeIPA.
Now I want to restrict OpenVPN to enforce that they belong to a certain group.
I've created a User Group in FreeIPA, and changed OpenVPN to have an "Additional LDAP Requirement" of "memberOf=CN=myGroup,CN=groups,CN=accounts,DC=mgmt,DC=company,DC=uk"
But when I try to authenticate now, I get access denied, with this error in openvpn logs:
2019-11-26T09:38:12+0000 [stdout#info] VPN Auth Failed: u"LDAP exception on ldaps://endpoint.free.ipa.internal/ (facility='search (u'cn=users,cn=accounts,dc=mgmt,dc=company,dc=uk', 2, u'(&(uid=myUser)(memberOf=CN=myGroup,CN=groups,CN=accounts,DC=mgmt,DC=company,DC=uk))')'): **user not found that meets specified requirements**: memberOf=CN=myGroup,CN=groups,CN=accounts,DC=mgmt,DC=company,DC=uk: auth/authldap:178,python2.7/threading:774,python2.7/threading:801,python2.7/threading:754,_threads/_threadworker:46,_threads/_team:190,python/threadpool:250,python/threadpool:266,python/context:122,python/context:85,auth/authldap:138,auth/authldap:178,util/error:67,util/error:48" [None]
If I try (what I think is) the equivalent LDAP Search from command line, it works fine:
ldapsearch -x -D "uid=admin,cn=users,cn=accounts,dc=mgmt,dc=company,dc=uk" -W -H ldap://localhost -b "cn=users,cn=accounts,dc=mgmt,dc=company,dc=uk" '(&(uid=myUser)(memberOf=cn=myGroup,cn=groups,cn=accounts,dc=mgmt,dc=company,dc=uk))'
That returns the user, and even lists their memberOf attributes:
...
memberOf: cn=ipausers,cn=groups,cn=accounts,dc=mgmt,dc=company,dc=uk
memberOf: cn=myGroup,cn=groups,cn=accounts,dc=mgmt,dc=company,dc=uk
...
So unsure what I've done wrong in OpenLDAP.
I read that memberOf only works retrospectively, so I removed and re-added myUser to myGroup. Still didn't work.
Ah found it.
OpenVPNAS was using anonymous binding to connect to FreeIPA in order to authenticate people. With anonymous binding, it isn't permitted to see group membership!
Fix was to change OpenVPNAS to bind as an admin user. Now it works fine.
I tried to delete one of my Jelastic environments by means of the following API call:
curl -k \
-H "${CONTENT_TYPE}" \
-A "${USER_AGENT}" \
-X POST \
-fsS ${HOSTER_URL}/1.0/environment/control/rest/deleteenv -d "password=${password}&session=${session}&envName=${envName}
where I am sure that the session and envName are correct, as I have other commands running perfectly well with them. In particular, I get the session in the following way:
getSession() {
local login=$1
local password=$2
local hosterUrl=$3
echo "Signing in..." >&2
local cmd=$(curl -k -H "${CONTENT_TYPE}" -A "${USER_AGENT}" -X POST \
-fsS "$hosterUrl/1.0/users/authentication/rest/signin" -d "login=$login&password=$password");
exitOnFail $cmd
echo "Signed in" >&2
echo $(jq '.session' <<< $cmd | sed 's/\"//g')
}
In the call to deleteenv, I provide the very same password as that of my Jelastic provider account. Indeed, when I want to delete an environment through Jelastic's dashboard, this is the password I need to provide to make the deletion happen. However, I get the following error:
{"result":801,"source":"hx-core","error":"invalid password"}
Because the password field is documented as optional in Jelastic's API documentation, I tried not to set the password. This yields the following error:
{"result":3,"source":"JEL","error":"invalid parameter [password] for method [DeleteEnv] in service [ControlService]"}
I tried to use other secrets as that password, like the APPID, without any success.
Does anyone have a clue what password I need to put there?
We used the same oneliner based on API you used, your script to get a session and the same Jelastic version but were not able to reproduce this issue. Environment were successfully deleted.
Does anyone have a clue what password I need to put there?
This is the same password as you used to get session or to enter Dashboard. Make sure there are no additional symbols in your password variable.
Because the password field is documented as optional
Indeed, it's optional if use token instead of session. In case of session, password is an obligatory parameter.
I try to fetch some data from a Microsoft Dynamics Nav WebService.
This service uses the NTML authentication.
If I open the webservice url in a browser and use the given credentials everything works fine.
For setting up the environment for the WebService Client, I used the command line to check whether everything is working fine, I was, at a specific point, unable to authenticate.
Thats the command I am using:
curl --ntlm -u "DOMAIN\USERNAME" -k -v "http://hostname:port/instance/Odata/Company('CompanyName')/Customer"
The command will prompt for the password.
I copy in the password and everything is doing fine.
But when I use this command, with the password already included, it stops working and the authentication fails:
curl --ntlm -u "DOMAIN\USERNAME:PASSWORD" -k -v "http://hostname:port/instance/Odata/Company('CompanyName')/Customer"
The password contains some special chars, so I tried to use the percent encoding, which had no effect at all.
It is very difficult to research this kind of issue. Searching for curl + ntlm authentication issues provides a lot of results, but nothing is related to this specific kind of issue.
Does anyone of you guys already had experience with this kind of issue?
I had a problem with authentication because of cookies. I solved this containing cookies in txt file and using exactly this file through all requests. For example, after login request I saved this cookies:
curl -X POST -u username:password https://mysite/login -c cookies.txt
And with next request I used this file like this:
curl -X POST -u username:password https://mysite/link -b cookies.txt
This solution worked for me, I don't know if your problem is similar, but, I think, you may try this.
I was struggling with similar issue for a long time and finally I found this curl bug report #1253 NTLM authentication fails when password contains special characters (british pound symbol £) .
NTLM authentication in cURL supports only ASCII characters in passwords! This is still the case in version 7.50.1 on Ubuntu but I tested this on many different distributions and it is always the same. This bug also will break curl_init() in PHP (tested on PHP7). The only way to solve that is to avoid non ASCII characters in NTLM authentication passwords.
If you are using Python then you are lucky. Apparently Python developers rewrote cURL implementation and it works with non ASCII characters if you use HttpNtlmAuth package.
Try with nltm flag.
Something like this:
curl -v --proxy-nltm -u 'username:password' youproxy.com:8080 someURL
from > curl --help
-x, --proxy [PROTOCOL://]HOST[:PORT] Use proxy on given port
--proxy-anyauth Pick "any" proxy authentication method (H)
--proxy-basic Use Basic authentication on the proxy (H)
--proxy-digest Use Digest authentication on the proxy (H)
--proxy-negotiate Use Negotiate authentication on the proxy (H)
--proxy-ntlm Use NTLM authentication on the proxy (H)
Want to use ldap_mod_add command with SSL on Centos but get the following error message;
PHP Warning: ldap_mod_add (): Modify: Server is unwilling to perform in ...
However the SSL ldapsearch command is working well;
ldapsearch -x -H ldaps://winsvr.intra -b dc=windows, dc=intra -D "DOMAIN\user"-w "123456"
The required Windows.pem file is in /etc/ssl/certs/windows.pem directory and has the appropriate line in /etc/openldap/ldap.conf.
Indeed getting above error message.
What else should I configure to work properly?
Updated:
Everything's OK. Problem was that I didn't recognize existing AD user. That's why the ldap_mod_add returned with above error messages (it couldn't add same AD user through ldap_mod_add).
The LDAP client in your PHP example is apparently doing an update, whereas the ldapsearch tool is doing a search, not to point too fine a point on it. The configuration of the server, the nature of the target entries involved, and any access controls involved might affect the update but not the search.