The 9 Windows Server Security Settings You Need To Get Right
Vinnie Breidenthal
If running Windows Server or Azure Stack HCI Failover Clustering, don't remove Authenticated Users from the Access this computer from the network policy setting. Doing so may induce an unexpected production outage. This is due to the local user account CLIUSR that is used to run the cluster service. CLIUSR is not a member of the local Administrators group and if the Authenticated Users group is removed, the cluster service won't have sufficient rights to function or start properly.
The Access this computer from the network policy setting determines which users can connect to the device from the network. This capability is required by many network protocols, including Server Message Block (SMB)-based protocols, NetBIOS, Common Internet File System (CIFS), and Component Object Model Plus (COM+).
Users, devices, and service accounts gain or lose the Access this computer from network user right by being explicitly or implicitly added or removed from a security group that has been granted this user right. For example, a user account or a machine account may be explicitly added to a custom security group or a built-in security group, or it may be implicitly added by Windows to a computed security group such as Domain Users, Authenticated Users, or Enterprise Domain Controllers.By default, user accounts and machine accounts are granted the Access this computer from network user right when computed groups such as Authenticated Users, and for domain controllers, the Enterprise Domain Controllers group, are defined in the default domain controllers Group Policy Object (GPO).
Users who can connect from their device to the network can access resources on target devices for which they have permission. For example, the Access this computer from the network user right is required for users to connect to shared printers and folders. If this user right is assigned to the Everyone group, anyone in the group can read the files in those shared folders. This situation is unlikely because the groups created by a default installation of at least Windows Server 2008 R2 or Windows 7 don't include the Everyone group. However, if a device is upgraded and the original device includes the Everyone group as part of its defined users and groups, that group is transitioned as part of the upgrade process and is present on the device.
Restrict the Access this computer from the network user right to only those users and groups who require access to the computer. For example, if you configure this policy setting to the Administrators and Users groups, users who sign in to the domain can access resources that are sharedfrom servers in the domain if members of the Domain Users group are included in the local Users group.
Note If you are using IPsec to help secure network communications in your organization, ensure that a group that includes machine accounts is given this right. This right is required for successful computer authentication. Assigning this right to Authenticated Users or Domain Computers meets this requirement.
If you remove the Access this computer from the network user right on domain controllers for all users, no one can sign in to the domain or use network resources. If you remove this user right on member servers, users can't connect to those servers through the network. If you have installed optional components such as ASP.NET or Internet Information Services (IIS), you may need to assign this user right to other accounts that are required by those components. It's important to verify that authorized users are assigned this user right for the devices that they need to access the network.
If running Windows Server or Azure Stack HCI Failover Clustering, don't remove Authenticated Users from the Access this computer from the network policy setting. Doing so may induce an unexpected production outage. This outage is due to the local user account CLIUSR that is used to run the cluster service. CLIUSR isn't a member of the local Administrators group and if the Authenticated Users group is removed, the cluster service won't have sufficient rights to function or start properly.
I am trying to allow members of a domain security group, GlobalRDP, to RDP into certain Windows 10 PCs. I granted the GlobalRDP group the "Allow log on through Remote Desktop Services" right and that policy has been successfully deployed to the target computers.
Despite this, whenever a member of the GlobalRDP group attempts to login via RDP, they receive the following error: "The connection was denied because the user account is not authorized for remote login". A similar access denied error appears in the RDP log "User is not granted access to this connection' in CUMRDPSecurityStreamCallback::AccessCheck at 5236 err=[0x80070005]".
What made things weirder is that I also removed the RDP right for Administrators and Remote Desktop Users groups that have this right by default and I was still able to RDP in as member of the local Remote Desktop Users group.
Finally, I changed my GPO to add the GlobalRDP group to the local Remote Desktop Users group of the target PCs, and RDP worked. Despite the fact that this local group still wasn't granted the RDP login right!
The GPO is absolutely applied to the target computers. Looking at Local Security Policy -> Policies -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment -> Allow log on through Remote Desktop Services shows only the GlobalRDP group and that the policy set via GPO. The group policy results wizard shows the same thing.
It seems like no matter what I change, only the default groups are granted the RDP login right. Adding the domain global group to the local group on each PC works, but smells weird to me. What did I miss? Why can't I simply manage that privilege using a domain group?
However, I strongly recommend that you don't mess with these settings. As Todd's answer already mentioned, adding domain users and/or groups to the Remote Desktop Users local group is the supported method for granting remote desktop access.
To use Remote Desktop Services to successfully log on to a remote device, the user or group must be a member of the Remote Desktop Users or Administrators group and [emphasis added] be granted the Allow log on through Remote Desktop Services right.
Since the Remote Desktop Users group is granted the Allow log on through Remote Desktop Services right, adding a user or group to that group fulfills both requirements, while simply granting the right does not.
However, to enable a solution where the user can connect to the apps or desktops that you have published for them from ANY device and from ANYWHERE, then you eventually need to deploy certificates.
Jacob has also written a couple of awesome guides that will come in handy when avoiding this scenario. The first one is a guide on how to build out an Active Directory Certificate Services (ADCS) lab, and the second link is for building out an RDS Farm in a lab. Both of course feature the amazing new Windows Server 2016, and they are spot on to help you avoid this first scenario. Just remember they are guides for LAB environments.
By default, RD Session Host sessions use native RDP encryption. However, RDP does not provide authentication to verify the identity of an RD Session Host server. You can enhance the security of RD Session Host sessions by using Secure Sockets Layer (SSL) Transport Layer Security (TLS 1.0) for server authentication and to encrypt RD Session Host communications. The RD Session Host server and the client computer must be correctly configured for TLS to provide enhanced security. ( -us/library/ff458357.aspx)
Next, check the certificate(s) that are being used to ensure they contain the proper and accurate information. Referring to the methods mentioned in the following information is from this TechNet Article:
In Windows 2008 and Windows 2008 R2, you connect to the farm name, which as per DNS round robin, gets first directed to the redirector, then to the connection broker, and finally to the server that hosts your session.
Go and read that article thoroughly. It talks about proper SAN names to include for external and internal naming for the 2012 / 2012 R2 RDS server roles. Only the RD Web Access and RD Gateway roles should ever be exposed to the Internet, which means obtaining a certificate for those roles from a Public CA.
You can use a single certificate for all the roles if your clients are internal to the domain only, by generating a wildcard certificate (for example: *.CONTOSO.com) and binding it to all roles. Or you will use multiple certs if you have both internal and external requirements.
Security settings and user rights assignments can be changed in local policies and group policies to help tighten the security on domain controllers and member computers. However, the downside of increased security is the introduction of incompatibilities with clients, services, and programs.
This article describes incompatibilities that can occur on client computers that are running Windows XP, or an earlier version of Windows, when you change specific security settings and user rights assignments in a Windows Server 2003 domain or an earlier Windows Server domain.
For information about Group Policy for Windows 7, Windows Server 2008 R2, and Windows Server 2008, see the following articles:
To increase the awareness of misconfigured security settings, use the Group Policy Object Editor tool to change security settings. When you use Group Policy Object Editor, user rights assignments are enhanced on the following operating systems:
bcf7231420