>>>>> "JE" == Jay Elvove <jay at umd.edu> writes:
JE> Last month, a colleague of mine sent a message to the Windows
JE> Higher Ed list asking about possible problems authenticating
JE> certain Microsoft applications to an external KDC. We're getting
JE> ready to roll out our very first campus-wide Active Directory
JE> environment, which will include Exchange 2007 and Microsoft
JE> SharePoint Server (MOSS) 2007. User accounts and other data will
JE> be populated into AD using Microsoft Identify Lifecycle Manager
JE> 2007. The plan, which thus far has worked successfully in test,
JE> is to store user passwords in our Heimdal KDC and force all
JE> authentications to occur through the external KDC
Can you give more details about your setup? I'm guessing that you have an
AD realm, a Heimdal realm, cross-realm trust at least of Heimdal by AD,
and that you have people choose the Heimdal realm when logging into
Windows.
JE> Several key departments have voiced concerns over whether or not
JE> web authentication to applications such as MOSS 2007, Outlook Web
JE> Access (OWA) and Citrix will work using an external KDC.
If the setup is as above, you'll need to set the altSecurityIdentities
attribute on your AD accounts with the corresponding Kerberos principals
from your Heimdal realm, so that when AD receives a request for a service
ticket based on a TGT issued by Heimdal, it can return the appropriate PAC
in the ticket. The Windows service to which you present the ticket needs
it.
JE> We received a lot of good information from the Windows Higher Ed
JE> list, but I thought it might be valuable to get feedback from the
JE> folks who support external KDCs as well. Are there any major
JE> gotchas that those of us who support Kerberos or the Windows
JE> community at large should be aware of?
There are plenty of other gotchas, unfortunately, although they may not
all apply to you. A few that spring to mind:
* There are registry bits you need to set on Windows clients so that they
will use an external realm, including features of the realm such as TCP
support, trust for delegation, whether the client will use the DNS to
locate KDCs, etc. Some of these bits are not documented.
* Unix clients are responsible for determining the realm of a service
host, and use static configuration or the DNS to do so. Windows clients
always assume a host is in the local AD realm, and rely on AD to return
Kerberos referrals to redirect them. On the other hand, these referrals
must never be returned to Unix clients, which will not know how to
handle them. This issue applies if you're trying to access kerberized
services in the Unix realm from Windows, e.g. an Apache server using
mod_auth_kerb.
* Kerberos tickets including the PAC can get quite large, and some
non-Windows services can't deal with them, either because they can't
handle the size or they don't expect anything in the authorization field
at all. Cisco routers have problems with them, as does Apache /
mod_auth_kerb (the latter problem can be fixed). Some older Kerberos
software can only do UDP, and so can't fall back on TCP to transfer
a big ticket which won't fit in a single UDP message.
JE> Thanks,
JE> Jay ----- Jay Elvove Distributed Computing Services University of
JE> Maryland Office of Information Technology Computer & Space
JE> Sciences Building Room 1301A College Park, MD 20742 jay at umd.edu
--
Richard Silverman
res at qoxp.net