Controlling who can access your computers from the network and which users must be denied is a basic act in system hardening. Allowing users to access a computer from the network is sometimes critical for functionality, although usually at the price of decreasing security. Deciding who can access requires a gentle balance between security and functionality.
There are best practices that instruct who should be allowed and who must be denied but following them might negatively affect delegated tasks.
Note that there are different recommendations for users who access the computer from the network and users are denied access through the network. There're are also different recommendations to different machine roles (Domain Controllers, Member Servers).
This blog post will cover:
- Access this computer from the network - how to configure and the potential impact of the policy.
- Deny access to this computer from the network - how to configure and the potential impact of the policy.
- How to set access and deny access to this computer from the network without causing damage?
Access this computer from the network:
The policy setting controls which users can access a device from the network. Several network protocols depend on this setting. It is critical to secure this configuration, by limiting which users will have access, but it is important to generate an impact analysis before enforcing your rules.
How to configure the 'Access this computer from the network' setting:
The Potential Impact of This Policy:
System components such as ASP.NET and IIS servers might be impacted by this hardening action. Determine which user accounts need to have access to the network, for these components to continue working properly.
In addition, there are few network protocols that require access from the computer:
- Server Message Block (SMB) protocols
- Common Internet File System (CIFS)
- Component Object Model Plus (COM+)
Before changing this setting, make sure you're not using these protocols.
Deny access to this computer from the network:
This policy restricts user groups from connecting to a computer from the network. Not configuring this setting correctly will allow users to access and modify data remotely. It is recommended to use network servers for file sharing when needed.
Note! 'Deny access to this computer from the network' user right supersedes the 'Access this computer from the network' user right in case an account is subject to both.
How to configure 'Deny access to this computer from the network' setting:
End Point – Deny access from Anonymous logon, Built-in local Administrator account, Local Guest account, All service accounts
Member Server- Deny access from Guests, Local accounts, and members of the Administrators group.
Domain Controller- Deny access from Guests.
In high-security environments, there should be no need for remote users to access data on a computer.
The Potential Impact of This Policy:
Changing a Member Server or a standalone server configuration to the recommended state may affect applications that require creating a local service account in the Administrators group. To solve this issue, you can either convert the app to use a domain-hosted service account or change this setting's configuration by removing the Local account and a member of the Administrators group. The first option is preferred when possible.
If using IPsec connection, it is recommended you assign it to the Authentication Users group.
Components such as ASP.NET and IIS may require you to configure this setting differently so that functionality won't be affected.
How to set access and deny access to this computer from the network without causing damage?
The biggest challenge in setting who can access and who must be denied from accessing a computer from the network is enhancing security without causing damage to system components functionality. Therefore, before implementing any change of these policies, you must conduct impact analysis.
The best approach for conducting an impact analysis is to use hardening automation tools for automatically generating impact reports. Hardening automation tools will let you skip the impact analysis procedure and generate a detailed report on what will be the impact of each policy change and why. Investing in these tools will minimize the risk for production outages and save you time and resources invested in testing. Learn how CalCom hardening automation solutions can automatically generate an impact analysis report.
When not using automation, impact analysis is done manually. These are the stages you'll need to go through in order to generate a single report:
- Set a test environment that will simulate your production environment.
- Implement your desired change in the test environment to see if any component is affected by it.
- If you find that you can't implement your desired policy, understand why, and decide on a new policy and retest it.
This is a critical, yet very complex procedure and an error in it may have devastating results. Therefore, we recommend using automation for this procedure and for the entire hardening task.