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 [email protected]:
$ kvno afs/mydomain.com
afs/[email protected]: kvno = 5
$ aklog -d
Authenticating to cell mydomain.com (server myserver).
Trying to authenticate to user's realm AD.MYDOMAIN.COM.
Getting tickets: afs/[email protected]
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: [email protected]

Valid starting     Expires            Service principal
08/24/22 12:28:35  08/24/22 22:28:35  krbtgt/[email protected]
        renew until 08/25/22 12:28:30
08/24/22 12:28:51  08/24/22 22:28:35  afs/[email protected]
        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 <[email protected]>
Sent: Wednesday, August 24, 2022 11:42 AM
To: Ben Huntsman <[email protected]>
Cc: [email protected] <[email protected]>
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 [email protected]
>kvno: Server not found in Kerberos database while getting credentials for 
>[email protected]

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

Reply via email to