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

Большая переработка Synchronize-DNSZones.ps1

Сегодня я закончил серьёзную переработку моего сценария синхронизации DNS-зон Synchronize-DNSZones (больше о нём вы можете прочитать здесь). Основной причиной для переработки, являлось добавление поддержки записей на уровне непосредственно самой зоны. Для того, чтобы делать это эффективно, я разбил большой кусок кода на несколько функций (и вижу, что можно его подробить ещё).
В связи с новой функциональностью, появились и новые предупреждения:
55 — DNS-zone creation is not yet supported. (И не думаю, что когда-либо будет поддерживаться)
72 — Function New-DnsRecord failed.
82 — Cannot import DNSClient PowerShell module.

В процессе переработки я, наконец-то, заменил все глаголы в именах функций на одобренные (см. Get-Verb). Имя самого сценария я изменю чуть позже.
Исправил ситуацию с возвращением функцией Receive-DnsData пустого ответа.
Исправил опечатки, некорректную обработку ошибок, немного улучшил комментарии.
Также, вернул на место забытое объявление переменной $SMTPCc.

В будущем планирую добавить поддержку ShouldProcess (WhatIf).

Ваши пулл-реквесты и сообщения о проблемах приветствуются!

Презентация LAPS

Как я писал ранее, в декабре я выступал на IT Pro UG с докладом о LAPS.
Видео, наконец-то, обработано и доступно:

Саму презентацию вы можете скачать здесь.

После доклада задали пару вопросов:
Q: Передаётся ли пароль открытым текстом по сети в момент его обновления или считывания утилитой?
A: Нет, LDAP-соединение в таких случаях защищается при помощи SASL. Однако же, если при установке соединения в собственных средствах/скриптах вы явно укажете LDAP_OPT_ENCRYPT = 0 или будете использовать ldap_simple_bind без TLS/SSL, тогда всё будет передаваться открытым текстом.

Q: Почему бы вообще локальные учетки не отключать? При каком бизнес-сценарии нам понадобится управлять их паролями?
A: Например, в том случае, если машина потеряла домен и надо получить к ней доступ с минимальными изменениями (без перезагрузок, оффлайн-сброса пароля и т.п.). Кеш доменного пароля толже может не помочь в таком сценарии, если на машине не сохранён ни один из известных — с LAPS можно быть более уверенным, что доступ к системе получишь.

SCDPM в зонированной инфраструктуре

Построение безопасной инфраструктуры в компании обычно подразумевает разделение ресурсов по нескольким зонам безопасности, которые управляются разными администраторами (или, по крайней мере, одними и теми же администраторами, но под разными учётными записями). Например, можно выделить серверы с важными данными, такие как центры сертификации PKI, хостовые машины Hyper-V или машины содержащие персональные данные, и определить их как «Зона 1». Остальные серверы можно обозначить как «Зона 2». Разрешения настраиваются таким образом, чтобы в каждой зонае были свои собственные локальные администраторы, логоны пользователей между зонами — запрещаются (кроме сетевого входа в систему — он обычно не несёт рисков безопасности).

В идеальном мире, для обслуживания каждой зоны безопасности используется своя собственная выделенная инфраструктура, но в реальной жизни не всегда возможно изыскать дополнительные ресурсы для полноценной поддержки инфраструктуры и приходится идти на компромисы. В таком случае, обслуживающие серверы, в т.ч. серверы резервного копирования, логично разместить в более доверенной зоне (зоне 1) — таким образом более защищённые серверы будут получать доступ к менее защищённым, но не наоборот.

Что это означает для SCDPM? DPM не предназначен для резервного копирования между зонами безопасности, но мы можем его заставить.
После того, как вы установили агент SCDPM на сервер в зоне 2, вы должы прикрепить его к серверу SCDPM в зоне 1. На этом шаге, пользователи, под которым вы прикрепляете агента, должен быть локальным администратором одновременно и на сервере, и на клиенте. В зонированной инфраструктуре это невоможно, т.к. одна учётная запись не может быть локальным администратором на машинах в двух разных зонах.
Что же делать? Придётся предоставить необходимые разрешения гранулированно:

Шаг 1

Мы должны предоставить для администратора зоны 1 следующие разрешения на корень WMI на сервере из зоны 2:

  • Enable
  • MethodExecute
  • RemoteAccess
  • ReadSecurity

Вы можете назначить эти разрешения через графический интерфейс (wmimgmt.msc) или через PowerShell.
Если вы выберете PowerShell, используйте эту версию сценария Set-WmiNamespaceSecurity.ps1. В этой версии исправлено назначение наследований разрешений — оригинальный сценарий Стива Ли падает с ошибкой «Invoke-WmiMethod : Invalid parameter».
Запустите сценарий на клиенте из зоны 2 с такими параметрами:
Set-WmiNamespaceSecurity.ps1 -namespace 'root' -operation 'add' -account 'EXAMPLE\tier1-admin' -permissions 'Enable','MethodExecute','RemoteAccess','ReadSecurity' -allowInherit $true

При назначении разрешений через графический интерфейс, они должны выглядеть так:

Шаг 2

Второй шаг немного контр-интуитивный: Как известно, сервер SCDPM запрашивает с агента его часовой пояс и сохраняет в своей базе. Почему-то, назначение разрешений из шага 1 не даёт не-администратору возможность удалённо запросить эти данные. В качестве обходного пути, выполните вот такой запрос к WMI на клиенте SCDPM: select * from Win32_TimeZone. После этого, не-администратор в течение некоторого времени сможет запрашивать часовой пояс удалённого компьютера.
Команда PowerShell для этого: Get-WmiObject -Query 'select * from Win32_TimeZone'

После выполнения этих двух шагов, у вас должно получиться успешно добавить агента из зоны 2 на сервер SCDPM в зоне 1. После этого, вы можете отозвать только что выданные разрешения: Set-WmiNamespaceSecurity.ps1 -namespace root -operation delete -account 'EXAMPLE\tier1-admin'

Синхронизация split-brain DNS

Последнюю версию скрипта вы всегда можете найти на GitHub.

Множество компаний использует одну и ту же доменную зону, как во внутренней инфраструктуре, так и во внешней. В случае, если внутренняя зона, по совместительству, является именем домена Active Directory и внутренние пользователи должны обращаться к некоторым серверам из этой зоны с использованием их внешних IP-адресов, возникает проблема: Каким то образом все такие записи должны присутствовать в синхронизированном состоянии и на внешних, и на внутренних DNS-серверах.
Существует несколько способов решения такой проблемы:

1. Использовать контроллеры домена Active Directory для разрешения имён и внешними, и внутренними пользователями.

За:

  • Единая точка управления.
  • Не требуется никакого дополнительного ПО на контроллерах домена.

Против:

  • Невозможно сделать так, чтобы для одного и того же имени внешним и внутренним пользователям возвращалась разная информация.
  • Необходимо предоставить внешним пользователям доступ во внутреннюю инфраструктуру, что может быть невозможно по политикам безопасности. Злонамеренный пользователь может получить информацию о внутренней инфраструктуре.
2. Использовать два независимых набора DNS-серверов: внутренние и внешние.

За:

  • Можно сделать так, чтобы для одного и того же имени внешним и внутренним пользователям возвращалась разная информация.
  • У внешних пользователей отсутствует доступ к внутренней инфраструктуре.
  • Не требуется дополнительного ПО на контроллерах домена.

Против:

  • Две точки управления. DNS-записи могут стать рассинхронизированными.
3. Использовать новую функциональность Windows Server 2016 — политики DNS.

(https://blogs.technet.microsoft.com/teamdhcp/2015/08/31/split-brain-dns-in-active-directory-environment-using-dns-policies/)
За:

  • Единая точка управления.
  • Можно сделать так, чтобы для одного и того же имени внешним и внутренним пользователям возвращалась разная информация.

Против:

  • Контроллеры домена должны быть обновлены на новейшее ПО, что подходит не для всех организаций.
  • Необходимо предоставить внешним пользователям доступ во внутреннюю инфраструктуру, что может быть невозможно по политикам безопасности. Злонамеренный пользователь может получить информацию о внутренней инфраструктуре.

 

Лично я пока предпочитаю второй способ, с различными внешними и внутренними DNS-серверами. В этом случае появляется еще одна проблема: Как обеспечить своевременную синхронизацию тех DNS-записей, которые должны быть одинаковыми для внутренних и внешних пользователей?
Читать далее Синхронизация split-brain DNS

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

Представьте, что половина ваших пользователей — локальные администраторы на своих машинах. Довольно часто они переустанавливают ОС и просят службу поддержки ввести их компьютеры заново в корпоративный домен 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.

«0x80070721 A security package specific error occurred» при подключении к WMI между доменами

Симптомы:

Предположим, у вас есть 2 сервера IBM System x с установленной ОС Windows Server 2012 или более новой и с активированным сетевым интерфейсом IBM USB Remote NDIS Network Device. Они расположены в одном лесу Active Directory, но в разных доменах.
Вы пытаетесь установить соединение к WMI между ними (например, с использованием wbemtest). В этом случае, соединение не установится, и вы получите следующую ошибку:

Number: 0x80070721 Facility: Win32 Description: A security package specific error occurred.»
In System log of the server which initiates the connection we have:
Log Name: System
Source: Microsoft-Windows-Security-Kerberos
Date: 10/6/2013 9:13:09 PM
Event ID: 4
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: SRV1.alpha.example.com
Description:
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server srv1$. The target name used was host/srv2.beta.example.com. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (ALPHA.EXAMPLE.COM) is different from the client domain (BETA.EXAMPLE.COM), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

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

Начиная с Windows Server 2012, когда вы подключаетесь к WMI другого компьютера, Windows запрашивает список IP-адресов сетевых интерфейсов у удалённой системы. Далее, клиент определяет, к какому из полученных от удалённой системы IP-адресу ему лучше подключаться.
В случае серверов IBM System x, на них на обоих есть сетевой интерфейс с одним и тем же IP-адресом — 169.254.95.120. Windows выбирает его, как наиболее подходящий для установки соединения, но, т.к. клиентская машина обладает таким же IP-адресом, она подключается сама к себе. В результате, вы видите ошибку.

Когда вы пытаетесь подключиться к удалённому компьютеру с помощью wbemtest, вы вызываете WMI API. В фоне, WMI использует DCOM для связи с другими серверами. Когда DCOM устанавливает сессию, он использует запрос «ServerAlive2», чтобы проверить другой сервер.
Вот, как это выглядит в записи сетевого траффика:

14 14:38:55 10.01.2014 0.0111483 srv2.beta.example.com 135 (0x87) 91.103.70.14 55535 (0xD8EF) DCOM DCOM:IObjectExporter:ServerAlive2 Response {MSRPC:10, TCP:9, IPv4:8}
NetworkAddress: srv1
NetworkAddress: 169.254.95.120
NetworkAddress: 192.0.2.1

Тот же траффик, если мы попробуем подключиться с обратной стороны:

38 14:37:12 10.01.2014 37.1871388 srv1.alpha.example.com 135 (0x87) 10.253.12.2 59278 (0xE78E) DCOM DCOM:IObjectExporter:ServerAlive2 Response {MSRPC:14, TCP:13, IPv4:8}
NetworkAddress: srv2
NetworkAddress: 169.254.95.120
NetworkAddress: 203.0.113.2

Уровень приложения выбирает общий IP и заворачивает соединение назад. DCOM получает билет Kerberos и пробует аутентифицироваться с ним, вот почему мы видим ошибку AP_ERR_MODIFIED. То есть соединение на основе DCOM (WMI, как пример) не будет работать, если участники имеют общий IP-адрес.

Эта проблема известна Microsoft и не будет исправлена, т.к. это работает так, как задумано.

Как лучше всего выходить из такой ситуации?

  1. Отключите сетевой интерфейс IMM USB Network Interface на, по крайней мере, одном из серверов. Но будьте внимательны: обновление микрокода IMM из Windows или использование средства ASU64 включит этот интерфейс обратно.
    Если вы выберите этот способ, я рекомендую вам настроить вашу систему мониторинга таким образом, чтобы она предупреждала вас, если этот сетевой интерфейс будет активирован.
  2. Измените IP-адрес на любом из сетевых интерфейсов на какой-нибудь другой. Вы можете использовать практически любой адрес из частных сетей, но вот рекомендации IBM по этому поводу.

Process Monitor 3.10

Коллеги, Process Monitor обновился до версии 3.10 и вот почему это важно:

Как вам может быть известно, открывать ключи реестра на чтение можно как минимум двумя функциями с противоположными по смыслу названиями: RegCreateKeyEx и RegOpenKeyEx. RegCreateKeyEx создаёт переданный ей ключ реестра, а если он уже существует, просто открывает его. При этом, функция записывает выполненное действие (создание/открытие) в отдельную переменную, которую ей тоже можно передать при вызове.
RegOpenKeyEx создавать ключи реестра не умеет и в случае отсутствия переданного ей ключа, возвращает ошибку.

Ранее, у нас не было возможности понять в Process Monitor’е, какую именно операцию выполнила функция RegCreateKeyEx, свойство Granted Access для вызова такой функции всегда содержало строку «Read/Write».

В последнем обновлении Process Monitor 3.10 наконец-то научили распознавать действие, произведённое функцией RegCreateKeyEx. Свойства Granted Access для операции RegСreateKey больше нет, зато есть новое свойство Disposition в котором будет указано:
REG_CREATED_NEW_KEY — если функция RegCreateKeyEx создала отсутствующий ключ реестра.

REG_OPENED_EXISTING_KEY — если ключ существовал до вызова функции RegCreateKeyEx и она его просто открыла.

Свойство Desired Access осталось неизменным — «Read/Write», что логично, т.к. до вызова функции неизвестно, что именно она будет делать.

Новая возможность Process Monitor позволит вам быстро фильтровать события. Для этого добавьте условие в котором колонка Detail содержит либо REG_CREATED_NEW_KEY, либо REG_OPENED_EXISTING_KEY.

Unable to find the callback library jcb.dll (or one of its dependencies)

Для дефрагментации БД Exchange на компьютере, где не установлены компоненты управления Exchange, вы, вероятно, воспользуетесь статьёй Microsoft 244525: How to run Eseutil on a computer without Exchange Server. Я воспользовался этой статьёй для дефрагментации БД Exchange 2003 на свободном сервере с установленной Windows Server 2008 R2.

Через некоторое время работы eseutil (когда процесс использовал чуть больше 2 ГБ оперативной памяти), я получил ошибку, описанную в статье 273087: Error With Jcb.dll While Running Eseutil. К сожалению, описанные в ней способы мне не помогли: при нажатии кнопки Cancel, я получал ошибку «Operation terminated with error -2102 JET_errCallbackNotResolved, A callback function could not be found) after 1168.136 seconds.».

В итоге, воспользовавшись Process Monitor’ом, я выяснил, что для Windows Server 2008 R2 описанных в оригинальной статье Microsoft и в сообщении в треде «Re: JCB.DLL Not Found Error» файлов недостаточно — нужен ещё 1 файл: ntlsapi.dll. Я скопировал его из исходной системы Windows Server 2003 R2 SP2 с работающим Microsoft Exchange 2003 SP2 на целевую систему Windows Server 2008 R2 SP1, на которой производил дефрагментацию, и всё прошло нормально.