3

I'm looking to set up a Kerberos trust between MIT Kerberos5 and Active Directory. However, it's noted in my old Kerberos book from 2003 that "there are several applications, notably Microsoft Exchange (2000 and below), that still use the older NTLM-style authentication."

Fortunately, we don't use MS Exchange, but there's concern that we may miss an important use case that Kerberos doesn't support. I know other organizations in our industry have done a similar setup, and I know they have found workarounds for this, but I haven't found a good list of apps that gave them problems. Can the ServerFault community help me out here? Even anecdotal evidence is appreciated.

EDIT 1: APIs to Active Directory require password changes to be delivered in plaintext rather than hashes. We'd like to remove that requirement from our authentication infrastructure by standing up an MIT realm for user authentication. There are some use cases that might make helpdesk's life easier, but it would be difficult to get other people in IT to agree to a change if it breaks any applications.

Community
  • 1
jldugger
  • 14,122
  • 19
  • 73
  • 129
  • 1
    what's this about exchange not supporting kerberos? iirc, it used kerberos heavily. I think it's msrpc calls using spnego for the initial context establishment, so that could fall back to ntlm if kerberos was b0rked, but kerberos all the way by default. Of course I am not a) an exchange admin or b) even a windows admin, for that matter. but sounds to me like this book is out of date. – Michael Lowman Jul 29 '11 at 19:20
  • 1
    If your Kerberos book is the O'Reilly one, this is at least 8 years old ... – Sven Jul 29 '11 at 19:26
  • Sven, I'm trying to locate a newer book. I've asked this question in hopes of finding newer advice: http://serverfault.com/questions/295608/can-anyone-recommend-a-book-on-kerberos-that-mentions-ad-2008 – jldugger Jul 29 '11 at 19:50
  • "I am trying to understand how the answers would affect your decision on whether to create the realm trust or not." If our proposed change breaks existing uses, there will be... "push back." – jldugger Jul 29 '11 at 19:52
  • Oops, small mistake in the quote regarding Exchange, corrected. – jldugger Jul 29 '11 at 19:57
  • maweeras, I suspect we'll still have users in AD, simply because of applications pointing at it for auth likely use it for directory information. But we'd probably push in long random passwords if the AD schema requires one. – jldugger Jul 29 '11 at 21:05
  • Its not the AD schema that requires "long random passwords". Its the password policy you enforce in AD. Complexity aside, admins can control length of password for users. I am interested to know how you think the MIT realm can help you. – maweeras Jul 29 '11 at 22:43
  • Mainly meant if AD allowed authentication with null passwords. To your interest: we built a metadirectory that populates and drives a number of systems, comparable perhaps to Forefront Identity stuff. AD has long been a sore spot that we work around, because the features are valuable and occasionally AD is the best solution to non-MS stuff. But since AD requires a plaintext we don't keep, the hashes we store do us no good (particularly at a later date). Other Kerberos systems don't have this limitation, hence the cross-realm trust. MIT, CMU, Stanford, and others all use this setup. – jldugger Jul 30 '11 at 02:24

2 Answers2

1

I'm not sure what book that is, but Outlook/Exchange can use Kerberos. It is possible to have it use NTLM, perhaps they meant that.

Also note that Windows Server 2003 IIS can use Kerberos, but if unsuccessful, it will attempt NTLM. There really isn't anything that can be done to prevent this except using a custom HTTP module, and it can be frustratingly non-apparent which authentication mechanism is in use.

I believe Windows 2008 R2 IIS introduced a new protocol, Nego2, which enables finer granularity of control over authentication mechanisms (Kerberos and no NTLM).

http://blogs.iis.net/mailant/archive/2009/01/11/iis7-in-windows-server-2008-r2.aspx

enter image description here

Greg Askew
  • 34,339
  • 3
  • 52
  • 81
1

Everything Microsoft does (IIS, SMB2, Exchange, etc.) supports Kerberos nowadays. And in case you're not in a domain, there's fallthrough to something else. What non-Microsoft services are you currently running on the Windows side that you're worried about?

If you had a list of every two-bit app with ten users, it's more than likely most would support little more than hard-coded passwords. And larger apps generally work with the OS for authentication; in that case Kerberos should be supported.

Do you have a more specific use-case?

Michael Lowman
  • 3,584
  • 19
  • 36
  • "Do you have a more specific use-case?" Unfortunately, no. We're talking university enterprise wide authentication. Which means any and everything some random department buys and requests SSO for. It also means I don't have a ready list of everything the enterprise runs. – jldugger Jul 29 '11 at 20:03
  • So you're migrating your users to exclusively having MIT accounts? If so, reduce pushback by explaining in understandable terms how much easier it makes your life to have a single system, and how much money that saves and security that adds. Any users of an app old/odd enough to not use OS APIs can live without SSO for your peace of mind. – Michael Lowman Jul 29 '11 at 20:09
  • Usually it's other IT people that push back. But we'll certainly try. There's just a fear within from management (something about credibility) that we're missing a critical use case that will scuttle the project before we can come up with a workaround / solution. – jldugger Jul 29 '11 at 20:12
  • I can understand the fear. Perhaps treat this as an opportunity to find outdated and unsupported apps? You certainly don't want anything that falls back on LM ;) And I've seen 3.1 boxes still in use at universities... best to get anything too old off the network, stat. – Michael Lowman Jul 29 '11 at 20:14
  • 2
    @jldugger Having just recently come through the "lets turn off LM already" fires at my recently-ex job at a mid-size university, I know very well what you're facing. We, legitimately, had some Win3.11 around attached to *very* expensive scientific equipment. The owners of that agreed to keep their data-interchange to "other methods" and saved us a fight. – sysadmin1138 Jul 29 '11 at 21:15