I am new to working with LDAP, and my ultimate goal is to offer LDAP single sign-on in a web app. In order to achieve this, I'm trying to run ldapwhoami, but I'm running into issues. I am able to run other commands, like ldapsearch and ldapadd.
I'm running OpenLdap on Mac OS High Sierra.
My relevant slapd.conf looks like this:
access to *
by self write
by * read
by anonymous auth
database ldif
suffix "dc=test,dc=com"
directory openldap-data
rootdn "cn=admin,dc=test,dc=com"
## rootpw = secret
rootpw {SSHA}fFjKcZb4cfOAcwSjJer8nCGOEVRUnwCC
I then added a user with ldapadd -x -w secret -f shanson.ldif, where shanson.ldif looks like:
dn: cn=shanson,dc=test,dc=com
objectClass: inetOrgPerson
sn: Hanson
uid: shanson
cn: shanson
userPassword: secret
I am successfully able to search for and find this new user with ldapsearch -x "(cn=shanson)".
Now, I am trying to verify the user's credentials using ldapwhoami, and I keep getting an error:
> ldapwhoami -x -D cn=shanson,dc=test,dc=com -w secret
ldap_bind: Invalid credentials (49)
The same operation with my root admin user succeeds:
> ldapwhoami -x -D cn=admin,dc=test,dc=com -w secret
dn:cn=admin,dc=test,dc=com
I'm sure I'm just making a simple mistake or not understanding what I'm doing, but I don't really know where else to look right now for answers. Thanks!
It seems to have had something to do with the plain text password I set up. I installed Jxplorer and manually updated my user's password and hashed it with MD5, and now the ldapwhoami command works. If I set the password as plain text in JXplorer, ldapwhoami still does not work. Beyond that, I'm not entirely sure what I was doing wrong.
For me, my dn was wrong.
I did an ldapsearch with admin credentials to get the dn: uid=xxx,ou=xxx,dc=xxx,dc=xxx,dc=xxx
Then I did an ldapwhoami -x -D "uid=xxx,ou=xxx,dc=xxx,dc=xxx,dc=xxx" -w secret and it worked fine.
Related
We have a Google G suite with multiple domains and users with email addresses not always having the primary domain extension.
When ldap searching the Secure LDAP environment for a user with a non primary domain we get the wrong user DN back.
Example:
LDAPTLS_CERT=ldap-client.crt LDAPTLS_KEY=ldap-client.key ldapsearch -H ldaps://ldap.google.com -b dc=example,dc=com '(mail=user#company.nl)'
returns dn: uid=user,ou=Users,dc=example,dc=com
where it should return dn: uid=user,dc=company,dc=nl
But with this wrong DN the next step in my radius authentication (because that's where we are using this for) fails:
LDAPTLS_CERT=ldap-client.crt LDAPTLS_KEY=ldap-client.key ldapsearch -W -D uid=user,ou=Users,dc=example,dc=com -H ldaps://ldap.google.com -b dc=example,dc=com '(mail=user#company.nl)' with a
ldap_bind: Invalid credentials (49)
additional info: Incorrect password
which makes sense because LDAP cannot find the user.
whereas as binding with the right DN succeeds:
LDAPTLS_CERT=ldap-client.crt LDAPTLS_KEY=ldap-client.key ldapsearch -W -D uid=user,ou=Users,dc=company,dc=nl -H ldaps://ldap.google.com -b dc=example,dc=com '(mail=user#company.nl)'
If I query for the user with the corresponding base_dn from the user's email address the returned DN is ok, but I cannot dynamically adjust the based_dn depending on the users email address, I think, in freeradius
I’m not sure if this a problem of the google LDAP servers or a problem with the LDAP protocol or a problem with the way I/radius queries LDAP.
I'm thinking to implement scripting authentication in the authorize section and implement my own ldapsearch + bind , but I hope there's a better solution.
Thanks. Wessel
Try with ldaps://ldap.google.com:636.
We found unless the port is defined it does not work.
We also noticed that not all fields can be searched, i.e uidNumber.
My current problem is that i cannot stop OpenLDAP to store passwords as plaintext. In an older openLDAP version , i entered following configuration in the slapd.conf
ppolicy_hash_cleartext
password-hash {SSHA} {SHA}
So once a password was sent from my application as plaintext, the ldap was encrypting it and storing it encrypted.
Unfortunately i was not able to configure OpenLDAP 2.4.40. I found out that the slapd.conf does not exist anymore in the newer version and instead the configuration is taking place in the cn=config.ldif file.
I tried to add again the same configuration there but it seems that it has no effect.
EDIT : I added with ldapmodify the olcPasswordHash: {SSHA} entry in olcBackend={0}mdb.ldif , olcDatabase={1}mdb.ldif , olcDatabase={0}config.ldif and cn=config.ldif , still my passwords that are sent as plaintext are stored as plaintext.
Took some time, but figured out finally.
Load schema describing ppolicy attributes.
ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/ppolicy.ldif
Create a ppolicy_module.ldif with the following content and make sure that the ppolicy.la is located under the defined olcModulePath. Store the file under /etc/ldap
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModuleLoad: ppolicy.la
olcModulePath: /usr/lib/ldap
Add the ppolicy_module.ldif
ldapadd -Y EXTERNAL -H ldapi:/// -f ppolicy_module.ldif
Create a ppolicy-overlay.ldif file with the following content. Make sure of the olcDatabase number . In this case it is olcDatabase={1}mdb . Store the file under /etc/ldap
dn: olcOverlay=ppolicy,olcDatabase={1}mdb,cn=config
objectClass: olcPPolicyConfig
olcOverlay: ppolicy
olcPPolicyDefault: cn=ppolicy,ou=policies,dc=example,dc=com
olcPPolicyUseLockout: FALSE
olcPPolicyHashCleartext: TRUE
Add LDIF file.
ldapadd -Y EXTERNAL -H ldapi:/// -f ./ppolicy-overlay.ldif
Restart ldap.
More details under:
https://fedorahosted.org/sssd/wiki/openldap_ppolicy
Here is my LDAP ORG Structure:
I created user with first, last name with password. But it is not working when am trying to connect using jdbc. Error says invalid credentials. Then I tried ldapsearch as follows:
I followed this process for users and group creation:
root#ip:/home# ldapwhoami
SASL/DIGEST-MD5 authentication started
Please enter your password:
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: SASL(-13): user not found: no secret in database
root#ip:/# ldapsearch -x -LLL -h ip -D username -w password -b"cn=admin,dc=ivhdev,dc=local" -s sub "(objectClass=*)" "givenName=username*"
ldap_bind: Invalid DN syntax (34)
additional info: invalid DN
Please suggest/correct me, if am passing the right info in DN syntax. I am unable to validate the user credentials with their name and password.
The -D option takes the DN for logging in to your LDAP server.
The -b option takes the search base in your LDAP tree where you want to search for the user's given name.
So, your ldapsearch command becomes:
ldapsearch -x -LLL -h ip -D 'cn=admin,dc=ivhdev,dc=local' -w password -b 'dc=users,dc=local' -s sub '(objectClass=*)' 'givenName=username*'
If you use the Apache Directory Studio (http://directory.apache.org/studio/) you can see the actual ldapsearch commands used by the application. Maybe this is useful for anyone.
Am new to ApacheDS - am using apacheds-2.0.0-M17.
The default password for admin is secret.
Does anyone know where I can change the value to something else?
Inside:
apacheds/instances/default/conf/config.ldif
Found the following entry:
ads-pwdattribute: userPassword
When googling it, there are a lot of examples that mention doing it using Apache Directory Studio but the particular instance I am trying to configure is running in a Linux shell in a headless (no UI) mode.
Tried using the following command with ldapmodify and the cursor hangs (keeps blinking) after pressing enter. I even tried prepending it with sudo and the same thing happens.
ldapmodify -H ldap://localhost:10389 -D "uid=admin,ou=system" -x -w secret
Does anyone know why it hangs?
What am I possibly doing wrong?
Thanks again,
James
Changing the admin account password is documented in the ApacheDS documentation.
ldapmodify, if not given a file to process with -f parameter, waits for input from standard input, on which it expects a LDIF formatted file with modifications to perform.
In your case such a LDIF file would look something like:
dn: uid=admin,ou=system
changetype: modify
replace: userPassword
userPassword: new-password
BTW, you can still use Apache Directory Studio (or any other graphical LDAP client) to make this change, even if your directory is running on a headless server. LDAP is, after all, a network protocol. Just run the LDAP client on a local machine and connect over the network to your server. (Of course, I leave it to you to figure out if you have to open up some firewall rules or whatever.)
dn: uid=admin,ou=system
changetype: modify
replace: userPassword
userPassword: new-password
-
After each modification, you need to add the end of "-"！！！
I many times integrate authentication in application based on LDAP.
I just put configs: URL (like ldap.company.com:389), search base (like dc=europe,dc=com) and query pattern (like (uid=$)) to libraries and frameworks.
But I always wonder what really do libraries and frameworks to actually authenticate user by supplied login/password.
Seems that LDAP has three type of authentication itself - anonymous, plain password and SASL. So sometimes in order to authenticate you need application login/password to get access to LDAP service.
I am not sure that this blog answer the question: http://thecarlhall.wordpress.com/2011/01/04/ldap-authentication-authorization-dissected-and-digested/ :
Get a connection to the LDAP server.
Bind as the application user.
Search for the DN (distinguished name) of the user to be authenticated.
Bind as user to be authenticated using DN from step 3.
Is that right?
That may be summarized as (as experiment in command line):
$ ldapsearch -x -h ldap.company.com -s sub -b 'dc=europe,dc=com' "uid=XYZ"
....
dn: uid=XYZ,dc=sales,dc=europe,dc=com
...
$ ldapsearch -W -h ldap.company.com -D 'uid=XYZ,dc=sales,dc=europe,dc=com' \
-s sub -b 'dc=europe,dc=com' "uid=XYZ"
Are there any other authentication schema like using specific DN attribute value as user secret? Or userPassword is that attribute itself?
Your four steps are basically correct. SASL is an External Authentication Mechanism where Authentication is "handed" off to the SASL Mechanism. RFC 4513 spells out Authentication and Security Mechanisms.
-jim