Our environment consists of Windows 7 clients in a 2008-functional domain. All DCs are running server 2008 R2. I have recently created a 1-way AES Trust between our domain and an MIT Kerberos realm. I am using name mappings to map AltSecurityID for a given user account to the Realm principal, eg, each user in AD has a 1:1 name mapping with a principal in the realm such that the realm provides authentication for the user account, which is then granted access to resources in the domain. This is implemented thru Active Directory name mappings and Kerberos V5 interoperability settings in group policy. (Passthrough authentication) Problem: User on a Windows 7 client successfully authenticates to the domain using his MIT Realm account credentials. He is granted a separate kerberos TGT from both the Realm and the Server2008 domain. He receives all the AD groups his account belongs to in the domain, and he is able to open file resources hosted on fileservers running Server 2008. HOWEVER, when the client attempts to access file resources hosted on a Server 2003 file server, the client is challenged for credentials. Any credentials given fail, whether in the form domain\user, or realm\principal. In contrast, logging in to the domain using an account that does NOT use name mappings --ie the domain authenticates the user, not the realm-- produces no such errors. I understand that server 2003 does not support AES for kerberos. But I would expect that the windows 7 client should negotiate a lesser encryption type when attempting to connect to downlevel servers. An article on the MS site states that in my scenario (win7 client, 2008 domain, server 2003 resources), the kerberos exchange only partly uses AES, specifically, the Service Ticket request/response and the TGT request/response use AES --and this does indeed work. But as soon as a user logs on using an account that utilizes passthrough authentication to the UNIX realm, the client isn't able to connect to any severs not running at least server 2008. Using only server 2008 is not a viable solution. Thanks for any insight. --- ian

Hello Ian, If we are being prompted for credentials when authenticating to the 2003 machine, that normally implies that we are either unable to obtain a kerberos ticket or the 2003 server we are passing it to is unable to decrypt or use the ticket for some reason. So let’s break down each section… The first thing I’m interested in is knowing if he client machine successfully gets a ticket or not. To check this we can use a tool like klist.exe. So if we are on the client machine and run “klist purge” then agree to purge each ticket from cache, we will have no tickets. Then if we attempt to connect to a network share by name (not IP or cname) on the 2003 server, the client should attempt to get a ticket. So after the connection is attempted and you are prompted for creds, we can run “klist tickets” to see what tickets we obtained. We should always see a TGT ticket listed for the domain and/or realm (for example krbtgt/Contoso.com), but we should also have a TGS ticket for the server itself. If we try to connect to a network share we should see a ticket for “cifs/<serverName>” If we don’t have a ticket this is the problem and we generally need to look at network trace of the failed ticket request to determine why the DC could not give us one. If you are using netmon or wireshark a display filter of “udp.port==88 || tcp.port==88” will show all ticket requests, you are primarily interested the TGS response packets from the DC to look for any type of error, for example KDC_S_PRINCIPAL_UNKNOWN means the DC could not find an SPN for the resource we are trying to connect to. (NOTE: Remember that kerberos tickets are cached so anytime you are getting a network trace of Kerberos traffic you always want to flush your Kerberos tickets (klist purge) before starting the capture and reproducing the problem to make sure you see the request in the trace). If you do get a ticket that would imply that when passing that ticket to the 2003 server there is something about our ticket he doesn’t like, it may be that he is unable to decrypt the ticket. If you do get a cifs TGS ticket for the 2003 server on the client, then we should first check the system event log on the 2003 server to look for any Kerberos related errors at that time, if we are not able to decrypt a ticket we’re generally pretty good at logging errors to indicate why. In fact if you haven’t already check the system log on all machines involved to see if anyone is logging Kerberos or KDC errors of interest. If you’re looking at this in a trace, you can also drill into the Kerberos ticket requests and responses to see what etypes the client is asking for and what etypes the server supports, we agree on highest encryption that both support. Here are a few Known issues and KB articles that may be worth checking out… As you may or may not know we no longer support DES encryption types out of box on Windows 7/2008 R2, KB 977321 provides more information on this 977321 KDC Event ID 16 or 27 is logged if DES for Kerberos is disabled http://support.microsoft.com/default.aspx?scid=kb;EN-US;977321 The following issue should effect connections to 2003 or 2008 machines so I’m not sure its related to this, but it is still one you should be aware of. 976424 Error code when the kpasswd protocol fails after you perform an authoritative restore: "KDC_ERROR_S_PRINCIPAL_UNKNOWN" http://support.microsoft.com/default.aspx?scid=kb;EN-US;976424 I hope this info helps…J Tait