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
