locked
My.User.IsInRole("Role Name") throws a Trust Relationship error on Windows 7 RRS feed

  • Question

  • Hi Forum,

    I hope someone can help me with this one, we've been working on this for weeks but can't find a solution.

    Problem: My programs throw a Trust Relationship error when calling My.User.IsInRole() but only on Windows 7 64 bits.  They work on all our Windows XP stations.

    My code is pretty simple.

    With My.User
       if .IsInRole("Some Security Group Name") Then
          Bla.. Bla.. Bla..
      End If
    End With

    I'm the only one in the company using Windows 7 which we are evaluating to decide if/when we're going to upgrade all our PC's.  I am a domain administrator and my PC is in the domain and I'm authenticated.  Since I installed Win 7 I haven't had any other authentication issues.

    The apps are built on .NET 2.0 SP2

    I don't know much about our domain setup which is handled by our network administrator but I'm told that the Primary Controller is a Windows 2003 and the Secondary is Windows 2000.  He tells me that by default every workstation first authenticate on the Secondary controller if it's available.

    Here's the StackTrace

    System.SystemException was unhandled
      Message="The trust relationship between this workstation and the primary domain failed.\r\n"
      Source="mscorlib"
      StackTrace:
           at System.Security.Principal.NTAccount.TranslateToSids(IdentityReferenceCollection sourceAccounts, Boolean& someFailed)
           at System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess)
           at System.Security.Principal.WindowsPrincipal.IsInRole(String role)
           at Microsoft.VisualBasic.ApplicationServices.User.IsInRole(String role)
           at Inventory.Form1.SetSecurity() in D:\Visual Studio 2005\Projects\Inventory\Inventory\Form1.vb:line 92
           at Inventory.Form1.Form1_Load(Object sender, EventArgs e) in D:\Visual Studio 2005\Projects\Inventory\Inventory\Form1.vb:line 12
           at System.EventHandler.Invoke(Object sender, EventArgs e)
           at System.Windows.Forms.Form.OnLoad(EventArgs e)
           at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
           at System.Windows.Forms.Control.CreateControl()
           at System.Windows.Forms.Control.WmShowWindow(Message& m)
           at System.Windows.Forms.Control.WndProc(Message& m)
           at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
           at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
           at System.Windows.Forms.UnsafeNativeMethods.SendMessage(HandleRef hWnd, Int32 msg, Int32 wParam, Int32 lParam)
           at System.Windows.Forms.Form.SetVisibleCore(Boolean value)
           at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
           at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
           at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnRun()
           at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoApplicationModel()
           at Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run(String[] commandLine)
           at Inventory.My.MyApplication.Main(String[] Args) in 17d14f5c-a337-4978-8281-53493378c1071.vb:line 81
           at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args)
           at System.Runtime.Hosting.ApplicationActivator.CreateInstance(ActivationContext activationContext, String[] activationCustomData)
           at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssemblyDebugInZone()
           at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
           at System.Threading.ThreadHelper.ThreadStart()
    Thursday, December 10, 2009 11:28 PM

Answers

  • Thanks for answering Ji.

    I found my answer last night after a few hours of "Googling" and "Binging". It is in fact a problem with all Windows 7  and Windows 2008 R2.  I installed the following Hotfix and the issue is now resolved.  I'm guessing that the IsInRole() function in .NET makes a call to Windows' LookupAccountName function.

    My question would have been better asked in the .NET or in the AD/LDAP forum you pointed me to but I'm posting the solution here anyway in case somebody with the same problem checks this thread.

    Error 1789 when you use the LookupAccountName function on a computer that is running Windows 7 or Windows Server 2008 R2

    • Marked as answer by Eric Gagne Friday, December 11, 2009 1:54 PM
    Friday, December 11, 2009 1:52 PM

All replies

  • Hello Eric,

     

    Thanks for posting in MSDN forum! Actually the codes are simple and just look fine to me. I think it should not be related to Windows 7, but related to the AD environment.

    I searched on the web and find the following discussion,
    http://social.msdn.microsoft.com/forums/en-US/clr/thread/f7c1a1ec-106c-4fec-b8ad-2e126591099a

    So it looks like the user logged in are in different domain from the parameter group's domain,  and the that user do not have privileges to access the AD trees where the group is defined, right?

    Considering the scenario is complicated and AD specific, I think the VB forum is not very appropriate for it. A better place is,
    http://forums.asp.net/93.aspx (Active Directory and LDAP)

    By the way, as a MSDN subscriber, you have up to four free support incidents. I think for such an issue, it is a good idea to open a case and handle with CSS support engineer directly.
     

    Ji Zhou

    MSDN Subscriber Support in Forum

    If you have any feedback on our support, please contact msdnmg@microsoft.com


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    • Marked as answer by Eric Gagne Friday, December 11, 2009 1:52 PM
    • Unmarked as answer by Eric Gagne Friday, December 11, 2009 1:53 PM
    Friday, December 11, 2009 10:45 AM
    Moderator
  • Thanks for answering Ji.

    I found my answer last night after a few hours of "Googling" and "Binging". It is in fact a problem with all Windows 7  and Windows 2008 R2.  I installed the following Hotfix and the issue is now resolved.  I'm guessing that the IsInRole() function in .NET makes a call to Windows' LookupAccountName function.

    My question would have been better asked in the .NET or in the AD/LDAP forum you pointed me to but I'm posting the solution here anyway in case somebody with the same problem checks this thread.

    Error 1789 when you use the LookupAccountName function on a computer that is running Windows 7 or Windows Server 2008 R2

    • Marked as answer by Eric Gagne Friday, December 11, 2009 1:54 PM
    Friday, December 11, 2009 1:52 PM