[OpenAFS] Active Directory 2003, kerberos 5, openAFS - rxkad
error=19270407, arghhhh
John W. Sopko Jr.
sopko@cs.unc.edu
Thu, 11 Jan 2007 10:39:12 -0500
I tried and it did not work, am I missing something?
My linux server is a test server, I can do anything on it:
Verify kvno of service principal:
[sopko@eagle /]$ kvno afs/cs.unc.edu@MSE.UNCCS.TEST
afs/cs.unc.edu@MSE.UNCCS.TEST: kvno = 2
I have admin rights on the AD, it also is a test
server. I loaded the Active Directory ADSI Edit snapin
and examined the Domain user AFS.CS.UNC.EDU everything
looks in order, I think:
sAMAccountName AFS.CS.UNC.EDU
servicePrincipalName afs/cs.unc.edu
msDS-KeyVersionNumber 2
userPrincipalName afs/cs.unc.edu@MSE.UNCCS.TEST
I then did this on the linux/afs server:
eagle/root [/usr/afs/etc] # /bin/rm KeyFile
eagle/root [/usr/afs/etc] # ../bin/bos_util adddes 2
input key:
Retype input key:
eagle/root [/usr/afs/etc] # /etc/init.d/openafs-server restart
Stopping openafs-server: [ OK ]
Starting openafs-server:
Using an input key of:
win_passwordMSE.UNCCS.TESTAFS.CS.UNC.EDU
win_password = password set for Domain user AFS.CS.UNC.EDU
Douglas E. Engert wrote:
>
>
> John W. Sopko Jr. wrote:
>
>>
>> I really did not think it would be this complex to
>> generate a Windows service principal and corresponding
>> /usr/afs/etc/KeyFile.
>
> No it should not be, but then again Microsoft did some
> things early on that did not follow the Kerberos
> conversions, including not using kvnos. We are living with
> thuse early decisions.
>
>> think the best route is to
>> try windows ktpass again. The thing I do not understand
>> is; you create a Windows domain account and then use
>> setspn to add the afs/cs.unc.edu service principal.
>> (Or I found the service principal gets added if you
>> use the "-mapuser" option to ktpass). Then if I use
>> ktpass to set the password, kvno and generate a
>> keytab, neither the password or the kvno change for
>> afs/cs.unc.edu service principal. I thought ktpass was
>> supposed to do what MIT "kadmin ktadd" does, change the
>> principals password and dump the key to a keytab so
>> they matched. Maybe this is the problem with the "bad"
>> ktpass version.
>
> You have to have admin privilages in AD to change the
> enties, although a user can change thier own password,
> but I don't thin ktpass is doing that.
>
>>
>> At this point I am confused with ktpass, I read the microsoft docs:
>>
>> http://technet2.microsoft.com/WindowsServer/en/library/a412a943-4567-4674-9015-fe1b7bf0228c1033.mspx?mfr=true
>>
>
> The only comment on this is the statememt:
>
> "You cannot map multiple service instances to the same user account."
>
> You can have multiple SPNs, but ktpass appearently can not handle it.
>
>>
>> For example I re-created my domain account as AFS.CS.UNC.EDU
>> and the ran ktpass like this:
>>
>> ktpass -out keytab -princ afs/cs.unc.edu@MSE.UNCCS.TEST -kvno 7
>> -crypto DES-CBC-CRC -DesOnly -pass * -mapuser AFS.CS.UNC.EDU
>>
>> the -mapuser option adds the afs/cs.unc.edu service to the user account.
>> You can verify this with setspn -L AFS.CS.UNC.EDU, I did not
>> need to run the Windows "setspn -A afs/cs.unc.edu AFS.CS.UNC.EDU"
>> command, (FYI).
>>
>> The kvno will always default to 1 if you do not specify it.
>> But after I run this I run "kvno afs/cs.unc.edu @MSE.UNCCS.TEST"
>> and the kvno is not 7. The kvno only increments if you change
>> the password for the domain user, in this case AFS.CS.UNC.EDU.
>
> Yes, one password per account, and the kvno is stored in the account
> as msDS-KeyVersionNumber with ( mmc and the ADSI plugin you can look
> at the AD entries.)
>
>> At this point I am not sure if there is one password for
>> the user accunt and one for the service principal or if they
>> are one and the same.
>
> They are the same.
>
>>
>> I do not know where to get a "good" version of ktpass. I will
>> ask our Windows guy, I searched Microsoft and they only have
>> the SP1 version.
>
> Asw I said there is the other way, to avoid ktpass and asetkey.
>>
>>>
>>> Another way is to create the AD account, and add the SPN,
>>> and set the password to something known. The salt can then
>>> be determened from the UPN,
>>
>> I can try this for fun but we really need simpler solution.
>
>
> msktutil we used this for unix hosts too.
>
>> What do I run to determine this?
>
> You AD dmin can look at te entry. You as a user can run
> on the mmc command, then use the ADSI Edit plugin to look at your
> domain.
>
>>
>>> of to *really* be sure, do a network
>>> trace of the KRB5_ERROR packet returned when you do a
>>> kinit afs/your.cell@REALM. Then drill down in the e-data
>>> till you find the salt for DES.
>>
>> Here it is, don't know how to decode the salt info, I got
>> this using the command:
>>
>> /usr/sbin/tshark -V host eagle or host madison-cs and port 88
>>
>> host eagle is the afs server, host madison-cs the Windows AD server.
>>
>>
>> e-data
>> padata: PA-ENCTYPE-INFO
>> Type: PA-ENCTYPE-INFO (11)
>> Value:
>> 304E3025A003020103A11E041C4D53452E554E4343532E54... des-cbc-md5
>> des-cbc-crc
>> Encryption type: des-cbc-md5 (3)
>> Salt:
>> 4D53452E554E4343532E544553544146532E43532E554E43...
>
>
> OK this is the salt! Its in asci, so:
> 4D 53 45 2E 55 4E 43 43 53 2E 54 45 53 54 41 46 53 2E 43 53 2E 55 4E
> 43...
> M S E . U N C C S . T E S T A F S . C S . U N
> C ...
>
> So this look like it is taking the realm(MSE.UNCCS.TEST) and the
> SamAccountName AFS.CS.UNC... and using these as the salt. (I assume the ...
> would be .EDU from uyourother messages.
>
>
>> Encryption type: des-cbc-crc (1)
>> Salt:
>> 4D53452E554E4343532E544553544146532E43532E554E43...
>>
>>>
>>> Then forget about asetkey, and use the AFS "bos_util adddes"
>>> command instead, to add the key to the keytab. Since bos_util
>>> was designed for Krb4 where no salt was used for DES we can in
>>> effect concatenate the password and the salt used in AD and use
>>> this as the password to bos_util adddes!
>>>
>>> Best to test this first on a non-server machine as bos_util
>>> wants to update the /usr/afs/etc/KeyTab file.
>>
>> If you can give me the password string to give
>> bos_util I will try it, that is I will enter my known password
>> I just need the other string/salt info.
>
> From the above message it looks like you would concatenate to the
> known password MSE.UNCCS.TESTAFS.CS.UNC.EDU
>
> I am not sure what the kvno is, but you can find that with the
> mmc ADSI Edit and look in the entry for the msDS-KeyVersionNumber
>
> Make sure the knvo does not match any existing keys in the KeyTable file.
> If so change the passwrod in AD again, and it will increment the
> kvno.
>
>
>>
>> Thanks for all the input.
>>
>>>
>>>
>>>
>>>
>>>
>>> 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