Link to home
Start Free TrialLog in
Avatar of cjrmis
cjrmis

asked on

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

Hi,

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)"
   Wsh.Quit
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."
   else
   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
         objUser.SetInfo
         MsgBox "Password reset for " & strUser
      Else
         MsgBox strUser & " is not a valid user account."
      End If
   End If
Next
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!
SOLUTION
Avatar of CitizenRon
CitizenRon
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of cjrmis
cjrmis

ASKER

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.
Thanks.
Avatar of cjrmis

ASKER

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.
Avatar of cjrmis

ASKER

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!
Avatar of cjrmis

ASKER

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.