Part 4 of 4 – SSSD Authentication: Known Problems and Troubleshooting Tips

Introduction In Part 3 of 4 – SSSD Linux Authentication: Implementation Step-by-Step Guideline I covered all the necessary step-by-step details on deploying SSSD, but nothing ever seems to go perfect the first time does it.  This is why I have included a final Part 4 that covers known problems I came across, though there could […]

Part 3 of 4 – SSSD Linux Authentication: Implementation Step-by-Step Guideline

Introduction In Part 2 of 4 – SSSD Linux Authentication: LDAP Identity Store Requirements all the aspects of the LDAP Identity Store requirements were covered. And before that in article Part 1 of 2 – SSSD Linux Authentication: Introduction and Architecture I covered an introduction and high-level architecture of SSSD, which will be very important […]

Part 2 of 4 – SSSD Linux Authentication: LDAP Identity Store Requirements

Introduction In Part 1 of 4 – SSSD Linux Authentication: Introduction and Architecture I covered an introduction on SSSD and an architecture overview with details on the flow of how it all works.  In this part I am going to cover the LDAP Identity Store details required for SSSD.   LDAP Identity Store Schema Requirements […]

Part 1 of 4 – SSSD Linux Authentication: Introduction and Architecture

Introduction This article provides the details needed to solve a real use case used to allow a user to authenticate to an Oracle Public Cloud Linux server in SaaS using a single or multiple LDAP Identity store that could be Active Directory 2012R2 (AD) or better, Oracle Internet Directory (OID), Oracle Unified Directory (OUD), Oracle […]

Quickly setup OpenLDAP on Oracle Linux 5

Sometimes you need an LDAP directory for testing but don’t need a heavy duty directory like OID, DSEE or OUD. In those cases OpenLDAP suits your needs and it’s a quick and easy install.

Last night someone pinged me and asked for help doing just that. I set it up, took some notes and thought I’d share them here.


[root@dogwoodvm ~]# yum install openldap-servers
Loaded plugins: rhnplugin, security
This system is not registered with ULN.
ULN support will be disabled.
Setting up Install Process
Resolving Dependencies
--> Running transaction check

...etc...

Installed:
openldap-servers.x86_64 0:2.3.43-12.el5_5.3

Dependency Installed:
libtool-ltdl.x86_64 0:1.5.22-7.el5_4

Complete!

You can find the config files in /etc/openldap


[root@dogwoodvm ~]# cd /etc/openldap/
[root@dogwoodvm openldap]# ls
cacerts DB_CONFIG.example ldap.conf schema slapd.conf

Make a backup of slapd.conf and then edit the original.
Duplicate these lines and then comment out one of the pair:


#suffix "dc=my-domain,dc=com"
#rootdn "cn=Manager,dc=my-domain,dc=com"

Then edit the duplicates you made to reflect your environment. I want the root of my directory to be “dc=oracleateam,dc=com” and the super user account needs to be inside that root. So my config looks like:


suffix "dc=oracleateam,dc=com"
rootdn "cn=Manager,dc=oracleateam,dc=com"

You will also need to pick and set the password for that account. A few lines later you’ll see this:


# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpw secret
# rootpw {crypt}ijFYNcSNctBYg

By default the OpenLDAP RPMs ship with the password disabled. In order to allow the administrator to connect and manage the directory contents you need to add a line like so:


rootpw ABcd1234

If this were a real environment you wouldn’t want to put the password in the clear there, but since this is just for testing it’s fine. If you want to be more secure even for testing use the slappasswd account to hash the password before pasting it into the slapd.conf file.

Side note: I always use the password ABcd1234 for my test environments – it’s 8 characters long, contains uppercase letters, lowercase letters and numbers. It’s a weak password but it meets virtually every default password policy I’ve encountered.

Save the file and then start the OpenLDAP server:


[root@dogwoodvm openldap]# service ldap start
Checking configuration files for slapd: config file testing succeeded
[ OK ]
Starting slapd: [ OK ]

If you want the OpenLDAP server to start automatically on boot use chkconfig to do that:


[root@dogwoodvm openldap]# chkconfig --level 35 ldap on
[root@dogwoodvm openldap]# chkconfig --list ldap
ldap 0:off 1:off 2:off 3:on 4:off 5:on 6:off

Once you’ve done that you need to actually create the directory root objects inside the directory. To do that you can use a graphical LDAP editor or just use the command line ldapmodify tool.


[root@dogwoodvm openldap]# yum install openldap-clients
Loaded plugins: rhnplugin, security
This system is not registered with ULN.
ULN support will be disabled.
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package openldap-clients.x86_64 0:2.3.43-12.el5_5.3 set to be updated
--> Finished Dependency Resolution
... etc ...
Installed:
openldap-clients.x86_64 0:2.3.43-12.el5_5.3

Complete!

Then use ldapmodify to create the entries.
Run the command:


[root@dogwoodvm openldap]# ldapmodify -D 'cn=Manager,dc=oracleateam,dc=com' -w ABcd1234 -x

Then paste the entry in


dn: dc=oracleateam,dc=com
changetype: add
objectClass: dcObject
objectClass: organizationalUnit
dc: oracleateam
ou: rootobject
description: LDAP Admin

and hit return to leave a blank line. The command should come back and tell you that it’s adding an entry, like so:


adding new entry "dc=oracleateam,dc=com"

Then create the Organizational Units (ou) for People and Groups if you want them by pasting these in and hitting return after:


dn: ou=People, dc=oracleateam,dc=com
changetype: add
objectClass: organizationalUnit
ou: People
description: Users

dn: ou=Groups, dc=oracleateam,dc=com
changetype: add
objectClass: organizationalUnit
ou: Groups
description: Groups

Hit ctrl-d to exit and you’re done.