This tutorial explains how you can set up centralised LDAP authentication for a network, covering both the setting up of the LDAP server and client. Whilst based on Fedora 13, it may also apply to other versions.
That’s right, Fedora 13, so I haven’t tested this on Fedora 19 or 20… many things have changed, but something might still be useful.
LDAP stands for Lightweight Directory Access Protocol, which is a computer protocol for querying and modifying a database backed directory service. While Fedora ships its own LDAP based server (389 Directory Server), we will be using the OpenLDAP implementation, with Berkley Database (bdb) as the database backend. Data is entered into the LDAP server via plain text LDIF (LDAP Data Interchange Format) files. We will use a set of perl scripts from the migrationtools package to create most of these for us, but we will also create a few manually for adding a new user and group.
Finally, there are probably better (and more Fedora-specific) ways to do some of these tasks. If so, please let me know!
Note: For the purposes of this how to, our domain is test.lan and our LDAP server is server.test.lan – replace this with your server details instead!
Outline
The outline of steps is as follows:
- Install required packages.
- Configure the LDAP server configuration file for our domain, test.lan (dc=test,dc=lan).
- Configure the LDAP server to use TLS encryption, using a self-signed certificate.
- Start the LDAP server and test.
- Create LDIF files of our base domain, users and groups using migration tools.
- Populate the LDAP server using LDIF files.
- Configure clients to authenticate to LDAP server over secure channel.
- Configuring password policy (contributed by Sunil Tumma).
Prerequisites
This how to assumes you have performed a standard Fedora install, or a base install with relevant configuration tools installed.
- Networking is configured (see below).
- DNS is working, or at least you can resolve the LDAP server’s FQDN (fully qualified domain name), i.e. server.test.lan.
- You have the (awesome) text editor vim installed (if not, substitute and edit as required).
Disable NetworkManager
First, you may wish to use standard network configuration rather than NetworkManager on the server.
If so, let’s become root, disable NetworkManager and tell it to not start automatically on boot.
[user@server ~]$ su -
[root@server ~]$ service NetworkManager stop
[root@server ~]$ chkconfig NetworkManager off
Enable standard networking
Next we enable the standard networking daemon and tell it to start automatically on boot.
[root@server ~]$ service network start
[root@server ~]$ chkconfig network on
Now you’ll need to configure networking, which you can do via the graphical tool.
[root@server ~]$ system-configure-network-gui
Set eth0 (or your network device) to be static/use DHCP, whatever is required by your network setup, by selecting it and clicking edit.
Finally, activate the device and close the tool.
[[Image:fedora-network-client-config.png|thumb|500px|none|Fedora – configure networking]]
Now that your network is configured, let’s get started with LDAP!
Let’s begin!
As we need to run lots of commands on the LDAP server, it’s easier to to this as root.
If you’re not yet root, become so.
[user@server ~]$ su -
Install packages
We must install the required packages. The first is the LDAP server itself, the second is a set of perl scripts which help us create LDIF files for populating the LDAP server.
[root@server ~]$ yum install openldap-servers migrationtools
Create admin password
There is an all-powerful root LDAP user which will populate our directory. Rather than publishing this password in cleartext with in the configuration file, we want to encrypt it.
To do so, we run the slappasswd command, which will encrypt our password and return the value.
[root@server ~]$ slappasswd
New password:
Re-enter new password:
{SSHA}MP0BeMJzmCoCi5olBhwcRDYJaGBFgN5K
Copy the final encrypted output (i.e. {SSHA}MP0BeMJzmCoCi5olBhwcRDYJaGBFgN5K) for use in the next section.
Configuration
Previously, OpenLDAP was previously managed via a single configuration file (/etc/openldap/slapd.conf), however these days the configuration for LDAP is stored inside the LDAP server itself! As such, the configuration is done by editing LDIF files under the /etc/openldap/slapd.d/ directory.
Fedora supports both methods. We can either delete the slapd.d directory and use a slapd.conf file, or go along with the new method and edit the LDIF files before starting up our LDAP server.
Config file
If you wish to use the config file (which some will find easier), then follow these instructions.
Remove the existing slapd.d directory (else Fedora will not read our configuration).
[root@server ~]$ rm -Rf /etc/openldap/slapd.d/
Create a new config file from the existing template.
[root@server ~]$ cp -a /etc/openldap/slapd.conf.bak /etc/openldap/slapd.conf
Now that we have the base files in place, we need to begin configuring the file. We need to set several options, most importantly the domain (dc=test,dc=lan), and the admin password.
First, open it.
[root@server ~]$ vim /etc/openldap/slapd.conf
If you’re using Vim, just run the following command.
:%s/dc=my-domain,dc=com/dc=test,dc=lan/g
If not, find and set the following domain values
suffix "dc=test,dc=lan"
rootdn "cn=Manager,dc=test,dc=lan"
...
# allow only rootdn to read the monitor
access to *
by dn.exact="cn=Manager,dc=test,dc=lan" red
by * none
Next, we need to set the admin user’s password (which we generated earlier) and tell LDAP where to find the certificate and key for encryption (which we will create in a later step).
rootpw {SSHA}MP0BeMJzmCoCi5olBhwcRDYJaGBFgN5K
TLSCertificateFile: /etc/openldap/ssl/slapdcert.pem
TLSCertificateKeyFile: /etc/openldap/ssl/slapdkey.pem
Finally, save and quit the file.
:wq
Non-config file
Here’s now to edit the LDIF files under slapd.d to store the LDAP server configuration within LDAP (cn=config) itself.
The first of two LDIF files is the base database file.
[root@server ~]$ vim /etc/openldap/slapd.d/cn\=config/olcDatabase\=\{1\}bdb.ldif
If you’re using Vim, then just run the following.
:%s/dc=my-domain,dc=com/dc=test,dc=lan/g
Else, find and replace the following entry.
olcRootDN: dc=test,dc=lan
Now we must set the admin password and specify the location of our encryption certificate and key.
olcRootPW: {SSHA}ccFKiy8ska8IhNwwlaNYxiBNbilWe5M1
olcTLSCertificateFile /etc/openldap/ssl/slapdcert.pem
olcTLSCertificateKeyFile /etc/openldap/ssl/slapdkey.pem
Open the second file, which specifies monitoring privileges.
[root@server ~]$ vim /etc/openldap/slapd.d/cn\=config/olcDatabase\=\{2\}monitor.ldif
Once again, use Vim to replace the required entry.
:%s/cn=manager,dc=my-domain,dc=com/cn=Manager,dc=test,dc=lan/g
Or replace it yourself.
That’s it! Now you can continue with the how to.
Database cache
You should now have configured LDAP using either the single config file, or by specifying LDIF files. If not, see above.
Back at the terminal, copy a default DB_CONFIG file which sets cache and tuning options for the Berkley database backend (this also needs to be writeable by the ldap user).
[root@server ~]$ cp /usr/share/doc/openldap-servers-*/DB_CONFIG.example /var/lib/ldap/DB_CONFIG
[root@server ~]$ chown -Rf ldap:ldap /var/lib/ldap/
Test configuration
Lastly, test your configuration by running the command, and check return:
[root@server ~]$ slaptest -u
config file testing succeeded
That’s all the initial base configuration we should need to do! Next we will configure encryption.
Encryption (LDAPS) using TLS
Because we are using LDAP for authentication across a network, we want to encrypt the traffic. This means we can either run LDAP (on default port of 389) with TLS, or the LDAPS (on port 636) with TLS. We will do the latter.
We need to tell Fedora how to start the secure LDAP daemon, which is done by editing the sysconfig entry for ldap.
[root@server ~]$ vim /etc/sysconfig/ldap
Set the following:
SLAPD_LDAPS=yes
When the service is started, it will also run LDAP Secure (LDAPS).
Generate and configure keys
Now that we have told LDAP to run on secure port 636 we need to generate SSL keys and configure the LDAP service to use them!
Fedora has a script to automate this process, but it’s easy enough to generate the keys manually (when prompted, fill in the information as below, but replace the hostname with the FQDN of the LDAP server!).
[root@server ~]$ mkdir /etc/openldap/ssl/
[root@server ~]$ openssl req -new -x509 -nodes -out /etc/openldap/ssl/slapdcert.pem -keyout /etc/openldap/ssl/slapdkey.pem -days 365
Generating a 2048 bit RSA private key
....................................................+++
writing new private key to '/etc/openldap/ssl/slapdkey.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]: AU
State or Province Name (full name) []: ACT
Locality Name (eg, city) [Default City]: Canberra
Organization Name (eg, company) [Default Company Ltd]: Company
Organizational Unit Name (eg, section) []: Section
Common Name (eg, your name or your server's hostname) []: server.test.lan
Email Address []: user@test.lan
This will create the two required keys in the /etc/openldap/ssl/ directory, but we need to make sure that the ldap user can read them.
[root@server ~]$ chown -Rf root:ldap /etc/openldap/ssl
[root@server ~]$ chmod -Rf 750 /etc/openldap/ssl
We have already told the LDAP server to use them, so once we start the server it should be good to go!
Start LDAP service
It’s time to start the LDAP service, and tell it to start on bootup.
[root@server ~]$ service slapd start
Starting slapd: [ OK ]
Test that the server came up properly and is listening on the LDAPS port
[root@server ~]$ netstat -lt |grep ldap
tcp 0 0 *:ldap *:* LISTEN
tcp 0 0 *:ldaps *:* LISTEN
If so, tell Fedora to start the LDAP server on bootup.
[root@server ~]$ chkconfig slapd on
Test configuration
[root@server ~]$ ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: namingContexts
#
#
dn:
namingContexts: dc=test,dc=lan
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
This should returns a success, as above.
If all that went as planned, congratulations, you have a basic LDAP server configured! Next we need to populate this with our users and groups.
Configure base domain
We should now have a base LDAP server running, configured for our domain. However we do not have any users (People) or groups (Group) configured! We do that in the next step Now we need to set up our base, authentication and group files.
This is done via a migration of your existing local unix accounts already configured on the system, which are converted into an LDIF file for loading into LDAP. First however, we need to create a template base.ldif file which creates the base structure of our directory (test.lan), which we will import into LDAP database first.
[root@server ~]$ vim base.ldif
Add the following to the base.ldif file:
dn: dc=test,dc=lan
dc: test
objectClass: top
objectClass: domain
dn: ou=People,dc=test,dc=lan
ou: People
objectClass: top
objectClass: organizationalUnit
dn: ou=Group,dc=test,dc=lan
ou: Group
objectClass: top
objectClass: organizationalUnit
Now that we have the base information for our LDAP structure, we can (hopefully!) import that information into our LDAP database (use the password you created above):
[root@server ~]$ ldapadd -x -W -D "cn=Manager,dc=test,dc=lan" -f ./base.ldif
Enter LDAP Password:
adding new entry "dc=test,dc=lan"
adding new entry "ou=People,dc=test,dc=lan"
adding new entry "ou=Group,dc=test,dc=lan"
If you saw the above, then it worked! If you get an error about authentication issues connecting to my-domain.com then it’s not reading your configuration properly, and is using the default. Stop the service and start again.
Migrate users and groups
We are now going to use the migration tools to create ldif files for our existing users and groups, which we will import into LDAP like in the previous step.
First, tell the migration scripts which domain to use by default (we want to use test.lan instead of the default padl.com).
[root@server ~]$ vim /usr/share/migrationtools/migrate_common.ph
Set the following:
# Default DNS domain
$DEFAULT_MAIL_DOMAIN = "test.lan";
# Default base
$DEFAULT_BASE = "dc=test,dc=lan";
Users (People)
Now, we will use the migration script to create an ldif which we will use to populate LDAP with all our existing users (note, this will pull in the user account).
[root@server ~]$ /usr/share/migrationtools/migrate_passwd.pl /etc/passwd people.ldif
Once you have the file, we can import the entries into LDAP:
[root@server ~]$ ldapadd -x -W -D "cn=Manager,dc=test,dc=lan" -f people.ldif
Groups (Group)
Now, we will use the migration script to create an ldif which we will use to populate LDAP with all our existing groups (note, this will pull in the user group).
[root@server ~]$ /usr/share/migrationtools/migrate_group.pl /etc/group group.ldif
Once you have the file, we can import the entries into LDAP:
[root@server ~]$ ldapadd -x -W -D "cn=Manager,dc=test,dc=lan" -f group.ldif
Test contents of LDAP database
Now, we have our database populated with info. It’s time to test our work. First, you can use the ldapsearch command to look for your username. You should get a successful response back, as below.
[root@server ~]$ ldapsearch -xWD “cn=Manager,dc=test,dc=lan” -b “dc=test,dc=lan” “cn=user”
# extended LDIF
#
...
# user, Group, test.lan
dn: cn=user,ou=Group,dc=test,dc=lan
objectClass: posixGroup
objectClass: top
cn: user
userPassword:: E2NyeXB0fXG=
gidNumber: 500
# search result
search: 2
result: 0 Success
...
Adding a new user and group
To add a new user, we create an ldif for the user account, and the group. Then we import these into the LDAP server, like we did with the base, people and groups previously.
User
To add a user, simply create an ldif file (like chris.ldif) with contents like so:
dn: uid=chris,ou=People,dc=test,dc=lan
uid: chris
cn: Chris Smart
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$6$XemGNmMU9f3FRFo/vt7Uld/gUcP/2N7/R.uw5SK.
shadowLastChange: 14846
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 501
gidNumber: 501
homeDirectory: /home/chris
gecos: Chris Smart
Group
Then, add the group information for this user (like chris-group.ldif):
dn: cn=chris,ou=Group,dc=test,dc=lan
objectClass: posixGroup
objectClass: top
cn: chris
userPassword: {crypt}x
gidNumber: 501
Add to LDAP
Then add these into LDAP!
[root@server ~]$ ldapadd -x -W -D "cn=Manager,dc=test,dc=lan" -f chris.ldif
Enter LDAP Password:
adding new entry "uid=chris,ou=People,dc=test,dc=lan"
[root@server ~]$ ldapadd -x -W -D "cn=Manager,dc=test,dc=lan" -f chris-group.ldif
Enter LDAP Password:
adding new entry "cn=chris,ou=Group,dc=test,dc=lan"
Now you have a new user called chris!
Client Configuration
Now that we have a server which is responding correctly, we can configure our clients to authenticate to the LDAP server.
For Fedora machines, authconfig-gtk or authconfig-tui:
[root@server ~]$ authconfig-gtk
In the tool, select and fill in the details below.
User Account Configuration
User Account Database: LDAP
LDAP Search Base DN: dc=test,dc=lan
LDAP Server: ldaps://server.test.lan
Authentication Configuration
Authentication Method: LDAP Password
[[File:fedora-client-ldap-config.png|thumb|500px|none|LDAP Client Authentication]]
Now, we need to tell Fedora the location of the encryption certificate. Click on Download CA Certificate and pass the location of the file.
Note: If this is a local machine, you can use file://, however if it’s a remote machine, you’ll need to put the certificate on an NFS, FTP or HTTP share.
[[File:fedora-client-ldap-cacert.png|thumb|500px|none|LDAP Client Authentication – location of certificate]]
On the Advanced Options tab, tick Create home directories on the first login – else although users can authenticate, they won’t have a home directory when they log in!
[[File:fedora-client-ldap-config-2.png|thumb|500px|none|LDAP Client Authentication – create home directories]]
Hit Apply and we should now be able to log in as our users!
Test
Of course, to test this you can just log out and back in, but a quicker way (in case something’s not right) is to open a non-root terminal and switch to the new user you created (i.e. chris as above).
[user@server ~]$ su - chris
This should ask for chris’ password and if everything’s working correctly, you should be able to switch to this user.
If it fails, check your /var/log/messages to see if there are some helpful errors.
The following has been contributed by Sunil Tumma:
OpenLDAP with ppolicy
Overlays are dynamically configurable modules that provide additional functionality to OpenLDAP. The ppolicy overlay provides some useful functionalities for enforcing a password policy for the domain.
Requirement was the following
- Account should be locked out after 5 failed authentication attempts
- Password expiration on 90 days
- Minimum password length of 8
All of our desktops were authenticating to the OpenLDAP server (test.lan) which was setup on a CentOS box. We were able to achieve the 99999 days password expiration using the default shadowAccount objectClass as given below.
# test, People, test.lan
dn: uid=test,ou=People,dc=test,dc=lan
uid: test
cn: test
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword:: e2NyeXB0fSQxJEMzOxxxxxxxxxx
shadowLastChange: 15140
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 1000
gidNumber: 1000
homeDirectory: /home/test
But we couldn’t find any way to implement the password expirartion and password length polcies using the default OpenLDAP configuration. So I started my experiments with password policy (ppolicy) overlays. The ppolicy overlay provides enhanced password management capabilities that are applied to non-rootdn bind attempts in OpenLDAP.
Installation
The ppolicy and other overlays are included in the package openldap-servers-overlays for Redhat/CentOS servers. So we need first install this package assuming OpenLDAP server and dependencies are already installed.
yum install openldap-servers-overlays
The ppolicy module file should get installed at /usr/lib64/openldap/ppolicy.la and schema file at /etc/openldap/schema/ppolicy.schema on a 64 bit CentOS/Redhat server and in the /usr/lib/openldap/ directory on a 32bit i686 server.
Server Configuration
We need to configure the ppolicy overlays now. Add the following lines to /etc/openldap/slapd.conf in the respective sections.
include /etc/openldap/schema/ppolicy.schema
modulepath /usr/lib64/openldap
moduleload ppolicy.la
This is assuming that ppolicy overlay files are in respective locations. The ACL’s should be set such that clients bind to OpenLDAP server by self-authentication. We should not allow anonymous or rootdn binds to the server although the default configuration is to allow anonymous binds to server. So I added ACL as given below in the ACL section of slapd.conf.
#ACL
access to attrs=userPassword
by self =xw
by anonymous auth
by * none
access to *
by self write
by * read
Next we need to add default password policy we are going to enforce on the domain. Add the following after the DB section in slapd.conf.
overlay ppolicy
ppolicy_default "cn=default,ou=policies,dc=test,dc=lan"
ppolicy_use_lockout
This should complete the configuration of slapd.conf. You should be able to restart the LDAP server without any issues now.
Importing the password policy
Create a LDIF file called password-policy.ldif with following content:
dn: ou=policies,dc=test,dc=lan
ou: policies
objectClass: top
objectClass: organizationalUnit
# default, policies, test.lan
dn: cn=default,ou=policies,dc=test,dc=lan
objectClass: top
objectClass: device
objectClass: pwdPolicy
cn: default
pwdAttribute: userPassword
pwdMaxAge: 7776002
pwdExpireWarning: 432000
pwdInHistory: 3
pwdCheckQuality: 1
pwdMinLength: 8
pwdMaxFailure: 5
pwdLockout: TRUE
pwdLockoutDuration: 900
pwdGraceAuthNLimit: 0
pwdFailureCountInterval: 0
pwdMustChange: TRUE
pwdAllowUserChange: TRUE
pwdSafeModify: FALSE
This sets the following policies
- password expiration at 90 days
- password lockout on 5 failures and lockout duration of 15 mintues
- minimum password length of 8
- 3 earlier password in history
To import the policy run the following command:
ldapadd -D "cn=Manager,dc=test,dc=lan" -W -x -f password-policy.ldif
This ldapadd command should add to policy on authentication as LDAP administrator and we should be able to see the newly imported policy now when we do an ldapsearch.
ldapsearch -x -D "cn=Manager,dc=test,dc=lan" -W -b "dc=test,dc=lan"
This completes the server configuration.
Client Side Configuartion
On the LDAP clients we need make the following change in LDAP client configuration file /etc/ldap.conf assuming the client was configured to authenticate to our LDAP server before. Uncomment the pam_lookup_policy line which should be already there in /etc/ldap.conf, to enable it:
pam_lookup_policy yes
Now the password policy should be enforced for all non-rootdn authentication attempts.
Licensed under Creative Commons 3.0 non-ported license.
162 thoughts on “OpenLDAP How To (Fedora)”
We have successfully installed a Centos 6.2 box, which authenticates to a non-encrypted LDAP server. Trying the same thing with a 6.2 client, however, does not work. The client can talk to the server, and return user information (“getent passwd username” works), but users can’t log in from the console, or via ssh. Any ideas about what is the issue
I have successfully installed a Centos 6.2 box, which authenticates to a non-encrypted LDAP server. Trying the same thing with a 6.2 client, however, does not work. The client can talk to the server, and return user information (“getent passwd username” works), but users can’t log in from the console, or via ssh. Any ideas about what is the issue.
I mean, as root, switch to test4, not switch to root.
Hi Chris,
The problem has been resolved. Now i am able to login via ldap.
One more questions.
How do i implement password policies on ldap server for users and groups.
I want to create below policies
1) Password Complexity
2) Password policy
3) Account lockout policy
4) Account expiry policy
5) Account disable policy
and want to implement folder level permissions, like we do in co in Microsoft Windows Server(Windows Active Directory).
Regards,
Sunil Tumma
And is there in Windows client to integrate with CentOS openldap server.
I did delve into password policies, but can’t recall all the steps. There was a schema we had to use, from memory. I think I Google’d it and read some information out there. It wasn’t easy, IIRC.
Hi have configured the basic password policies on openldap server
but the policies are not applying on the client system, is there any setting to be done on the client side. client side i am using centos 6.2
If you have any references please share…
Ahh.. from memory you did have to set something in PAM? What online resource did you use to configure the password policies?
-c
Hi chris,
Thanks for your write-up on OpenLDAP as it helped me a lot. now i’m stranded at a point where, after following all the steps jotted here, while trying su – (new user entries added through an ldif to the base) says the below
su – pcuser
su: incorrect password
su – roz
su: user roz does not exist
Could you please share your thoughts on this? My LDAP client is running GNU/Linux and the OpenLDAP server runs on RHOS6.
What does
getent passwd
show? Can you see your users?Also, try switching to root first to bypass any password usses:
su -
su - pcuser
Hi Chris,
The password policies problem has been resolved.
Password Policies using overlay has been configured successfully and tested on CentOS client machines. Thanks for the help and procedure provided on this forum.
Still working on Windows authentication via ldap server using pGina client software.
Regards,
Sunil Tumma
Glad to hear it! Do you want to post how you did it? Then it might help others.
-c
Definitely Chris…
I’ve added it to the article here:
https://blog.christophersmart.com/articles/openldap-how-to-fedora/#ppolicy
Hi there Chris and Sunil. I setup LDAP in Ubuntu 10.04. Everything works fine ubuntu client able to login. But one thing that I’m trying to working out for morethan 2 months now is the passwordPolicy overlay. Its proven that “shadowAccount” is not enough, only shadowExpire attributes works. I really want to work is the “shadowWarning” wherein client will be inform that thier login authentication will soon expire so they have to change thier password. I’ve believe that “ppolicy overlay” is what I needed. I have succesfully add ppolicy in my cn=config. But its seems not working..
@ Sunil can you also sent me a copy of the procedure you made..
@ Chris pls help. thanks
Hi Kenji,
It’s now part of the how to:
https://blog.christophersmart.com/articles/openldap-how-to-fedora/#ppolicy
Hope that helps,
Chris
Hi Chris,
Can i configure multiple domains in Openldap. And can i configure the same user can authenticate with multiple domains.
Regards,
Sunil Tumma
Hi Sunil,
Sorry I have no idea about that one and I’d have to Google it. My guess is no, because a user’s account is a part of a tree, and there would need to be some way to mirror parts of the trees, which might be possible but I don’t know.
-c
Thanks for the reply.
Yes this is not possible. User can login into individual domain with their individual credentials.
I’m trying to get ppolicy setup, but I’m hitting a wall here.
Running CentOS 6.4, OpenLDAP 2.4.23.
I’ve followed a few howtos today which all looked simular to this. However I cannot get LDAP to enforce the policy.
One thing that looks odd to me is how the policy gets looked up. According to the slapd log, the base is empty.
onn=1006 op=3 SRCH base=”” scope=0 deref=0 filter=”(?objectClass=passwordPolicy)”
However If i manually bind as the user and update my passwd with an ldif, it has no problem letting me set my password to 1234.
Any pointers?
Hi Chris,
I am having problems with SSH and SSSD authentication. I am able to use su – ldapuser but I am not able to login via ssh.
According to /var/log/secure, ldapuser is not in AllowedUser (which is true). However, I wouldn’t want to modify it and I want sshd to refer to the LDAP server alone to know who’s allowed to use ssh. Is there a way to do this?
Ahh.. yes you need to configure ssh to allow it although I can’t remember off the top of my head.
Do you have any ldap entries in your /etc/pam.d/sshd file?
-c
Hi Chris,
How r u?
Can you please remove the website link from my profile..
Regards,
Sunil Tumma
Hi Sunil,
Fine thanks, hope you’re well! I don’t use profiles on my blog, but I’ve gone through all your comments and removed your URL.. should be gone now.
Cheers,
Chris
Hi Chris,
I am trying to implement the ppolicy in openldap-2.4.23 when i start the service of slapd it gives the error:—
overlay “ppolicy” not found
I test all the things according to your blog, but it couldn’t resolve.
I am using rhel-6.4
Any ideas about what is the issue?
Hey dheeraj, have you installed the overlays package?
yum install openldap-servers-overlays
-c
Sunil, I’m having the same problem where su – username works for an LDAP user, but I’m unable to SSH. Can you elaborate on how you resolved your issue?
Hi Brad,
sshd sources /etc/pam.d/password-auth so make sure you have ldap configured in there like in /etc/pam.d/system-auth.
-c
Hi Chris,
Many thanks for extensive article. I’m trying to configure LDAP authentication in Apache and facing troubles. Was really hard to imagine how server works. Now with this article I got the basic idea. The part with setting expiration of 99999 is a bit unclear to me but I guess I just have to have the opportunity to install ldap server myself to grasp the concept.
Wish you keep maintaining the good blog,
Best
Georgi
Hi Chris.
I am relatively new to the Linux OSs, so there might be some dumb questions in the middle (sorry in advance about that). Also sorry if my english is not the best. I’m running a Fedora 19 64 bits VM for testing purposes before doing it on a production server. The goal is to have a AD DC with openLDAP/Samba4.
I ran the following command to install openLDAP (as seen here: http://docs.fedoraproject.org/en-US/Fedora/18/html/System_Administrators_Guide/ch-Directory_Servers.html#s2-ldap-installation) along with the migrationtools
[root@localhost slapd.d]# yum install openldap* migrationtools
.
.
.
[root@localhost slapd.d]# rpm -qa | grep openldap
openldap-servers-2.4.36-4.fc19.i686
openldap-servers-sql-2.4.36-4.fc19.i686
openldap-2.4.36-4.fc19.i686
openldap-devel-2.4.36-4.fc19.i686
openldap-clients-2.4.36-4.fc19.i686
I created a root password with slappasswd, and wrote the output to use it in the configuration. Next I saw that my config files in the /etc/openldap/slapd.d/cn=config were slightly different:
[root@localhost slapd.d]# ll
drwxr-x---. 2 ldap ldap 4096 Nov 8 12:03 cn=schema
-rw-------. 1 ldap ldap 378 Nov 8 12:03 cn=schema.ldif
-rw-------. 1 ldap ldap 513 Nov 8 12:03 olcDatabase={0}config.ldif
-rw-------. 1 ldap ldap 408 Nov 8 12:03 olcDatabase={-1}frontend.ldif
-rw-------. 1 ldap ldap 562 Nov 8 12:03 olcDatabase={1}monitor.ldif
-rw-------. 1 ldap ldap 609 Nov 8 12:03 olcDatabase={2}hbd.ldif
I changed the names to …{1}hdb and …{2}monitor because I read that the numbers were the loading order or something alike, and in your guide they appear in that order, then changed the following files:
/etc/openldap/slapd.d/cn=config.ldif:
(at first I did this in olcDatabase={1}hdb.ldif but then I saw that the cn=config.ldif had the olcTLSCertificateFile and olcTLSCertificateKeyFile in it already)
#...
...
olcTLSCertificateFile: /etc/openldap/ssl/slapdcert.pem
olcTLSCertificateKeyFile: /etc/openldap/ssl/slapdkey.pem
...
/etc/openldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif:
#...
dn= olcDatabase={1}hdb
...
olcDatabase: {1}hdb
...
olcSuffix: dc=teste,dc=pt
olcRootDN: cn=Manager,dc=teste,dc=pt
olcRootPW: {SSHA}...
...
/etc/openldap/slapd.d/cn=config/olcDatabase={2}monitor.ldif:
#...
dn= olcDatabase={2}monitor
...
olcDatabase: {2}monitor
...
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external
,cn=auth" read by dn.base="cn=Manager,dc=teste,dc=pt" read by * none
...
Then, with:
[root@localhost slapd.d]# cp /usr/share/doc/openldap-servers-*/DB_CONFIG.example /var/lib/ldap/DB_CONFIG
it returned this:
cp: cannot stat '/usr/share/doc/openldap-servers-*/DB_CONFIG.example': No such file or directory
That’s when I went to check for it, and it wasn’t anywhere, but I read in another page that “The DB_CONFIG file will only be created if you have used the parameter olcDbConfig (dbconfig in slapd.conf)”. I thought that it was fine and proceeded to next step:
[root@localhost slapd.d]# chown -Rf ldap:ldap /var/lib/ldap
It didn’t return any error. Then with slaptest -u:
[root@localhost slapd.d]# slaptest -u
527d2ca1 ldif_read_file: checksum error on "/etc/openldap/slapd.d/cn=config.ldif"
527d2ca1 ldif_read_file: checksum error on "/etc/openldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif"
527d2ca1 ldif_read_file: checksum error on "/etc/openldap/slapd.d/cn=config/olcDatabase={2}monitor.ldif"
config file testing succeeded
I wonder what happened here, so I went to check all referred files, and found that /etc/openldap/ssl/ doesn’t exist:
[root@localhost slapd.d]# ls /etc/openldap/
certs check_password.conf ldap.conf schema slapd.d
[root@localhost slapd.d]# ls /etc/openldap/certs
cert8.db key3.db password secmod.db
Can you tell me with my info what can be the problem? Thanks in advance
You can set the expiration to be whatever you like.. that’s just a large number 🙂
-c
Hi,
I haven’t tested in Fedora 19, but my advice would be to try and get it working without SSL first. You can enable it later but it might stop you from seeing the cause of a problem when it isn’t working which can make it hard to fix.
As for the other things, I’d re-order your ldif files so that they are the defaults (my example is old).
DB_MONITOR isn’t necessary for actually getting openldap running, it just helps with indexing and speed later.
Also, your config files did seem to succeed, so you might be OK to keep going. I’d turn off SSL though if you get stuck.
Does the ldap server respond to the test queries in the howto?
-c
Hi Chris,
first I didn’t see that we needed to create the ssl folder and the permission files inside it, it’s done now. I started the service without any errors and the test output was nearly the same as yours (only difference in netstat):
[root@srvldap slapd.d]# ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts
# extended LDIF
#
# LDAPv3
# base with scope baseObject
# filter: (objectclass=*)
# requesting: namingContexts
#
#
dn:
namingContexts: dc=teste,dc=pt
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
[root@srvldap slapd.d]# netstat -lf | grep ldap
tcp 0 0 *:ldap *:* LISTEN
tcp6 0 0 [::]:ldap [::]:* LISTEN
After that I created the structure file:
nano base.ldif
dn: dc=teste,dc=pt
dc: teste
objectClass: top
objectClass: domain
dn: ou=People,dc=teste,dc=pt
ou: People
objectClass: top
objectClass: organizationalUnit
dn: ou=Group,dc=teste,dc=pt
ou: Group
objectClass: top
objectClass: organizationalUnit
And when I import, I get this error:
[root@srvldap slapd.d]# ldapadd -x -W -D "cn=Manager,dc=test,dc=lan" -f ./base.ldif
Enter LDAP Password:
adding new entry "dc=test,dc=lan"
ldap_add: Invalid syntax (21)
additional info: objectClass: value #1 invalid per syntax
So, as far as I can tell, LDAP’s not liking the “domain” objectClass. How can I turn this around?
I’va managed to add all entries by replacing domain by organization:
dn: dc=teste,dc=pt
o: teste
objectClass: dcObject
objectClass: organization
Forget that last comment, if I do that then I won’t be able to create the user list from /etc/passwd (at least I think it’s because of that)
Sorry to bother you again Chris, but I got stuck…
this is my base.ldif:
#Organization para teste
dn: dc=teste,dc=pt
objectClass: dcObject
objectClass: organization
dc: teste
o: teste
description: teste LDA
#Organizational Role para o administrador de directórios
dn: cn=Manager,dc=teste,dc=pt
objectClass: organizationalRole
cn: Manager
description: Administrador de Directórios
#Criar grupos de utilizadores
dn: ou=People,dc=teste,dc=pt
ou: People
objectClass: organizationalUnit
dn: ou=Group,dc=teste,dc=pt
ou: Group
objectClass: organizationalUnit
and this is the beggining of the people.ldif I got from migrate_passwd.pl /etc/passwd (it’s way too big to put it all here IMHO)
dn: uid=root,ou=People,dc=teste,dc=pt
uid: root
cn: root
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$6$BZUbuayVX4FPAqL2$ayxe.SqdOJj.ghCiRm0XT8JwLQI65rT5WZh2GH8yAGMbW0iH.emcnY1Pd2cCxAZTB4VP4M1A41520n.lbDVXj0
shadowLastChange: 16016
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 0
gidNumber: 0
homeDirectory: /root
gecos: root
dn: uid=bin,ou=People,dc=teste,dc=pt
uid: bin
cn: bin
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}*
shadowLastChange: 15863
shadowMax: 99999
shadowWarning: 7
loginShell: /sbin/nologin
uidNumber: 1
gidNumber: 1
homeDirectory: /bin
gecos: bin
[...]
The ldapadd (…) base.ldif works just fine, when I try:
ldapadd -x -W -D "cn=Manager,dc=teste,dc=pt" -f people.ldif
Enter LDAP Password:
adding new entry "uid=root,ou=People,dc=teste,dc=pt"
ldap_add: Invalid syntax (21)
additional info: objectClasses: value #0 invalid per syntax
For what I’ve been reading, the “additional info: objectClasses: value #0 invalid per syntax” means that the first field is incorrect, but if it is a generated file, it should be okay, right? :\ the more I read about this, the more confused I get :\
Done it 😀
In order to LDAP to recognize the classes that the migration builds for users (shadowAccount, posixAccount, etc), you need to import them from schemas (I used cosine and nis).
Nice one.. it must not be the default any more in the new ldif cn=config database? It used to be in the slapd.conf file..
-c
The only schema that LDAP uses as default in cn=config is core.schema (/etc/openldap/slapd.d/cn=config/cn=schema/cn={0}core.ldif), which is also why the entry “objectClass: domain” wasn’t working before.
I have applied password policy but it is not applied on users
Dec 23 16:50:16 ip-10-10-10-41 slapd[10367]: <= bdb_equality_candidates: (uid) not indexed
Dec 23 16:50:16 ip-10-10-10-41 slapd[10367]: slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1
how to configure with webmin?? is the same? I still couldn’t connect..
Hello Chris,
Thanks very much for your step-by-step instructions. I was wondering if you knew of a way to identify an existing Openldap (2.4.23) installation to see if it is 32 or 64-bit please? It is something I have inherited from another team.
Hi Christopher, This is a great blog. I am using centos 6.0. Can all these be valid?
I have the problem in ldapadd for the base.ldif
I also have slapd.d directory. I learn here , i must delete the directory slapd.d.
if you can post the required configuration for centos 6.0 , it shall be really great.
It should be the same for CentOS 6. You don’t have to delete the slapd.d directory but you can if you want to use the config file. If you’re getting an error then maybe post that so we can see what’s going on.
Hi Scott, sorry for delay. I would use rpm to tell me
rpm -qa |grep openldap-servers
x86_64 is 64bit, i386 is 32bit.
Sorry not sure how to use webmin to configure openldap.. maybe try their forums or something.
Great tutorial!!!
Quick Question:
– Is it mandatory to use
OU=GROUP , OU=PEOPLE for assigning groups & users respectively?
Can I use OU=UNIX_GROUP OU=USERS?
– I want to use OU=PEOPLE for real users (objectClass: inetOrgPerson) and OU=GROUPS (objectClass: group) for groups of people ?
The objective is to use the same usernames for FreeRadius & Samba
I think it depends on how searching (perhaps the filter) of the LDAP tree. By default the system will search for “uid” as the unique key probably and it does this via searching down the domain. I’m sure that even if this is hard-coded you should be able to change it, perhaps in the client’s ldap.conf file, but I’m not sure. Would definitely be interested to hear how it goes for you 🙂
Hello Chris,
I have created 2 machines(CentOS) on VMware. I want one to work as server and another as client.
* I have installed all necessary packages(Openldap) on
both.
* Already Configure one as server as mentioned in your
blog.
* Now to configure client you have implemented all steps
on same machine because server can also work as client.
(If I am not wrong!)
* But what to do if I want another machine to work as
client. Have to follow same steps or anything else?
Totally confused.
I am a fresher to this ldap world. So pl.guide me.
I think I wrote it for both, but maybe some of the client packages are missing. On a base install of Fedora I think you already have the required packages though, so just try to follow from the configure client section with authconfig-gtk.