0

So, I've been working on a SSO enabled XMPP application on our network for a couple weeks. I have 95% of the bugs worked out, and everything is running smoothly. The problem is that I have a couple machines that are not connecting, giving me the error "SSO Failed, etc etc"

I did a packet analysis, and on one machine, I am getting a packet with a Kerberos error KDC_ERR_ETYPE_NOSUPP which of course means that the server does not support the encryption type selected by the client.

This is where this get's interesting.

The request body portion of the packet sent from client to the Kerberos server shows that it is requesting encryption types that are most definitely supported by Kerberos, most notable RC4-HMAC IS being requested by the client.

I'm sure you can imagine I was quite confused when I saw that. So I compared the Kerberos request packet with the packet from another client that is functioning properly.

I found that in a portion the packet labeled as padata > ap-req > authenticator which you probably know is: (pre-authentication > authentication protocol request > authenticator) the requested encryption type is NULL !!!!

So, first of all, my other machines are using an appropriate encryption type for pre-authentication, and working just fine.

I have done nothing that I can imagine would have affected this configuration, considering that I hadn't worked on that system since I (recently) started here, nor do I have any idea where I could look to adjust that configuration. On some of our other systems there was a VPN installed that seemed to have been interfering with SSO, but that VPN was NOT installed on this system, and I have removed EVERY application aside from Microsoft Office. I also removed and re-added it to the domain, hoping that there would be some re-configuration that happened there.

How can I fix the pre-authentication protocol setting for this computer, aside from re-installing Windows?

Thanks!!

Jonathon Anderson
  • 288
  • 1
  • 3
  • 10
  • Not an answer, but I notice that you're using the XP tag. XP is EoL. Don't troubleshoot it, upgrade it. (Or take it out back and shoot it, if it's been particularly troublesome.) – HopelessN00b Dec 11 '14 at 00:49
  • As a possible answer, however, [check the registry key mentioned in this msdn blog](http://blogs.technet.com/b/instan/archive/2009/10/12/changes-in-default-encryption-type-for-kerberos-pre-authentication-on-vista-and-windows-7-clients-cause-security-audit-events-675-and-680-on-windows-server-2003-dc-s.aspx), to see if your misbehaving clients have no encryption or an invalid encryption type specified as the default for their Kerberos authentication. – HopelessN00b Dec 11 '14 at 00:57
  • I'm aware of the EOL issue. We are a non profit and work on limited funds. Perhaps you would donate a couple licenses for 7? There is no registry entry on any of the systems, working or not. I am going to add a registry entry and see if it produces a new result. – Jonathon Anderson Dec 11 '14 at 04:24
  • [Microsoft offers pretty steep discounts on software licensing for eligible non-profit organizations](http://www.microsoft.com/about/corporatecitizenship/en-us/nonprofits/whos-eligible/) and Linux is free. Either option is generally preferable to running on an EoL platform. – HopelessN00b Dec 11 '14 at 04:47
  • Modifying the registry didn't help. Strangely, when I try to access a network share, SMB/NetBios are using the appropriate encryption mechanisms and are able to access anything on the network. The only issue is with this application using SSO. I'm reinstalling, but I think there is some underlying tangential issue – Jonathon Anderson Dec 11 '14 at 15:02

0 Answers0