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