# What's the point of using Kerberos with LDAP?

## VinzC

Hi.

Does it make sense to use Kerberos at all with LDAP given that every HOWTO I've read uses SSL/TLS to connect to the LDAP server *anonymously* and check posixAccount's passwords stored in LDAP? This is surely not as secure as Kerberos, is it?

I mean kerberos has the main advantage of preventing password information from circulating over the network. Now if you want a centralized user management with LDAP your *only* choice is to allow for *anonymous* access to the password fields from all clients in your network!

In this case Kerberos doesn't make any sense at all does it? Just like putting an alarm system in one's house but leaving the doors open wide...

----------

## vad3r

You dont need to use a anonymous connection to get the data stored in your LDAP server. It doesn't matter if you use SSL/TLS or not.

Hope this helps

----------

## VinzC

Well, I've tried countless times to not use anonymous access but I haven't succeeded yet to have nss_ldap use anything else than anonymous bind. (BTW I mean logging onto a workstation with an LDAP account; let's be sure we're talking about the same thing.) What I'd like is nss_ldap to use the kerberos ticket that the user acquires during logging on. I haven't succeeded so far.

In fact I've succeeded in querying my LDAP server once I was logged, after calling kinit. But even then nss_ldap insists on binding anonymously to the LDAP server (as per the logs: anonymous bind disabled).

----------

## VinzC

Fact is [padl] documentation is either obscure or incomplete or missing. I've been struggleing with that [put any qualifier here] for more than three weeks without a) finding any relevant info, b) knowing what I'm doing, c) knowing what to do, d) knowing how to do it.

I *do* need help for it's driving me nuts.

----------

## depontius

I will freely admit that I'm a Kerberos/LDAP wannabe.  I've tried several times, and bounced off each time, mostly because of lack of time.  However, this is for my home network, and it's all for my own knowledge, so it's not as bad as it sounds.

But...

There was one series of HowTo's, and some discussion about having Kerberos use LDAP as its database, to store the keys.  Heimdal can be configured to do this, and MIT will be able to as of version 1.6.  ISTR that there are some decided advantages to being able to do this, but at this point don't remember the entire discussion.  But at the very least, it insures that your Kerberos and LDAP passwords are kept in sync, by definition and without extra glue.

I also seem to remember some discussion about taking, I believe, the authentication portion of pam and routing it directly to Kerberos instead of SSL/LDAP.  In that fashion I believe it no longer needs to do an anonymous bind for the password.

Keep in mind I was most intensively into this several years ago.  Last time I touched it was simply trying to use LDAP without Kerberos almost a year ago.  I count it as a blessing that I don't really have enough spare time to work harder on this.

----------

## VinzC

Well, thanks for the info, depontius. However I'm feeling desperate for I still haven't been able to put this all together. I really need information on how to put PAM, SASL, Kerberos and LDAP together.

For instance, someone told in a discussion list on nabble.com that it's a security hole to use the logging user's kerberos ticket to bind to LDAP -- which I don't understand at all. In fact it's what I'd like to achieve -- just that there doesn't seem to be complete information on how to do that.

I've also read that recent versions of nss_ldap support a (non documented) parameter, krb5_keytabname and a specific value of krb5_ccname, MEMORY:store_cred but when I use them the client cannot contact my LDAP server anymore... Imagine I had to dig the source code to find that!

Up to now all I can do is use an existing kerberos ticket cache file from /etc/ldap.conf. But I always fail to renew it. Without typing a password by hand. And if I must put a password in a script to renew the ticket... well, better forget about securing a network then, right?

I'm still digging the net and the sources to find information. Maybe in 8-9 months I'll be able to setup a complete LDAP/Kerberos single sign-on solution  :Laughing:  ...

----------

## depontius

I'll see if I can dig out some of my old references.  Have you been including SASL in your mix of acronym soup to tie this all together?  You mention it in your response to me, but I didn't see it before.  In all of the work I've read, SASL was essential because it included the GSSAPI stuff to talk to Kerberos at the client.  (If I understand correctly, that is.)

The 2 most "almost there" documents I read were a sort of "LDAP V3" by a guy with the handle "Turbo" and some stuff by Jose Gonzales Gomez.  If you just run Google with "openldap" "kerberos" "sasl" they'll float right near the top.

There's also an [LDAP-interop] mailing list that I once subscribed to, and never got much traffic from.  I know a while back I had some email problems, and I suspect I got bounced off the list, because in running this search for you, I found some recent results.  Anyway, I suspect it might prove to be a good resource, and I plan to resubscribe.

Hope some of this helps.

----------

## VinzC

 *depontius wrote:*   

> Have you been including SASL in your mix of acronym soup to tie this all together?  You mention it in your response to me, but I didn't see it before.  In all of the work I've read, SASL was essential because it included the GSSAPI stuff to talk to Kerberos at the client.  (If I understand correctly, that is.)

 

That's it. In fact I've first had trouble finding the appropriate keywords to perform a search good enough to return the results I expected. I've got none so far. All the kinds of guides I found were always setting SLAPD with at least anonymous read access to everything -- including LDAP password fields  :Shocked:  -- even those guides which showed how to setup SLAPD for SASL/GSSAPI.

As far as I can tell, what I've tried to achieve is a "single sign-on" system using Kerberos, PAM and LDAP, forbidding anonymous access to the directory. I've successfully setup Kerberos on the KDC server (which happens to be the LDAP server as well) and used principals to logon -- either on the server or on workstations -- but with corresponding accounts defined locally, i.e. on the machines I was logging on.

I've also successfully setup an LDAP server and used it either anonymously (e.g. ldapsearch -x [...]) or authenticated with SASL/Kerberos (e.g. ldapsearch -Y GSSAPI [...]). Both work after logging on with a local *NIX account.

So yes, I included SASL/GSSAPI in my acronym hot soup  :Smile:  .

 *depontius wrote:*   

> The 2 most "almost there" documents I read were a sort of "LDAP V3" by a guy with the handle "Turbo" and some stuff by Jose Gonzales Gomez.  If you just run Google with "openldap" "kerberos" "sasl" they'll float right near the top.
> 
> There's also an [LDAP-interop] mailing list that I once subscribed to, and never got much traffic from.  I know a while back I had some email problems, and I suspect I got bounced off the list, because in running this search for you, I found some recent results.  Anyway, I suspect it might prove to be a good resource, and I plan to resubscribe.

 

I've thought of subscribing in last resort for I still haven't found accurate information whether such a single sign-on system can be done or not. I'm making progresses but with very tiny, little steps.

As of now the only way I could force access to LDAP with Kerberos at the logon time was to logon as root, run kinit, copy the credential cache /tmp/krb5cc_0 to /etc/.ldapcache, change /etc/nsswitch.conf to include ldap for passwd, shadow and group, uncomment krb5_ccname FILE:/etc/.ldapcache from /etc/ldap.conf and then -- and only then -- logon with a user account that is stored in LDAP and which password is that of its Kerberos principal (LDAP password field being removed).Also I didn't realize immediately that you *must* set use_sasl on in /etc/ldap.conf. That feature is of course not documented in the man pages of nss_ldap. It's even not documented in most of the guides I found on the Internet -- I start to wonder if these were supposed to work  :Rolling Eyes:  .

Also note that the rare guides I found that talk about using /etc/.ldapcache also talked about renewing the latter ticket, without of course telling how to do that. But the ticket I get cannot be renewed -- as I could read from kinit's error message. The guides of course didn't mention either how to get a renewable ticket.

There is also one thing I still haven't understood.

Before putting LDAP into the game, you can create a Kerberos principal to use for logging on, provided you have defined a local UNIX account without setting its password. Then with a properly setup /etc/pam.d/system-auth the password authentication is done with Kerberos and the remaining information (shell, home directory, gecos) is read from the flat files in /etc/ (i.e. password and shadow, in which the password field is set to *K*).

But I've never succeeded in doing the same once I wanted to use LDAP. The only way I could logon with an account stored in LDAP was to change /etc/nsswitch.conf as explained above. Then I also saw that using nsswitch.conf makes PAM access my LDAP server *before* the password can be typed on the console login! That makes anonymous access to LDAP mandatory -- probably for checking if the user name exists.

So at that moment, the only way out I found was to use the credential cache file. LDAP is then queried using SASL/Kerberos but with the account information stored in the cached ticket, not that of the logging user. (Of course since he hasn't typed his password yet.)

With the current state so far, things happen as follows:the user types his/her logon name;

a Kerberos ticket is granted to the user stored in the ticket cache file;

access is made through SASL/Kerberos with that user account to the LDAP server;

a series of queries are made against the LDAP server to return... I don't know what yet;

the "Password" prompt appears;

the user enters his/her password;

a series of LDAP queries occur again with their responses; note that numResults is always 1, probably meaning the queries are successful -- at least I haven't checked for queries, which didn't have a different value;

the user gets his/her ticket from Kerberos

yet another series of LDAP queries

login granted, session open.Note I'm typing this from memory for my test LDAP server is a virtual machine that's hosted on my laptop and haven't powered the latter on yet.

This looks like kind of a chicken/egg problem (doubtlessly due to nsswitch.conf) but I'm about to dig the code of pam_ldap, in cases it can be used as a workaround for nsswitch.conf, trying to understand how and when it queries the LDAP server. I'm almost sure it can use the currently logging user's Kerberos ticket to query LDAP *after* pam_krb5 has done its job -- provided of course /etc/pam.d/system-auth is setup properly.

I really find it crazy to be forced to use a cached ticket from a user that's not supposed to logon just to be able to make the whole damn thing work... There has to be another way.

Given the length of time I've spent on this, especially not having found the whole solution yet, I understand what you mean by "blessing"...

----------

## depontius

 *VinzC wrote:*   

> 
> 
> Given the length of time I've spent on this, especially not having found the whole solution yet, I understand what you mean by "blessing"...

 

Are you doing this as hobby, or business?  I have a home network that's just a bit (?!) overgrown, that I also treat as something of a training ground in case I ever have to switch professions.  Admins are dime-a-dozen, but they can also find work anywhere, and there is room for differentiation.  So I run industrial-strength (BIND, ISC DHCP, Dovecot, Postfix, OpenVPN, etc.) software on my cast-off deskside machines I use as servers, and have this long-term, never-achieved goal of single-sign-on with the LDAP/Kerberos mix.

----------

## VinzC

 *VinzC wrote:*   

> Given the length of time I've spent on this, especially not having found the whole solution yet, I understand what you mean by "blessing"...

 

 *depontius wrote:*   

> Are you doing this as hobby, or business? [...] and have this long-term, never-achieved goal of single-sign-on with the LDAP/Kerberos mix.

 

I'm mostly doing this for my personal need of experimentation... but also in the hope I succeed for the small business I work for. I just can't stand failing on this one.

I'll probably go dig the code of pam_ldap to clearly understand how it works. I find it so much frustrating that padl gives that little information on their own business. It's as closed as proprietary software if nobody can understand what they've done. I swear I'll reach my goal. It'll probably take me some time but I simply can't admit giving up.

----------

## depontius

As we converse, the memories keep coming back.  I've really let this one drop for about a year, because I've been too busy.  But I guess I can dump more of what I remember.  It's going to be a bit of a ramble.

Last time I tried anything with SSO, it was LDAP-only.  I decided to try just that, and either add Kerberos to it, or rip it up and restart with Kerberos, once I had the experience.  But when I tried it that time I couldn't even get OpenLDAP working right.  I think it was because I had debris left over from an earlier OpenLDAP install that caused database conflicts with the new version, but never had/took the time to chase it down.  Incidentally, I was trying to us a Gentoo wiki document on LDAP SSO that was now marked as stale or deprecated, with no updated or replacing version.

When I first got interested, it was just interest until I ran into the "turbo@bayour.com" documents, and began reading them.  Shortly into that, I realized that it was quite RedHat or Debian (forget-which) specific, but it also got me looking for more information and reading the OpenLDAP mailing list.  Shortly after I found the HowTo from Jose Gonzales Gomez, which was actually Gentoo-specific, though for earlier versions than the current ones.

I pursued that HowTo, and got stuck on SSL certificates.  One line in there is that "OpenLDAP treats self-signed certificates with extreme prejudice," which can really be interpreted as, "Don't bother trying to use self-signed certificates with OpenLDAP."  At this point, I'd had both MIT and Heimdal Kerberos working at various times, and had kinit working, and extracted machine tickets to go onward with the integration.  But LDAP was really annoyed at my attempts to bind, because of the security issues.

I kind of dropped it, because I was (very slowly) learning about certificates.  I tried several programs and instructions, but didn't really have much luck until setting up an OpenVPN on my home server, and reading its "easykeys-rsa" HowTo.  I think somewhere around this point, I actually got OpenLDAP working and answering queries, but didn't tackle the Kerberos integration, and ran out of time.

So a few thoughts, beyond what I've written, which I haven't placed into the preceding context, because I'm not sure exactly where I should have put them...

My impression is that PADL sells this kind of integration service. They also give away things like pam_ldap and migrationtools, but if they're a bit sparse with the information, it might be because they're too busy, or because giving away too much information might erode their business model.

Another name to look for is "Howard Chu" - I remember seeing him pop up in the OpenLDAP mailing list, and he seemed to know his stuff, or at least know it better than my ability to know if he was right or spewing.  He might be involved with PADL, but I'm not sure.

PADL also has "migrationtools", which used to be a Gentoo ebuild, but has been withdrawn.  They are scripts which can turn your /etc/ passwords, groups, etc files into ldif files ready for import into OpenLDAP.  Though the ebuild has been withdrawn, last I saw PADL still had the script there.  I'm under the impression that the withdrawal was a Gentoo maintenance issue, as well as the fact that their usage is pretty much a one-off thing to get onto LDAP, and not sued thereafter.

The Jose Gonzales Gomez document urged using Heimdal over MIT Kerberos because at the time, the former was thread-safe and the latter not, and because the former was able to use LDAP as its database for storing passwords.  The latter issue is important because it lets you have one-stop shopping for the password.  Otherwise you have to wrap the password change operation, to change it in both LDAP and Kerberos databases.  Using LDAP as the database for Kerberos means that you have only one copy of the password, only have to change it once, and the possibility of falling out of sync is gone.  Over time, MIT Kerberos has worked on their thread safety, so I believe this issue is gone.  In addition, as of MIT Kerberos V 1.6, which is ~x86 in Gentoo, it can use LDAP as its database, so it appears to be on par with Heimdal.  In the intervening time I've heard of other problems with Heimdal, but don't know about their status.

I've collected quite a few documents on LDAP, and some of Kerberos.  If you want, use the "private message" button and I can send you some as email attachments.  I would also recommend searching IBM DeveloperWorks and/or IBM Redbooks for information.

----------

## VinzC

Thanks a lot for your advices, depontius. I'm indeed interested in your documentation. For now I'm a little bit short on time but I'll knock your door as soon as I can.

Also I remember reading Kerberos man pages that it now supports LDAP as its database. You need to include krb5.schema (IIRC) to use it on the LDAP server side. You might have to use Google to find it. The one I've found is dated 2004. I don't have it on the machine I'm typing at right now and I haven't planned to use it yet, focusing on getting PAM, LDAP and Kerberos married in good terms, if you know what I mean. (okay, threesome weddings are uncommon but we're supposed to be Open, aren't we?  :Laughing:  )

As for password synchronization, I've opted for no password in LDAP, keeping them in Kerberos database only. I'm secretly hoping that a clever PAM configuration can handle this appropriately, i.e. don't use LDAP for password service, for instance. I'm not likely to store everything in LDAP though. But I might want to wait to be convinced...  :Wink: 

----------

## VinzC

I've left this topic aside for a moment but I've recently had to come back to configure a mail/file server for small sized company using LDAP as its central user repository. Tuning my existing LDAP/Kerberos configuration a little more, I've come to realize it was rather pointless to have the directory accessed using Kerberos only in all circumstances if the directory didn't contain any sensible information like passwords -- I've deleted userPassword field from every posixAccount object.

So I've left /etc/pam.d/system-auth to use Kerberos for auth, account, password and session; I've also kept /etc/nsswitch.conf as is, i.e. use ldap for at least passwd, shadow and group. The key was to enable anonymous access to the directory instead of restricting to SASL/GSSAPI.

Here's my LDAP server configuration:

```
include      /etc/openldap/schema/core.schema

include      /etc/openldap/schema/cosine.schema

include      /etc/openldap/schema/inetorgperson.schema

include      /etc/openldap/schema/nis.schema

pidfile      /var/run/openldap/slapd.pid

argsfile   /var/run/openldap/slapd.args

modulepath   /usr/lib/openldap/openldap

moduleload   back_hdb.so

sasl-realm INSTALL.LOCAL

sasl-host ldap.install.local

sasl-secprops   noplain,noactive

authz-policy from

authz-regexp

      uid=root/admin,cn=install.local,cn=gssapi,cn=auth

      uid=root,ou=People,dc=install,dc=local

authz-regexp

      uid=root/admin,cn=gssapi,cn=auth

      uid=root,ou=People,dc=install,dc=local

authz-regexp

      uid=([^/]*),cn=install.local,cn=gssapi,cn=auth

      uid=$1,ou=People,dc=install,dc=local

authz-regexp

      uid=([^/]*),cn=gssapi,cn=auth

      uid=$1,ou=People,dc=install,dc=local

access to attrs=userPassword,shadowLastChange

   by dn="uid=root,ou=People,dc=install,dc=local" write

   by dn.regex="uid=.*/admin,cn=GSSAPI,cn=auth" write

   by self write

   by anonymous auth

   by * read

access to dn.base=""

   by dn="uid=root,ou=People,dc=install,dc=local" write

   by dn.regex="uid=.*/admin,cn=GSSAPI,cn=auth" write

   by * read

access to dn.base="cn=Subschema"

   by dn="uid=root,ou=People,dc=install,dc=local" write

   by dn.regex="uid=.*/admin,cn=GSSAPI,cn=auth" write

   by * read

access to *

   by dn="uid=root,ou=People,dc=install,dc=local" write

   by dn.regex="uid=.*/admin,cn=GSSAPI,cn=auth" write

   by * read

database   hdb

suffix      "dc=install,dc=local"

checkpoint   32   30 # <kbyte> <min>

directory   /var/lib/openldap-data

index   uid,cn,uidNumber,uniqueMember,gidNumber,objectClass   eq

index   memberUid   pres
```

My LDAP test server is ldap.install.local. Here's a sample LDAP client configuration:

```
suffix dc=install,dc=local

uri ldap://ldap.install.local/

ldap_version 3

scope one

pam_filter objectclass=posixAccount

pam_login_attribute uid

pam_member_attribute memberUid

pam_password exop

nss_base_passwd      ou=People,dc=install,dc=local

nss_base_shadow      ou=People,dc=install,dc=local

nss_base_group      ou=Group,dc=install,dc=local

nss_base_hosts      ou=Hosts,dc=install,dc=local

nss_reconnect_tries 4         # number of times to double the sleep time

nss_reconnect_sleeptime 1      # initial sleep value

nss_reconnect_maxsleeptime 16   # max sleep value to cap at

nss_reconnect_maxconntries 2   # how many tries before sleeping
```

In fact there isn't anything different from examples I saw in the various HOWTO's across the Internet. While I can now logon using LDAP accounts thanks to anonymous bind and nss_ldap, Kerberos should allow authenticated users to access their own attributes in read/write mode.

----------

