Deny access to this computer from the network PowerShell

In "Don't Shoot Yourself in the Foot with Group Policy Security Settings, Part 1," http://www.winnetmag.com, InstantDoc ID 21656, you warned that within Group Policy Objects (GPOs) that are applied to domain controllers (DCs), removing all users and groups from the Access this computer from the network user right or assigning all users the Deny access to this computer from the network user right can cause severe problems. Can I manually grant the Access this computer from the network right to users without using a GPO?

The problems associated with removing all users and groups from the Access this computer from the network user right or assigning all users the Deny access to this computer from the network user right include preventing administrators—even those who are logged on locally—from running administrative tools, such as DNS Manager and the Microsoft Management Console (MMC) Active Directory Users and Computers, Active Directory Domains and Trusts, Active Directory Sites and Services, and Group Policy snap-ins. However, Microsoft has documented a way to manually edit gpttmpl.inf, the file that maintains rights assignments in a GPO, to grant the Access this computer from the network right to users on the DC.

At a DC console, log on as a member of Domain Admins, open Windows Explorer, navigate to %winroot%\Sysvol\Sysvol\Domainname\Policies, and examine the subfolders. Each subfolder in the Policies folder corresponds to a GPO in your domain. However, the subfolder names don't correspond to the GPO names. Rather, each subfolder derives its name from the corresponding GPO's globally unique identifier (GUID)—a complex string that looks something like \{31B2F340-016D-11D2-945F-00C04FB984F9\}. Without being able to open the Active Directory Users and Computers snap-in, you can't easily obtain a GPO's GUID, so you'll need to do some detective work to determine the GUID of the GPO you're interested in. Within each GPO subfolder, you'll find gpttmpl.inf in Machine\Microsoft\Windows NT\SecEdit, as Figure 1 shows. You need to determine which subfolder corresponds to the GPO that restricts the Access this computer from the network right and edit that folder's gpttmpl.inf file. If you can't figure out the correct subfolder to edit, you can simply edit temporarily every GPO's gpttmpl.inf file.

Use Notepad to open the file, then look for a line that starts with SeNetworkLogonRight=. In this line, the GPO stores assignments for the Access this computer from the network right. Replace everything after the equals sign (=) with the string *S-1-1-0, which corresponds to the SID of the Everyone group. Then, look for a line that starts with SeDenyNetworkLogonRight=. The GPO stores assignments for the Deny access to this computer from the network right in this line. Delete everything after the equals sign on that line. (Policies that don't contain either of these lines are configured as Not defined in the GPO.) Save and close gpttmpl.inf.

Next, open the gpt.ini subfolder in the GPO's folder. You'll find a line that starts with Version=. Increment the number that follows the equals sign, then save and close the file.

Finally, run the command

from the command line to force the DC to reapply Group Policy and thus update the rights assignments. After you log off and log back on to the DC, you should be able to run the Active Directory Users and Computers snap-in and other tools that depend on the Access this computer from the network right. For more details, see the Microsoft articles "'Access This Computer from the Network' User Right Causes Tools Not to Work" (http://support.microsoft.com/?kbid=257346), "Using Secedit.exe to Force Group Policy to Be Applied Again" (http://support.microsoft.com/?kbid=227448), and "Replication Does Not Work After Upgrading to Windows 2000" (http://support.microsoft.com/?kbid=249261).

—Randy Franklin Smith

In Windows: we block remote network access for local user accounts for various reasons.

Here at Bobcares, we have seen several such Windows-related errors as part of our Server Management Services for web hosts and online service providers.

Today we’ll take a look at the cause and fix of this Windows error.

What causes ‘Windows: block remote network access for local user accounts’

For a number of reasons, restrictions are there to use local accounts to access another computer over the network in Active Directory environments.

The same local administrator username and password are often used on many computers. As a result, this can put multiple devices at risk if a single computer compromises.

Moreover, accessing network resources with local accounts is hard to personify and centrally monitor. Because such events are not logged on AD domain controllers.

To reduce the risk, administrators can rename the default local Windows Administrator account.

In Windows: how we block remote network access for local user accounts

Usually, our Support Engineers restrict network access for local accounts. We do it by using the Deny access to this computer from the network policy.

But in this policy, we need to explicitly list all accounts that need to be denied network access to the computer.

In Windows 8.1 and Windows Server 2012 R2, two new well-known security groups with new SIDs appears. One includes all local users, and the second includes all local administrators.

Now, to restrict access for local accounts, we use their common SIDs.

These groups are added to the user’s access token during logon to the computer under a local account.

We make sure that in Windows 10/Windows Server 2016, the local administrator account is assigned to two new security groups. They are (NT AUTHORITY\Local account (SID S-1-5-113) and NT AUTHORITY\Local account and member of Administrators group (SID S-1-5-114)). For that, we run the command:

Also, we can check if these security groups exist on a Windows device by SID using the following PowerShell script:

If the script returns NT Authority\Local account, then this local group (with S-1-5-113 SID) exists on the computer.

We can block the remote network access under local user accounts containing these SIDs in the token. For that, we use the settings from the GPO section Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment.

Deny Remote Desktop (RDP) Access for Local Users and Administrators

The Deny log on through Remote Desktop Services policy allows specifying users and groups that are explicitly denied to logon to a computer remotely via Remote Desktop. We can deny RDP access to the computer for local and domain accounts.

By default, RDP access on Windows is allowed for the administrators and members of the local Remote Desktop User group.

If we want to restrict RDP connections for local users only

• First, we open the local GPO editor gpedit.msc (if we want to apply these settings on computers in the Active Directory domain, use the domain Group Policy Editor – gpmc.msc).
• Then we go to the GPO section User Rights Assignment and edit the Deny log on through Remote Desktop Services policy.

After that, we add the built-in local security groups. That is “Local account and member of Administrators group” and “Local account” to the policy. We update local Group Policy settings using the command:

The deny policy takes precedence over the Allow log on through Remote Desktop Services policy. If we add a user or group in both policies, RDP access for that user will be denied.

Finally, if we try to connect to the computer under a local user via RDP, an error will appear:

Deny Access to Computer from the Network

We can deny network access to a computer under local credentials with the Deny access to this computer from the network policy.

We add the local groups “Local account” and “Local account and member of Administrators group” to the Deny access to this computer.

For a domain environment, we completely block access to workstations and domain-member servers. We do this under accounts from the Domain Admins and Enterprise Admins security groups. We use this account only to access domain controllers. This reduces the risks of capturing the administrative (privileged) account hash and privilege escalation.

After applying the policy, we won’t be able to remotely connect to this computer over the network under any local Windows account. When trying to connect to a shared network folder or map a network drive from this computer under a local account, an error appears:

When trying to establish a Remote Desktop connection under the local administrator account, an error message appears.

If we apply this policy to a computer that is part of a Windows workgroup, we can only logon to that computer locally.

[Need any further assistance in fixing Windows errors? – We are here to help you]

Conclusion

Today, we saw how our Support Engineers restrict remote network access for a local user account.

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

GET STARTED