This looks promising. I'll give a call to Microsoft on Monday and see if
this hotfix helps.
andrew
--On Saturday, June 25, 2005 4:45 AM +0300 Guy Teverovsky
<[EMAIL PROTECTED]> wrote:
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/
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/