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 ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
