Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×

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

Posted by Cliff from the enhancing-schema dept.
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?"
This discussion has been archived. No new comments can be posted.

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

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

Comments Filter:

  • Client-side support (Score:5, Informative)

    by jonabbey ( 2498 ) * <jonabbey@ganymeta.org> on Wednesday March 15, 2006 @07:50PM (#14928944) Homepage

    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.

  • 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 =)
    • And if you're going to extend the schema with a CanLogin (or simmilar) attribute, It shouldn't be too hard to write something in (Perl/Python/Whatever) that could flip that value based on time of day (maybe even as cron job). Now all you have to worry about for the authentication is whether the CanLogin is set. All your other systems just check that attribute in LDAP when they pass along the authentication credentials. You could even store the time limits in LDAP and have your script flip the attribute base
  • I was going to say 'Active Directory' can do that, but you say you don't want to use that.

    Does Novell support it?

    • Re:Active Direc... (Score:3, Interesting)

      by BRTB ( 30272 )
      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.

      • 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 synchroniza

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


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

    by forsetti ( 158019 ) on Wednesday March 15, 2006 @08:52PM (#14929353)
    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 (Score:4, Insightful)

    by maggard ( 5579 ) <michael@michaelmaggard.com> on Wednesday March 15, 2006 @08:55PM (#14929366) Homepage Journal
    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.

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

      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)

    by pla ( 258480 ) on Wednesday March 15, 2006 @10:29PM (#14929815) Journal
    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.
    • I agree that the questioner has ruled out MS a bit too obliquely, and it's a good point that one could use just the KDC functions in AD. However, I doubt that "just the one Windows server" will be enough. We're talking about a critical piece of infrastructure in an organization that is evidentally large enough to justify the use of Kerberos and LDAP. They'll need redundant servers, and (if their sysadmins have only been managing Unix systems) they may need to train their sysadmins in proper Windows managem
  • 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

    • 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).

      You haven't done much programming against AD, have you?

      So picking something like AD ensures that the troublesome side of the house stays quite and the flexible side of the house can adapt.

      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)

    by timotten ( 5411 ) on Thursday March 16, 2006 @04:20AM (#14931150) Homepage
    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 [cfengine.org] 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
  • It is not that difficult. Start with the source code for pam_time and change it to get the configuration via LDAP instead of the local file.

    Sounds pretty trivial...

  • 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 a
  • Fedora Directory Server http://directory.fedora.redhat.com/wiki/Main_Page [redhat.com] and Sun Java Directory http://www.sun.com/software/products/directory_srv r/home_directory.xml [sun.com] are both derived from old Netscape LDAP solution and I can highly recommend it.
    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]

Slashdot Top Deals

"Ninety percent of baseball is half mental." -- Yogi Berra

Close