Kerberos 5, LDAP, and Time-of-Day Constraints? 34
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?"
Client-side support (Score:5, Informative)
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 [padl.com] 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.
OR... (Score:4, Informative)
Putting such script in the machines' crontabs would be sufficient, IMHO.
YMMV, HTH
Re:OR... (Score:2)
You are correct, sir!
Nicely done. ;-)
Krb = Auth, not Access (Score:1)
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 =)
Re:Krb = Auth, not Access (Score:1)
Active Direc... (Score:2)
Does Novell support it?
Re:Active Direc... (Score:3, Interesting)
Network Time Protocol == NTP (Score:2, Insightful)
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 synchroniza
Re:Network Time Protocol == NTP (Score:3, Informative)
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. (Score:3, Informative)
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 Ti
Resist the urge to equate AuthN with AuthZ (Score:5, Insightful)
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 (Score:4, Insightful)
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.
Open Directory? (Score:1)
Re:Open Directory? (Score:1)
So to paraphrase your comment - I don't really know anything about this subject and I can't really contribute anything useful or relevant to the original question, but I thought it might be a good op
Don't turn down a good solution out of pride... (Score:3, Funny)
"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:Don't turn down a good solution out of pride... (Score:2)
Re:WTFFF? (Score:2)
Ah, no biggie... My karma can handle it, and I've mostly gotten used to Slashdot's moderation as about 25% completely random.
In this case, I can only guess that the modder never made it past my pathetically weak joke (although that would seem to warrant "unfunny" rather than "troll", but I did warn that I needed sleep). That, or just the typical MS-hater with points.
So it goes... Just roll with the mods, and hope the good ones win over ti
Don't reinvent the wheel (Score:1)
Re:Don't reinvent the wheel (Score:1)
You haven't done much programming against AD, have you?
Your AD environment must not be too complex either. AD is a verifiable dog. It is a statistical fact that a MS backend takes much more time and man-power to manage than *Nix, Ne
Alternative solutions... (Score:4, Informative)
* 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 (Score:2)
What if the user is already logged-in? (Score:2)
Short answer: CRON (Score:2)
Write your own PAM module (Score:2)
Sounds pretty trivial...
Go commercial, just not AD (Score:2, Insightful)
Netscape legacy (Score:1)
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/acces [sun.com]