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...
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739!

vad3r · Posted: Mon Jun 09, 2008 9:38 am Post subject:

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
_________________
-- http://www.linuxaddicted.de/ | Please help to answer open questions

VinzC · Posted: Mon Jun 09, 2008 4:09 pm Post subject:

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).
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739!

VinzC · Posted: Mon Jun 09, 2008 8:50 pm Post subject:

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.
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739!

depontius · Advocate Joined: 05 May 2004 Posts: 3526

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.
_________________
.sigs waste space and bandwidth

VinzC · Posted: Tue Jun 10, 2008 7:11 am Post subject:

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 :lol:

...
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739!

depontius · Advocate Joined: 05 May 2004 Posts: 3526

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.
_________________
.sigs waste space and bandwidth

VinzC · Posted: Sat Jun 14, 2008 12:23 pm Post subject:

depontius · Advocate Joined: 05 May 2004 Posts: 3526

VinzC · Posted: Mon Jun 16, 2008 4:42 pm Post subject:

depontius · Advocate Joined: 05 May 2004 Posts: 3526

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.
_________________
.sigs waste space and bandwidth

VinzC · Posted: Tue Jun 17, 2008 7:13 pm Post subject:

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? :lol:

)

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:

_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739!

VinzC · Posted: Sun Jul 06, 2008 8:59 pm Post subject:

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: