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
Posted on 2011-03-01
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 - xxxx.xxxxxxxx.org.
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)"
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.Put "PwdLastSet", 0
objUser.lockoutTime = 0
MsgBox "Password reset for " & strUser
MsgBox strUser & " is not a valid user account."
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!