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/[EMAIL PROTECTED]: >>> ktutil: wkt keytab.ktutil >>> >>> eagle/root [/usr/afs/etc] # asetkey add 5 keytab.ktutil >>> afs/[EMAIL PROTECTED] >>> >>> 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: >>> --------------------------------- >>> [EMAIL PROTECTED] /]$ 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 >>> >>> [EMAIL PROTECTED] /]$ kinit >>> Password for [EMAIL PROTECTED]: >>> >>> [EMAIL PROTECTED] /]$ klist >>> Ticket cache: FILE:/tmp/krb5cc_3903_015mRF >>> Default principal: [EMAIL PROTECTED] >>> >>> Valid starting Expires Service principal >>> 01/10/07 08:56:02 01/10/07 18:56:06 >>> krbtgt/[EMAIL PROTECTED] >>> renew until 01/17/07 08:56:02 >>> >>> >>> Kerberos 4 ticket cache: /tmp/tkt3903 >>> klist: You have no tickets cached >>> >>> [EMAIL PROTECTED] /]$ kvno afs/[EMAIL PROTECTED] >>> afs/[EMAIL PROTECTED]: kvno = 5 >>> >>> [EMAIL PROTECTED] /]$ klist >>> Ticket cache: FILE:/tmp/krb5cc_3903_015mRF >>> Default principal: [EMAIL PROTECTED] >>> >>> Valid starting Expires Service principal >>> 01/10/07 08:56:02 01/10/07 18:56:06 >>> krbtgt/[EMAIL PROTECTED] >>> renew until 01/17/07 08:56:02 >>> 01/10/07 08:56:28 01/10/07 18:56:06 afs/[EMAIL PROTECTED] >>> renew until 01/17/07 08:56:02 >>> >>> >>> Kerberos 4 ticket cache: /tmp/tkt3903 >>> klist: You have no tickets cached >>> >>> [EMAIL PROTECTED] /]$ 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/[EMAIL PROTECTED] >>> 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 >>> [EMAIL PROTECTED] /]$ tokens >>> >>> Tokens held by the Cache Manager: >>> >>> User's (AFS ID 3903) tokens for [EMAIL PROTECTED] [Expires Jan 10 18:56] >>> --End of list-- >>> >>> [EMAIL PROTECTED] /]$ 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/[EMAIL PROTECTED] != afs/[EMAIL PROTECTED] >>>> >>>> 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/[EMAIL PROTECTED] >>>> >>>> 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: >>>>>> [EMAIL PROTECTED] != afs/[EMAIL PROTECTED] >>>>>> >>>>>> choose one and stick with it. >>>>> I am confused with Windows principals: >>>>> >>>>> [EMAIL PROTECTED] /]$ kinit afs/[EMAIL PROTECTED] >>>>> kinit(v5): Client not found in Kerberos database while getting initial >>>>> credentials >>>>> >>>>> That is why I did: >>>>> >>>>> [EMAIL PROTECTED] /]$ kinit afs >>>>> Password for [EMAIL PROTECTED]: >>>>> >>>>> 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): >>>>> >>>>> >>>>> |[EMAIL PROTECTED]:19% kinit afs/cs.unc.edu >>>>> Password for afs/[EMAIL PROTECTED]: >>>>> >>>>> >>>>> >>>>>> >>>>>> 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/[EMAIL PROTECTED] -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 [EMAIL PROTECTED]: >>>>>>> eagle/root [/usr/afs/etc] # kvno afs >>>>>>> [EMAIL PROTECTED]: kvno = 4 >>>>>>> >>>>>>> I then ran: >>>>>>> >>>>>>> ktutil> add_entry -password -p afs/[EMAIL PROTECTED] -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 [EMAIL PROTECTED] 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 >> >> > _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
