[OpenAFS] Windows 2003 afs service keys info
John W. Sopko Jr.
sopko@cs.unc.edu
Tue, 23 Jan 2007 14:45:42 -0500
Here are the results I found for creating a working afs/cell.name service
principal on Windows 2003 SP1 AD/Kerberos server.
I Used the latest Windows ktpass version 5.2.3790.2732 mentioned in:
http://support.microsoft.com/kb/919557
The version that comes with SP1 is broke. SP2 is supposed to have the
fixed version.
Windows does not have service principals like MIT Kerberos. You create
a regular Windows domain account and turn the account into a service
principal.
I re-created a new Windows Account for each test case below. To keep
things simple I used a lower case alpha account name "afscs". You can
use any valid Windows Account name to map the afs/cell.name service
principal to. Set these account options:
X = checked
_ = not checked
_ User must change password at next logon
_ User cannot change password
X Password never expires
_ Store password using reversible encrytpion
_ Acount is disabled
_ Smart card is required for interactive logon
X 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 I used Active Directory ADSI Edit
snapin to look at the values for the account name:
sAMAccountName = afscs
userPrincipalName = afscs@mse.unccs.test
servicePrincipalName = <Not Set>
Note the userPricipalName 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.
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.
CASE1:
------
No setpn command used, used setpass -mapuser, -mapOp add options. The
default is supposed to be -mapOP add:
ktpass -princ afs/cs.unc.edu@MSE.UNCCS.TEST -mapuser afscs@MSE.UNCCS.TEST
-mapOp add -out keytab.afs +rndPass -crypto DES-CBC-CRC +DesOnly -ptype
KRB5_NT_PRINCIPAL +DumpSalt
C:\temp>ktpass -princ afs/cs.unc.edu@MSE.UNCCS.TEST -mapuser afscs@MSE.UNCCS.TES
T -mapOp add -out keytab.afs +rndPass -crypto DES-CBC-CRC +DesOnly -ptype KRB5_N
T_PRINCIPAL +DumpSalt
Targeting domain controller: madison-cs.mse.unccs.test
Successfully mapped afs/cs.unc.edu to afscs.
Password succesfully set!
Building salt with principalname afs/cs.unc.edu and domain MSE.UNCCS.TEST...
Hashing password with salt "MSE.UNCCS.TESTafscs.unc.edu".
Key created.
Output keytab to keytab.afs:
Keytab version: 0x502
keysize 56 afs/cs.unc.edu@MSE.UNCCS.TEST ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype
0x1 (DES-CBC-CRC) keylength 8 (0x8ae049576b2c585b)
Account afscs has been set for DES-only encryption.
ADSI Edit shows values changed to:
sAMAccountName = afscs
userPrincipalName = afs/cs.unc.edu@MSE.UNCCS.TEST
servicePrincipalName = afs/cs.unc.edu
Note the userPrincipalName changes to the service principal name.
The servicePrincipalName got updated with the service name just like
"setspn -A" does. The domain got changed to uppercase. The "+DesOnly"
option will enable the "Use DES encryption types for this account"
in the account settings if not already enabled.
From a linux client you can "kinit -kt keytab.afs afs/cs.unc.edu" and
get a krbtgt for the principal afs/cs.unc.edu because the user principal
name now exists.
Ktpass changes the password and increments the kvno in the UPN AD entry
and puts the proper matching kvno in the keytab.afs file.
asetkey works fine:
/usr/sbin/asetkey add 3 keytab.afs afs/cs.unc.edu@MSE.UNCCS.TEST
Restart openafs servers. Use "kinit" to get your user tgt, then run
"aklog" to get an openafs token, CASE1 worked fine.
CASE2:
------
No setpn command used, use -mapuser, mapOp set options to ktpass.
Trying to figure out what the "mapOp" option is for and the difference
between mapOp add|set are. Could not find any info on this option.
Deleted/re-created afscs account.
ktpass -princ afs/cs.unc.edu@MSE.UNCCS.TEST -mapuser afscs@MSE.UNCCS.TEST
-mapOp set -out keytab.afs +rndPass -crypto DES-CBC-CRC +DesOnly -ptype
KRB5_NT_PRINCIPAL +DumpSalt
C:\temp>ktpass -princ afs/cs.unc.edu@MSE.UNCCS.TEST -mapuser afscs@MSE.UNCCS.TES
T mapOp set -out keytab.afs +rndPass -crypto DES-CBC-CRC +DesOnly -ptype KRB5_NT
_SRV_INST +DumpSalt
Targeting domain controller: madison-cs.mse.unccs.test
Successfully mapped afs/cs.unc.edu to afscs.
Password succesfully set!
Building salt with principalname afs/cs.unc.edu and domain MSE.UNCCS.TEST...
Hashing password with salt "MSE.UNCCS.TESTafscs.unc.edu".
Key created.
Output keytab to keytab.afs:
Keytab version: 0x502
keysize 56 afs/cs.unc.edu@MSE.UNCCS.TEST ptype 2 (KRB5_NT_SRV_INST) vno 3 etype
0x1 (DES-CBC-CRC) keylength 8 (0xe925202fe0dc0b8c)
Account afscs has been set for DES-only encryption.
ADSI Edit shows values changed to:
sAMAccountName = afscs
userPrincipalName = afs/cs.unc.edu@MSE.UNCCS.TEST
servicePrincipalName = afs/cs.unc.edu
This works just like CASE1, no problems. Can not figure out difference
between mapOp set|add options.
CASE3:
------
Use setspn command and no -mapuser option to ktpass.
Deleted/re-created afscs account, run:
setspn -A afs/cs.unc.edu afscs
ADSI Edit values changed to:
sAMAccountName = afscs
userPrincipalName = afscs@mse.unccs.test
servicePrincipalName = afs/cs.unc.edu
Note userPrincipalName does not change, servicePrincipalName is updated
with service name.
Must use -ptype option else ktpass will not create the keytab.afs file:
ktpass -princ afs/cs.unc.edu@MSE.UNCCS.TEST -out keytab.afs +rndPass -crypto
DES-CBC-CRC +DesOnly -ptype KRB5_NT_PRINCIPAL +DumpSalt
C:\temp>ktpass -princ afs/cs.unc.edu@MSE.UNCCS.TEST -out keytab.afs -kvno 3
-pass * -crypto DES-CBC-CRC +DesOnly -ptype KRB5_NT_PRINCIPAL +DumpSalt
NOTE: creating a keytab but not mapping principal to any user.
For the account to work within a Windows domain, the
principal must be mapped to an account, either at the
domain level (with /mapuser) or locally (using ksetup)
If you intend to map afs/cs.unc.edu@MSE.UNCCS.TEST to an account through
o
ther means
or don't need to map the user, this message can safely be ignored.
Type the password for afs/cs.unc.edu:
Type the password again to confirm:
WARNING: pType and account type do not match. This might cause problems.
Building salt with principalname afs/cs.unc.edu and domain MSE.UNCCS.TEST...
Hashing password with salt "MSE.UNCCS.TESTafscs.unc.edu".
Key created.
Output keytab to keytab.afs:
Keytab version: 0x502
keysize 56 afs/cs.unc.edu@MSE.UNCCS.TEST ptype 1 (KRB5_NT_PRINCIPAL) vno 3
etype
0x1 (DES-CBC-CRC) keylength 8 (0x92252f9240922516)
ADSI Edit values do not change:
sAMAccountName = afscs
userPrincipalName = afscs@mse.unccs.test
servicePrincipalName = afs/cs.unc.edu
Note the ktpass does NOT set the password like in CASE1 and 2.
So you have to specify -pass * option and enter the password
the same as the user account.
If you do not specify the -kvno option to ktpass the key number exported
to the keytab.afs will always be kvno=1. The kvno for the user shown
in ADSI Edit shows 2 immediately after the account is created and the
password set. I then changed the account setting to use DES only password
encryption and reset the password. The kvno then gets incremented to 3. I
then specified -kvno 3 to ktpass.
This is similar to what you have to do if running the kaserver; run
"bos addkey" to the /usr/afs/etc/KeyFile then change the password "kas
setpassword afs" of the afs service principal. You need to look up the
kvno using ADSI Edit and run ktpass specifying the -kvno to be sure of
the kvno and specify this to ktpass.
You can NOT "kinit -kt keytab.afs afs/cs.unc.edu" and get a krbtgt
for the principal afs/cs.unc.edu because the user principal does
not exists, only the service principal. So you cannot kinit and do a
packet trace for the salt. You can kinit to your own account then use
"kvno afs/cs.unc.edu@MSE.UNCCS.TEST" to see the knvo. Then use "aklog"
to get openafs tokens.
I can then run asetkey fine, "bos listkey" and "kvno
afs/cs.unc.edu@MSE.UNCCS.TEST" show the kvno are the same. Running "kvno
afs/cs.unc.edu@MSE.UNCCS.TEST" shows the ticket numbers are the same.
I restart openafs servers. You can kinit and aklog and get a token but it
does NOT work, get famous rxkad error=19270407 error! I cannot see the
salt since "kvno afs/cs.unc.edu@MSE.UNCCS.TEST" does not show it in the
packet trace, and you cannot "kinit afs/cs.unc.edu@MSE.UNCCS.TEST". It
must be that the salt in the keytab and the salt for the service principal
are different but I cannot prove it.
Conclusion:
-----------
I would recommend using CASE1, it is similar to creating a MIT K5 service
principal and doing a "kadmin> ktadd" command to export the keytab for
the service principal. CASE1 is straight forward as long as Microsoft
does not break it in the future.
When you use the -mapuser option to ktpass, Windows AD changes the
"userPrincipalName" to a service principal name with a "/" in it
like MIT Kerberos service principals. It updates the password and
incrments the kvno and sets the proper password and kvno in the
keytab. The Active Directory User Principal Name gets changed to the
afs/cell.name@REALM. But, it only allows you to map one service name.
That is the "userPrincipalName" AD entery can only contain one user.
The "setspn" command will allow you to add service principals to a
Windows User Principal Name, (login name), in the "servicePrincipalName"
AD directory entry. You can also add multiple services using "setpn
-A". they are separated by a ";". But exporting the keytab for the
service without using the -mapuser option to ktpass is confusing. The
afs service principal does not work with the keytab that is generated
with ktpass. Probably do to a salt mismatch.
I searched microsoft.com for many hours and could not find any useful
information on the relationship between the the various AD fields, setspn,
ktpass and keytabs and passwords. There are a couple of crappy examples
and there is no more explanation about what the options are doing other
then doing a "ktpass /?" help output. Without more information I would
only be speculating on how Microsoft intends one to use the "setspn"
command. Having multiple service principles attached to a single account
name is confusing.
If someone has Microsoft Support and is going to use Windows AD for
linux/unix service tickets maybe they can put in a call and ask for more
information on this subject.
--
John W. Sopko Jr. University of North Carolina
email: sopko AT cs.unc.edu Computer Science Dept., CB 3175
Phone: 919-962-1844 Sitterson Hall; Room 044
Fax: 919-962-1799 Chapel Hill, NC 27599-3175