Archive for the ‘GPO’ Category

HOWTO: Set Logon as a Service Dynamically via GPO

March 16, 2015 Leave a comment

I recently ran into a situation where a client has a group per server for Administrators, Remote Desktop Users, and hopefully, Service Accounts.  This may or may not be the best way of dealing with this, but it does solve a need by moving user access to AD vs configuration on local servers.  It’s a little easier to centralize and manage by administrators that may have access to AD but not the servers themselves (eg: HelpDesk users).  The problem, as indicated below, is that setting the rights for the service account/groups has been getting done manually to the systems as they are built or needed.  This has resulted in inconsistencies, as one might expect.  So I found a way to standardize and bring it all “back up to code”, as it were.



You have a need to set a user or group to have “Log on as a Service” or “Log on as a Batch Job” rights.  This can be done via the Local Security Policy (secpol.msc) or via GPO.  However, there are two obvious issues with this:

1) Using SECPOL.MSC means you’re editing the local security policy.  While this may be the only way to accomplish this, it is decentralized and uncertain to maintain. 

2) Using the GPO method only allows you to set a particular set of user(s) or group(s) to the affected machines

However, if you have a need to set a 1:1 relationship with a dynamic name to the system, GPO’s and the Local Security Policy leave something to be desired.  There is no functionality within the GPO to say “Apply GRP-%SERVERNAME%-SVC” to have this rights, and have it apply as needed – at least for the Logon As a Service right.  Using other methods you can allocate to existing groups with existing rights, but you cannot either dynamically specify a group in THIS GPO location, affect the Local Security Policy, or set the rights for this local group. 


  • Have each server/system have a group such as GRP-SERVER01-SVC group identifying service accounts.  This would be a company policy scenario, and would ensure that administration and auditing of local group memberships was ONLY done via Active Directory, and could be done via delegated rights by users who may not have rights to login to the server. 
  • Have the group apply only to the named server.  Eg: GRP-SERVER01-SVC should have rights on SERVER01, but not SERVER02 or SERVER03
  • If possible, one should also be able to add to the local group a GRP-ALLSERVERS-SVC for a service account that might be globally allowed. Eg: DOMAIN\svcAutomation, DOMAIN\svcBackup, etc. 
  • Centrally manageable
  • Automatic, dynamic, updates and standardizes over time. 
  • OPTIONAL – also do similar for the pre-existing local groups of “Administrators” and “Remote Desktop Users” for a corresponding GRP-%COMPUTERNAME%-ADM and GRP-%COMPUTERNAME%-RDP as appropriate.


1) Obtain the file “NTRIGHTS.EXE” from the Windows 2003 Resource Kit found at

Unpack/install the Resource Kit and copy the file where appropriate. 

2) Copy the file centrally to a location that is accessible by the MACHINE account, not a user.  A great example would be to place the file in \\DOMAIN\NETLOGON, as this allows Read/Execute.

3) Create a script that will run in that location that contains the following:


@echo off 

net localgroup "Service Accounts" /add /Comment:"Used for allowing Service Accounts local rights" >> \\SERVER\INSTALLS\BIN\logs\SET_LOGONASSERVICE.LOG

\\SERVER\INSTALLS\BIN\ntrights +r SeServiceLogonRight -u "Service Accounts" -m \\%COMPUTERNAME% >> \\SERVER\INSTALLS\BIN\logs\SET_LOGONASSERVICE.LOG 


4) If required, this script can be called via PSEXEC and executed against a list of computers:


This MUST be run with the –u / -p switch to specify the user to use with the –h “highest privileges”.  The –C must also be used to copy the batch file to the local system so it can run. 

You will see entries in the log similar to:

Granting SeServiceLogonRight to Service Accounts on \\NW-ADCS1... successful 

Granting SeServiceLogonRight to Service Accounts on \\NW-DC1... successful 

Granting SeServiceLogonRight to Service Accounts on \\NW-DC2... successful 

5) We now have a local group called “Service Accounts” and this local group has the rights “Logon as a Service”. 

We can verify this by running “SECPOL.MSC” on one of the servers and checking the rights assignments:


Sure enough, the local “Service Accounts” group is listed.

6) We can now handle the remainder of this via normal GPO’s for Restricted Groups, using DYNAMIC naming. 

Open the GPO editor and create a new GPO and name it something obvious such as “LOCAL_RESTRICTED_GROUPS”, and then edit it.



Right click and select NEW -> LOCAL GROUP

8) Now we modify the properties for this group:


We will choose UPDATE for an action, as the group should already exist based on our previous work. 

The group name will be “SERVICE ACCOUNTS”. 

Click ADD to add members


This is where the magic comes in.  If you press the “…” beside the NAME, you can search for the group/user based on a traditional ADUC type search.  But we don’t want that.  Instead, place your cursor in the NAME field.  Press the F3 key:


We get a list of VARIABLES!  We want to use ComputerName so that we can reference the group as GRP-%COMPUTERNAME%-SVC and each computer will get its own group.  Click SELECT.


Note the variable shows %ComputerName% as expected.  Modify that as needed to have the GRP- and -SVC prefix and suffix.


Click OK to close this window.

I’ve chosen to also add an -ADM and –RDP group for Administrators and Remote Desktop Users as this is another use case.


Close and save the GPO

9) Link your GPO appropriately:


Here I have a GROUPS-TEST OU and I have placed my NW-VEEAM01 server in this OU, along with the 3 associated groups.   This will limit impact during testing.

10) On the system in question, check the current group memberships:


11) On the system in question, run a “gpupdate /force”

12) Again on the system in question, confirm the updated group membership:


There you have it.  The ADM/RDP groups were easy as they not only pre-exist, but are pre-defined.  The complication really was the “Service Accounts” group, which both does not pre-exist, and has no special rights by default or built in direct way of adding them via the command line. 

The recommendation would be to run the SET_LOGONASSERVICE.BAT as part of the server build process/scripts, or have it pre-done in your deployment image/WIM/VM Template.  Equally, a PSEXEC run against all servers in the domain could force set this group on a periodic basis to ensure the rights existed.  Additional error checking could be built in to check if the command was successful, check if the domain group exists, create it if required, etc. 

Some post comments:

  • Remember that the local account has a SID.  If it is deleted, and recreated with the same name, that won’t be enough as the Log on as a Service right will be assigned to the old SID
  • As the batch file creates the account with a description and we didn’t tell the GPO to do so, it’ll create a new group if required, but with no description.  This is your identifier that something is off, and hopefully that helps you troubleshoot.

Windows Patching – What happens when you aren’t paying attention.

November 19, 2014 Leave a comment

Yesterday, I posted some details about MS14-068 and MS14-066 ( and of course today, have had to do some investigating into a few sites that have a variety of patching systems.  Some are using SCCM, some WSUS, some have policies and procedures, some don’t.  But I noticed a potential ‘perfect storm’(?) of situations that could cause some of them grief – and it was more than just one.

Let me draw you a picture of what is a pretty common environment:

  • WSUS exists for updates, because that’s “the responsible thing to do”
  • WSUS was likely configured some time ago, and no one likes it because it’s not sexy or fancy, so it doesn’t get any love.  Thus, it is probably running on Windows 2008 or 2008 R2.
  • Someone at some point *did* ensure that WSUS was upgraded or installed with WSUS 3.0 SP2

This all sounds pretty good, on the face of it.  Now let’s introduce some real world into this environment….

  • Someone decreed that they shall “only install Critical and Security Updates” – Updates, Update Rollups, Feature Packs, etc, would not be installed.
  • Procedures state that you will install updates that are previous month or older – so  you’re staying 30 days out, which is reasonable – let someone else go on Day0.
  • Those same procedures state that you will look at the list, and select the Critical and Security Updates from the last month, and approve them.
  • Nothing is stated for what to do about the current month’s patches – they are left as “unapproved” – but also not “declined”

Alright, so still pretty “common” and at face value, not that bad.  A year or two goes by, and now you introduce Windows 2012 and Windows 2012 R2 to the mix.  This itself is not a problem, but it’s where you start to see the cracks.  Without even having to look at the environment, I know already the things I want to be looking for….

  • Because the current month’s updates are not being “Declined”, they’re showing up in the list as “missing”.  If you have 10 updates, and 8 are approved and 2 are not, you will only ever possibly show 90% patched.  The remaining two WSUS/WU knows are “available”, but “I don’t have them.  You want to decline those so they only show up as 8 updates and 100% success.  Otherwise, how do you know at a glance if the missing update is the approved one that SHOULD be there, or one from this month?  Your reporting is bad.  See:


  • Because the process counts on someone approving “last months” updates and not “all previous updates”, there’s almost certainly going to be some weird “gap” where there is a period of a few months that isn’t approved and isn’t installed for some reason.  But the “assumption” is that they’re all healthy.  Because the previous point doesn’t “decline” any updates, the reports for completion are untrustworthy – and/or never reviewed anyways.


  • Next, Windows 2012+ has been introduced.  There’s a KB that is required to be installed on the WSUS server *and* rebuild of the WSUS package on the client to ensure compatibility.  See MS KB2734608 (  Because this is an “Update” and neither Critical nor Security, it is not applied to either the WSUS server or the clients.



  • In order for the Windows 2012/2012R2 WU/WSUS behavior to actually be changed, you need GPO’s that Windows 2012/2012R2 understands.  In order for that to be true, you need 2012+ ADMX files in your GPO environment.  Preferably in your GPO “Central Store” (again –  But because Windows 2012 and 2012 R2 were likely “added to the domain” with no testing, studying, certification, or reading, this wasn’t done.  Equally, even if it WAS done, most likely someone is still editing the GPO’s on the 2008/2008R2 based Domain Controller – which wipes out the ADMX based changes and replaces them with ADM files and the subset of options that they understand.  You’ll never know this happened though, and even if you jump up and down and tell people not to do it, they will.


  • No one is ever doing a WSUS cleanup, so Expired, Superceded, etc updates are still present.  Which isn’t helping anyone.


So to make that detail a little shorter:

  • Choosing Critical and Security Updates only is causing you to miss out on *required* updates.  Stop being “fancy” – just select them all please.
  • Because you’re choosing “date ranges” of updates, you’re missing some from time to time.  Stop being “fancy” – select “from TODAY-## to END”
  • If you introduce a new OS to your environment, you need to ensure your AD and GPO’s support them.

On top of the Updates and Update Rollups above that cause those issues, let’s take a quick look at some of the other things that are NOT considered Critical or Security Updates:

November 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2:

    That’s just ONE Update Rollup.  None of those look like ANYTHING I’d want to happen to my servers.  </Sarcasm> So why WOULDN’T I want to install those?  Yes, there may be features you’re not using.  Perhaps you don’t use DeDuplication or DFS-R.  Won’t it be fun later when you install those Roles/Features, and WSUS scans that server, and says “all good, nothing to update” for you?  Tons of fun!
    So, long story short – please stop being fancy.  You’re introducing complexity and gaps into your environment, and actually making things harder.  This means more work for you and your staff and co-workers.  That likely don’t have enough time and resources as it is.
    Don’t pay technical debt….

HOWTO: Force WSUS Client to Update using PSEXEC

March 21, 2014 2 comments

WSUS is a great tool for automating and managing Windows Updates to various systems in a domain. However, it’s not really all that granular, which is a problem. While you could say “install all updates at 03:00 on Saturday”, you can’t say “and after rebooting, check again, because you’re still in the maintenance window”. You also can’t specify “do it RIGHT NOW, don’t wait for a random period” and there are some difficulties with “reboot when complete, don’t want 5-15 minutes, don’t wait 3 days, do it now”.

It turns out there some undocumented switches for the Windows Update Client (wuauclt.exe). Various lists can be found all over, I’ve found one at:

If you use these methods it might take you a bit of tweaking and fighting to make it work. Specifically if you’re having issues with Windows 2012/2012R2 systems, check: HOWTO: Dealing with Windows 2012 and 2012 R2 Windows Update Behavior and the 3 Day Delay.

This method can be pushed out to all systems via PSexec. Note though that there are some things to watch for:

· The GPO must be set to “4 – Download and Install Updates”. If it is set to “3 – Download and Notify” then all the “wuauclt /UpdateNow” in the world won’t make it do what it’s not allowed

· Except for maybe on Windows 2012/2012R2 systems, where it will think it’s in a maintenance window, and well, you said “UpdateNow”, so let’s do that.

· I’ve found it to be intermittent if the Day/Hour for the option to install in the GPO is not set near the time you’re pushing out. This doesn’t matter so much if you’re doing a scheduled restart such as “Sunday @ 03:00”. But if you have a manual maintenance window where you’re trying to brute force blast out and confirm all the updates that starts at Friday @ 20:00 – you should probably ensure that the GPO is set to the same, especially given that this batch file will refresh the GPupdate.

· As time goes on through that maintenance window, update the GPO time as well. They must go hand in hand.


What you’ll see is that it will schedule the installation for the next day. In the above example, C:\WINDOWS\WINDOWSUPDATE.LOG is showing that on 2014-03-20 at 2:20AM it says it is scheduling the installation to occur at March 21 2014 at 12:00AM. This is because the first line indicates the GPO setting is “Every day” @ “00:00”. So if anything, you’d like that to be “the next hour, of the same or following day”. Watch things like running Friday at 11:45PM and not changing your “Install Day” from Friday to Saturday to accommodate the 00:00 or 01:00 next time.

· There doesn’t seem to be any harm in pushing out the batch file to a system that’s already updating, other than it will restart the Windows Update service. Where possible though, you want to push it to systems that are not otherwise installing. I don’t yet have a method for knowing if a current update process is occurring. Perhaps if you took the “ping” process that is the timer, and made it a “start /wait” with a title, then looked to see if a process was running with that title, don’t run…. But this is as far as I’ve gotten for now.

· Periodically check the WSUS console for “Last Updated” and “Last Reported” to get an idea for what systems need checking. Also look at the % complete column to know which systems are done.

With all that said, the batch file itself:

===== WSUS_FORCE.BAT =====

@echo off






REM psexec @SERVER.LST -u svcautomation -H -f -c -D \\FSRVCLOWSUS1\E$\WSUS\bin\WSUS_FORCE.bat





gpupdate /force


REM Restart services and refresh Windows Update


net stop wuauserv

REG DELETE "HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /v LastWaitTimeout /f

REG DELETE "HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /v DetectionStartTime /f

REG DELETE "HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update" /v NextDetectionTime /f

net start wuauserv

wuauclt /scannow

wuauclt /resetauthorization /detectnow


wuauclt /r /ReportNow


wuauclt /UpdateNow



REM This registry key only exists if WSUS indicates a reboot is required. Thus, keep checking for it to appear, and then reboot


ping -n 61 > nul

reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired" >nul







shutdown -r -t 0



===== WSUS_FORCE.BAT =====

HOWTO: Dealing with Windows 2012 and 2012 R2 Windows Update Behavior and the 3 Day Delay

March 20, 2014 13 comments

So let’s assume for the moment, that you’re a guy trying to work on some pretty detailed WSUS update deployments for a mixed OS network. This network will included some Windows 2012 and Windows 2012 R2 servers. You configure your WSUS server to auto deploy updates at some time – let’s say Sunday at 3:00AM. Then you check on Monday and realize that some of the servers still have a > 24 hour uptime, so updates must not have installed. You get busy, forget about it thinking the updates failed, and go about your day.

Then Wednesday morning you identify that some of the servers restarted at 3AM. Which is odd, because you didn’t do any maintenance. So something must be broken, now we need to investigate.

Hello, Microsoft KB2885694. It seems in this KB, they’ve released an update to allow 2012/2012R2/8/8.1 to have a more controlled update experience. Gone are the “we’re restarting in 15 minutes” that is non-cancellable. Now what you can do is create a schedule maintenance window, and allow things to happen IN that window. So you’ll install updates and wait for that window to reboot. That might be when you deploy other software as well. Or do weekly reboots. Or just stop monitoring the system to send alarms. Either way, it’s a quasi-good thing. Unless you’re EXPECTING it to do what it has done in Windows 2003/2003R2/2008/2008R2.  If you’re not in an environment that does a lot of patches, or doesn’t do them regularly, and have only recently added 2012/2012R2 systems, this may catch you off guard. 

The body of the text on this is:

KB 2885694 introduces two main changes that define how Windows Update on Windows 8 and Windows Server 2012 computers can be configured using group policy. All policies mentioned are located at this path:

Computer Configuration / Administrative Templates / Windows Components / Windows Update

When enabled with a value of 4…

The Configure Automatic Updates group policy works identically to the Windows 7 / Windows Server 2008 R2 and earlier behavior.

On Windows 8 and Windows Server 2012 without KB 2885694 installed, that policy could configure the main automatic updating setting, but configuring the scheduled install day and time had no effect. After installing KB 2885694, the policy will enable you to configure machines to:

  • Install updates during automatic maintenance, the default behavior, or
  • Install updates at the scheduled day and time defined in the policy

A new group policy called Always automatically restart at the scheduled time enables restarts soon after updates are installed, instead of 3 days later

Also, in the link for is the following important nugget:

However, the scheduled day and time in this policy setting has no effect. The computer still installs downloaded updates during automatic maintenance, which defaults to 2:00 AM. Additionally, the computer no longer restarts 15 minutes after installing updates. To help avoid unintended data loss, a restart timer instead begins 3 days after updates are installed, and only when you are actively using the computer and are able to see and react to the restart timer.

Let’s talk about that last bit “only when you are actively using the computer”. This means the timer MAY NOT START, until an interactive login happens. So no one logs in until Tuesday afternoon at 2PM. All well and good. But THEY don’t know about this process, and they ignore the message. Guess what happens on Friday at 2PM? That *IS* 3 days later after all…

That would be good to know. So you have a few options:

1) Install the update(s) and get understanding of the options, making it more “Windows 2008R2” ish.

2) Deal with the new method, and create some process that automatically restarts during maintenance

3) Create a process that will watch for a “RebootPending” status and when found, reboot. Obviously this has some danger to it, if you try to do this anytime. But if you do it just say “Sunday from 3:00-5:00AM” you’d probably be fine. Until you tried to do mass updates on say a Quarterly Outage on a Friday night at 8:00PM and couldn’t figure out why 30% of your servers aren’t updating.

So for now, my suggestion would be to move towards the Windows 2008R2 method. Likely, you need to do that anyways, as you have a mixed OS fleet to support, so accept the lowest common method. Note though, that’s not as simple as you’d think So – how do you DO that? The same link ( indicates how – but you have to read it carefully:

An update is available that lets you control how the Automatic Updates client applies updates in Windows 8 and Windows Server 2012. After you install this update, the "Configure Automatic Updates" policy setting will work again as it used to in previous Windows operating systems. Instead of installing updates during the daily maintenance cycle, Windows updates will be installed at the time and day that are scheduled in the "Configure automatic updates" policy setting.  
This update also introduces the following Group Policy setting that you can configure to force the computer to automatically restart sooner in order to finish installing important updates:

Computer Configuration\Administrative Templates\Windows Components\Windows Update\Always automatically restart at the scheduled time

Update information

To obtain this update, install update rollup 2883201. For more information about how to obtain this update rollup package, click the following article number to view the article in the Microsoft Knowledge Base:

2883201 Windows RT, Windows 8, and Windows Server 2012 update rollup: October 2013

What’s that you say? Your WSUS server is 2008 R2? And your domain/forest is 2008 R2? And you edit your GPO’s from a DC or the WSUS server? Guess what – you’re never going to see the 2012/2012R2 based GPO settings to enable them!

So what you need to do:

· Start modifying GPO’s on the HIGHEST level OS you have. A generally good practice

· Apply update 2883201 to that system

· Modify the GPO

· Apply update 2883201 to ALL your 2012/2012R2 based servers. (What you thought it would be as simple as updating the GPO editing machine? They won’t know what to DO with the updated GPO until they get the update that says that they should use that information to do it the Windows 7/2008R2 way….)

So there’s a fun little catch-22. In order to get control over your updates on your Windows 2012/2012 R2 systems via WSUS/GPO, you need to deploy an update that you’re having issues deploying, to tell it how to deploy updates.

On the plus side, looking at WSUS reports in this environment:


It looks like all the systems have it. So now we just need to go edit the GPO’s on a 2012 R2 system.

So let’s look at how this appears different:

2008R2 based Group Policy Editor:


2012R2 based Group Policy Editor:


2012R2 based Group Policy Editor:


Well that doesn’t make any sense, no new settings. But why?


“Administrative Templates: Policy Definitions (ADMX files) retrieved from the central store”. That means the ADMX files are being loaded from AD, and NOT from this machine. If you haven’t PUT the updated ADMX files on the Central Store… then it’s not going to work.


Policy Definitions (ADMX files) from 2010 likely isn’t going to help us much in 2014… If you go ahead and get: for the Windows 8.x/2012 ADMX templates, you can update the central store. Note that sometimes some of the ADMX files remove options that used to exist, so consider this when you’re blindly copying in ADMX files that might overwrite others. Unpack the files to a location – on a Windows 7 system this will go to C:\Program Files (x86)\Microsoft Group Policy\Windows 8.1-Windows Server 2012 R2\PolicyDefinitions. Then you want to take the WindowsUpdate.ADMX file and copy it to \sysvol\\Policies\PolicyDefinitions\">\\<domain>\sysvol\<domainname>\Policies\PolicyDefinitions\ Do the same for the ADML (language) file, but put it in \sysvol\\Policies\PolicyDefinitions\en-US">\\<domain>\sysvol\<domainname>\Policies\PolicyDefinitions\en-US. Close and re-open the Group Policy you were editing, and go back to the Windows Update node:


Look who decided to come to the party. Also note there is now an option for completely blocking the “Check for updates directly from Microsoft Update”. This isn’t relevant to our topic, but worth calling it out as an additional update. Set this to ENABLED and set a time (Default and minimum is 15 minutes), and save your Group Policy.

Now, if you’re looking to identify if this is working, you’ll want to look at the C:\WINDOWS\WINDOWSUPDATE.LOG on your Windows 2012 servers:


Here you can see we have a server that has installed updates, and is setting the timer for a few days from today (2014-03-20). That’s no good. So let’s do a GPUpdate /force on the system, and a WUAUCLT /UpdateNow and see what it says. If you’re using something like my WSUS_FORCE.BAT to push the updates and restart when the registry key indicates there is a restart pending, you’ll see:


Here you can see right before that, at 1:40:21AM, that Windows Update indicated a restart was required. The reboot in question only took about 15 seconds to complete. This allowed the post restart updates to install and finish. We now show no required updates on the VM.


This matches with what WSUS indicates as well for FSRVCLOTEST6.

So the key takeaways here:

· When introducing a new OS to your environment, such as Windows 2012 or 2012R2, make sure your GPO’s are updated to allow for it.

· Even if they are, be aware that updates can change the behavior of previously known systems.

· Only ever update/modify/edit GPO’s with the MOST RECENT OS in your environment, using the MOST RECENT ADMX files.

· Before blindly copying over the entirety of the ADMX/ADML files, test and confirm you’re not modifying any required settings. Remember you might be support Windows 2003 or 2000 still or Windows XP on the client side.

· Be careful selecting any new features from the latest GPO’s and ensure you check for backwards compatibility. Most GPO settings will tell you the minimum/oldest OS that is supported for that setting.

· Using the above modifications, you can not only be certain that Windows 2012/2012R2 systems will reboot during scheduled/automated maintenance, but also during situations where you are brute force pushing out something like a WSUS_FORCE.BAT which will look for new updates and install them immediately.

HOWTO: Using GPO Enforcement and GPO Modeling

September 24, 2013 Leave a comment

We recently had a need to apply one-off GPO settings to all servers in TST to override any other WSUS settings for a one-off force update of all servers.   This seemed like a good time to document this procedure and share it with those learning GPO’s in general.

First, let’s understand the WSUS GPO Structure I have put in place:


What we have here is 4 main WSUS OU’s under the SERVERS OU:

· WSUS-Servers-Automatic = those servers that will be automatically patched

· WSUS-Servers-Manual = those servers that will be manually patched, but need settings configured to point at the WSUS server, pre-download updates, etc.

· WSUS-Servers-PrimaryAutomatic – used for servers in NLB or Clusters where there are 2 or more servers, and they CAN be patched automatically – as long as they are done at alternating times.  In our case, I set the Primary for a Saturday operation.

· WSUS-Servers-SecondaryAutomatic – same as above, but used for the Secondary servers, and set to a Sunday operation – leaving a day between for checks and balances.


When we look at the GPO Management Console, you can see that each of the OU’s has the similar GPO linked.  Also the “WSUS-Servers-Manual” is linked to the parent “Servers” OU, so that all servers at a bare minimum get the “Manual” settings to configure to point at the WSUS server, do reporting, etc.    The important thing to note here is that for this one off event, I have linked “WSUS – Servers – Automatic” to the root of the SERVERS OU, and set it as “ENFORCED”.


This changes the icon on the object to show a padlock. 

To test this operation, what we want to do now, is run a Group Policy Modeling Wizard on any user and any server in the OU.  We do this by right clicking on Group Policy Modeling and choosing Group Policy Modeling Wizard:



Choose the DOMAIN you want to run against as well as the DC and click NEXT.


Choose the simulated user container and server container.  In our case, we can use the root of the domain as we want “any user” and we use the root of the SERVERS OU.  Check the box to Skip to the final page… and click NEXT, and then NEXT and then FINISH.


When the modeling wizard completes, we can see the summary.  If you expand the GROUP POLICY OBJECTS and then the APPLIED GPOs, you can see which GPO’s were applied.  Here we can see that BOTH “WSUS – Servers – Manual” and “WSUS – Servers – Automatic” were applied.  This is great and all, but WHICH settings were applied, as they have conflicting settings?  Click on the SETTINGS tab…



The important thing here is the “WINNING GPO”.  It will TELL you not only which GPO won, but show you the setting(s) that it applied.  So we can confirm that the “WSUS – Servers – Automatic” will apply to all servers in this OU.

If we go back to the GPO where it is linked and uncheck ENFORCED, we can come back to the Group Policy Modeling Wizard.  Because it was previously run, the settings are saved and you can right click on this Model and re-run it with the current settings – very handy if you have to test specific sets of groupings very often.



Here we can see that at least for servers in the SERVERS OU, the “WSUS – Servers – Manual” GPO will apply.  This is normally what we want – the SERVERS OU, unless a server is in one of the sub-OU’s, should only be MANUAL, and be “3 – Auto Download and Notify for install” – which is exactly what we see.

So we have a great way to force these settings, one time, to all SERVERS in the SERVERS or sub-level OU’s.  This is a great time saver.  But what if we were told that one of the servers should NOT be patched?  Now we have a logistical issue.

Right click on the GPO in question, and choose EDIT:


NOTE that in our example, it is STILL set as ENFORCED! 

Right click on the GPO, and not the COMPUTER or USER configuration, and choose PROPERTIES:


(You’ve probably never thought to right click on this object J)

Click on the SECURITY tab:


Click on ADD:




Select COMPUTERS and click OK


Enter the name of the SERVER(S) to be DENIED and click CHECK NAMES which will underline the servers and then click OK.


Ensure you’ve selected the SERVER(S) and in the PERMISSIONS choose APPLY GROUP POLICY and select the DENY option.  Press OK.


The WINDOWS SECURITY message is in fact true – DENY takes precedence.  This is what we want, so click YES.  Close the GPO you’re editing.

Now let’s return to the GROUP POLICY MODELING and let’s create a new model.  Right click and choose GROUP POLICY MODELING WIZARD:



We’re still going to select the root of the domain for the USER, but for the COMPUTER instead of a Container (OU) we’re going to select the SPECIFIC computer object.  You can use the BROWSE button to do so.  Click NEXT after checking the “Skip to the final page” option.


Here you can see:

· Group Policy Modeling clearly shows I’m testing COMPUTER=FSRVTSTDB1 against all users in FOCUSCORPTEST.

· The WSUS-SERVERS-AUTOMATIC GPO linked to the SERVERS OU is in fact still set to ENFORCED – which should make it apply to ALL SERVERS

· The Winning GPO was NOT “WSUS-SERVERS-AUTOMATIC” – because that OU doesn’t allow this server to apply it, based on the security we have set.

This seemed like a really good place to show practical examples of:

· GPO Inheritance

· GPO Conflict Detection

· GPO Enforcement

· Group Policy Modeling usage

· Security filtering on GPO’s to allow/deny them to be applied. 

o This is also a really good way to set settings for USERS but exclude certain members.  Examples could be “All employees, except Managers” or “All employees get these visual settings, except employees requiring visual aids, who can choose their own video settings accordingly”.

Hopefully this helps someone in the future, especially those studying for the 70-680 exam and are presently working on GPO’s in general

Categories: GPO, WSUS

Creating a WPA2-EAP Wireless Network with NPS, AD CS, and GPO

May 26, 2012 8 comments

I have had to deal with some networks in the past where wireless was perhaps not treated with the proper amount of concern.  I know of at least a few where the basic premise to security is just a WPA2 password – that hopefully the users don’t know.  It can’t be changed regularly because you’d have to communicate this change out to everyone.  A user with local administrator rights and Windows 7 can simply check the “show password” box on the WPA password settings, and it will show them.  Compound this with not changing passwords when a user leaves the company and you leave a fairly big hole in the side of your network.  Even worse is relying on MAC security, as this can be spoofed just by sitting there long enough and watching the packets go by and picking a MAC you want to use.

So what’s the solution?  WPA2-EAP using RADIUS, SSL via an Active Directory Certificate Authority, and GPO’s.  The general overview of what you are wanting to set up here and wanting to accomplish, is this:

  • The computer must be a domain computer and trusted.
  • The computer will, via GPO, auto-enroll for a computer based certificate.
  • AD CS will provide said certificate.  This will allow for the computer to be trusted beyond simply its SID or hostname, etc.
  • Wireless settings will be pushed out to all systems via GPO.  No one wants to go to 20 computers and enter a new SSID or configuration.  This should be automatic.  If you add a new access point or a new office, it should publish to the computer (assuming you want this – you might want to use security groups to limit who can use what AP’s in what locations, etc).
  • We don’t want users messing with the wireless settings at all.
  • There should be no password for a user to share, shoulder surf, remember, etc.
  • The user is not what we’re trusting but the computer.  This prevents the user from finding a way to use their credentials to authorize a non-domain computer by sharing, and walking away.
  • Because the computer is authenticating, it is connected as soon as the WiFi is available at boot up, even before the login.  This means that GPO’s and software deployments, etc, can be taking effect even if the machine sits at the login screen.  Contrast this with the situation where the user must login using cached credentials, then connect to the network, and then run any of these tools.  Also, a user who has no cached credentials from a previous login, can login and create a profile.

So some pre-requisites and reference links:

  • You’ve configured an Enterprise PKI for your network similar to how I have described before – Enterprise CA PKI for Domains – 2 Tier, with Root & Subordinate
  • A handy primer on how to do this –
  • WAP’s capable of using WPA2-Enterprise and RADIUS (my Netgear WNDR-3700v2 with DD-WRT will)
  • Create any groups in AD if you want to restrict access to certain computers or users in your domain.  The most likely reason you would do this is if you wanted to create say a “grpAllowedWiFi-OfficeName” per office, and then you chose which computers had access to which office.  I’m going to assume here that we are giving access to the entire network from all domain computers, as this is probably most likely.

And now the steps – there is very little that is different from the SpiceWorks HOWTO post by Tino Todino.

1) Configure your Wireless Access Point.

We’re going to do this with a DD-WRT device, as this configuration should translate well regardless of device and if your device doesn’t do it, you might be able to use DD-WRT devices to deal with this.



I have created a Virtual Interface for this access point, so that I can do this testing in parallel with what I already have in place.  Set it as an AP and give it a name – case matters, and you may want this SSID to be generic through your infrastructure.  I have also chosen to not broadcast the SSID.  This is security through obscurity, but every little bit helps.  Plus because we are going to publish these out to computers via GPO, we don’t have to worry about end-user usability.   Click SAVE/APPLY CONFIGURATION.



Security mode is going to be WPA2-Enterprise.  WPA Algorithm we’ll set to AES (TKIP I understand can be cracked).   Enter the IP’s and shared secrets of your RADIUS servers.  This shared secret will be used later.   Click SAVE/APPLY CONFIGURATION.

The Wireless Access Point is now configured.

2) Install NPS on the server

I already had NPS installed, but if you followed my setup, you only have the Network Policy Service installed and not the Routing and Remote Access Service

3) Set up RADIUS clients on the NPS

Open the NPS console on the NPS server.  Expand RADIUS CLIENTS AND SERVERS –> RADIUS CLIENTS.  Right click and choose NEW.


Enter the friendly name of this WAP, the IP, and the Shared Secret and click OK.  If you have multiple AP’s, repeat this process as needed.

4) Configure 802.1x on the NPS server

In the NPS console, click on the root NPS (Local) option.  On the right hand side from the drop down select “RADIUS server for 802.1x Wireless or Wired connections”.   Then click the green arrow beside “Configure 802.1x”.


Select “Secure Wireless Connections” and give it a name.  I’ve named mine “NetWise – Secure Wireless Connections”.  Click NEXT.


Select the RADIUS client(s) you want to use this configuration.  To be fair, you could have also added the client here as well I just realize.  Click NEXT.


Select Microsoft: Protected EAP (PEAP).  Click CONFIGURE.


In my case, my primary RADIUS server also happens to be my Exchange server (I’ll get around to fixing that some day…..).  As such, it has more than one SSL Certificate present.  Select the one for the RADIUS server itself, which will be the one showing the FQDN.  Also it will show “Issued:” by your internal AD CA, vs an external 3rd party.   Click OK


Click NEXT.

This is where you would configure USER groups.  Note that this is not groups of Computer objects, so this is not where/how you would restrict ComputerA from using the WAP in CityQ for example.  Click NEXT, as we’re not adding groups in the scope of this document.


On the Traffic Controls screen, click NEXT.


On the last page, you’ll see confirmation that we have created both a Connection Request Policy and a Network Policy.  Click FINISH.


5) Create a Certificate AutoEnrollment GPO.

  • Open the Group Policy Management Console
  • Either create a new GPO or modify an existing one.  I’m choosing to modify my Default Domain Policy as I want this to affect all my computers.  You might choose to create a new one so you could link it to OU’s or computer groups as desired.
  • Under Security Filtering, you would remove the “Authenticated Users” and add in the Computer/User groups if you wanted to do it that way.
  • Edit the GPO (Right Click –> EDIT)
  • Right click on “Certificate Services Client – Autoenrollment” and click PROPERTIES.
  • Change “Configuration Model” to ENABLED and check both boxes and click OK.
  • Right click on “Certificate Services Client – Certificate Enrollment Policy” and click PROPERTIES.
  • Change “Configuration Model” to ENABLED and click OK.
  • Close the GPO you’re working on to save it.  (I forget this so often, it hurts.)

6) Create a Windows Vista/7 Wireless 802.1x GPO.

  • Edit the GPO in question.  It might very well be the same one from step 5 above.
  • Right click and choose “Create a new wireless network policy for Windows Vista and later release”.image
    Note: if you don’t see this, you might already have a policy configured for Vista.  If so, you will only get the option for the Windows XP policy.  But you can only have one of each per GPO.   This could be a good design reason to want to keep the GPO’s with the policies separate from your Default Domain Policy, if you are intending to have a configuration that is not standard across the board.
  • Give your policy a name and a description, and then click ADD –> INFRASTRUCTURE.
  • Give your profile a Profile Name (ie: NETWISE CORPORATE).  Type in the name of your SSID and click ADD.  I have to assume you could put in multiples here if perhaps your SSID’s were setup like NW-<CITY> or NW-<LOC_CODE>, etc.
    Check all 3 boxes: “Connect automatically…”, “Connect to a more preferred….” (more on this later!) and “Connect even if….”.  Click the SECURITY tab.
    Click PROPERTIES next to (PEAP).
  • Check the box for “VALIDATE SERVER CERTIFICATES”.  Check the box for “CONNECT TO THESE SERVERS:” and enter the FQDN name(s) of your RADIUS servers to use for this policy, separated by a semi-colon if needed.  In the TRUSTED ROOT CERTIFICATION AUTHORITIES list, find and check the certificate for your Enterprise Root CA.
    Click OK twice to return to the 802.11 Wireless Network Policy Properties window.
  • Click on the NETWORK PERMISSIONS tab.
  • If you want to get more granular, this is where you have some greater control over the wireless settings on the client.   Some specific options:
    • You can click ADD and enter an Infrastructure/Ad-Hoc SSID and choose to allow or deny.  This is where you might add a known public SSID that you don’t want users to use (ie: “Linksys” or “Starbucks” or something.).
    • Check boxes for “Prevent connections to ad-hoc/infrastructure networks”.
    • If you’re going to prevent said access, then you might want to uncheck “Allow user to view denied networks” – this would make them simply not show up at all.
    • “Only use Group Policy profiles” locks the WiFi lists on the client down to ONLY what you have configured in Group Policy – they cannot add anything additional.  This seems pretty drastic, but it is a nice option to have.
  • Click OK
  • Close the GPO to save it.

7) On a client that might already be connected via a WPA2 configuration or wired, refresh the group policies (gpupdate /force) and let it run.  If you have to log off or reboot, do so.


Once it applies, you’ll see that your new options are present.  Do note that you see the wireless configuration friendly name “NETWISE CORPORATE” vs the SSID of “NETWISE-ENT”.  Also, because of the check boxes when creating the GPO Wireless Policy of “Connect to a more preferred network….” you will note that I’ve stayed connected to my 802.11n 5GHz AP/SSID vs switching over to NETWISE CORPORATE automatically.  Depending on your environment, you may then want to modify this in the GPO.  Perhaps your office is next to a Starbucks and maybe they even have better signal strength on that side of your office.  This setting would tell the computer to connect to the corporate network any time it is available.

8) Troubleshooting.

Are you seeing this: image

Remember the part where I said the NPS I was on had more than one SSL certificate?  If you pick the wrong one, and the FQDN and such don’t match, you’re going to get this error.  To remedy it:

  • If you’re working wirelessless, you should TERMINATE and connect to either another WPA2 based SSID or a wireled link.
  • Connect back to your RADIUS/NPS server(s)
  • In the NPS console, click on POLICIES –> NETWORK POLICIES.  Select the Secure Wireless Connections policy (with the appropriate name) and right click and choose PROPERTIES.
  • Click on the CONTSTRAINTS tab
  • Select the EAP type listed (there should be only one) and click EDIT.
  • On the EAP Protected EAP Properties window, ensure that Certificate Issued: is showing the FQDN of the server as entered in the RADIUS properies previously and shows ISSUER: as your Enterprise Root CA.  Click OK twice to finish editing.
  • Do this on both (or more) of your NPS/RADIUS servers
  • Retry your connection.

Now, to wrap up.  Once you’re connected if you want, you can right click on the connection in the WiFi list and choose PROPERTIES:

You will note that everything is grayed out and un-modifiable:


So what we have is exactly what we set out to get.  No WPA2 passwords that can be shared.  We’re using PKI/SSL/ADCS/GPO to deploy the security so no one ever has to touch the machine(s).

Its been a good day Smile

Categories: ADCS, GPO, PKI, RADIUS, SSL, WiFi

Enterprise CA PKI for Domains – 2 Tier, with Root & Subordinate

May 19, 2012 3 comments

I’ve been fighting with wanting a PKI working in my environment for a while.  For all the typical reasons:

  • Required for 802.1x WiFi authentication
  • Required for 802.1x Wired authentication
  • Required for RADIUS
  • Required for IPSEC between domain systems
  • Required for internal web sites that have SSL based traffic without a 3rd party SSL including:
    • Actual web sites – ie: those hosted and created on IIS/Apache
    • Application/utility web sites – ie: Open Manage (OMSA, IT Assistant, OME, etc), Veeam Enterprise Manager, etc.
    • Hardware with administration pages – ie: Juniper ScreenOS/SSG, Dell PowerConnect switches, Dell iDRAC, Digi CM32, etc.

I finally got around to finding a way to make it work.  I don’t propose that this is 100% functional at this point, but it’s working. I also don’t suggest that this is ideal – there likely is a better way.  By all means – let me know if there is!  Thanks in advance.  I cobbled together a little here and a little there and made it functional for me.  I’m sure there is more to do…..

With that said – the meat of this post…..

Would you like to know why companies don’t have PKI infrastructures?  Because it is FRUSTRATING AS HELL.  Wizardry might be easier.  Seriously, I could make dragons teleport in and breath flaming acid on Orcs easier.

Okay, so here is the VERY high level of what you want to know:


1) Best link to get started:

a. READ IT VERY FREAKING CAREFULLY.  There is a lot of stuff that if you skim it, you’re missing some CRITICAL stuff.  Or if you think you know better, you’ll mess it up – and realize why in step 43.  For example:

· “Log off the Subordinate CA”.  “Log onto the Root CA, do blah blah”.  “Log off the root CA”.  “Log onto the DC and edit the GPO to include the certificate”, “Log back onto the Subordinate CA”


o You’re logging OFF the first box, so that after you modify the GPO, you’re re-processing the GPO when you login.  If you don’t, the stuff you added to the GPO isn’t there!  Go figure.

o If you don’t log off the DC after editing the GPO, there’s a good chance you didn’t close the GPO.  Or save it.  Or set it up to push out the next pass.

· Think about your naming.  You will NEVER be able to change it.

· I have NO idea how to do any sort of dual server clustering of your Subordinate CA’s.  You will almost certainly want some HA of it, especially in a corporate environment

2) After you do the above…. Now what?  There’s no good details on how to TEST it.  You also haven’t added in the Web Requestor, the Network Device Enrollment, etc.  We’ll get to that.

3)– this is a great resource.  Not just this link, and this 5 part series, but in general.  Read it a few times.  Digest the information.  Let it sink in.  Read it again.  Then realize it is NOT digested.

4) Go find a computer.  Go login as a member of ENTERPRISE ADMINS.  Start MMC, add the CERTIFICATE option and choose COMPUTER -> LOCAL COMPUTER.



b. Look at that – we have some options.  All we care about (and that you’ll have at this point is COMPUTER and *maybe* IPSEC.  Click COMPUTER and NEXT.


c. OOOH!  Look at that!



d. I bring to you – certificates!  It works!


5) Sooner or later you’re going to want to create a certificate request.  I can’t seem to do mine via the MMC – because I was getting the error shown here:

Rather than fight with it, I have accepted Dave’s Solution.  Smile  It works fine for me, I’ll cope for now.  This is a “to be fixed” thing though for me.

6) – you’re probably going to set it up like me so it uses Domain Credentials and Trusted Computer to do enrollment.  Think about that for a second.   That works GREAT if your computers are all Windows, and all Domain Joined and all Local.  Now how are you planning on getting a certificate for your Juniper Router, at a remote site, that isn’t connected with a VPN because of DMZ?  How is your user going to request a Cert for DirectAccess, when he’s off network, and trying to setup for the first time?  There are a LOT of VERY LONG TERM design issues to think about here.  For now, I’m stumbling.

Categories: AD, ADCS, GPO, PKI, SSL