[OpenAFS] Re: AFS + CrossRealm + FreeIPA + Migration
Fri, 7 Nov 2014 10:39:23 -0600
On Fri, 07 Nov 2014 11:41:21 +0100
Andreas Ladanyi <email@example.com> wrote:
> old server:
> MIT Kerberos 5 - Realm A
> new server:
> FreeIPA 3.3
I don't suppose you know what version of MIT krb5 this is based on?
> Service principals:
> afs/"FQDN of the old Server with AFS server daemon"@Realm B
I'm a little confused by this; we only use afs/cell.example.com
principals with the cell name, which is usually not the FQDN of a
server. Are you planning to migrate to a new cell name based on the
old-server FQDN? Or did you mean afs/"AFS CELL"@REALM B here?
> new PC Testclient:
> Ubuntu 14
> I could login as user, get a shell and a tgt. The afs client is running.
A TGT for which realm? Do you know if the client is also using MIT krb5?
> The clients CellServDB points to the "AFS CELL" and AFS server on the
> old server system.
> An aklog -d shows the message:
> Authenticating to cell "AFS CELL" (server "THE OLD SERVER").
> Trying to authenticate to user's realm REALM B
> Getting tickets: afs/"AFS CELL"@REALM B
> Kerberos error code returned by get_cred : -1765328370
> aklog: Couldn't get "AFS CELL" AFS tickets:
> aklog: unknown RPC error (-1765328370) while getting AFS tickets
This is a little puzzling, since we're trying to use afs/"AFS
CELL"@REALM B, but above, it was mentioned the service princ that exists
is afs/"FQDN of the old Server with AFS server daemon"@Realm B, unless
that was a mistake, or they are the same thing.
Anyway, you can kind of test this without using any AFS components,
which can maybe make this a bit easier (and makes it easier to ask krb5
or FreeIPA people about it, if you want). Just run this:
$ kinit # if you haven't already
$ kvno afs/CELL
$ klist -ef
(All three of those commands will have realms, if you want to obfuscate
them.) You'll probably just get the same error that Brandon told you
about, but it's good to make sure. You can also try 'kinit'ing with a
principal from REALM A and see if that changes anything, or requesting
the afs/CELL princ from REALM A vs REALM B, etc.
Or change what enctype you request like so:
$ kvno -e des-cbc-crc afs/CELL
$ kvno -e aes256-hmac-cts afs/cell # this should _not_ work
Can you get any of those variations to work? If you can see which work
and which fail, it can point to what's causing it to fail.