On 10/5/2011 3:28 AM, stasheck wrote:
2011/10/4 Douglas E. Engert<deeng...@anl.gov>:
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?
Yes.
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.
That would be preferred course of action, except that it would allow
users of only "ours" network to login into "contractors" - and we risk
severe consequences for that. Mind you, the Kerberos protects also
workstation logon. So unless I'm missing something (I hope I do),
we'll still need 2 Kerberos realms.
Is the Kerberos V5 or V4.
V5, MIT implementation.
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 have, unfortunately. Is there an easy way to change AFS cell name?
Good question, I have not had to do it, others on this list would
know better then I.
If you want to create a new cell, and migrate to it,
The fs newcell -linkedcell might help, (AFAIK) if a volume is not found
in the current cell see if is in the linked cell.
cell aliases could help too.
(users have the cell names in scripts too.)
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 surely hope it doesn't. I am mentally prepared to create some
subdomain for AD - like ad.test.int, and the Kerberos domain would be
named the same. But what I would like to do is to allow users to have
just one password for all Kerberos-authenticated services.
So you are talking about Kerberos cross realm between an AD domain and a
Kerberos realm. Others do that, and we did at one time,
and move all the user to the top level AD domain and unix server in the
Kerberos domain. We since move the unix server to the top level AD domain.
Cross realm can be a little tricky as AD is not as flexible as other Kerberos
implementations.
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.
That's ok.
You can register other Unix machines in AD Kerberos where
the DNS domain name is not the same as the AD domain name.
You got me lost - I don't know what you're reffering to.
It has to do with adding host principals in to AD where the
DNS domain name of the host does not patch 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 n...@test.int after logging to his/her workstation as
n...@contractor.test.int. 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.
See comment above, about one password-rule.
Cross-realm or moving all users to the same realm can do this.
This is an old article, but the basic concepts still apply when
using AD and Kerberos together:
http://technet.microsoft.com/en-us/library/bb742433.aspx
All Kerberos implementations supports AES and RC4 now,
all default DES as being turned off.
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.
That's quite alright. Could you point me to some docs to learn how to
use AD Kerberos for OpenAFS? And, maybe even more important, is there
a migration path from MIT Kerberos V5 to AD Kerberos?
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.
That's something I hope for, except that this pesky "contractors"
network and its stupid firewall comes in my way. I'd still need to
solve the problem on how to auth users in "contractors" network
despite the one-way firewall (possible, I guess), and how to block
"ours"-only users from logging on "contractors". I feel there should
be some way to do this, I just don't know what is it.
Maybe I can use this parallel:
let's say there are users in Finances and Sales. Both departaments
have separate LANs. I want to give both Finances and Sales the same
Linux workstations, but somehow refrain Sales users from logging on
Finance's computers - but those from Finances can login wherever they
want.
Is there a way to do that?
Yes, you can use netgroups to control who can login on what system,
see: man netgroup. Can also work with LDAP where you store the netgroups
in LDAP and see the @netgroup entries in /etc/passwd. and it works
independent of how they authenticated.
Comments are very welcome.
I may add - this is of course not purely OpenAFS problem, but I write
here because the community is quite experienced with systems
integration.
/br
Stan
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
--
Douglas E. Engert <deeng...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
