Руководство по настройке защищенных учетных записей
С помощью атаки с передачей хэша (PtH) злоумышленник может пройти проверку подлинности для доступа к удаленному серверу или услуге, используя исходный NTLM-хэш пользовательского пароля (или другие производные учетных данных). Ранее корпорация Майкрософт опубликовала руководство по уменьшению вреда от атак типа pass-the-hash. Windows Server 2012 R2 включает новые функции для устранения таких атак. Подробную информацию об остальных функциях безопасности, направленных на защиту от кражи учетных данных, см. в разделе Защита учетных данных и управление ими. В этом разделе описан процесс настройки следующих новых функций:
В Windows 8.1 и Windows Server 2012 R2 встроены дополнительные средства защиты для предотвращения кражи учетных данных, рассмотренные в следующих статьях:
Защищенные пользователи
"Защищенные пользователи" — новая глобальная группа безопасности, в которую вы можете добавлять новых или уже зарегистрированных пользователей. Windows 8.1 устройствах и узлах Windows Server 2012 R2 имеют особое поведение с членами этой группы, чтобы повысить защиту от кражи учетных данных. Для члена группы устройство Windows 8.1 или узел Windows Server 2012 R2 не кэширует учетные данные, которые не поддерживаются для защищенных пользователей. Члены этой группы не имеют дополнительной защиты, если они вошли на устройство, на котором запущена версия Windows до Windows 8.1.
Члены группы защищенных пользователей, вошедшие в систему на устройствах Windows 8.1 и узлах Windows Server 2012 R2, больше не могут использовать следующее:
Делегирование учетных данных по умолчанию (CredSSP) — учетные данные в виде обычного текста не кэшируются, даже если включена политика делегирования учетных данных по умолчанию .
Дайджест Windows — учетные данные в виде обычного текста не кэшируются, даже если они активны.
Кэширование NTLM- и NTOWF-данных не выполняется.
Долговременные ключи Kerberos — билет предоставления билета (TGT) Kerberos получается при входе и не может быть повторно выдан автоматически.
Автономный вход — создание кэшированного средства проверки входа не производится.
Если уровень функциональности домена — Windows Server 2012 R2, члены группы больше не могут:
Выполнять проверку подлинности NTLM
Использовать для предварительной проверки подлинности Kerberos алгоритм шифрования DES или наборы шифров RC4
Получать полномочия с помощью ограниченного или неограниченного делегирования
Выполнять продление пользовательских билетов (TGT) и использовать их более 4 часов.
Чтобы добавить пользователей в группу, можно использовать такие средства пользовательского интерфейса, как Центр администрирования Active Directory (ADAC) или Пользователи и компьютеры Active Directory, или средство командной строки, например группа dsmod, или командлет Windows PowerShellAdd-ADGroupMember. Учетные записи служб и компьютеров не должны входить в группу защищенных пользователей. Членство для этих учетных записей предполагает отсутствие локальной защиты, поскольку пароль или сертификат всегда доступны на главном компьютере.
Предупреждение
Ограничения проверки подлинности нельзя обойти, т. е. члены высокопривилегированных групп, такие как администраторы предприятия или доменов, подвержены тем же ограничениям, что и другие члены группы "Защищенные пользователи". Если все члены таких групп добавляются в группу защищенных пользователей, можно заблокировать все эти учетные записи. Никогда не следует добавлять все учетные записи с высоким уровнем привилегий в группу защищенных пользователей, пока вы тщательно не протестировали потенциальное влияние.
Члены группы "Защищенные пользователи" должны иметь возможность проверки подлинности при помощи протокола Kerberos с алгоритмом AES. В этом методе для учетных записей в Active Directory требуются ключи AES. Встроенный администратор не имеет ключа AES, если пароль не был изменен на контроллере домена под управлением Windows Server 2008 или более поздней версии. Кроме того, любая учетная запись с измененным паролем на контроллере домена, на котором запущена более ранняя версия Windows Server, заблокирована. Поэтому следуйте приведенным ниже рекомендациям.
Не тестируйтесь в доменах, если только все контроллеры домена не запускают Windows Server 2008 или более поздней версии.
Измените пароли для всех учетных записей домена, созданных раньше домена. В противном случае успешная проверка подлинности для этих учетных записей исключается.
Измените пароль для каждого пользователя перед добавлением учетной записи в группу защищенных пользователей или убедитесь, что пароль был изменен недавно на контроллере домена под управлением Windows Server 2008 или более поздней версии.
Требования для использования защищенных учетных записей
Для использования защищенных учетных записей должны выполняться следующие требования.
Чтобы обеспечить ограничения на стороне клиента для защищенных пользователей, узлы должны выполняться Windows 8.1 или Windows Server 2012 R2. Пользователю требуется лишь войти в учетную запись, принадлежащую к группе "Защищенные пользователи". В этом случае группу защищенных пользователей можно создать, передав роль эмулятора основного контроллера домена (PDC) на контроллер домена, на котором работает Windows Server 2012 R2. После этого объект группы реплицируется на другой контроллер домена; роль эмулятора может быть передана доменному контроллеру под управлением более ранних версий Windows Server.
Чтобы обеспечить ограничения на стороне контроллера домена для защищенных пользователей, то есть ограничить использование проверки подлинности NTLM и других ограничений, функциональный уровень домена должен быть Windows Server 2012 R2. Дополнительные сведения о функциональных уровнях см. в разделе Общее представление о режимах работы доменных служб Active Directory (AD DS).
Примечание.
Встроенный администратор домена (S-1-5-<domain>-500) всегда освобождается от политик проверки подлинности, даже если они назначены Silo политики проверки подлинности.
Диагностика неполадок событий, связанных с группой защищенных пользователей
В этом подразделе рассматривается использование новых журналов для диагностики неполадок событий, связанных с группой "Защищенные пользователи", а также возможные действия защищенных пользователей для решения проблем, связанных со сроком действия билетов предоставления билетов (TGT) или делегированием.
Новые журналы для защищенных пользователей
Два новых операционных административных журнала доступны для устранения неполадок событий, связанных с защищенными пользователями: защищенный пользователь — журнал клиента и защищенные сбои пользователей — журнал контроллера домена. Новые журналы можно найти при помощи средства просмотра событий. По умолчанию они неактивны. Чтобы включить журнал, щелкните Журналы приложений и служб, затем нажмите Майкрософт, щелкните Windows, нажмите Проверка подлинности, выберите журнал и щелкните Действие (или щелкните по журналу правой кнопкой мыши), после чего нажмите Включить журнал.
Подробную информацию см. в разделе Политики проверки подлинности и приемники команд политик проверки подлинности.
Диагностика неполадок, связанных с временем жизни TGT
В общем случае контроллер домена устанавливает время жизни TGT и срок его продления в зависимости от политики домена, как видно в окне редактора управления групповыми политиками на следующем рисунке.
Для группы Защищенные пользователистрого определены следующие параметры.
Максимальное время жизни пользовательского билета: 240 минут
Максимальное время продления пользовательского билета: 240 минут
Диагностика неполадок, связанных с делегированием
Ранее, если технология, использующая делегирование Kerberos, выходила из строя, проверялось, установлен ли для учетной записи клиента параметр Учетная запись важна и не может быть делегирована . Однако если учетная запись клиента входит в группу Защищенные пользователи, этот параметр может быть не настроен в центре администрирования Active Directory (ADAC). Поэтому в случае проблем с делегированием следует проверить, установлен ли указанный параметр и входит ли учетная запись в группу "Защищенные пользователи".
Аудит попыток проверки подлинности
Для явного аудита попыток проверки подлинности членов группы Защищенные пользователи вы можете продолжить сохранять события аудита в журнале безопасности или же собирать данные в новых операционных журналах администрирования. Подробную информацию см. в разделе Политики проверки подлинности и приемники команд политик проверки подлинности.
Защита служб и компьютеров со стороны контроллера домена
Учетные записи служб и компьютеров не должны входить в группу Защищенные пользователи. В этом подразделе описываются средства защиты на базе контроллера домена, применяемые для этих учетных записей.
Отклонение проверки подлинности NTLM: Настраивается только с помощью политик блокировки NTLM.
Отклонение стандартного шифрования данных (DES) в предварительной проверке подлинности Kerberos: контроллеры домена Windows Server 2012 R2 не принимают DES для учетных записей компьютеров, если только они не настроены для DES, так как каждая версия Windows, выпущенная с kerberos, также поддерживает RC4.
Отклонение при использовании RC4 в предварительной проверке подлинности Kerberos: нельзя настроить.
Примечание.
Хотя можно изменить конфигурацию поддерживаемых способов шифрования, не рекомендуется менять эти настройки для учетных записей компьютеров без предварительного тестирования в целевой среде.
Ограничение времени жизни пользовательских билетов (TGT) до 4-х часов: используйте политики проверки подлинности.
Запретить ограниченное и неограниченное делегирование: чтобы ограничить учетную запись, откройте центр администрирования Active Directory (ADAC) и отметьте флажком параметр Учетная запись важна и не может быть делегирована .
Политики проверки подлинности
Политики проверки подлинности — новый контейнер доменных служб Active Directory, содержащий объекты политики проверки подлинности. Вы можете настроить политики проверки подлинности, чтобы защититься от кражи учетных данных, например ограничить время жизни TGT для учетных записей или добавить прочие условия, связанные с утверждениями.
В Windows Server 2012 Dynamic контроль доступа представила класс объектов области леса Active Directory с именем Central Access Policy, чтобы упростить настройку файловых серверов в организации. В Windows Server 2012 R2 новый класс объектов с именем "Политика проверки подлинности" (objectClass msDS-AuthNPolicies) можно использовать для применения конфигурации проверки подлинности к классам учетных записей в доменах Windows Server 2012 R2. Классы учетных записей Active Directory.
User
Компьютер
Управляемые учетные записи служб и групповые управляемые учетные записи служб (GMSA)
Быстрое обновление Kerberos
Протокол проверки подлинности Kerberos использует три способа обмена, также известных как подпротоколы.
Обмен AS — обмен службы проверки подлинности (KRB_AS_*)
Обмен TGS — обмен службы предоставления билетов (KRB_TGS_*)
Обмен AP — обмен между клиентом и сервером (KRB_AP_*)
Обмен AS — это место, в котором клиент использует пароль учетной записи или закрытый ключ для создания предварительной проверки подлинности для запроса билета на предоставление билетов (TGT). Это происходит при первом входе пользователя или при первой необходимости билета службы.
Обмен TGS — это место, в котором TGT учетной записи используется для создания средства проверки подлинности для запроса билета на обслуживание. Это происходит при необходимости подключения с успешной проверкой подлинности.
Обмен AP выполняется, если в протоколе приложения содержатся данные и он не подвержен влиянию политик проверки подлинности.
Подробную информацию см. в разделе Принцип действия протокола проверки подлинности Kerberos версии 5.
Обзор
Политики проверки подлинности позволяют дополнить группу защищенных пользователей, позволяя применять к учетным записям настраиваемые ограничения и ограничивая учетные записи служб и компьютеров. Политики проверки подлинности используются при обмене AS и обмене TGS.
Вы можете ограничить начальную проверку подлинности или обмен AS, настроив
Время жизни TGT
Условия управления доступом для ограничения входа пользователей, которые должны выполняться устройствами, инициирующими обмен AS.
Вы можете ограничить запросы билетов служб с помощью обмена TGS, настроив
- Условия управления доступом, которые должны выполняться клиентом (пользователь, служба или компьютер) или устройством, инициирующим обмен TGS
Требования для использования политик проверки подлинности
| Политика | Требования |
|---|---|
| Возможность настройки времени жизни TGT | Домены функционального уровня домена Windows Server 2012 R2 |
| Ограничение входа пользователей | — домены учетных записей уровня функциональности домена Windows Server 2012 R2 с поддержкой динамической контроль доступа — Устройства Windows 8, Windows 8.1, Windows Server 2012 или Windows Server 2012 R2 с поддержкой dynamic контроль доступа |
| Ограничение выдачи билетов служб на основе учетных записей пользователей и групп безопасности | Домены функционального уровня домена Windows Server 2012 R2 |
| Ограничение выдачи билетов служб на основе требований пользователя или учетной записи, групп безопасности или требований устройства | Домены функционального уровня домена Windows Server 2012 R2 с поддержкой динамической контроль доступа |
Ограничение учетных записей пользователей для особых устройств и главных компьютеров.
Ценные учетные записи с правами администратора должны входить в группу Защищенные пользователи . По умолчанию группа Защищенные пользователи пуста. Перед тем как добавить в нее учетные записи, настройте поддержку контроллера домена и создайте политику аудита, чтобы исключить проблемы с блокированием.
Настройка поддержки контроллера домена
Домен учетной записи пользователя должен находиться на уровне функциональных возможностей домена Windows Server 2012 R2 (DFL). Убедитесь, что все контроллеры домена — Windows Server 2012 R2, а затем используйте домен Active Directory и доверия для повышения уровня DFL до Windows Server 2012 R2.
Настройка поддержки Dynamic контроль доступа
В политике контроллеров домена по умолчанию щелкните "Включено ", чтобы включить поддержку клиентов Центра распространения ключей (KDC) для утверждений, составной проверки подлинности и защиты Kerberos в конфигурации компьютера | Административные шаблоны | Система | KDC.
В поле Параметрыв раскрывающемся списке выберите Всегда предоставлять утверждения.
Примечание.
Поддерживается также можно настроить, но так как домен находится в Windows Server 2012 R2 DFL, если контроллеры домена всегда предоставляют утверждения, будут разрешать проверки доступа на основе утверждений пользователей при использовании устройств, не поддерживающих утверждения, и узлов для подключения к службам с поддержкой утверждений.
Предупреждение
Настройка запросов проверки подлинности сбоем неустраченной приведет к сбоям проверки подлинности из любой операционной системы, которая не поддерживает защиту Kerberos, например Windows 7 и предыдущих операционных систем, или операционных систем, начиная с Windows 8, которые не были явно настроены для поддержки.
Создание средства аудита учетной записи пользователя для политики проверки подлинности с помощью ADAC
Откройте центр администрирования Active Directory (ADAC).
Примечание.
Выбранный узел проверки подлинности отображается для доменов, которые находятся в Windows Server 2012 R2 DFL. Если узел не отображается, повторите попытку с помощью учетной записи администратора домена из домена, которая находится в Windows Server 2012 R2 DFL.
Щелкните Политики проверки подлинностии нажмите Новая , чтобы создать новую политику.
Политики проверки подлинности должны иметь отображаемое имя и используются по умолчанию.
Чтобы создать политику только для аудита, щелкните Ограничения политики только для аудита.
Политики проверки подлинности применяются в зависимости от типа учетной записи Active Directory. Одна политика может применяться ко всем трем типам учетных записей, если для каждого типа настроить необходимые параметры. Типы учетных записей
User
Компьютер
Управляемые учетные записи служб и групповые управляемые учетные записи служб.
Если вы расширили схему с помощью новых субъектов, которые могут использоваться центром распределения ключей, тип новой учетной записи определяется на основе ближайшего производного типа учетной записи.
Чтобы настроить время жизни TGT для учетных записей пользователей, отметьте флажком пункт Указать время жизни билетов предоставления билета и введите время в минутах.
Например, если вы хотите, чтобы TGT действовал 10 часов, введите 600 , как показано на рисунке. Если значение не указано и учетная запись входит в группу Protected Users , время существования TGT и время продления устанавливаются на 4 часа. В противном случае время жизни TGT и время продления определяются политикой домена, как видно в окне редактора управления групповыми политиками для домена с настройками по умолчанию.
Чтобы запретить для учетной записи пользователя выбор устройств, щелкните Изменить и укажите требования.
В окне Изменения условий управления доступом щелкните Добавить условие.
Добавление условий для учетной записи компьютера или группы
Чтобы настроить учетные записи компьютеров или группы, в раскрывающемся списке измените пункт Члены каждой на Члены любой.
Примечание.
Управление доступом определяет условия для устройства или главного компьютера, с помощью которого пользователь выполняет вход. Согласно терминологии управления доступом, учетная запись компьютера для устройства или главного компьютера является пользователем, поэтому Пользователь — единственный доступный вариант в соответствующем поле.
Щелкните Добавить элементы.
Чтобы изменить типы объектов, щелкните Типы объектов.
Чтобы выбрать объекты компьютеров из Active Directory, щелкните Компьютеры, а затем нажмите OK.
Чтобы ограничить пользователя, введите имена компьютеров и щелкните Проверить имена.
Щелкните "ОК" и создайте остальные необходимые условия для учетной записи компьютера.
После этого нажмите OK , и установленные условия отобразятся для учетной записи компьютера.
Добавление утверждений компьютера
Чтобы настроить утверждения компьютера, откройте раскрывающийся список, в котором указано "Группа".
Утверждения будут доступны лишь в случае, если они были предварительно подготовлены в лесу.
Выберите организационное подразделение, возможности входа для учетной записи пользователя должны быть ограничены.
После этого щелкните "OK", и в соответствующем поле отобразится добавленное условие.
Диагностика неполадок, связанных с пропавшими утверждениями компьютера
Если утверждения были подготовлены, но стали недоступными, они могли быть настроены только для класса Компьютер .
Предположим, вы хотите ограничить проверку подлинности на основе подразделения компьютера, который уже настроен, но только для классов компьютеров .
Чтобы утверждение стало доступным и пользовательские возможности подключения к устройству ограничились, поставьте флажок рядом с пунктом Пользователь .
Применение политики проверки подлинности для учетной записи пользователя с помощью ADAC
В Учетной записи пользователя щелкните Политика.
Отметьте флажком пункт Применить политику проверки подлинности для учетной записи .
После этого выберите необходимую политику проверки подлинности.
Настройка поддержки динамического контроля доступа для устройств и главных компьютеров
Вы можете настроить время жизни TGT, не настраивая динамический контроль доступа (DAC). Динамический контроль доступа используется лишь в случае необходимости проверки параметров AllowedToAuthenticateFrom и AllowedToAuthenticateTo.
С помощью групповой политики или редактора локальной групповой политики включите поддержку клиентов Kerberos для утверждений, составной проверки подлинности и защиты Kerberos в конфигурации компьютера | Административные шаблоны | Система | Kerberos:
Диагностика неполадок политик проверки подлинности
Определите учетные записи, для которых была напрямую задана политика проверки подлинности.
В разделе учетных записей в настройках политик проверки подлинности показаны учетные записи, для которых была напрямую назначена политика проверки подлинности.
Использование ошибок политики проверки подлинности — журнал администрирования контроллера домена
Был создан новый журнал политики проверки подлинности — административный журнал контроллера домена в разделе "Приложения и службы>" проверки подлинности Microsoft>Windows>, чтобы упростить обнаружение сбоев из-за политик проверки подлинности. По умолчанию он неактивен. Чтобы активировать его, щелкните правой кнопкой мыши по названию журнала и выберите пункт Включить журнал. Новые события по содержанию очень похожи на события аудита билетов предоставления билетов Kerberos и билетов служб. Подробную информацию об этих событиях см. в разделе Политики проверки подлинности и приемники команд политик проверки подлинности.
Управление политиками проверки подлинности с помощью Windows PowerShell
Эта команда создает политику проверки подлинности TestAuthenticationPolicy. Параметр UserAllowedToAuthenticateFrom определяет устройства, с которых пользователь может пройти проверку подлинности с помощью строки SDDL в файле someFile.txt.
PS C:\> New-ADAuthenticationPolicy testAuthenticationPolicy -UserAllowedToAuthenticateFrom (Get-Acl .\someFile.txt).sddl
Эта команда позволяет найти все политики проверки подлинности, отвечающие фильтру, который задается параметром Filter .
PS C:\> Get-ADAuthenticationPolicy -Filter "Name -like 'testADAuthenticationPolicy*'" -Server Server02.Contoso.com
Эта команда позволяет изменить описание и свойства UserTGTLifetimeMins указанной политики проверки подлинности.
PS C:\> Set-ADAuthenticationPolicy -Identity ADAuthenticationPolicy1 -Description "Description" -UserTGTLifetimeMins 45
Эта команда удаляет политику проверки подлинности, заданную с помощью параметра Identity .
PS C:\> Remove-ADAuthenticationPolicy -Identity ADAuthenticationPolicy1
В этой команде используется командлет Get-ADAuthenticationPolicy и параметр Filter , чтобы найти все неактивные политики проверки подлинности. Результирующий набор передается по конвейеру командлету Remove-ADAuthenticationPolicy .
PS C:\> Get-ADAuthenticationPolicy -Filter 'Enforce -eq $false' | Remove-ADAuthenticationPolicy
Приемники команд политик проверки подлинности
Приемники команд политик проверки подлинности — это новый контейнер (objectClass msDS-AuthNPolicySilos) в доменных службах Active Directory, предназначенный для учетных записей пользователей, компьютеров и служб. Эти приемники предназначены для защиты ценных учетных записей. Во всех организациях требуется защита членов групп "Администраторы предприятия", "Администраторы доменов" и "Администраторы схемы", поскольку учетные записи, входящие в них, могут использоваться злоумышленниками для неограниченного доступа к лесу. Однако другим учетным записям также может понадобиться защита.
Некоторые организации изолируют рабочие нагрузки путем создания для них уникальных учетных записей, а также применяя настройки групповой политики для ограничения возможностей локального и удаленного интерактивного входа и привилегий администрирования. Приемники команд политик проверки подлинности позволяют дополнить этот процесс и открывают новый способ назначения отношений между учетными записями пользователей, компьютеров и управляемых служб. Учетные записи могут принадлежать только к одному приемнику команд. Вы можете настроить политику проверки подлинности для каждого типа учетной записи, чтобы управлять следующими параметрами.
Время жизни непродлеваемых TGT.
Условия управления доступом для возвращающихся TGT (примечание: неприменимо к системам, поскольку требуется защита Kerberos).
Условия управления доступом для возвращающихся билетов служб.
Кроме того, учетные записи в приемнике команд политик проверки подлинности располагают утверждением этого приемника команд, которое могут использовать для управления доступом поддерживающие утверждения ресурсы, такие как файловые серверы.
Может быть настроен новый дескриптор безопасности, предназначенный для управления выдачей билетов служб на основе
Утверждения пользователей, групп безопасности пользователей и (или) пользователей
Утверждения устройства, группы безопасности устройства и (или) устройства
Для получения этих сведений для контроллеров домена ресурса требуется динамическая контроль доступа:
Для утверждений пользователей:
Windows 8 и более новые клиенты с поддержкой динамического контроля доступа
Домен учетной записи с поддержкой динамического контроля доступа и утверждений.
Для устройств и/или групп безопасности устройств:
Windows 8 и более новые клиенты с поддержкой динамического контроля доступа
Ресурс, настроенный для комплексной проверки подлинности.
Для утверждений устройств:
Windows 8 и более новые клиенты с поддержкой динамического контроля доступа
Домен устройства с поддержкой динамического контроля доступа и утверждений
Ресурс, настроенный для комплексной проверки подлинности.
Политики проверки подлинности могут применяться ко всем членам приемника команд, а не к отдельным учетным записям. Отдельные политики проверки подлинности можно также применить к разным типам учетных записей в рамках приемника команд. Например, одну политику можно применить для учетных записей высокопривилегированных пользователей, а другую — к учетным записям служб. Перед созданием приемника команд политик проверки подлинности необходимо создать по крайней мере одну политику проверки подлинности.
Примечание.
Политику проверки подлинности можно применить к членам приемника команд или использовать для ограничения области действия определенных учетных записей независимо от приемников. Например, одну или несколько учетных записей можно защитить с помощью политики без добавления в приемник команд.
Вы можете создать хранилище политики проверки подлинности с помощью Центра администрирования Active Directory или Windows PowerShell. По умолчанию политика проверки подлинности выполняет аудит только политик silo, что эквивалентно указанию параметра WhatIf в командлетах Windows PowerShell. В этом случае ограничения политик не применяются для приемников команд, однако в случае наложения ограничений происходит создание событий аудита для поиска источников ошибок.
Создание приемника команд политики проверки подлинности с помощью Центра администрирования Active Directory
Откройте Центр администрирования Active Directory, щелкните Проверка подлинности, правой кнопкой мыши щелкните Приемники команд политик проверки подлинности, щелкните Создать, после чего нажмите Приемник команд политик проверки подлинности.
В поле Отображаемое имяукажите имя для приемника команд. В разделе Разрешенные учетные записищелкните Добавить, укажите названия учетных записей и нажмите OK. Вы можете использовать учетные записи пользователей, компьютеров или служб. После этого выберите, будет ли для всех субъектов использоваться одна политика или же для каждого типа субъекта следует задействовать отдельную, а также введите имя (имена) политики (политик).
Управление приемниками команд политик проверки подлинности с помощью Windows PowerShell
Эта команда создает объект приемника команд политик проверки подлинности и применяет его.
PS C:\>New-ADAuthenticationPolicySilo -Name newSilo -Enforce
Эта команда позволяет найти все приемники команд политик проверки подлинности, отвечающие фильтру, который задается параметром Filter . После этого результат передается в командлет Format-Table для отображения имени политики и значения параметра Enforce каждой политики.
PS C:\>Get-ADAuthenticationPolicySilo -Filter 'Name -like "*silo*"' | Format-Table Name, Enforce -AutoSize
Name Enforce
---- -------
silo True
silos False
В этой команде используется командлет Get-ADAuthenticationPolicySilo и параметр Filter , чтобы найти всех неактивных приемников команд политик проверки подлинности и передать результаты в командлет Remove-ADAuthenticationPolicySilo .
PS C:\>Get-ADAuthenticationPolicySilo -Filter 'Enforce -eq $False' | Remove-ADAuthenticationPolicySilo
Эта команда позволяет открыть для учетной записи пользователя User01 доступ к приемнику команд Silo.
PS C:\>Grant-ADAuthenticationPolicySiloAccess -Identity Silo -Account User01
Эта команда отменяет доступ пользователя User01 к приемнику команд Silo. Поскольку параметру Confirm присвоено значение $False, сообщение для подтверждения не выводится.
PS C:\>Revoke-ADAuthenticationPolicySiloAccess -Identity Silo -Account User01 -Confirm:$False
В этом примере сначала используется командлет Get-ADComputer , чтобы найти все учетные записи компьютеров, отвечающие фильтру, который задается с помощью параметра Filter . Результаты действия этой команды передаются в командлет Set-ADAccountAuthenticatinPolicySilo , чтобы применить для них приемник команд политик проверки подлинности Silo и политику проверки подлинности AuthenticationPolicy02 .
PS C:\>Get-ADComputer -Filter 'Name -like "newComputer*"' | Set-ADAccountAuthenticationPolicySilo -AuthenticationPolicySilo Silo -AuthenticationPolicy AuthenticationPolicy02