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 OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info