From 98c66a23922526b9c070f89dd66bf034d2d04e18 Mon Sep 17 00:00:00 2001 From: John Sopko Date: Tue, 24 Jul 2007 13:58:18 +0000 Subject: [PATCH] none --- AFSLore/WindowsK5AfsServicePrincipal.mdwn | 110 ++++++++++++++++++++---------- 1 file changed, 74 insertions(+), 36 deletions(-) diff --git a/AFSLore/WindowsK5AfsServicePrincipal.mdwn b/AFSLore/WindowsK5AfsServicePrincipal.mdwn index 2db5819..fab08d1 100644 --- a/AFSLore/WindowsK5AfsServicePrincipal.mdwn +++ b/AFSLore/WindowsK5AfsServicePrincipal.mdwn @@ -1,4 +1,4 @@ -Here are the instructions I used for creating a working afs/cell.name service principal on Windows 2003 SP2 AD/Kerberos server. +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: @@ -8,25 +8,37 @@ The instructions below were tested with the ktpass command that comes with SP2. 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. +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 then use the windows "ktpass" command to generate a Kerberos style keytab that is then imported into the afs [[KeyFile]] on the afs servers located in the /usr/afs/etc/KeyFile file. +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) +#### 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 is CSW.UNC.EDU in this example. +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: + In the Account tab: -X = checked \_ = not checked + 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 + _ 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 = servicePrincipalName = + sAMAccountName = afscs + userPrincipalName = afscs@csw.unc.edu + servicePrincipalName = 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. @@ -38,35 +50,57 @@ ktpass - Key tab password. This command has many options, use "ktpass /?" to see 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) +#### 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 -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 +DumpSalt option is for informational purposes and shows the salt that is appended to the password. +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 -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 -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. + 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 = servicePrincipalName = afs/csw.unc.edu + sAMAccountName = afscs + userPrincipalName = afscs@csw.unc.edu + servicePrincipalName = afs/csw.unc.edu -Step 3) +#### 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 : + % 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 + % 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. @@ -80,25 +114,31 @@ You use the "asetkey" utility command that comes with [[OpenAFS]] to read the ke 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 - ----- - ----- + # 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 -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 + 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. + # 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. After you import the key into the [[KeyFile]] you need to restart the AFS db servers which will read the new key. You need to 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. @@ -114,16 +154,14 @@ 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 to K5 Tip - ----- +#### 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, MIT or probably Heimdal server. I have tested on MIT and Windows 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 user principal in the [[KeyFile]]. If you add the K5 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 use "klog" or Windows machines not configured to get tokens from a K5 server to get tokens via either the kaserver or the kinit/aklog method ,(or KFW pam etc.), to get K5 tickets from the k5 server and get an afs token. +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. -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 password, one kaserver and one K5 server and not confusing the users. +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 -- 1.9.4