You just need to keep NTLM passwords in AD. Windows 2000 makes the synchronization of NTLM and Kerberos passwords trivial, from the user's perspective.

You ALSO need to allow anonymous LDAP/SAM lookup access in AD. This can be done on a per-container and per-object basis if you wish.

The general rule is: if you must run Windows 2000 clients and services with Kerberos authentication then your KDCs had better AD.

The whole [technical] point of Microsoft's profile-in-Kerberos tickets extension is to allow them to deny anonymous lookups. This is because the servers you connect to won't need to lookup your user profile data if it's provided in the Kerberos ticket.

Of course, MS's extension stinks for a number of reasons.

I suggest you search the krb-protocol and ietf-krb-wg mailing list archives. (Most posters cross-post to both lists. I don't know where there might be archives for the IETF list).

There was a thread in those lists, earlier this summer, about this whole issue.

My opinion is that MS is right to want to make it possible to deny anonymous lookups that previously had to be allowed. I think they're approach is wrong. I have proposed more than one alternative on the krb-protocol list.

Unfortunately, there is much too much interest in whining about MS' extension and not enough interest in putting forward a better alternative. Yes, MS is abusing the good will of those who dreamed up and made Kerberos possible; I know. I hope we don't degenerate into yet another debate about MS/antitrust/etc.

Another problem is that there is a strong aversion to mixing any authorization features with an authentication protocol. This is quite understandable, though I submit that with SSO systems there is an authorization issue: how to, practically, control delegation of impersonation OR, in other words, how do you authorize remote services to act on your behalf to other services while not giving those services the rights to impersonate you completely.

Nick