>> old server: >> ======== >> >> MIT Kerberos 5 - Realm A > What version? Version 1.9.2 from OpenCSW > >> new server: >> ======== >> >> FreeIPA 3.3 > I don't suppose you know what version of MIT krb5 this is based on? Version : 1.11.5 Release : 11.fc20
> >> 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? On the old server REALM A the AFS cellname is the same like the FQDN. At the moment i dont plan to migrate to a new AFS cell name. > >> 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? REALM B - the new FreeIPA server system. > Do you know if the client is also using MIT krb5? yes it is. > >> 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. On the old server system the AFS cell name and the fqdn are the same. > > 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: Yes. This is a great option. > > $ 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 kvno -e des-cbc-crc afs/cellname kvno: KDC has no support for encryption type while getting credentials for afs/cellname@Realm B (the new Realm on FreeIPA) kvno -e aes256-cts-hmac-sha1-96 afs/cellname afs/cellname@Realm B: kvno = 1 I think here is a problem with Kerberos. > > 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.
smime.p7s
Description: S/MIME Cryptographic Signature
