[OpenAFS] Question Win AD domain, krb5 REALM

[Lars Schimmer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeffrey Altman wrote:
> Lars Schimmer wrote:
>> Hi!
>>
>> I=B4ve got some questions about Win LogOn and obtaining tokens/tickets
>> while logon.
>>
>> Our setup: 1 windows AD server (CGV is the domain name)
>> 1 linux MIT krb5 server (REALM: CGV.TUGRAZ.AT)
>> OpenAFS Cell cgv.tugraz.at
>=20
> Rename one of your realms.  Or add afs/cgv.tugraz.at service tickets to
> both realms with different kvnos and insert both keys in the AFS keyfil=
e.

Ok, not really easy but doable (just 20 PC and about 40 ppl here).
But what is the best way do go on from here?
OpenAFS cell is up and running with users.
Windows AD is up and running with about 20 PCs/users.
Given: a subnet .128/25 routeable.
And the cell with the server is out in CellServDB (yeah, I won=B4t change
my OpenAFS cell).

Wanted: a nice, "easy" krb5 setup, using the Win AD for users to logon,
OpenAFS as win profile dataspace and obtaining ticket/token at logon.

Is it no problem, to rename the AD to another name different from the
DNS server entry? (cgv.tugraz.at is our resolve).
I=B4m not really familar with AD and all its assumptions...


Is using the AD server as krb5 auth server the better way?

Using the linux MIT krb5 server as auth server seems not to be possible
(at least not for windows clients to logon).


>> Yes, two different krb5 server, it=B4s bad, I know.
>=20
> And it will make things almost impossible for you to support for any
> service other than AFS.

I=B4m willing to change it ;-)

>> Til yet (krb5 <3.1 and OpenAFS <1.5.16) everything went more or less
>> well. Win XP SPII clients are in the CGV domain, user logon and obtain=
ed
>>  krb5 tickets for CGV.TUGRAZ.AT and a token for cgv.tugraz.at (win
>> profile is on AFS space).
>=20
> You really should use KFW 3.2 and OpenAFS 1.5.19.  See the security
> advisories.  The critical thing you need to do is disable DNS lookups
> for Kerberos and disable the importation of the MSLSA: credentials.

Yes, we want to use the latest versions.

>> I just installed krb5 2.x or 3.0, setup the REALM info in the
>> krb5.config in C:\WINDOWS to the linux MIT krb5 server and configure
>> OpenAFS to obtain tokens while logging in.
>>
>>
>> I was told the official way now is to obtain tickets/tokens via the
>> leash manager 3.2 and not via OpenAFS 1.5.x
>=20
> Not Leash but Network Identity Manager using the AFS Credential Provide=
r
> installed by OpenAFS.  See the OpenAFS release notes.

Ok.

>> Right now I expirienced some flaws while obtaining tickets/tokens (use=
r
>> can change krb5 settings AFTER logon, but with not correct setting, th=
ey
>> can=B4t logon ??) or just not getting any tickets.
>> I assume the 2 krb5 servers (one AD server, one linux MIT) are the pro=
blem.
>=20
> yes they are.

Need to be changed.

>> Anyone got a hint/info about conifg this system the right way?
>> (no, not using only the win server or cross auth, I just think about t=
he
>> clients).
>=20
> Realms are unique by name.  As long as you have two realms with the sam=
e
> name you are always going to have problems.   You can hack around them
> for AFS but you are never going to be able to work around them for all
> services.  Microsoft provides a mechanism for performing domain name
> renames.  You really should consider using it.

I got the package and the docs, something to read ;-)
But I don=B4t know yet for sure it will work in our (only 1) subnet with
given DNS resolv and will provide a solution.

If I rename the AD, I need to do cross auth setup between MIT and win
AD, right?

> Jeffrey Altman
> Secure Endpoints Inc.
>=20
>=20


MfG,
Lars Schimmer
- --
- -------------------------------------------------------------
TU Graz, Institut f=FCr ComputerGraphik & WissensVisualisierung
Tel: +43 316 873-5405       E-Mail: l.schimmer@cgv.tugraz.at
Fax: +43 316 873-5402       PGP-Key-ID: 0x4A9B1723
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGRFiJmWhuE0qbFyMRAvkyAJ9gQ0M7qZn76Y1AbQlZk7tzZpdNkQCfTcdc
9aiT5RraxOXEwhgSGegFNWs=3D
=3D3vnm
-----END PGP SIGNATURE-----