Архив рубрики: ADDS

Как разрешить пользователям вводить свои машины в домен самостоятельно?

Представьте, что половина ваших пользователей — локальные администраторы на своих машинах. Довольно часто они переустанавливают ОС и просят службу поддержки ввести их компьютеры заново в корпоративный домен Active Directory. Обычно, у нас есть два способа помочь им в этой ситуации: или подойти к рабочему месту пользователя и использовать свои учётные данные для ввода в домен, или пересоздать компьютерный аккаунт, одновременно делегировав им право ввода компьютера в домен. В первом случае, сотруднику службы поддержки приходится ногами идти к рабочему месту пользователя, что может быть довольно выматывающе, особенно для отдалённых локаций. Во втором же, членство компьютера в группах скорее всего будет утеряно и его потребуется восстанавливать вручную.
Возможно ли сократить затраты времени и сил, необходимых на решение таких задач? Да, конечно!

Всё, что нам нужно, это представить пользователю следующие разрешения на учётную запись его компьютера:

  • Validated write to DNS host name
  • Validated write to service principal name
  • List the children of an object
  • Read
  • Read security information
  • List the object access
  • Control access right
  • Delete an object and all of its children
  • Delete
  • Write to the following properties:
    • sAMAccountName
    • displayName
    • description
    • Logon Information
    • Account Restrictions

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

Я сделал небольшой PowerShell-сценарий, чтобы помочь вам в выдаче таких разрешений. Пожалуйста обратимость к его секции помощи (можете использовать командлет Get-Help) за информацией о синтаксисе и примерами использования.

Если вы используете Windows 8.1/Server 2012 R2, вам может потребоваться установить исправление из KB 3092002, иначе сценарий будет работать только при запуске от имени учётной записи, входящей в группу «Domain Admins». Это происходит из-за ошибки в реализации командлета Set-Acl. Исправление для Windows 10 включено в последний выпуск RSAT.

Если вы испытываете какие-либо проблемы или ошибки при использовании сценария, пожалуйста, оставьте ниже комментарий или свяжитесь со мной напрямую.

Команда «setspn -x» теперь регистронезависимая

Как вы знаете, дублирующиеся SPN в домене AD DS приводят к сбоям при аутентификации с использованием Kerberos, заметить которые вы можете по появлению ошибок KRB_AP_ERR_MODIFIED и событиям №11 в журналах ваших систем. Для проактивного исправления проблемы, начиная с Windows Server 2008, встроенное средство setspn дополнено ключом «-x», который выводит список дублирующихся SPN в домене (либо в лесу, если использован ещё и ключ «-f»). Многие компании используют результат работы команды «setspn -x -f», как источник данных для системы мониторинга.

Оказывается, всё это время, практически никто из IT-администраторов (и я тоже) не обращал внимания, что ключ «-x» производил сравнение SPN с учётом регистра! Т.е. следующие SPN он считал разными и не выводил в результате своей работы:

  • HOST/SERVERNAME
  • HOST/ServerName

Начиная с Windows 10, Microsoft изменила поведение средства setspn на регистронезависимое и, теперь, в вывод setspn будут попадать все дублирующиеся SPN, независимо от их регистра.

Несмотря на то, что Microsoft утверждает, что в среде Windows SPN не-регистрозависимые, Shane Young обнаружил, что SharePoint так не считает.

Я советую всем администраторам AD DS проверить свою инфраструктуру при помощи setspn из поставки Windows 10, хотя бы один раз, чтобы найти ДЕЙСТВИТЕЛЬНО ВСЕ дублирующиеся SPN (я у себя нашёл ;).

Утверждение AuthenticationSilo не выпускается

Вы настраиваете Active Directory Authentication Policy и, в качестве условия контроля доступа, устанавливаете необходимость членства в определённом Authentication Policy Silo. Далее, вы используете эту политику в silo, определённом выше, для соответствующих типов объектов. Вы настраиваете этот silo только на аудит ограничений.

В этом случае, утверждение типа AuthenticationSilo не выпускается для ваших объектов безопасности.

Почему это происходит?

Как описано в разделе 3.1.1.11.2.18 GetAuthSiloClaim технической спецификации по Active Directory, утверждение типа AuthenticationSilo выпускается только тогда, когда Authentication Silo находится в режиме принудительного применения ограничений («Enforce policy restrictions»):
/*
Check if user is assigned to an enforced silo.
*/
assignedSilo := pADPrincipal!msDS-AssignedAuthNPolicySilo
if (assignedSilo = NULL ||
assignedSilo!msDS-AuthNPolicySiloEnforced = FALSE)
return NULL
endif

Решение

Я пока не нашёл способа изменить это поведение, просто помните о нём, пока настраиваете ваши Authentication Policies.

SCCM: Коллекция устройств на основе членства в локальной группе

Недавно передо мной возникла задача отделять в SCCM рабочие станции, управляемые IT-отделом, от рабочих станций, управляемых пользователями самостоятельно. Критерием самостоятельно управляемой рабочей станции было выбрано наличие каких-либо учётных записей в группе локальных администраторов, кроме Administrator, Domain Admins и группы сотрудников техподдержки. Все рабочие станции расположены в одном OU, поэтому создание коллекций по OU не подходило.

Как вы возможно знаете, SCCM 2012 не имеет встроенных средств для получения членства в локальных группах рабочих станций и серверов. Спасибо Sherry Kissinger, которая решила эту проблему с использованием Compliance Settings.
После установки её пакета, вы получите новые Configuration Baseline, Configuration Item и 2 таблицы и 1 view в базе SCCM: LocalGroupMembers_DATA, LocalGroupMembers_HIST и v_GS_LocalGroupMembers0.

В дальнейшем вы можете использовать данные из view v_GS_LocalGroupMembers0 для построения отчётов о членах локальных групп управляемых вами компьютеров (Не забудьте распространить baseline на нужную коллекцию компьютеров, но ни в коем случае не на контроллеры домена! Например, создайте коллекцию с правилом Include для стандартной коллекции All Systems и правилом Exclude для коллекции All Domain Controllers. Вы можете загрузить MOF-файл такой коллекции здесь).

НО, к сожалению, ни таблица LocalGroupMembers_DATA, ни v_GS_LocalGroupMembers0 недоступны для WQL-запросов, которые используются при создании коллекций.
Казалось бы, я застрял. Что у меня было на руках на тот момент:

  • У меня есть все данные о членстве в локальных группах на всех компьютерах.
  • Я могу построить любые отчёты по ним.
  • У меня есть средства для построения коллекций по данным из стандартных таблиц SCCM.
  • SCCM не может использовать данные из нестандартных таблиц для построения коллекций.

Итак, нам нужен способ поместить данные из таблицы LocalGroupMembers_DATA в стандартные таблицы SCCM для построения коллекции по ним и PowerShell нам в этом поможет.
Есть как минимум 2 способа получения данных из SQL в PowerShell:

  1. Подключаться напрямую к базе и использовать SQL-запросы при помощи командлетов SQL.
  2. Или подключаться к SQL Server Reporting Services с использованием командлета New-WebServiceProxy. Stefan Stranger и Jin Chen написали сценарий для этого.

Т.к. это PowerShell, дальше мы можем делать с данными из SQL всё, что угодно. Наша задача — это наполнение коллекции устройств, и тут опять существует как минимум 2 варианта:

  1. Добавлять компьютеры в группу AD DS, по которой затем создавать коллекцию устройств в SCCM. В этом случае, метод обнаружения Active Directory Group Discovery для сайта и домена, где будет расположена эта группа, должен быть активирован.
  2. Напрямую добавлять компьютеры в коллекцию SCCM используя командлет Add-CMDeviceCollectionDirectMembershipRule.

Т.к. и отчёт, и группа в AD DS будут мне полезны в будущем, я выбрал вариант именно с ними.

Итак, общий сценарий действий такой:

  1. Активировать Active Directory Group Discovery.
  2. При помощи Compliance Settings собирать сведения о членстве в локальных группах на компьютерах.
  3. Строить отчёт по этой таблице на любом SSRS.
  4. Используя командлет New-WebServiceProxy, получать имена компьютеров из этого отчёта.
  5. Добавлять эти компьютеры в специальную группу.
  6. Стандартными средствами SCCM наполнять коллекцию устройств по группе AD DS.

Я построил отчёт в котором вывожу списком все компьютеры, не удовлетворяющие условиям, описанным выше. Вот, как выглядит запрос для первого DataSet’а:

Вы легко можете расширить его для исключения как-то других групп.
Обратите внимание на параметр CompOU: в веб-интерфейсе вы можете выбрать одно или несколько OU, откуда выводить компьютеры.

Для получения полного списка этих OU из ваших лесов, служит второй DataSet с таким кодом:

Далее я модифицировал сценарий RenderSQLReportFromPosh.v1.000.ps1 таким образом, чтобы он не только получал отчёт из SSRS, но и на его основе формировал группу в AD DS. Вот его полный код:

Сценарий получает отчёт с SSRS, определяемому в переменных $URI и $ReportPath, сравнивает список компьютеров из него с группой $GroupName и добавляет/удаляет компьютеры из неё таким образом, чтобы она совпадала со списком из отчёта.
Сценарий ведёт журнал работы по пути $Log, в который записывает, удалил он компьютер в группу или, наоборот, добавил.
В качестве параметров я передаю отчёту 2 OU ($param1 и $param2). Если вам нужно больше, просто создавайте новые параметры и добавляйте их в переменную $parameters.

Наконец, я создал стандартную коллекцию устройств на основе членства в группе $GroupName и всё заверте…

Загрузить RDL-файл отчёта и сценарий вы можете здесь. Не забудьте в отчёте создать DataSource для подключения к вашему серверу SSRS.

SCCM: Коллекция для всех контроллеров домена

Существует множество способов определить коллекцию, содержащую все контроллеры домена. Вот несколько примеров:

Все компьютеры с установленной ролью Domain_Controller:

Все компьютеры, с основной группой Domain Controllers:

Все члены группы Domain Controllers:

Лично я предпочитаю первый вариант, с определением по установленным ролям в операционной системе. Вы можете загрузить MOF-файл для такой коллекции здесь. Просто импортируйте его, как описано в статье How to Create Collections in Configuration Manager и новая коллекция «All Domain Controllers» появится в вашей консоли SCCM.