AHA! Got it. Your mentioning of the cross-realm princ's gave me the idea to compare them to the basic krbtgt/[email protected]. It seems that when I created the cross-realm princ's, I did not explicitly set their encryption type to our default. So technically the principal did contain the DES-CBC-CRC encryption, but it also had another one in there of a different type and I guess it was trying to authenticate to that. I recreated the krbtgt princs and it worked like a charm.
Thank you very much for your help! Hopefully this will be of use to someone in the future. On Tue, Jan 25, 2011 at 3:14 PM, Wilper, Ross A <[email protected]> wrote: > No really brilliant insights. Not very likely that your cross-realm > principals on the MIT side does not contain DES enctype keys... You are not > upgrading from Windows 2003, so it's not the DES key "upgrade" bug in Windows > 2008 R2 (kb978055)... > > What are the registry settings under HKLM\CCS\Control\LSA\Kerberos\Domains? > > Were the user passwords set after upgrading the supported enctypes on the > Domain Controller? > Have you tried flushing all of the trust principals and trying again? > > -Ross > > -----Original Message----- > From: Grant Cohoe [mailto:[email protected]] > Sent: Monday, January 24, 2011 7:58 PM > To: Wilper, Ross A > Cc: [email protected] > Subject: Re: Cross-Platform/Realm Authentication Error Assistance > > No good on the state of that flag. I have spun up a machine running > Windows Server 2003 and configured it to be identical to the Windows > Server 2008R2 one. Despite this, I still get the same error as above. > Also just for kicks, I setup a Windows XP client to do some testing, > and even it still produces the error. I hoped that the older operating > systems would be able to avoid the whole deprecated DES type, but it > seems that even that is not working. Any thoughts? > > On Mon, Jan 24, 2011 at 7:46 PM, Wilper, Ross A <[email protected]> wrote: >> You might try removing the flag to use DES enctypes on the user account.. We >> never turned that on when we had a DES-CBC-CRC trust password. I think what >> that flag actually does is disable all enctypes other than DES-CBC-CRC and >> DES-CBC-MD5. >> >> -Ross >> >> -----Original Message----- >> From: Grant Cohoe [mailto:[email protected]] >> Sent: Monday, January 24, 2011 1:38 PM >> To: Wilper, Ross A >> Cc: [email protected] >> Subject: Re: Cross-Platform/Realm Authentication Error Assistance >> >> Yeah, I would like to keep our DC on 2008R2 for future features. But >> our MIT KDC might be holding us back on that. What I find somewhat >> peculiar is that in the TGS-REQ from the Windows 7 Client to the AD >> DC, it reports multiple encryption types (aes123, aes256, rc4-hmac, >> des-cbc-crc, des-cbc-md5, rc4-hmac-exp, rc4-hmac-old-exp). I don't >> know if this has any bearing on the issue I am having though. >> >> On Mon, Jan 24, 2011 at 3:42 PM, Wilper, Ross A <[email protected]> wrote: >>> Well that isn't it then. There is another trust flag in trustAttributes on >>> the object that forces RC4 on Windows 2003 domain controllers only, but >>> that would not be your issue since you are running a newer OS. >>> >>> Trust objects are in CN=System,DC=<DOMAIN> >>> >>> -Ross >>> >>> -----Original Message----- >>> From: Grant Cohoe [mailto:[email protected]] >>> Sent: Monday, January 24, 2011 11:21 AM >>> To: Wilper, Ross A >>> Cc: [email protected] >>> Subject: Re: Cross-Platform/Realm Authentication Error Assistance >>> >>> I ran 'ksetup /getenctypeattr EXAMPLE.COM' on the AD DC and it >>> returned "Enctypes for domain EXAMPLE.COM: DES-CBC-CRC". I set this >>> earlier with 'ksetup /setenctypeattr EXAMPLE.COM DES-CBC-CRC'. Still >>> no good. Where in AD might I find the actual trust object? I looked >>> through ADSI Editor and was unable to locate anything that looked >>> related to this. >>> >>> Thanks! >>> >>> On Mon, Jan 24, 2011 at 12:26 PM, Wilper, Ross A <[email protected]> >>> wrote: >>>> First, I would strongly suggest that you set the allowed encryption types >>>> by GPO, not by setting registry on machines. >>>> >>>> By default, all new external trust relationships created on Windows Server >>>> 2008 R2 will use only RC4-HMAC for the cross-realm enctype. You must use >>>> ksetup to enable/disable other enctypes (This will update the >>>> msDS-SupportedEncryptionTypes attribute on the trust object in AD you feel >>>> brave) >>>> >>>> -Ross >>>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:[email protected]] On Behalf >>>> Of Grant Cohoe >>>> Sent: Sunday, January 23, 2011 3:19 PM >>>> To: [email protected] >>>> Subject: Cross-Platform/Realm Authentication Error Assistance >>>> >>>> Hello, >>>> >>>> My organization is in the process of integrating an Active Directory >>>> server into our current UNIX-based environment for the purposes of >>>> account management and workstation policy. >>>> >>>> We currently have an MIT Kerberos KDC with realm EXAMPLE.COM >>>> (replacing my actual realms and domains). We now have the AD domain of >>>> AD.EXAMPLE.COM running on a Windows Server 2008R2 server. Following >>>> the guide here (http://pig.made-it.com/kerberos-trust.html), I have >>>> attempted to set up an outgoing realm trust between EXAMPLE.COM and >>>> AD.EXAMPLE.COM (in that the latter trusts the former for >>>> authentication). I am currently testing with a Windows 7 workstation >>>> that has been joined the the AD domain. Our MIT KDC currently >>>> supports DES-CBC-CRC only (something we are in the process of >>>> changing), so I ran gpedit on the Windows 7 client and added the >>>> appropriate settings according to this TechNet article >>>> (http://technet.microsoft.com/en-us/library/dd560670(WS.10).aspx). I >>>> have also specified this policy on the DC. On the AD DC, I set the >>>> "Use Kerberos DES encryption types for this account" flag for my >>>> testing user account. >>>> >>>> Using my EXAMPLE.COM credentials and monitoring the network traffic, I >>>> can see the AS and TGS communication between the Windows 7 client and >>>> the MIT KDC and all seems well there. However when the Windows 7 >>>> client attempts to communicate with the AD DC (TGS-REQ), I get a >>>> "KRB5KDC_ERR_ETYPE_NOSUPP" error. At first, I thought it was just some >>>> encryption type mismatches. In the TGS-REQ to the AD DC, I can see >>>> multiple encryption types including DES-CBC-CRC, yet something in AD >>>> isn't liking this. As per this document >>>> (http://wiki.alfresco.com/wiki/Alfresco_Authentication_Subsystems), my >>>> suspicions were confirmed that it is indeed an encryption problem, but >>>> I am unsure as to how to go about fixing this on the AD DC. Could >>>> anyone help shed some light on what is happening or provide some ideas >>>> for how to fix this? >>>> >>>> Thank you in advance for any help you can provide, >>>> -- >>>> Grant Cohoe >>>> >>>> System Administrator, Computer Science House >>>> Applied Networking and System Administration >>>> Rochester Institute of Technology >>>> ________________________________________________ >>>> Kerberos mailing list [email protected] >>>> https://mailman.mit.edu/mailman/listinfo/kerberos >>>> >>> >>> >>> >>> -- >>> Grant Cohoe >>> >>> System Administrator, Computer Science House >>> Applied Networking and System Administration >>> Rochester Institute of Technology >>> >> >> >> >> -- >> Grant Cohoe >> >> System Administrator, Computer Science House >> Applied Networking and System Administration >> Rochester Institute of Technology >> > > > > -- > Grant Cohoe > > System Administrator, Computer Science House > Applied Networking and System Administration > Rochester Institute of Technology > -- Grant Cohoe System Administrator, Computer Science House Applied Networking and System Administration Rochester Institute of Technology ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
