In this document, we will learn how to setup our OpenLDAP 2.4 server as a repository for our Kerberos principals. We will also explore how to configure the client machines. Kerberos is a computer network authentication protocol which works on the basis of "tickets" to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner. Its designers aimed primarily at a client–server model, and it provides mutual authentication—both the user and the server verify each other's identity. Kerberos protocol messages are protected against eavesdropping and replay attacks. Kerberos builds on symmetric key cryptography and requires a trusted third party, and optionally may use public-key cryptography by utilizing asymmetric key cryptography during certain phases of authentication.

Server Configuration

Enable NTP and make sure your server and clients are synchronized! I will not explain how to setup NTP in this document. There are quite a lot of examples if you need help. Maybe in some other blog post.

Now that we have our OpenLDAP server configured, we can now proceed with the Kerberos 5 server setup. In this blog post, we will create a Kerberos Key Distribution Center server for the realm COMPANY.COM. To start with, as usual, install the appropriate rpm packages. This will also install several dependencies. The words package will create the /usr/share/dict/words directory used by the kadmind(8) service.

No we don't. So we must add the LDAP container for our Kerberos principals. We must also add an LDAP user and group which will be used by Kerberos to talk to the LDAP server. So create a temporary LDIF file.

What we need to do, is to grant read/write permission to the Kerberos admin user (i.e. cn=krbadmin,ou=users,dc=company,dc=com) on the ou=kerberos subtree. Any other user should not have access to this data. We again proceed to write an LDIF file.

Check to see if the new ACL works. Both the cn=admin user and a user with both UID zero and GID zero will be able to see the ou=kerberos subtree. The cn=nssproxy user will not even see the ou=kerberos container while the cn=krbadmin user will be able to read and write to the entire ou=kerberos subtree. We must also check to see if normal users can still use our OpenLDAP server for authentication via pam_ldap and check to see if they can change their LDAP password?

When we installed the krb5-server rpm, it configured logrotate(8) to handle two new log files : one for krb5kdc(8) and the other for kadmind(8) as we can see from /etc/logrotate.d/krb5kdc and /etc/logrotate.d/kadmind files. Strangely, the rpm installation does not create those files. So let's create them.

sudo touch /var/log/krb5kdc.log /var/log/kadmind.log

We now need to instruct rsyslogd(8) what to send into those two new files.

A quick look at the /var/log/krb5kdc.log file should display this line :

May 14 12:53:34 alice krb5kdc[23528]: commencing operation

Using netstat(8), we can see that we now have TCP ports 88 (kerberos), 464 (kpasswd) and 749 (kerberos-adm) in LISTEN mode.

netstat -alnt | egrep ':88|:464|:749'

Congratulations! We now have an operational MIT Kerberos 5 Authentication Service and Key Distribution Center :)

Now what? Well, first, we need to create a principal for the local server. We should also create a test.user principal. Here's how. The lines below in bold are what is actually typed. This is a single session, but we break it down to add some details.

sudo kadmin.localAuthenticating as principal root/admin@COMPANY.COM with password.Here we create the machine principal for the current server we're currently logged-in.kadmin.local: addprinc -randkey host/alice.company.com@COMPANY.COMWARNING: no policy specified for host/alice.company.com@COMPANY.COM; defaulting to no policyPrincipal "host/alice.company.com@COMPANY.COM" created.

Once we have created the host principal, we can add it to the machine's kerberos keytab (i.e. /etc/krb5.keytab)

Next we create a user princpipal for myself and assign a password to this new user.kadmin.local: addprinc drobilla@COMPANY.COMWARNING: no policy specified for drobilla@COMPANY.COM; defaulting to no policyEnter password for principal "drobilla@COMPANY.COM": Re-enter password for principal "drobilla@COMPANY.COM": Principal "drobilla@COMPANY.COM" created.

The next user is again for me, but with administrative rights. Remember the /var/kerberos/krb5kdc/kadm5.acl file? That's where it comes into play. The /admin users have administrative rights to the Kerberos realm via that file. That means they can create and destroy users or policies. So make sure we know and trust them!kadmin.local: addprinc drobilla/admin@COMPANY.COMWARNING: no policy specified for drobilla/admin@COMPANY.COM; defaulting to no policyEnter password for principal "drobilla/admin@COMPANY.COM": Re-enter password for principal "drobilla/admin@COMPANY.COM": Principal "drobilla/admin@COMPANY.COM" created.

As we can see, these are all the encryption keys for this particular machine. No wonder the permissions on the file are restricted to root!

We still have one last item on the server side to fix. That's the « bdb_equality_candidates: (krbPrincipalName) not indexed » error we keep having in the /var/log/slapd.log log file. To fix this, we need another LDIF file.

Create a new machine principal for this host. We run the kadmin(1) command as root so that we can write the resulting keyfile /etc/krb5.keytab. Otherwise, we would get the « No such file or directory while adding key to keytab » error which is not quite explicit enough. We also must use the -p switch to let kadmin know with which principal we want to connect with. If we only try sudo kadmin, then we will get the « Client not found in Kerberos database while initializing kadmin interface » error because we didn't create the root/admin@COMPANY.COM principal. Don't create it either, we want to be able to know who connected with his /admin user. If it's root/admin, there's now way to tell.

That created the /etc/krb5.keytab. We can now edit /etc/ssh/sshd_config to enable Kerberos authentication. Don't forget to add test.group into the AllowGroups directive. Otherwise we won't be able to test and will have the « User test.user from alice.company.com not allowed because none of user's groups are listed in AllowGroups » in the machine's /var/log/secure log file.sudo vi /etc/ssh/sshd_config

Restart the daemon.

sudo /etc/init.d/sshd restart

Leave this terminal window open after we've issued this command :

sudo tail -F /var/log/secure

From another terminal window on the server, create a test.user principal.

kadmin -p drobilla/admin@COMPANY.COM

kadmin: addprinc test.user@COMPANY.COM

WARNING: no policy specified for test.user@COMPANY.COM; defaulting to no policy

Enter password for principal "test.user@COMPANY.COM":

Re-enter password for principal "test.user@COMPANY.COM":

Principal "test.user@COMPANY.COM" created.

kadmin: exit

Assume this user's identity by taking his Kerberos ticket. We first destroy our own tickets with kdestroy(1), then get the test.user's ticket with kinit(1) and finally confirm that we do indeed have the new ticket with klist(1).

kdestroy

kinit -p test.user@COMPANY.COM

Password for test.user@COMPANY.COM:

klist

Ticket cache: FILE:/tmp/krb5cc_1100

Default principal: test.user@COMPANY.COM

Valid starting Expires Service principal

05/14/12 14:12:10 05/15/12 14:12:10 krbtgt/COMPANY.COM@COMPANY.COM

renew until 05/14/12 14:12:10

We can now login with this Kerberos ticket.

ssh test.user@bob.company.com

If we go back to the terminal window on the client in which the tail(1) command was running on the /var/log/securefile, we should have those lines :

SASL GSSAPI OpenLDAP authentication

Server Configuration (part 1 of 2)

To enable SASL GSSAPI authentication, we must configure the OpenLDAP server so that it knows about our Kerberos realm. Then we can configure the clients.

So, from the OpenLDAP server, connect to the KDC and create a new principal. We still use kadmin as root because we want to place the new keytab into /etc/openldap so that our OpenLDAP daemon has a different keytab then the host.

Ah ha! So we already have olcSaslSecProps: configured. Let's build on that.

vi ~/ldap/sasl.ldif
Well, actually, we wouldn't need to play with olcSaslSecProps: but I left it there because I tried adding the « noactive » keyword. When we do and try to « sudo ldapsearch -LLLY EXTERNAL... » we get the following error :

Good! Now here's a tricky part, we need to add the KRB5_KTNAME parameter to the /etc/sysconfig/ldap file.But this parameter is not part of any OpenLDAP documentation I've ever found?!? A hint about this parameter is found in the /etc/init.d/slapd startup script and that's it! If anyone knows why, please let me know!

Ouf! Did you get all this? Don't be alarmed and read it one by one. You should be fine ;) Still, this looks like a lot of changes, so make a full backup in case things go wrong...

sudo tar zcvf ~/ldap/slapd.d.backup.tar.gz /etc/openldap/slapd.d

Add those news ACLs to our OpenLDAP server.

ldapmodify -xZWD cn=admin,dc=company,dc=com -f ~/ldap/gssapi.ldif

And test to see if we can access what we need? Are users that are not supposed to see things really aren't capable of seeing them? Is our Kerberos kadmin(1) programm still working? Can the cn=nssproxy user do it's job? Let's find out.

Check if the RootDN can still see the configuration? It should return only « dn: cn=config ».

Can normal users still change their passwords? Well, that changed! If we try the passwd command of a user which is not part of the local /etc/passwd file, instead of trying the OpenLDAP passwd, the passwd(1) command will look the the Kerberos 5 password. That's because we enabled PAM Kerberos. Don't worry, that command will prompt for the Kerberos password.

su - test.user

passwd

Changing password for user test.user.

Kerberos 5 Password:

Client Configuration (part 2 of 2)

We can now head to the client machine and modify it to use SASL GSSAPI authentication for it's default LDAP queries and the autofs maps. Connect to the client machine with a user that is NOT using an NFS home!

ssh panic@bob.company.com

Check to make sure there is no NFS mounted directories? If there are any, make sure to unmount them before you continue!

Note that the OPTIONS and LOGGING clauses are set to debug values. This is just to help us find problems if there are any. During normal operations, these should be changed. We'll get to these in a minute.

Next we need to create a Kerberos principal that will be used by our autofs daemon. We must also add this new principal's keys into the client's keytab.

sudo kadmin -p drobilla/admin@COMPANY.COM

kadmin: addprinc -randkey autofsclient/bob.company.com@COMPANY.COM

kadmin: ktadd autofsclient/bob.company.com@COMPANY.COM

kadmin: exit

We can see that the autofsclient keys are now part of the client's keytab :

We should now edit the automount system-wide configuration to change it for production mode (i.e. less verbose output). Only those two lines are changed.

vi /etc/sysconfig/autofs

LOGGING="none"

# OPTIONS="-d -v"

And restart the autofs deamon for those changes to take effect.

sudo /etc/init.d/autofs stop

sudo /etc/init.d/autofs start

That's it! We have achieved all of our Kerberos goals!

Enable sshd(8) Kerberos authentication.

Enable PAM Kerberos authentication.

SASL GSSAPI OpenLDAP authentication.

Use SAS:L GSSAPI Authentication with AutoFS.

We also achieved goal number 8 which was :

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.

Our next blog post will explain how to backup and restore our OpenLDAP server. We will then configure replication. With all the OpenLDAP services which our clients now depend on, we need to add some robustness to our OpenLDAP setup.

UPDATE : When autofs is configured to use Kerberos in the /etc/autofs_ldap_auth.conf, then we must change the startup procedure in order to have Kerberos start before autofs. Otherwise the NFS home directories are not mounted. To do this, edit /etc/init.d/autofs script to change this line...

Great series... an amazing reference. Can you link the sections in each article to their corresponding pages. Would be great to be able to navigate through all this work you've done for the rest of us.

Since I started the kerberos part of this great series (this post) I can no longer login with ldap users... I can see tickets being granted, and the ldap query succeeds but I'm getting an error related to initgroups and the session doesn't get setup for the user.

That is quite obscure to me too. Did you enable the nslcd daemon? Not the nscd, but nslcd (the extra L is for LDAP). There is a bug with Ubuntu and nss-ldap, but I'm not sure it applies here (see https://bugs.launchpad.net/ubuntu/+source/at/+bug/509734).

Are you running with SELinux enabled? Try disabling it to see if that might be the problem? Or do you have a modified login.conf file?

So how exactly did you fix the issue? You modified the pam.d files listed in your comment? If so, what changes did you apply to them? If you could describe your fix in detail, I could add it to this blog post. With full credit to you of course :)

Do you have any idea connecting to Microsoft Active Directory? or any idea how to connect it via ldap? via Ubuntu client. I used to try use winbind (for details see https://help.ubuntu.com/community/ActiveDirectoryWinbindHowto) and likewise-open (still based on winbind) and it is working well.

I'm just curious on connecting to AD, so that able to achieve the single-sign on (SS0) which winbind could not do it. My problems, the what correct DN in authenticating to AD? and getting those accounts/passwords?

I believe you have an experience on it, as these great articles (blogs) are the living witness of your knowledge. Keep up.

In order to query an Active Directory (AD) server, you need a DN that has access to the data you're interested in. In general, that usually means a Microsoft Domain Admin. What I usually do is create a user in AD with the Microsoft AD tools. This user is labeled as a service account and not an ordinary user. This is mostly done so that other admins who come into contact with this AD will know what this account is used for. I usually also check the « password never expire » and setup a reminder each year to change it. This is to prevent a failed service during a week-end.

Then SSL access to the AD should be enabled so that the service account's password and data query results are not sent in clear down the wire.

Using this user, it's now a question of working out the correct ldapsearch query to fetch the data you need. To help you, check out the default /etc/nslcd.conf file when you install nslcd. It has some default values listed there that are quite good.

You can achieve user authentication on an Active Directory (AD) server via winbind from the Samba suite (see reference [1] below). It works well, but you have to place the Linux machine into the Kerberos realm of the AD servers (with /etc/krb5.conf as usual). So if you're already using Kerberos in your UNIX environment (like you say you are) then you would need to setup cross-realm trust and authentication for this to work (i.e. keep using your existing UNIX Kerberos realm AND use the AD Kerberos realm at the same time).

If you don't have an existing UNIX Kerberos realm, then winbind is probably the way to go.

With that said, one has to know that in AD, user passwords are stored in the « unicodePwd » attribute. But this attribute is never returned by an LDAP search! [2],[3].

I could go on about how to use AD to authenticate users, but someone called Gred has already wrote two articles on the subject. See [4] and [5] for more information.

> What do you mean by service account? > Or how do i make an ordinary user to it?

You can of course use a normal AD user to bind to the AD. But this user's password will eventually expire. If you have several servers using that user's credentials to bind to the AD machines, then once the password expires, all those server that depend on it will be broken.

So instead of doing this, what I suggested is to create a service account in AD. This account is just like a normal user, except it has the « Password Never Expires » property. You then configure your servers and workstations that need to bind to AD with that account.

The olcSaslSecProps directive is part of the OpenLDAP Global configuration options which is defined in cn=schema. The SASL directives are installed by adding them to your OpenLDAP server via an LDIF file such as this one https://dl.dropbox.com/u/72609528/blog/openldap/sasl.ldif

It is installed as part of this article too. And you need the SASL libraries installed on your machines to leverage them of course. That's why we run...

Hi David , I configured my ldap server to use SASL GSSAPI . When I try to authenticate myself from ldap server by generating a tkt from my kerberos server , it works. I chck this by typing "ldapwhoami" on my ldap server. But when i do this on my client , it gives me an error :ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info : SASL(-4): no mechanism available: No worth mechs foundBy the way my client was authenticating the user before using SASL GSSAPI.In addition I havent configured any LDAP ACL's so far.THanks

That should be easy to fix because this exception is thrown when your client doesn't have the required SASL libraries installed. You're using SASL GSSAPI which means you need to have the SASL GSSAPI libraries on your machine. If you're on CentOS or RedHat client, that means installing the cyrus-sasl-gssapi rpm. By default, only the cyrus-sasl-plain is installed. But you don't use this. So, to fix your problem, run this :

sudo yum -y install cyrus-sasl-gssapi

And then try to authenticate yourself with your Kerberos principal to the OpenLDAP server and see if this works?

Hi David , I am following your tutorial ,but I have setup my ldap server and kerberos server on two seperate machines. When I reach to a point where I want to populate my kerberos container with all the kerberos principals with this command :root@kerberos # kdb_ldap_util -D "cn=admin,dc=xx,dc=xx" create -subtrees "ou=kerberos,ou=services,dc=xx,dc=xx" -r -sIt throws an error :kdb5_ldap_util: Can't contact LDAP server while initializing databasei can search the ldap server from my kerberos and when i type ldapwhoami , it works fine too, Any ideas what went wrong? Thank you

I do remember that, in the past when I first started to play with Kerberos, you HAD to have the LDAP server and Kerberos KDC on the same machine. That was because the Kerberos implementation did not talk to the LDAP server via a TCP/IP connection, but via a local socket.

Now that's not the case anymore as the kdb5_ldap_util(8) man page clearly shows an example where the LDAP server is accessed over the network :

ok , The -H option worked for me and i see some new kerberos principals in my openldap database for my realm.Now the issue is that the krb5kdc and kadmin services refuse to start . the logs are not clear only says" root@kerberos# service kadmin startkadmind: Can't contact LDAP server while initializing, abortingroot@kerberos# service krbkdc startkrb5kdc: cannot initialize realm XXXX.XXX - see log file for details

I am exactly following your doc, but still my kadmind.log and krb5kdc.log shows the same error as it displays on the screen and my slapd.log has no affect on my starting the kadmind or krb5kdc services.It doesnt even show the ip of my kerberos server. I already synched the time b/w all servers....wooof

Since your OpenLDAP server is on a different machine than your Kerberos KDC, you might have to tell to both kadmin and krb5kdc that they need to contact the OpenLDAP machine. This can be done by adding the right flags into /etc/sysconfig/kadmin and /etc/sysconfig/krb5kdc respectively.

If you look at the kadmin(1) man page, the -x flags will tell kadmin where to locate it's LDAP server and how to bind to it (i.e. which credentials to use). See this exerpt from the kadmin(1) man page :

-x db_args Specifies the database specific arguments.

Options supported for LDAP database are:

-x host= specifies the LDAP server to connect to by a LDAP URI.

-x binddn= specifies the DN of the object used by the administration server to bind to the LDAP server. This object should have the read and write rights on the realm container, prin- cipal container and the subtree that is referenced by the realm.

-x bindpwd= specifies the password for the above mentioned binddn. It is recommended not to use this option. Instead, the password can be stashed using the stashsrvpw command of kdb5_ldap_util.

The same goes for krb5kdc(8) man page :

The -x db_args option specifies the database specific arguments.

Options supported for LDAP database are:

-x nconns= specifies the number of connections to be maintained per LDAP server.

-x host= specifies the LDAP server to connect to by a LDAP URI.

-x binddn= specifies the DN of the object used by the KDC server to bind to the LDAP server. This object should have the rights to read the realm container, principal container and the subtree that is referenced by the realm.

-x bindpwd= specifies the password for the above mentioned binddn. It is recommended not to use this option. Instead, the password can be stashed using the stashsrvpw command of kdb5_ldap_util.

Try configuring krb5kdc and kadmin with these flags and restart them. See if that's better?

Ah I'm sorry if that doesn't work. It's just that I've never tried to run my KDC seperate from my OpenLDAP server. So I'm working in the dark with you.

Let's try something else. What happens when you try to launch the krb5kdc service with the -x switch. Like this :

sudo sh -x /etc/init.d/krb5kdc start

You will get quite a few lines describing what the script is doing. Our target here is to find out which files it tries to open and which command it's using to perform the KDC startup itself and with which arguments.

Once we have this, we can try it manually and see if there are other error messages. We can also try to launch it manually with strace(1) to see what it's trying to do and thus isolate where the failure occurs.

# 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}xxxxxxxxxxxxxxxxxx

# The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools.# Mode 700 recommended.directory /var/lib/ldap/diacs

Hi David , Now I have rebuild my openldap server with both ldap and kerberos on the same machine.Now when I start my krb5kdc and kadmind i get this error"Error reading password from stash: Bind DN entry missing in stash file..."Thanks for your extended support

Hi David, Nice to see you again. My kerberos admin is krbadmin and my stash file has correct info.The path to my stash file is also correctly mentioned in my krb5.conf file, can it be a permission issue?Thanks

Indeed, it can clearly be a permission issue. You can try to see what goes wrong by running an strace on the startup script. Something like this will show you all the files it tries to open and if it was successful or not :

Hi David , Sorry to bother you but if you have time can you put some light on what this error means.root@ldap$ ldapmodify -xWD cn=admin,dc=company,dc=com -f ~/nssproxy.ldifldapmodify: Invalid format (line 5) entry: "olcDatabase={2}bdb,cn=configroot@ldap$ cat nssproxy.acl.ldifdn: olcDatabase={2}bdb,cn=configchangetype=modifyreplace: olcAccessolcAccess: {0} to * dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by dn.base="cn=nssproxy,ou=users,dc=company,dc=com" read by * auth by * noneAny Ideas why its throwing this error?Thanks

...and you cat the file nssproxy.acl.ldif. But if you look at it, the nssproxy.ldif and nssproxy.acl.ldif files are not the same. Is this just a typo or you really are working with two different files? Because if this is the case, you're looking for trouble ;)

Ah, I'm sorry for you : no internet access! I'm not sure I can live without internet access :)

So if it's the right file, was it pulled from this blog post? Because I can't find it here. Anyway, when you do the ldapmodify, what logs are generated? And what is the current ACL setup on your olcDatabase={2}bdb,cn=config?

You can find out what are your current ACLs with a command similar to this one :

And the reason why I started this discussion is as follows:root@ldap$kadmin.localAuthenticating as principal root/admin@COMPANY.COM with passwordkadmin.local: addprinc testuserWARNING : no policy specified for testuser@COMPANY.COM; defaulting to no ploicyEnter password for principal "testuser@COMPANY.COM" dirtysecretRe-enter password for principal "testuser@COMPANY.COM" dirtysecretadd_principal: Principal add failed: Insufficient access while creating "testuser@COMPANY.COM".

That would mean your OpenLDAP equivalent of the « root » user is configured as « cn=admin,cn=config » instead of « cn=admin,dc=company,dc=com ». Could that be the case? (I don't have access to my OpenLDAP servers right now, so I can't find find out how to make sure that is the case).

Now, I'm sorry, but I lost track of the current issue. What was your problem again?

The issue was this:And the reason why I started this discussion is as follows:root@ldap$kadmin.localAuthenticating as principal root/admin@COMPANY.COM with passwordkadmin.local: addprinc testuserWARNING : no policy specified for testuser@COMPANY.COM; defaulting to no ploicyEnter password for principal "testuser@COMPANY.COM" dirtysecretRe-enter password for principal "testuser@COMPANY.COM" dirtysecretadd_principal: Principal add failed: Insufficient access while creating "testuser@COMPANY.COM".

I tried to make one rootdn but when I reached to the point where I had to issue the following command , it did not return anything:root@ldap$ ldapsearch -xLLLWD cn=admin,dc=company,dc=com -b cn=config dnNo such object (32)Therefore I decided to add another one.Please forgive my limited knowledge but this is the toughest topic I have encountered so far. Actually my slapd.log says:slapd[18025]: conn=1018 op=7 ADD dn="krbPrincipalName=testuser@COMPANY.COM,ou=krb5,dc=company,dc=com"slapd[18025]: conn=1018 op=7 RESULT tag=105 err=50 text=no write acces to parent

Moreover i had an exact setting of ou's and subtrees as yours in my kerberos database where my REALM was in a seperate container than my kadmin and nssproxy user but when i tried to start the kerberos services , they gave me an error that they could not find the stash password until i brought them into the same container which in my case is called krb5.

See the « no write access to parent »? That means your ACLs are not setup properly. ACLs are probably also the reason why you have the « No such object (32) » error when you do the ldapsearch.

So what we need to do is to give read/write access to the root/admin@COMPANY.COM user. Actually, we will want to give read/write access to the « ou=krb5,dc=company,dc=com » container to a regular expression like this one : « */admin@COMPANY.COM ».

This ACL setup is done via the « ~/ldap/kerberos.acl.ldif » file in this blog post. Read it again and make sure you understand it and make sure you change the container from my « ou=kerberos » to your own « ou=krb5 » container.

Hi Dave, your updating the blog encouraged me that I ask you error messages while working on the last part of autofs mounting from the client machine. Instead of the nice log from your "May 15 14:46:42 bob automount[5539]: sasl_bind_mech: sasl bind with mechanism ..... " I got the autofs error messages as below:

Hi David, Just wanted to make myself clear about certain things in the setup.

1. When i had only nssproxy.acl on the database. My "getent passwd" command on the ldap client was working, but this command did not work on the ldap server right from the start. i read your blog where you have explained about "getent" but not sure if you meant to type the command on the server or the client? if you meant client then my setup is ok.

2. After i reached to the step to apply " kerberos.acl" then my "getent" command even stopped working on the client as well. Not sure if this is the normal behaviour. Even when i "su testuser" it says "user does not exist"my slapd.log after my getent shadow testuser shows the following entries:conn=1011 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text=conn=1011 op=2 ABANDON msg=2conn=1002 op=5 SRCH base="dc=company,dc=com" scope=2 dref=0 filter="(&(objectClass=posixAccount)(uid=root))"

3. I have setup my ssh configuration on client but when i try to login from another machine to ldapclient , it cant find the user. Can you put some light on this?

1. The getent command tests your entire system's directory search setup. In other words, it will check the /etc/nsswitch.conf file for the database you need to check (ex. passwd) and then check what are the data sources for this database (ex. file ldap). It will then query these data sources in the order they are listed in the /etc/nsswitch.conf file and try to fetch the data you requested. For example, if you run this...

getent passwd testuser

...and the /etc/nsswitch.conf file has this entry...

passwd: files ldap

...then getent will first check the local /etc/passwd file to see if the testuser is listed there. If not, then it will query the ldap server to see if the testuser is there. If it finds the user, either in /etc/passwd or in ldap, then it will print the info for that entry.

Of course, if you list ldap in /etc/nsswitch.conf, then you need to have a working ldap setup.

If the command works on your ldap client, but not on your ldap server, it probably means that the /etc/nsswitch.conf file is not configured on your ldap server to query the ldap server (i.e. itself)

2. Can you please list all your ACLs for the OpenLDAP server once you apply the kerberos.acl file? Maybe that file changes the ACLs in a way that prevents your OpenLDAP bind user from read access to the passwd and shadow attributes?

Don't forget that to query the passwd database, you don't need to be root. But for the shadow database, you need to have super-user access. Try doing a simple « cat /etc/passwd » and you will see that it works. But « cat /etc/shadow » will not work unless you do a « sudo cat /etc/shadow ». It's the same with getent. This will fail...

David , once again thank you for your continous support . here is a list of my acl on the database.root@ldap: ldapsearch -xLLLWD cn=admin,cn=config -b olcDatabase={2}bdb,cn=config olcAccessdn: olcDatabase={2}bdb,cn=configolcAccess: {0}to attrs=userPassword,userPKCS12 by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by dn.exact="cn=nssproxy,ou=users,dc=company,dc=com" read by self write by anonymous auth by * noneolcAccess: {1}to attrs=shadowLastChange by self write by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by dn.exact="cn=nssproxy,ou=users,dc=company,dc=com" read by * noneolcAccess: {2}to dn.subtree="ou=krb5,dc=company,dc=com" by dn.exact="cn=kadmin,ou=krb5,dc=company,dc=com" write by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by * noneolcAccess: {3}to dn.subtree="dc=company,dc=com" by dn.exact="cn=kadmin,ou=krb5,dc=company,dc=com" write by dn.exact="cn=nssproxy,ou=users,dc=company,dc=com" read by * none

David, Thanks for the prompt reply!!! (sorry, misspelled your first name)I followed your instruction and the client site(dyna9)'s message log is same as before. In the server side(192.168.0.5) message log has not propagated any log, but slapd.log has added as below:

What we see from the slapd.log file is that client dyna9 at IP 192.168.0.109 has connected to the server, successfully established a TLS connection and then issued a search for the Kerberos principal « autofsclient/dyna9.rock.lab@ROCK.LAB ». So that's good.

But on the client side, we don't have logs. What you should do now is to enable verbose logging for autofs on the client machine. To do so, edit the /etc/sysconfig/autofs file en replace the verb « none » with « verbose » for the logging clause. Then do the debug thing again we talked about previously (with multiple shells, tail -F, etc).

Ok, do you have a ou=autofs,ou=services,dc=rock,dc=lab object in your OpenLDAP server? If you do, can you try to do an ldapsearch with a) your OpenLDAP admin user and b) the nssproxy user configured in the /etc/openldap/ldap.conf file of the client?

See if these two queries return the same answer or not? If the query returns the info with the OpenLDAP admin but not with the nssproxy, that means your ACLs are not setup right.

Can you please post your /etc/openldap/ldap.conf file? Make sure you remove the password of course.

And do you have an /etc/ldap.conf file? If you do, then please post it as well.

Some binaries use /etc/openldap/ldap.conf while others rely on /etc/ldap.conf. I know for sure that sudo uses /etc/ldap.conf. But I haven't done any strace runs to know which files are used by which binaries.

Anyway, please post the contents of both files.

Also, make sure you check your slapd.log file on the master OpenLDAP server to see which DN is used for the bind.

Hi David , I am glad that we worked out some of the major issues in the setup. So far I understand by kerberizing the ldap client , the user will only be authenticated if it has a valid ticket available, but I am experiencing that even if I dont have any ticket , the user is still authenticated.This behaviuor is slightly different on ldap client and on the system connecting to the client. If I have a valid tkt on the ldap client then ssh testuser does not ask for password but ssh testuser from another system still requires password. I was expecting that once you dont have a valid tkt for that user , it wont be authenticated at all ?

Once you configure your SSH daemon to allow Kerberos authentication via the Generic Security Service Application Programming Interface (i.e. GSSAPI), then you can connect to the machine with a user that has a valid Kerberos ticket. Unless you want this to be the only authentication mechanism, your SSH daemon will also accept Public/Private DSA and RSA keys as well as normal password authentication. It is thus quite flexible. If you don't want to allow public key or password authentication, you need to remove them from the sshd_config file and restart the sshd service.

Also, if you have « UsePAM yes » in the sshd_config file, then you need to update your Pluggable Authentication Modules (i.e. PAM) configuration. One way to do this is to use the « sudo authconfig-tui » command. With that, you can decide to enable or disable various authentication modules.

IMHO, I prefer to configure SSH and PAM to use Kerberos, Public keys and Passwords. Then prevent the root user from connecting via SSH. And setup AllowGroups in the sshd_config file to limit which groups have access to the servers. Then keep only system accounts in the local /etc/passwd and /etc/group files. Use OpenLDAP to keep all the users and groups. And configure /etc/nsswitch.conf to use first the local files and the ldap for group, passwd, shadow and sudoers. I also like to configure a panic user in all my machines which has sudo ALL in the local sudoers file. This user is handy when either OpenLDAP, NFS or Kerberos are broken. Ideally, this user is created during OS installation via KickStart. YMMV of course :)

I don't have any blogs to refer on virtualisation and clustering I'm afraid. I've used Linux Virtual Server [1] in the past. It works very well and is quite easy to setup.

And for virtualisation, I worked in environments that used Xen [2], VMware [3] and OpenVZ [4] in the past. They all have some good and bad sides. Usually there is already some form of virtualization when you join a corporation. So I use whatever is already in place. For my home virtualisation needs, I use VirtualBox [5] and VMware.

In /var/log/secure I only get the messages:Oct 4 23:31:04 ldap-02 su: pam_unix(su-l:session): session opened for user test.user by root(uid=0)Oct 4 23:31:06 ldap-02 passwd: pam_unix(passwd:chauthtok): user "test.user" does not exist in /etc/passwd

Hi: I didn't add the below lines in slapd.conf at the beginning setup. Is it possible to add it through phpldapadmin and how? Can you share a little bit for password aging policy? The new 2.4.23 config database is dfferent from the previous version. overlay ppolicy ppolicy_default "cn=default,ou=policies,dc=example,dc=com"Thank you for this great blogs to help me setup 2.4.23 on CentOS 6.4.

Any help? Do I need those two lines in slapd.conf before running slaptest to create slapd.d for password aging policy or not? In the older version than 2.4.23, I used to have to add thses two lines. But in this new version, I am stuck to make the password aging work. Will appreicate it for any help.overlay ppolicyppolicy_default "cn=default,ou=policies,dc=example,dc=com"

> Thank you for this great blogs to help me setup 2.4.23 on CentOS 6.4.

Glad I could help!

> Do I need those two lines in slapd.conf before running slaptest to create slapd.d for password aging policy or not?

This time I can't help you. I haven't been playing much with password aging policies of OpenLDAP. I looked more into the Kerberos ones (which makes me think I should write about it :) So, yeah, good luck with that.

Say, if you do make it work, may I kindly ask you to share you findings? Thanks in advance!

> Is it possible to add it through phpldapadmin and how?

No idea?! I've never used that software (I tend to stay well away from PHP tools, but YMMV). I prefer Apache Directory Studio to manage my LDAP entries. It's a Java app that can thus be used on my home MacBook, on the corporate Linux machines and Windows desktops. But you can't modify slapd.conf(5) via this tool. IMHO it's best to go CLI from there.

I have a module.ldif like this dn: cn=module,cn=configobjectClass: olcModuleListcn: moduleolcModuleLoad: ppolicyolcModulePath: /usr/lib64/openldap

How do I use ldapadd -a -xWD "cn=config" -f module.ldif ? It shows Invalid credentials.I need to use ldapadd to add the module.ldif and ppolicy_overlay.ldif, but I can't use ldapadd. Any help? Thank you

This is my ppolicy-overlay.ldifdn: olcOverlay=ppolicy,olcDatabase={2}bdb,cn=configobjectClass: olcPPolicyConfigolcOverlay: ppolicyolcPPolicyDefault: cn=ppolicy,ou=policies,dc=tux,dc=comolcPPolicyUseLockout: TRUEolcPPolicyHashCleartext: TRUEBasically, there is no {2}bdb, but I search the documents and forums, people say it should use {2}bdb. Any help will be appreicated. Thanks

Hi: These are three files that I added. The pwdAccountLockedTime attribute does show up after the 3 times failure, but the timestamp is 8 hours later. I am not sure why. If anyone is interested in setting password aging, hope these three files can help and work togther to work out. Thank you. -b "cn=config" in ldapadd doesn't work, so I use ldapmodify this wayldapmodify -a -xWD cn=admin,dc=example,dc=com -f ppolicy.ldifcat module.ldif dn: cn=module,cn=configobjectClass: olcModuleListcn: moduleolcModuleLoad: ppolicyolcModulePath: /usr/lib64/openldap

Thanks for posting your setup, I'll try to implement it and see if I can add another section to my OpenLDAP blog series. If I do this, I'd like to let everyone know that you did the hard work, but I don't have your name. If you're ok with that, how would you like me to name you? Or to whom should I give credit to? :)

> Basically, there is no {2}bdb, but I search the documents and forums, > people say it should use {2}bdb. Any help will be appreicated.

For the {2}bdb vs. {1}bdb setup, it all depends on each user's own OpenLDAP servers. Here there are two details: a) the number in curly braces and b) the name of the backend database.

For a), the number will change depending on how many databases your OpenLDAP server uses. When you write LDIF files, you have to know which number to use. To find that, you can query your cn=config base and look for dn: A command similar to this one should give you that :

ldapsearch -xLLLZWD cn=admin,dc=example,dc=org -b cn=config dn

With this info, you will know if you have {2}bdb or {1}bdb for example.

As for b), the type of backend might change. Some might use hdb or mdb instead of bdb too. See http://www.openldap.org/doc/admin24/backends.html for a bit more info. Note that the hdb backend has superseded the bdb backend, and both will soon be deprecated in favor of the new mdb backend. Also note that each databases in your OpenLDAP server can use different backend solutions. For example, you can have a {0}bdb, {1}hdb and {2}mdb.

Now, before you write LDIF files, you also need to check this out. To do that, you can use the exact same command as for a) above.

Once you know both the number and backend, you can then write your LDIF files.

> The pwdAccountLockedTime attribute does show up after the 3 times failure, > but the timestamp is 8 hours later. I am not sure why.

You mention the pwdAccountLockedTime attribute, but it's not part of the LDIF file you posted and it does not show up in the OpenLDAP documentation?

Stupid question: are all the machines in your LAN in the same time zone? Are they all synched via NTP?

Hi David: pwdAccountLockedTime is read only attribute. http://www.zytrax.com/books/ldap/ch6/ppolicy.html I managed to make everything work now. Automount and ppolicy all work now. But I change to use sss service instead of nslcd and change the ldapbasedn to cn=Manager, dc=test,dc=com. There are many associate files that have to be changed, too.I do get the help from your pam_ldap.conf, autofs_ldap_auth.conf, /etc/pam.d/system*. Without your blog, I probably can't get everything work in Opeldap. This new version in CentOS 6 is much more complex than we used in CentOS 5.5. It was way easier to set up before. Anyhow, if I am allowed by you, I will like to share the files that I edit. I don't want to hijack your blog. Thank you.

Hello. Your tutorial is fantastic. I have yet to find another post with as fine a detail as yours. I really appreciate your incremental approach where nearly every step is followed with a means to test the changes, and often what problem/error we might encounter. Further, you take the time to explain why your setup is this way.

I do have a question though. The https://dl.dropbox.com/u/72609528/blog/openldap/sasl.acl.ldif file contains:

Thank you for confirming the entry. My next question is then what should not work with the incorrect DN (i.e., missing the 'ou=users')? Does this mean the 'nssproxy' user would not be able to access the 'userPassword' and 'shadowLastChange' attributes, preventing an LDAP-only user from logging in? Is this problem not seen because at this point in the tutorial we've switched to using Kerberos for authentication?

OK, so I do have another question (unrelated). Admittedly, I am using Ubuntu 12.04 for the clients and servers, and have adapted your setup (where appropriate) for my network. I have set the 'binddn' and 'bindpw' to use the 'nssproxy' user in the client '/etc/ldap.conf' but seemingly the file must be world-readable. Otherwise, 'getent netgroup XXX' is unable to query the entries. I could not find a solution allowing me to keep this file private so as to hide the 'nssproxy' credentials AND allow the setup to fully work. Also, I could not find a way to specify the proxy credentials elsewhere, i.e., in another file. Have you any suggestion(s)?

> Is this problem not seen because at this point in the tutorial we've > switched to using Kerberos for authentication?

Humm, not sure there. I wrote the DropBox files after I've configured everything. And I don't have access to the OpenLDAP servers I used to write this blog post. But yes, you might just be right about the Kerberos authentication. We would need to test to find out. Disable Kerberos authentication in the PAM modules and try with the wrong DN for nssproxy (i.e. without the ou=users,) and see what happens?

> I could not find a solution allowing me to keep this file private so as to > hide the 'nssproxy' credentials AND allow the setup to fully work.

You can certainly do that by switching your ldap.conf file to use the GSSAPI SASL authentication instead of the basic authentication. Like this :

# /etc/openldap/ldap.conf## OpenLDAP client configuration.# Do NOT confuse this file with /etc/ldap.conf.# See ldap.conf(5) for details.## David Robillard, April 23rd, 2012.

I really appreciate your help and apologize in advance for what is to be a long posting.

1) I intend to try disabling Kerberos in PAM, leaving out the 'ou=users', and testing LDAP to verify the net effect. However, I would like to finish setting up everything first.

2) Regarding the removal of 'binddn' and 'bindpw', I'm getting a bit confused. Given that I'm using Ubuntu, the file names and locations are different. I don't expect you to know these although I would be grateful if you do. I have only been able to get sudo+LDAP to succeed with the binddn/bindpw options set in '/etc/ldap/ldap.conf' and I have only been able to get the netgroup lookups to work with those options set in '/etc/ldap.conf'. The 'SASL_MECH GSSAPI' option seems to make no difference for me, with or without the bind information in either file.

3) When attempting to load the https://dl.dropboxusercontent.com/u/72609528/blog/openldap/sasl.acl.ldif via 'ldapmodify', I ran into a couple a problems. Once loaded, I attempted to confirm loading of the contents but found two entries with what I thought was garbage:

After some searching, the double colon suggests an illegal character or something of the like in those entries of the LDIF file. It seems both of the corresponding entries in the LDIF have a trailing space character at the end of the line:

dn: olcDatabase={0}config,cn=config…olcAccess: {0}to *.. by * none (the above line has a trailing space)

and

dn: olcDatabase={1}hdb,cn=config…olcAccess: {4}to dn.subtree="ou=autofs,ou=services,dc=company,dc=com" by dn.regex="uid=autofsclient/.*,cn=company.com,cn=gssapi,cn=auth" read (the above line has a trailing space)

Regarding the latter, this appears to be the only entry that does not specify 'by * none' leading me to ask if it is accidentally missing (and therefore leading to the error). After removing the spaces from each line, I was then able to load the contents.

For your questions number 2) about using Ubuntu, it's quite easy to find which files a particular command needs. Simply install strace [1] on your machine if it's not already there. Then run your command with the -eopen switch. For example :

sudo strace -eopen ldapwhoami

You will get a trace of each files the ldapwhoami tries to open. With that, you should be able to find out which ldap.conf file is being used by which commands.

As for questions number 3) you found out how the garbage came. I must say I'm happy because I've never dug deep enough to figure that one out! I'll go ahead and update the DropBox files right now. Thanks!

And for the automounter, what did you list in your nsswitch.conf(5) file? Mine reads this :

automount: ldap

Which asks the automounter to query only the LDAP server for the mounts. And not the local /etc/auto.master Your setup seems to check the local auto.master file.

On the OpenLDAP server, you do seem to have a ou=autofs, but there doesn't seem to be anything in it? Can you please send me the output of this query :

I am able to mount the home folder when '/etc/autofs_ldap_auth.conf' contains:

but unable to mount anything at all when it contains:

My '/etc/nsswitch.conf' does specify only to use LDAP when automounting:

automount: ldap

My '/etc/default/autofs' does contain 'MASTER_MAP_NAME="/etc/auto.master"' where the file contents of that file are '+auto.master'. I have enabled/disabled this option without it seeming to make any difference, in that simple authentication with 'nssproxy' mounts the home folder and GSSAPI fails.

Hummm, I'm not sure what the -ghost option does. And I'm quite sure you would prefer to remove the -hard option as well. And from my experience, I'm not sure you need the ampersand in your OpenLDAP automount entries. Try removing it, restart the automount daemon and see if you can mount now?

We haven't talked about the /etc/autofs_ldap_auth.conf file. What does your file contains? This is Kerberos version :

Last, but not least, make sure your Kerberos machines and your client machines are all in sync via NTP. If they're not, nothing will work. Make sure all machines have a working copy of the /etc/ntp.conf file and try this on all of them :

This was an attempt to provide the autofsclient/* Kerberos principals with access to the entire base DN. After restarting my client machine, the automounting worked. I then returned to the separate ACL's but switched their order:

This also worked. Not really being familiar with ACLs, is it possible that the rules of '{3'} (before I made these changes) are overriding/superseding the rules of '{4}'? I did find the site http://www.linuxtopia.org/online_books//network_administration_guides/ldap_administration/slapdconf2_Access_Control.html which might confirm my assumption:

The following example shows the use of style specifiers to select the entries by DN in two access directives where ordering is significant. olcAccess: to dn.children="dc=example,dc=com" by * search olcAccess: to dn.children="dc=com" by * readRead access is granted to entries under the dc=com subtree, except for those entries under the dc=example,dc=com subtree, to which search access is granted. No access is granted to dc=com as neither access directive matches this DN. If the order of these access directives was reversed, the trailing directive would never be reached, since all entries under dc=example,dc=com are also under dc=com entries.

Also, when I removed the ampersand from the 'cn=/,ou=auto.home,ou=autofs,ou=services,dc=company,dc=com' automount information, my home folder mounted funny as '/home/jerry/jerry'. Returning the ampersand yielded just '/home/jerry'.

Thank you for your help in all of this. Again, your tutorial is the first and only one to get me this far :) Jerry.

Yeah, the ACLs in OpenLDAP are read from top to bottom. So the idea is to place the most restrive ones on top (or with index number {0}) then open up wider and wider as you go down the list. So in your case, placing a restriction on ou=autofs before the entire directory information tree (DIT) makes a lot of sense. That will allow the autofsclient/* Kerberos principals to get their data from the ou=autofs subtree while other OpenLDAP dn won't have read access to your ou=autofs. Which is sound security practices.

And if your curious to learn more about OpenLDAP access control, the URL you posted is simply a copy of the official OpenLDAP documentation on this :

http://www.openldap.org/doc/admin24/access-control.html

Finally, about the ampersand, I think my configuration identifies the mount point as /nfs and then in there you can either mount /home or /install as in /nfs/home and /nfs/install. So when a user's home is set to /nfs/home/davidr for instance, then the automounter will mount /nfs/home and won't try to mount /nfs/home/davidr.

In your case, the mount point is set /home and the username is the actual directory that is being mounted by the automounter. In this way, the directory set for the user is /home/jerry. So that when you login, the moint point is /home/jerry. Do you see the difference?

This is a design choice of course. Your setup works just as good as mine. But there's a subtle difference. If you set a corporate network with thousands of users with your configuration, then each time one of them connects to a server, then the automounter has to request a specific direectory from the NFS server. Which means that if we both login to the same box, we would each have our own NFS mounted file system. If, on the other hand, you setup the same corporate network with a setup like mine, then if there is a single or a thousand users connected to the same machine, there's only a single NFS call being done for all of them.

As an example, let's say we're both connected on the same machine with my setup, then this is what we see :

Now try to scale this in your imagination. How many NFS mounts can your NFS server really perform? How many NFS mounts can the client do? When does this all comes crashing down because of too many NFS traffic? It's a simple question of managing the resources of both the client and the NFS server.

Or course, if you're building the OpenLDAP and NFS setup in your home for fun, then both work equaly well :)

That helps me better understand ACLs and the implications of using the two NFS 'home' approaches. I didn't fully understand the overhead differences when choosing my direction, but your way looks better.

I am seeking to configure the client system for mitigating the user home folder availability automatically. Maybe this would mean to cache the user's NFS home data to the client file system. If the NFS mount is unavailable, then the user would automatically access the local copies. Otherwise, the NFS location would be used and the local folder synchronized. However, I don't have enough information yet to understand if my expectations are reasonable. Do you know if this is a valid setup and, if so, an available solution?

Otherwise, this is all I can come up with:

The machine 'nas1' is the network-attached storage device and exports '/export/home'.

The client machine 'test3' caches/mirrors the user's NFS home data to the local file system at '/home/'.

The client machine's '/etc/fstab' mounts '/home' over '/nfs/home'.

The user's LDAP account has 'homeDirectory' set to '/nfs/home/', which is where the user should access its data.

If the network share becomes available, then 'nas1:/export/home' is mounted at 'test3:/nfs/home' (not sure what any of that would imply for files already open on the local user folder).

I was hoping CacheFS would synchronize the NFS and local locations but the only information I could find suggests no. It is also unclear unclear to me if a machine associated with a particular user (like my laptop to me) can or should have a local account with the same user name, UID and/or GUID. This is getting off topic a bit from just the AutoFS but the questions seem to fit with the SSO approach.

I made a mistake when it was time to make a full backup on destination path so no backup exist and of course I encountered an other mistake chen I tryed to new gssapi.acl.ldif (on most important one I think :dn: olcDatabase={0}config,cn=configchangetype: modifydelete: olcAccessolcAccess: {0}

and now I'm not more able to modify anything....

I decided to stop slapd service and to restore /etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif from an old backup which contains deleted olcAccess....

I tryed to implement again new gssapi.acl.ldif, exactly same as yours exept about Domain and Realm names, and again it's impossible to modify anything more after first deleting olcAccess on dn: olcDatabase={0}config,cn=config....

Really I understand why but I don't see how to modify without error...

I found a solution to implement new ACLs as described and check with "ldapsearch -xLLLZWD cn=admin,dc=company,dc=com -b cn=config olcAccess" and all news ACLs were in right place so I decided to reboot server and now there are some wrong things I think :

I don't know why but when I made my first backup (just before modifying gssapi.acl.ldif) on which I made a mistake on my command :$ dossier6="/media/TRANSCEND/LDAP-LAN/ldap-srvr/cmds-executees/08-srvr"$ sudo tar zcvf $dossiers6/slapd.d.backup.tar.gz /etc/openldap/slapd.d

Last command was wrong because I wrote $dossiers6 and not $dossier6, well I don't know why but it wrote backup directly on /.....

Anyway, after long night spent to find a solution to repair, I found backup on / this morning and I decided to restore it.So I've done :$ sudo service slapd stop$ sudo tar -zxvf /slapd.d.backup.tar.gz -C /$ sudo shutdown -r now

During reboot all services started so I can conclude : everything is restored.

I found an other of my mistake on my gssapi.acl.ldif about uppercase/lowercase on OU.

Does uppercase/lowercase important or not ?

Now I'm a little afraid when I need to modify ACLs....

You will find below my gssapi.acl.ldif :# gssapi.acl.ldif## Specify ACLs for use with SASL GSSAPI Kerberos.# We will work on three different dn:# # First on dn: olcDatabase={0}config,cn=config# Second on dn: olcDatabase={1}bdb,cn=config# Third on dn: olcDatabase={2}monitor,cn=config

# Allow Kerberos /admin principals to see the Kerberos container, but not change it.# This will force administration of the Kerberos realm with Kerberos tools.dn: olcDatabase={1}bdb,cn=configchangetype: modifyadd: olcAccessolcAccess: {6}to dn.subtree="ou=kerberos,ou=services,dc=berok,dc=org" by dn.exact="cn=krbadmin,ou=Users,dc=berok,dc=org" write by dn.regex="uid=.*/admin,cn=berok.org,cn=gssapi,cn=auth" read by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.base="cn=admin,dc=berok,dc=org" read by * none

# Allo */admin principals to manage this OpenLDAP server.# This will be used with Apache Directory Studio.dn: olcDatabase={1}bdb,cn=configchangetype: modifyadd: olcAccessolcAccess: {7}to dn.subtree="dc=berok,dc=org" by dn.base="cn=admin,dc=berok,dc=org" manage by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by dn.regex="uid=.*/admin,cn=berok.org,cn=gssapi,cn=auth" manage by dn.exact="cn=krbadmin,ou=Users,dc=berok,dc=org" write by dn.exact="cn=nssproxy,ou=Users,dc=berok,dc=org" read by * none

I tryed to modify gssapi.acl.ldif and this time that seems to be ok in terms of ldif....

When I check if the RootDN can still see the configuration with ldapsearch -xLLLZWD cn=admin,dc=berok,dc=org -b cn=config -s base dn, I have :"Enter LDAP Password: dn: cn=config" as you said.When I check if a user with both UID and GID set to zero can see the configuration with sudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -b cn=config -s base dn, I have :"sudo: ldap_sasl_bind_s(): Invalid credentialsMot de passe :SASL/EXTERNAL authentication startedSASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=authSASL SSF: 0dn: cn=config"

So I think I have a mistake with ldap_sasl_bind while command still give good result...

How can I repair this, please ?

If I continu and check if a /admin principal has access to the configuration, I have :"kdestroykdestroy: No credentials cache found while destroying cachekinit -p fredouille/admin@BEROK.ORGPassword for fredouille/admin@BEROK.ORG:ldapsearch -LLLZb cn=config -s base dnSASL/GSSAPI authentication startedSASL username: fredouille/admin@BEROK.ORGSASL SSF: 56SASL data security layer installed.dn: cn=config"

It seems to work...

But when I check if the cn=nssproxy user can still work with ldapsearch -xZLLLWD cn=nssproxy,ou=Users,dc=berok,dc=org -b dc=berok,dc=org dn, I have :"Enter LDAP Password:ldap_bind: Invalid credentials (49)"

With regards to Kerberos, you have to treat OpenLDAP as a simple database. You don't use OpenLDAP commads or GUI browsers to update Kerberos data. It's simply that the Kerberos realm's data is stored within OpenLDAP and leverages it's replication capacity.

To add or remove Kerberos principals, use the kadmin interface.

sudo kadmin -p user/admin@REALM

Then type ? to see what commands are available to you. Most can use a regex. Such as getprincs host/* for example.

Sure, no problem. There's a few examples of the kadmin command in this page. You'll notice that the first principals are added with the kadmin.local command. This one only works when you're logged in the KDC (hence the .local name, which hints at localhost).

As with anything with Kerberos, make sure your NTP is working. It will save you hours of frustrating debug sessions :)

Hi David,Thanks for your earlier responses about kerberos on this page on Nov 14/15th.Actually I have openldap configured for 'bdb' database, TLS enabled and working fine. Also have Kerberos install done, working fine. I am planning to have openldap as repository for Kerberos, that's why I asked earlier questions. I am following your blog for this exercise.

Started cn=config configuration, completed slaptest steps successfully. Now everything set under /etc/openldap/slapd.d

Check them out. Make a copy of it. Playing with OpenLDAP ACLs is a pain (well any product's ACLs are a pain to setup :)

Search this blog post for kerberos.acl.ldif and check it's contents. Make sure you DO NOT blindly copy those. As I said, your setup is different than mine (i.e. your olcDatabase={2}bdb,cn=config is different than my olcDatabase={1}bdb,cn=config) .

Sometimes, I would update my ACLs and the next olcAccess query would return junk characters. I don't know why, but it's a real problem. I had to revert to backup files. Hopefully you don't have this problem.

As you can see, the only people that can manage this one is the root user (when you authenticate using sudo), the OpenLDAP manager and the Kerberos /admin principals. Anybody else can't even query this database.

Thanks David, for your quick response, you are very helpful, sincerely appreciate it. Really above info provided by you is very clear now. I will try on my end, and will let you know the outcome. Is it OK to ask you about the place from where you are responding to our queries. I just want to know, so that I dont want to disturb you during the odd hours.

Hi David, how are you ?, hope everything is fine.I am SS, back again :)I took your help with regards to ACL issues end of the last year, I messed up I think, so I started working on openldap freshly again by installing everything and following your steps 1 by 1. I am currently on Kerberos step, having some issues as below.==========================================================================[root@master1 ldap]# ldapmodify -xZWD cn=admin,dc=msr,dc=com -f /root/ldap/kerberos.ldifEnter LDAP Password: ldapmodify: modify operation type is missing at line 2, entry "ou=kerberos,ou=services,dc=msr,dc=com"=========================================================================Below is the method you have followed [root@master1 ldap]# ldapmodify -aH ldapi:/// -f /root/ldap/kerberos.ldifSASL/PLAIN authentication startedPlease enter your password: I have no idea what password it is expecting

Also, I have successfully completed TLS portion too and I am also able to complete adding ldif files without any issues before this Kerberos.ldif file, like users,groups and posixAccounts.When you get a chance, can you please look into ldapmodify step for kerberos.ldifPlease let me know , if you need any more information.

Hi David,Thanks for your prompt responses.Yes, you are right, ou=services is not there, I created first ou=services, and next I was successfully completed adding kerberos ou. Next, you have mentioned that you have written a 'super nice reply' for me. Did I miss anything, or those nice replies are the two replies you have posted for me.

BTW, is there any specific reason you've put KDC config (setting up the ldap db module) into /etc/krb5.conf rather than kdc.conf? I've found people do this either way, but the latter one looks more logical to me. The KDC configured by kdc.conf after all (while krb5.conf left for client conf only). And it is so on MIT kerberos website.

Also, presently, the kerberos schema requiers the container in which the realms are created to be of krbContainer ObjectClass and referred to as cn=kerberos,dc=example,dc=org (note CN= instead of OU=)There's a corresp. bug on ubuntu's launchpad which in turn references a discussion on MIT mailing list

Yet again thank you for this series, it got me started with LDAP and Kerberos.

And for the kdc.conf vs. krb5.conf, I honestly simply never had issues with it, so I've never dug out more info on that. I *think* the first time I tried to set things up, the default krb5.conf file had an example LDAP module configuration. But in any case, I guess there's more than one way to do it :) It sure does make sense to use kdc.conf for the KDC and leave krb5.conf for the client, I agree.

Then for the CN= vs. OU= conversation, if I check my own OpenLDAP servers, they do indeed use CN= as a krbContainer ObjectClass, but it's buried one step « down » if you'd like. To say this another way, I've decided to setup a ou=kerberos so that things look cleaner when you use an LDAP browser (such as Apache Directory Studio for example). So the kerberos admin has access to the entire subtree of...

As a side note, I have to say that I find ADS really clunky and unergonomic, though my dislike stems from it basically being Eclipse.) And though I'm not a big fan of web GUIs either (yes I'm picky :) I've found phpLDAPadmin way more adequate.

Hi David,Great article. I was trying to see config files but looks like all dropbox links are broken. Would appreciate if you can fix it. I have my current setup running, but I want to check if user needs to maintain separate password for kerberos and LDAP or passwd will change password for ldap and kerberos both for a specific user.

Thanks David, really appreciate it. Do you know if changing the password will change user password for both kerberos and ldap user account in this setup? I am not sure, if user will have separate password for Kerberos principal and LDAP user account.

As for the password, the users in this setup have a Kerberos and an LDAP password. I have not worked on nor tried to have them use a single password for both systems. If you manage to configure this, please let me know!