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

Client-side support

[jonabbey]

You'll need to get some custom code written for your systems, in order to get them to honor the time constraints you put in your LDAP server. You could do this most simply by modifying pam_ldap, probably, though I don't know whether there are any pre-defined schema/OID values that you could leverage.. you might need to define your own attributes and encoding.

Doing it at the Keberos level would work, but that would require modifications to the ticket granting server, so that it knows what services are to be constrained for which users on whatever schedule.

I'm not sure it does what you need, but you might check out the XAD Identity Server from PADL.com down in Australia. Luke Howard of PADL wrote the RFC 2307 which guides the use of LDAP on Unix systems for NIS-like applications (as well as the nss_ldap and pam_ldap modules that most folks use), and is generally an incredibly expert fellow.

You could also use something like our own Ganymede software to provide management intelligence for your central directory services, but as it's not specifically linked to LDAP or Kerberos (though you can adapt it to manage both, as we have), something like XAD is more likely to provide an appropriate framework for you.

If you were to be especially ambitious about doing the right thing, you'd talk to Luke about getting scheduled access controls into some successor to RFC 2307, and integrating support for those extensions into nss_ldap/pam_ldap.

Re:Active Direc...

[BRTB]

Novell via eDirectory does have the capability of restricting login access times, according to the management interfaces of NWAdmin and ConsoleOne. I've never tried to get it to talk Kerberos, though I imagine it'd be possible.

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.

Don't turn down a good solution out of pride...

[pla]

In contrast, this is found on Microsoft but that isn't a solution we're willing to engage.

"willing to engage"?

Take a course on management-speak recently? ;-)


Anyway... You can use a Microsoft KDC without bothering with the rest of the AD overhead (at least not on any other machines). If you just don't want to commit yourself to implementing a full domain with AD, you can do just the one Windows server and the rest your 'nix of choice.


That will satisfy all your target constraints except for actualizing your non microsofterian design paradigm, while still leveraging your market share of intellectual property and maximizing your focal penetration.

Hmm... Okay, ignore that last bit. Past my bedtime.

Re:Network Time Protocol == NTP

[jonabbey]

You misunderstand his question. He's not looking to slave the clocks together on his network.. as you say, NTP does that just fine (and more than just fine) right now. He's looking to enforce a restriction on login capabilities according to the time of day, using LDAP and Kerberos.

It's easy to represent such constraints in LDAP, the question is whether any of his systems will know what he's talking about if he does.

Implementation.

[mosel-saar-ruwer]

You misunderstand his question. He's not looking to slave the clocks together on his network.. as you say, NTP does that just fine (and more than just fine) right now. He's looking to enforce a restriction on login capabilities according to the time of day, using LDAP and Kerberos. It's easy to represent such constraints in LDAP, the question is whether any of his systems will know what he's talking about if he does.

Right, but you have to tie it all together: Kerberos, LDAP, NTP, Login Restrictions by Time of Day.

That's what an IMPLEMENTATION like NDS/eDirectory does for you.

And, believe it or not, IMPLEMENTATIONS are not trivial. Trying to roll your own - from scratch - could take from now until forever.

Look, back in May of 2000, LDAP folks were fantasizing about some hypothetical "Access Control Factors" they might implement someday:

Authentication Methods for LDAP

3.2. Access Control Factors

A request, when it is being processed by a server, may be associated with a wide variety of security-related factors (section 4.2 of [1]). The server uses these factors to determine whether and how to process the request. These are called access control factors (ACFs). They might include source IP address, encryption strength, the type of operation being requested, time of day, etc. Some factors may be specific to the request itself, others may be associated with the connection via which the request is transmitted, others (e.g. time of day) may be "environmental".

Access control policies are expressed in terms of access control factors. E.g., a request having ACFs i,j,k can perform operation Y on resource Z. The set of ACFs that a server makes available for such expressions is implementation-specific.

ftp://ftp.rfc-editor.org/in-notes/rfc2829.txt

At that point, Novell already had a directory IMPLEMENTATION that had about seven years worth of stress testing & debugging in the real world, and about 100 Million licenses sold and installed in the field.

Now again: Obviously everyone is free to try to roll their own implementations, but, gee whiz, it's really hard to imagine that you'd beat the price of NDS/eDirectory licenses, much less match NDS/eDirectory reliability & stability.

Alternative solutions...

[timotten]

There have been several good comments in this article, but I just wanted to add a few more... esoteric suggestions. :)

* For the back-to-basics approach... the power-switch is a very effective access control mechanism (both literally -- cutting electricity -- and figuratively -- stopping/starting daemon processes). You could, for example, put one set of users in the realm "dayworkers.example.com" on one KDC, and then put another set of users in the realm "nightworkers.example.com" on another KDC. To ensure that dayworkers can only login between 9am and 5pm, you use cron to start their KDC at 9am and stop it at 5pm.

* Implementing time-based constraints in the Kerberos layer kind of sucks -- you're only going to check the time constraints at session startup. Sessions that start before the cut-off can stay online after the cutoff. Ex: Suppose our rule is "members of group A can login between 9am and 5pm". A member of group A logs in to the SSH server at 4:30 pm -- he can stay online indefinitely because SSH won't try to re-authenticate or re-authorize him.

* It's most effective to implement the time-based constraint in each of your applications. The former is ideal in that each application can cope with the time change in an intelligent fashion. (One app might prompt a user to save before he gets cut off, another might issue a warning 5 min ahead, etc.) But this approach is also the most difficult, and that seems to be an important concern.

* It's also effective to implement this at the network layer -- only route packets from specific users at specific times. This could be easy to implement with a VPN-style system. Non-VPN solutions may be possible but, ehm, tricky.

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!

OR...

[hummassa]

he can write a single 4-line shell script that, using ldap-utils or somesuch, goes into his LDAP directory and writes pam_time.so's config flat file.

Putting such script in the machines' crontabs would be sufficient, IMHO.

YMMV, HTH :-)