Install OpenLDAP 2.4.Configure Transport Layer Security (TLS).- Manage users and groups in OpenLDAP.
- Configure pam_ldap to authenticate users via OpenLDAP.
- Use OpenLDAP as sudo's configuration repository.
- Use OpenLDAP as automount map repository for autofs.
- Use OpenLDAP as NFS netgroup repository again for autofs.
- Use OpenLDAP as the Kerberos principal repository.
- Setup OpenLDAP backup and recovery.
- Setup OpenLDAP replication.
Manage users and groups in OpenLDAP
We now have an empty OpenLDAP directory. We can prove this simply by trying to extract information from it.
ldapsearch -LLLxWD cn=admin,dc=company,dc=com -b dc=company,dc=com
Enter LDAP Password:
No such object (32)
In order to use our OpenLDAP directory, we need to create the base suffix and two Organizational Units (OU) to store our users and groups. So create an LDIF file with the following data.
vi ~/ldap/users+groups.ldif
Add this new data into our directory.
ldapmodify -a -xWD cn=admin,dc=company,dc=com -f ~/ldap/users+groups.ldif
Verify that we now have the new data.
ldapsearch -LLLxWD cn=admin,dc=company,dc=com
Did you notice I didn't specify any -b dc=company,dc=com suffix with the previous ldapsearch command? That's because the suffix is already configured in the /etc/openldap/ldap.conf file.
Let's now add a few groups. We will create the following groups :
- sysadmin to group the Linux systems administrators together.
- oinstall, sysoper, asmdba, asmadmin and asmoper which are all Oracle related groups.
- test.group to test verious parts of our PAM and LDAP architecture. It's always good to test!
- panic which will be used by in case LDAP and/or NFS has a problem.
- nssproxy which will be used to query this LDAP server instead of an anonymous user.
Of course, I encourage you to change this group list to fit your organization's needs. Create another LDIF file with the following data.
Add those new groups to our LDAP directory.
ldapmodify -a -xWD cn=admin,dc=company,dc=com -f ~/ldap/groups.ldif
Now it's time to create a few users. In this document, we will create the following users. Again, you should change this user list and the user's details (such as UID) to fit your corporation's needs.
- drobilla. That's me :)
- nssproxy. This user will be used to query our LDAP server instead of using an anonymous user.
- panic. This user will be used when LDAP and/or NFS is broken. It is a local user, but we list it here in order to have a central place where we can get all of our UID. This prevents UID clash!
- test.user. Again, this user will be used to test our setup as we build on this OpenLDAP server.
Let's write yet another LDIF file. Don't bother with the passwords for now, we will address those in a few minutes.
Add these users to the LDAP directory.
ldapmodify -a -xWD cn=admin,dc=company,dc=com -f ~/ldap/users.ldif
Let's now assign a proper password to the users. Repeat this procedure for each of the users. Note that this command will prompt twice for the new user's password and a third time for the cn=admin,dc=company,dc=com user's password.
ldappasswd -xZWD cn=admin,dc=company,dc=com -S cn=nssproxy,ou=users,dc=company,dc=com
New password:
Re-enter new password:
Enter LDAP Password:
New password:
Re-enter new password:
Enter LDAP Password:
If you take a look in the /var/log/slapd.log file, you should see these lines which indicates the password has been modified :
slapd[5319]: conn=1022 op=1 PASSMOD id="cn=nssproxy,ou=users,dc=company,dc=com" new
slapd[5319]: conn=1022 op=1 RESULT oid= err=0 text=
We need to modify an OpenLDAP ACL to enable the nssproxy user access to our data. Let's first check which ACLs are in place. But first we need to know what is our database's DN?
sudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -b cn=config dn | grep -i database
dn: olcDatabase={-1}frontend,cn=config
dn: olcDatabase={0}config,cn=config
dn: olcDatabase={1}bdb,cn=config
dn: olcDatabase={2}monitor,cn=config
Ok, so now we know that we need to edit the « olcDatabase={1}bdb,cn=config » DN. Let's see what ACLs are configured on this DN?
ldapsearch -xZLLLWD cn=admin,dc=company,dc=com -b olcDatabase={1}bdb,cn=config olcAccess
dn: olcDatabase={1}bdb,cn=config
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=externa
l,cn=auth" manage
olcAccess: {1}to attrs=userPassword by self write by * auth
olcAccess: {2}to dn.base="dc=company,dc=com" by * search by * none
We need to modify an OpenLDAP ACL to enable the nssproxy user access to our data. Let's first check which ACLs are in place. But first we need to know what is our database's DN?
sudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -b cn=config dn | grep -i database
dn: olcDatabase={-1}frontend,cn=config
dn: olcDatabase={0}config,cn=config
dn: olcDatabase={1}bdb,cn=config
dn: olcDatabase={2}monitor,cn=config
Ok, so now we know that we need to edit the « olcDatabase={1}bdb,cn=config » DN. Let's see what ACLs are configured on this DN?
ldapsearch -xZLLLWD cn=admin,dc=company,dc=com -b olcDatabase={1}bdb,cn=config olcAccess
dn: olcDatabase={1}bdb,cn=config
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=externa
l,cn=auth" manage
olcAccess: {1}to attrs=userPassword by self write by * auth
olcAccess: {2}to dn.base="dc=company,dc=com" by * search by * none
We can see that we have ACLs on three configuration DN. We must then change these to allow the nssproxy user to read our data. Edit another LDIF file.
Apply the modifications to the OpenLDAP server.
ldapmodify -xZWD cn=admin,dc=company,dc=com -f ~/ldap/nssproxy.acl.ldif
Test to see if we can see our data with the nssproxy user? This command should return the entire Directory Information Tree (DIT)
ldapsearch -xZWD cn=nssproxy,ou=users,dc=company,dc=com "(objectClass=*)"
Test that you cannot get anything using another user.
ldapsearch -xLLLZWD cn=drobilla,ou=users,dc=company,dc=com "(objectClass=*)"
result: 50 Insufficient access
Excellent! We can now continue.
LDAP Browser
Now that we're starting to have a few objects in the LDAP directory, you should think about installing an LDAP Browser. It's a GUI which helps you visualize your LDAP data. My own personal favorite is Apache Directory Studio. It's a free, cross-platform and full featured LDAP Browser. It can be installed stand-alone or inside Eclipse. That's how I use it on my PC-BSD 9.0 desktop.
Ok, we achieved another of our goals...
Login to another machine running CentOS 6.2 (or install a new one :) Install the required packages on this client.
sudo yum -y install openldap openldap-clients nss-pam-ldapd pam_ldap
Before we start changing this client's configuration file, we should test again just to make sure our nssproxy user is ok and that we can connect to the OpenLDAP machine.
ldapsearch -xZLLLWD cn=nssproxy,ou=users,dc=company,dc=com -b dc=company,dc=com -H ldap://alice.company.com:389
Edit the system-wide LDAP client configuration file.
sudo vi /etc/openldap/ldap.conf
Edit another system-wide LDAP client configuration file.
sudo vi /etc/nslcd.conf
Fix permissions on the /etc/nslcd.conf file because there is the password for our nssproxy user.
sudo chmod 600 /etc/nslcd.conf
sudo chown root:root /etc/nslcd.conf
Edit the network service switch configuration file.
sudo vi /etc/nsswitch.conf
Install OpenLDAP 2.4.Configure Transport Layer Security (TLS).Manage users and groups in OpenLDAP.- Configure pam_ldap to authenticate users via OpenLDAP.
- Use OpenLDAP as sudo's configuration repository.
- Use OpenLDAP as automount map repository for autofs.
- Use OpenLDAP as NFS netgroup repository again for autofs.
- Use OpenLDAP as the Kerberos principal repository.
- Setup OpenLDAP backup and recovery.
- Setup OpenLDAP replication.
Configure pam_ldap to authenticate users via OpenLDAP
Login to another machine running CentOS 6.2 (or install a new one :) Install the required packages on this client.
sudo yum -y install openldap openldap-clients nss-pam-ldapd pam_ldap
Before we start changing this client's configuration file, we should test again just to make sure our nssproxy user is ok and that we can connect to the OpenLDAP machine.
ldapsearch -xZLLLWD cn=nssproxy,ou=users,dc=company,dc=com -b dc=company,dc=com -H ldap://alice.company.com:389
Edit the system-wide LDAP client configuration file.
sudo vi /etc/openldap/ldap.conf
Edit another system-wide LDAP client configuration file.
sudo vi /etc/nslcd.conf
Fix permissions on the /etc/nslcd.conf file because there is the password for our nssproxy user.
sudo chmod 600 /etc/nslcd.conf
sudo chown root:root /etc/nslcd.conf
Edit the network service switch configuration file.
sudo vi /etc/nsswitch.conf
Make sure the nslcd daemon starts at boot.
sudo chkconfig nslcd on
Start it.
sudo /etc/init.d/nslcd start
Make sure you do NOT have the nssproxy user in the system's local passwd file. This should return nothing.
grep nssproxy /etc/passwd
Then test the new LDAP query.
getent passwd test.user
test.user:x:1101:1101:Test User:/home/test.user:/bin/bash
getent group test.group
test.group:*:1101:
Good! That means the system can now find users and groups from the LDAP directory.
We can thus configure the PAM LDAP module. Note that we could use the authconfig(8) and authconfig-tui(8) tools to configure PAM LDAP, but I prefer to edit the files manually. Keep note that if you edit the files manually and then user either of those tools, the configurations in /etc/nslcd.conf and pam.d will be removed! So edit the /etc/pam_ldap.conf file.
sudo vi /etc/pam_ldap.conf
Then edit several files in the /etc/pam.d directory. First the system authentication PAM in which we list the new pam_ldap module.
sudo vi /etc/pam.d/system-auth-ac
Next we also want to use pam_ldap to authenticate users coming in via sshd(8), so let's tell PAM about it.
sudo vi /etc/pam.d/sshd
Of course, we also need to configure sshd(8) so it knows we want to use pam_ldap.
sudo vi /etc/ssh/sshd_config
In this file we also restricted who could login via the AllowGroups directive. Now restart sshd so that it knows about the new configuration.
sudo /etc/init.d/sshd restart
We also like to let our users know that this machine is restricted via a simple /etc/issue file:
cat /etc/issue
Restricted Access.
Create a home directory for the user.
sudo mkdir /home/test.user
sudo chown test.user:test.group /home/test.user
Ok, from the client machine, issue a tail on the secure log file to see if things work?
sudo tail -F /var/log/secure
While from another machine, try to ssh into this new LDAP configured client.
ssh -v test.user@client.company.com
You should now have access to the client :)
But wait! If you take a look at the /var/log/slapd.log file on the OpenLDAP server, you will find quite a lot of lines like these :
slapd[6152]: <= bdb_equality_candidates: (objectClass) not indexed
slapd[6152]: <= bdb_equality_candidates: (uid) not indexed
If we take a look to our server, we notice that we don't have any indexes at the moment.
sudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -b olcDatabase={1}bdb,cn=config olcDbIndex
That means we must modify the backend database to create indexes for these attributes. So edit another LDIF file.
sudo ldapmodify -a -H ldapi:/// -f ~/ldap/posixAccount.indexes.ldif
Then check if the changes have been properly installed?
sudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -b olcDatabase={1}bdb,cn=config olcDbIndex
dn: olcDatabase={1}bdb,cn=config
olcDbIndex: default pres,eq
olcDbIndex: uid
olcDbIndex: cn,sn pres,eq,sub
olcDbIndex: objectClass eq
olcDbIndex: memberUid eq
olcDbIndex: uniqueMember eq
olcDbIndex: uidNumber
olcDbIndex: gidNumber eq
Excellent! We should not have any more errors in our slapd.log file.
We now have finished another of our goals!
Install OpenLDAP 2.4.Configure Transport Layer Security (TLS).Manage users and groups in OpenLDAP.Configure pam_ldap to authenticate users via OpenLDAP.- Use OpenLDAP as sudo's configuration repository.
- Use OpenLDAP as automount map repository for autofs.
- Use OpenLDAP as NFS netgroup repository again for autofs.
- Use OpenLDAP as the Kerberos principal repository.
- Setup OpenLDAP backup and recovery.
- Setup OpenLDAP replication.
See you later,
DA+
Due to AllowGroups in /etc/ssh/sshd_config, the test.user can't really login because test.group is not included. Also, this set up means that even root can't login because root group is not included. It is best to allow local accounts to be able to login, in addition to the ldap accounts.
ReplyDelete@Anonymous : I've changed the sshd_config file to add the test.group group into AllowGroups.
ReplyDeleteBut allowing root over ssh is a very bad idea. The default sshd_config file also doesn't allow root over ssh. In fact, most -if not all- the Linux security guides specify not to allow root over ssh (or worse, over rsh!).
And for the other local or LDAP accounts, it depends on your organisation. But in most places I've worked for (~12 differents corporations) most users never need a shell access to the UNIX or Linux machines. They mostly need access to the server's services (i.e. HTTP, Wiki, SMTP, NTP, SQL, etc).
But again, YMMV ;)
David
You sshd_config actually allows for root access via ssh keys:
ReplyDeletePermitRootLogin without-password
This is very secure if you have good control on your ssh keys.
Yes, it does seem like it. But root still doesn't have remote access on the servers because the root group is not in AllowGroups. I use the « PermitRootLogin without-passwords » to allow remote backup using rsnapshot.
ReplyDeleteThe trick here is that there is another user with UID zero on my servers : the user backup.
This user can login without-password (and thus using it's ssh key), but it doesn't have an interactive shell on the servers. It has the rssh shell. rssh is a restricted shell for use with OpenSSH (see http://www.pizzashack.org/rssh/ for more info). I further restrict rssh to the rsync command only.
Also, the ~backup/.ssh/authorized_keys file on each server is modified to include a « from="backupserver.domain.com" » keyword further restricting the use of this key.
See http://itdavid.blogspot.ca/search/label/rsnapshot for more info on how to setup this particular backup configuration.
Regards,
David
It does work in your setup where you have backup account already set up. However, in a newly setup server, with your version of sshd_config, no one can even sudo to root any more. I got bitten by this and I had to get into single user mode to change sshd_config so that I can control the server again. My point is that to the unwary user, this kind of set up can make him locked out of the server, if local accounts are not allowed and sudo via ldap has not been set up yet.
DeleteYou do have a very interesting point. Thank you for bringing it forward. I should modify a blog post to include a safe no-matter-how-you-change-your-server's-authentication setup, you'll always be able to login.
ReplyDeleteOr at least warn the unwary user.
Once you understand how the authentication works, it's easier to play with it. As always, RTFM and test, test, test.
> I got bitten by this and I had to get into single user mode to change sshd_config so that I can control the server again.
Sorry mate :(
As you can imagine, these blog posts are not a trap. I don't work on these posts during the week-end to fool people I don't know into breaking their Linux machines. What would be the point?
Thanks for your input,
DA+
@Anonymous : I've modified the sshd_config files to include a warning about the AllowGroups configuration. The warning in the file's header is...
ReplyDelete# WARNING : This configuration restricts ssh access to the
# WARNING : groups listed in AllowGroups. Make sure your
# WARNING : user is part of at least one of those groups.
# WARNING : If not, YOU MAY BE LOCKED OUT OF YOUR SERVER.
# WARNING : If that happens, use the system's console.
If that warning was present in the files, do you think you would have avoided the problem when you first used the instructions in this blog post?
David
David,
ReplyDeleteTHANK you so much for taking your time to author these awesome blog posts on a topic that easily spans three ten pound tech manuals! This makes it so much easier for those of us who prefer learning by doing; combing through configs, tailing logs, and just getting down to the nitty gritty on a very complex topic.
Oh, and the "WARNING" comments for sshd_config are absolutely PRICELESS!! LOL!
-ACE
@ACE : Great! Glad you enjoy these posts. And thanks for the good words, I appreciate them :)
ReplyDeleteDA+
I'm having an existing Samba PDC with LDAP (using samba.schema) able to authenticate Windows users but mislead/astonish in authenticating to Linux as the clients. Do you have any ideas, comments or solutions? I believe it is same concepts on authenticating users and groups you have presented. Hope you can give me insights with it..
ReplyDelete@Ewann : I've never configured OpenLDAP with the samba.schema to authenticate Windows users. So be wary of my comments here ;)
DeleteI would start by making sure I log my OpenLDAP activities properly. That's done by setting « olcLogLevel » to « stats » in your cn=config. Then start a shell and issue a « sudo tail -F /var/log/slapd.log » (or whatever your slapd(8C) log file is). Keep that tail open and fire up another shell in which you try to authenticate a Linux user.
Of course, you have to configure your Linux machine to query the appropriate OpenLDAP distinguished name in order to fetch your OpenLDAP user's data (i.e. passwd, group and shadow). Instructions on how to configure your Linux machine are found in this blog post. Edit your /etc/nsswitch.conf file to use LDAP as the second source of information (after file) for group, shadow and password. This is important so as not to lock yourself out of your own Linux machine! Then make sure you can get the entire list of users and groups with the getent command. For exmaple, this command...
getent passwd
...should display the entire local /etc/passwd file AND your OpenLDAP users.
While this one...
getent group
...should output the entire /etc/group groups AND your OpenLDAP groups.
Don't forget to check if you can get the shadow data from your OpenLDAP server again using getent. Keep in mind that when you query shadow, you have to be root (or use sudo) and specify a user. You can't get the entire shadow data and getent will not complain if you try. For example, let's say the test.user is not found in your local /etc/shadow file and he's only in your OpenLDAP server, then this command...
sudo getent shadow test.user
...should display this OpenLDAP user's shadow information.
If any of those three getent command fail, you will not be able to authenticate users via your OpenLDAP server.
Each and every time you hit getent, check the logs on your OpenLDAP server. If you have more than one OpenLDAP server, then configure your test Linux machine to query only one them (or better : send all your OpenLDAP servers logs to a central syslog machine and check that machine's logs).
With this you should catch LDAP query errors and be able to rectify them.
Let me know how it goes?
HTH,
DA+
Thanks a lot David, you give me enough insights with it.
DeleteWhat I did, used to copy the samba server configuration to the client (testing only 1) but change the security = domain instead of user (in the server).
I can't see my logs, what do you mean by "setting « olcLogLevel » to « stats » in your cn=config. Then start a shell and issue a « sudo tail -F /var/log/slapd.log » (or whatever your slapd(8C) log file is)"?
If issue the command getent passwd --> I saw the users from the local and from the OpenLDAP same with the command getend group.
But for the getend shadow , no display for any user in the LDAP but for local it will display. I can't see logs except on the logs of my client.
#tail -F /var/log/samba/log.smbd
[2012/07/20 17:26:20.249671, 0] lib/smbldap.c:1180(smbldap_connect_system)
ldap_connect_system: Failed to retrieve password from secrets.tdb
2012/07/20 17:26:21.250435, 0] passdb/secrets.c:350(fetch_ldap_pw)
fetch_ldap_pw: neither ldap secret retrieved!
My question now is it automatically be retrieved the userPassword from a particular uid, in ou=users? A bit mislead.
Btw what I did, i used the join the member to my existing PDC
net rpc join -S -u then restart the smbd and the nmbd.
But if I issue this command,
#net ads info
ads_connect: No logon servers
ads_connect: No logon servers
Didn't find the ldap server!
Another command, it will display like this one
#net ads status -U Administrator
Enter Administrator's password:
ads_connect: No logon servers
ads_connect: No logon servers
Lastly on the server, i check it
#netstat -alxA unix | grep ldapi
no result(s).
Any idea?
@Ewann : Hello again and sorry for the late reply. I don't have much experience with Samba. In fact, I try to stay away from Samba as much as possible. But I understand it's a requirement at many sites (like where I just started! Note to self : read a good Samba book :)
DeleteFor this...
#netstat -alxA unix | grep ldapi
no result(s).
...I would check the /etc/sysconfig/ldap file to make sure the slapd daemon listens to a UNIX socket. Then restart slapd. This should be easy to fix.
Also check your /etc/nslcd.conf file. If you retrive userPassword from your OpenLDAP server, you may have to play with the schema settings for nslcd.
Finally, about this...
I can't see my logs, what do you mean by "setting « olcLogLevel » to « stats » in your cn=config. Then start a shell and issue a « sudo tail -F /var/log/slapd.log » (or whatever your slapd(8C) log file is)"?
...well I mean you need to make sure slapd has the appropriate log setting before you can debug.
Of course, if your LDAP repository is a Microsoft Active Directory machine, I won't be able to help you much! Just checking to make sure that is not the case :)
HTH,
DA+
This comment has been removed by the author.
ReplyDeleteHi,
ReplyDeleteI keep getting these 2 errors on my client pc's
ldap_sasl_bind(SIMPLE): Can't contact LDAP server(-1)
and ldap_sasl_interactive_bind_s: Can't contact LDAP server(-1)
@Hubert : Hi, I'm going to need a lot more information in order to help you. What commands return which error would be a good start. Cheers!
DeleteWhen I run
Deleteldapsearch -xZLLLWD cn=nssproxy,ou=users,dc=company,dc=com -b dc=company,dc=com -H ldap://alice.company.com:389
the error i get is ldap_sasl_bind(SIMPLE): Can't contact LDAP server(-1)
When I run
Deleteldapsearch -xZLLLWD cn=nssproxy,ou=users,dc=company,dc=com -b dc=company,dc=com -H ldap://alice.company.com:389
the error i get is ldap_start_tls: Can't contact LDAP server(-1)
@Hubert : Sorry for the very late post. I was away in vacation!
DeleteIt's strange, because both your queries are identical, but yet you have two different errors?!
I'd first check if your daemon has SSL enabled. Check the /etc/sysconfig/ldap file, make sure it has this enabled :
# Enable various slapd interfaces.
SLAPD_LDAP=yes
SLAPD_LDAPI=yes
SLAPD_LDAPS=no
Also be sure you're TLS configuration is ok? Check the configuration with this command (make sure you run this from the local OpenLDAP server and that you issue it as root via sudo)
sudo ldapsearch -LLLY EXTERNAL -b cn=config -H ldapi:/// -s base | grep -i olctls
olcTLSCACertificateFile: /etc/pki/tls/certs/companyCA.crt
olcTLSCertificateFile: /etc/pki/tls/certs/alice.company.com.pem
olcTLSCertificateKeyFile: /etc/pki/tls/certs/alice.company.com.key
olcTLSVerifyClient: never
Then make sure all the files listed there exist and have the following permissions :
-rw-r--r--. 1 root root 1326 Apr 24 14:08 /etc/pki/tls/certs/companyCA.crt
-rw-r--r--. 1 ldap ldap 1952 May 23 14:08 /etc/pki/tls/certs/alice.company.com.pem
-rw-------. 1 ldap ldap 1708 May 23 13:53 /etc/pki/tls/certs/alice.company.com.key
Then restart slapd(8) with this...
sudo /etc/init.d/slapd restart
Check your log file /var/log/slapd.log and test again. What do you have?
HTH,
DA+
Hi, great blog..this has been such a relief. Just a little question though
ReplyDeleteWhen i run getent passwd test.user nothing happens. I have made all the changes to the nsswitch.conf.
> Hi, great blog..this has been such a relief
DeleteThanks! Glad I could help.
> When i run getent passwd test.user nothing happens.
Well, let's start by the basic : do you have a test.user in your OpenLDAP server? If so, is it in the same ou=users,dc=company,dc=com as the others? And is your /etc/openldap/ldap.conf correctly configured? Can you getent passwd other OpenLDAP users?
DA+
Yes, there's test.user in my OpenLDAP server, I can see it in my phpldapadmin page. My ldap.conf is configured exactly like you said, but I can't getent passwd on any user.
ReplyDeleteOk, next step is to check if the OpenLDAP user cn=test.user has the proper LDAP attributes. But which attributes do we need exaclty? Well, that's easy to find out. We start by making sure our olcLogLevel is properly set. To find out, connect to your OpenLDAP server and issue this query :
Deletesudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -s base -b cn=config olcLogLevel
This will print your current log level settings. Mine is this...
olcLogLevel: stats sync
Now I like to keep « stats » in there. I also keep « sync » because I want to see the OpenLDAP replication service logs. If you don't have a replicated OpenLDAP server, you don't need sync. Ok, so now that we know that olcLogLevel has « stats » in it, we can start a shell to monitor our logs. While connected to your OpenLDAP server, issue this :
sudo tail -F /var/log/slapd.log
In another shell, query your shadow database. Don't forget that is you type this...
getent shadow test.user
...you will *never* have a result. Why? Simple : one needs to be root to be able to see the local /etc/shadow file right? It's the same for the OpenLDAP shadow data. So hit this...
sudo getent shadow test.user
...and you should get the intended result.
When you type the above command, the logs in your other shell should display the OpenLDAP stats. In there you will see the query that getent sent to slapd. This is it :
Jul 26 11:09:04 alice slapd[923]: conn=8491 op=3 SRCH base="ou=users,dc=company,dc=com" scope=2 deref=0 filter="(&(objectClass=shadowAccount)(uid=test.user))"
Jul 26 11:09:04 king slapd[923]: conn=8491 op=3 SRCH attr=shadowFlag shadowMin shadowMax userPassword shadowWarning shadowInactive uid shadowExpire shadowLastChange
The first line tells us the we need the « shadowAccount » objectClass. The second line shows us the required LDAP attributes (i.e. shadowFlag shadowMin shadowMax userPassword shadowWarning shadowInactive uid shadowExpire shadowLastChange).
We can now double-check if our OpenLDAP cn=test.user has the appropriate objectClass and attributes. Still on your OpenLDAP machine, issue this query...
sudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -b cn=test.user,ou=users,dc=company,dc=com
...and you should see something like this :
dn: cn=test.user,ou=users,dc=caprion,dc=com
uid: test.user
gecos: Test User
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
shadowMin: 0
shadowMax: 99999
shadowWarning: 7
homeDirectory: /nfs/home/test.user
cn: test.user
userPassword:: TTN0NGwxbmsh
shadowLastChange: 15474
loginShell: /bin/bash
gidNumber: 5007
uidNumber: 5007
As you can see, we have the « objectClass: shadowAccount » which is required by getent. We also have the various « shadow » attributes listed above.
If you don't have all this, then it won't work.
HTH,
DA+
When I run sudo ldapmodify -a -H ldapi:/// -f ~/ldap/posixAccount.indexes.ldif, it requires a password, and every password I type returns :
ReplyDeleteldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: SASL(-13): user not found: no secret in database
Same with me Kwesi with different errors
DeleteSASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_0' not found)
what I did was to modify the command
ldapmodify -xZWD cn=admin,dc=company,dc=com -f posixAccount.indexes.ldif
I found that it can also added on the slapd.conf (before coming up to this, what I did create a script that will do from scratch).
David I now solve my problems before with solving it in reverse, meaning your tutorial #3 then back to tutorial #2, because by default the client (which is also the host) not yet configured to use the OpenLDAP which generates errors. Thank you for this most useful tutorials.
(I'm back from busy work... hope it helps).
Hello Ambot Lang,
DeleteGood to know your OpenLDAP setup now works. I'm curious to know what you did to fix it exactly. As other people seem to have the same error you had on your first post. And what is the content of the script you created?
Thanks for the good words :)
Cheers,
DA+
Hi, David
ReplyDeleteSorry for the long response, too busy at work coz of the new project. Then at home, we've been cut off our net (just flatting dunno how they manage it,at least this day reanimation jutsu release back to normal). For the script just follow your nice tutorials but I have to emphasize creating the certificates (which mostly including me got an error on the TLS/SSL connections and your tutorial uses MS Certreq command which not familiar with, not much fan of MS, in relation have you heard the story why the Peso Bill's wife is not happy, because of two reasons micro and soft, jk only)
this is optional you can modify /etc/pki/tls/openssl.cnf so you can make your life easier, by just pressing enter key. Just modify with _default see
https://www.dropbox.com/s/m68t5x0mzyxyupc/openssl.cnf
then you will see similar to this
Country Name (2 letter code) [PH]:
State or Province Name (full name) [Mindanao]:
Locality Name (eg, city) [Aurora]:
Organization Name (eg, company) [Ambot Lang Bisdak]:
Organizational Unit Name (eg, section) [Mga Lumad]:
Common Name (eg, your name or your server's hostname) [aurora.zamboanga.del.sur]:
Email Address [ambotlang@rocketmail.com]:
Here is the script:
rm -Rf CA
rm -f *.pem
./xCA.pl -newca
openssl req -new -nodes -keyout newreq.pem -out newreq.pem
./xCA.pl -sign
cp -f newcert.pem /etc/openldap/certs
cp -f newreq.pem /etc/openldap/certs
cp -f CA/cacert.pem /etc/openldap/certs
#testing where aurora.x.x.x:636 is your ldap
openssl s_client -connect aurora.zamboanga.del.sur:636 -showcerts -state -CAfile /etc/openldap/certs/cacert.pem
on the first 2 line of script it does
Delete the folder CA (check the xCA.pl see the next) if exist and all pem extensions
modify the following in the xCA.pl (an old script but very useful, courtesy of the authors)
here is the script
https://www.dropbox.com/s/ct99sahhtfjq0hy/xCA.pl
$CATOP="CA";
$CAKEY="cakey.pem";
$CAREQ="careq.pem";
$CACERT="cacert.pem";
note $CATOP you can specify a specific folder on it (absolute addressing),
for more info
http://www.openssl.org/docs/apps/CA.pl.html
on the slapd.conf add these files
TLSCertificateFile /etc/openldap/certs/newcert.pem
TLSCertificateKeyFile /etc/openldap/certs/newreq.pem
TLSCACertificateFile /etc/openldap/certs/cacert.pem
or if you don't want to start from scratch (it assumed ldap is running)
root@xxx#ldapmodify -Y EXTERNAL -H ldapi:///
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# input like follows
dn: cn=config
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/openldap/certs/newcert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/openldap/certs/newreq.pem
-
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/openldap/certs/cacert.pem
# Press "Ctrl+D" to quit/save
Just change the names to fit to your configurations. Hope it really helps to others.
Cheers!
Hi David,
ReplyDeleteI have previously configured LDAP with TLS and it worked on CentOS 6.2. Then I update the system using yum update, and it is now 6.3. My LDAP no longer works. I found that the 'nslcd' was removed and replaced with 'sssd'. What should I do to make LDAP/TLS work again?
Thanks in advance,
Hello Anonymous,
DeleteI find quite brutal to remove pam_ldap and nslcd in order to install sssd during the 6.2 > 6.3 upgrade. Sorry, it sure wasn't my call.
You now have two choices : a) setup sssd or b) remove sssd and reinstall pam_ldap + nslcd and reconfigure.
If you go with b) hopefully the configuration files should still be there with a .rpmnew or something. If you used RCS, then it should be easy to revert to the old setup.
I haven't done it yet. So I can't give you more precise information.
And I'm on vacation, so I'm not even supposed to check my computer :)
Good luck!
DA+
Hi David,
ReplyDeleteGreat set of blog postings! I'm happily ldaping across my enterprise now. I haven't had much time to research it just yet but when I implement the indexes my authentication breaks. When looking into it with ldapsearch I did notice that approximate queries worked but equals queries didn't. Also, when I added an & to the search it fell apart again (&(uid~=myuid)(objectClass~=posixAccount)). I almost complete guess is that this is because the indexes aren't defined for them (I haven't had time to tweak and experiment with this). Looking at the slapd.log this is the query that is run to find a user's account. I'm on CentOS 6.3 + Errata. If I come across the answer first I'll post it back but for now I wanted to let you and the other followers of this posting that there can potentially be an issue with the indexing.