>>>>> "JE" == Jay Elvove <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] -- Richard Silverman [EMAIL PROTECTED] ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos