Hi there!
   Thanks for the replies!

I got it working!!!

> In addition to the key version number you also need to know the encryption 
> type used to
> encrypt the service private portion of the afs/mydomain....@ad.mydomain.com 
> service
> ticket.  It is that encryption type which does not need to match either the 
> encryption type
> used to encrypt the client private portion of the ticket or the session key 
> which needs to
> match the keys added via asetkey.

Ah!  This is interesting:

# kinit adUser
Password for adu...@ad.mydomain.com:
# klist -e
Ticket cache: FILE:/var/krb5/security/creds/krb5cc_0
Default principal: adu...@ad.mydomain.com

Valid starting     Expires            Service principal
08/24/22 21:49:12  08/25/22 07:49:12  krbtgt/ad.mydomain....@ad.mydomain.com
        renew until 08/25/22 21:49:10, Etype (skey, tkt): 
aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
# aklog
# klist -e
Ticket cache: FILE:/var/krb5/security/creds/krb5cc_0
Default principal: adu...@ad.mydomain.com

Valid starting     Expires            Service principal
08/24/22 21:49:12  08/25/22 07:49:12  krbtgt/ad.mydomain....@ad.mydomain.com
        renew until 08/25/22 21:49:10, Etype (skey, tkt): 
aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
08/24/22 21:49:26  08/25/22 07:49:12  afs/mydomain....@ad.mydomain.com
        renew until 08/25/22 21:49:10, Etype (skey, tkt): arcfour-hmac, 
arcfour-hmac

After running aklog I have one that is using arcfour-hmac.  Didn't expect that.

I had only the AES types in my keytab, and hadn't run an asetkey for that one.
I had the original keytab pre-edits to remove all but the AES types, and I 
brought that back over and removed only DES, leaving the arcfour-hmac one, and 
then ran asetkey for it using the encryption type 23, bounced the server, and 
it worked!!

I also did end up adding in the "mydomain.com" and ".mydomain.com" entries in 
krb5.conf, and I put in a file /opt/openafs/etc/openafs/server/krb.conf with 
only one line that says "AD.MYDOMAIN.COM".

I'm glad this all working now!!  Thank you all so much for the help!!

-Ben



________________________________
From: Jeffrey E Altman
Sent: Wednesday, August 24, 2022 6:49 PM
To: Ben Huntsman; openafs-info@openafs.org
Subject: Re: [OpenAFS] Kerberos + Windows

On 8/24/2022 12:53 PM, Ben Huntsman 
(b...@huntsmans.net<mailto:b...@huntsmans.net>) wrote:

   Here's some configuration info:

   Let's say my cell is going to be mydomain.com.  My Active Directory is 
ad.mydomain.com, and my AFS service account is srvAFS.

When installing Active Directory for a domain "mydomain.com" it is best if the 
Active Directory domain is "MYDOMAIN.COM" instead of "AD.MYDOMAIN.COM".  This 
is because Kerberos clients will attempt to use the DNS name of the host as the 
Kerberos realm name.   The use of "AD.MYDOMAIN.COM" or "WIN.MYDOMAIN.COM" 
naming is common only in cases where there is a pre-existing Kerberos realm for 
"MYDOMAIN.COM".


  Here's my krb5.conf:

[libdefaults]
        default_realm = AD.MYDOMAIN.COM
        default_keytab_name = 
[FILE:/etc/krb5/krb5.keytab]FILE:/etc/krb5/krb5.keytab
        dns_lookup_realm = true
        dns_lookup_kdc = true
        forwardable = true

[realms]
        AD.MYDOMAIN.COM = {
                kdc = ad.mydomain.com:88
                admin_server = ad.mydomain.com:749
                default_domain = ad.mydomain.com
        }

[domain_realm]
        .ad.mydomain.com = AD.MYDOMAIN.COM
        ad.mydomain.com = AD.MYDOMAIN.COM


You also need to add


    .mydomain.com = AD.MYDOMAIN.COM

    mydomain.com = AD.MYDOMAIN.COM


since the Kerberos realm is not the same as the DNS domain name used for the 
AFS service principal.

[logging]
        kdc = [FILE:/var/krb5/log/krb5kdc.log]FILE:/var/krb5/log/krb5kdc.log
        admin_server = 
[FILE:/var/krb5/log/kadmin.log]FILE:/var/krb5/log/kadmin.log
        kadmin_local = 
[FILE:/var/krb5/log/kadmin_local.log]FILE:/var/krb5/log/kadmin_local.log
        default = [FILE:/var/krb5/log/krb5lib.log]FILE:/var/krb5/log/krb5lib.log


I then created the service account srvAFS, and extracted a keytab on the Domain 
Controller using the following command:

ktpass /princ 
afs/mydomain....@ad.mydomain.com<mailto:afs/mydomain....@ad.mydomain.com> 
/mapuser srvAFS /mapop add /out rxkad.keytab +rndpass /crypto all /ptype 
KRB5_NT_PRINCIPAL +dumpsalt

The use of 
"afs/mydomain....@ad.mydomain.com"<mailto:afs/mydomain....@ad.mydomain.com> is 
correct.     The "a...@ad.mydomain.com"<mailto:a...@ad.mydomain.com> service 
principal name should no longer be used and must never be used with Active 
Directory.


I verified that the account did not have the "Use only Kerberos DES encryption 
types for this account" box checked.  I then copied the rxkad.keytab over to 
the UNIX host.  I built OpenAFS with a prefix of /opt/openafs, so I put the 
keytab in /opt/openafs/etc/openafs/server

I used ktutil to delete the two des entries in the keytab.  ktutil indicates 
that the KVNO is 5.

I then added the keys to OpenAFS using the command:

asetkey add rxkad_krb5 5 17 /opt/openafs/etc/openafs/server/rxkad.keytab 
afs/mydomain.com
asetkey add rxkad_krb5 5 18 /opt/openafs/etc/openafs/server/rxkad.keytab 
afs/mydomain.com

For an Active Directory realm you most likely also need to add rc4-hmac, 
enctype 23.


Did the above "asetkey" commands succeed?   Since the cell is named 
"mydomain.com" I would expect asetkey to expand "afs/mydomain.com" to 
"afs/mydomain....@mydomain.com"<mailto:afs/mydomain....@mydomain.com> which is 
not going to be present in the rxkad.keytab file.


What is the output of "asetkey list" after the above commands were executed?

But things aren't quite working:

# ls /afs
afs: Tokens for user of AFS id 204 for cell mydomain.com are discarded (rxkad 
error=19270408, server 192.168.0.114)
ls: /afs: The file access permissions do not allow the specified action.

# kvno adu...@ad.mydomain.com<mailto:adu...@ad.mydomain.com>
kvno: Server not found in Kerberos database while getting credentials for 
adu...@ad.mydomain.com<mailto:adu...@ad.mydomain.com>
This is not expected to work.

# vos listvol myserver
Could not fetch the list of partitions from the server
rxk: ticket contained unknown key version number
Error in vos listvol command.
rxk: ticket contained unknown key version number

19270408 = rxk: ticket contained unknown key version number


It means the OpenAFS servers are not finding the expected key entry.   There is 
not a match for the combination of enctype and key version number and name.

# kinit -kt /opt/openafs/etc/openafs/server/rxkad.keytab 
afs/mydomain....@ad.mydomain.com<mailto:afs/mydomain....@ad.mydomain.com>


The above command is using the 
afs/mydomain....@ad.mydomain.com<mailto:afs/mydomain....@ad.mydomain.com> 
keytab entry to obtain a client Ticket Granting Ticket.    I doubt that is what 
you intended.


Instead you wanted to "kinit" using a client principal and then execute the 
kvno command below.

# kvno afs/mydomain....@ad.mydomain.com<mailto:afs/mydomain....@ad.mydomain.com>
afs/mydomain....@ad.mydomain.com<mailto:afs/mydomain....@ad.mydomain.com>: kvno 
= 5

In addition to the key version number you also need to know the encryption type 
used to encrypt the service private portion of the 
afs/mydomain....@ad.mydomain.com<mailto:afs/mydomain....@ad.mydomain.com> 
service ticket.  It is that encryption type which does not need to match either 
the encryption type used to encrypt the client private portion of the ticket or 
the session key which needs to match the keys added via asetkey.


After adding the keys via "asetkey" did you install KeyFileExt on every server 
in the cell?


Did you restart the services or touch the server instance of the CellServDB 
file to force the new keys to be loaded?



Did I miss something, or make a mistake along the way somewhere?

Ben mentions in a separate reply that the OpenAFS krb.conf file needs to be 
created and specify the local authentication realm as "AD.MYDOMAIN.COM".  
Failure to do so will prevent authorization from succeeding but would not 
result in a key version not found error.


Jeffrey Altman

Reply via email to