In the previous article we saw how to integrate Graylog with LDAP. In this section we will discuss about Linux client LDAP Integration.

What we will do ?

Based on our scenario, we will implement key based authentication to a linux client connected to LDAP. Like previous examples, two users will have access to the server. One of the user is an admin and will have sudo privileges. The other will be considered a Dev user, who has sudo access only to a specific application id ( appid )

We first need to create a separate group for managing access to servers. Let’s get our hands dirty and start doing it.

We have already got few containers and entries created in the previous section when we integrated Graylog with LDAP. We need to create the ones marked in dotted red boundaries in the diagram above.

Overcoming posixGroup and groupOfNames caveat

We will be creating server group objects of type posixGroup under ou=server container. The posixgroup is required to provide the translation between group id numbers and their name. We’ll be providing access to servers based on membership of the groups. posixGroup’s member attribute is called memberUID and simply lists the uid of the member. Using this alone, there’s really no solid way to identify the specific distinguished name of the group member.

The problem we have is, memberOf attribute is part of groupOfNames objectClass. We cannot use both posixGroup and groupOfNames together since both are STRUCTURAL objectClasses ( An entry can have only one STRUCTURAL object class ).

To overcome this, we need to create a custom objectClass that will be a clone of posixGroup but of type AUXILIARY instead of STRUCTURAL. Hence we will be able to use groupOfNames along with the custom posixGroup which is almost identical to posixGroup except the class type.

The posixGroup exists in nis schema and hence we’ll make the change there.

We are using customposixGroup and groupOfNames as objectClass. As part of creating this entry we are adding members to it. chris.sam is added as part of server_admin and aron.francis is added as part of server_dev group.

The gidNumber represents the Group id in the server. We are giving higher numbers for this to be safe from conflicting with the local gid’s in the server.

Implement the change by running the below command,

ldapadd -W -Z -D cn=admin,dc=devopsideas,dc=com -f server_group.ldif

We have now completed adding group entries inside ou=server container.

Service id for Linux Client binding

Create a service id cn=serverid,ou=service_ids,dc=devopsideas,dc=com, for binding LDAP clients. Since we need to specify password for this, we’ll create password hash first,

The serverid DN will now have ‘cn=servicePasswordPolicy,ou=pwpolicies,dc=devopsideas,dc=com’ as its password policy definition

Update schema to enable sshPublicKey attribute

Since we will implement key based authentication, we need an attribute that can store public key of the user. There is no attribute available by default to store the public key. Hence we need to define a schema for the same and create an attribute to store the key.

We have created an attributed named ‘ldapPublicKey’ to store the ssh public key of the users.

Update user entry with posixGroup and ldapPublicKey

We already have user entries created with inetOrgPerson objectClass. We further need posixGroup & ldapPublicKey added as part of the entries to get attributes that will be used for working with Linux clients.

3) Edit /etc/ldap/ldap.conf and change the value of TLS_CACERT to point to cacert.pem

TLS_CACERT /etc/ldap/certs/cacert.pem

Configure nslcd

nslcd is a daemon that will do LDAP queries for local processes based on a simple configuration file. nslcd is configured through a configuration file nslcd.conf. We will using filter to implement access control.

Edit the nslcd configuration file /etc/nslcd.conf and it should contain the below content.

If you are not able to login, check the syslog of LDAP server and see if you get any errors. Try troubleshooting based on the error code.

The id command reveals that the user is part of server_admin which we created in LDAP. This gets fetched from the group filter specified in the nslcd.conf file

Configure sudo access

We can’t do anything much with the present configuration. The user can only login with their id’s but they cannot perform any operations like deploying new code, make configuration changes, restarting service etc.

For this example, we will consider the application is owned by an application id (appid). The Dev user should have access to switch only to this id. On the other hand the Admin user should have complete sudo access. We will achieving this by editing sudoers file and adding relevant permission to the groups that we got through the group filter in nslcd configuration

The content highlighted in blue are the ones we have added additionally. We have specified that users belonging to server_admin will have sudo access and user part of server_dev will have access to switch only to appid

For eg, the aron.francis belongs to server_dev group. Hence in order to switch to appid, he has to run