Вот уж не думал, что будет непросто найти перевод группы «Authenticated Users». Но всё-таки получилось! Ниже приведены названия специальных групп (не всех) и их перевод на русский язык (найденные экспериментально).
ВНИМАНИЕ! При поиске по фрагменту названия очень важно соблюдать регистр! Введя «СЕ» найдём группу «СЕТЬ», а вот введя «Сеть» — уже нет. Поэтому данные (по крайней мере по русскому переводу и по возможности на английском языке) приведены в соответствующем регистре.
Знаком * отмечены встроенные группы и идентификаторы. Некоторые группы не стали переводить, а оставили в английском варианте, например, LOCAL SERVICE.
* SYSTEM
* система (Windows 7)
* SYSTEM (Windows Server 2008)
* SERVICE
* СЛУЖБА
* LOCAL SERVICE
* LOCAL SERVICE (именно так!)
* NETWORK SERVICE
* NETWORK SERVICE (именно так!)
* NETWORK
* СЕТЬ
* BATCH
* ПАКЕТНЫЕ ФАЙЛЫ
* INTERACTIVE
* ИНТЕРАКТИВНЫЕ
* REMOTE INTERACTIVE LOGON
* REMOTE INTERACTIVE LOGON (именно так!)
* DIALUP
* УДАЛЕННЫЙ ДОСТУП
* EVERYONE
* Все
* ANONYMOUS LOGON
* АНОНИМНЫЙ ВХОД
* authenticated users
* Прошедшие проверку
* IUSR
* IUSR (именно так!)
* OWNER RIGHTS
* ПРАВА ВЛАДЕЛЬЦА
* CREATOR OWNER
* СОЗДАТЕЛЬ-ВЛАДЕЛЕЦ
* CREATOR GROUP
* ГРУППА-СОЗДАТЕЛЬ
ADMINISTRATOR
Администратор
ADMINISTRATORS
Администраторы
DOMAIN ADMINS
Администраторы домена
USERS
Пользователи
DOMAIN USERS
Пользователи домена
GUEST
Гость
GUESTS
Гости
DOMAIN GUESTS
Гости домена
Конечно, это не полный список. Полный список будет зависеть от операционной системы, языка, включения в домен и других параметров/условий. Например, сюда не вошли:
* SELF
* Дайджест проверка подлинности
* Данная организация
* Другая организация
* КОНТРОЛЛЕРЫ ДОМЕНА ПРЕДПРИЯТИЯ
* ОГРАНИЧЕННЫЕ
* ПОЛЬЗОВАТЕЛЬ СЕРВЕРА ТЕРМИНАЛОВ
* Проверка подлинности NTLM
* Проверка подлинности SChannel
? PROXY
ACCOUNT OPERATORS
BACKUP OPERATORS
DnsAdmins
DnsUpdateProxy
HelpServicesGroup
PRINT OPERATORS
REPLICATOR
SERVER OPERATORS
TelnetClients
Администраторы DHCP
Администраторы SQL
Администраторы WSUS
Администраторы предприятия
Администраторы схемы
Владельцы-создатели групповой политики
Доступ DCOM службы сертификации
Издатели сертификатов
Компьютеры домена
Компьютеры сервера терминалов
Контроллеры домена
Контроллеры домена — только чтение
Контроллеры домена предприятия — только чтение
Криптографические операторы
Операторы архива
Операторы настройки сети
Операторы печати
Операторы сервера
Операторы учета
Пользователи
Пользователи DCOM
Пользователи DHCP
Пользователи домена
Пользователи журналов производительности
Пользователи системного монитора
Пользователи удаленного рабочего стола
Пред-Windows 2000 доступ
Репликатор
Серверы RAS и IAS
Серверы лицензий сервера терминалов
Сертификат этой организации
Создатели отчетов WSUS
Время на прочтение2 мин
Количество просмотров38K
В целях поддержания надлежащего уровня контроля доступа, важно однозначно понимать, что каждый объект в списке управления доступом (ACL) представляет, в том числе встроенные в ОС Windows.
Существует множество встроенных учетных записей с малопонятными именами и неопределенными описаниями, что может привести к путанице в понимании разницы между ними. Очень частый вопрос: «В чем разница между группами Everyone и Authenticated Users?»
Самое важное
Группа Authenticated Users охватывает всех пользователей, вошедших в систему, используя учетную запись и пароль. Группа Everyone охватывает всех пользователей, вошедших в систему с учетной записью и паролем, а также встроенные, незащищённые паролем учетные записи, такие как Guest и LOCAL_SERVICE.
Больше деталей
Если описанное выше показалась вам упрощённым, то дальше чуть больше деталей.
Группа Authenticated Users включает в себя всех пользователей, чья подлинность была подтверждена при входе в систему, в них входят как локальные учетные записи, так и учетные записи доверенных доменов.
Группа же Everyone включает всех членов группы Authenticated Users, а также гостевую учетную запись Guest и некоторые другие встроенные учетные записи, такие как likeSERVICE, LOCAL_SERVICE, NETWORK_SERVICE и др. Гостевая учётная запись Guest по умолчанию отключена, однако если она активна, то она дает возможность попасть в систему без ввода пароля.
Вопреки распространенному мнению, любой, кто вошел в систему анонимно, т.е. не прошедшие процедуру подтверждения подлинности, не будут включены в группу Everyone. Это имело место ранее, но изменено начиная с Windows 2003 и Windows XP (SP2).
Выводы
Когда дело доходит до распределения разрешений, существует один важный вопрос, на который мы должны быть в состоянии ответить: какие конкретные люди имеют доступ к данному ресурсу?
Большую часть разрешений, которые мы видим, даны не конкретным людям, а группам безопасности (и это — правильно), роль которых не всегда очевидна. В результате приходится тратить много времени для выяснения ответа на вопрос выше.
Решение есть. Когда ваш CEO спросит: «Кто имеет доступ к «Зарплатная ведомость.doc»?» вы сможете быстро, уверенно и абсолютно точно дать ответ, вместо предположений после недельных расследований.
На днях решил я накатить групповую политику. Политика была предназначена для пользователей, причем не для всех, поэтому я использовал фильтры безопасности.
Напомню, что по умолчанию права на политику имеет группа Authenticated Users (Прошедшие проверку). При использовании фильтра безопасности мы удаляем эту группу и добавляем только тех, для кого эта политика должна отработать.
Функция стандартная, много раз опробованная. Но на сей раз что то пошло не так 🙁
Политика была назначена на правильную область, в фильтре безопасности находились правильные пользователи, но политика упорно не хотела отрабатывать. Не было никаких ошибок и предупреждений, а gpresult и RSOP просто показывали отсутствие политики в списке примененных к пользователю. Как будто ее не было совсем.
Проверив все что можно и что нельзя, я решил удалить политику и создать ее заново. И вот тут, при настройке фильтра безопасности, я обратил внимание на сообщение, появляющееся при удалении группы Authenticated Users.
Как следует из сообщения, для того, чтобы пользовательская политика смогла успешно отработать на компьютере, у компьютера должно быть право чтения на эту политику. А в группу Authenticated Users входят не только пользователи, но и компьютеры, и при ее удалении компьютер не сможет получить доступ к политике и применить ее.
Это связано с обновлением безопасности MS16-072 от 14 июня 2016 года. Обновление изменяет контекст безопасности, с помощью которого извлекаются политики пользователя. До установки обновления политики извлекаются в контексте безопасности пользователя, после — в контексте компьютера. Это делает невозможным несанкционированное повышение привилегий в том случае, если злоумышленник перехватил трафик между пользовательским компьютером и контроллером домена.
В качестве побочного эффекта при использовании фильтра безопасности компьютеры теряют право чтения и политика не может отработать. Поэтому, для успешного применения политики, назначенной на пользователя, в фильтре безопасности должен присутствовать не только пользователь, но и его компьютер.
Самый простой вариант, это добавить в фильтр группу Domain Computers, что собственно я и сделал. После этого политика успешно применилась.
Какие из этой истории можно сделать выводы? Во первых, при назначении политики на пользователя и использовании фильтров безопасности добавляйте в список группу Domain Computers. Ну и во вторых, не ленитесь читать системные сообщения, в них может быть важная информация. Которая сэкономит вам кучу времени 🙂
Некоторые обновления безопасности приводят к изменению механизма функционирования подсистемы, при этом эти изменения не всегда очевидны и могут идти в разрез с теоритическими знаниями, полученными ранее. Итак, 14 июня 2016 компания Microsoft выпустила бюллютень безопасности MS16-072, в котором объявила о закрытии уязвимости несанкционированного получение прав, если злоумышленник запускает man-in-the-middle (MiTM) атаку на трафик, проходящий между контроллером домена и на целевым компьютером. Закрытие этой уязвимости привело к изменению применения групповых политик (GPO), в случаях, когда использовался механизм Security Filtering для пользователей.
Проблема наблюдается с групповыми политиками применяемыми на пользователя (user scope), и только если изменено применение через Security Filtering. Теперь, если для Security Filtering изменить значение по умолчанию Authenticated Users
на любой список пользователей и/или группу пользователей, например, Domain Users
то данная групповая политика перестанет применяться.
А при попытке диагностики через GPResult, созданные политики или вообще не будут отображаться или появится сообщение, что групповая политика отфильтрована.
Эта проблема возникает в том случае, если было установлено одно из следующих обновлений (или обновлений их заменяющие):
- 3159398 MS16-072: Description of the security update for Group Policy
- 3163017 Cumulative update for Windows 10
- 3163018 Cumulative update for Windows 10 Version 1511 and Windows Server 2016
- 3163016 Cumulative Update for Windows Server 2016
и если отсутствуют разрешения на Read для группы Authenticated Users на объект групповой политики или отсутствуют разрешения на Read для группы Domain Computers. Подробности можно посмотреть тут.
Именно эта пара факторов должна совпасть, если во всех политиках в разделе Security Filtering используется Authenticated Users, то ошибки возникать не будет.
Для решения это проблемы, достаточно вернуть Authenticated Users в настройки Security Filtering, а если это не целесообразно, то для применения политики можно вручную добавить права на чтение для группы Domain Computers.
Чтение и управление правами на GPO при помощи PowerShell
Указанные выше операции можно выполнить вручную, а можно при помощи скрипта PowerShell. Например скрипт ниже выведет список всех групповых политик, у которых в настройках безопасности явно не указана группа Authenticated Users:
Get-GPO -All | foreach-object { if (!($_ | Get-GPPermission -TargetName "Authenticated Users" -TargetType Group -ErrorAction SilentlyContinue)) {$_.DisplayName}}
А для того, чтобы добавить всем политикам без назначенных прав для группы Authenticated Users, можно использовать скрипт, которых для всех групповых политик у которых нет выданных прав для Authenticated Users, добавит права Read для группы Domain Computers.
Get-GPO -All | foreach-object { if (!($_ | Get-GPPermission -TargetName "Authenticated Users" -TargetType Group -ErrorAction SilentlyContinue)) {$_ |Set-GPPermissions -TargetType Group -TargetName "Domain Computers" -PermissionLevel GpoRead}} Last Updated on January 3, 2025 by Deepanshu Sharma
In a Windows environment, there are many built-in accounts with obscure names and descriptions, making it difficult to know what their purpose is. Yet, understanding every entity on an access control list (ACL) is essential for maintaining proper access controls. A question that is commonly asked is: “What’s the difference between the Everyone group and Authenticated Users?”. In simple terms, Authenticated Users includes all users who have logged in with a username and password, while Everyone includes password-protected accounts and built-in accounts such as Guest and LOCAL_SERVICE. The Authenticated Users group includes local and domain user accounts, while the Everyone group includes additional security accounts.
It is important to note that anonymous users are not included in the Everyone group. Most of the time, Windows deals with groups rather than individual users. However, when inspecting permissions, it is crucial to determine which specific users have access to a given resource, which often requires a thorough investigation.
Types of Windows Accounts
As mentioned above, the Authenticated Users group includes all users who are authenticated with valid credentials in the Windows OS, while the Everyone group includes the Authenticated Users group and the Guest account. In Windows XP SP2 and Windows Server 2003, there are changes to the memberships of these groups. Below is a brief explanation of the built-in accounts in Windows:
- Guest account: The Guest account is a member of both groups in Windows 2000 AD and XP, but only a member of the Everyone group in Windows 2003 AD and XP SP2.
- Anonymous account: The Anonymous account is a member of the Everyone group in Windows 2000 AD and XP, but is not a member of the Authenticated Users group. In Windows 2003 AD and XP SP2, the Anonymous account is not a member of either group by default, unless a specific security policy setting is enabled.
- Everyone group: The Everyone group is useful for granting permissions to all users, but it includes the Guest and Anonymous accounts, which may not be desirable in some cases.
- Authenticated Users group: The Authenticated Users group excludes the Guest and Anonymous accounts and is useful when restricting access to valid, non-Guest, and non-Anonymous users.
Difference Between Everyone, Users, and Authenticated Users Groups
It may not be immediately clear what sets apart the Everyone, Users, and Authenticated Users groups based on their names alone. However, it’s worth noting that the Everyone group is the least secure as it truly encompasses all users. Frequently, the Everyone group contains the same set of users as the Users and Authenticated Users groups. Nonetheless, if the Guest account is enabled, users who log in as Guest are part of Everyone but not Users or Authenticated Users. The distinction between Users and Authenticated Users groups is a bit more complex. While one might assume that all users are authenticated users because they must authenticate, the presence of a separate group called Authenticated Users serves a purpose, as not all members of the Users group are authenticated.
Windows networks allow for computer-to-computer connections involving null sessions, which are used for exchanging lists of shared resources. Workstations also employ null sessions to connect to domain controllers before users authenticate to the domain. It is important not to confuse null sessions with Anonymous authentication in IIS, as they are entirely different concepts. Users who use Anonymous authentication in IIS use the pre-existing IUSR_computername account and are members of Everyone, Users, and Authenticated Users groups. The inclusion of null connections in the User group poses a security issue, prompting Microsoft to introduce the Authenticated Users group around the time of Windows NT 4.0 Service Pack 3 (SP3). This group includes authenticated users but excludes null sessions. Hence, for NTFS permissions, it is advisable to use Authenticated Users over Everyone.
How Lepide Helps Keep Active Directory Users and Groups Secure
The Lepide Data Security Platform provides a variety of features for effectively safeguarding Active Directory Groups. The platform uses advanced algorithms to monitor and analyze user behavior, detecting any unusual patterns that may jeopardize data security. It is also capable of identifying risky user actions and sending real-time notifications to administrators regarding potential security threats. The platform will scan your repositories and classify sensitive data as it is found, as well as classify data at the point of creation/modification. Furthermore, it determines the number of privileged users and recognizes those with excessive permissions, empowering administrators to take the necessary steps. The platform also automates the management of inactive user accounts, mitigating the risk of unauthorized access. By setting threshold alerts, administrators can receive instant notifications when specific conditions are met, enabling proactive security monitoring. Lastly, the platform facilitates the easy reversal of unauthorized or unwanted changes made to Active Directory and Group Policy, allowing administrators to uphold the integrity of their systems.
If you’d like to see how the Lepide Data Security Platform can help you secure and manage your Active Directory Groups, schedule a demo with one of our engineers.
- Active Directory