- AccessChk: View effective permissions on files and folders - Thu, Apr 13 2023
- Read NTFS permissions: View read, write, and deny access information with AccessEnum - Wed, Mar 29 2023
- Kill Windows a process with Tskill and Taskkill - Mon, Mar 13 2023
Security policy settings are sets of rules that control various aspects of protection. They include account policies, local policies, user rights assignment, the Windows firewall, software restrictions, and so on. There are several ways to configure security policy settings. The most common are:
- Group policy objects (GPO) – Used in Active Directory domains to configure and regularly reapply security settings to multiple computers.
- Local security policy (secpol.msc) – Used to configure a single (local) computer. Note that this is a one-time action. If another administrator changes these settings, you will need to manually change them back to the required state.
As most organizations use an Active Directory domain, it is preferred to apply security settings via group policies. You should have at least three security baselines created and linked in your domain, based on the following machine types:
- Domain Controllers (DC)
- Member Servers (MS)
- User Workstations
Configuring user rights assignment via Goup Policy
If you have multiple versions of operating systems (OS) running on these machines, you should create separate baselines for each OS version, as some settings might not be available. This also enables stricter configuration for older systems, as they are usually less secure.
Built-in local security principals and groups
It is a best practice to configure security policies using only built-in local security principals and groups, and add needed members to these entities. This gives you much better visibility and flexibility, as GPO provides more options to manage local group members, than to manage security policy members. For example, it's not possible to add a group whose name is generated using system variables (e.g., LAB\LocalAdmins_%COMPUTERNAME%) to a security policy; however, the group can be added to the Administrators group itself.
Security policies do not support generated group names
The following groups are used throughout this article:
- Administrators – Members of this group have full, unrestricted access to the computer. Even if you remove some privileges from the Administrators group, a skilled administrator can still bypass those settings and gain control of the system. Only add highly trusted people to this group.
- Authenticated Users – A special security principal that applies to any session that was authenticated using some account, such as a local or domain account.
- Local account and member of Administrators group – A pseudogroup available since Windows Server 2012 R2. It applies to any local account in the Administrators group and is used to mitigate pass-the-hash attacks (lateral movement).
- Remote Desktop Users – Members of this group can access the computer via Remote Desktop services (RDP).
- Guests – By default, this group has no permissions. I don't think there is any need to use the Guest account and group today.
Center for Internet Security
The Center for Internet Security (CIS) is a well-known non-profit organization that focuses on cybersecurity. To improve your knowledge of cybersecurity, you can access their free materials:
- CIS Controls – A set of 20 basic and advanced cybersecurity actions (controls). Using these, you can stop the most common attacks.
- CIS Benchmarks – Guidelines with specific configuration steps and detailed explanations. CIS Benchmarks are available for various products such as Windows Server, SQL Server, Apple iOS, and many more.
Both can be downloaded in exchange for your email address. There's no need to worry—there will be no further email, unless you choose to receive them.
Many companies and institutions create their security baselines based on CIS. I recommend you read CIS Controls. It really helped me to understand the importance of various security actions and settings.
CIS Benchmarks example
Local Policies/User Rights Assignment
User rights assignments are settings applied to the local device. They allow users to perform various system tasks, such as local logon, remote logon, accessing the server from network, shutting down the server, and so on. In this section, I will explain the most important settings and how they should be configured.
For each setting, the following format is used:
Name of the setting: Recommended value, or values
Access Credential Manager as a trusted caller: No one (empty value)
Access to the Credential Manager is granted during Winlogon only to the user who is logging on. Saved user credentials might be compromised if someone else has this privilege.
Access this computer from the network: Administrators, Authenticated Users
Required for users to connect to the computer and its resources, such as an SMB share, shared printers, COM+, etc. If you remove this user right on the DC, no one will be able to log on to the domain.
Note: On DCs, you should also add the “ENTERPRISE DOMAIN CONTROLLERS“ group.
Allow log on locally: Administrators
The default configuration includes the Users group, which allows a standard user to log on to the server console. Limit this privilege only to administrators.
Allow log on through Remote Desktop Services: Administrators, Remote Desktop Users
It's common practice that some applications are used via RDP sessions by standard users. This privilege is also frequently required for remote assistance offered by an organization's helpdesk. If a server is running Remote Desktop Services with the Connection Broker role, the Authenticated Users group must also be added to this privilege.
Note: On the DC, it is recommended to allow only administrators to connect via RDP.
Back up files and directories: Administrators
This is a sensitive privilege that allows a user to bypass NTFS permissions (only via an NTFS API interface, such as NTBACKUP). A malicious user could backup and restore data on a different computer, thereby gaining access to it.
Deny access to this computer from the network/Deny log on through Terminal Services: Local account and member of Administrators group, Guests
The default value is only Guests. You should add the second group to prevent pass-the-hash attacks, so if a local elevated user is compromised, it cannot be used to elevate privileges on any other network resource, or access it via RDP.
Force shutdown from a remote system/Shut down the system: Administrators
Only administrators should be able to shut down any server, to prevent denial-of-service (DoS) attacks.
Manage auditing and security log: Administrators
This is a sensitive privilege, as anyone with these rights can erase important evidence of unauthorized activity.
Note: If you are running MS Exchange, the “Exchange Servers” group must be added to DCs.
Restore files and directories: Administrators
Attackers with this privilege can overwrite data, or even executable files used by legitimate administrators, with versions that include malicious code.
Take ownership of files or other objects: Administrators
User having this privilege can take control (ownership) of any object, such as a file or folder, and expose sensitive data.
Deny log on as a batch job/Deny log on as a service/Deny log on locally: Guests
To increase security, you should include the Guests group in these three settings.
Debug programs/Profile single process/Profile system performance: Administrators
This setting allows a user to attach a debugger to a system or process, thereby accessing critical, sensitive data. It can be used by attackers to collect information about running critical processes, or which users are logged on.
Change the system time: Administrators, Local Service
Changes in system time might lead to DoS issues, such as unavailability to authenticate to the domain. The Local Service role is required for the Windows Time service, VMware Tools service, and others to synchronize system time with the DC or ESXi host.
Create a token object: No one (empty value)
Users with the ability to create or modify access tokens can elevate any currently logged on account, including their own.
Impersonate a client after authentication: Administrators, Local Service, Network Service, Service
An attacker with this privilege can create a service, trick a client into connecting to that service, and then impersonate that account.
Note: For servers running Internet Information Services (IIS), the "IIS_IUSRS" account must also be added.
Load and unload device drivers: Administrators
Malicious code can be installed that pretends to be a device driver. Administrators should only install drivers with a valid signature.
Wrap up
I hope this article helped you to understand why it is important to define a security baseline for your systems. Many of the settings are already configured properly following server deployment; however, if they are not controlled by a GPO, they can be manipulated by malicious users. Be careful to whom you grant administrator permissions.
Created a domain account to use as a service account and then tried to run powershell cmdlets against the active RDS management server.
Gave that account local admin access on the broker servers and then was able to get further.
Got the error “Access is denied” when trying to run the invoke-RDUserLogoff(with correct hostserver and unifiedsessionID values) to log off a session using that account.
Need to know what permissions should be granted to the account to provide ability to run this command and where like on the broker or the session host.
I can’t run the RD cmdlets on the RD broker to remove a user session without local administrator privileges on the broker and session host.
I need to know what user permissions are necessary to run these cmdlets as giving local admin is not desired.
Sir we are having user1 in server1. We want to collect logs of server1 from server2 using credentials of user1. Surprisingly even after entering the credentials of user1 in event viewer it is taking loggedin credentials of the user logged into server2.