Kerberos 5, LDAP, and Time-of-Day Constraints?

David asks: "I've come across a need for a single sign-on solution needing the ticket services of KRB5 and the backend store of LDAP for an enterprise system involving multiple operating systems. KRB and LDAP are required components. In short the solution needs to authenticate users and authorize host/group/client services such as SSH based on time-of-day/day-of-week schedule. With PAM, time-of-day is easily arranged in a flat file: /etc/security/time.conf using pam_time.so. Unfortunately, this is a single host-based answer, and the complex collection of systems in use means this isn't feasible. It's certainly easy to extend a KRB5 schema for LDAP to store this information, but I haven't found any place that utilizes such a setup. In contrast, this is found on Microsoft but that isn't a solution we're willing to engage. So the question is, are there any resources available where this feature of pam_time.so is pushed into the Kerberos/LDAP interaction or do I need another layer dictating authorization values to KRB?"

Comments

Resist the urge to equate AuthN with AuthZ

[forsetti]

Time-constraints are an "authorization" (AuthZ) issue, not an "authentication" (AuthN) issue. Kerberos does its job well because it is focused solely on AuthN. Try to avoid the urge to make it do AuthZ as well.

So, what to do ...

If you are looking to limit Windows hosts, you won't be able to use LDAP directly. For central AuthZ of Windows services, you will have to use either AD or NDS, both of which support time-of-day contraints. With AD (not sure about NDS), you can leverage your Kerberos AuthN with a cross-realm "trust", and use AD for the AuthZ (Kerberos princ gets mapped to an AD princ). Perhaps Samba as a fake-PDC could also do this for you?

If you are only looking for Unix hosts, writing a PAM module is not too difficult. Perhaps you could simply modify pam_time to read it's config from LDAP.

Acroyms and geek talk

[maggard]

Before the whiners all start going "I didn't understand that, acronyms are haaard! " guess what: It wasn't written for you.

Seriously.

This is a geek website. Discussions here can be expected to be reasonably technical. Nothing in the original post is particularly esoteric, most IT professionals will understand most of the post and guess the rest.

Those who don't follow are welcome to read along. But acting like spoiled children and complaining this isn't all "babytalk" is not acceptable. If you really want to learn then look up the acronyms and post an explanation for all other the other lost folks.

Network Time Protocol == NTP

[mosel-saar-ruwer]

The original poster ["David"] said:

With PAM, time-of-day is easily arranged in a flat file: /etc/security/time.conf using pam_time.so. Unfortunately, this is a single host-based answer, and the complex collection of systems in use means this isn't feasible.

What you need is for your directory servers to be tied together with NTP [Network Time Protocol].

Novell has used NTP since the version of NDS that shipped with NetWare 4.00 way back in about 1993/1994.

So Novell would give you the time synchronization, with a good 12 to 13 years' worth of debugging of the algorithms and the implementations.

But trying to wing your own Kerberos + LDAP + NTP - gee whiz, that sounds like something at about the level of a Masters's Thesis, and probably the better part of a year's worth of work. The RFC for NTP is about the most challenging reading I've ever encountered in networking theory - to really understand what's going on, you need about a thousand pages' worth of background in the theory of stochastic processes & its application to a bunch of old AT&T switching standards.

I'd say "Screw that," and give the local Novell Rep a call - see what kind of a deal he can quote you.

Go commercial, just not AD

[wrfelts]

Your hesitence against AD is justified. Most of the standards that it implements are broken in some way, even Kerberos. It works decently when all of the dependant hosts are MS products, but there is quite a bit of trouble when tying in outside hosts. 3rd party extensions to AD are dependant on MS to not break their extensions on the next service pack (which often happens.) They typically don't even follow their own specs internally, as I have found out through extensive programming against AD. There are workarounds, but you sometimes don't know that there is an issue until after implementation. I have actually had AD return truncated partial results without a warning or error message that went unnoticed for a while. Basically, you can't trust an AD request to be accurate without double-checking each interface into it for corroborating results. MS knows these issues internally and programs around them. The public documentation of them is enemic at best, which leaves us in the dark. Stay away from AD in a mixed environment, or one that YOU have to program against.

On the other hand, Novell's eDirectory (NDS for all you old codgers) is solid, clean, robust, and consistent. It has Kerberos options and time locking options (and has had them for MANY years.) You could "roll your own" if you you are not faint of heart, but I don't recommend it with such a fine product available. eDirectory also runs native on NetWare, Linux, various Unixes, Windows, and several mainframes. It takes a bit to wrap your brain around their products but it is well worth the effort.

good luck!