[OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad
error=19270407, arghhhh
John W. Sopko Jr.
sopko@cs.unc.edu
Wed, 10 Jan 2007 09:10:48 -0500
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