Optimization of AD domain usage: users automatically join the local administrator group after booting VBS script + restrict multiple logins¶

Original link: https://www.itylq.com/ad-domain-user-get-administrator.html

Release date: 2022-11-06 Migration time: 2026-03-21

Some time ago, the company deployed an AD domain environment based on WIN2008 R2. The number of clients is about 200. It is used in combination with EXCHANGE2010. Before deploying the clients, a group policy was made on the AD. By adding the restricted group function, DOMAIN USERS was added to the local administrator group of the client. In this way, after employees log in as domain users, they also have local administrator rights and can install some software by themselves, which reduces a lot of maintenance.

But the ensuing problem also occurred. The client's local administrator group includes DOMAIN. The USERS group means that all domain users have local administrator rights for any client. That is to say, any domain user can log in to any computer and has the highest authority. What is even more terrifying is that with administrator rights, it is easy to access the default hidden shared disk of any computer through the network. In response to the above two problems, Baidu and GOOGLE found that there is no complete solution. After painstaking consideration, piecing together, and repeated testing, they finally found the ultimate solution, which has now been verified in the company domain environment.

**The first question: Any domain user has the highest local administrator rights on any computer. **

Solution: Combine domain group policy and VBS script to achieve

Step 1: Create a new policy for the entire AD domain including computers and users. Right-click on Computer – Policy – WINDOWS Settings – Security Settings – Restricted Groups to add the name and enter administrators. Add the DOMAIN USERS and DOMAIN ADMINS groups to the restricted group. First, let all domain users have local administrator rights on any computer in the domain.

Step 2: Select User – Policy – WINDOWS Settings – Script (login/logout) in the original policy, add login and logout scripts respectively, and place the script in the shared folder of the intra-domain server that can be accessed by any domain user. The script name format is \IP address\shared folder name\script name.vbs. The script is as follows:

The content execution process of the script is: after the user logs in, add the currently logged-in domain user to the local administrator group, and delete the DOMAIN USERS group that exists in the local administrator group. In this way, only the logged-in domain user has local administrator rights. If a restricted group has not been created before, the execution of this script will not be successful because there is no administrator rights. Note: If there is a WIN7 system, UAC needs to be turned off for successful execution. This can be configured in Group Policy, Computer – Policy – WINDOWS Settings – Security Settings – Local Policy – Security Options – User Account Control: Run all administrators in administrator approval mode. Set this item to Disabled to disable UAC.

Copy the following content into the TXT file and save it in VBS format.

On Error Resume Next
dim objUser
dim objGroup
dim objDGroup
Set oNet = CreateObject("Wscript.Network")
strComputer = "."
sUser = oNet.UserName
sDomain = oNet.UserDomain
Set objUser = GetObject("WinNT://"&sDomain&"/"&sUser&",user")
Set objGroup = GetObject("WinNT://"&strComputer&"/administrators,group")
If Not objGroup.IsMember(objUser.AdsPath) Then
objGroup.Add(objUser.AdsPath)
End If
On Error Resume Next
Set oNet = CreateObject("Wscript.Network")
strComputer = "."
Set objDGroup = GetObject("WinNT://replace with domain name/domain users,group")
Set objGroup = GetObject("WinNT://"&strComputer&"/administrators,group")
If objGroup.IsMember(objDgroup.AdsPath) Then
objGroup.Remove(objDgroup.AdsPath)
End If

After performing the above operations, only the user logged in to this client will have local administrator rights. However, other users can still log in to the client and can still obtain administrator rights, so please go to the second question.

Second question: Any domain user can log in to any computer in the domain

Solution:

After completing the steps to solve the first problem above, domain users can automatically obtain local administrator rights after logging in to the computer, but they still cannot control other users to log in to this computer. Therefore, they need to create a new OU in the domain and add the computers (just computers) that have logged in and successfully obtained permissions in the solution to the first problem. In the new OU, set the new OU to prevent policy inheritance, and then create a new group policy in the new OU. In Computer-Policy-WINDOWS Settings-Security Settings-Local Policy-User Rights Assignment-Allow local login, add only the ADMINISTRATORS group and ensure that only this group is retained. In this way, after the user restarts, because policy inheritance is blocked, the previously set policy of adding DOMAIN USERS to the local administrators in the restricted group will not take effect. Only logged-in domain users and DOMAIN ADMINS remain in the local administrators group, and now it is set to allow local logins to only include ADMINISTRA. TORS, so other domain users cannot log in to this client. Only users in this domain can log in and have administrator rights. New computers that join the domain in the future will be in the COMPUTERS group by default. After the domain user logs in once, the computer will be moved to the newly created block policy inheritance group, you can simultaneously add domain users to the local administrator group and deny other users from logging in. If an employee leaves the computer and the computer is used by others, you only need to move the computer back to the COMPUTERS group. After the new user logs in once, move it back to the OU where the blocking policy is inherited. Doing this saves a lot of maintenance work, why not do it, and takes safety into account at the same time. You can make appropriate adjustments and use it flexibly according to your actual application environment and needs.

This article was moved from WordPress to MkDocs