Computer configuration windows settings security settings local policies user rights assignment

Если при входе в Windows вы получаете ошибку “Этот метод входа запрещено использовать”, значит результирующие настройки групповых политик на компьютере запрещают локальный вход под этим пользователем. Чаще всего такая ошибка появляется, если вы пытаетесь войти под гостевой учетной записью на обычный компьютер, или под пользователем без прав администратора домена на контроллер домена. Но бывают и другие нюансы.

The sign-in method you're trying to use isn't allowed. For more info, contact your network administrator.

Список пользователей и групп, которым разрешен интерактивный локальный вход на компьютер задается через групповую политику.

1. Откройте редактор локальной групповой политики (
   gpedit.msc
   );
2. Перейдите в раздел Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment;
3. Найдите в списке политику Allow log on locally (Локальный вход в систему);
4. В этой политике содержится список групп, которым разрешен локальный вход на этот компьютер;

   В зависимости от операционной системы и роли компьютера список групп, которым разрешен локальный вход может отличаться.Например, на рабочих станциях с Windows 10 и рядовых серверах на Windows Server 2022,2019,2016 локальный вход разрешен для следующих групп:

   • Administrators
   • Backup Operators
   • Users

   На серверах Windows Server с ролью контроллера домена Active Directory интерактивный вход разрешен для таких локальных и доменных групп:

   • Account Operators
   • Administrators
   • Backup Operators
   • Print Operators
   • Server Operators
5. Вы можете разрешить другим пользователям или группам локальный вход в систему. Для этого можно нажать кнопку Add User or Group, и найти нужных пользователей. Также вы можете, например, запретить пользователям без прав администратора вход на это устройство. Для этого просто удалите группу Users из настроек данной политики;
6. После внесения изменения изменений нужно обновить настройки локальных политик командой
   gpupdate /force
   (перезагрузка не понадобится).

Также обратите внимание, что в этой же секции GPO есть еще одна политика, позволяющая принудительно запретить локальный интерактивной вход на консоль Windows. Политика называется Deny log on locally (Запретить локальных вход). В моем случае на компьютер запрещен анонимный локальный вход под учетной записью Гостя.

Вы можете запретить определенной группе (или пользователю) локальный вход на компьютер, добавив группу в эту политику. Т.к. запрещающая политика Deny log on locally имеет более высокий приоритет, чем разрешающая (Allow log on locally), пользователи не смогут зайти на этот компьютер с ошибкой:

Этот метод входа запрещено использовать

Одной из best practice по обеспечению безопасности аккаунтов администраторов в домене Windows является принудительный запрет на локальных вход на рабочие станции и рядовые сервера под администраторами домена. Для этого нужно распространить политику Deny log on locally с группой Domain Admins на все OU, кроме Domain Controllers. Аналогично нужно запретить вход под локальными учетными записями.

В доменной среде на компьютер может действовать несколько GPO. Поэтому, чтобы узнать примененные политики, назначающих права на локальный вход, нужно проверить результирующие настройки политик. Для получения результирующих настроек GPO на компьютере можно использовать консоль
rsop.msc
или утилиту gpresult.

Обратите внимание, что пользователи могут использовать интерактивные RDP сессии для подключения к устройству с Windows (если на нем включен RDP вход) несмотря на запрет локального входа. Список пользователей, которым разрешен вход по RDP задается в этом же разделе GPO с помощью параметра Allow logon through Remote Desktop Services.

Еще одной из причин, из-за которой вы можете встретить ошибку “
The sign-in method you are trying to use isn’t allowed
”, если в атрибуте LogonWorkstations у пользователя в AD задан список компьютеров, на которые ему разрешено входить (подробно описано в статье по ссылке). С помощью PowerShell командлета Get-ADUser вы можете вывести список компьютеров, на которых разрешено логиниться пользователю (по умолчанию список должен быть пустым):

(Get-ADUser kbuldogov -Properties LogonWorkstations).LogonWorkstations

В некоторых случаях (как правило в филиалах) вы можете разрешить определенному пользователю локальный и/или RDP вход на контроллер домена/локальный сервер. Вам достаточно добавить учетную запись пользователя в локальную политику Allow log on locally на сервере. В любом случае это будет лучше, чем добавлять пользователя в группу локальных администраторов. Хотя в целях безопасности еще лучше использовать RODC контроллер домена.

Также вы можете предоставить права на локальный вход с помощью утилиты ntrights (утилита входила в какую-то древнюю версию Admin Pack). Например, чтобы разрешить локальный вход, выполните команду:

ntrights +r SeInteractiveLogonRight -u "GroupName"

Чтобы запретить вход:

ntrights -r SeInteractiveLogonRight -u "UserName"

In my previous post,Windows Server security features and best practices, I introduced the built-in features that can be used to increase your organization’s security. Today, I will focus on one of the main security mechanisms in Windows: security policy settings, specifically local policies/user rights assignment, in Windows Server 2016.

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

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.

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.

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.

Windows 7 / Security and Privacy

---

The most efficient way to assign user rights is to make the user a member of a group
that already has the right. In some cases, however, you might want a user to have a
particular right but not have all the other rights of the group. One way to resolve this
problem is to give the user the rights directly. Another way to resolve this is to create a
special group for users that need the right. This is the approach used with the Remote
Desktop Users group, which was created by Microsoft to grant Allow Logon Through Terminal Services to groups of users.

You assign user rights through the Local Policies node of Group Policy. Local policies
can be set on a per-computer basis using a computer’s local security policy or on a
domain or OU basis through an existing group policy for the related domain or OU.
When you do this, the local policies apply to all accounts in the domain or OU.

Assigning User Rights for a Domain or OU

You can assign user rights for a domain or OU by completing the following steps:

1. In the Group Policy Management Console, select the policy you want to work
   with, and then click Edit. Access the User Rights Assignment node by working
   your way down the console tree. Expand Computer Configuration, Windows
   Settings, Security Settings, Local Policies, and User Rights Assignment.
2. To configure a user right, double-click a user right or right-click it and select
   Properties. This opens a Properties dialog box. If the
   policy isn’t defined, select Define These Policy Settings. To apply the right to a
   user or group, click Add User Or Group. Then, in the Add User Or Group dialog
   box, click Browse. This opens the Select Users, Computers, Or Groups dialog box.
3. Type the name of the user or group you want to use in the field provided, and
   then click Check Names. By default, the search is configured to find built-in
   security principals, groups, and user accounts. After you select the account names
   or groups to add, click OK. The Add User Or Group dialog box should now show the selected accounts. Click OK again.
4. The Properties dialog box is updated to refl ect your selections. If you made a
   mistake, select a name and remove it by clicking Remove. When you’re fi nished
   granting the right to users and groups, click OK.

Assigning User Rights on a Specific Computer

User rights can also be applied to a specific computer. However, remember that domain
and OU policy take precedence over local policy. This means that any settings in these
policies will override settings you make on a local computer.

You can apply user rights locally by completing the following steps:

1. Start Local Security Policy by clicking Start, Programs or All Programs,
   Administrative Tools, Local Security Policy. All computers, even domain
   controllers, have Local Security Policy. Settings available in the Local Security
   Policy console are a subset of the computer’s local policy.
2. Under Security Settings, expand Local Policies and then select User Rights Assignment.
3. Double-click the user right you want to modify. The Properties dialog box shows
   current users and groups that have been given the user right.
4. You can apply the user right to additional users and groups by clicking Add User
   Or Group. This opens the Select Users, Computers, Or Groups dialog box, which you can use to add users and groups.
5. Click OK twice to close the open dialog boxes.

Note:
If the options in the Properties dialog box are dimmed, it means the policy has been set
at a higher level and can’t be overridden locally.

Подсистема контроля доступа Windows, которая определяет пользователей, имеющих доступ к тем или иным ресурсам, основана на концепциях разрешений (permission) и пользовательских прав (user right). Разрешения связаны с объектами — например, разрешения для распечатывания файла, создания папки и добавления объекта user в Active Directory (AD). Пользовательские права связаны с системой Windows в целом — например, право пользователя регистрироваться в системе Windows или изменять системные часы.

Права пользователя Windows подразделяются на две категории: привилегии пользователя (user privilege) и права регистрации (logon right). Привилегии пользователя, такие как Change the System Time и Shut down the System, обеспечивают контроль над системными ресурсами и операциями, связанными с системой. Права регистрации задают учетные записи пользователей, которые могут регистрироваться в системе Windows, и способ регистрации учетной записи пользователя в системе. Более подробная информация об учетных записях пользователя и процедуре входа Windows приведена в статье «Все дело в доверии» (http://www.osp.ru/text/302/2599419/). В данной статье рассматривается, как использовать права регистрации в качестве инструмента контроля доступа, даны объяснения различных прав доступа и рекомендации по их применению.

Права регистрации — общая картина

В Windows Server 2003 и Windows XP определены 10 различных прав доступа, с помощью которых можно управлять разными типами попыток локальной и доменной аутентификации пользователей в системах Windows. Права регистрации также охватывают процедуры аутентификации пользователей, в том числе регистрацию в FTP-службе на базе Windows. Например, чтобы обеспечить регистрацию учетной записи пользователя в FTP-службе на базе Windows, необходимо присвоить учетной записи право Log on locally в системе Windows, на которой размещена служба FTP. В Windows 2000 было введено право регистрации «deny». Windows 2003, XP и Windows 2000 Service Pack 2 (SP2) и более поздние версии поддерживают права регистрации для Terminal Services.

В таблице 1 перечислены права регистрации Windows наряду с именами API, соответствующими каждому праву регистрации, и показаны встроенные группы, которые получают права регистрации, назначаемые по умолчанию на контроллере домена (DC), члене-сервере и автономной системе. Имена API — внутренние имена, используемые Windows для обозначения прав регистрации. Иногда их необходимо указывать при использовании инструментов командной строки, о которых будет рассказано ниже, или при просмотре журнала событий Security. Рассмотрим каждое право регистрации немного подробнее:

• Log on locally позволяет пользователям регистрироваться в Windows с помощью комбинации клавиш Ctrl+Alt+Del или из экрана Welcome. В Windows этот метод входа называется локальным или интерактивным. Пользователям Windows 2000 это право необходимо для входа через Terminal Services.
• Access this computer from the network обеспечивает подключение пользователей к компьютеру через сеть. Это право обязаны иметь все пользователи, желающие обратиться к удаленной системе для доступа к файлу, папке, приложению или другому ресурсу. В Windows данный метод регистрации называется сетевым или неинтерактивным входом.
• Log on as a batch job позволяет пользователям регистрироваться для запуска пакета команд. Это право применяется в Windows Task Scheduler и некоторых других службах для регистрации пользователей. Scheduled Tasks автоматически предоставляет это право по мере необходимости — в моменты, когда необходимо запустить запланированное задание.
• Log on as a service позволяет субъекту безопасности регистрироваться в качестве службы. Это право обеспечивает работу служб в системах Windows в фоновом режиме. Учетным записям System и Network Service на автономных системах и серверах, членах доменов, это право предоставляется по умолчанию. Если для запуска службы используется другая специальная запись, то необходимо явно назначить ей это право.
• Allow logon through Terminal Services определяет пользователей, которые могут регистрироваться с помощью Terminal Services или клиента Remote Desktop.
• Deny logon locally запрещает пользователю регистрироваться с клавиатуры или экрана Welcome компьютера. Это право имеет приоритет перед правом Log on locally.
• Deny access to this computer from the network запрещает пользователю подключаться к компьютеру через сеть. Это право имеет приоритет перед правом Access this computer from the network.
• Deny logon as a service запрещает субъекту безопасности регистрироваться в качестве службы для формирования контекста безопасности. Это право имеет приоритет перед правом Log on as a service.
• Deny logon as a batch job запрещает пользователю регистрироваться в роли пакетного файла; оно имеет приоритет перед правом Log on as a batch job.
• Deny logon through Terminal Services запрещает пользователю регистрироваться с помощью Terminal Services или Remote Desktop; это право имеет приоритет перед правом Allow logon through Terminal Services.

Права Deny logon полезны в крупных сетях Windows. Например, если нужно предоставить право Access this computer from the network всем, кроме двух конкретных учетных записей. В этом случае, гораздо проще назначить группе Authenticated Users право Access this computer from the network, а двум отдельным учетным записям — право Deny access to this computer from the network, вместо того, чтобы определять все учетные записи, имеющие доступ, объединяя их в специальную группу, а затем назначать этой группе право Access this computer from the network.

Управление правами регистрации в Windows

Чтобы назначать и управлять правами регистрации в Windows, можно использовать инструмент Local Security Policy (только на автономных системах) или оснастку Group Policy Object консоли Microsoft Management Console (MMC) (для автономных компьютеров и систем, членов доменов). В комплектах ресурсов Windows 2003 и Windows 2000 содержится два инструмента командной строки, которые помогают управлять правами регистрации: NTRights (ntrights.exe) и ShowPriv (showpriv.exe).

К инструменту Local Security Policy можно обратиться из раздела Administrative Tools Панели управления (меню Start, Settings, Control Panel, Administrative Tools, Local Security Policy). В окне Local Security Settings, право регистрации назначается путем расширения контейнеров Security Settings, Local Policies, User Rights Assignment (Экран 1).

Для доступа к оснастке Group Policy Object следует запустить MMC, затем загрузить оснастку. Для управления правами входа на автономных системах следует выбрать Local Computer Group Policy Object (GPO); для управления правами входа на контроллерах домена (DC), нужно выбрать Default Domain Controllers GPO. В оснастке Group Policy Object можно назначить права регистрации, развернув контейнеры Computer Configuration, Windows Settings, Security Settings, Local Policies, User Rights Assignment (Экран 2).

С помощью утилиты NTRights можно предоставлять и отменять пользовательские права Windows (как права регистрации, так и привилегии) для пользователей и групп на локальном или удаленном компьютере. Например, чтобы предоставить учетной записи ServiceAccount1 право Logon as a service на компьютере MyComputer, следует выполнить следующую команду:

Ntrights +r SeServiceLogonRight
 -u ServiceAccount1 -m MyComputer

Отменить право Access this computer from the network для группы Authenticated Users можно с помощью команды

Ntrights -r SeNetworkLogonRight -u Everyone

С помощью утилиты ShowPriv можно вывести на экран пользователей и группы, которым назначено конкретное пользовательское право только в локальной системе. Например, чтобы отыскать пользователей и группы, которые имеют право регистрации Log on locally в данной системе, следует выполнить команду

Showpriv SeInteractiveLogonRight

Оптимальные процедуры

Для удобства управления доступом, в Windows реализована концепция групп. Вместо того, чтобы назначать разрешения и права многим отдельным пользователям, гораздо проще организовать пользователей в группы, а затем назначить разрешения и права группам. При этом упрощается также управление правами регистрации.

Еще один эффективный прием — назначать пользовательские права доменным, а не локальным учетным записям. С помощью локальной учетной записи пользователь может обойти централизованную политику безопасности, применяемую на уровне домена Windows. Как отмечалось в статье «Все дело в доверии», следует всегда стараться использовать домены Windows, независимо от размера сети.

Кроме того, полезно при любой возможности назначать служебным учетным записям права Deny logon locally, Deny access to this computer from the network и Deny logon through Terminal Services. Всегда следует руководствоваться принципом минимальных достаточных привилегий. В контексте прав регистрации, это значит, что служебной учетной записи нужно назначать только права регистрации, необходимые для работы.

Может оказаться, что стандартные права регистрации, перечисленные в таблице 1, недостаточно строги. Чтобы блокировать назначенные права регистрации, рекомендуется принять следующие меры:

• Отменить право Log on locally для групп Users, Power Users и Guest на серверах, членах доменов.
• Отменить право Access this computer from the network для группы Authenticated Users на отдельных серверах и контроллерах доменов.

Права регистрации и журналы событий

В журнале событий Windows перечислены события аудита регистрации, которые относятся к рассмотренным правам регистрации. Просматривать события аудита полезно при диагностике проблем с аутентификацией Windows. Для генерации событий аудита регистрации, следует активизировать режим Audit account logon events (как успешных, так и неудачных) в политике аудита автономной системы или домена.

Наибольший интерес для администратора представляет поле Logon Type. На Экране 3 показано событие регистрации с ID 540, которое свидетельствует об удачной регистрации. В поле Description можно увидеть поле Logon Type, содержащее значение 3, которое указывает, что успешный вход был произведен с помощью сетевой регистрации. Поле Logon Type содержать значения 2 (интерактивный вход), 3 (сетевой вход) 4 (пакетный вход) или 5 (регистрация службы). Самые часто встречающиеся значения Logon Type — 2 и 3. Logon Type 2 в журналах Event Viewer показывает, что кто-то интерактивно зарегистрировался в системе. Logon Type 3 означает, что кто-то пытался обратиться к ресурсам компьютера по сети. Logon Type 4 показывает, что служба Task Scheduler запускает сценарий или программу в пакетном режиме. Logon Type 5 означает, что была запущена служба Windows от имени конкретной пользовательской учетной записи.

Мощный инструмент управления доступом

Права регистрации Windows — важный компонент безопасности Windows. Наряду с привилегиями пользователей, они обеспечивают мощный метод управления пользовтельским доступом к системам Windows. Описанные в данной статье методы назначения прав регистрации и использования журнала событий для идентификации неполадок обеспечивают надежно защищенный доступ к системам Windows.

Экран 1. Использование инструмента Local Security Policy для назначения прав регистрации.

Экран 2. Использование оснастки Group Policy Object для назначения прав регистрации.

Экран 3. Событие аудита для для успешного входа.

Жан де Клерк (jan.declercq@hp.com) — член Security Office компании HP. Специализируется на управлении идентификационными параметрами и безопасности в продуктах Microsoft. Он автор книги Windows Server 2003 Security Infrastructures (издательство Digital Press).

В каждой операционной системе Windows по умолчанию присутствует встроенная (built-in) учетная запись администратора. Эта учетная запись имеет неограниченные права и при ее компрометации злоумышленник получает полный контроль над системой. Чтобы этого не произошло, встроенную учетную запись администратора необходимо защитить.

Существует множество различных способов защиты и сегодня мы рассмотрим некоторые из них.

Отключение и переименование

Одной из наиболее распространенных атак является перебор паролей. Обычно от перебора защищаются с помощью политик блокировки, ограничивающих количество попыток ввода пароля. Однако особенностью встроенной учетной записи администратора является то, что она не зависит от количества неправильного ввода пароля и ее невозможно заблокировать. Поэтому учетная запись администратора является распространенной целью для подобного рода атак.

Одним из способов защиты от перебора является отключение учетной записи либо, если отключение невозможно, то ее переименование.

В производственной среде сделать это проще всего с помощью групповых политик. Нужные нам параметры находятся в разделе Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options.

Для получения доступа к системе необходимо узнать две вещи — имя пользователя и его пароль. В случае со встроенной учеткой администратора по умолчанию имя всегда Administrator (или Администратор в русскоязычной версии системы). Переименование усложнит процесс взлома, поскольку злоумышленнику придется сначала выяснить имя пользователя, а уже затем приступить к перебору.

За переименование отвечает параметр политики с именем Accounts: Rename administrator account. Надо открыть его, отметить чекбокс ″Define this policy settings″ и задать новое имя пользователя. Имя может быть любое, насколько хватит фантазии. Как вариант, можно переименовать администратора в гостя (Guest), а гостя в администратора. Поскольку у гостевой учетной записи практически нулевые права в системе, то взломав ее злоумышленник будет неприятно удивлен 🙂

Переименование учетной записи повышает безопасность, однако эта мера недостаточно эффективна. Учетная запись администратора имеет известный идентификатор безопасности (SID) и существуют средства, позволяющие проходить аутентификацию с использованием SID а не имени пользователя.

Поэтому более эффективным способом защиты учетной записи администратора является ее отключение. Для отключения используется параметр политики с названием Accounts: Administrator account status. Надо открыть его, отметить чекбок ″Define this policy settings″ и поставить переключатель в положение Disabled.

Ну а для большей безопасности учетную запись можно и переименовать и отключить. В результате должно получиться что то типа этого.

Примечание. Если вы сначала переименуете учетную запись администратора, а потом захотите ее отключить, то ничего не получится. Видимо дело в том, что политика жестко привязана к имени пользователя и при его изменении просто не находит нужную учетку. А вот в обратном порядке все отлично работает и переименовать отключенную учетную запись можно без проблем.

Запрет на вход

И переименование и даже отключение учетной записи администратора вовсе не гарантируют ее полную безопасность. Поэтому следующим этапом защиты будет минимизация потерь в том случае, если учетная запись все же оказалась скомпрометирована.

Надо сказать, что ограничить права локального администратора в системе практически невозможно, но зато можно запретить сам вход в систему. Для этого мы ограничим права входа для учетной записи локального администратора, также с помощью групповых политик.

Примечание. Права входа (Logon Rights) определяют способы входа в систему, доступные для пользователя.

В разделе Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment находятся следующие параметры:

Deny log on locally — запретить локальный вход в систему;
Deny log on through Remote Desktop Service — запретить доступ с помощью службы удаленных рабочих столов;
Deny access to this computer from the network — запретить доступ к компьютеру по сети. Доступ по сети используется при удаленном доступе к файловой системе или приложениям;
Deny log on as a service — запретить пользователю регистрироваться в качестве службы. Это право обеспечивает работу служб Windows в фоновом режиме;
Deny log on as a batch job — запретить пользователю регистрацию в качестве пакетного задания. Это право используется планировщиком заданий (Task Scheduler) и некоторыми другими службами.

Для активации параметра политики надо надо открыть его, отметить чекбок ″Define this policy settings″ и указать пользователей или группы, для которого эта политика будет применяться. В нашем случае надо указать имя Administrator.

Microsoft рекомендует отключать для локального администратора все способы входа кроме локального, в результате должно получиться примерно так.

После применения запрещающих политик надо проверить их работу. Для проверки запрета на вход по RDP попробуем зайти на сервер с помощью RDP клиента, и если все получилось, то получим примерно такое сообщение.

Проверить запрет на доступ по сети несколько сложнее. Для проверки надо зайти на сервер локально, запустить от имени администратора командную консоль и выполнить команду net use. Например:

net use \\SRV2\C$

Если политика отработала корректно, то вместо ответа будет выдана ошибка с номером 1385.

Для проверки запрета на запуск в виде сервиса надо открыть оснастку Services, выбрать любой некритичный сервис, например сервис печати (Print spooler), и попробовать запустить его от имени локального администратора.

В результате должна получиться следующая ошибка.

Ну и проверить запрет на запуск в виде пакетного задания можно с помощью планировщика заданий (Task scheduler). Для этого создадим в планировщике задание и укажем его запуск от имени учетной записи локального администратора.

В случае успеха при сохранении задания мы получим ошибку.

Заключение

В заключение некоторые важные моменты, о которых необходимо помнить:

• Если вы решили отключить встроенную учетную запись администратора, то не забудьте создать на компьютере хотя бы одного пользователя с административными правами;
• Не рекомендуется применять вышеописанные политики к контроллерам домена. Дело в том, что на контроллерах домена нет локальных учетных записей и политики применяться к учетной записи DSRM администратора. При недоступности этой учетной записи вы не сможете зайти на контроллер домена в режиме восстановления Active Directory;
• При отключении политики переименования учетной записи администратора имя пользователя может не измениться на исходное. В этом случае потребуется в политике прописать стандартное имя, подождать пока она применится, и только потом ее отключать.