[OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad
error=19270407, arghhhh
John W. Sopko Jr.
sopko@cs.unc.edu
Wed, 10 Jan 2007 11:51:09 -0500
I think the problem is the afs/cs.unc.edu service key
is the wrong encryption type even thought I checked the
"Use DES encryption type for this account" in the gui.
IT is using DES but with RSA-MD5 as shown in kinit -e.
So I tried to change the principal account
to use only plain DES-CBC-CRC. I try using the ktpass command
shown below to change the password but it does not work.
I still get the old kvno 5 and the encryption type does
not change. Note I have to use the /ptype option else
ktpass complains and will not work:
C:\temp>ktpass -out keytab -princ afs/cs.unc.edu@MSE.UNCCS.TEST -kvno 9
-cryptoDES-CBC-CRC -DesOnly -pass * /ptype KRB5_NT_PRINCIPAL
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.
Key created.
Output keytab to keytab:
Keytab version: 0x502
keysize 56 afs/cs.unc.edu@MSE.UNCCS.TEST ptype 1 (KRB5_NT_PRINCIPAL) vno 9 etype
0x1 (DES-CBC-CRC) keylength 8 (0x92252f9240922516)
[sopko@eagle /]$ kdestroy
[sopko@eagle /]$ kinit
Password for sopko@MSE.UNCCS.TEST:
[sopko@eagle /]$ kvno afs/cs.unc.edu@MSE.UNCCS.TEST
afs/cs.unc.edu@MSE.UNCCS.TEST: kvno = 5
[sopko@eagle /]$ klist -e
Ticket cache: FILE:/tmp/krb5cc_3903_RpApLt
Default principal: sopko@MSE.UNCCS.TEST
Valid starting Expires Service principal
01/10/07 11:49:24 01/10/07 21:49:26 krbtgt/MSE.UNCCS.TEST@MSE.UNCCS.TEST
renew until 01/17/07 11:49:24, Etype (skey, tkt): ArcFour with
HMAC/md5, ArcFour with HMAC/md5
01/10/07 11:49:31 01/10/07 21:49:26 afs/cs.unc.edu@MSE.UNCCS.TEST
renew until 01/17/07 11:49:24, Etype (skey, tkt): DES cbc mode with
CRC-32, DES cbc mode with RSA-MD5
John W. Sopko Jr. wrote:
> [sopko@eagle /]$ klist -e
> Ticket cache: FILE:/tmp/krb5cc_3903_015mRF
> Default principal: sopko@MSE.UNCCS.TEST
>
> Valid starting Expires Service principal
> 01/10/07 09:46:13 01/10/07 19:46:16 krbtgt/MSE.UNCCS.TEST@MSE.UNCCS.TEST
> renew until 01/17/07 09:46:13, Etype (skey, tkt): ArcFour with
> HMAC/md5, ArcFour with HMAC/md5
> 01/10/07 09:46:18 01/10/07 19:46:16 afs/cs.unc.edu@MSE.UNCCS.TEST
> renew until 01/17/07 09:46:13, Etype (skey, tkt): DES cbc mode
> with CRC-32, DES cbc mode with RSA-MD5
>
>
> Kerberos 4 ticket cache: /tmp/tkt3903
> klist: You have no tickets cached
>
> Jeffrey Altman wrote:
>> It is the realm name which is upper-case.
>>
>> What does "klist -e" show for the ticket enc-types?
>>
>>
>>
>> John W. Sopko Jr. wrote:
>>> Yes:
>>>
>>> eagle/root [/usr/afs/etc] # cat /usr/afs/etc/krb.conf
>>> MSE.UNCCS.TEST
>>>
>>> I tried making it lower case, restarting afs and
>>> that did not work either.
>>>
>>>
>>>
>>> Jeffrey Altman wrote:
>>>> cs.unc.edu != mse.unccs.test
>>>>
>>>> Do you have the Kerberos realm specified in the
>>>>
>>>> afs/etc/krb.conf
>>>>
>>>> file?
>>>>
>>>>
>>>>
>>>> John W. Sopko Jr. wrote:
>>>>> Getting close, I can feel it:
>>>>>
>>>>> Verify Windows service account:
>>>>> -------------------------------
>>>>> C:\temp>setspn -L afs
>>>>> Registered ServicePrincipalNames for CN=afs service
>>>>> principal,CN=Users,DC=mse,DC
>>>>> =unccs,DC=test:
>>>>> afs/cs.unc.edu
>>>>>
>>>>> Change the Windows afs domain user password to a known password, this
>>>>> increments the kvno from 4 to 5. This is verified below.
>>>>>
>>>>> Create /usr/afs/etc/KeyFile with kvno 5:
>>>>> ----------------------------------------
>>>>> ktutil: add_entry -password -p afs/cs.unc.edu -k 5 -e des-cbc-crc
>>>>> Password for afs/cs.unc.edu@MSE.UNCCS.TEST:
>>>>> ktutil: wkt keytab.ktutil
>>>>>
>>>>> eagle/root [/usr/afs/etc] # asetkey add 5 keytab.ktutil
>>>>> afs/cs.unc.edu@MSE.UNCCS.TEST
>>>>>
>>>>> eagle/root [/usr/afs/etc] # bos listkeys eagle -localauth
>>>>> key 5 has cksum 509175897
>>>>> Keys last changed on Wed Jan 10 08:53:50 2007.
>>>>> All done.
>>>>>
>>>>> Get afs token and try afs access:
>>>>> ---------------------------------
>>>>> [sopko@eagle /]$ klist
>>>>> klist: No credentials cache found (ticket cache
>>>>> FILE:/tmp/krb5cc_3903_015mRF)
>>>>>
>>>>>
>>>>> Kerberos 4 ticket cache: /tmp/tkt3903
>>>>> klist: You have no tickets cached
>>>>>
>>>>> [sopko@eagle /]$ kinit
>>>>> Password for sopko@MSE.UNCCS.TEST:
>>>>>
>>>>> [sopko@eagle /]$ klist
>>>>> Ticket cache: FILE:/tmp/krb5cc_3903_015mRF
>>>>> Default principal: sopko@MSE.UNCCS.TEST
>>>>>
>>>>> Valid starting Expires Service principal
>>>>> 01/10/07 08:56:02 01/10/07 18:56:06
>>>>> krbtgt/MSE.UNCCS.TEST@MSE.UNCCS.TEST
>>>>> renew until 01/17/07 08:56:02
>>>>>
>>>>>
>>>>> Kerberos 4 ticket cache: /tmp/tkt3903
>>>>> klist: You have no tickets cached
>>>>>
>>>>> [sopko@eagle /]$ kvno afs/cs.unc.edu@MSE.UNCCS.TEST
>>>>> afs/cs.unc.edu@MSE.UNCCS.TEST: kvno = 5
>>>>>
>>>>> [sopko@eagle /]$ klist
>>>>> Ticket cache: FILE:/tmp/krb5cc_3903_015mRF
>>>>> Default principal: sopko@MSE.UNCCS.TEST
>>>>>
>>>>> Valid starting Expires Service principal
>>>>> 01/10/07 08:56:02 01/10/07 18:56:06
>>>>> krbtgt/MSE.UNCCS.TEST@MSE.UNCCS.TEST
>>>>> renew until 01/17/07 08:56:02
>>>>> 01/10/07 08:56:28 01/10/07 18:56:06 afs/cs.unc.edu@MSE.UNCCS.TEST
>>>>> renew until 01/17/07 08:56:02
>>>>>
>>>>>
>>>>> Kerberos 4 ticket cache: /tmp/tkt3903
>>>>> klist: You have no tickets cached
>>>>>
>>>>> [sopko@eagle /]$ aklog -d
>>>>> Authenticating to cell cs.unc.edu (server eagle.cs.unc.edu).
>>>>> We've deduced that we need to authenticate to realm MSE.UNCCS.TEST.
>>>>> Getting tickets: afs/cs.unc.edu@MSE.UNCCS.TEST
>>>>> Using Kerberos V5 ticket natively
>>>>> About to resolve name sopko to id in cell cs.unc.edu.
>>>>> Id 3903
>>>>> Set username to AFS ID 3903
>>>>> Setting tokens. AFS ID 3903 / @ MSE.UNCCS.TEST
>>>>> [sopko@eagle /]$ tokens
>>>>>
>>>>> Tokens held by the Cache Manager:
>>>>>
>>>>> User's (AFS ID 3903) tokens for afs@cs.unc.edu [Expires Jan 10 18:56]
>>>>> --End of list--
>>>>>
>>>>> [sopko@eagle /]$ ls /afs/cs.unc.edu/home
>>>>> ls: /afs/cs.unc.edu/home: Permission denied
>>>>>
>>>>> Jan 10 08:56:39 eagle kernel: afs: Tokens for user of AFS id 3903 for
>>>>> cell cs.unc.edu are discarded (rxkad error=19270407)
>>>>>
>>>>> eagle/root [/usr/afs/etc] # translate_et 19270407
>>>>> 19270407 (rxk).7 = security object was passed a bad ticket
>>>>>
>>>>>
>>>>> Jeffrey Altman wrote:
>>>>>> Even assuming you wanted to kinit to your service principal
>>>>>> you would have to so with the correct principal name
>>>>>>
>>>>>> afs/cs.unc.edu@CSX.UNC.EDU != afs/cs.unc.edu@MSE.UNCCS.TEST
>>>>>>
>>>>>> Your default realm name is CSX.UNC.EDU, not MSE.UNCCS.TEST.
>>>>>>
>>>>>> However, you don't want to be able to kinit to that service
>>>>>> principal. What you want is to be able to obtain a service
>>>>>> ticket for it using a client principal
>>>>>>
>>>>>> kvno afs/cs.unc.edu@MSE.UNCCS.TEST
>>>>>>
>>>>>> obtains a service ticket for the specified principal name.
>>>>>> Assuming the kvno is still 4 after you set the service principal
>>>>>> name. You should try to authenticate to your AFS servers again.
>>>>>>
>>>>>>
>>>>>> John W. Sopko Jr. wrote:
>>>>>>> Jeffrey Altman wrote:
>>>>>>>> afs@MSE.UNCCS.TEST != afs/cs.unc.edu@MSE.UNCCS.TEST
>>>>>>>>
>>>>>>>> choose one and stick with it.
>>>>>>> I am confused with Windows principals:
>>>>>>>
>>>>>>> [sopko@eagle /]$ kinit afs/cs.unc.edu@MSE.UNCCS.TEST
>>>>>>> kinit(v5): Client not found in Kerberos database while getting
>>>>>>> initial
>>>>>>> credentials
>>>>>>>
>>>>>>> That is why I did:
>>>>>>>
>>>>>>> [sopko@eagle /]$ kinit afs
>>>>>>> Password for afs@MSE.UNCCS.TEST:
>>>>>>>
>>>>>>> So I have a Windows "afs" user account that I ran:
>>>>>>>
>>>>>>> setspn -A afs/cs.unc.edu afs
>>>>>>>
>>>>>>> To Add/Associate a service principal to the Windows login
>>>>>>> name.
>>>>>>>
>>>>>>> But I cannot kinit to afs/cs.unc.edu like I can
>>>>>>> under MIT KRB5, (my CSX.UNC.EDU linux server):
>>>>>>>
>>>>>>>
>>>>>>> |sopko@lark:19% kinit afs/cs.unc.edu
>>>>>>> Password for afs/cs.unc.edu@CSX.UNC.EDU:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> John W. Sopko Jr. wrote:
>>>>>>>>> Jeffrey Altman wrote:
>>>>>>>>>> John W. Sopko Jr. wrote:
>>>>>>>>>>
>>>>>>>>>>> In C:\Program Files\Support Tools\ktpass
>>>>>>>>>>> right click properties "version tab" shows 5.2.3790.1830
>>>>>>>>>>>
>>>>>>>>>>> So use ktutil on the linux openafs server, setting the
>>>>>>>>>>> password the same as the afs users Windows password:
>>>>>>>>>>>
>>>>>>>>>>> eagle/root [/usr/afs/etc] # ktutil
>>>>>>>>>>> ktutil: add_entry -password -p afs/cs.unc.edu@MSE.UNCCS.TEST -k
>>>>>>>>>>> 1 -e
>>>>>>>>>>> des-cbc-crc
>>>>>>>>>> Where did you get the key version number of 1 from?
>>>>>>>>> When I ran the "bad" ktpass command on windows it always generates
>>>>>>>>> kvno 1
>>>>>>>>> by default. The ktpass /? (help) says:
>>>>>>>>>
>>>>>>>>> kvno : Override Key Version Number
>>>>>>>>> Default: query DC for kvno. Use /kvno 1 for Win2K compat.
>>>>>>>>>
>>>>>>>>> Since this Windows 2003 server is running in 2000 mixed mode I
>>>>>>>>> thought
>>>>>>>>> it forced/kept the kvno at 1 for w2k compatability. Below is the
>>>>>>>>> output of
>>>>>>>>> the ktpass, no matter how many times I run it it keeps the "vno"
>>>>>>>>> at 1. I check the keytab.mse file with ktutil and it is at 1.
>>>>>>>>>
>>>>>>>>> But you are right I do not know what is in the server. I did not
>>>>>>>>> think hard enough about this.
>>>>>>>>>
>>>>>>>>>> The key version number must match the number that is actually
>>>>>>>>>> issued by the KDC. You can identify the version number using
>>>>>>>>>> the MIT Kerberos utility
>>>>>>>>>>
>>>>>>>>>> kvno <principal>
>>>>>>>>> I tried this to get the kvno:
>>>>>>>>>
>>>>>>>>> eagle/root [/usr/afs/etc] # kinit afs
>>>>>>>>> Password for afs@MSE.UNCCS.TEST:
>>>>>>>>> eagle/root [/usr/afs/etc] # kvno afs
>>>>>>>>> afs@MSE.UNCCS.TEST: kvno = 4
>>>>>>>>>
>>>>>>>>> I then ran:
>>>>>>>>>
>>>>>>>>> ktutil> add_entry -password -p afs/cs.unc.edu@MSE.UNCCS.TEST -k
>>>>>>>>> 4 -e
>>>>>>>>> des-cbc-crc
>>>>>>>>> ktutil> write_kt keytab.ktutil_generated
>>>>>>>>>
>>>>>>>>> /usr/sbin/asetkey add 4 keytab.ktutil_generated afs/cs.unc.edu
>>>>>>>>>
>>>>>>>>> /etc/init.d/openafs-server restart
>>>>>>>>>
>>>>>>>>> I now get the same error as Eric had:
>>>>>>>>>
>>>>>>>>> Jan 9 17:14:27 eagle kernel: afs: Tokens for user of AFS id 3903
>>>>>>>>> for
>>>>>>>>> cell cs.unc.edu are discarded (rxkad error=19270407)
>>>>>>>>>
>>>>>>>>> Do I need to map an account like Eric did with the "mapuser"
>>>>>>>>> option
>>>>>>>>> to ktpass?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> The key version number must match the number that is actually
>>>>>>>>>> issued by the KDC. You can identify the version number using
>>>>>>>>>> the MIT Kerberos utility
>>>>>>>>>>
>>>>>>>>>> kvno <principal>
>>>>>>>>>>
>>>>>>>>>>> cell cs.unc.edu are discarded (rxkad error=19270408)
>>>>>>>>>> The OpenAFS translate_et <error_code> command will tell you this
>>>>>>>>>> is because
>>>>>>>>>>
>>>>>>>>>> 19270408 = ticket contained unknown key version number
>>>>>>>>>>
>>>>>>>>>>> Windows Event Viewer, System log shows this, sometimes:
>>>>>>>>>>>
>>>>>>>>>>> While processing a TGS request for the target server
>>>>>>>>>>> afs/cs.unc.edu, the
>>>>>>>>>>> account sopko@MSE.UNCCS.TEST did not have a suitable key for
>>>>>>>>>>> generating
>>>>>>>>>>> a Kerberos ticket (the missing key has an ID of 8). The
>>>>>>>>>>> requested
>>>>>>>>>>> etypes
>>>>>>>>>>> were 2. The accounts available etypes were 3 1.
>>>>>>>>>> What in the world is requesting a ticket with DES-CBC-MD4 ?
>>>>>>>>>>
>>>>>>>>>>> AM I CRAZY?
>>>>>>>>>>> -----------
>>>>>>>>>>>
>>>>>>>>>>> Once I get Windows AD working can I run both our current
>>>>>>>>>>> kaserver
>>>>>>>>>>> and
>>>>>>>>>>> Windows AD authentication against our production cs.unc.edu
>>>>>>>>>>> openafs
>>>>>>>>>>> cell
>>>>>>>>>>> at the same time? If I can generate afs/cs.unc.edu service
>>>>>>>>>>> pincipals
>>>>>>>>>>> with the same password on the kaserver and the AD server will
>>>>>>>>>>> this
>>>>>>>>>>> work?
>>>>>>>>>>>
>>>>>>>>>>> This may be a good migration path for us. We currently have 2
>>>>>>>>>>> password
>>>>>>>>>>> databases, kaserver and Windows AD. When we create accounts we
>>>>>>>>>>> use the
>>>>>>>>>>> same user login name for both wndows and linux. Most users keep
>>>>>>>>>>> their
>>>>>>>>>>> passwords the same so logging into Windows gives them an afs
>>>>>>>>>>> token.
>>>>>>>>>>> Even if they don't we just tell them to use their Windows
>>>>>>>>>>> password
>>>>>>>>>>> as we migrate machine configurations.
>>>>>>>>>>>
>>>>>>>>>>> This way we can migrate machines to authenticate to "Windows AD
>>>>>>>>>>> only"
>>>>>>>>>>> over a short period of time and start testing real live systems.
>>>>>>>>>>>
>>>>>>>>>>> First I have to get Windows AD afs service pricnipal working.
>>>>>>>>>> AFS only stores DES keys by key version number. Ensure that your
>>>>>>>>>> kaserver key and your AD key have different version numbers and
>>>>>>>>>> you will be just fine.
>>>>>>>>>>
>>>>>>>>>> Jeffrey Altman
>>>>
>>
>
--
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