"asanford" wrote:

> We are experiencing intermittent "The trust relationship between this
> workstation and the primary domain failed" (ERROR_TRUSTED_RELATIONSHIP_FAILURE
> 1789) errors in our asp.net web service.  We are running Windows 2003 SP2 on
> the load-balanced web machines that are receiving this error, as well as on
> the Active Directory servers.  We think the code that is generating the error
> is a PrincipalPermission.Demand() call, which in turn is calling
> WindowsPrincipal.IsInRole(string) to check if an associated WindowsIdentity
> user is a member of the specified group (all groups are domain groups.)  The
> WindowsIdentity is constructed by calling Win32’s LogonUser() and then
> constructing a new WindowsIdentity with the resulting access token.  The
> account running the IIS app pool is a domain account.
>
> We’ve looked thru the various windows event logs on both web machines and
> DCs and didn’t see anything obvious, we have run “netdom verify
> [computername]” on all the machines to verify the “secure channel” between
> the given machine and the domain, which succeeded on all machines except one
> of the DCs (we think the FSMO DC (?) – BTW, is this normal for this to fail
> on the FSMO DC?)  We have also browsed thru the computer accounts in the AD
> users MMC app, etc – didn’t get any errors there.  We also checked the time
> synchronization between all of the servers and that looked correct. 
>
> We haven’t yet taken the steps of, for each web machine, resetting the
> computer account in AD, removing the machine from the domain, and then
> re-joining it, since in general things seem to work. 
>
> Perhaps the problem could be an intermittent network link between web and AD
> machines?  Or perhaps there’s a problem during high load?  Perhaps a certain
> AD logging level to watch? 
>
> Is there a recommended way to diagnose ERROR_TRUSTED_RELATIONSHIP_FAILURE
> errors, especially intermittent ones? 
>
> Any ideas would be much appreciated.
>
> Thanks!
>

"asanford" <asanford2000_at_hotmail.com@newsgroups.nospam> wrote in message
news:74AEB634-3D96-44B3-AD02-33EFCB4A84C8@microsoft.com...
> Can Microsoft please provide some assistance on this item?  Thanks!
>
> "asanford" wrote:
>
>> We are experiencing intermittent "The trust relationship between this
>> workstation and the primary domain failed"
>> (ERROR_TRUSTED_RELATIONSHIP_FAILURE
>> 1789) errors in our asp.net web service.  We are running Windows 2003 SP2
>> on
>> the load-balanced web machines that are receiving this error, as well as
>> on
>> the Active Directory servers.  We think the code that is generating the
>> error
>> is a PrincipalPermission.Demand() call, which in turn is calling
>> WindowsPrincipal.IsInRole(string) to check if an associated
>> WindowsIdentity
>> user is a member of the specified group (all groups are domain groups.)
>> The
>> WindowsIdentity is constructed by calling Win32’s LogonUser() and then
>> constructing a new WindowsIdentity with the resulting access token.  The
>> account running the IIS app pool is a domain account.
>>
>> We’ve looked thru the various windows event logs on both web machines and
>> DCs and didn’t see anything obvious, we have run “netdom verify
>> [computername]” on all the machines to verify the “secure channel”
>> between
>> the given machine and the domain, which succeeded on all machines except
>> one
>> of the DCs (we think the FSMO DC (?) – BTW, is this normal for this to
>> fail
>> on the FSMO DC?)  We have also browsed thru the computer accounts in the
>> AD
>> users MMC app, etc – didn’t get any errors there.  We also checked the
>> time
>> synchronization between all of the servers and that looked correct.
>>
>> We haven’t yet taken the steps of, for each web machine, resetting the
>> computer account in AD, removing the machine from the domain, and then
>> re-joining it, since in general things seem to work.
>>
>> Perhaps the problem could be an intermittent network link between web and
>> AD
>> machines?  Or perhaps there’s a problem during high load?  Perhaps a
>> certain
>> AD logging level to watch?
>>
>> Is there a recommended way to diagnose ERROR_TRUSTED_RELATIONSHIP_FAILURE
>> errors, especially intermittent ones?
>>
>> Any ideas would be much appreciated.
>>
>> Thanks!
>>

"Joe Kaplan" wrote:

> You need to post from a "managed" newsgroup email alias that you have
> registered to get automatic MS attention.  Please read the guidance on
> managed newsgroup support published on their website for more details.
>
> --
> Joe Kaplan-MS MVP Directory Services Programming
> Co-author of "The .NET Developer's Guide to Directory Services Programming"
> http://www.directoryprogramming.net
> "asanford" <asanford2000_at_hotmail.com@newsgroups.nospam> wrote in message
> news:74AEB634-3D96-44B3-AD02-33EFCB4A84C8@microsoft.com...
> > Can Microsoft please provide some assistance on this item?  Thanks!
> >
> > "asanford" wrote:
> >
> >> We are experiencing intermittent "The trust relationship between this
> >> workstation and the primary domain failed"
> >> (ERROR_TRUSTED_RELATIONSHIP_FAILURE
> >> 1789) errors in our asp.net web service.  We are running Windows 2003 SP2
> >> on
> >> the load-balanced web machines that are receiving this error, as well as
> >> on
> >> the Active Directory servers.  We think the code that is generating the
> >> error
> >> is a PrincipalPermission.Demand() call, which in turn is calling
> >> WindowsPrincipal.IsInRole(string) to check if an associated
> >> WindowsIdentity
> >> user is a member of the specified group (all groups are domain groups.)
> >> The
> >> WindowsIdentity is constructed by calling Win32’s LogonUser() and then
> >> constructing a new WindowsIdentity with the resulting access token.  The
> >> account running the IIS app pool is a domain account.
> >>
> >> We’ve looked thru the various windows event logs on both web machines and
> >> DCs and didn’t see anything obvious, we have run “netdom verify
> >> [computername]” on all the machines to verify the “secure channel”
> >> between
> >> the given machine and the domain, which succeeded on all machines except
> >> one
> >> of the DCs (we think the FSMO DC (?) – BTW, is this normal for this to
> >> fail
> >> on the FSMO DC?)  We have also browsed thru the computer accounts in the
> >> AD
> >> users MMC app, etc – didn’t get any errors there.  We also checked the
> >> time
> >> synchronization between all of the servers and that looked correct.
> >>
> >> We haven’t yet taken the steps of, for each web machine, resetting the
> >> computer account in AD, removing the machine from the domain, and then
> >> re-joining it, since in general things seem to work.
> >>
> >> Perhaps the problem could be an intermittent network link between web and
> >> AD
> >> machines?  Or perhaps there’s a problem during high load?  Perhaps a
> >> certain
> >> AD logging level to watch?
> >>
> >> Is there a recommended way to diagnose ERROR_TRUSTED_RELATIONSHIP_FAILURE
> >> errors, especially intermittent ones?
> >>
> >> Any ideas would be much appreciated.
> >>
> >> Thanks!
> >>
>
>

"asanford" <asanford2000_at_hotmail.com@nospam.nospam> wrote in message
news:7E5CEA76-4B6F-4159-A19F-EF35B6C8F8F2@microsoft.com...
> Hi,
>
> I thought I was...I did already have my ID registered with managed
> newsgroups, but it seems the suffix I had ("@newsgroups.nospam") is no
> longer
> auto-recognized by MS?  When I went to edit it, I could no longer assign
> such
> a suffix (it must have been allowed before), so I picked a new one from
> the 4
> available and re-posted.  Hopefully that will prompt a response.
>
> Thanks!
>
> "Joe Kaplan" wrote:
>
>> You need to post from a "managed" newsgroup email alias that you have
>> registered to get automatic MS attention.  Please read the guidance on
>> managed newsgroup support published on their website for more details.
>>
>> --
>> Joe Kaplan-MS MVP Directory Services Programming
>> Co-author of "The .NET Developer's Guide to Directory Services
>> Programming"
>> http://www.directoryprogramming.net
>> "asanford" <asanford2000_at_hotmail.com@newsgroups.nospam> wrote in
>> message
>> news:74AEB634-3D96-44B3-AD02-33EFCB4A84C8@microsoft.com...
>> > Can Microsoft please provide some assistance on this item?  Thanks!
>> >
>> > "asanford" wrote:
>> >
>> >> We are experiencing intermittent "The trust relationship between this
>> >> workstation and the primary domain failed"
>> >> (ERROR_TRUSTED_RELATIONSHIP_FAILURE
>> >> 1789) errors in our asp.net web service.  We are running Windows 2003
>> >> SP2
>> >> on
>> >> the load-balanced web machines that are receiving this error, as well
>> >> as
>> >> on
>> >> the Active Directory servers.  We think the code that is generating
>> >> the
>> >> error
>> >> is a PrincipalPermission.Demand() call, which in turn is calling
>> >> WindowsPrincipal.IsInRole(string) to check if an associated
>> >> WindowsIdentity
>> >> user is a member of the specified group (all groups are domain
>> >> groups.)
>> >> The
>> >> WindowsIdentity is constructed by calling Win32’s LogonUser() and then
>> >> constructing a new WindowsIdentity with the resulting access token.
>> >> The
>> >> account running the IIS app pool is a domain account.
>> >>
>> >> We’ve looked thru the various windows event logs on both web machines
>> >> and
>> >> DCs and didn’t see anything obvious, we have run “netdom verify
>> >> [computername]” on all the machines to verify the “secure channel”
>> >> between
>> >> the given machine and the domain, which succeeded on all machines
>> >> except
>> >> one
>> >> of the DCs (we think the FSMO DC (?) – BTW, is this normal for this to
>> >> fail
>> >> on the FSMO DC?)  We have also browsed thru the computer accounts in
>> >> the
>> >> AD
>> >> users MMC app, etc – didn’t get any errors there.  We also checked the
>> >> time
>> >> synchronization between all of the servers and that looked correct.
>> >>
>> >> We haven’t yet taken the steps of, for each web machine, resetting the
>> >> computer account in AD, removing the machine from the domain, and then
>> >> re-joining it, since in general things seem to work.
>> >>
>> >> Perhaps the problem could be an intermittent network link between web
>> >> and
>> >> AD
>> >> machines?  Or perhaps there’s a problem during high load?  Perhaps a
>> >> certain
>> >> AD logging level to watch?
>> >>
>> >> Is there a recommended way to diagnose
>> >> ERROR_TRUSTED_RELATIONSHIP_FAILURE
>> >> errors, especially intermittent ones?
>> >>
>> >> Any ideas would be much appreciated.
>> >>
>> >> Thanks!
>> >>
>>
>>