The trust relationship between this workstation and the primary domain fails, only sometimes, when user logs on after standard user resets their password via vbs script/LDAP via delegated permissions


Description of environment: I have a domain with two WIN 2008 R2 servers which are both Domain Controllers. On this domain I have approximately 40 workstations, almost all of them are running Windows 7 32-bit. Almost all my devices are Dell computers. All devices on the domain are local to each other on the same wired Ethernet LAN. All devices are on the same subnet of 10.10.10.x. My workstations are receiving their IP addresses via DHCP, one of the two servers which I mentioned above is functioning as my DHCP server. The domain name is in this format -

Description of Relevant AD containers: In active directory I have an OU called UsersOU in which I have User Objects and User Group Objects. There is a sub-OU under that OU called "Student Accounts" (without the quotes), this OU contains User Objects only.

Description of Delegation of Control within AD: In my UsersOU I have a user object, lets call it UserObjectA. I also have a User Group Object, lets call it UserGroupObjectA. UserObjectA is a member of UserGroupObjectA. I have delegated permissions for UserGroupObjectA for my Student Accounts OU. The permissions which I have delegated are "Create, delete, and manage user accounts," "Reset user  passwords and force password change at next logon," "Read all user information."

Description of script which users execute to perform AD functions: I have a vbs script which I have written and which I will paste below. The script references AD via LDAP. Its purpose is to allow User Objects who are in UserGroupObjectA to reset passwords for certain User Objects that are in the Student Accounts OU. The user Objects which the script allows UserGroupObjectA members to run against all begin with the letter "s" followed by at least one numeric. The script resets the User Object's password, preexpires the password, and unlocks the account for the User Object within Student Accounts against which it is ran. The script itself is located in my sysvol\DomainName\scripts directory. The Authenticated Users Group and the Server Operators Group have "Read and Execute" and "Read" permissions on this vbs file in this location. The System Object and the Administrators Group have Full Control on this vbs file in this location.

Description of method of User Access to the script: I have a network share which is a mapped drive for UserObjectA. Under this mapped drive there is a folder, let's call it FolderA. UserGroupObjectA has full contol on FolderA. Within FOlderA there is a shortcut (an .lnk file) which points to the vbs script file that I referred to above. UserGroupObjectA has "Read and Execute" and "Read" permissions on this lnk shortcut file.

UserObjectA right now has a desktop shortcut, referenced via uncpath, to FolderA. I intend to change this shortcut to reference FolderA via mapped drive letter\foldername.

Contents of Script:

strUser = InputBox("Enter full name of user or comma-separated list.  For instance s31 or s31, s32, s33.")
if strUser = "" then
   MsgBox "You didn't enter any users.",,"No User(s)"
End If

strPassword = InputBox("Enter a new password")

strUserArray = split(strUser,",")
For Each strUser in strUserArray
   strUser = trim(strUser)
   if Not (left(strUser,2) >= "s0" And left(strUser,2) <= "s9") then
   MsgBox strUser & " is not an S account."
   Set objUser = GetObject("LDAP://CN=" & strUser & ",OU=Student Accounts,OU=UsersOU,DC=xxxx,DC=xxxxxxxx,DC=org")
      If objUser.class="user" then
         objUser.SetPassword strPassword
         objUser.Put "PwdLastSet", 0
         objUser.lockoutTime = 0
         MsgBox "Password reset for " & strUser
         MsgBox strUser & " is not a valid user account."
      End If
   End If
MsgBox "Done!"

Now we do have Security Settings\Account Policies\Password Policy\Password Must Meet Complexity Requirements policy within the Domain Security Policy Enabled. If the password which the user has entered does not meet the requirement, then the Windows Script Host will popup an error box advising so, and
immediately advance to the next instance of the For-Next loop.

Here is my problem, it is random and does not occur all the time. UserObjectA uses the script to reset a Student Account password. The Student will then log on to one of the workstations with the temporary password which UserObjectA has issued to the student. The workstation will force the student to enter a new password. The student will enter the temporary (old) password, and enter and confirm his new password. When clicking ok, the student will then incur "The trust relationship between this workstation and the primary domain failed." Sometimes this student can go and log on to and use another workstation successfully, sometimes they cannot (they incur the trust relationship error when attempting logon). Sometimes if another user tries to use the workstation which incurred the trust relationship error they can use it successfully, sometimes they incur this error and cannot, and sometimes the next user can use it successufully but the user after that incurs this error and cannot logon. WOrkstations which have incurred this error have later incurred this error again both when User Objects that are in the UsersOU and when User Objects that are in the Student Accounts OU try to authenticate. There have been instances in which UserObjectA logged on to her own workstation with the account which she just reset and changed the password (when prompted to do so) at logon, and then the student attempted to logon with this account to another computer, and at this second logon the trust error was incurred.

We also have four WIN 7 64-bit workstations which this has not occurred on yet, but this might simply be because noone has duplicated this scenario on any of these workstations yet (or perhaps the problem is only affecting the 32-bit workstations).
I would really appreciate any help which anyone can give me to resolve this.
 Thank you so much, in advance!
Who is Participating?
TasmantConnect With a Mentor Commented:
hi, and thanks for your clear explanation.
at this time it can de difficult to answer, but we can point you in some direction:
- Did you checked replication on your DC (post the result of "repadmin /showrepl")? Because if you have issues with replication, computer accounts password may not be synced between DC and cause this error (it's seems aleatory and therefore could come from the DNS round Robin mechanism to obtain the logon server at start up).

Else, potentially others points:
- Did you use sysprep to deploy your computers? If not, could be related to
CitizenRonConnect With a Mentor Commented:
In my experience, the "Trust Relationship" failure message is totally a workstation issue.  It's a case of the Local Workstation's GUID and the Active Directory Domain Computer Object's GUID that it corresponds to being disassociated somehow.

The only time I have run into situations like this are when imaging/cloning computers and then connecting them to the same domain without renaming them and without using something like NewSID or SYSPrep to make sure even the local workstation GUID is unique.

On the other hand, I've never seen this happen as randomly as you suggest either.
cjrmisAuthor Commented:
Thank you for your replies. We built all the workstations individually; we didn't use any cloning software. Then we manually added each to the domain. So each should have a unique GUID on its own without having to use something like sysprep.
Ill check on the DC replication tomorrow and post back what I find.
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

cjrmisAuthor Commented:
I'm really sorry, I got caught up in another project and haven't had a chance to look into this. I'll post my results for the DC replication within the next few days.
cjrmisAuthor Commented:
Fortunately (or unfortunately, as now we can't determine the underlying cause) the problem has not continued to occur. So there is nothing for me to troubleshoot any further at this point. Thanks for your help!
cjrmisAuthor Commented:
The problem did not recur, on its own. So I could not test the solution. But the ideas suggested sound like good ideas for what may possibly cause this type of problem in general.
I am unfamiliar with how to perform "repadmin /showrepl" and would need to research how to do this. Since I needed a bit more information to complete this task, I graded this B.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.