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