> The preceding solution works great, but I've found that if we establish a > trust to a domain such as DOMAIN.SCHOOL.EDU (not in the same DNS hierarchy > as AD.SCHOOL.EDU) then user logons fail.
[Guy] There is a similar bug when changing passwords over cross forest trust when the UPN suffix of the account you logon with to trusting forest is different from the trusted forest's DNS name. In this case the DC resolves the domain to \\<first_part_of_upn_suffix> i.e.: [EMAIL PROTECTED] is AD account in internal.local forest and logs on to other.local forest over cross-forest transitive trust. When trying to change password (when logged on with UPN), the target domain is resolved to COMPANY and not INTERNAL (or internal.local) There is a hotfix that you might want to try (it addresses the way the domains are located when using UPN - might also resolve the MIT Kerb issue): http://support.microsoft.com/?kbid=890953 Also try to logon from W2K3 box in OTHER.AD.SCHOOL.EDU domain with MIT Kerberos principal as it is not experiencing the above behavior. Guy List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
