Как разрешить или запретить пользователям вход на компьютеры в домене AD?
Когда вы создаёте нового пользователя в Active Directory, он автоматически добавляется в группу Domain Users. Группа Domain Users в свою очередь по умолчанию добавляется в локальную группу Users на компьютере при добавлении его в домен AD. Это означает что любой пользователь домена может войти на любой компьютер в вашей сети. В этой статье рассмотрено, как ограничить вход пользователей на компьютеры домена и ограничить разрешенное время входа.
Разрешить вход на определенные компьютеры в свойствах пользователя AD
В свойствах (атрибутах) учетной записи пользователя Active Directory можно задать список компьютеров, на которые ему разрешено входить. Например, вы хотите, чтобы определенный пользователь мог войти только на свой компьютер. Для этого:
- Запустите оснастку ADUC (Active Directory Users and Computers), выполнив команду dsa.msc ;
- С помощью поиска найдите учетную запись пользователя, которому нужно ограничить вход только на компьютеры домена и откройте его свойства;
- Перейдите на вкладку Account и нажмите кнопку Log On To;
- Как вы видите, пользователю разрешено входить на все компьютеры (The user can log on to: All computer). Чтобы разрешить пользователю аутентифицироваться только на определенных компьютерах, выберите опцию The following computers и добавьте в список имена компьютеров, но которые ему разрешено входить;
Примечание. Нужно указывать полное NetBIOS или DNS имя компьютера (нельзя знаки подстановки использовать), параметр регистронезависимый.
- Количество компьютеров, которые можно добавить в этот список ограничено 64. При попытке добавить 65 компьютер появится сообщение об ошибке: This property is limited to 64 values. You must remove some of the existing values before you can add new ones.
- Сохраните изменения. Теперь пользователь может входить только на указанные компьютеры.
С помощью оснастки Active Directory Administrative Center ( dsac.msc ) и с помощью PowerShell вы можете разрешить пользователю входить более чем на 65 компьютер. Однако максимальное значение ограничивается типом данных атрибута Logon-Workstation в схема Active Directory (Octet String). В Windows Server 2016 + в этом атрибуте может содержаться до 8192 символов (в предыдущих версиях Windows Server 2003-2012 использовалось ограничение 1024 символов).
Еще одна интересная особенность появляется, если вы ограничили пользователю список компьютеров разрешенных для входа с помощью атрибута LogonWorkstation.
При попытке подключится к удаленному компьютеру (RDS ферме) по RDP, вы можете получить ошибку:
The system administrator has limited the computers you can log on with.
Системный администратор ограничил количество компьютеров с которых вы можете войти в систему.
Для решения этой проблемы нужно добавить в список LogonWorkstation компьютер с которого (!!!) осуществляется RDP вход.
Изменяем атрибут LogonWorkstations с помощью PowerShell
Вручную заполнять список компьютеров, на которые разрешено входить пользователю домена довольно утомительно. С помощью PowerShell можно автоматизировать это действие. Список компьютеров, на которые разрешено входить пользователю хранится в атрибуте пользователя в AD – LogonWorkstations. Например, наша задача разрешить определенному пользователю входить только на компьютеры, чьи имена содержатся в текстовом файле computers.csv (в этом примере в первой строке файла должно содержаться имя столбца – NetBIOSName).
Скрипт может выглядеть так (сначала загружаем модуль AD для Powershell):
Import-Module ActiveDirectory
$ADusername = ‘aapetrov’
$complist = Import-Csv -Path «C:\PS\computers.csv» | ForEach-Object {$_.NetBIOSName}
$comparray = $complist -join «,»
Set-ADUser -Identity $ADusername -LogonWorkstations $comparray
Clear-Variable comparray
Для изменения атрибутов пользователя Active Directory используется командлет Set-ADUser.
С помощью командлета Get-ADUser команды можно вывести список компьютеров, на которые разрешено входить пользователю:
Get-ADUser $ADusername -Properties LogonWorkstations | Format-List Name, LogonWorkstations
Либо можно посмотреть список компьютеров в консоли ADUC.
Чтобы добавить в список новый компьютер, воспользуйтесь такой командой:
$Wks = (Get-ADUser dvivannikov -Properties LogonWorkstations).LogonWorkstations
$Wks += «,newpc»
Set-ADUser aapetrov -LogonWorkstations $Wks
Ограничить часы входа пользователя в Active Directory
В свойствах учетной записи пользователя вы можете ограничить время входа учетной записи. Например, вы можете разрешить пользователю входить на компьютеры домена только в рабочие часы с 8:00 до 19:00.
- Для этого откройте свойства пользователя в оснастке ADUС, перейдите на вкладку и нажмите кнопку Logon Hours (Время входа);
- По умолчанию для пользователей не ограничено время входа в домена (все выделено синим);
- Выделите диапазоны времени, в которые вы хотите запретить вход пользователя и нажмите Logon Denied (цвет диапазонов, в которые запрещено логиниться пользователям изменится на белый).
Если вам нужно применить одинаковы ограничения Logon Hours для нескольких пользователей, проще всего использовать PowerShell. Сначала вручную настройте ограничения для одного пользователя, а затем используете значение его атрибута logonHours в качестве шаблона для других пользователей. Например, вы хотите ограничить время входа для группы удаленных пользователей:
$templateuser=’a.khramov’
$templatehours= Get-ADUser -Identity $templateuser -properties logonHours
Get-ADGroupmember «msk-VPN_Users» |foreach {Set-ADUSer $_.samaccountname -Replace @{logonHours = $templatehours.logonHours} }
Если пользователь попытайся войти в компьютер за пределами разрешенных logonhours, он получит ошибку:
Account restrictions are preventing this user from signing in. For example: blank passwords aren't allowed, sign-in times are limited, or a policy restriction has been enforced.
В Windows нет встроенного функционала по принудительному завершению сессии пользователе, если его рабочее время закончено. Для гарантированного выполнения logoff можно создать простое задание планировщика и распространить его через GPO.
Также обратите внимание на два параметра GPO в разделе to Computer configurations -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options.
- Network security: Force logoff when logon hours expire
- Microsoft network server: Disconnect clients when logon hours expire
При включении этих политик SMB сервера будут отключать подключения пользователей, чьи часы работы просрочены.
Ограничить вход на компьютеры в Active Directory с помощью GPO
В больших доменах использовать свойство пользователя LogonWorkstations для ограничения доступа пользователей к компьютерам нецелесообразно из-за ограничений и недостаточной гибкости. Для более гибкого управления правилами запрета/разрешения входа на компьютеры используют групповые политики.
Можно ограничить список пользователей в локальной группе Users с помощью политики Restricted Groups. Но мы рассмотрим другой вариант.
Есть две групповые политики, которые находятся в разделе Computer Configuration -> Policies -> Security Settings -> Local Policies -> User Rights Assignment (Конфигурация пользователя -> Политики -> Параметры безопасности -> Локальные политики -> Назначение прав пользователя):
- Deny log on locally (Запретить локальный вход) – позволяет запретить локальный вход на компьютеры для определенных пользователей или групп. ;
- Allow log on locally (Локальный вход в систему) – содержит список пользователей и групп, которым разрешено входить на компьютер локально.
Например, чтобы запретить пользователям определенной группы входить на компьютеры в определенной Organizational Unit (OU), вы можете создать отдельную группу пользователей, добавить ее в политику Deny log on locally и назначить ее на OU с компьютерами, доступ к которым вы хотите ограничить.
В больших доменах можно использовать комбинацию этих политик. Например, вы хотите запретить пользователям входить на компьютеры других OU.
Для этого в каждой OU нужно создать группу безопасности, куда нужно включить всех пользователей OU.
Совет. Группы можно автоматически наполнять пользователями из OU с помощью PowerShell командлетов Get-ADUser и Add-ADGroupMember таким скриптом:
Import-module ActiveDirectory
$rootOU = “OU= Users,OU=MSK,DC=itoservice,DC=ru”
$group = “corp\msk-users”
Get-ADUser -SearchBase $rootOu -Filter * | ForEach-Object {Add-ADGroupMember -Identity $group -Members $_ }
Затем нужно включить параметр GPO Allow log on locally, добавить в него эту группу (+ различные администраторские группы: Domain Admins, администраторы рабочих станций и прочее) и назначить политику на OU с компьютерами. Таким образом вы разрешите входить на компьютеры только пользователям конкретного OU.
Обновите настройки GPO на клиентах. Теперь при попытке входа пользователя, которому не разрешен локальный метод входа, появится окно с предупреждением:
You cannot log on because the logon method you are using is not allowed on this computer. Please see your network administrator for more information.
Или
The sign-in method you are trying to use isn’t allowed. For more info, contact your network administrator.
Несколько важных моментов касательно данных политик:
- Не стоит применять данные политики, для ограничения доступа к серверам и тем более к контроллерам домена;
- Не включаете эти политики через стандартные GPO: Default Domain Policy или Default Domain Controllers Policy;
- Запрещающая политика имеет больший приоритет;
- Не забывайте про сервисные учетные записи(в том числе gMSA), которые могут использоваться для запуска служб на компьютерах;
- Не стоит применить политики, ограничивающие локальный вход на весь домен. Назначайте их на конкретные OU;
- Пользователи смогут подключаться компьютерам с помощью интерактивных RDP сессий несмотря на запрет локального входа. Для этого нужно, чтобы на компьютере был включен протокол RDP и учетная запись пользователя находилась в группе Remote Desktop Users.
Managing user privileges in Windows 10 by configuring User Rights Assignments security policy offers IT administrators more control over device accessibility and security. User Rights Assignments also allow IT teams to configure more secure networks or extend administrative privileges to users such as for remote IT support specialists.
This blog will break down what User Rights Assignments in Windows 10 do and how to modify its settings to strengthen your security posture and create custom access privileges.
What Are Windows Security Policies?
Windows Security Policies are a set of operating system configurations that govern how users can interact with devices and corporate resources. From access control to enforcing password complexity, security policies ensure that a system operates securely while still adhering to organizational requirements.
The role of User Rights Assignment in Windows security
User Rights Assignment defines what a user or system account is authorized to do on a machine, such as logging on locally, accessing a system over a network, or backing up files. This targeted approach allows custom configurations tailored to different roles, enhancing security without limiting functionality. Always ensure that the chosen group memberships and their access rights align with organizational compliance and operational needs.
Common security policies controlled by User Rights Assignment
-
“Log on locally”
This setting controls who can sign in directly through the device.
-
“Access this computer from the network”
This setting determines who can control a PC remotely. Several types of network protocols, such as NetBIOS require this right to function. The “Deny access to this computer from the network “ right overrides this.
-
“Allow log on through Remote Desktop Services”
This right determines who can access a device’s sign-in screen through Windows’ remote access tool, Remote Desktop Services (formerly known as Terminal Services).
-
“Shut down the system”
This setting specifies which accounts can turn off or reset the Windows device.
-
“Back up files and directories”
This right allows a user or group to bypass permissions that they lack in order to back up critical files for data security.
-
“Take ownership of files or other objects”
This security policy allows users to take ownership of files and other resources, regardless of prior permissions. IT administrators can use this right to recover access to a file on a locked device or to gain ownership of files after an employee leaves the organization.
Step-by-step guide to changing User Rights Assignment settings
Prerequisites for modifying User Rights Assignment in Windows 10
Before making changes to these policies, you must have administrator-level access. If you wish to update a group policy object on the domain controller, you also need admin access to install the Microsoft Management Console (MMC). To change security policy settings on Windows 10, you will need to access either the Local Group Policy Editor or the Local Security Policy Editor.
However, you also need to make sure that you have a compatible version of Windows as some tools, like Local Group Policy Editor, are available only on Windows 10 Pro or Enterprise editions, not the Home version.
How to configure a User Right Assignment using the Local Security Policy console
- Navigate to the Local Security Policy by typing “secpol.msc” into the Start menu search bar.
- Go to the Security Settings, then select Local Policies. You can edit a User Rights Assignment from here.
- Double-click the security policy that you need to modify.
- Modify which users and groups are included by clicking either the “Add user or group…” or “Remove” buttons.
- Click the OK button once you’re finished.
How to configure a security policy setting using the Local Group Policy Editor console
- Go to the Local Group Policy Editor (gpedit.msc).
- Navigate to Computer Configuration > Windows Settings> Security Settings.
- From here, you can click on Local Policies to edit a User Right Assignment setting by double-clicking the security policy.
- You can select which users or groups are included by clicking either the “Add user or group…” or “Remove” buttons.
- Click “OK” to save your changes.
Windows 10 user rights management guide: best practices for configuring User Rights Assignment
1. Avoid overly permissive configurations
Granting excessive permissions increases the chances of misuse, accidental changes, misconfigurations, or even exploitation by cybercriminals. Apply the Least Privilege Access, which dictates that users or groups should only have the minimum rights required to perform their tasks. Make use of the Local Security Policy Editor for granular control of security policy settings.
2. Log and document changes for troubleshooting
Track changes to all changes made to User Rights Assignments to make it easier for technicians to troubleshoot any security configurations. IT documentation software makes it faster and more efficient to log and access information detailing the default and current configurations, along with any history of prior modification.
3. Test changes in a non-production environment before applying them broadly
Changes to User Rights Assignment policies can have far-reaching consequences if not implemented carefully. For example, incorrectly modifying “Access this computer from the network” can lead to losing remote access functionality. You can use a virtual machine with tools like Hyper-V or VMware to create isolated testing environments.
Use cases and practical uses for configuring user privileges on Windows 10
1. Controlling logon permissions
Login privileges allow administrators to define how users can access a system. Restricting logon privileges is highly recommended for kiosk devices or shared workstations. For example, IT administrators can assign the “Log on locally” right to the technician user groups, allowing them to access devices to troubleshoot and resolve any issues remotely.
2. Securing Windows devices and servers
IT administrators should change the security policy settings on Windows 10 to prevent unauthorized access and protect sensitive data. Modifying user rights access policies ensures that access to Windows devices and servers is only given to authorized users and roles. This helps prevent unauthorized access that can lead to data breaches.
3. Compliance management
Modifying local security policy settings makes it easier for IT compliance as it allows organizations in industries like finance or healthcare to meet regulatory standards. For example, PCI compliance requires administrative access to systems managing payment data to reduce risks that user rights access can enforce strict controls over logon privileges and administrative rights to comply with these guidelines.
FAQs
1. What is the difference between User Rights Assignment and NTFS permissions?
A User Rights Assignment defines what actions users or groups are authorized to perform at the system level, such as logon access. NTFS permissions, on the other hand, control users’ access to interact with files and folders stored on an NTFS-formatted drive. For example, a user may have NTFS permission to Read a file in a shared folder but may not be able to access the laptop from the network because of a User Rights Assignment policy.
2. Can User Rights Assignment settings be reverted to default?
Yes, you can use the Local Security Policy Editor to revert User Rights Assignments to the default. Alternatively, for domain-joined systems, Group Policy configurations can enforce standard settings defined by your organization, effectively reverting any local changes directly.
3. Are these changes applicable across all users or just specific accounts?
You can configure User Rights Assignment settings to apply to specific accounts or groups rather than all users.
Managing user privileges in Windows 10 for enhanced security
User Rights Assignment allows IT administrators to proactively protect their Windows systems and effectively manage user access controls. By modifying Local Security Policy settings, IT administrators can ensure that their Windows 10 systems are secure while also ensuring that end-users, technicians, and other stakeholders have the appropriate user privileges to complete their tasks.
Simplify Windows 10 security settings management with NinjaOne Windows Endpoint Management. With NinjaOne, you can get real-time information on all your endpoint devices, manage user permissions at scale, and back up critical files from a single pane of glass. NinjaOne’s automation tools reduce manual workloads by taking care of repetitive tasks so IT professionals can focus on strategic tasks. See NinjaOne in action today – watch a demo, or try it for free.
Для безопасного запуска сторонних сервисов в Windows можно использовать учетную запись пользователя без прав локального администратора. Для этого нужно изменить настройки локальной политики безопасности и предоставить пользователю права входа в качестве службы.
По умолчанию службы Windows запускаются в контексте привилегированных учетных записей (System, Local Service или Network Service). Чтобы ограничить права службы, можно настроить ее запуск из-под обычного пользователя.
Чтобы изменить учетную запись, из-под которой запускается служба из консоли управления службами (services.msc).
- Запустите консоли, найдите нужную службу и откройте ее свойства
- Перейдите на вкладку Log On. По умолчанию служба запускается от имени Local System.
- Чтобы запустить службу от пользователя, включите опцию This account и укажите учетную запись и ее пароль.
- Когда вы сохраните настройки, появится сообщение:
The account svc_user1 has been granted the Log On As A Service right.
Windows сама предоставила права на запуск служб от имени этого пользователя. Чтобы проверить это, откройте редактор локальной GPO (gpedit.msc).
Перейдите в раздел Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment и найдите политику Log on as a service.
Как вы видите, пользователь был добавлен в эту локальную политику безопасности.
Можно предоставить права запуска служб другим пользователям или группам. Нажмите кнопку Add User or Group и укажите имя пользователя/группы.
Чтобы обновить настройки GPO, выполните команду:
gpupdate /force
Кроме разрешающей политики, есть еще и политика, которая позволяет запретить запускать службы от имени некоторых пользователей или групп. Эта политика находится в этом же разделе GPO и называется Deny log on as a service. Запрещающая политика имеет более высокий приоритет. Поэтому если добавить пользователя одновременно в Deny log on as a service и Logon as a service, запустить службу от его имени не получится.
Данная политика разрешает определенным учетным записям запускать от своего имени какой-то процесс, как службу Windows. При запуске такого процесса он регистрируется как служба. При этом пользователю не обязательно входить локально.
Запуск служб от имени непривилегированных пользователей позволяет повысить безопасность и стабильность Windows. Естественно, нужно минимизировать количество аккаунтов, которым вы предоставляете право Logon as a service.
Для предоставления права Logon as a service из командной строки можно использовать утилиту ntrights.exe (входит в состав Windows Server 2003 Resource Kit). Скачать ее можно по ссылке из WebArchive.
После установки Resource Kit, чтобы предоставить пользователю права на запуск служб, выполните команду:
ntrights.exe +r SeServiceLogonRight -u RESLAB\svc_user1
Это добавит учетную запись в локальную политику безопасности.
Чтобы убрать права пользователя:
ntrights.exe -r SeServiceLogonRight -u RESLAB\svc_user1
Если при входе в Windows вы получаете ошибку “Этот метод входа запрещено использовать”, значит результирующие настройки групповых политик на компьютере запрещают локальный вход под этим пользователем. Чаще всего такая ошибка появляется, если вы пытаетесь войти под гостевой учетной записью на обычный компьютер, или под пользователем без прав администратора домена на контроллер домена. Но бывают и другие нюансы.
The sign-in method you're trying to use isn't allowed. For more info, contact your network administrator.
Список пользователей и групп, которым разрешен интерактивный локальный вход на компьютер задается через групповую политику.
- Откройте редактор локальной групповой политики (
gpedit.msc
); - Перейдите в раздел Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment;
- Найдите в списке политику Allow log on locally (Локальный вход в систему);
- В этой политике содержится список групп, которым разрешен локальный вход на этот компьютер;
В зависимости от операционной системы и роли компьютера список групп, которым разрешен локальный вход может отличаться.Например, на рабочих станциях с Windows 10 и рядовых серверах на Windows Server 2022,2019,2016 локальный вход разрешен для следующих групп:
- Administrators
- Backup Operators
- Users
На серверах Windows Server с ролью контроллера домена Active Directory интерактивный вход разрешен для таких локальных и доменных групп:
- Account Operators
- Administrators
- Backup Operators
- Print Operators
- Server Operators
- Вы можете разрешить другим пользователям или группам локальный вход в систему. Для этого можно нажать кнопку Add User or Group, и найти нужных пользователей. Также вы можете, например, запретить пользователям без прав администратора вход на это устройство. Для этого просто удалите группу Users из настроек данной политики;
- После внесения изменения изменений нужно обновить настройки локальных политик командой
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"
Учимся применять важнейший метод аутентификации.
Подсистема контроля доступа 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).