Cross-Platform/Realm Authentication Error Assistance

[Grant Cohoe]

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

[Wilper, Ross A]

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

Hello,

________________________________________________
Kerberos mailing list Kerb...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

[Grant Cohoe]

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!

[Wilper, Ross A]

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

[Grant Cohoe]

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.

[Grant Cohoe]

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 <rwi...@stanford.edu> 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.

[Wilper, Ross A]

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?

[Grant Cohoe]

AHA! Got it. Your mentioning of the cross-realm princ's gave me the
idea to compare them to the basic krbtgt/EXAMP...@EXAMPLE.COM. 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.