Here are the instructions I used for creating a working afs/cell.name service principal on Windows 2003 SP2 Active Directory Kerberos 5 server.

These instructions require the Windows "ktpass.exe" command that comes with Windows Server 2003 support tools. There is a problem with the ktpass command that comes with SP1 support tools, see the following:

http://support.microsoft.com/kb/919557

The instructions below were tested with the ktpass command that comes with SP2. Production environments should be running SP2. I originally configured with SP1 and the ktpass fix mentioned above. Microsoft may not be giving out the ktpass fix anymore and tell you to upgrade to SP2. A few options have changed in the SP2 ktpass command and I would recommend using this one.

I originally got a working afs cell in Windows 2003 SP1 using the SP1 patch for ktpass. We since upgraded to SP2. Things continued to run fine, that is the SP2 patch did not break anything. I then configured again using the ktpass command that comes with SP2 as shown below.

Windows does not have service principals like MIT Kerberos. You create a regular Windows domain account, (User Principal Name or UPN), and turn the account into an afs/your.cell service principal using the ktpass utility. Once the service principal is created it then acts like a regular kerberos 5 service principal.

You use the windows "ktpass" command to create the serivce principal and generate a Kerberos style keytab. You then import the keytab into the afs KeyFile on the afs servers located in the /usr/afs/etc/KeyFile file using the OpenAFS supplied asetkey utility command.

Step 1) Create a Windows account

First create a new UPN account name using Active Directory Users and Computers. You can use any valid Windows UPN name. The commands below use the account name "afscs". Note the afs cell name is csw.unc.edu and the Windows AD REALM "CSW.UNC.EDU" in this example.

Once the account is created edit the properties for the user.

In the Account tab:

X = checked
_ = not checked

_   User must change password at next logon
_   User cannot change password
X   Password never expires
_   Store password using reversible encryption
_   Acount is disabled
_   Smart card is required for interactive logon
_   Account is trusted for delegation
_   Account is sensitive and cnnot be delegated
X   Use DES encryption types for this account
_   Do not require Kerberos preauthentication

After creating the "afscs" account you can use the Active Directory ADSI, (Active Directory Service Interface tool) Edit snapin tool from the mmc editor to look at the values for the account name if you are interested in watching what happens:

sAMAccountName = afscs
userPrincipalName = afscs@csw.unc.edu
servicePrincipalName = <Not Set>

Note the userPrincipalName value has a lower case realm/AD domain. This is standard for Windows. The sAMAccountName is used for pre-windows 2000 clients that do not use Kerberos. Note the servicePrincipalName is not set yet. This is done below with the Windows ktpass command.

There are 2 commands for dealing with service principals in Windows 2003. They are not documented very well.

setspn - set service principal for a user account. This command will add service/hostname type service principals to the "servicePrincipalName" directory entry.

ktpass - Key tab password. This command has many options, use "ktpass /?" to see them. Its primary purpose is to export a Kerberos complient keytab file for service principals to use. Like the afs/cell.name service principal.

This procedure does not use the setspn command. I could not find any good info on how to use this command and it was not necessary to get the afs/cell.name service principal to work.

Step 2) Run the Windows ktpass command utility

Run the ktpass command to map the UPN name to the afs/cell.name service principal.

ktpass -princ afs/csw.unc.edu@CSW.UNC.EDU -mapuser afscs@CSW.UNC.EDU -mapOp add -out keytab.afs +rndPass -crypto DES-CBC-CRC +DesOnly -ptype KRB5_NT_PRINCIPAL +DumpSalt

The ktpass command maps the -mapuser UPN you created in step 1 to the afs principal name, -princ afs/your.cell@REALM. A random password is assigned to the account using DES encryption. The +DesOnly option sets the "Use DES encryption types for this account" if it was not done so in the Account tab in step 1. The -out options specifies the file to place the kerberos principal keytab information in that you will use to import into the OpenAFS KeyFile on your afs servers. I do not know what the -ptype is for but the one that is shown will not produce and error and is the recommended type. The -mapOp add option is the default if not specified but I could not find any info on what option is for. The +DumpSalt option is for informational purposes and shows the salt that is appended to the password.

Here is the output from the ktpass command:

ktpass -princ afs/csw.unc.edu@CSW.UNC.EDU -mapuser afscs@CSW.UNC.EDU -mapOp
add -out keytab.afs +rndPass -crypto DES-CBC-CRC +DesOnly -ptype
KRB5_NT_SRV_INST +DumpSalt


C:\Documents and Settings\Administrator>ktpass -princ
afs/csw.unc.edu@CSW.UNC.ED
U -mapuser afscs@CSW.UNC.EDU -mapOp add -out keytab.afs +rndPass -crypto
DES
-CBC-CRC +DesOnly -ptype KRB5_NT_PRINCIPAL +DumpSalt
Targeting domain controller: eleanor.csw.unc.edu
Using legacy password setting method
Successfully mapped afs/csw.unc.edu to afscs.
Building salt with principalname afs/csw.unc.edu and domain CSW.UNC.EDU...
Hashing password with salt "CSW.UNC.EDUafscsw.unc.edu".
Key created.
Output keytab to keytab.afs:
Keytab version: 0x502
keysize 54 afs/csw.unc.edu@CSW.UNC.EDU ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype
0
x1 (DES-CBC-CRC) keylength 8 (0xcdecc7381adf6407)
Account afscs has been set for DES-only encryption.

Using ADSI edit shows the servicePrincipalName got updated:

sAMAccountName = afscs
userPrincipalName = afscs@csw.unc.edu
servicePrincipalName = afs/csw.unc.edu

Step 3) Copy and import the Windows generated keytab

The next step is to copy the keytab.afs file that was generated and import into the afs KeyFile. Note the "vno 3 etype" output. This is the kerberos key version number. You can verify the key number using the kerberos kvno command to your windows AD REALM. Use the linux/unix kvno command or the kvno command on Windows that comes with KFW (Kerberos For Windows). You will need the kvno when importing the keytab.afs to your afs KeyFile. This is an optional step for verifying the kvno set in Windows Active Directory:

First you need to get a regular ticket granting ticket from your Windows REALM:

% kinit
Password for sopko@CSW.UNC.EDU: 

Then query for the afs service principal:

% kvno afs/csw.unc.edu@CSW.UNC.EDU   
afs/csw.unc.edu@CSW.UNC.EDU: kvno = 3

Next you import the keytab.afs to your /usr/afs/etc/KeyFile. You should securely copy the keytab.afs file that was created on your Windows server using the ktpass command over to your afs server that runs the afs upsever for distributing files. If you do not have an upserver then you will have to generate one KeyFile and copy as you normally would.

If this is NOT a new installation make sure the existing key numbers in your KeyFile is different from the one that was generated with ktpass. If you have one or more keys in your KeyFile make sure they are different! Each time you run the Windows ktpass command it will increment the key. Do NOT use the ktpass -kvno option for configuring a key version number. It only seems to set the key number in the output keytab file not Active Directory, this will break things! It is simple to use the dos window and re-run the ktpass command until you get a key number you are happy with.

You can use the "asetkey list" command to list the keys that are currently in the KeyFile. Or you can run the "bos listkeys" command to get this information. You can run the ktpass command until the key number that is generated is different then the one currently in the KeyFile.

You use the "asetkey" utility command that comes with OpenAFS to read the ketyab.afs file and import into the KeyFile. You specify the key version number when doing this:

/usr/sbin/asetkey add 3 keytab.afs afs/csw.unc.edu@CSW.UNC.EDU

You must specify the proper key number! You can use the kerberos ktutil command to read the keytab.afs file to verify the kvno. You can also use the keytab.afs keytab to obtain a K5 tgt as the user who is acting as the service principal. This can help you debug any issues. For example:

# ktutil
ktutil:  read_kt keytab.afs
ktutil:  list
slot KVNO Principal
---- ----
---------------------------------------------------------------------
   1   3              afs/csw.unc.edu@CSW.UNC.EDU


# kinit -kt keytab.afs afs/csw.unc.edu
afsk5/root [/usr/afs/etc] # klist
Ticket cache: FILE:/tmp/krb5cc_3903_GAwMFc
Default principal: afs/csw.unc.edu@CSW.UNC.EDU

Valid starting     Expires            Service principal
07/23/07 13:46:34  07/23/07 23:46:34  krbtgt/CSW.UNC.EDU@CSW.UNC.EDU
        renew until 07/30/07 13:46:34

If the kinit command fails then the keytab does not work with the service principal user you created with ktpass and you will have to try again.

You can use the "bos listkey" command to read the key you just imported into the KeyFile with asetkey. The ktutil takes a kerberos style keytab and the bos listkey takes an afs style KeyFile:

# bos listkeys afsk5.csw.unc.edu -localauth
key 3 has cksum 999999999
Keys last changed on Mon Jul 23 15:13:04 2007.
All done.

Step 4) Configure REALM name and restart AFS db servers

After you import the key into the KeyFile you need to restart the AFS db servers which will read the new key. You should put the name of the Windows AD Kerberos REALM you are using in the /usr/afs/etc/krb.conf file. I believe the realm will default to your DNS domain if you do not do this. So if your REALM name is different then your DNS domain you must put the REALM name in the krb.conf file. I would enter the REALM to be safe.

Also be aware that you can specify a K5 REALM name option to the afs fileserver daemon as an option in your /usr/afs/local/Bosconfig file! I believe if you specify a "-realm REALM" option to your afs fileserver command it will override the one in the krb.conf file and the dns name. I would recommend putting the REALM in /usr/afs/etc/krb.conf file to lessen the confusion. Make sure you get the REALM settings correct!

From the OpenAFS Administrators manual section Managing Server Encryption Keys:

Issue the bos restart command to restart the database server processes on all database server machines. This forces them to start using the key in the KeyFile file that currently has the highest key version number.

Repeat this command in quick succession for each database server machine, starting with the machine that has the lowest IP address.

bos restart buserver ptserver vlserver

The "Managing Server Encryption Keys" in the OpenAFS Administrator documentation explains how to delete your old keys if you wish. You can use the "bos removekey" or "asetkey delete" command to remove old key version numbers from the KeyFile after your maximum token lifetime for users has passed.

Migrating kaserver clients to use K5

I have found that I can run the kaserver and a K5 authentication server in parallel. It does not matter if it is a Windows or MIT K5 server.

If you are currently running a kaserver to do authentication then you have an afs KeyFile with your kaserver afs service principal in the KeyFile. If you add the K5 afs/cell.name service pricipal with the asetkey command to the KeyFile just make sure the key version numbers are different. Leave the kaserver afs principal key in the KeyFile!

If your pts protection server user names in afs and the users names you create in Windows or Mit kerberos are the same, you can continue to use "klog" style authentication from OpenAFS clients not yet configured to get tokens from the K5 server.

The reason one would do this is during the transition to K5. Once you have your K5 servers and your KeyFile configured to contain the old afs kaserver principal and the new K5 service principal you can continue to run the kaserver until your afs clients are configured to use K5 only and wean yourself off the kaserver. The downside of this is having 2 passwords, one in the kaserver and one in the K5 server and not confusing the users.

-- JohnSopko - 24 Jul 2007