On 10/4/2011 8:41 AM, stasheck wrote:
Hi to all, I write here in search for some conceptual advice (the actual help will be needed far further down the road). First, a bit of background. My company started work as a contractor. One of our clients' security requirements was to create physically separate network, just for people working for this contractor. This way, we initially had 2 internal networks: one is "ours", and the other "contractors". This way, when OpenAFS has been introduced, two separate "worlds" has been created - complete with separate LDAP and Kerberos databases, and separate OpenAFS systems. As if that wasn't enough, short-sighteness of my precursors caused them to name BOTH of those worlds the same name - let's say "TEST.INT". That surely was *great* idea at the time, because it reduced administrative overhead a bit. Also, DNS space is doubled - so there are e.g. two afs servers, named the same, just in different networks. What noone saw coming, was a bit of relaxation from our contractor - and some time ago they agreed that IPs from "ours" network can (after all) be accessible from "contractors" - but not the other way round. Let me point the areas of problem: - user authentication - in both "worlds" users are named the same,
If the same principal appears in both Kerberos realms, does it represent the same individual? If the case was the same username in each realm represented only one individual, you might be able to merge the two realms into one. If there are only a few conflicts, you might beable to change some principals before a merge. Is the Kerberos V5 or V4.
they are in realm that's named the same, but is a different one - AFS servers -
Server names are not a big problem. If the two AFS cells have the same name that may be a problem.
they too are named the same; furthermore, the one from "ours" network can't "see" one from "contractors", but the one from "contractors" can see "ours" just fine (think of it as iptables related,established - type - firewall) - two separate DNS instances - oh, and currently we've got ~1000 users and 1,5k computers in our network What's more, now we've got plans to introduce AD domain in "ours" network. Great, another Kerberos, another AAA system in place. How about I (and my fellow sysadmins) will try to fix and simplify it as much as possible?
And I assume the AD top level domain name would end up being the same as the current 2 Kerberos realm names????
I've already put in motion a plan to "flatten" DNS space, so names will be unique - so we can treat that as nearly non-issue.
Keep in mind, that AD like to have the DCs and other windows servers with a DNS domain name == AD domin name. The AD domin name is then the Kerberos realm name (in uppercase) when AD is using Kerberos. You can register other Unix machines in AD Kerberos where the DNS domain name is not the same as the AD domain name.
Next idea is to allow "contractors" network users to use AFS resources from "ours" network (already a handful requests about that). What I already figured: - I have to change at least one of Kerberos realms to some other name (e.g. CONTRACTOR.TEST.INT)
AN AFS cell name does not have to match the Kerberos realm name at least when Kerberos v5 is used. Are you using the kaserver and the built in Kerberos v4? If so that may make a conversion to AD and Kerberos v5 easier.
- I have to move AFS infrastructure to the new realm Those are already two things I have no idea how to do smoothly (I mean, 1 weekend service window tops - you know, there are people working there :-) ). So, any advice would be appreciated. - I *think* that after that, having access from CONTRACTOR.TEST.INT to TEST.INT will be a piece of cake - if every user will re-authenticate with [email protected] after logging to his/her workstation as [email protected]. Acceptable, but I'd like to be better than that - I would like to allow access to TEST.INT if one is already authenticated for CONTRACTOR.TEST.INT. From what I've seen, it's quite possible (of course, if stupid firewall won't come in between :/) Next: (actually, it may happen that it'll be the first thing to do): stupid Windows Domain. I already figured I need to move away from OpenLDAP to 389 Directory Server, so the AD can be kept in sync with LDAP; what I haven't figured is "is it possible to use just one Kerberos login", and "which Kerberos should it be".
For unix machines you can continue to LDAP for authorization and Kerberos for authentication. You don't have to use AD for the authorization but you could.
As far as I know, Microsoft decided to add some custom bits to its Kerberos implementation, which would mean that if I want to keep just one user password database, it will be AD's. So, in fact, I'd need to move away from my precious MIT Kerbers TEST.INT towards AD implementation. But I'm not sure what that'd mean for OpenAFS - i.e. can I run OpenAFS user auth from AD Kerberos?
Yes, we have been doing it for years. All users are in the top level AD domain. Unix servers as well as an afs/cellname@realm principal. Our cellname == AD domain name but that is not required.
Another possibility (one I hope for) is that my lack of extensive experience with Kerberos and OpenAFS means I'm missing something simple. Or maybe what I devised is simple, it just seems complicated? I'll just re-iterate my goal: "flat" address and realm space, one (or two) user databases.
Could work. One AD domain for Windows and all users for authentication, and AD for windows authorization, and a LDAP for Unix authorization. You would still have the AFS PTS with is user and groups as a seperate authorization database.
Comments are very welcome. /br Stan _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
-- Douglas E. Engert <[email protected]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
