5/27/2016

SecureAdministrativeWorkstations|AskPremierFieldEngineering(PFE)Platforms

Server & Tools Blogs > Server & Management Blogs > Ask Premier Field Engineering PFE
Platforms
Sign in

Ask Premier Field Engineering PFE Platforms

Secure Administrative Workstations

March 14, 2016 by BrandonWilson // 3 Comments

0

15

Hi All. This Jerry Devore a Midwest PFE back after a long hiatus from blogging.
If you thumb through the owners manual of your car you will find a maintenance schedule section. There you
can see how often the manufacture suggests you should change your engine oil, flush your radiator fluid and
replace various filters. Any well trained auto mechanic will whole heartily agree with those recommended
intervals. However, if you can get one to be completely honest you will likely find his own engine is currently a
quart low on oil and his check engine light has been on for the last year. IT Pros can be the same way when it
comes to security. We know all of the best practices and are quick to tell others how they need to change their
habits in the name of security. In reality though it is easy to let our guards down and occasionally take shortcuts
which can put our systems at risk. That is why your elevated accounts should be restricted to logging on to
Privileged Administrative Workstations PAW. With the correct hardening setting applied to a PAW, credential
protection is not dependent on personal discipline.
Before we get into how a PAW should be configured it helps to put into context where a PAW fits in with the
other devices on your network. One of the key principles promoted in the Microsoft Pass the Hash whitepapers
is that accounts and devices should be grouped into a Tier Model so that the trust level of the device is
consistent with privileges used to operate that device. In other words, you should not log on to a device that is
less trustworthy that than the account you are using. While you could easily get carried away with defining
multiple levels of trust, Microsoft uses a three tier approach which is often sufficient and is easy to visualize.

[Link]

1/10

5/27/2016

SecureAdministrativeWorkstations|AskPremierFieldEngineering(PFE)Platforms

Tier 0 is the top of hierarchy and is where control of the environment resides. The most obvious Tier 0
resources are the domain controllers because once they are acquired, an adversary has everything needed to
access all other resources. Tier 0 also includes anything that can be used to gain control of those domain
controllers such as the SCCM servers or other agent based management tools.
Tier 1 encompasses the applications and data. This is truly where the adversaries want to get to because it
contains the information which can be sold or otherwise used for nefarious purposes. The credentials use to
manage Tier 1 should be contained to that tier so if they fall into the wrong hands elevation to Tier 0 is not
possible.
Tier 2 is the bottom of the hierarchy and contains your least trusted devices. This is the level where your
everyday workstations live. The accounts used to administer this level should not have admin access to the
servers. The sad reality is that every organization can pretty much expect that an adversary will gain control of a
few of these devices. That is why the PtH whitepapers include several mitigations to prevent lateral movement at
this level.
So since a PAW is a workstation does that mean it is a Tier 2 device? Not at all. Because highly privileged
accounts will be used on them they must be regarded as a Tier 0 devices for domain administrator accounts and
as a Tier 1 device when used by application server administrators. If you understand the nature of a Pass the
Hash PtH attack, then you know that an interactive logon can leave password hashes resident in LSASS
memory. Thanks to publically available tools a very low skilled hacker can harvest and utilize those hashes
regardless of the password length or complexity. But what about the highly disciplined administrator who
launches all management tools with Run As and never logs on interactively with an elevated account? I hate to
break it to you but Run As also places a hash of your NTLM credential in LSASS memory. Beyond credentials
stored in LSASS memory, we also need to be vigilant against malware based keyboard loggers. Therefore, we
[Link]

2/10

5/27/2016

SecureAdministrativeWorkstations|AskPremierFieldEngineering(PFE)Platforms

should not get caught up on where the credential is stored but rather focus on the trustworthiness the entire
device. We sometimes refer to this as having a clean keyboard.
Getting Started
So now that we have defined the purpose of a PAW, how do you get one? Simple. Microsoft Consulting Services
MCS has an offering which will design, document and build you a PAW environment. The end result will be a
turnkey solution which encompasses the latest Microsoft best practices. If letting MCS lighten your load is not in
the budget for this year then you will want to check out the PAW documentation Microsoft recently published. It
does an excellent job of explaining the concepts and configuration steps. However, it is not a quick read so here
are my Cliff Notes to get you started.
1. Use verified media to ensure a clean build I know what you are thinking but I am not wearing a tinfoil
hat as I type this. The creation and deployment of your PAW could require hundreds of manhours and we are
approaching it from an Assumed Breach position. All of that effort would be of no value if you used media or
downloads which have been compromised. To ensure your bits are pure, acquire them from different sources
then compare their hashed values and make sure they match.
2. Apply a hardening security baseline from Microsoft Security Compliance Manager SCM. SCM
templates contain a plethora of information based on Microsoft best practices. The Security Compliance
template will let you implement all of those recommendations with a few clicks. It can also be used to quickly
compare your general workstation and server GPOs to the documented best practices
3. Enable Secure Boot. This will ensure that bootkit software cannot modify your system and allow malicious
code to operate at a level too low to be detect by common AV products. Keep in mind that Secure Boot requires
UEFI which needs to be enabled on the machine before installing the OS.
4. Impose Software Restrictions using AppLocker. Once you deploy the PAWs you want their configuration to
remain unchanged. AppLocker can help enforce that by blocking malicious or unapproved applications
5. Enable Full Disk Encryption. This will ensure that offline manipulation of the device is not feasible. It will
also protect any local data if the computer ended up in the wrong hands
6. Impose restrictions on USB ports. I have witnessed this being achieved by physically damaging the USB
ports. A more refined approach is to use policies to disable USB for media use. That will allow you to continue
to utilize other types of USB devices such as keyboards, mice and headsets.
7. Implement Network Isolation via host firewall. Start by blocking all inbound connections and make
exceptions only if absolutely necessary
8. Install and configure the Enhanced Mitigation Experience Toolkit EMET. EMET stops zeroday exploits
by blocking many of the functionalities utilized by malicious code. While implementing EMET can cause
application capability issues, a PAW should have very little software installed on it. You should be able to enable
all of the default protections offered by EMET without any negative impacts
[Link]

3/10

5/27/2016

SecureAdministrativeWorkstations|AskPremierFieldEngineering(PFE)Platforms

9. Windows 10. A good description of the Windows 10 security features can be found at
[Link] Many organizations have not adopted
Windows 10 yet so there may be a tendency to stick to the officially standard client OS. The PAW will not be
supported in the same manner as your regular desktops and the security enhancement in Windows 10 are too
important to pass up. This is not a time to hang back in order to be compliant with company standards.
10. No Internet access from a browser. While PAWs are hardened and patched devices there is no need to play
with fire by using them to browse web pages. Highly managed environments might be able to impose this
limitation at the proxy servers. Those who dont have that amount of control can simply configure a bogus proxy
server address in the browser.
11. Minimal Software. Each installed product introduces the opportunity for vulnerabilities and blurs the lines
between the purpose of your regular workstation and your PAW. Keep focused on the fact that a PAW exists as a
way to securely logon with elevated credentials and access equally secure devices. It is not intended to be used
for documentation, reading email or updating change control records. The use limited to administrative tools
i.e. RSAT and support scripts however is considered acceptable.
12. Minimal Administrative Accounts. For obvious reasons a PAW should not be operated with an account
which is a member of local administrators. Additionally, the PAW owner should not have a secondary account
with administrative access. Having such a back door makes it too tempting for the owner to fix flaws they
perceive in the PAW configuration.
13. Hardened OU. The PAW computer accounts should be segregated into their own OU. The security applied to
that OU needs to be strictly limited and audited to ensure access to the PAWs cannot be gained by anyone not
responsible for PAW support. In addition to the PAW documentation, Microsoft has also published scripts to
implement and harden these OUs.
Support model
Developing and deploying a PAW will look nothing like your standard workstations. In order to maintain them
as Tier 0 devices the management tools and staff used use support the normal workstations cannot be leveraged
for the PAW. Without a wellplanned strategy it would be easy for the PAWs to end up in a state of limbo when it
comes to support. While designing your solution make sure have carefully considered:
Patching strategy
Antivirus updates and monitoring
Auditing and event forwarding
Hardware Repairs
If you have a limited number of PAWs it is difficult to justify implementing a comprehensive management
solution. Relying on manual support processes might need to be used. Just make sure you are not neglecting
[Link]

4/10

5/27/2016

SecureAdministrativeWorkstations|AskPremierFieldEngineering(PFE)Platforms

the maintenance required to preserve their integrity.

Form Factor
In an ideal world the PAW devices would only reside in a secure room and never be exposed to the general
network let alone leave the building. However, in the real world we are rather fond of work from home
arrangements and being able to provide oncall support without spending the weekend in the office. As a result,
form factor should be considered when designing your solution. Here some options to consider:
Secondary laptop The most isolated approach is to provide your administrators with a second device. Given
this results in them lugging around two laptops it would be best to use compact hardware for the PAW. A
Surface device would be great fit given they are very portable and provide the necessary security features UEFI,
TPM, Bitlocker, etc.
PAW with HyperV In this approach HyperV would be installed on the PAW and it would host a VM which is
used for standard workstation purposes Email, Web browsing, etc. Hosting a PAW VM on a standard
workstation is not considered a viable alternative because a keyboard logger resident on the standard
workstation could capture credentials when logging on to the PAW VM.
PAW with VDI This is very similar to the HyperV model except the standard workstation VM is hosted in your
data center. This might not be as convenient when working remotely given a connection to the data center will
be required in order to utilize standard workstation functions. However, it might be much easier to support than
running a VM on top of a laptop.
PAW with Jump Server This approach closely parallels the VDI solution and is often used where network
segmentation exists. Jump servers allows you to consolidate the management of support tools so the PAW
configuration can remain simplified. Keep in mind that these hardened servers are Tier 0 resources and would not
be supported in the same manner as other terminal servers.
Enforcing Use
Once PAWs have been deployed to all administrators you are done and ready to close out the project right?
Nope. We have not solved the original problem of shortcuts being taken. Without enforcement you are still
depending on personal discipline to protect privileged credentials. So what are some ways to add teeth to the
design? I am glad you asked. Here are a few things you can implement to make sure PAWs are used for their
intended purpose:
1. Impose Deny log on polices via User Rights Assignment in a GPO. This should be applied anywhere the
account should not be used to log on. For Domain Admins, you should apply this restriction to all devices other
than Tier 0 computers such as Domain Controller and the PAWs. Keep in mind that if these setting are managed
in a local policy and a domain GPO, the GPO will overwrite rather than merge.

[Link]

5/10

5/27/2016

SecureAdministrativeWorkstations|AskPremierFieldEngineering(PFE)Platforms

2. Use IPSEC to impose device level restrictions that are otherwise not feasible using host or network firewalls.
For example, place the PAWs in a domain group then configure IPSEC polices so that only Domain Admins
logging from a PAW can make an RDP connection to the domain controllers. Such policies can be configured via
GPO so they are easy to centrally manage and enforce. Just make sure to test your policies in a lab because
misconfigured IPSEC settings will take devices off the network in a blink of an eye. Once that happens backing
out the GPO will not undue your RGE resume generating event.
3. Restrict where privileged accounts can interactively logon by defining devices in the Log On To field of the
account properties. As computer names are added they are written to the UserWorkstation attribute of the user
account

This feature has been with us since the beginning of Active Directory and it has some considerable limitations:
The field only accepts NetBIOS names so there is a 15 character limit
By default, the field only accepts 64 names. As explained in KB938458 it is possible but not recommended to
[Link]

6/10

5/27/2016

SecureAdministrativeWorkstations|AskPremierFieldEngineering(PFE)Platforms

expand that limit.

While the restriction applies to Kerberos and NTLM, both protocols rely on the workstation to provide its
NetBIOS name. A malicious user could manipulate the device to spoof the response and defeat the restriction
This restriction must be managed per user account. Even if you leverage scripting it could quickly get difficult to
manage.
Implement Authentication Policy Silos. Authentication Policy Silos were introduced with 2012 R2. They restrict
where accounts can be used by disabling NTLM and blocking the ability to acquire a Kerberos Service Ticket
unless the policy allows it. The prerequisites are a Domain Functional Level of 2012 R2 and Window 8 / 2012 or
higher operating systems. Authentication Policy Silos are the way of the future when it comes to restricting where
accounts can be used. Unfortunately, it will be some time before many organizations will be able to raised their
DFL to 2012 R2.
Now that you have the basics I hope you check out the published PAW documentation and start designing your
solution. This would also be a great time to review both Pass the Hash whitepapers to make sure your plan is
comprehensive in addressing current day threats to privileged credentials.
Jerry Devore, PFE

Search MSDN with Bing

Search this blog

Search all blogs

Share This Post

Tags

Active Directory ADFS Announcements Azure Best Practices Career Charity

Shelbourne David Gregory deployment Disaster Recovery DNS Doug Gabbard Doug Symalla Failover Cluster
Greg Jaworski Group Policy Hyperv Joao Botto Lab Lakshman Hariharan Mailbag

Mark

Morowczynski martin lucas Michael HIldebrand Networking Performance

PowerShell SBSL Security Server 2003 Server 2008 Server 2008 R2 Server

2012 Server 2012 R2 Tom Moser troubleshooting Upgrade Windows

[Link]

7/10

5/27/2016

SecureAdministrativeWorkstations|AskPremierFieldEngineering(PFE)Platforms

Windows 7 Windows 8 Windows 8.1 Windows 10 windows server 2012 r2 WPA Xperf
Recent Posts
Windows 7 SP1 and Server 2008 R2 SP1 convenience rollup now available at a download location near you!
KB3125574 May 20, 2016
Monitoring Service Accounts with System Center Operations Manager May 16, 2016
Preparing for DAC May 9, 2016
Installing Bash on Ubuntu on Windows 10 Insider Preview May 2, 2016

Live Now on Server & Tools Blogs

New: [Link] Session State Provider for SQL Server InMemory OLTP
Getting Started with Power Query Part I
Introducing Microsoft Azure StorSimple

Archives
May 2016 4
April 2016 4
March 2016 5
February 2016 5
January 2016 4
All of 2016 22
All of 2015 63
All of 2014 66
All of 2013 90
All of 2012 64
All of 2011 4

Tags

Administrator
Security

Administrators

Windows

auditing

Windows 10

Hyperv

Windows 2008 R2

Jerry Devore
Windows 7

NTLM

PAW

Windows 8

Windows 8.1

Join the conversation

Andrey

[Link]

Add Comment
2 months ago

8/10

5/27/2016

SecureAdministrativeWorkstations|AskPremierFieldEngineering(PFE)Platforms

Thank you for great article and useful links.

Fred

2 months ago

How does this work with the Security Baselines? Should we also apply the baselines?
[Link]
[Link]
Any strategies on convincing your IT users to implement this paradigm? Lot of resistance to any security initiative
like this that makes life harder for them to do their job
Thanks,
Fred

jkdevore

2 months ago

Fred The setting in the Security Baselines Aaron is referring to are covered with the
Security Compliant Manager SCM templates. As long as applying the template is in your plan, you have security
baselines covered. BTW, Microsoft recently released the SCM templates for Windows 10 v1511
[Link]
[Link]
Convincing members of your organization to adopt this strategy begins with making sure they are fully educated
on the nature of Pass the Hash based attacks. Many people have the selfsoothing believe that it could never
happen to us. FBI Director James Comey addressed that fantasy a couple years ago when said something to the
effect of There are two types of companies in the United States. Those who have been hacked and those who
dont know they have been hacked. Some statistic to help put things in perspective are: On average it takes over
200 days to discover such a breach, less than 10% of companies detect it on their own usually informed by an
outside party and once the first device has been compromised it take less than 48 hours for an adversary to
acquire a domain admin account.
Begin the process by focusing on your Tier 0 admins domain admins, enterprise admins, etc. Anyone with that
level of access should read and fully comprehend both Pass the Hash whitepapers. They should also understand
that this is not about a lack of trust with them personally but rather matter of trust in the devices where their
credentials are used.
Once the Tier 0 admins have been addressed you can start to turn your attention to the Tier 1 admins
applications and infrastructure servers. While these users do not need to understand PtH to the same level, it
certainly helps for them to understand the concepts so they are more supportive of the restrictions placed on
their accounts.
Aside from the PtH whitepapers here are some great resources to education your users:
[Link]
[Link]

9/10

5/27/2016

SecureAdministrativeWorkstations|AskPremierFieldEngineering(PFE)Platforms

TheftwithPOPSLAM
[Link]

2016 Microsoft Corporation.

Terms of Use Trademarks Privacy & Cookies

[Link]

10/10