• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

HowTO: Setup an LDAP server and Client CentOS 6.2

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.
Thanks for Great Post. Its working..
I want to do Dns+PDC+Ldap in RHEL6/CentOs6. Can you post for "How to setup PDC+LDAP" in CentOS 6.2
 
You need to make your request much more specific.

What specifically are you trying to achieve?
 
You need to make your request much more specific.



What specifically are you trying to achieve?

I want to configure DNS+ Ldap + samba pdc in Centos6.2 for windows systems in my network. Previously I did samba pdc domain in CentOS 5.0. But I am not familiar Ldap. Please help me. Thanks in advance....
 
For those pm'ing me and asking for help in general

We (the community) will NOT do your work for you!

We will however be glad to help if you can prove that you have taken a stab at your problem and are attempting to troubleshoot.

We are doing this in our spare time, so please be mindful we have jobs, wives/lives and our own projects on the go. Most of us love to spread information around but we are not going deploy solutions with users attempting it on their own first

Please be specific with your questions instead of a grocery list of things you want to accomplish
 
Excellent guide, however I have found a few small issues while following these notes:

1) To run ldapsearch you need open ldap client software installed even if its the server.
2) ldapadd requires full path name of the -f file.

The problem I have is I now want to delete the database as start again as I dont want to use
ou=People
and want to use
ou=User
So I have tried using :
ldapdelete -x -W -D "cn=fred,dc=mydomain,dc=local" "uid=fred,ou=People,dc=mydomain,dc=local"

That gives:

ldap_bind: Invalid credentials (49)

So I have broken something somewhere by trying to modify the config templates before deletion.

Is there an easy way just to trash the whole ldap database and start again with an updated /etc/openldap/schema/base.ldif??
 
Hi,
this is a great post, I haven't found similar complex documentation with configs for the most recent versions of RH/Centos.
I followed your guidance and I can log in to ldap on 389 but I can't log in on 636.
ldapsearch -x -H ldap://127.0.0.1:389 works fine but ldapsearch -x -h ldaps://127.0.0.1:636 hangs and doesn't display anything.
I believe that it might be issue with certificates. is there any way to check it?

Best,
John
 
So it could very well be a certificate problem.

The first thing to check is that the cert has actually been copied to the client's /etc/pki/tls/certs directory.

Additionally you can look in /var/log/secure, you can use the ldapsearch with '-vv' for very verbose and see if there is additional input available.

Have you also made sure that port 636 is open on your server? Try an nmap from an external computer. This will tell you if computers can see the open port. As well as, a netstat from the server itself will tell you whether it is listening on 636.
 
I guess that it might be certificate related issue.

I forgot to add that I test ldapsearch on the server so location or certs is right.
Nothing in /var/log/secure.
-vv only displays ldap_initialize( ldaps://127.0.0.1:636/??base ) and then hangs.
Ports are open too.
 
How did you get the certs onto your client?

Did it create a sym link (what usually is supposed to happen is that there is a hash that is taken of the cert and then a sym link is created in the same directory)
 
I didn't create symlinks.
If I understand correctly then certs should be in /etc/pki/tls/certs directory for both server and client.

ls -la /etc/pki/tls/certs
-rw-r--r--. 1 ldap ldap 1220 Oct 9 10:16 ldap_cert.pem
-rw-r--r--. 1 ldap ldap 1704 Oct 9 10:16 ldap_key.pem
 
This may seem like a double post, but the information is the same.

After having run through this again, I have found that the authentication gui does not pull down the cert(s)

putting them in place manually sort of fixed the problem

I noticed this in /var/log/messages

Code:
Oct  9 12:53:20 client sssd[be[default]]: Could not start TLS encryption. TLS: hostname does not match CN in peer certificate

This was because I used a hostname in the creation of the cert and an ip when editing pam_ldap and ldap.conf

Changing those configs to a FQDN allowed me to go from start to finish following this guide on CentOS 6.3
 
Stratus_ss.
can you confirm that with your guide you can see search results after you run ldapsearch -x -H ldaps://127.0.0.1:636 on the server ? This is even before configuring client.
I checked with external client (Apache DS and it says that it can init connection but it stops after I put password.
It 99% suggests that the problem is with cert or some missing bit in configuration.
I'm working on the project that will be published as free open source later on and I appreciate any help.
 
Stratus_ss.
can you confirm that with your guide you can see search results after you run ldapsearch -x -H ldaps://127.0.0.1:636 on the server ? This is even before configuring client.
I checked with external client (Apache DS and it says that it can init connection but it stops after I put password.
It 99% suggests that the problem is with cert or some missing bit in configuration.
I'm working on the project that will be published as free open source later on and I appreciate any help.

As I mentioned above, IP addresses do not work. Here is the output that you have requested

Code:
[root@ldap Desktop]# ldapsearch -x -H ldaps://localhost:636
# extended LDIF
#
# LDAPv3
# base <dc=stratinfotech,dc=com> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# stratinfotech.com
dn: dc=stratinfotech,dc=com
dc: stratinfotech
objectClass: top
objectClass: domain

# People, stratinfotech.com
dn: ou=People,dc=stratinfotech,dc=com
ou: People
objectClass: top
objectClass: organizationalUnit

# thiddy, People, stratinfotech.com
dn: uid=thiddy,ou=People,dc=stratinfotech,dc=com
uid: thiddy
cn: thiddy thiddy
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword:: cGFzc3dvcmQ=
shadowLastChange: 15140
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 1000
gidNumber: 1000
homeDirectory:: L2hvbWUvdGhpZGR5IA==

# search result
search: 2
result: 0 Success

# numResponses: 4
# numEntries: 3


This is from the client

Code:
[root@client Desktop]# ldapsearch -x -H ldaps://ldap.stratinfotech.com:636
# extended LDIF
#
# LDAPv3
# base <dc=stratinfotech,dc=com> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# stratinfotech.com
dn: dc=stratinfotech,dc=com
dc: stratinfotech
objectClass: top
objectClass: domain

# People, stratinfotech.com
dn: ou=People,dc=stratinfotech,dc=com
ou: People
objectClass: top
objectClass: organizationalUnit

# thiddy, People, stratinfotech.com
dn: uid=thiddy,ou=People,dc=stratinfotech,dc=com
uid: thiddy
cn: thiddy thiddy
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword:: cGFzc3dvcmQ=
shadowLastChange: 15140
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 1000
gidNumber: 1000
homeDirectory:: L2hvbWUvdGhpZGR5IA==

# search result
search: 2
result: 0 Success

# numResponses: 4
# numEntries: 3


Using 127.0.0.1 does not work because RedHat has (recently?) decided that IPs are not appropriate for this task. They do mention this in their training class for the RHCE. (Of course I don't expect many to have taken that :D)

Anyways please do feel free to continue posting any questions you may have. As I have time (and/or knowledge) I will get back to you. I monitor this subforum almost daily

For reference, here is what happens if you dont make sure that it creates the home directory on first login

Code:
[root@client Desktop]# cat /etc/passwd |grep thiddy
[root@client Desktop]# su thiddy
bash-4.1$ pwd
/root/Desktop
bash-4.1$ cd
bash: cd: /home/thiddy : No such file or directory
bash-4.1$
 
Last edited:
did you try ldapmodify?

I would imagine that should do what you are looking for

Yes - suspect that would have worked, but I found the db's, and trashed them, then reinstalled the software and started from line 1.

I seem to be getting somewhere..
The server is on centos 6.2, and the clients are centos 5.8 & OSX Lion.
The centos clients can ID and login without issues.
The OSX Lion client can ID the user, but cannot login.

Left it a few days hoping for the bright idea to resolve the OSX Lion problem.
Now centos clients cannot login, or ID, and ldapsearch -vv -x fails - just hangs:

[root@licserver certs]# ldapsearch -vv -x
ldap_initialize( <DEFAULT> )

I seem to also be getting confused between ldap, openldap, slapd.

Are your notes for ldap or openldap as some files edited are pure openldap and others are ldap?
 
So this is for OpenLDAP, which is the available implementation on CentOS.

some file names don't specify openldap but that is what it is.

Make sure that sssd is running (perhaps try restarting it?)

You can also try working nscd as well though that shouldn't be strictly necessary
 
So this is for OpenLDAP, which is the available implementation on CentOS.

some file names don't specify openldap but that is what it is.

Make sure that sssd is running (perhaps try restarting it?)

You can also try working nscd as well though that shouldn't be strictly necessary

Progress...

sssd wasn't chkconfig'd on so configured on and started - wont start due to database issues?!

I re-created certificates and re-configured the ldap.conf so it used your path names for the certificate location as I had moved the certificate and key to /etc/openldap/certs.

Restarted slapd and I can perform ldapsearch and ID users under linux, plus I can login as an ldap user :D

Back to OSX...
Laptop is dual boot between 10.6.8 & 10.7.5 so started with 10.6.8.
Configured everything and used "use from server".
I can ldapsearch and id a user, but cannot su - username or login.
/var/log/secure.log just says BAD SU

Moved over to 10.7.5 and got no further... can id and ldapsearch but cannot login or su

I believe the problem is to do with the certificate in that I have not copied it over as I have no idea
a) where to copy it to.
b) how to reference it as /etc/openldap/ldap.conf has not been touched..

I guess at this point it's time to start searching again using my fav search engine to see what that brings up for OSX and openldap as I suspect your ldap knowledge does not reach that far.
When a solution is found I will post it on here.
 
Yes please,

You are correct, I have no experience with OSX and LDAP but I would be really interested in any details you would share.

Thanks!
 
Back