Changing Local Administrator Passwords Remotely

Changing domain and local passwords remotely.

As of May 13 2014 it is no longer possible to create local accounts and assign passwords to them on a domain computer via Group Policy. This was a handy feature when it existed, however Microsoft found that a vulnerability in Group Policy Preferences could allow elevation of privileges.

If you would like further reading on this head over to read about MS14-025.

Here is the KB2962486 article if you would like even more reading on this.

But the basics of it are that Microsoft dropped the ball and the key that was used to encrypt the passwords via Group Policy was published in one of their articles. Total newbs, I hope the incompetent responsible for this got fired for that one.

Either way you can no longer create local accounts on a domain attached computer and set their passwords via group policy. There is a work around but it is no longer fully automated via GPO.

It is a two step process now, and you use the “update” setting instead of “create”  in GPO. You are no longer able to create local account you can however “Update” them. The update feature will create a new account, but it will not set the password. You can use PsTools to set the passwords remotely. Inside the PsTool suite is an executable called PsPasswd.exe that can change local and domian passwords alike.

One thing to note as of this writing is that PsTools, v1.23 of the PsPasswd executable is broken. You will need v1.22 of PsPasswd to accomplish this. It’s not easy to find the v1.22 of the exec but I managed to find a link on the net that works and I’ve shared it via Gdrive.

This works on Windows 7, as for newer versions of Windows I can not comment. I will never move my domain computers to Windows 8+.

Some anti-virus scanners report that one or more of the tools are infected with a “remote admin” virus. None of the PsTools contain viruses, but they have been used by viruses, which is why they can trigger virus notifications. I also assure you I have not altered this zip file in any shape or form, that is beyond me.

PsPasswd usage:

pspasswd [[\\computer[,computer[,..] | @file [-u user [-p psswd]]] Username [NewPassword]

computer Perform the command on the remote computer or computers specified. If you omit the computer name the command runs on the local system, and if you specify a wildcard (\\*), the command runs on all computers in the current domain.

@file Run the command on each computer listed in the text file specified.

-u Specifies optional user name for login to remote computer.

-p Specifies optional password for user name. If you omit this you will be prompted to enter a hidden password.

Username Specifies name of account for password change.

NewPassword New password. If ommitted a NULL password is applied.

For example if you wanted to change a local Admin password on a domain computer named COMPU-DEV1, it would go something like this:

pspasswd \\COMPU-DEV1 -u domain\DomainAdmin -p Password Administrator Password

If you wanted to change the local Admin password on all the computers on the Domain you can execute the following command:

pspasswd \\* -u domain\DomainAdmin -p Password Administrator Password

Alternatively you can do this with a text file. The file needs to contain a single computer name on each line. You can export such file from Active Directory, do this by right clicking the appropriate OU and select Export List… select the Text (Tab Delimited) .txt file format. You’ll have to remove the first line out of the file, and any other columns that aren’t the computer name.

The formatting for PsPasswd with a file is as follows.

pspasswd @c:\locationoffile\computers.txt -u domain\DomainAdmin -p Password Administrator Password

Advertisements

Deploying a WSUS environment with GPO

WSUS or Windows Server Update Services is used on a local network to approve or reject Windows updates and security fixes. The benefits of this system of delivering updates is that it allows you as much or as little control over updates as you want. It’s all about choice. So if you do not want the Windows 10 OS update rolling out to your Windows 7 desktops, you have the ability to prevent that.   

For Server 2012 R2 it’s quite easy to install WSUS. Start up the Server Manager, click Add roles and features, and under Server Roles and Windows Server Update Services select WID Database and WSUS Services. Install the WSUS server role.setup1

setup2

Once installed,start up WSUS and you should be greeted by the WSUS Server Configuration Wizard. If that is not the case you can start it manually from the WSUS Options.

There are a few things you should note before you start.setup3

Join the improvement program if you wish. I generally opt out.

Choose the upstream server. If this is your only WSUS server on the network you will synchronize your updates from Microsoft. Otherwise you can opt for another WSUS server on your network.

Set a proxy server if you need to.

Then you will connect to the upstream server by clicking Start Connecting button. This process can take a while and it can actually fail on your first try. Be patient, grab a coffee or something.setup4

Choose the language that you want all your updates in.

Choose which OS or Microsoft Software you want to receive updates for.

Pick which types of updates you want. Generally I pick critical, definition, and security updates.setup7

Configure the Sync Schedule. This sets the time at which WSUS checks for new updates and pulls them down from Microsoft. I generally set this for after business hours.setup8

You can now start the initial sync of Windows Updates for the products you selected, go ahead and grab a long lunch, this can take a while.

Now you can set a couple of other options in the WSUS application. I like to set the Automatic Approvals. This way I’m not approving hundreds of updates every week. I set the Critical and Security updates for WIndows 7 desktops to automatically approve. You can also set it up for a specific group of computers. You can set this group up either manually or via Group Policy. I will cover the group policy method later in the post.setup9

Next go to Computers in WSUS options and select Use Group Policy or registry settings on computers. This option allows you to use group policy to set the computer group membership. This is the preferred method. Close it, the next time the sync runs it should pull all the updates down. Please note that generally during initial setup, when I ran the manual sync it would more often than not fail. I had to wait for WSUS to pull the updates automatically on it’s scheduled evening run.

Now you will have to create two Group Policy Objects. One of the GPOs will be used to set the local update server and other Windows Update options. The other GPO will be used to log users off prior to the updates being applied on the computers. The reason I do this is that the computer will not restart after the updates are pushed if there are any users logged into the computer. The restart is a necessary part of the update.

Here are the things you want to consider when creating these GPOs; when will you be applying these updates, what time of day, which day of the week? These are all questions you should be asking yourself. For instance on my network I schedule my updates for every Wednesday at 10 PM or 22:00. On that same Wednesday evening at 9:30 PM all users are logged off every machine on the network. You don’t want to interfere with your employees but you also don’t want the computer to break from a bad patch or update on a Friday morning. You want to avoid spending the entire Friday and parts of the weekend fixing broken software.

Let’s create the Windows Update policy first:

Open up the Policy Manager either on the server or via Remote Administration Tools.

Create a new policy and name it something like WSUS_Desktops. This will be the desktop update policy and will reside in the OU where all the Network computers are.

Link the new policy to the appropriate OU, it is a good practice to test a policy prior to rolling it out, so maybe first link the GPU to a test OU, or set Item Level Targeting for the time being. This is how I do it on my network.

In the New GPO navigate to Computer Configuration, Policies, Administrative Templates, Windows Components, and Windows Update.GPO1

Open up Windows Update to view the policies in there.GPO2

I only care about 5 of those policies. You can get away with using as few as 2 to push Windows Updates via WSUS using a GPO.

Configure Automatic Updates, this policy setting sets up how the updates are downloaded and how they are scheduled to install. I use option 4 – Auto download and schedule the install. I schedule the install time for every Wednesday at 22:00 or 10pm. Enable it and set the options accordingly for your environment.

Specify intranet Microsoft update service location, this policy setting points the computers to the server where you installed the WSUS application. Please input the http address of the WSUS server and port, for example http://server-name:8530. You don’t need to use a FQDN. If you need to find the port number for your WSUS instance remote into the server where WSUS resides, open IIS Manager, and select Sites, in the right pane you will see all the running websites and which port they are on.GPO3

Enable the policy and input the address in the two fields under the options pane, same address for both the intranet update service and the statistics server.

Automatic Updates detection frequency, this sets the interval at which the desktop computers check back with the WSUS server to see if there are any new windows updates. Default is 22 hours, this setting is optional.

Turn off the upgrade to the latest version of Windows through Windows Update, this will prevent the dreaded Windows 10 update from appearing on your Windows desktop. This is optional but a wise choice if you choose to enable it.

Enable client-side targeting, this policy setting has only one purpose, it is to set the target group in WSUS. Whatever you the group name, this is what the computers that apply this group policy will be sorted under in WSUS. Do not forget to change the Automatic Approvals in WSUS to this group and make sure all the auto approvals are pointing to the right computer group name. The policy will not auto generate the group in WUSUS, you need to manually create it. Once you create it the computers will be auto added to the group.

One thing to consider is that you might want to change the Security Filtering for the GPO. I changed mine to Domain Computers and removed Authenticated Users, since this policy only targets the machines and not the users this made sense. Once the policy is in place for few minutes, you can run the gpupdate command in command line on your test desktop to attempt and update the group policies on said computer.

Then you can check to see which update server the computer is pointing to by running the following command with elevated privileges on the test desktop…

REG QUERY “HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate”

This will show you the WUServer property, which is the Windows Update server address.

If this value or property is not present then then the group policy has not been applied yet, you might need to reboot. Alternatively you can try to manually register the computer with the server using the following command, wuauclt /detectnow.

Once you have that working, now you can create a group policy to log users off before the updates roll out each week. This is necessary as the computers might not reboot if users are still logged on to the desktops during the update process. Users need to log off so that the policy can reboot the PCs and roll out subsequent Windows Updates.

Create a new policy and name it something along the lines of Users Log Off. Link this GPO to the appropriate OU, one where all the network users reside. Again you might want to test the policy first before deploying it to everyone in your Domain. Open the GPO to User Configuration, Preferences, Control Panel Settings, Scheduled Tasks.

Create a new task and call it something along the lines of “Log Off Notify”. This task will notify users 15 minutes prior to logging them off to have them save their work as not to lose it. The task should look similar to the following.

Note the Action for this task is Display a message the message reads “You will be logged off in 15 minutes. Please save and close all your work if you do not wish to lose it.“

In the same Group Policy create another task and call it something along the lines of “Windows Log Off”. This task will log the users off their computers prior to the Windows Updates being applied. It should look like the following.

Note that the Action for this task is Start a program and you are running a force log off command using cmd.exe and switches.

That is it! Run some tests on your test computer to see if the Tasks are being pushed to your workstation. Test the tasks, make sure they work. 

Windows 10 Remote Server Administration Tools finally available.

Despite Windows 10 being more like Windows 8 than Windows 7 and a security nightmare, you might be using it at work and there is also a chance you might want to administer your Active Directory. I prefer this method it is easier to work with than having to RDP to the Domain Controller. Microshaft finally decided to release the RSAT tool kit for Windows 10, and you can grab it here: https://www.microsoft.com/en-us/download/details.aspx?id=45520

Install it on your machine and give it a reboot. Once you reboot your computer head over to Control Panel > Programs and Features > Turn Windows features on or off.

Under Remote Server Administration Tools and Role Administration Tools select the features you might want.adds

Note that the Group Policy Administration Tools feature sits under Remote Server Administration Tools > Feature Administration Tools.GPO

There you go, finally you can manage your domain from the comfort of your desktop. Also to note that these features were all installed by default when I installed Windows 10 RSAT, this might be due to the fact that I upgraded from Windows 7 and it had RSAT installed but when I upgraded Windows 10 did not have an equivalent feature set. I’m thinking there might have been a setting left over from the previous OS version, that’s all. If not be sure to chime in.

All these features can be accessed from the Administrative Tools section in the Control Panel.AdminTools

Noe you have to find a way to enjoy the shitty OS.

AD Security Filtering and Item Level Targeting, apply specific policies to specific resources.

Let’s talk Active Directory again, AD for short. In my opinion is an IT administrators best friend. It has the potential to eliminate the need for log on scripts, it can simplify software deployments to multiple computers, improve security, and eliminate malware. If you’re an IT admin in a small shop or new to the Admin game and haven’t really employed AD on your network beside the default domain policy, I suggest you have a look into it.

What does Security Filtering and Item Level Targeting do exactly? Well they allow you to apply Group Policies to individual users, computers or groups.

FilteringSecurity Filtering is a basic way of filtering out to which group the policy is applied to. For instance, when one creates a new Group Policy Object in Active Directory, by default the GPO applies to Authenticated Users. So any user that logs on to the domain or rather is authenticated by the domain, and exists in the OU where the GPO resides, will have said policy applied when they log in. Now, let’s say you want to limit this to a specific set of users. Perhaps someone in the Accounting department, they might have a specific drive or access to a drive that you want them to have mapped when they log on. This is easy to accomplish with Security Filtering. Please be aware that Security Filtering is not the only way to restrict or grant access to specific network resources, not at all. There are several ways to approach this, some more complicated than others, this is merely just one of those ways.

The benefit of Security Filtering is that you will omit any users, security groups, or computers that are not in this list. It also gives you a somewhat greater control, such as allowing you to set the read write permissions on each group in the policy. Security Filtering is a top level filter, during log on AD will check to see if you are part of said resource and if you are not no further checks will be performed against this policy. The draw back is that no further checks will be performed against this policy, so for for instance if you have a policy that maps various network drives to people in different departments and the drives differ per department you’d have to create new policies for each department. Note: Some people prefer to have separate policies per department, and organize theirs just like this. This method works well for large organizations that need to visually separate policies.

Insert Item level Targeting, it is a nested form of filtering within a specific Active Directory policy. This is where you can have your entire filtering done inside the policy. Perfect for your smaller offices or filtering resources per department. On my network I use Item Level targeting to target specific groups which users are members of to map special drives on their computers. ItemLevel

I don’t have that many users that I support and this is a viable solution to me. For larger scale organizations and to be more transparent with your policies use Security Filtering.

There are many ways to filter groups, users, and computer these are just a couple that are useful.

Side Note: You can also use WMI filters to filter group policies based on specific hardware resources. WMI filters need to be created in the Group Policy Management editor. WMI filters can be created and applied a GPO based on computer attributes, such as the OS, free space, brand, or model. This is perfect if you want to deploy drivers and software to specific machines on your network or range of machines without wanting to add them to a specific group.

Use GPO to set user as a local administrator on a single computer.

This is a revision of a previous post I did. In this version there are fewer steps that need to be performed in the policy. The key here is Item Level targeting, it allows you to apply policies to specific targets in your Active Directory. In this case the target would be a specific computer.

Open up your group policy managment console. Via the run command if you’re on the server, gpmc.msc. I run my policy manager from a Win 7 desktop on the domain, for this you need to install and setup the Remote Server Administration Tools, and run them with Domain Admin credentials. Once you have this open navigate down through your forest and domain to the right organizational unit (ou) where your new admin policy will sit. Generally you want to apply this in the computer OU, as the policy will be affecting desktops on your domain.

Right click on the OU and select “Create a GPO in this domain, and Link it here…“. Give the new Group Policy Object a new name and click OK. Now right click the new GPO and select “Edit…“, this will bring up the GPO editor.

GPEDIT

Since this policy applies to a specific computer we will select the Computer Configuration, Preferences, Control Panel Settings, and Local Users and Groups. On the right pane of this option right click and select New, Local Group. In the properties of this for Action: select Update. Group name: will be Administrators (built-in), this is the local Administrators group on all PCs. Rename to: renames the Administrators group on the target PC. Description: is just a description you might want to put in here “Administrators for computer X”. Next click Add under the Members: pane. This will bring up the Local Group Member prompt. In the Name: field type in %DomainName%\userid , where the userid is a specific logon ID and in my case tuser or my domain Test User account. %DomainName% is a variable and in this case it is the domain that the GPO resides in. If you want to see all the available variables hit F3 in the Name: field.

Click OK on the Local Group Member prompt.

AdminAdd

Now click the Common tab in the New Local Group Properties window. Here is where we target which computer that this policy will be applied to. On the Common tab check off Item-level targeting and click the Targeting… button.

common

In the target editor on the top left select New Item and Computer Name. the NetBIOS computer name is should appear. In the pane below click the “” button, here is where you select the computer this policy will apply to. Type in a computer name and click Check Names, it should underline the computer name if found correctly.

computername

 

cpname

Click OK, OK, and OK. Congratulations you have successfully assigned a user to the local administrator group on a single computer on the domain.

GPOM

You can also rename this to reflect more closely what the Action does. Highlight it and press F2, then rename.

GPOM2

 

Go ahead, close the Group Policy Management Editor, you’re done.

NOTE: If you want to add a single user on the network as an Administrator on all the network computers your best bet for Item Level targeting is to create a Security Group and make all Domain computers members of this group. One you’ve done that use Item Level targeting and target this said group.

Use GPO to add a single admin user to only one computer on the domain.

UPDATE: This post has some great ideas, however if you’d like an easier way to accomplish this with Item-level targeting navigate to this new post.

This post I’m going to detour from the usual Home Theatre write up. I still have more Home Theatre to go through, however I though I would give this topic a little attention. So recently I embarked on locking down my companies computer systems and what better way to do it with than Group Policy. Well I ran into a little problem when I tried to assign a single user as a local administrator on a single domain computer, it seemed impossible to accomplish with Restricted Groups as they encompass the entire OU no one single computer.

I searched the dark recesses of the internet and I thought I had found a link on social.technet, but as it turned out this did not allow me to do all the work remotely and I had to add additional groups to the computers. Then further looking over what Alan Burchill wrote I concluded that with his implication of the policy local administrators would be able to add other network users as local administrators, this did not work for me. I want to rule with an Iron Fist!!!

Either way what Allan had set out for me in black and white was a very good start and it really helped . Some of the comments in the post also shone some light on the behaviour of the Policy. You can find Allan’s blog post in regards to this here: http://www.grouppolicy.biz/2010/01/how-to-use-group-policy-preferences-to-secure-local-administrator-groups/.

What’s nice about this method is that it will also clean up your policy each time it gets updated or anyone logs on to the computers in the OU. So if anyone adds another admin user to the group they will be removed. Also if you have some old administrators on PCs that were added manually in the past and have since left this will remove them.

Well let’s get on with it then, shall we.

My environment consists of Server 2008 R2 and Windows 7 machines.

I run my policy editor on my local machine, however I recommend you run it off your server since you can run gpupdate /force from there as it propagates faster this way.

1. Start the policy editor  on your server by going to Start > Run > gpmc.msc

Create a new policy under the OU in which you have your domain computers.

12. Edit the policy and navigate to Local Users and Groups, Computer Configuration > Preferences > Control Panel Settings > Local Users and Groups.

3. Right click in the right pane of the window and select New > Local Group, you will be prompted with a New Local Group Policy window.

4. The Action heading should be set to Update,  from the Group name drop down list select “Administrators (built-in)”, check off  “Delete all member users” and “Delete all member groups”. Only use these options on the first Order policy as these are the options used to clear any previously assigned users and groups to the Local Administrators group.

25. Next we will add a single member to this new Local Admin policy. Click Add and you will be prompted with Local Group Member window, in the Name: section type in “BuiltIn\Administrator” this adds the Administrator account present on all machines to the Administrators group. For Action: select Add to this group.

6. Your Local Group Properties window should look like the following image. If yours looks the same go ahead and click OK.

3

7. This will take you back to the Group Policy Management Editor and you will have one policy with Order 1. The order is the order in which these policies get applied in. Since we’ll be adding more policies you may want to rename this policy in the Editor to something more descriptive like “Built in Local Admin”, highlight the policy and press F2 to do so.

4

In Allan’s blog he groups  the assignment of the Built in Admin account and Domain Administrators group in one Local Group. What I have found to be the case is that if you have more than one member that is to be added to the Local Group and one of these members does not exists or the spelling is incorrect the Local Group policy will stop processing as soon as it encounters and error and refrain from processing any further Member assignments. As a good practice try and assign one member per Order.

8. Let’s create a new policy. This time we will add the Domain Admins group as Administrators to all the OU computers. Follow steps 3 & 4 again, with one exception, do not check off  “Delete all member users” and “Delete all member groups” leave these unchecked otherwise when this policy is processed it will remove the previous members from policy Order 1  (Built in Local Admin).

9. When adding the member as in step 5, click in the Name: field and hit F3. You will be prompted with a Select a Variable window, select “DomainName” and make sure Resolve Variable is checked off then proceed and click Select. This will populate the Name field in the Group Member window add “\Domain Admins” to this so you have “%DomainName%\Domain Admins” in the Name field and click OK.

5

Your new policy should look something like the following image. You may not have a Domain Admins group on your domain, and if that is the case substitute the name of the group to the one that matches up with your domain administrators group. Now you should have two groups, go ahead and rename the second one as well. I renamed mine to Domain Admins.

6

10. In my 3rd order policy, since by default all local Administrator accounts are disabled, I ended up adding a local user account named “User” to all computers in the OU. Right click and select New User. It’s very similar to creating a new user on the domain.

7

11. In my 4th order policy I assign the User account to the Administrators (built-in) group. The only difference between this step and step 9 is instead of using the %DomainName% variable I’m using the %ComputerName% variable. Also to note you don’t need to hit F3 to select the variable you can type the information in manually ie. “%ComputerName%\User”. It should look like the following image. Click ok and rename the policy.

8

12. Now this is where the magic happens and we create an individualized local admin policy for a single computer. Before we create the policy we need to rename the Administrator group on each computer to something unique, after pondering this for a while I came up with the following solution. Create a new Local Group policy. Action: Update, Group Name: Administrators (built-in), Rename to: %ComputerName%.ADMIN. Do not Add any members leave this portion blank and click OK. Rename the policy if you would like.

9

The key here is the %ComputerName%.ADMIN, each computer will rename the Administrators group locally to something unique to that computer in this case it will use it’s name. For example a computer named DMCL-00203 will rename the local admin group to DMCL-00203.ADMIN. As seen below.

13

Once you have this in place you are able to add individual local administrators by creating new Local Group policies with higher orders than the policy which renames the local admin group.

13. To add a local administrator to computer DMCL-00203 create a new Local Group policy, Action: Update, Group name: DMCL-00203.ADMIN add a member using %DomainName%\UserId, UserID being a valid domain account.

11

You can add more member accounts to this policy just know that if it errors out or the account is invalid there is a possibility that the policy will not be applied to the computer. That is it, now you should have 6 policies in place depending on how many computers need local admin users. The order of the policies are important, for example you can not assign a local user to the admin group in order 6 if the user account gets created in order 7. Keep this in mind when designing your policy.

12

IMPORTANT UPDATE: So it seems the Active Directory likes to show all the computer admin groups created with in the policy on one single computer (see below). However that does not mean that the users in these groups have admin access to all computers on the network, having tested this they only have access to the computer they are assigned to. This is purely aesthetic.

adminoooIn order to avoid this purely asthetic replication to other computers except the target machine use “Item-Level Targeting”, it is available under the common tab. So at the end of step 13. click the common tab, and check item level targeting and click the Targeting button. Then in the Targeting Editor select New Item and Computer Name, then Type in the computer name or look it up in the Domain using the … button.

14 15