LDAP server (OpenLdap centos 7)

I claim that this will be the most complete tutorial you can find for free in Internet regarding setting up Ldap server in Linux (centos 7.2) and also setting up ldap client (login node) to authenticate against Ldap server.

Why Ldap Server

When a user want to log in to a Linux system, he needs to authenticate as a valid and active user with his Username and password. The authentication can happen with local system and as a result Linux system need to store the data locally in /etc/passwd and /ect/shadow files. It might be an option for a single system but for a cluster of systems, it is useless as it needs huge works for administration.

One way of solving this problem is to authenticate to a centralized database which is storing username and passwords of all users. In this way we need to configure each system to redirect the authentication process to the system which has a database. One of the best option exist for storing the data in a centralized database is LDAP directory. In this tutorial, I will install and configure free and Open-source Ldap server in Linux.

Concepts

There is a file format here called LDIF (ldap data interchange format) which is representing ldap data and commands. So basically we need to use the ldif file format to specify the data in ldap directory information tree beside using it for any modification to the ldap database. Using LDIF, LDAP changes are simple written within files with an arbitrary name and then fed into the LDAP system using one of the available management commands.

LDIF works using a basic key-value system, with one statement per-line. The key is on the left-hand side of a line followed by a colon (:) and a space. The space is important for the line to be read correctly. The value is then assigned on the right side. This format works well for LDAP’s attribute-heavy syntax, but can also be used to issue commands and provide instructions on how the content should be interpreted.

The new style ldap server that I will use here is using the slapd backend database to store the configuration. Usually the configuration database is residing in /etc/openldap/slapd.d/cn=config directory after installing the services as we will see later.

The slapd configuration is stored as a special LDAP directory with a predefined schema and DIT. There are specific objectClasses used to carry global configuration options, schema definitions, backend and database definitions, and assorted other items. A sample config tree is shown in Figure 5.1.

Installation and configuration

1. The LDAP server name (hostname)

ldap-master.hrouhani.org

2. Install all stuff

yum -y install *openldap* migrationtools

and as a result, following packages are installed:

collectd-openldap
migrationtools
openldap-clients
openldap-servers
openldap-servers-sql

The openldap-clients is not needed if you are planning to only install the server and user need to use another server as login node.

The main service which is Openldap is following daemon:

[root@jameson ~]# systemctl status slapd.service

Description: The default configuration of the ldap is stored on a file in /etc/openldap/slapd.d/cn=config.ldif which is offcourse the ldif file format. We can also change some settings related to the ldap server such as number of connections the server can support and some database settings in olcDatabase{2}bdb.ldif file which is also located at /etc/openldap/slapd.d/. This is the file that also contains the parameters like LDAP root user and the base DN.

3. Create a LDAP root passwd for administration purpose

[root@ldap-master ~]# slappasswd

New password: linux200
Re-enter new password:
{SSHA}zQzF9cxOeEVH77eV7cm1758BbCfHzLJc

We need to also save the SSHS line completely as we will use later.

Description: the file olcDatabase={2}bdb.ldif has the user account with full permission to change the information on the ldap database. The default username is called Manager and can be seene easily with following commnad:

# grep olcRootDN /etc/openldap/slapd.d/cn=config/olcDatabase={2}bdb.ldif
olcRootDN: cn=Manager,dc=my-domain,dc=com

We can change the above account (Manager) to what we prefer. In my case, I leave it as it is.

4. Edit the OpenLDAP Server Configuration

OpenLDAP server Configuration files are located in /etc/openldap/slapd.d/.
Go to cn=config directory under /etc/openldap/slapd.d/ and edit the “olcDatabase={2}hdb.ldif” for changing the configuration.

[root@jameson openldap]# cd /etc/openldap/slapd.d/cn\=config/

[root@jameson cn=config]# ls

cn=schema cn=schema.ldif olcDatabase={0}config.ldif olcDatabase={-1}frontend.ldif olcDatabase={1}monitor.ldif olcDatabase={2}hdb.ldif
[root@ldap-master cn=config]# vim olcDatabase\=\{2\}hdb.ldif
# AUTO-GENERATED FILE – DO NOT EDIT!! Use ldapmodify.
# CRC32 42c46d37
dn: olcDatabase={2}hdb
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {2}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=hrouhani,dc=org
olcRootDN: cn=Manager,dc=hrouhani,dc=org
olcDbIndex: objectClass eq,pres
olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub
structuralObjectClass: olcHdbConfig
entryUUID: cd3ee542-0e91-1036-9c22-5966947b520b
creatorsName: cn=config
createTimestamp: 20160914063959Z
entryCSN: 20160914063959.387335Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20160914063959Z
olcRootPW: {SSHA}zQzF9cxOeEVH77eV7cm1758BbCfHzLJc
olcTLSCertificateFile: /etc/pki/tls/certs/hrouhanildap.pem
olcTLSCertificateKeyFile: /etc/pki/tls/certs/hrouhanildapkey.pem

The oldRootPW is exactly the hash of our password that created in previous section. I simply copy and paste it here. The TLS certificates at the moment are empty. I just created a names for both of them and defined the directory, and I will create these files in next steps.

5. Providing the Monitor privileges

There is a file which basically defines who can have a access to monitor or simply have a read access to ldap database. By default, everybody has a read access. To change it and only give the Manager the read access, I will modify/etc/openldap/slapd.d/cn=config/olcDatabase={1}monitor.ldif file in line which is start with olcAccess.

[root@ldap-master cn=config]# vim olcDatabase={1}monitor.ldif

olcAccess: {0}to * by dn.base=”gidNumber=0+uidNumber=0,cn=peercred,cn=extern
al,cn=auth” read by dn.base=”cn=Manager,dc=hrouhani,dc=org” read by * none

6. Testing and verifying the configuration until this stage

(ignore checksum error for the moment)

[root@ldap-master cn=config]# slaptest -u

57d8fb37 ldif_read_file: checksum error on “/etc/openldap/slapd.d/cn=config/olcDatabase={1}monitor.ldif”
57d8fb37 ldif_read_file: checksum error on “/etc/openldap/slapd.d/cn=config/olcDatabase={2}hdb.ldif”
config file testing succeeded

we can now start the slap service:

[root@ldap-master cn=config]# systemctl start slapd.service

[root@ldap-master cn=config]# systemctl enable slapd.service

6. Configure the ldap database, first we copy the example config file.

[root@ldap-master cn=config]# cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG

[root@ldap-master cn=config]# chown -R ldap:ldap /var/lib/ldap/

[root@ ldap-master]# ll /var/lib/ldap/

total 532
-rw-r–r– 1 ldap ldap 2048 Sep 14 09:26 alock
-rw——- 1 ldap ldap 434176 Sep 14 09:26 __db.001
-rw——- 1 ldap ldap 57344 Sep 14 09:26 __db.002
-rw——- 1 ldap ldap 49152 Sep 14 09:26 __db.003
-rw-r–r– 1 ldap ldap 845 Sep 14 09:29 DB_CONFIG
-rw——- 1 ldap ldap 8192 Sep 14 09:26 dn2id.bdb
-rw——- 1 ldap ldap 32768 Sep 14 09:26 id2entry.bdb
-rw——- 1 ldap ldap 10485760 Sep 14 09:26 log.0000000001

7. Adding some Ldap schema

Description: LDAP schema is the definition of sets of related data objects. The schema defines both the attributes of the objects and their relationships.

We have lots of prepared schema which comes with openldap installation and can easily be copied to our ldap database. Following commands can be used for this purpose:

[root@linux1 cn=config]# ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/cosine.ldif
[root@linux1 cn=config]# ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/nis.ldif
[root@linux1 cn=config]# ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/inetorgperson.ldif

Description: There are lots of prepared schema in the following directory:

[root@ldap-master]# pwd

/etc/openldap/schema

by using above commands, the mentioned schemas are added to the following directory:

[root@jameson schema]# ll /etc/openldap/slapd.d/cn=config/cn=schema/

total 40
-rw——- 1 ldap ldap 15578 Sep 14 08:39 cn={0}core.ldif
-rw——- 1 ldap ldap 11455 Sep 14 09:36 cn={1}cosine.ldif
-rw——- 1 ldap ldap 6587 Sep 14 09:38 cn={2}nis.ldif
-rw——- 1 ldap ldap 2949 Sep 14 09:39 cn={3}inetorgperson.ldif

8. Creating the self-signed certificate

In previous steps, we have defined our self-signed certificate, but did not create them. We do it here now. We use “openssl req” command which mainly creates and processes certificate request in PKCS’10 format. It can additionally create self signed certificates for use as root CAs for example.

[root@ldap-master cn=schema]# openssl req -new -x509 -nodes -out /etc/pki/tls/certs/navastoldap.pem -keyout /etc/pki/tls/certs/navastoldapkey.pem -days 365

Options that I used:

-new :this option generates a new certificate request. It will prompt the user for the relevant field values. The actual fields prompted for and their maximum and minimum sizes are specified in the configuration file and any requested extensions. If the -key option is not used it will generate a new RSA private key using information specified in the configuration file.

-x509: this option outputs a self signed certificate instead of a certificate request. This is typically used to generate a test certificate or a self signed root CA .

-nodes: if this option is specified then if a private key is created it will not be encrypted.

-out filename: This specifies the output filename to write to or standard output by default.

-keyout filename: this gives the filename to write the newly created private key to. If this option is not specified then the filename present in the configuration file is used.

-days n: when the -x509 option is being used this specifies the number of days to certify the certificate for. The default is 30 days.

9. Migration tools : The MigrationTools are a set of Perl scripts for migrating users, groups, aliases, hosts, netgroups, networks, protocols, RPCs, and services from existing nameservices (flat files, NIS, and NetInfo) to LDAP format which has a ldif format.

It is for the sack of simplicity that we are planning to first create the users locally in system (/etc/passwd) and then we use the Migration tool to convert for example in our case the /etc/passwd into ldif file format. At the end we use the Openldap command (ldapadd) to add these ldif files to our Ldap Database.

All of the perl scripts which are coming with migration tool is located in /usr/share/migrationtools/ after installation in our case. We need to change some predefined values in the file “migrate_common.ph” according to our domain name, for that do the following:

The main file which we need to modify in this directory is migrate_common.ph which need to be modified:

# Default DNS domain (change your domain name)
$DEFAULT_MAIL_DOMAIN = “hrouhani.org”;
# Default base
$DEFAULT_BASE = “dc=hrouhani,dc=org”;
# such as person.
$EXTENDED_SCHEMA = 1;

The mail domain used for the mail attribute in migrate_passwd.pl when extended schema support is enabled.

9. Creating a base.ldif file: The use of OU (organizational unit) objects can help you in providing additional structure to the LDAP database. If you are planning on adding in different types of entries, such as users, groups, computers, printers and more to the LDAP directory, it makes it easier to put every entry type into its own container.

To create these OU’s, you can create an initial LDIF file as shown in the below example. In this example, this file allows you to create the base container which is dc=hrouhani,dc=org and it creates two organizational units with the names users and groups in that container.

we create a directory in /root/openldap and make a file base.ldif and fill it with:

[root@jameson openldap]# pwd

/root/openldap

[root@jameson openldap]# cat base.ldif

dn: dc=hrouhani,dc=org

objectClass: top

objectClass: dcObject

objectclass: organization

o: navasto de

dc: navasto

dn: cn=Manager,dc=hrouhani,dc=org

objectClass: organizationalRole

cn: Manager

description: Directory Manager

dn: ou=Users,dc=hrouhani,dc=org

objectClass: organizationalUnit

ou: Users

dn: ou=Groups,dc=hrouhani,dc=org

objectClass: organizationalUnit

ou: Groups

10. Now we can import the base.ldif file that we created in to the LDAP directory using the ldapadd command as shown below.

[root@jameson openldap]# ldapadd -x -W -D “cn=Manager,dc=hrouhani,dc=org” -f base.ldif

Enter LDAP Password:

adding new entry “dc=hrouhani,dc=org”

adding new entry “cn=Manager,dc=hrouhani,dc=org”

adding new entry “ou=Users,dc=hrouhani,dc=org”

adding new entry “ou=Groups,dc=hrouhani,dc=org”

11. Modifying one more time the migrate_common.ph in /usr/share/migrationtools/ that match our base.ldif file completely. In base.ldif file I specified Users and Groups that must be exist exactly in migrate_common.ph file since it will be used for creating the ldif related file format.

a. Changed People to users that when

$NAMINGCONTEXT{‘fstab’} = “ou=Mounts”;

#$NAMINGCONTEXT{‘passwd’} = “ou=People”;

$NAMINGCONTEXT{‘passwd’} = “ou=Users”;

Description: The reason for this changes from people to users is that when we use following command at the next steps: “./migrate_passwd.pl /root/ldap/files/passwd /root/ldap/users.ldif” it create the users in users ou by default and not in People ou.

b. Also we need to change the following line, from Group to Groups to match our base.ldif

$NAMINGCONTEXT{‘passwd’} = “ou=users”;

$NAMINGCONTEXT{‘netgroup_byuser’} = “nisMapName=netgroup.byuser”;

$NAMINGCONTEXT{‘netgroup_byhost’} = “nisMapName=netgroup.byhost”;

$NAMINGCONTEXT{‘group’} = “ou=Groups”;

12. Now we want to verify that the organization units (ou) that we added with base container (base.ldif) already exist, we can use following command:

[root@jameson openldap]# ldapsearch -x -W -D “cn=Manager,dc=hrouhani,dc=org” -b “dc=hrouhani,dc=org” “(objectclass=*)”

Enter LDAP Password:

# extended LDIF

# LDAPv3

# base <dc=hrouhani,dc=org> with scope subtree

# filter: (objectclass=*)

# requesting: ALL

# hrouhani.org

dn: dc=hrouhani,dc=org

objectClass: top

objectClass: dcObject

objectClass: organization

o: hrouhani org

dc: hrouhani

# Manager, hrouhani.org

dn: cn=Manager,dc=hrouhani,dc=org

objectClass: organizationalRole

cn: Manager

description: Directory Manager

# Users, hrouhani.org

dn: ou=Users,dc=hrouhani,dc=org

objectClass: organizationalUnit

ou: Users

# Groups, hrouhani.org

dn: ou=Groups,dc=hrouhani,dc=org

objectClass: organizationalUnit

ou: Groups

# search result

search: 2

result: 0 Success

# numResponses: 5

# numEntries: 4

13. Now the plan is to create users/groups inside the ldap database. For this purpose we need to first create a ldif file format out of usernames/passwords and the groups and then use ldapadd command to import it into the ldap directory. There are two solutions for this purpose, manual and automatic. I first go through manual way, even though I will not use it for our case.

a. Manual: We need to create ldif file format ourself for every entity that we want to insert to the ldap database. Here in our case, as an example I want to enter hrz user to the ldap database. So first we need to create an appropriate ldif file format for this purpose and then insert it with a command as we see later.

vim /root/ldap/hrz.ldif

# cat hrz.ldif
dn: uid=hrz,ou=users,dc=hrouhani,dc=org
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
cn: hrz
uid: hrz
uidNumber: 16859
gidNumber: 100
homeDirectory: /home/hrz
loginShell: /bin/bash
gecos: hrz
userPassword: {crypt}x
shadowLastChange: 0
shadowMax: 0
shadowWarning: 0

as we can see, I also specified the uid and gid for hrz account. And at the next step, I use following command to insert this user to the database.

ldapadd -x -W -D “cn=Manager,dc=hrouhani,dc=org” -f /dirofFile/hrz.ldif

and then we need separately add password for the LDAP user we just added.

# ldappasswd -s passwdHere -W -D "cn=Manager,dc=hrouhani,dc=org" -x "uid=hrz,ou=users,dc=hrouhani,dc=org"

Description:

-s specify the password for the username entry

-x The username entry for which the password is changed

-D specify your DN here. i.e Distinguished name to authenticate in the server

Similar to adding user, we also need a ldif file to add a group. To add a new group to the LDAP groups OU, you need to create a LDIF with the group information as shown in the example ldif file below.

# cat hrzgroup.ldif
dn: cn=hrzgroup,ou=users,dc=hrouhani,dc=org
objectClass: top
objectClass: posixGroup
gidNumber: 678

Just like adding user, use ldapadd command to add the group from the hrzgroup.ldif file that we created above.

# ldapadd -x -W -D "cn=Manager,dc=hrouhani,dc=org" -f hrzgroup.ldif

b. Automatic: As we have seen, the above way of doing is not easy and we need to create ldif file for each user, group or any entity we want to add to the ldap directory. For automatic way, we take advantage of Migration tool and taking advantage of /etc/passwd and /etc/groups. So in summary we create our users/groups as before locally in linux, and then using Migration tool to convert them them to ldap directory and finally insert it to the ldap database.

First we create local user

[root@ldap-master ~]# useradd hrz1

[root@ldap-master ~]# useradd hrz2

[root@ldap-master ~]# passwd hrz1

Changing password for user transtec1.

New password: linux101

BAD PASSWORD: The password fails the dictionary check – it is based on a dictionary word

Retype new password:

Sorry, passwords do not match.

New password:

BAD PASSWORD: The password fails the dictionary check – it is based on a dictionary word

Retype new password:

passwd: all authentication tokens updated successfully.

[root@ldap-master ~]# passwd hrz2

Changing password for user transtec2.

New password: linux102

BAD PASSWORD: The password fails the dictionary check – it is based on a dictionary word

Retype new password:

passwd: all authentication tokens updated successfully.

At the next step we need to save those lines of /etc/passwd and /etc/group that corresponding users need to be added to the ldap database. I use simply following grep command, however you can simply also copy and paste it.

[root@ldap-master ~]# grep “:10[0-9][0-9]” /etc/passwd > /root/ldap/passwd

[root@ldap-master ~]# grep “:10[0-9][0-9]” /etc/group > /root/ldap/group

[root@jameson ~]# cat /root/openldap/passwd

hrz1:x:1002:1002::/home/hrz1:/bin/bash

hrz2:x:1003:1003::/home/hrz2:/bin/bash

[root@jameson ~]# cat /root/openldap/group

hrz1:x:1002:

hrz2:x:1003:

And then we need to create a ldif file out of above files we created with using the migration tools.

[root@jameson migrationtools]# ./migrate_passwd.pl /root/openldap/passwd /root/openldap/ldifFiles/users.ldif

now we can see the content of the ldif file:

[root@jameson ~]# cat /root/openldap/ldifFiles/users.ldif

dn: uid=hrz1,ou=Users,dc=hrouhani,dc=org

uid: hrz1

cn: hrz1

sn: hrz1

mail: hrz1@hrouhani.org

objectClass: person

objectClass: organizationalPerson

objectClass: inetOrgPerson

objectClass: posixAccount

objectClass: top

objectClass: shadowAccount

userPassword: {crypt}$6$4U01yb.o$dVodNdvB9koD3/njmOY4S97/yWHWogodvmOn4C85Ln9KHv4jwADWYPYZlD8BAFQ54mhruvF5DJmYbZm0D77Of0

shadowLastChange: 17058

shadowMin: 0

shadowMax: 99999

shadowWarning: 7

loginShell: /bin/bash

uidNumber: 1002

gidNumber: 1002

homeDirectory: /home/hrz1

dn: uid=hrz2,ou=Users,dc=hrouhani,dc=org

uid: hrz2

cn: hrz2

sn: hrz2

mail: hrz2@hrouhani.org

objectClass: person

objectClass: organizationalPerson

objectClass: inetOrgPerson

objectClass: posixAccount

objectClass: top

objectClass: shadowAccount

userPassword: {crypt}$6$XM4e7Y0Y$9hS8.Ol9yUsTidGcpN6U4VYVZAFsJb.vbYjn7lvluLRb14NEoGB8/lIOpH2lcnnC/PRPR6y0gqnBy.76mhksA/

shadowLastChange: 17058

shadowMin: 0

shadowMax: 99999

shadowWarning: 7

loginShell: /bin/bash

uidNumber: 1003

gidNumber: 1003

homeDirectory: /home/hrz2

The important point is that the password also automatically by the migration script is moving to the ldif file format and later can be used to insert to the ldap database.

We doing the same thing for group

[root@jameson migrationtools]# ./migrate_group.pl /root/openldap/group /root/openldap/ldifFiles/groups.ldif

[root@jameson ~]# cat /root/openldap/ldifFiles/groups.ldif

dn: cn=hrz1,ou=Groups,dc=hrouhani,dc=org

objectClass: posixGroup

objectClass: top

cn: hrz1

userPassword: {crypt}x

gidNumber: 1002

dn: cn=hrz2,ou=Groups,dc=hrouhani,dc=org

objectClass: posixGroup

objectClass: top

cn: hrz2

userPassword: {crypt}x

gidNumber: 1003

and now that we have the proper ldif files for both users and groups, we can import them to the ldap database. For this as before we use the ldapadd command, however like option a, we do not need to add the password separately, since the ldif files has them included.

[root@jameson ~]# ldapadd -x -W -D “cn=Manager,dc=hrouhani,dc=org” -f /root/openldap/ldifFiles/users.ldif

Enter LDAP Password:

adding new entry “uid=hrz1,ou=Users,dc=hrouhani,dc=org”

adding new entry “uid=hrz2,ou=Users,dc=hrouhani,dc=org”

[root@jameson ~]# ldapadd -x -W -D “cn=Manager,dc=hrouhani,dc=org” -f /root/openldap/ldifFiles/groups.ldif

Enter LDAP Password:

adding new entry “cn=hrz1,ou=Groups,dc=hrouhani,dc=org”

adding new entry “cn=hrz2,ou=Groups,dc=hrouhani,dc=org”

14. Testing the configuration: There is 2 ways of testing, whether querying specific user from ldap database or querying all users

a. Querying special user

[root@jameson ~]# ldapsearch -x cn=hrz1 -b dc=hrouhani,dc=org

b. Querying all users

[root@ldap-master ~]# ldapsearch -x -b ‘dc=hrouhani,dc=hrz’ ‘(objectclass=*)’

15. Let say in some days we want to add new users into Ldap database. Its quite simple we can add them first locally to the system, and then cut them in a new file such as is in /root/ldap/files and the file passwd and group. We don’t need to keep the users that already added to the ldap, in this file (only new users) and then we create a New ldif files same as before. They can be also new ones and then add them as before.

*********************************************************************************************************************************************************************************************************************************************************

Login node configuration

There are 2 options for configuring the the Login node (ldap client), one is to use nslcd or sssd. [if the login node is the same as Master node which Openldap server has been installed, we need to do these stuff in the same server]

a. The nslcd is old solution and is not really advisable anymore, however can be easily being configured.

1. yum install -y openldap-clients nss-pam-ldapd

This is nss-pam-ldapd which provides a Name Service Switch (NSS) module that allows your LDAP server to provide user account, group, host name, alias, netgroup, and basically any other information that you would normally get from /etc flat files or NIS. It also provides a Pluggable Authentication Module (PAM) to do identity and authentication management with an LDAP server on unix systems.

This is implemented using thin NSS and PAM modules which delegate to a dedicated service (nslcd) that queries the LDAP server with persistent connections, authentication, attribute translation, etc.

The NSS module was originally a fork of nss_ldap with some structural design improvements. The most important features of nss-pam-ldapd are:

light and simple NSS and PAM libraries
avoid loading LDAP and SSL libraries in all programs
separation between NSS, PAM and LDAP code
fewer connections to the LDAP server
better debugging possibilities
better performance

and then we use following command:

authconfig –enableshadow –enablemd5 –enableforcelegacy –enableldap –enableldapauth –ldapserver=ldap://ldap-master.cluster.urz –ldapbasedn=dc=cluster,dc=urz –enablemkhomedir –update

b. SSSD option which has many advantages including the cashing capability. The System Security Services Daemon (SSSD ) provides access to different identity and authentication providers. I described properly the sssd in separate thread.

Installation and configuration:

1. yum install -y openldap-clients sssd nss-pam-ldapd.x86_64

In my system sssd has been installed by default so all of the following package are exist:

[root@login sssd]# yum list installed | grep -i sssd*

libsss_idmap.x86_64 1.13.0-40.el7_2.4

libsss_nss_idmap.x86_64 1.13.0-40.el7_2.4

python-sss-murmur.x86_64 1.13.0-40.el7_2.4

python-sssdconfig.noarch 1.13.0-40.el7_2.4

sssd.x86_64 1.13.0-40.el7_2.4

sssd-ad.x86_64 1.13.0-40.el7_2.4

sssd-client.x86_64 1.13.0-40.el7_2.4

sssd-common.x86_64 1.13.0-40.el7_2.4

sssd-common-pac.x86_64 1.13.0-40.el7_2.4

sssd-ipa.x86_64 1.13.0-40.el7_2.4

sssd-krb5.x86_64 1.13.0-40.el7_2.4

sssd-krb5-common.x86_64 1.13.0-40.el7_2.4

sssd-ldap.x86_64 1.13.0-40.el7_2.4

sssd-proxy.x86_64

The important point is that, our system should have a system-config-authentication utility for graphical and authconfig for command-line installed. In our case we have following

[root@login ~]# yum list installed | grep -i authconfig

authconfig.x86_64 6.2.8-10.el7

both of them (no matter which one to use) will change the content of /etc/sysconfig/authconfig and at the same time update/modify the related files.

2. DNS name.

If we don’t have DNS properly set that resolve the name of ldap server, we will add it to the /etc/hosts file:

172.16.1.144 ldap-master.hrouhani.org

3. Slelinux disabled on both server and login node and its status can be seen by following command:

[root@login ~]# cat /etc/sysconfig/selinux

# This file controls the state of SELinux on the system.

# SELINUX= can take one of these three values:

# enforcing – SELinux security policy is enforced.

# permissive – SELinux prints warnings instead of enforcing.

# disabled – No SELinux policy is loaded.

SELINUX=disabled

[root@login ~]# sestatus

SELinux status: disabled

4. Now we want to use the authconfi command. Check for an existing /etc/sssd/sssd.conf file. If this is a new installation where LDAP authentication has not been set up before the file will not exist, although the directory will.

[root@login ~]# authconfig –enableshadow –enablemd5 –enableforcelegacy –enablesssd –enablesssdauth –enableldap –enableldapauth –ldapserver=ldap://ldap-master.cluster.urz –disableldaptls –ldapbasedn=dc=cluster,dc=urz –enablemkhomedir –enablecachecreds –enablelocauthorize –update

so afterwads many new thing will be automatically added including sssd.conf file which is as follow:

[root@login ~]# cat /etc/sssd/sssd.conf

[domain/default]

#autofs_provider = ldap

cache_credentials = True

ldap_search_base = dc=hrouhani,dc=org

id_provider = ldap

auth_provider = ldap

chpass_provider = ldap

ldap_uri = ldap://ldap-master.hrouhani.org

ldap_id_use_start_tls = False

cache_credentials = True

#ldap_tls_cacertdir = /etc/openldap/cacerts

autofs_provider = ldap

ldap_tls_cacertdir = /etc/openldap/cacerts

[sssd]

#services = nss, pam, autofs

services = nss, pam, autofs

config_file_version = 2

domains = default

[nss]

homedir_substring = /home

[pam]

offline_credentials_expiration = 2

offline_failed_login_attempts = 3

offline_failed_login_delay = 5

If the sssd.conf file has not added automatically, simply copy and paste above file and store it for userself. If I am not mistaken you also need to take care of permission for this file.

what is important when we do getent passwd, we will see the users that we already created at Ldap system.

*********************************************

If you have other compute nodes that need to authenticate against our ldap server, you need to do the exact same steps as I did above. If you are using a management tools like xCAT and want to do it inside the image, can do following commands and just copy and paste needed files into the image.

yum –installroot=/install/netboot/centos7.2/x86_64/compute/rootimg/ install openldap-clients sssd nss-pam-ldapd.x86_64

yum –installroot=/install/netboot/centos7.2/x86_64/compute/rootimg/ install authconfig

rsync -av /etc/sssd/ /install/netboot/centos7.2/x86_64/compute/rootimg/etc/sssd/

rsync -av /etc/nsswitch.conf /install/netboot/centos7.2/x86_64/compute/rootimg/etc/

So we have following in compute node:

[root@node-01 ~]# cat /etc/sssd/sssd.conf

[domain/default]

#autofs_provider = ldap

cache_credentials = True

ldap_search_base = dc=hrouhani,dc=org

id_provider = ldap

auth_provider = ldap

chpass_provider = ldap

ldap_uri = ldap://10.0.0.254

ldap_id_use_start_tls = False

cache_credentials = True

#ldap_tls_cacertdir = /etc/openldap/cacerts

autofs_provider = ldap

ldap_tls_cacertdir = /etc/openldap/cacerts

[sssd]

#services = nss, pam, autofs

services = nss, pam, autofs

config_file_version = 2

domains = default

[nss]

homedir_substring = /home

[pam]

offline_credentials_expiration = 2

offline_failed_login_attempts = 3

offline_failed_login_delay = 5

[autofs]

Installation and configuration

Login node configuration

Share this:

Like this: