Manage User Accounts in Windows Server Essentials

Applies To: Windows Server 2016 Essentials, Windows Server 2012 R2 Essentials, Windows Server 2012 Essentials

The Users page of the Windows Server Essentials Dashboard centralizes information and tasks that help you manage the user accounts on your small business network. For an overview of the Users Dashboard, see Dashboard Overview.

Managing user accounts

The following topics provide information about how to use the Windows Server Essentials Dashboard to manage the user accounts on the server:

Add a user account

When you add a user account, the assigned user can log on to the network, and you can give the user permission to access network resources such as shared folders and the Remote Web Access site. Windows Server Essentials includes the Add a User Account Wizard that helps you:

Provide a name and password for the user account.

Define the account as either an administrator or as a standard user.

Select which shared folders the user account can access.

Specify if the user account has remote access to the network.

Select email options if applicable.

Assign a Microsoft Online Services account (referred to as a Microsoft 365 account in Windows Server Essentials) if applicable.

Assign user groups ( Windows Server Essentials only).

• Non-ASCII characters are not supported in Microsoft Azure Active Directory (Azure AD). Do not use any non-ASCII characters in your password, if your server is integrated with Azure AD.
  • The email options are only available if you install an add-in that provides email service.

To add a user account

Open the Windows Server Essentials Dashboard.

On the navigation bar, click Users.

In the Users Tasks pane, click Add a user account. The Add a User Account Wizard appears.

Follow the instructions to complete the wizard.

Remove a user account

When you choose to remove a user account from the server, a wizard deletes the selected account. Because of this, you can no longer use the account to log on to the network or to access any of the network resources. As an option, you can also delete the files for the user account at the same time that you remove the account. If you do not want to permanently remove the user account, you can deactivate the user account instead to suspend access to network resources.

If a user account has a Microsoft online account assigned, when you remove the user account, the online account also is removed from Microsoft Online Services, and the user’s data, including email, is subject to data retention policies in Microsoft Online Services. If you want to retain user data for the online account, deactivate the user account instead of removing it. For more information, see Manage Online Accounts for Users.

To remove a user account

Open the Windows Server Essentials Dashboard.

On the navigation bar, click Users.

In the list of user accounts, select the user account that you want to remove.

In the Tasks pane, click Remove the user account. The Delete a User Account Wizard appears.

On the Do you want to keep the files? page of the wizard, you can choose to delete the user’s files, including File History backups and the redirected folder for the user account. To keep the user’s files, leave the check box empty. After making your selection, click Next.

Click Delete account.

After you remove a user account, the account no longer appears in the list of user accounts. If you chose to delete the files, the server permanently deletes the user’s folder from the Users server folder and from the File History Backups server folder.

If you have an integrated email provider, the email account assigned to the user account will also be removed.

View user accounts

The Users section of the Windows Server Essentials Dashboard displays a list of network user accounts. The list also provides additional information about each account.

To view a list of user accounts

Open the Windows Server Essentials Dashboard.

On the main navigation bar, click Users.

The Dashboard displays a current list of user accounts.

To view or change properties for a user account

In the list of user accounts, select the account for which you want to view or change properties.

In the Tasks pane, click View the account properties. The Properties page for the user account appears.

Click a tab to display the properties for that account feature.

To save any changes that you make to the user account properties, click Apply.

Change the display name for the user account

The display name is the name that appears in the Name column on the Users page of the Dashboard. Changing the display name does not change the logon or sign-in name for a user account.

To change the display name for a user account

Open the Windows Server Essentials Dashboard.

On the navigation bar, click Users.

In the list of user accounts, select the user account that you want to change.

In the Tasks pane, click View the account properties. The Properties page for the user account appears.

On the General tab, type a new First name and Last name for the user account, and then click OK.

The new display name appears in the list of user accounts.

Activate a user account

When you activate a user account, the assigned user can log on to the network and access network resources to which the account has permission, such as shared folders and the Remote Web Access site.

You can only activate a user account that is deactivated. You cannot activate a user account after you remove it from the server.

To activate a user account

Open the Windows Server Essentials Dashboard.

On the navigation bar, click Users.

In the list view, select the user account that you want to activate.

In the Tasks pane, click Activate the user account.

In the confirmation window, click Yes to confirm your action.

After you activate a user account, the status for the account displays Active. The user account regains the same access rights that were assigned prior to account deactivation.

If you have an integrated email provider, the email account assigned to the user account will also be activated.

Deactivate a user account

When you deactivate a user account, account access to the server is temporarily suspended. Because of this, the assigned user cannot use the account to access network resources such as shared folders or the Remote Web Access site until you activate the account.

If the user account has a Microsoft online account assigned, the online account is also deactivated. The user cannot use resources in Microsoft 365 and other online services that you subscribe to, but the user’s data, including email, is retained in Microsoft Online Services.

You can only deactivate a user account that is currently active.

To deactivate a user account

Open the Windows Server Essentials Dashboard.

On the navigation bar, click Users.

In the list view, select the user account that you want to deactivate.

In the Tasks pane, click Deactivate the user account.

In the confirmation window, click Yes to confirm your action.

After you deactivate a user account, the status for the account displays Inactive.

If you have an integrated email provider, the email account assigned to the user account will also be deactivated.

Understand user accounts

A user account provides important information to Windows Server Essentials, which enables individuals to access information that is stored on the server, and makes it possible for individual users to create and manage their files and settings. Users can log on to any computer on the network if they have a Windows Server Essentials user account and they have permissions to access a computer. Users access their user accounts with their user name and password.

There are two main types of user accounts. Each type gives users a different level of control over the computer:

Standard accounts are for everyday computing. The standard account helps protect your network by preventing users from making changes that affect other users, such as deleting files or changing network settings.

Administrator accounts provide the most control over a computer network. You should assign the administrator account type only when necessary.

Manage user accounts using the Dashboard

Windows Server Essentials makes it possible to perform common administrative tasks by using the Windows Server Essentials Dashboard. By default, the Users page of the Dashboard includes two tabs: Users and Users Groups.

• If you integrate your server that is running Windows Server Essentials with Microsoft 365, a new tab called Distribution Groups is also added within the Users page of the Dashboard.
  • In Windows Server Essentials, the Users page of the Dashboard includes only a single tab — Users.

The Users tab includes the following:

A list of user accounts, which displays:

The name of the user.

The Logon name for the user account.

Whether the user account has Anywhere Access permission. Anywhere Access permission for a user account is either Allowed or Not allowed.

Whether the File History for this user account is managed by the server running Windows Server Essentials. The File History status for a user account is either Managed or Not managed.

The level of access that is assigned to the user account. You can assign either Standard user access or Administrator access for a user account.

The user account status. A user account can be Active, Inactive, or Incomplete.

In Windows Server Essentials, if the server is integrated with Microsoft 365 or Windows Intune, the Microsoft online account is displayed.

In Windows Server Essentials, if the server is integrated with Microsoft 365, the status of the account (known in Windows Server Essentials as the Microsoft online account) for the user account is displayed.

A details pane with additional information about a selected user account.

A tasks pane that includes:

A set of user account administrative tasks such as viewing and removing user accounts, and changing passwords.

Tasks that allow you to globally set or change settings for all user accounts in the network.

The following table describes the various user account tasks that are available from the Users tab. Some of the tasks are user account-specific, and they are only visible when you select a user account in the list.

If you integrate Microsoft 365 with Windows Server Essentials, additional tasks will become available. For more information, see Manage Online Accounts for Users.

User account tasks in the Dashboard

Task name	Description
View the account properties	Enables you to view and change the properties of the selected user account, and to specify folder access permissions for the account.
Deactivate the user account	A user account that is deactivated cannot log on to the network or access network resources such as shared folders or printers.
Activate the user account	A user account that is activated can log on to the network and can access network resources as defined by the account permissions.
Remove the user account	Enables you to remove the selected user account.
Change the user account password	Enables you to reset the network password for the selected user account.
Add a user account	Starts the Add a User Account Wizard, which enables you to create a single new user account that has either standard user access or administrator access.
Assign a Microsoft online account	Adds a Microsoft online account to the local network user account that is selected.

This task is displayed when your server is integrated with Microsoft online services, such as Microsoft 365. Add Microsoft online accounts Adds Microsoft online accounts and associates them to local network user accounts.

This task is displayed when your server is integrated with Microsoft online services, such as Microsoft 365. Set the password policy Enables you to change the values of the password polices for your network. Import Microsoft online accounts Performs a bulk import of accounts from Microsoft online services into the local network.

This task is displayed when your server is integrated with Microsoft online services, such as Microsoft 365. Refresh Refreshes the Users tab.

This task is applicable to Windows Server Essentials. Change File History settings Enables you to change File History settings, such as backup frequency, or backup duration.

This task is applicable to Windows Server Essentials. Export all remote connections Creates a .CSV-format file of all remote connections to the server that have occurred over the past 30 days.

Managing passwords and access

The following topics provide information about how to use the Windows Server Essentials Dashboard to manage user account passwords and user access to the shared folders on the server:

Руководство по настройке защищенных учетных записей Guidance about how to configure protected accounts

Область применения. Windows Server 2016, Windows Server 2012 R2, Windows Server 2012 Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

С помощью атаки с передачей хэша (PtH) злоумышленник может пройти проверку подлинности для доступа к удаленному серверу или услуге, используя исходный NTLM-хэш пользовательского пароля (или другие производные учетных данных). Through Pass-the-hash (PtH) attacks, an attacker can authenticate to a remote server or service by using the underlying NTLM hash of a user’s password (or other credential derivatives). Ранее корпорация Майкрософт опубликовала руководство по уменьшению вреда от атак типа pass-the-hash. Microsoft has previously published guidance to mitigate pass-the-hash attacks. В состав Windows Server 2012 R2 входят новые функции, помогающие устранить подобные атаки. Windows Server 2012 R2 includes new features to help mitigate such attacks further. Подробную информацию об остальных функциях безопасности, направленных на защиту от кражи учетных данных, см. в разделе Защита учетных данных и управление ими. For more information about other security features that help protect against credential theft, see Credentials Protection and Management. В этом разделе описан процесс настройки следующих новых функций: This topic explains how to configure the following new features:

В Windows 8.1 и Windows Server 2012 R2 встроены дополнительные средства защиты для предотвращения кражи учетных данных, рассмотренные в следующих статьях: There are additional mitigations built in to Windows 8.1 and Windows Server 2012 R2 to help protect against credential theft, which are covered in the following topics:

Защищенные пользователи Protected Users

«Защищенные пользователи» — новая глобальная группа безопасности, в которую вы можете добавлять новых или уже зарегистрированных пользователей. Protected Users is a new global security group to which you can add new or existing users. Windows 8.1 устройства и узлы Windows Server 2012 R2 имеют особое поведение для членов этой группы, чтобы обеспечить лучшую защиту от кражи учетных данных. Windows 8.1 devices and Windows Server 2012 R2 hosts have special behavior with members of this group to provide better protection against credential theft. Для члена группы Windows 8.1ное устройство или узел Windows Server 2012 R2 не кэширует учетные данные, которые не поддерживаются для защищенных пользователей. For a member of the group, a Windows 8.1 device or a Windows Server 2012 R2 host does not cache credentials that are not supported for Protected Users. Члены этой группы не имеют дополнительной защиты, если они вошли на устройство под управлением более ранней версии Windows, чем Windows 8.1. Members of this group have no additional protection if they are logged on to a device that runs a version of Windows earlier than Windows 8.1.

Члены группы «защищенные пользователи», которые вошли в Windows 8.1 устройства и узлы Windows Server 2012 R2, больше не могут использовать: Members of the Protected Users group who are signed-on to Windows 8.1 devices and Windows Server 2012 R2 hosts can no longer use:

Делегирование учетных данных по умолчанию (CredSSP) — учетные данные в виде обычного текста не кэшируются, даже если включена политика делегирования учетных данных по умолчанию. Default credential delegation (CredSSP) — plaintext credentials are not cached even when the Allow delegating default credentials policy is enabled

Дайджест Windows — учетные данные в виде обычного текста не кэшируются, даже если они активны. Windows Digest — plaintext credentials are not cached even when they are enabled

Кэширование NTLM- и NTOWF-данных не выполняется. NTLM — NTOWF is not cached

Долговременные ключи Kerberos — билет предоставления билета (TGT) Kerberos получается при входе и не может быть повторно выдан автоматически. Kerberos long term keys — Kerberos ticket-granting ticket (TGT) is acquired at logon and cannot be re-acquired automatically

Автономный вход — создание кэшированного средства проверки входа не производится. Sign-on offline — the cached logon verifier is not created

Если функциональный уровень домена — Windows Server 2012 R2, члены группы больше не могут: If the domain functional level is Windows Server 2012 R2 , members of the group can no longer:

Выполнять проверку подлинности NTLM Authenticate by using NTLM authentication

Использовать для предварительной проверки подлинности Kerberos алгоритм шифрования DES или наборы шифров RC4 Use Data Encryption Standard (DES) or RC4 cipher suites in Kerberos pre-authentication

Получать полномочия с помощью ограниченного или неограниченного делегирования Be delegated by using unconstrained or constrained delegation

Выполнять продление пользовательских билетов (TGT) и использовать их более 4 часов. Renew user tickets (TGTs) beyond the initial 4-hour lifetime

Чтобы добавить пользователей в группу, можно использовать средства пользовательского интерфейса , такие как центр администрирования Active Directory (ADAC) или Active Directory пользователи и компьютеры, или средство командной строки, например dsmod Group, или командлет Windows PowerShellAdd-адграупмембер . To add users to the group, you can use UI tools such as Active Directory Administrative Center (ADAC) or Active Directory Users and Computers, or a command-line tool such as Dsmod group, or the Windows PowerShellAdd-ADGroupMember cmdlet. Учетные записи служб и компьютеров не должны входить в группу защищенных пользователей. Accounts for services and computers should not be members of the Protected Users group. Членство для этих учетных записей предполагает отсутствие локальной защиты, поскольку пароль или сертификат всегда доступны на главном компьютере. Membership for those accounts provides no local protections because the password or certificate is always available on the host.

Ограничения проверки подлинности нельзя обойти, т. е. члены высокопривилегированных групп, такие как администраторы предприятия или доменов, подвержены тем же ограничениям, что и другие члены группы «Защищенные пользователи». The authentication restrictions have no workaround, which means that members of highly privileged groups such as the Enterprise Admins group or the Domain Admins group are subject to the same restrictions as other members of the Protected Users group. Если все члены таких групп добавлены в группу «защищенные пользователи», все эти учетные записи могут быть заблокированы. Никогда не следует добавлять все учетные записи с высоким уровнем привилегий в группу «защищенные пользователи», пока вы не тщательно протестировали потенциальное воздействие. If all members of such groups are added to the Protected Users group, it is possible for all of those accounts to be locked out. You should never add all highly privileged accounts to the Protected Users group until you have thoroughly tested the potential impact.

Члены группы «Защищенные пользователи» должны иметь возможность проверки подлинности при помощи протокола Kerberos с алгоритмом AES. Members of the Protected Users group must be able to authenticate by using Kerberos with Advanced Encryption Standards (AES). В этом методе для учетных записей в Active Directory требуются ключи AES. This method requires AES keys for the account in Active Directory. У встроенного администратора нет ключа AES, если пароль не был изменен на контроллере домена под управлением Windows Server 2008 или более поздней версии. The built-in Administrator does not have an AES key unless the password was changed on a domain controller that runs Windows Server 2008 or later. Кроме того, заблокирована любая учетная запись с паролем, который был изменен на контроллере домена под управлением более ранней версии Windows Server. Поэтому следуйте приведенным ниже рекомендациям. Additionally, any account, which has a password that was changed at a domain controller that runs an earlier version of Windows Server, is locked out. Therefore, follow these best practices:

Не проверяйте в доменах, если только все контроллеры домена работают под управлением Windows Server 2008 или более поздней версии. Do not test in domains unless all domain controllers run Windows Server 2008 or later.

Измените пароли для всех учетных записей домена, созданных раньше домена. Change password for all domain accounts that were created before the domain was created. В противном случае успешная проверка подлинности для этих учетных записей исключается. Otherwise, these accounts cannot be authenticated.

Измените пароль для каждого пользователя перед добавлением учетной записи в группу защищенные пользователи или убедитесь, что пароль был недавно изменен на контроллере домена под управлением Windows Server 2008 или более поздней версии. Change password for each user before adding the account to the Protected Users group or ensure that the password was changed recently on a domain controller that runs Windows Server 2008 or later.

Требования для использования защищенных учетных записей Requirements for using protected accounts

Для использования защищенных учетных записей должны выполняться следующие требования. Protected accounts have the following deployment requirements:

Чтобы обеспечить ограничения на стороне клиента для защищенных пользователей, узлы должны работать под управлением Windows 8.1 или Windows Server 2012 R2. To provide client-side restrictions for Protected Users, hosts must run Windows 8.1 or Windows Server 2012 R2 . Пользователю требуется лишь войти в учетную запись, принадлежащую к группе «Защищенные пользователи». A user only has to sign-on with an account that is a member of a Protected Users group. В этом случае группу защищенных пользователей можно создать, передавая роль эмулятора основного контроллера домена на контроллер домена, работающий под управлением Windows Server 2012 R2. In this case, the Protected Users group can be created by transferring the primary domain controller (PDC) emulator role to a domain controller that runs Windows Server 2012 R2 . После этого объект группы реплицируется на другой контроллер домена; роль эмулятора может быть передана доменному контроллеру под управлением более ранних версий Windows Server. After that group object is replicated to other domain controllers, the PDC emulator role can be hosted on a domain controller that runs an earlier version of Windows Server.

Чтобы обеспечить ограничения на стороне контроллера домена для защищенных пользователей, необходимо ограничить использование проверки подлинности NTLM и других ограничений, если функциональный уровень домена должен быть Windows Server 2012 R2. To provide domain controller-side restrictions for Protected Users, that is to restrict usage of NTLM authentication, and other restrictions, the domain functional level must be Windows Server 2012 R2 . Дополнительные сведения о функциональных уровнях см. в разделе Общее представление о режимах работы доменных служб Active Directory (AD DS). For more information about functional levels, see Understanding Active Directory Domain Services (AD DS) Functional Levels.

Диагностика неполадок событий, связанных с группой защищенных пользователей Troubleshoot events related to Protected Users

В этом подразделе рассматривается использование новых журналов для диагностики неполадок событий, связанных с группой «Защищенные пользователи», а также возможные действия защищенных пользователей для решения проблем, связанных со сроком действия билетов предоставления билетов (TGT) или делегированием. This section covers new logs to help troubleshoot events that are related to Protected Users and how Protected Users can impact changes to troubleshoot either ticket-granting tickets (TGT) expiration or delegation issues.

Новые журналы для защищенных пользователей New logs for Protected Users

Для устранения неполадок с событиями, связанными с защищенными пользователями, доступны два новых журнала операций администрирования: журнал защищенных пользователей клиента и сбои защищенных пользователей — журнал контроллера домена. Two new operational administrative logs are available to help troubleshoot events that are related to Protected Users: Protected User — Client Log and Protected User Failures — Domain Controller Log. Новые журналы можно найти при помощи средства просмотра событий. По умолчанию они неактивны. These new logs are located in Event Viewer and are disabled by default. Чтобы включить журнал, щелкните Журналы приложений и служб, затем нажмите Майкрософт, щелкните Windows, нажмите Проверка подлинности, выберите журнал и щелкните Действие (или щелкните по журналу правой кнопкой мыши), после чего нажмите Включить журнал. To enable a log, click Applications and Services Logs, click Microsoft, click Windows, click Authentication, and then click the name of the log and click Action (or right-click the log) and click Enable Log.

Диагностика неполадок, связанных с временем жизни TGT Troubleshoot TGT expiration

В общем случае контроллер домена устанавливает время жизни TGT и срок его продления в зависимости от политики домена, как видно в окне редактора управления групповыми политиками на следующем рисунке. Normally, the domain controller sets the TGT lifetime and renewal based on the domain policy as shown in the following Group Policy Management Editor window.

Для группы Защищенные пользователи строго определены следующие параметры. For Protected Users, the following settings are hard-coded:

Максимальное время жизни пользовательского билета: 240 минут Maximum lifetime for user ticket: 240 minutes

Максимальное время продления пользовательского билета: 240 минут Maximum lifetime for user ticket renewal: 240 minutes

Диагностика неполадок, связанных с делегированием Troubleshoot delegation issues

Ранее, если технология, использующая делегирование Kerberos, выходила из строя, проверялось, установлен ли для учетной записи клиента параметр Учетная запись важна и не может быть делегирована. Previously, if a technology that uses Kerberos delegation was failing, the client account was checked to see if Account is sensitive and cannot be delegated was set. Однако если учетная запись клиента входит в группу Защищенные пользователи, этот параметр может быть не настроен в центре администрирования Active Directory (ADAC). However, if the account is a member of Protected Users, it might not have this setting configured in Active Directory Administrative Center (ADAC). Поэтому в случае проблем с делегированием следует проверить, установлен ли указанный параметр и входит ли учетная запись в группу «Защищенные пользователи». As a result, check the setting and group membership when you troubleshoot delegation issues.

Аудит попыток проверки подлинности Audit authentication attempts

Для явного аудита попыток проверки подлинности членов группы Защищенные пользователи вы можете продолжить сохранять события аудита в журнале безопасности или же собирать данные в новых операционных журналах администрирования. To audit authentication attempts explicitly for the members of the Protected Users group, you can continue to collect security log audit events or collect the data in the new operational administrative logs. Подробную информацию см. в разделе Политики проверки подлинности и приемники команд политик проверки подлинности. For more information about these events, see Authentication Policies and Authentication Policy Silos

Защита служб и компьютеров со стороны контроллера домена Provide DC-side protections for services and computers

Учетные записи служб и компьютеров не должны входить в группу Защищенные пользователи. Accounts for services and computers cannot be members of Protected Users. В этом подразделе описываются средства защиты на базе контроллера домена, применяемые для этих учетных записей. This section explains which domain controller-based protections can be offered for these accounts:

Отклонение проверки подлинности NTLM: Настраивается только с помощью политик блокировки NTLM. Reject NTLM authentication: Only configurable via NTLM block policies

Отклонение стандарта шифрования данных (DES) в предварительной проверке подлинности Kerberos. контроллеры домена Windows Server 2012 R2 не принимают алгоритм DES для учетных записей компьютеров, если они не настроены только для DES, так как каждая версия Windows, выпущенная с помощью Kerberos, также поддерживает RC4. Reject Data Encryption Standard (DES) in Kerberos pre-authentication: Windows Server 2012 R2 domain controllers do not accept DES for computer accounts unless they are configured for DES only because every version of Windows released with Kerberos also supports RC4.

Отклонение при использовании RC4 в предварительной проверке подлинности Kerberos: нельзя настроить. Reject RC4 in Kerberos pre-authentication: not configurable.

Хотя можно изменить конфигурацию поддерживаемых способов шифрования, не рекомендуется менять эти настройки для учетных записей компьютеров без предварительного тестирования в целевой среде. Although it is possible to change the configuration of supported encryption types, it is not recommended to change those settings for computer accounts without testing in the target environment.

Ограничение времени жизни пользовательских билетов (TGT) до 4-х часов: используйте политики проверки подлинности. Restrict user tickets (TGTs) to an initial 4-hour lifetime: Use Authentication Policies.

Запретить ограниченное и неограниченное делегирование: чтобы ограничить учетную запись, откройте центр администрирования Active Directory (ADAC) и отметьте флажком параметр Учетная запись важна и не может быть делегирована . Deny delegation with unconstrained or constrained delegation: To restrict an account, open Active Directory Administrative Center (ADAC) and select the Account is sensitive and cannot be delegated check box.

Политики аутентификации Authentication policies

Политики проверки подлинности — новый контейнер доменных служб Active Directory, содержащий объекты политики проверки подлинности. Authentication Policies is a new container in AD DS that contains authentication policy objects. Вы можете настроить политики проверки подлинности, чтобы защититься от кражи учетных данных, например ограничить время жизни TGT для учетных записей или добавить прочие условия, связанные с утверждениями. Authentication policies can specify settings that help mitigate exposure to credential theft, such as restricting TGT lifetime for accounts or adding other claims-related conditions.

В Windows Server 2012 динамический контроль доступа представил Active Directory класс объекта области леса, именуемый Центральной политикой доступа, чтобы обеспечить простой способ настройки файловых серверов в Организации. In Windows Server 2012 , Dynamic Access Control introduced an Active Directory forest-scope object class called Central Access Policy to provide an easy way to configure file servers across an organization. В Windows Server 2012 R2 для применения конфигурации проверки подлинности к классам учетных записей в доменах Windows Server 2012 R2 можно использовать новый класс объектов, именуемый политикой проверки подлинности (objectClass msDS-АуснполиЦиес). In Windows Server 2012 R2 , a new object class called Authentication Policy (objectClass msDS-AuthNPolicies) can be used to apply authentication configuration to account classes in Windows Server 2012 R2 domains. Классы учетных записей Active Directory. Active Directory account classes are:

User (Пользователь) User

Управляемые учетные записи служб и групповые управляемые учетные записи служб (GMSA) Managed Service Account and group Managed Service Account (GMSA)

Быстрое обновление Kerberos Quick Kerberos refresher

Протокол проверки подлинности Kerberos использует три способа обмена, также известных как подпротоколы. The Kerberos authentication protocol consists of three types of exchanges, also known as subprotocols:

Обмен AS — обмен службы проверки подлинности (KRB_AS_*) The Authentication Service (AS) Exchange (KRB_AS_*)

Обмен TGS — обмен службы предоставления билетов (KRB_TGS_*) The Ticket-Granting Service (TGS) Exchange (KRB_TGS_*)

Обмен AP — обмен между клиентом и сервером (KRB_AP_*) The Client/Server (AP) Exchange (KRB_AP_*)

В качестве Exchange клиент использует пароль учетной записи или закрытый ключ для создания предварительной проверки подлинности для запроса билета предоставления билета (TGT). The AS exchange is where the client uses the account’s password or private key to create a pre-authenticator to request a ticket-granting ticket (TGT). Это происходит при первом входе пользователя или при первой необходимости билета службы. This happens at user sign-on or the first time a service ticket is needed.

В службе TGS Exchange используется TGT учетной записи для создания средства проверки подлинности для запроса билета службы. The TGS exchange is where the account’s TGT is used to create an authenticator to request a service ticket. Это происходит при необходимости подключения с успешной проверкой подлинности. This happens when an authenticated connection is needed.

Обмен AP выполняется, если в протоколе приложения содержатся данные и он не подвержен влиянию политик проверки подлинности. The AP exchange occurs as typically as data inside the application protocol and is not impacted by authentication policies.

Обзор Overview

Политики проверки подлинности позволяют дополнить группу защищенных пользователей, позволяя применять к учетным записям настраиваемые ограничения и ограничивая учетные записи служб и компьютеров. Authentication policies complement Protected Users by providing a way to apply configurable restrictions to accounts and by providing restrictions for accounts for services and computers. Политики проверки подлинности используются при обмене AS и обмене TGS. Authentication policies are enforced during either the AS exchange or the TGS exchange.

Вы можете ограничить начальную проверку подлинности или обмен AS, настроив You can restrict initial authentication or the AS exchange by configuring:

Время жизни TGT A TGT lifetime

Условия управления доступом для ограничения входа пользователей, которые должны выполняться устройствами, инициирующими обмен AS. Access control conditions to restrict user sign-on, which must be met by devices from which the AS exchange is coming

Вы можете ограничить запросы билетов служб с помощью обмена TGS, настроив You can restrict service ticket requests through a ticket-granting service (TGS) exchange by configuring:

• Условия управления доступом, которые должны выполняться клиентом (пользователь, служба или компьютер) или устройством, инициирующим обмен TGS Access control conditions which must be met by the client (user, service, computer) or device from which the TGS exchange is coming

Требования для использования политик проверки подлинности Requirements for using authentication policies

Политика Policy	Требования Requirements
Возможность настройки времени жизни TGT Provide custom TGT lifetimes	Домены учетных записей функционального уровня домена Windows Server 2012 R2 Windows Server 2012 R2 domain functional level account domains
Ограничение входа пользователей Restrict user sign-on	— Домены учетных записей режима работы домена Windows Server 2012 R2 с поддержкой динамического контроля доступа — Windows Server 2012 R2 domain functional level account domains with Dynamic Access Control support — Устройства Windows 8, Windows 8.1, Windows Server 2012 или Windows Server 2012 R2 с поддержкой динамического управления доступом — Windows 8, Windows 8.1, Windows Server 2012 or Windows Server 2012 R2 devices with Dynamic Access Control support
Ограничение выдачи билетов служб на основе учетных записей пользователей и групп безопасности Restrict service ticket issuance that is based on user account and security groups	Домены ресурсов функционального уровня домена Windows Server 2012 R2 Windows Server 2012 R2 domain functional level resource domains
Ограничение выдачи билетов служб на основе требований пользователя или учетной записи, групп безопасности или требований устройства Restrict service ticket issuance based on user claims or device account, security groups, or claims	Домены ресурсов функционального уровня домена Windows Server 2012 R2 с поддержкой динамического управления доступом Windows Server 2012 R2 domain functional level resource domains with Dynamic Access Control support

Ограничение учетных записей пользователей для особых устройств и главных компьютеров. Restrict a user account to specific devices and hosts

Ценные учетные записи с правами администратора должны входить в группу Защищенные пользователи. A high-value account with administrative privilege should be a member of the Protected Users group. По умолчанию группа Защищенные пользователи пуста. By default, no accounts are members of the Protected Users group. Перед тем как добавить в нее учетные записи, настройте поддержку контроллера домена и создайте политику аудита, чтобы исключить проблемы с блокированием. Before you add accounts to the group, configure domain controller support and create an audit policy to ensure that there are no blocking issues.

Настройка поддержки контроллера домена Configure domain controller support

Домен учетной записи пользователя должен быть на уровне работы домена Windows Server 2012 R2 (ДФЛ). The user’s account domain must be at Windows Server 2012 R2 domain functional level (DFL). Убедитесь, что все контроллеры домена работают под Windows Server 2012 R2, а затем используйте Active Directory домены и отношения доверия, чтобы повысить ДФЛ до windows Server 2012 R2. Ensure all the domain controllers are Windows Server 2012 R2 , and then use Active Directory Domains and Trusts to raise the DFL to Windows Server 2012 R2 .

Настройка поддержки динамического контроля доступа To configure support for Dynamic Access Control

В окне настройки политики контроллеров доменов по умолчанию выберите пункт Включена, чтобы включить Поддержку центра распространения ключей для утверждений, комплексной проверки подлинности и защиты Kerberos по следующему адресу: Конфигурация компьютера | Административные шаблоны | Система | KDC. In the Default Domain Controllers Policy, click Enabled to enable Key Distribution Center (KDC) client support for claims, compound authentication and Kerberos armoring in Computer Configuration | Administrative Templates | System | KDC.

В поле Параметры в раскрывающемся списке выберите Всегда предоставлять утверждения. Under Options, in the drop-down list box, select Always provide claims.

Поддерживается также параметр, но так как домен находится в Windows Server 2012 R2 ДФЛ, если контроллеры доменов всегда предоставляют утверждения, то при использовании устройств и узлов, не поддерживающих утверждения, для подключения к службам, поддерживающим утверждения, они будут выполнять проверку доступа на основе утверждений. Supported can also be configured, but because the domain is at Windows Server 2012 R2 DFL, having the DCs always provide claims will allow user claims-based access checks to occur when using non-claims aware devices and hosts to connect to claims-aware services.

Настройка незащищенных запросов на проверку подлинности приведет к ошибкам проверки подлинности из любой операционной системы, которая не поддерживает защиту Kerberos, например Windows 7 и предыдущие операционные системы, или операционные системы, начиная с Windows 8, которые не были настроены для поддержки явным образом. Configuring Fail unarmored authentication requests will result in authentication failures from any operating system which does not support Kerberos armoring, such as Windows 7 and previous operating systems, or operating systems beginning with Windows 8, which have not been explicitly configured to support it.

Создание средства аудита учетной записи пользователя для политики проверки подлинности с помощью ADAC Create a user account audit for authentication policy with ADAC

Откройте центр администрирования Active Directory (ADAC). Open Active Directory Administrative Center (ADAC).

Выбранный узел проверки подлинности является видимым для доменов, которые находятся в Windows Server 2012 R2 ДФЛ. The selected Authentication node is visible for domains which are at Windows Server 2012 R2 DFL. Если узел не отображается, повторите попытку, используя учетную запись администратора домена из домена, который находится на сервере Windows Server 2012 R2 ДФЛ. If the node does not appear, then try again by using a domain administrator account from a domain that is at Windows Server 2012 R2 DFL.

Щелкните Политики проверки подлинности и нажмите Новая, чтобы создать новую политику. Click Authentication Policies, and then click New to create a new policy.

Политики проверки подлинности должны иметь отображаемое имя и используются по умолчанию. Authentications Policies must have a display name and are enforced by default.

Чтобы создать политику только для аудита, щелкните Ограничения политики только для аудита. To create an audit-only policy, click Only audit policy restrictions.

Политики проверки подлинности применяются в зависимости от типа учетной записи Active Directory. Authentication policies are applied based on the Active Directory account type. Одна политика может применяться ко всем трем типам учетных записей, если для каждого типа настроить необходимые параметры. A single policy can apply to all three account types by configuring settings for each type. Типы учетных записей Account types are:

User (Пользователь) User

Управляемые учетные записи служб и групповые управляемые учетные записи служб. Managed Service Account and Group Managed Service Account

Если вы расширили схему с помощью новых субъектов, которые могут использоваться центром распределения ключей, тип новой учетной записи определяется на основе ближайшего производного типа учетной записи. If you have extended the schema with new principals that can be used by the Key Distribution Center (KDC), then the new account type is classified from the closest derived account type.

Чтобы настроить время жизни TGT для учетных записей пользователей, отметьте флажком пункт Указать время жизни билетов предоставления билета и введите время в минутах. To configure a TGT lifetime for user accounts, select the Specify a Ticket-Granting Ticket lifetime for user accounts check box and enter the time in minutes.

Например, если вы хотите, чтобы TGT действовал 10 часов, введите 600, как показано на рисунке. For example, if you want a 10-hour maximum TGT lifetime, enter 600 as shown. Если значение не указано и учетная запись входит в группу Protected Users, время жизни TGT и время продления устанавливаются на 4 часа. If no TGT lifetime is configured, then if the account is a member of the Protected Users group, the TGT lifetime and renewal is 4 hours. В противном случае время жизни TGT и время продления определяются политикой домена, как видно в окне редактора управления групповыми политиками для домена с настройками по умолчанию. Otherwise, TGT lifetime and renewal are based on the domain policy as seen in the following Group Policy Management Editor window for a domain with default settings.

Чтобы запретить для учетной записи пользователя выбор устройств, щелкните Изменить и укажите требования. To restrict the user account to select devices, click Edit to define the conditions that are required for the device.

В окне Изменения условий управления доступом щелкните Добавить условие. In the Edit Access Control Conditions window, click Add a condition.

Добавление условий для учетной записи компьютера или группы Add computer account or group conditions

Чтобы настроить учетные записи компьютеров или группы, в раскрывающемся списке измените пункт Члены каждой на Члены любой. To configure computer accounts or groups, in the drop-down list, select the drop-down list box Member of each and change to Member of any.

Управление доступом определяет условия для устройства или главного компьютера, с помощью которого пользователь выполняет вход. This access control defines the conditions of the device or host from which the user signs on. Согласно терминологии управления доступом, учетная запись компьютера для устройства или главного компьютера является пользователем, поэтому Пользователь — единственный доступный вариант в соответствующем поле. In access control terminology, the computer account for the device or host is the user, which is why User is the only option.

Щелкните Добавить элементы. Click Add items.

Чтобы изменить типы объектов, щелкните Типы объектов. To change object types, click Object Types.

Чтобы выбрать объекты компьютеров из Active Directory, щелкните Компьютеры, а затем нажмите OK. To select computer objects in Active Directory, click Computers, and then click OK.

Чтобы ограничить пользователя, введите имена компьютеров и щелкните Проверить имена. Type the name of the computers to restrict the user, and then click Check Names.

Щелкните «ОК» и создайте остальные необходимые условия для учетной записи компьютера. Click OK and create any other conditions for the computer account.

После этого нажмите OK, и установленные условия отобразятся для учетной записи компьютера. When done, then click OK and the defined conditions will appear for the computer account.

Добавление утверждений компьютера Add computer claim conditions

Чтобы настроить утверждения компьютера, откройте раскрывающийся список, в котором указано «Группа». To configure computer claims, drop-down Group to select the claim.

Утверждения будут доступны лишь в случае, если они были предварительно подготовлены в лесу. Claims are only available if they are already provisioned in the forest.

Выберите организационное подразделение, возможности входа для учетной записи пользователя должны быть ограничены. Type the name of OU, the user account should be restricted to sign on.

После этого щелкните «OK», и в соответствующем поле отобразится добавленное условие. When done, then click OK and the box will show the conditions defined.

Диагностика неполадок, связанных с пропавшими утверждениями компьютера Troubleshoot missing computer claims

Если утверждения были подготовлены, но стали недоступными, они могли быть настроены только для класса Компьютер. If the claim has been provisioned, but is not available, it might only be configured for Computer classes.

Предположим, что необходимо ограничить проверку подлинности на основе подразделения компьютера (OU), который уже настроен, но только для классов компьютеров . Let’s say you wanted to restrict authentication based on the organizational unit (OU) of the computer, which was already configured, but only for Computer classes.

Чтобы утверждение стало доступным и пользовательские возможности подключения к устройству ограничились, поставьте флажок рядом с пунктом Пользователь. For the claim to be available to restrict User sign-on to the device, select the User check box.

Применение политики проверки подлинности для учетной записи пользователя с помощью ADAC Provision a user account with an authentication policy with ADAC

В Учетной записи пользователя щелкните Политика. From the User account, click Policy.

Отметьте флажком пункт Применить политику проверки подлинности для учетной записи. Select the Assign an authentication policy to this account check box.

После этого выберите необходимую политику проверки подлинности. Then select the authentication policy to apply to the user.

Настройка поддержки динамического контроля доступа для устройств и главных компьютеров Configure Dynamic Access Control support on devices and hosts

Вы можете настроить время жизни TGT, не настраивая динамический контроль доступа (DAC). You can configure TGT lifetimes without configuring Dynamic Access Control (DAC). Динамический контроль доступа используется лишь в случае необходимости проверки параметров AllowedToAuthenticateFrom и AllowedToAuthenticateTo. DAC is only needed for checking AllowedToAuthenticateFrom and AllowedToAuthenticateTo.

В редакторе групповых политик или локальных групповых политик активируйте пункт Поддержка клиентом Kerberos утверждений, комплексной проверки подлинности и защиты Kerberos, расположенный по следующему адресу: Конфигурация компьютера | Административные шаблоны | Система: Using either Group Policy or Local Group Policy Editor, enable Kerberos client support for claims, compound authentication and Kerberos armoring in Computer Configuration | Administrative Templates | System | Kerberos:

Диагностика неполадок политик проверки подлинности Troubleshoot Authentication Policies

Определите учетные записи, для которых была напрямую задана политика проверки подлинности. Determine the accounts that are directly assigned an Authentication Policy

В разделе учетных записей в настройках политик проверки подлинности показаны учетные записи, для которых была напрямую назначена политика проверки подлинности. The accounts section in the Authentication Policy shows the accounts that have directly applied the policy.

Использование сбоев политики проверки подлинности — Журнал администрирования контроллера домена Use the Authentication Policy Failures — Domain Controller administrative log

Новые сбои политики проверки подлинности — Журнал администрирования контроллера домена в разделе журналы приложений и служб > > > Проверка подлинности Microsoft Windows была создана для упрощения обнаружения сбоев из-за политик проверки подлинности. A new Authentication Policy Failures — Domain Controller administrative log under Applications and Services Logs > Microsoft > Windows > Authentication has been created to make it easier to discover failures due to Authentication Policies. По умолчанию он неактивен. The log is disabled by default. Чтобы активировать его, щелкните правой кнопкой мыши по названию журнала и выберите пункт Включить журнал. To enable it, right-click the log name and click Enable Log. Новые события по содержанию очень похожи на события аудита билетов предоставления билетов Kerberos и билетов служб. The new events are very similar in content to the existing Kerberos TGT and service ticket auditing events. Дополнительные сведения об этих событиях см. в разделе политики проверки подлинности и приемники политик проверки подлинности. For more information about these events, see Authentication Policies and Authentication Policy Silos.

Управление политиками проверки подлинности с помощью Windows PowerShell Manage authentication policies by using Windows PowerShell

Эта команда создает политику проверки подлинности под названием TestAuthenticationPolicy. This command creates an authentication policy named TestAuthenticationPolicy. Параметр UserAllowedToAuthenticateFrom определяет устройства, с которых пользователь может пройти проверку подлинности с помощью строки SDDL в файле под названием someFile.txt. The UserAllowedToAuthenticateFrom parameter specifies the devices from which users can authenticate by an SDDL string in the file named someFile.txt.

Эта команда позволяет найти все политики проверки подлинности, отвечающие фильтру, который задается параметром Filter. This command gets all authentication policies that match the filter that the Filter parameter specifies.

Эта команда позволяет изменить описание и свойства UserTGTLifetimeMins указанной политики проверки подлинности. This command modifies the description and the UserTGTLifetimeMins properties of the specified authentication policy.

Эта команда удаляет политику проверки подлинности, заданную с помощью параметра Identity. This command removes the authentication policy that the Identity parameter specifies.

В этой команде используется командлет Get-ADAuthenticationPolicy и параметр Filter, чтобы найти все неактивные политики проверки подлинности. This command uses the Get-ADAuthenticationPolicy cmdlet with the Filter parameter to get all authentication policies that are not enforced. Набор результатов передается в командлет Remove-ADAuthenticationPolicy. The result set is piped to the Remove-ADAuthenticationPolicy cmdlet.

Приемники команд политики проверки подлинности Authentication policy silos

Приемники команд политик проверки подлинности — это новый контейнер (objectClass msDS-AuthNPolicySilos) в доменных службах Active Directory, предназначенный для учетных записей пользователей, компьютеров и служб. Authentication Policy Silos is a new container (objectClass msDS-AuthNPolicySilos) in AD DS for user, computer, and service accounts. Эти приемники предназначены для защиты ценных учетных записей. They help protect high-value accounts. Во всех организациях требуется защита членов групп «Администраторы предприятия», «Администраторы доменов» и «Администраторы схемы», поскольку учетные записи, входящие в них, могут использоваться злоумышленниками для неограниченного доступа к лесу. Однако другим учетным записям также может понадобиться защита. While all organizations need to protect members of Enterprise Admins, Domain Admins and Schema Admins groups because those accounts could be used by an attacker to access anything in the forest, other accounts may also need protection.

Некоторые организации изолируют рабочие нагрузки путем создания для них уникальных учетных записей, а также применяя настройки групповой политики для ограничения возможностей локального и удаленного интерактивного входа и привилегий администрирования. Some organizations isolate workloads by creating accounts that are unique to them and by applying Group Policy settings to limit local and remote interactive logon and administrative privileges. Приемники команд политик проверки подлинности позволяют дополнить этот процесс и открывают новый способ назначения отношений между учетными записями пользователей, компьютеров и управляемых служб. Authentication policy silos complement this work by creating a way to define a relationship between User, Computer and managed Service accounts. Учетные записи могут принадлежать только к одному приемнику команд. Accounts can only belong to one silo. Вы можете настроить политику проверки подлинности для каждого типа учетной записи, чтобы управлять следующими параметрами. You can configure authentication policy for each type of account in order to control:

Время жизни непродлеваемых TGT. Non-renewable TGT lifetime

Условия управления доступом для возвращающихся TGT (примечание: неприменимо к системам, поскольку требуется защита Kerberos). Access control conditions for returning TGT (Note: cannot apply to systems because Kerberos armoring is required)

Условия управления доступом для возвращающихся билетов служб. Access control conditions for returning service ticket

Кроме того, учетные записи в приемнике команд политик проверки подлинности располагают утверждением этого приемника команд, которое могут использовать для управления доступом поддерживающие утверждения ресурсы, такие как файловые серверы. Additionally, accounts in an authentication policy silo have a silo claim, which can be used by claims-aware resources such as file servers to control access.

Может быть настроен новый дескриптор безопасности, предназначенный для управления выдачей билетов служб на основе A new security descriptor can be configured to control issuing service ticket based on:

Пользователь, группы безопасности пользователя и/или утверждения пользователя User, user’s security groups, and/or user’s claims

Устройства, группы безопасности устройства и (или) утверждения устройства Device, device’s security group, and/or device’s claims

Для получения этой информации в DCs ресурса требуется динамический контроль доступа: Getting this information to the resource’s DCs requires Dynamic Access Control:

Для утверждений пользователей: User claims:

Windows 8 и более новые клиенты с поддержкой динамического контроля доступа Windows 8 and later clients supporting Dynamic Access Control

Домен учетной записи с поддержкой динамического контроля доступа и утверждений. Account domain supports Dynamic Access Control and claims

Для устройств и/или групп безопасности устройств: Device and/or device security group:

Windows 8 и более новые клиенты с поддержкой динамического контроля доступа Windows 8 and later clients supporting Dynamic Access Control

Ресурс, настроенный для комплексной проверки подлинности. Resource configured for compound authentication

Для утверждений устройств: Device claims:

Windows 8 и более новые клиенты с поддержкой динамического контроля доступа Windows 8 and later clients supporting Dynamic Access Control

Домен устройства с поддержкой динамического контроля доступа и утверждений Device domain supports Dynamic Access Control and claims

Ресурс, настроенный для комплексной проверки подлинности. Resource configured for compound authentication

Политики проверки подлинности могут применяться ко всем членам приемника команд, а не к отдельным учетным записям. Отдельные политики проверки подлинности можно также применить к разным типам учетных записей в рамках приемника команд. Authentication policies can be applied to all members of an authentication policy silo instead of to individual accounts, or separate authentication policies can be applied to different types of accounts within a silo. Например, одну политику можно применить для учетных записей высокопривилегированных пользователей, а другую — к учетным записям служб. For example, one authentication policy can be applied to highly privileged user accounts, and a different policy can be applied to services accounts. Перед созданием приемника команд политик проверки подлинности необходимо создать по крайней мере одну политику проверки подлинности. At least one authentication policy must be created before an authentication policy silo can be created.

Политику проверки подлинности можно применить к членам приемника команд или использовать для ограничения области действия определенных учетных записей независимо от приемников. An authentication policy can be applied to members of an authentication policy silo, or it can be applied independently of silos to restrict specific account scope. Например, одну или несколько учетных записей можно защитить с помощью политики без добавления в приемник команд. For example, to protect a single account or a small set of accounts, a policy can be set on those accounts without adding the accounts to a silo.

Вы можете создать приемник команд для политики проверки подлинности с помощью центр администрирования Active Directory или Windows PowerShell. You can create an authentication policy silo by using Active Directory Administrative Center or Windows PowerShell. По умолчанию приемник команд для политики проверки подлинности выполняет аудит только политик приемника команд, что эквивалентно указанию параметра WhatIf в командлетах Windows PowerShell. By default, an authentication policy silo only audits silo policies, which is equivalent to specifying the WhatIf parameter in Windows PowerShell cmdlets. В этом случае ограничения политик не применяются для приемников команд, однако в случае наложения ограничений происходит создание событий аудита для поиска источников ошибок. In this case, policy silo restrictions do not apply, but audits are generated to indicate whether failures occur if the restrictions are applied.

Создание приемника команд политики проверки подлинности с помощью Центра администрирования Active Directory To create an authentication policy silo by using Active Directory Administrative Center

Откройте Центр администрирования Active Directory, щелкните Проверка подлинности, правой кнопкой мыши щелкните Приемники команд политик проверки подлинности, щелкните Создать, после чего нажмите Приемник команд политик проверки подлинности. Open Active Directory Administrative Center, click Authentication, right-click Authentication Policy Silos, click New, and then click Authentication Policy Silo.

В поле Отображаемое имя укажите имя для приемника команд. In Display name, type a name for the silo. В разделе Разрешенные учетные записи щелкните Добавить, укажите названия учетных записей и нажмите OK. In Permitted Accounts, click Add, type the names of the accounts, and then click OK. Вы можете использовать учетные записи пользователей, компьютеров или служб. You can specify users, computers, or service accounts. После этого выберите, будет ли для всех субъектов использоваться одна политика или же для каждого типа субъекта следует задействовать отдельную, а также введите имя (имена) политики (политик). Then specify whether to use a single policy for all principals or a separate policy for each type of principal, and the name of the policy or policies.

Управление приемниками команд политик проверки подлинности с помощью Windows PowerShell Manage authentication policy silos by using Windows PowerShell

Эта команда создает объект приемника команд политик проверки подлинности и применяет его. This command creates an authentication policy silo object and enforces it.

Эта команда позволяет найти все приемники команд политик проверки подлинности, отвечающие фильтру, который задается параметром Filter. This command gets all the authentication policy silos that match the filter that is specified by the Filter parameter. После этого результат передается в командлет Format-Table для отображения имени политики и значения параметра Enforce каждой политики. The output is then passed to the Format-Table cmdlet to display the name of the policy and the value for Enforce on each policy.

В этой команде используется командлет Get-ADAuthenticationPolicySilo и параметр Filter, чтобы найти все неактивные приемники команд политик проверки подлинности и передать результаты в командлет Remove-ADAuthenticationPolicySilo. This command uses the Get-ADAuthenticationPolicySilo cmdlet with the Filter parameter to get all authentication policy silos that are not enforced and pipe the result of the filter to the Remove-ADAuthenticationPolicySilo cmdlet.

Эта команда позволяет открыть для учетной записи пользователя User01 доступ к приемнику команд Silo. This command grants access to the authentication policy silo named Silo to the user account named User01.

Эта команда отменяет доступ пользователя User01 к приемнику команд Silo. This command revokes access to the authentication policy silo named Silo for the user account named User01. Поскольку параметру Confirm присвоено значение $False, сообщение для подтверждения не выводится. Because the Confirm parameter is set to $False, no confirmation message appears.

В этом примере сначала используется командлет Get-ADComputer, чтобы найти все учетные записи компьютеров, отвечающие фильтру, который задается с помощью параметра Filter. This example first uses the Get-ADComputer cmdlet to get all computer accounts that match the filter that the Filter parameter specifies. Результаты действия этой команды передаются в командлет Set-ADAccountAuthenticatinPolicySilo, чтобы применить для них приемник команд политик проверки подлинности Silo и политику проверки подлинности AuthenticationPolicy02. The output of this command is passed to Set-ADAccountAuthenticatinPolicySilo to assign the authentication policy silo named Silo and the authentication policy named AuthenticationPolicy02 to them.