Easily Find Local Admins on Your Network
In this article I want to share a super easy method of finding local administrators on a workstation, and all workstations that have local admins on them. Recently I needed to find admins on my network, and I think this solution is a very neat, simple and useful method that doesn’t require too much coding.
Finding Local Admins
Why is this important? We find ourselves increasingly granting users the privilege of being local administrators on their computer. Even though it is not a wise thing to do, sometimes it’s the easiest solution for users who can’t perform some actions on their computers because they do not have local admin rights.
There have been several incidents where I had to fix damage that users caused to computers due to their local admins rights. For example: They deleted registry keys, deleted system files, edited the HOSTS file in a wrong way, installed add-ons and all sorts of nasty toolbars and crapware, added other users as local administrators, etc.
Because of this, I decided to collect that information and centralize a list of who is a local administrator on which computer in my domain. We are going now to create a script, which after it runs, will create several textual output files.
Passwords Haven’t Disappeared Yet
123456. Qwerty. Iloveyou. No, these are not exercises for people who are brand new to typing. Shockingly, they are among the most common passwords that end users choose in 2021. Research has found that the average business user must manually type out, or copy/paste, the credentials to 154 websites per month. We repeatedly got one question that surprised us: “Why would I ever trust a third party with control of my network?
Creating a Shared Folder
Both the script and the output files have to be accessible to all the workstation in the domain that we want to scan, so as a preparation you have to create and share a folder and edit the Share and NTFS permissions of that folder. This shared folder can be created on any file server on your environment, but for the purpose of this demonstration I will create the shared folder on the Domain Controller. Obviously this is not a best practice for a real environment, but will be good enough here in a test environment.
Note: The following solution is very straightforward. Obviously it can be done in probably 101 other ways, but for my purposes it was perfect.
Now, create a batch file that runs the following commands. Copy and paste to a batch file as two separate lines and replace the share folder names according to your folders name.
net localgroup administrators | find “\” | find /v “Domain Admins” > \\Server_name\Share_name\Computers\%COMPUTERNAME%.txt
for /F “tokens=1,2 delims=\” %%i in (\\Server_name\Share_name\ \Computers\%COMPUTERNAME%.txt) do if not “%%j”==”” echo %DATE% — %COMPUTERNAME% >> \\ Server_name\Share_name\Users\%%j.TXT
Explanation of the command:
We search in local group named administrators, for entries that do NOT contain the string Domain Admins (by using find /V), the output of this command will be written to a text file which is located at \\Server_name\Share_name\Computers.
The name of the text file is the computer’s name (\%COMPUTERNAME%.txt).
The part of /F “tokens=1,2 delims=\” %%i is a loop command against a set of files – in this case, all the files that were created under \\Server_name\Share_name\ \Computers. The output will be a text file for each user, and in each user’s file the current date and computer name where he or she is a local administrator will be written.
The batch file looks like that:
Applying the script to all the workstations in the domain
The best way to apply this script is to use Group Policy Object (GPO).
For this demonstration I will use:
- Petri-labs.local – as the domain name.
- petri-dc – as the domain controller.
- Workstations – OU that contains the user’s computers that I want to scan
- admin-pc and client2 – computers that located under Workstations OU in Active Directory
If you’re using an Active Directory-based GPO, open the Group Policy Management Console (Start > Run > gpmc.msc) from a Windows client (running Vista/7/2008/R2/2012) that is a member of that domain.
In the GPMC window, find the required GPO that is linked to the domain or OU where the computers are located, then edit it, or if needed, create a new GPO.
If you decided to create new GPO:
- Select the desired OU, right click and create new GPO.
- Give a name to the GPO object.
- Select the GPO link that was just created, then right-click and select Edit.
- In the Group Policy Editor window, browse to Computer Configuration > Policies > Windows Settings > Scripts (Startup/Shutdown), and select Startup. Right-click that and select Properties.
- As shown in the next image, click Add and browse to the location where the batch file is saved, Then click OK.
Note: Even if the batch file is saved on the local drive of the computer where you create the GPO, you must use the path of the share folder and not the local path. Unless you point the GPO to the shared folder, the other computers on the network will not be able to process the script.
In this example, even though the file is saved at: C:\Reports\findadmin.bat, I must use \\petri-dc\Reports\findadmin.bat, otherwise the computers will search for the batch at their local C: drive and will not be able to access the file on the share drive.
Of course, as mentioned before, you will have to share the folder and handle the Share and NTFS permissions of that folder.
In Active Directory you can see an OU called “Workstations” that contains two computer accounts: ADMIN-PC and CLIENT2.
My goal for this demo is that when the GPO applies to Workstations OU, the script that runs will create a file for each computer account under \\petri-dc\Reports\Computers.
If we look at the members of the local administrators group on ADMIN-PC we can find the following users.
And if we look at the members of the local administrators group on CLIENT2 we can find the following users.
Once the GPO is applied, it will only take effect on the OU after the computer restarts. The results of the GPO after it was applied to both of the test computers are shown below:
A text file was created for each computer and the name of the file is actually the computer name. Open each file and you can find the users that are part of the local administrator group. If you compare it to the images above, you can see that only the domain users (and not local user accounts) appears in that file:
Now browse to the Users folder, and you can see that for each user a text file was created.
Open each file, and you can see that for each user you get a list of computers in which that particular user is a member of the local administrator group.
As you can see it was a very easy solution with a super easy implementation, and the output files are very friendly for the administrator to read. Now all you have to do is decide who needs to be a local admin and who is not!