- Interact with Azure Cosmos DB with PowerShell - Tue, Sep 14 2021
- Azure health services: Track Microsoft cloud outages and maintenance - Wed, Sep 8 2021
- Powerline: Customize your PowerShell console - Tue, Aug 31 2021
- Tip #1: Remember the Principle of Least Service
- Tip #2: Know exactly what your applications and services are doing
- Tip #3: Be Vigilant regarding the Everyone and Authenticated users groups
- Tip #4: Remember that network service authenticates as the Computer
- Tip #5: Use separate domain user accounts for services and applications
- Further reading
In my previous article, we defined services and service accounts and also examined what options there are for selecting a service account for use with a particular service or application.
Here we take that fundamental knowledge and put it in more of a practical context. In real world multi-tier Web application scenarios, a Windows administrator can quickly become overwhelmed in keeping track of which service account he or she used with which application or service.
Consider the following example diagram:
A typical multi-tier Web application topology
Think of how many service accounts we require in the preceding scenario:
- Client services (likely if the client is using anything beyond a simple Web browser to access the Web application)
- IIS services
- AD and related infrastructure services (DNS, DHCP, etc.)
- Application services (SharePoint 2010, for instance, requires an entire suite of service account-attached services and applications
- SQL Server services
- “Standard” Windows services (Server service, etc.)
What is a busy Windows systems administrator to do? Well, read on and I’ll tell you.
Tip #1: Remember the Principle of Least Service ^
The IT security principle of least service means, in a nutshell, if you don’t absolutely require a specific service, disable it. Just turn it off. By performing this action we not only conserve system and possibly network resources, but we also reduce the number of attack vectors a malicious user can employ to penetrate your network.
As you know, we can manage all aspects of Windows services by using either the Service Control Manager (services.msc) MMC console or (even better) through Group Policy. The relevant Group Policy path is \Computer Configuration\Preferences\Control Panel Settings\Services.
Managing services with Group Policy
Tip #2: Know exactly what your applications and services are doing ^
Microsoft does a fairly decent job of enumerating the system privileges and file system permissions that its enterprise applications grant automatically to service accounts. For instance, check out the following links and prepare to be surprised:
- SharePoint 2010 Account Permissions and Security Settings
- SQL Server 2008 R2: Setting Up Windows Service Accounts
- Exchange 2010: Roles, Rights, and Permissions
You need to remain ever-aware of any “out of the box” privilege escalation that your line-of-business applications grant to service account. The best way to do this is to keep a wary and scrupulous eye on the vendor’s documentation.
Tip #3: Be Vigilant regarding the Everyone and Authenticated users groups ^
Everyone and Authenticated Users are dynamic security principals, which means that their membership is controlled by your network environment itself and that we administrators cannot control membership to these group identities.
The Everyone identity includes all authenticated and unauthenticated network users (this includes Local Service, people).
The Authenticated Users identity includes all domain user and computer accounts who have successfully authenticated to Active Directory. This group includes the Local System and Network Service built-in service account identities.
Thus, our “take-home” message is to keep a careful eye on where and how we are assigning access permissions to these two special groups.
We can control which accounts have which system privilege by using Group Policy; the relevant Group Policy path is \Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment.
Managing user rights with Group Policy
NOTE 1: System privileges are also called user rights. Either way, we refer to system-wide abilities such as logging on as a service, logging on locally, changing the system time, and so forth.
NOTE 2: Be sure to exercise due diligence and perform research prior to making user rights assignments in Group Policy. We don’t want to inadvertently break LOB application access.
Tip #4: Remember that network service authenticates as the Computer ^
If you opt to associate the built-in Network Service service account to a network-aware service, be aware that when that service makes a remote connection, it does so under the security context of the “calling” computer account (not user account).
Thus, you may need to adjust the discretionary access control lists (DACLs) on relevant target systems to include an access control entry (ACE) for the calling computer.
Editing a DACL for an IIS Web application
Tip #5: Use separate domain user accounts for services and applications ^
The main reasons why I suggest that you use dedicated domain user accounts for service accounts instead of the built-in identities are as follows:
- By using domain user accounts as service account logons, you can more granularly audit access locally and across your network
- For applications that support them, managed user accounts (MSAs) enable you to use domain password policy with your service accounts
- A domain user account has unquestioned visibility throughout your entire domain and Active Directory forest
- Domain user accounts can be more definitively targeted with Group Policy
- Using domain user accounts consistently makes it easier to manage multi-tier application infrastructures
Speaking of Group Policy, you might want to ensure that your domain service accounts are denied the Log on Locally user right at the very least. This action will prevent a malicious user from succeeding in an interactive logon attempt by using a breached service account.
With regard to my final point about consistent use of service accounts, Microsoft recommends that you assign different service accounts to different services within each enterprise application. The thinking here is that an attacker would have to compromise more than one account to “own” your application.
The only “gotcha” with using multiple service accounts is the pure confusion factor that can happen if you deploy the service accounts with no consistency. To reduce the confusion, (a) store your service accounts in separate organizational units (OUs) in Active Directory; and (b) name the accounts in an intuitive manner.
In this lesson we learned some industry best practices for using service accounts in a Windows-based, multi-tier application infrastructure. To be sure, we have truly only scratched the surface of this behemoth of a topic.
Please feel free to share your own experiences, war stories, tips, etc. in the comments portion of this post. The Windows admin community deeply needs a vibrant yet solid knowledge base for this subject.