> > This is always one aspect of Kerberos that still > > confuses me and I was wondering if someone could > > clear it up for me. > > You are not unique in this respect.
It's good to hear I'm not alone and that I really am understanding Kereros' specific/limited role in the system. Thank you very much for your clarifications and comments. > > Is Kerberos destined to remain just an authentication > > architecture and designed to just be part of some > > other system when it comes to the needs of most network > > environments in regards to user/group/service management? > > Would that be a problem? Why? We don't have a problem with the fact > that the people who build our locks don't also build our doors and > walls. No, it's not necessarily a problem, but to follow the analogy, the door makers have a standardized hole size for deadbolts and door knobs, and key and key ring manufacturers have agreed that there should be a hole in the key so that end users can put their keys on key rings to help manage them and the hinges on the doors are standardized heights in the door frame for hanging them. The point I'm driving at is that is that while I see no problem for Kerberos being just an authentication platform, some standardized methodology for creating an entire IAAA environment that utilizes Kerberos should be developed. For instance, if the KDC is only going to provide Authentication information, then perhaps the KDC should not be treated as the authoritative source for principals. Perhaps instead some other system should be used as the authoritative source and Kerberos is an authentication service within that other system (perhaps not all principals need authentication, they just need identification) and the KDC should actually query this other system to verify a principal exists and is authorized to be authenticated (AKA the account is active and not disabled). Further, the Kerberos standard should be extended and presented in such a way that it expects to be subordinated to some other larger authorization system. It seems to me that Authentication is merely the first step in an Authorization scheme. I cannot think of a time where I would care about the identity of a principal outside of the case where I am trying to authorize them for something. It seems to always be the case that before you go checking whether or not this principal is authorized, you need to find out if this principal is who they claim to be and the only time you care about this person being who they claim to be is when you are about to go find out if they are authorized. > > For instance, I have IMAP email, file servers, printers, > > ftp servers, LDAP servers, and client workstations. > > Each of these systems could benefit from associating > > Access Controls to Kerberos Principals, but from > > what I can tell Kerberos provides no standardized > > way for those services to get help in managing those > > ACLs from the Kerberos system. > > Directory services play very well with Kerberos, and are designed to > provide storage for groups, access control, etc. If you have LDAP > running, you have a directory server and that is one good place to > centralize authorization. But for this to be effective all my other applications would need to use an agreed upon authorization method for storing data into authorization backend wouldn't they? I mean I suppose each app could just roll their own, but then we've each application having to make their own storage formats, no standardized way for creating easy admin tools where users/groups can be listed and shuffled around. You get the potential for separate identifiers since one app decides it's going to use the UID of the principal where another app decides it's going to use the fully qualified kerberos ID DOMAIN/principal and yet another app decides just to use the local principal name, and yet some other app developed by a guy who really hasn't figured it all out yet decides to use his own principal names requiring a mapping scheme to be set up because he had no tools for testing existence/status of principals. Further, everyone of them either uses the local Unix group ID or ends up rolling their own group methodology so none of the applications can take advantage of a centralized set of groups. I really hope I'm completely wrong here and have misunderstood something really basic and important that makes none of the above true. I've seen people say "just use LDAP" but I don't think any of them have actually set up fine grained controls where their Kerberos principals can be put into groups and where the same set of principals/groups can be granted/denied permissions to print to specific printers, access certain directories on filesystems, access certain network file shares, access certain folders in the IMAP mail store, and access other services (web/ftp/etc) in a centralized way where if a principal is added/removed from the system (or even just added/removed from a group (if the service even supports groups)), the administrator doesn't have to go to every single service and tell it that the user now exists, or no longer exists. Sure if you remove the user from the KDC they can no longer get a ticket for the services, but the ACL information (aka cruft) is still there. God forbid a well ACLed employee should get married and change their principal name. It'd be great if the administrator could just go in and say "principal X is now known as principal Y and principal Y principal X is now an alias for principal Y" - but those kinds of semantics don't seem to exist in the current schemes... (Granted that in my example simply adding an alias to the existing principal would be easier, but that's not always the case.) Am I really missing something or is this really the current "state of affairs"? > Notice how Microsoft's AD does it: authentication is done using > Kerberos, attributes of principals are kept in a directory and served > up via LDAP, and authorization is the responsibility of each object > type (with the OS providing a general access-control framework). (The > accounting bit is kind of mysterious and haphazard but can be made > useful.) Right, it's that "(with the OS providing a general access-control framework)" piece that I can't find an Open Source equivalent of. Some people have suggessted that a system _possibly could_ be implemented using PAM, but no one seems to really know exactly how. > > Are there any Open Source solutions for implementing > > a total package solution (where total package is both > > Authentication and Authorization - I'll figure out > > the others later)? > > A number of people are using Kerberos+OpenLDAP. <snip> > Of course the service needs code which can do this. And it still doesn't seem to do anything other than a Boolean yes/no (as opposed to read/write/execute for instance), or it has to provide it's own principal tree and manage yet another independent copy of each principal that it has a special ACL for (making adding/removing/modifying principals a major PITA). I suppose this also reinforces my earlier semi-conclusion that Kerberos should really just be viewed as an authentication service within the domain but that even it is a subordinate part to a larger authorization system. > Building something vaguely like ADS is not too hard, but there are a > lot of separate pieces. Building something interoperable with ADS is > a much larger task, but even that appears doable. The OS advantage is > that you get to *see* how your system is secured and managed, instead > of depending on a magical black box. OSS also saves a poor guy like me from having to pay $900 to have a home network based on linux. ;) Well for the time being I decided to skip on stuff like automatic service announcement/discovery and the Windows registry where you can have per user/per application/per machine/per domain type configuration options stored. I'm also not trying to build something interoperable with MS AD (I'll leave that for the brilliant folks over at the Samba project). I'm just a relatively new guy to Kerberos who was expecting an Authorization system to compliment the authentication system but all I've found so far is that each application has to do a "roll your own" authorization scheme. I guess the worst part is that I feel like I'm whining, complaining, or otherwise just stupid because the need seems so obvious to me that I'm assuming that it just has to be there because I know I'm not the first one to bump up against this problem. I can live with whatever the "state of affairs" is, I might even be able to help contribute to some project to help improve things, but at the moment, I feel like I don't really know what the authoritative "state of affairs" in regards to standardized Kerberos compatible Authorization schemes is. Thank you very much for your support/responses. I truly appreciate them and am supplementing what I've learned so far with them. So I am learning here and hope that I can get that understanding of what the options/state of affairs is so I can move forward rather than wandering around in a state of confusion. -- Michael -- ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
