[OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad error=19270407, arghhhh

[Jeffrey Altman]

afs@MSE.UNCCS.TEST != afs/cs.unc.edu@MSE.UNCCS.TEST

choose one and stick with it.



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
>