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

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