[OpenAFS] Re: Creating service principal and keytab from active directory for afs/cell

[Arne Wiebalck]

Thanks Andrew and Jeffrey.=0A=
=0A=
So, from what I understand from your answers is that as long the=0A=
AFS server has a rxkad.keytab that contains the enc type the=0A=
KDC issues, things should be OK afs-wise.=0A=
=0A=
To answer Andrew's questions: the test realm is a clone of our=0A=
production one, so it can issue service tickets for afs/testcell@testrealm.=
=0A=
With the corresponding changes to krb5.conf, CellservDB and the=0A=
like aklog will get you a session key/service ticket pair for the test=0A=
realm's "AFS service" (there are no AFS servers the client could talk=0A=
to, but that does not stop the client from getting a token). For that=0A=
sess/tkt pair I was surprised to see DES/ArcFour with old AFS client=0A=
versions and AES/AES for new client versions. Does that make sense?=0A=
=0A=
The reason I am doing all this is because our batch system uses=0A=
some home made tools to decrypt the token which is used to verify=0A=
a user's identity, and I managed to port that tool to decrypt AES, but=0A=
not ArcFour. The tool basically uses the functions the AFS server code=0A=
uses I didn't get round to look into that much more, but when I saw this=0A=
thread I thought it maybe worthwhile to jump in and ask if I am trying to=
=0A=
achieve something that is not achievable.=A0=0A=
=0A=
Cheers,=0A=
=A0Arne=0A=
________________________________________=0A=
From: openafs-info-admin@openafs.org [openafs-info-admin@openafs.org] on be=
half of Andrew Deason [adeason@sinenomine.net]=0A=
Sent: 26 September 2013 17:52=0A=
To: openafs-info@openafs.org=0A=
Subject: [OpenAFS] Re: Creating service principal and keytab from active di=
rectory for afs/cell=0A=
=0A=
On Thu, 26 Sep 2013 15:28:16 +0000=0A=
Arne Wiebalck <Arne.Wiebalck@cern.ch> wrote:=0A=
=0A=
> > For Windows 2003 I believe it should be RC4-HMAC-NT, yes. But for=0A=
> > newer versions, you need an AES (this starts with 2008 or 2008 R2).=0A=
> > But there=0A=
>=0A=
> Does that mean access to updated AFS servers would fail if AD handed out=
=0A=
> ArcFour encrypted service tickets for AFS?=0A=
=0A=
No no, sorry, I think I was trying to simplify too much and that came=0A=
out wrong. You just need to get the same enctype as AD issues, whatever=0A=
that is. Windows 2003 I believe will give rc4 by default (as that is the=0A=
strongest enctype it supports), but later versions can give you aes. The=0A=
instructions I linked earlier have some information on how to handle it.=0A=
=0A=
> With our 2008 R2 test domain controller I see that not-yet-updated=0A=
> clients get ArcFour service tickets (and DES session keys) while new=0A=
> clients get AES service tickets (and AES session keys). I don't have a=0A=
> test AFS cell at hand though, hence the question.=0A=
=0A=
I'm not sure what you mean by this, though; if there's no afs cell, I'm=0A=
not sure what clients you're talking about, and what they're receiving a=0A=
service ticket for. The client should not be able to impact the enctype=0A=
selection of the service ticket, and it can be a security issue if they=0A=
can. There is an option in AD that lets you do that, but it's a really=0A=
bad idea to turn it on unless you really really need it. (Previously=0A=
brought up here:=0A=
<http://lists.openafs.org/pipermail/openafs-info/2013-July/039763.html>)=0A=
=0A=
--=0A=
Andrew Deason=0A=
adeason@sinenomine.net=0A=
=0A=
_______________________________________________=0A=
OpenAFS-info mailing list=0A=
OpenAFS-info@openafs.org=0A=
https://lists.openafs.org/mailman/listinfo/openafs-info=0A=