Slashdot Mirror
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?"
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.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
One thing I'd point out here, is kerberos is strictly authentication (you are who you say you are), and you're looking to control access (I dont care if your bob, you're not getting in here [at this hour]).
That not withstanding, you could probably do some evil haxoring w/ OpenLDAPs latest versions which allow for fairly programmatic data control, and have a custom schema value in ldap such as CanLogin, require that in your libnss_ldap or whatnot.
Just a thought =)
-- (appended to the end of comments you post, 120 chars)
I was going to say 'Active Directory' can do that, but you say you don't want to use that.
Does Novell support it?
You may be able to do this with radius. http://identityengines.com makes a product that'll do the AAA stuff with time constraints.
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.
10b||~10b -- aah, what a question!
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.
I don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
I'll preface this comment with the statement that I don't actually know enough about kerberos and ldap to actually offer advice. I do know, however, that Open Directory that ships with Apple's OS X Server product, it uses kerberos and ldap to handle user authentication. Just thought it would be worth mentioning.
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.
The original poster ["David"] said: 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.
Everything that you are trying to do has been done already. I'm sure you have some *reasons* for not using Active Directory, but I'm not sure that they are the right reasons. Personally, I'm not a big fan of MS products, but AD *is* slick, and does its job when configured correctly (just like most things). There are even tools out there to get your *nix boxes to work with AD (I use Vintela Authentication Services at my workplace, but there are others) - they aren't that expensive, and they don't require a lot of engineering and administration like some free "solutions" do.
If you have Windows system in your environment, you really want them to run well and not have problems... because fixing design or compatibility problems on that platform can be a real pain. Where as *nix systems can be tinkered with more easily (and *nix admins are more prone to tinker). So picking something like AD ensures that the troublesome side of the house stays quite and the flexible side of the house can adapt.
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:
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.
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.
cfengine is your friend.
You realize that even if you do get this working with a pam_time.so type setup that when someone logs in then they can stay connected even during those time they would not be allowed to ssh into a machine as long as they do not log out? That fact alone makes using pam_time.so type configs sort of pointless if that is what you are trying to restrict. Now there are ways around this to force people off of machines after a certain period of time or at specific times, but again do you want to do this and if you do I do not know a way to do this in a centralized manner.
Sounds pretty trivial...
In Soviet Washington the swamp drains you.
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!
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
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
Long answer: CRON. Use the same configuration that pam_time.so uses, and kill the processes whose owner is outside of the time table.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
What the fuckity fuck fuck??? Why is this moderated as a troll? Is it because he indicated the right solution was not Linux?
The original poster is a complete moron! He wants Microsoft Active Directory for some huge project but is too cheap or bullheaded to use the right tool for the job! Even if that tool costs very little.
All you need is one Windows server running Active Directory. That's a $500 purchase regardless of the number of users. Factor in the hardware and it could become a few thousand. But, since he's being so cheap he'd probably rather use $500 computers from Costco for his servers. This Ask Slashdot is positively banal.
Moderate this as a troll!
Fedora Directory Server http://directory.fedora.redhat.com/wiki/Main_Page and Sun Java Directory http://www.sun.com/software/products/directory_srv r/home_directory.xml are both derived from old Netscape LDAP solution and I can highly recommend it.n dex.xml like solution.
Time based ACI are supported with no problem and you are also free to provide directory services to MS products. To this end you can choose either the samba (which means extending the schema) or some fancy access manager http://www.sun.com/software/products/access_mgr/i
It is often neglected in discussions on the subject how important it is to make sure you got binding permissions right. If you forbid access to some identity based on time of the day constraints make sure this identity will always try to bind to the directory as "self" - not some other (higher) identity.