Thanks for the reply!
> So I'm not the expert on how AD works, so I can't speak for what happens
> if you create a service account called _one_ thing and then have a
> different principal name. Like, what name ends up in the service
> ticket? But, moving on ...
I was a little fuzzy on that, but I was under the impression that in my case
the serivce principal for AFS has to be called "afs/mydomain.com". Is that not
so? Therefore, one could either create an AD account literally called "afs",
or, let the ktpass command create a SPN for the account, and let it's name
conform to local naming standards. Indeed we can see that the SPN is created,
by running setspn on Windows:
C:\>setspn -L srvAFS
Registered ServicePrincipalNames for
CN=srvAFS,OU=Users,DC=ad,DC=mydomain,DC=com:
afs/mydomain.com
> kvno is used when you already have a Kerberos ticket (with kinit) and you're
> getting a service ticket for what you give on the command line. I think
> what you want "kinit adUser" and the "kvno afs/mydomain.com". Although
> aklog should do the same thing.
>
> It would be interesting to see what the output of "klist" is after you
> do that kinit/kvno command sequence.
$ kinit adUser
Password for adu...@ad.mydomain.com:
$ kvno afs/mydomain.com
afs/mydomain....@ad.mydomain.com: kvno = 5
$ aklog -d
Authenticating to cell mydomain.com (server myserver).
Trying to authenticate to user's realm AD.MYDOMAIN.COM.
Getting tickets: afs/mydomain....@ad.mydomain.com
Using Kerberos V5 ticket natively
About to resolve name adUser to id in cell mydomain.com.
Id 204
Setting tokens. adUser @ mydomain.com
$ klist
Ticket cache: FILE:/var/krb5/security/creds/krb5cc_204
Default principal: adu...@ad.mydomain.com
Valid starting Expires Service principal
08/24/22 12:28:35 08/24/22 22:28:35 krbtgt/ad.mydomain....@ad.mydomain.com
renew until 08/25/22 12:28:30
08/24/22 12:28:51 08/24/22 22:28:35 afs/mydomain....@ad.mydomain.com
renew until 08/25/22 12:28:30
> There is some magic that asetkey does in terms of key version numbering
> for rxkad_krb5 but it escapes me now and I suspect that's not your real
> problem. I am assuming you've distributed the KeyFile to _all_ of your
> AFS servers.
This is the first AFS server, so there's no other servers to distribute it to
yet.
# asetkey list
rxkad_krb5 kvno 5 enctype 17; key is: blahblahblah
rxkad_krb5 kvno 5 enctype 18; key is: blahblahblahblahblahblah
All done.
It seems like it's close but I'm just missing one thing... not quite sure what
though.
Thank you so much!
-Ben
________________________________
From: Ken Hornstein <k...@cmf.nrl.navy.mil>
Sent: Wednesday, August 24, 2022 11:42 AM
To: Ben Huntsman <b...@huntsmans.net>
Cc: openafs-info@openafs.org <openafs-info@openafs.org>
Subject: Re: [OpenAFS] Kerberos + Windows
>I then created the service account srvAFS, and extracted a keytab on the
>Domain Controller using the following command:
So I'm not the expert on how AD works, so I can't speak for what happens
if you create a service account called _one_ thing and then have a
different principal name. Like, what name ends up in the service
ticket? But, moving on ...
># kvno adu...@ad.mydomain.com
>kvno: Server not found in Kerberos database while getting credentials for
>adu...@ad.mydomain.com
kvno is used when you already have a Kerberos ticket (with kinit) and you're
getting a service ticket for what you give on the command line. I think
what you want "kinit adUser" and the "kvno afs/mydomain.com". Although
aklog should do the same thing.
It would be interesting to see what the output of "klist" is after you
do that kinit/kvno command sequence.
There is some magic that asetkey does in terms of key version numbering
for rxkad_krb5 but it escapes me now and I suspect that's not your real
problem. I am assuming you've distributed the KeyFile to _all_ of your
AFS servers.
--Ken
