🪟 Windows: Понедельник — день «Locked Out». Спасаем пользователей массово 🔓

Утро понедельника у хелпдеска всегда одинаковое: "Я вводил пароль правильно, но оно не пускает!". После выходных пальцы пользователей забывают моторику, Caps Lock нажимается случайно, и половина офиса сидит с заблокированными учетками.

Не надо кликать мышкой в ADUC каждого страдальца. PowerShell спасет твой утренний кофе.

# Найти всех, кто заблокировался, и показать время блокировки
Search-ADAccount -LockedOut | Select-Object Name, SamAccountName, LockedOutTime | Format-Table -AutoSize

# Если ты чувствуешь себя великодушным — разблокировать ВСЕХ одной командой
Search-ADAccount -LockedOut | Unlock-ADAccount

Только убедись перед массовой разблокировкой, что это реальные пользователи, а не брутфорс-атака на RDP!

#windows #powershell #activedirectory #monday #automation #sysadmin #admin_future

🪟 Windows: Протокол «Чистые руки». Нативный LAPS и смерть локальных паролей

Коллеги, признавайтесь: у кого в блокноте или в закрытом чате до сих пор лежит «тот самый» пароль от локального админа, который подходит к половине серверов в сегменте? В 2026 году это не просто дыра, это широко распахнутые ворота для любого шифровальщика. Если одна машина в DMZ скомпрометирована — считайте, что упал весь домен.

Техническая суть:

Мы используем Windows LAPS (Local Administrator Password Solution), который теперь нативно интегрирован в ОС и Active Directory. Больше никаких сторонних костылей.

Как это работает: Каждая машина в домене генерирует уникальный, сложный пароль для своей учетки локального администратора. Этот пароль шифруется и сохраняется в защищенном атрибуте объекта компьютера в AD. Доступ к чтению этого атрибута жестко ограничен через ACL только для группы «Trusted Admins». Каждые 30 дней (или по вашему триггеру) пароль ротируется автоматически.

Практика:

Получаем актуальный пароль для проблемного сервера через PowerShell (все действия логируются, так что «просто посмотреть» не выйдет):

# 1. Проверяем состояние LAPS на конкретном сервере
Get-LapsDiagnostics -ComputerName "SRV-DB-01"

# 2. Получаем текущий пароль (требуются права доступа к зашифрованному атрибуту)
Get-LapsADPassword -Identity "SRV-DB-01" -AsClearText

# Вывод:
# ComputerName  Password            Expiration
# ------------  --------            ----------
# SRV-DB-01     $tr0ng_P@ss_2026!   10.04.2026 14:00:00

# 3. Принудительно заставляем сервер сменить пароль прямо сейчас
Set-LapsADPasswordExpiration -Identity "SRV-DB-01" -In 0

Зачем это нужно:

Полное исключение атаки типа Pass-the-Hash. Даже если злоумышленник вытащит хеш с одного сервера, он не сможет зайти под ним на другой. Админ больше не знает паролей — он получает их по требованию под присмотром аудита.

#windows #security #laps #powershell #activedirectory #admin_future

🛡️ Windows: Аудит элитного клуба — мониторим Domain Admins через PowerShell

Доверие — это отлично, но контроль — лучше. Особенно если дело касается группы Domain Admins. Представьте: в вашей инфраструктуре есть только два легитимных администратора — условные Bogdan и Roman. А в один прекрасный день скрипт показывает третьего. Это либо взлом, либо кто-то временно выдал права техподдержке и забыл забрать. В 2026 году такие инциденты стоят бизнесу миллионы.

Вместо того чтобы кликать мышкой по оснастке Active Directory, повесьте в планировщик задач простой скрипт, который будет следить за изменениями.

Скрипт мониторинга критичной группы:

$Domain = "domain.local"
$GroupName = "Domain Admins"
$AllowedAdmins = @("adm1", "adm1", "adm3")

# Получаем текущий состав группы
$CurrentMembers = Get-ADGroupMember -Identity $GroupName -Server $Domain | Select-Object -ExpandProperty SamAccountName

# Ищем чужаков
$Unauthorized = $CurrentMembers | Where-Object { $_ -notin $AllowedAdmins }

if ($Unauthorized) {
    Write-Warning "⚠️ АЛАРМ! Найдены неавторизованные пользователи в Domain Admins: $($Unauthorized -join ', ')"
    # Здесь можно добавить код отправки алерта в Telegram или на почту
} else {
    Write-Host "✅ Состав группы Domain Admins в норме." -ForegroundColor Green
}

Группа политик безопасности (GPO) не всегда спасет, если учетка скомпрометирована. Автоматический аудит критически важных групп — это ваш первый рубеж обнаружения внутренних угроз.
Безопасность домена начинается с понимания того, у кого от него ключи.

#windows #powershell #activedirectory #security #audit #admin_future

🧹 Windows: Уборка в лесу — ищем GPO-призраки через PowerShell

Коллеги, в любом домене со временем накапливается мусор. Мы создаем тестовые политики, применяем их, а потом забываем удалить. Когда приходит время провести масштабную реструктуризацию политик и передать часть функционала коллеге, этот мусор сильно мешает и путает.

Скрипт ниже найдет все групповые политики, которые либо полностью отключены, либо никуда не привязаны.

Код для PowerShell:

$AllGPOs = Get-GPO -All
foreach ($GPO in $AllGPOs) {
$Report = Get-GPOReport -Guid $GPO.Id -ReportType Xml
if ($GPO.GpoStatus -eq 'AllSettingsDisabled' -or $Report -notmatch 'LinksTo') {
Write-Host "Кандидат на удаление: " $GPO.DisplayName}
}

Чистый Active Directory работает быстрее и предсказуемее. Любая реструктуризация GPO должна начинаться с удаления всего, что не работает и просто висит мертвым грузом.

#windows #powershell #activedirectory #gpo #sysadmin #admin_future

👻 WINDOWS: ОХОТА ЗА ПРИЗРАКАМИ. УДАЛЯЕМ МЕРТВЫЕ SID ИЗ ПРАВ ДОСТУПА

При реорганизации инфраструктуры и чистке домена от легаси-объектов мы часто удаляем старые учетные записи. Но права доступа на файловых серверах (NTFS ACL) остаются. Вместо имен пользователей там появляются неопознанные SID (начинаются с S-1-5-21...).

Это не просто эстетическая проблема. При миграции серверов или глубоком аудите эти мертвые души сильно тормозят пересчет прав, ломают наследование и создают хаос в политиках безопасности.

PowerShell скрипт для поиска и удаления мертвых SID:

$Path = "C:\Shares\Department"
$ACLs = Get-Acl -Path $Path
$Rules = $ACLs.Access | Where-Object { $_.IdentityReference -match "^S-1-5-21" }

foreach ($Rule in $Rules) {
    $ACLs.RemoveAccessRule($Rule) | Out-Null
    Write-Host "Удален мертвый SID: " $Rule.IdentityReference
}
Set-Acl -Path $Path -AclObject $ACLs

Зачем это нужно:
Порядок в Active Directory должен отражаться порядком в файловых системах. Идеально подходит для включения в план реструктуризации домена и вывода из эксплуатации старых систем вроде Windows 2012 R2.

#windows #powershell #activedirectory #security #admin_future

🪟 Windows: LAPS v2 + Entra ID — хватит хранить пароль локального админа в Excel

Коллеги, я знаю, что где-то в вашей сети до сих пор живёт локальный Administrator с паролем из 2019 года, который записан в заметках у Богдана. И Богдан уже полгода как уволился.

Классический LAPS первого поколения умел ротировать пароль и класть его в AD — и это было неплохо. Но LAPS v2, встроенный в Windows Server 2025 и Windows 11, это уже другой уровень: шифрование пароля в AD, история паролей, поддержка Entra ID (Azure AD) для гибридных сред и ротация по требованию через PowerShell или Intune.

Включаем и настраиваем правильно:

# 1. Обновляем схему AD (один раз, на DC)
Update-LapsADSchema

# 2. Настраиваем права на OU с рабочими станциями
Set-LapsADComputerSelfPermission -Identity "OU=Workstations,DC=corp,DC=local"

# 3. Создаём GPO-политику через PowerShell (или через GUI GPMC)
# Путь в GPO: Computer -> Admin Templates -> LAPS
# Ключевые параметры:
#   - Enable password backup to AD: Enabled
#   - Password complexity: Large letters + small + digits + specials
#   - Password age: 30 days
#   - Enable encrypted password: Enabled  <-- вот это обязательно в v2

# 4. Смотрим пароль для конкретной машины (только авторизованным)
Get-LapsADPassword -Identity "PC-FINANCE-01" -AsPlainText

# 5. Принудительная ротация после инцидента
Invoke-LapsPolicyProcessing  # на машине
# или удалённо:
Reset-LapsPassword -Identity "PC-FINANCE-01"

Зачем это нужно:
Lateral movement через один скомпрометированный локальный пароль — классика пентестов и реальных атак. LAPS v2 с шифрованием и историей убирает этот вектор полностью. Пентестеры будут грустить, аудиторы — радоваться, а ты — спать спокойно.

Итог: Если у тебя больше 20 машин в домене и LAPS не настроен — это не техдолг, это открытая дверь. Закрой её сегодня, это займёт два часа.

#windows #laps #activedirectory #security #sysadmin #admin_future

🪟 Windows: dMSA в Server 2025 — Microsoft дала нам инструмент и сразу два способа им порезаться

Коллеги, поговорим о ситуации, которую я называю "security feature, meet security incident". Windows Server 2025 принёс delegated Managed Service Accounts (dMSA) — красивая замена старым сервисным учёткам с паролем "Service2019!" в Confluence. dMSA привязывает аутентификацию к идентичности конкретной машины: только явно указанные машины в AD могут получить доступ к учётной записи, что закрывает классический Kerberoasting.

Звучит хорошо. Но есть нюанс.

Исследователи из Akamai нашли атаку BadSuccessor: злоумышленник с минимальными правами на любой OU в домене может создать вредоносный dMSA, который имитирует процесс миграции и наследует все права любого пользователя — вплоть до Domain Admin. При этом права над целевой учёткой не нужны вообще. Patch до сих пор в разработке.

Что делать прямо сейчас — аудит и ограничение прав на создание dMSA:

# Akamai выпустили скрипт для аудита — запускаем и смотрим кто может создавать dMSA
# Скачиваем с их GitHub:
# https://github.com/akamai/BadSuccessor

# Ручная проверка — кто имеет право создавать объекты типа msDS-DelegatedServiceAccount в OU
Import-Module ActiveDirectory

$OUs = Get-ADOrganizationalUnit -Filter * -Properties nTSecurityDescriptor

foreach ($OU in $OUs) {
    $acl = Get-Acl "AD:$($OU.DistinguishedName)"
    $acl.Access | Where-Object {
        $_.ActiveDirectoryRights -match "CreateChild" -and
        $_.ObjectType -eq [guid]"ce206244-5827-4a86-ba1c-1c0c386c1b64"
        # ObjectType для msDS-DelegatedServiceAccount
    } | Select-Object IdentityReference, ActiveDirectoryRights |
    ForEach-Object {
        [PSCustomObject]@{
            OU       = $OU.Name
            Identity = $_.IdentityReference
            Rights   = $_.ActiveDirectoryRights
        }
    }
} | Format-Table -AutoSize | Export-Csv "dMSA_create_rights_audit.csv" -NoTypeInformation

# Включаем аудит событий dMSA — чтобы хотя бы видеть атаку
auditpol /set /subcategory:"Directory Service Changes" /success:enable /failure:enable

# Мониторим Event ID 5136 — изменения атрибута msDS-DelegatedMSAState
# и Event ID 4662 — изменения msDS-ManagedAccountPrecededByLink
# Эти два события вместе = сигнал возможной BadSuccessor-атаки
Get-WinEvent -LogName "Security" -FilterXPath `
  "*[System[EventID=5136] and EventData[Data[@Name='AttributeLDAPDisplayName']='msDS-DelegatedMSAState']]" |
  Select TimeCreated, Message | Format-List

Зачем это нужно:
По данным Akamai, в 91% исследованных сред нашлись пользователи за пределами группы Domain Admins, у которых были права для проведения этой атаки. Если у вас Server 2025 DC в домене — проверьте, кто может создавать dMSA объекты, прямо сегодня. Это займёт 10 минут.

Итог: Microsoft сделала dMSA для защиты от Kerberoasting — и это правильно. Но разворачивать новую фичу в продакшн без аудита прав — всё равно что поставить бронедверь и забыть закрыть окно. Следите за патчем.

#windows #activedirectory #security #dmsa #kerberos #sysadmin #admin_future

#windows #patchtuesday #bitlocker #activedirectory #security #sysadmin #admin_future

🪟 Windows: Апрельский Patch Tuesday сломал DC — и Microsoft уже выпустила OOB-фикс

Коллеги, если вы ещё не слышали — апрельское обновление KB5082063 наломало дров. Контроллеры домена в средах с Privileged Access Management (PAM) уходили в бесконечный цикл перезагрузок из-за краша LSASS. Затронуты все версии Windows Server от 2016 до 2025.

Хорошая новость: 19 апреля Microsoft выпустила внеплановые OOB-обновления. Для Windows Server 2025 — KB5091157 (стандартный) или KB5091470 (для hotpatch-сред, без перезагрузки).

# Проверяем установлен ли проблемный патч
Get-HotFix | Where-Object {$_.HotFixID -eq "KB5082063"}

# Проверяем статус LSASS и не крутится ли DC в петле
Get-Service lsass | Select-Object Status
Get-EventLog -LogName System -Newest 20 |
    Where-Object {$_.Source -like "*LSASS*" -or $_.Source -like "*SAM*"}

# Устанавливаем OOB-фикс вручную (скачать с Microsoft Update Catalog)
# Для WS2025: KB5091157
# Для WS2022: KB5091575
# Для WS2019: KB5091574

# Если DC уже в петле — загружаемся в DSRM и откатываем:
# В меню Advanced Boot Options -> Directory Services Restore Mode
# Затем из cmd:
dism /image:C:\ /get-packages | findstr /i "KB5082063"
# dism /image:C:\ /remove-package /packagename:[имя_пакета]

Зачем это нужно:
Апрельские апдейты ломали контроллеры домена уже три года подряд. Вывод простой: DC обновляем последними, держим снапшот перед каждым Patch Tuesday и знаем наизусть путь в DSRM.

Итог: KB5091157 ставим немедленно. Без него KB5082063 на DC — это потенциальная недоступность домена.

#windows #activedirectory #patchtuesday #sysadmin #admin_future

🪟 Windows: Kerberos RC4 enforcement уже включился — что сломалось и что делать

Коллеги, апрельский Patch Tuesday принёс не только патчи, но и тихое изменение, которое уже ломает аутентификацию в тех средах, где не подготовились.

Начиная с апреля 2026 года, апрельское накопительное обновление меняет дефолтное поведение Kerberos KDC: для учётных записей без явно заданного msDS-SupportedEncryptionTypes теперь выдаются только AES-SHA1-билеты. RC4 больше не используется по умолчанию.

Что это значит практически: сервисные учётки, NAS-устройства, принтеры, старые приложения и любая учётка без явного атрибута шифрования — потенциальная жертва. Симптомы: ошибки "KDC has no support for encryption type", сервисы не стартуют, авторизация в приложениях падает.

В июле 2026 поведение зафиксируется окончательно и откат в режим аудита станет невозможен. Времени мало.

# ШАГ 1: Ищем учётки БЕЗ AES-ключей
# Скрипт от Microsoft (GitHub: microsoft/Kerberos-Crypto):
# List-AccountKeys.ps1 — находит аккаунты с RC4 но без AES

# Ручная проверка: смотрим Event ID 201, 202 в System Log DC
Get-WinEvent -LogName System -ComputerName (hostname) |
    Where-Object {$_.Id -in @(201,202,206,207)} |
    Select-Object TimeCreated, Id, Message |
    Format-List

# ШАГ 2: Для сервисных учёток — сбрасываем пароль (генерирует AES-ключи)
Set-ADAccountPassword -Identity "svc_sql" -Reset `
    -NewPassword (ConvertTo-SecureString "NewP@ssw0rd!" -AsPlainText -Force)

# ШАГ 3: Явно задаём шифрование для проблемных учёток
# 0x18 = AES128 + AES256, 0x1C = AES128 + AES256 + RC4 (временно)
Set-ADUser -Identity "svc_legacy_app" `
    -KerberosEncryptionType AES128,AES256

# ШАГ 4: Временный откат если уже всё сломалось
# Возвращаем DC в режим аудита (работает ДО июля 2026):
Set-ItemProperty `
    -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Kdc" `
    -Name "RC4DefaultDisablementPhase" -Value 1

# ШАГ 5: Проверяем krbtgt — если пароль не менялся с 2008 года, AES-ключей нет
Get-ADUser krbtgt -Properties msDS-SupportedEncryptionTypes,PasswordLastSet |
    Select-Object Name, PasswordLastSet, msDS-SupportedEncryptionTypes
# Если PasswordLastSet старше 2012 — сбрасываем ДВАЖДЫ с репликацией между сбросами

Зачем это нужно:
RC4 позволяет Kerberoasting: атакующий запрашивает билет, зашифрованный RC4, и взламывает его оффлайн. Современные GPU делают это за минуты. Microsoft убирает RC4 принудительно — и это правильно.

Итог: аудит уже три месяца доступен через Event ID 201-202. Если ты не смотрел — посмотри сегодня. Июль ждать не будет.

#windows #kerberos #activedirectory #security #sysadmin #admin_future

🧠 Skills: Privilege creep — тихая дыра которая растёт годами и взрывается в инцидент

Коллеги, пятничный пост о вещи которую все знают теоретически, но мало кто делает системно на практике.

Даже самая совершенная система управления правами со временем деградирует — «дрейф привилегий». Сотрудники меняют должности, увольняются, а их старые доступы остаются активными. Систематический аудит позволяет выявить «мёртвые души» — аккаунты уволенных, избыточные права администраторов и факты несанкционированного доступа к критичным папкам.

Copy Fail, PhantomRPC, CVE-2026-32202 — все три эксплуатируют локальный или сетевой доступ. Принцип наименьших привилегий напрямую ограничивает радиус поражения каждой из них.

Практический аудит привилегий — делаем сегодня:

# ---- WINDOWS AD: кто лишний в привилегированных группах ----
# Топ-3 группы риска:
$groups = @("Domain Admins","Enterprise Admins","Schema Admins")
foreach ($g in $groups) {
    Write-Host "=== $g ===" -ForegroundColor Red
    Get-ADGroupMember $g -Recursive |
        Get-ADUser -Properties LastLogonDate, Enabled |
        Select-Object Name, Enabled, LastLogonDate |
        Sort-Object LastLogonDate
}
# Всё что не логинилось > 90 дней — под вопросом

# Ищем аккаунты уволенных (не отключены, но не логинились):
$cutoff = (Get-Date).AddDays(-90)
Get-ADUser -Filter {Enabled -eq $true -and LastLogonDate -lt $cutoff} `
    -Properties LastLogonDate, Department |
    Select-Object Name, Department, LastLogonDate |
    Export-Csv "stale_accounts.csv" -NoTypeInformation

# ---- LINUX: кто имеет sudo и не должен ----
# На каждом сервере:
grep -Po '^sudo.+:\K.*' /etc/group | tr ',' '\n'
cat /etc/sudoers /etc/sudoers.d/* 2>/dev/null | \
    grep -v "^#\|^$" | grep "ALL="
# Всё что не "systemd-related" и не конкретные команды — ревью

# ---- LINUX: сервисные учётки с интерактивным shell ----
awk -F: '$7 != "/sbin/nologin" && $7 != "/bin/false" && \
    $3 >= 500 {print $1, $7}' /etc/passwd
# Сервисные аккаунты должны иметь /sbin/nologin
# Если видишь /bin/bash — это либо человек либо проблема

# ---- АВТОМАТИЗАЦИЯ РЕВЬЮ (раз в квартал) ----
# Добавляем в cron/CI:
# 0 9 1 */3 * /opt/scripts/privilege_audit.sh | \
#   mail -s "Quarterly Privilege Audit" admin@company.com

Зачем это срочно именно сейчас:
Принцип наименьших привилегий применим ко всем уровням — учётным записям пользователей, системам, процессам, сетям, базам данных и всем другим аспектам IT-инфраструктуры. Скомпрометированный аккаунт рядового сотрудника не должен открывать хакеру доступ к финансовым отчётам или ядру инфраструктуры.

Итог: один час аудита привилегий в пятницу — это несколько закрытых векторов атаки к понедельнику. Начни с Domain Admins. Обычно там уже есть сюрпризы.

#skills #security #privilegemanagement #activedirectory #linux #sysadmin #admin_future

🪟 Windows: RC4 в Kerberos — июль финализирует, а у тебя ещё не готово

Коллеги, сегодня последний день Windows Server Summit 2026. И главная тема которая звучала все три дня — RC4 в Kerberos. Не потому что новая. Потому что июль близко, а большинство до сих пор не закончили аудит.

Хронология жёсткая: январь 2026 — аудит-режим, предупреждающие события в логах DC. Апрель 2026 — enforcement: AES-SHA1 по умолчанию для учёток без явного msDS-SupportedEncryptionTypes. Июль 2026 — финал: RC4 убирается из протокольного пути полностью, ключ реестра RC4DefaultDisablementPhase игнорируется.

Что реально сломается если не подготовиться: сервисные учётки, NAS-устройства, принтеры, старые приложения, любая учётка без явного атрибута шифрования. Симптом: ошибка «KDC has no support for encryption type», сервисы не стартуют, авторизация в приложениях падает.

# ШАГ 1: Смотрим Event ID 201-209 на DC — кто ещё использует RC4
Get-WinEvent -LogName System -ComputerName (hostname) |
    Where-Object {$_.Id -in @(201,202,203,206,207)} |
    Select-Object TimeCreated, Id, Message |
    Format-List | Select-Object -First 20

# Что означают ID:
# 201 — RC4 использован (клиент только RC4, у сервиса нет msDS-SET)
# 202 — RC4 использован (у учётки нет AES-ключей)
# 203 — RC4 ЗАБЛОКИРОВАН (это уже ошибка в апрельском enforcement)

# ШАГ 2: Ищем учётки без AES-ключей
Get-ADUser -Filter {Enabled -eq $true} `
    -Properties msDS-SupportedEncryptionTypes, PasswordLastSet,
    ServicePrincipalNames |
    Where-Object {$_.ServicePrincipalNames -ne $null} |
    Select-Object Name, PasswordLastSet, msDS-SupportedEncryptionTypes |
    Where-Object {$_.msDS-SupportedEncryptionTypes -eq $null -or
                  $_."msDS-SupportedEncryptionTypes" -eq 0}

# ШАГ 3: Генерируем AES-ключи для сервисных учёток
# Сброс пароля генерирует новые ключи автоматически:
Set-ADAccountPassword -Identity "svc_app01" -Reset `
    -NewPassword (ConvertTo-SecureString "NewP@ss2026!" -AsPlainText -Force)

# Явно задаём поддерживаемое шифрование:
Set-ADUser -Identity "svc_app01" `
    -KerberosEncryptionType AES128,AES256

# ШАГ 4: Проверяем krbtgt — если старый, AES-ключей нет:
Get-ADUser krbtgt -Properties PasswordLastSet,
    msDS-SupportedEncryptionTypes |
    Select-Object Name, PasswordLastSet, msDS-SupportedEncryptionTypes
# Если PasswordLastSet до 2012 — сбрасываем ДВАЖДЫ с репликацией

# ШАГ 5: Проверяем Event 4768/4769 на RC4-тикеты:
Get-WinEvent -LogName Security |
    Where-Object {$_.Id -in @(4768,4769)} |
    ForEach-Object {
        if ($_.Message -match "0x17") {
            Write-Host "RC4 ticket: $($_.TimeCreated) - $($_.Message)" `
                -ForegroundColor Red
        }
    } | Select-Object -First 10

Зачем это срочно именно сейчас: после июля 2026 аудит-режим убирается и реестровый ключ игнорируется. Единственный откат — вручную включить RC4 для конкретной учётки. Это не план, это последний шанс перед аварией.

Итог: Event ID 201/202 на DC — смотри прямо сейчас. Каждое событие это учётка или сервис, который упадёт в июле. У тебя меньше двух месяцев.

#windows #kerberos #activedirectory #rc4 #security #sysadmin #admin_future

🪟 Windows: Entra ID — две угрозы с одним дедлайном, 1 июня

Коллеги, пока все смотрели на Patch Tuesday и RC4 в Kerberos, в мире гибридной идентификации тихо созрели два изменения с одинаковым дедлайном — 1 июня 2026. Оба критичны для hybrid Entra Connect сред.

Первое: блокировка hard match для привилегированных учёток.

С 1 июня 2026 Microsoft Entra ID заблокирует любую попытку Entra Connect Sync или Cloud Sync выполнить hard-match нового объекта пользователя из Active Directory к существующему cloud-managed Entra ID пользователю с ролями Entra. Это защита от атак через манипуляцию атрибутами пользовательских объектов в Active Directory.

Почему это важно: атакующий с доступом к on-premises AD создаёт пользователя с matching sourceAnchor — и при следующей синхронизации захватывает cloud-identity включая Global Admin. Microsoft закрывает эту дыру принудительно.

Второе: уже закрытая (но проверить нужно) уязвимость Agent ID Administrator.

99% тенантов имеют хотя бы один привилегированный service principal. Пользователи с ролью Agent ID Administrator могли взять ownership произвольных service principals — включая те, у которых есть directory roles или высокоуровневые Graph permissions. Это полный захват service principal. Патч вышел 9 апреля, но следы активности нужно проверить.

# ---- ПРОВЕРКА К 1 ИЮНЯ ----

# 1. Найти cloud-привилегированные учётки КОТОРЫЕ могут сломаться:
# Ищем Entra-роли назначенные cloud-managed user с onPremisesImmutableId
Connect-MgGraph -Scopes "RoleManagement.Read.Directory","User.Read.All"

$roleAssignments = Get-MgRoleManagementDirectoryRoleAssignment -All |
    Where-Object {$_.PrincipalId -ne $null}

foreach ($ra in $roleAssignments) {
    $user = Get-MgUser -UserId $ra.PrincipalId `
        -Property OnPremisesImmutableId, DisplayName, UserPrincipalName `
        -ErrorAction SilentlyContinue
    if ($user -and $user.OnPremisesImmutableId) {
        Write-Host "РИСК: $($user.DisplayName) ($($user.UserPrincipalName))" `
            -ForegroundColor Red
        Write-Host "  Роль ID: $($ra.RoleDefinitionId)"
    }
}
# Все найденные — потенциально сломаются 1 июня при hard-match попытке

# 2. Проверяем Agent ID Administrator — кто назначен:
Get-MgDirectoryRole | Where-Object {$_.DisplayName -like "*Agent*"} |
    ForEach-Object {
        Get-MgDirectoryRoleMember -DirectoryRoleId $_.Id |
        Select-Object @{N="Role";E={$_.AdditionalProperties.displayName}},
                      @{N="Id";E={$_.Id}}
    }

# 3. Аудит подозрительных изменений ownership после февраля 2026:
# (период когда уязвимость могла эксплуатироваться)
Get-MgAuditLogDirectoryAudit -Filter `
    "activityDateTime ge 2026-02-01 and
     activityDisplayName eq 'Add owner to application'" |
    Select-Object ActivityDateTime, InitiatedBy, TargetResources |
    Export-Csv "agent_owner_audit.csv" -NoTypeInformation

# 4. Смотрим credential additions на service principals:
Get-MgAuditLogDirectoryAudit -Filter `
    "activityDateTime ge 2026-02-01 and
     activityDisplayName eq 'Add service principal credentials'" |
    Select-Object ActivityDateTime, InitiatedBy, TargetResources |
    Format-List | Select-Object -First 10

Зачем это срочно именно сейчас: если после 1 июня произойдёт ошибка hard match — см. документацию по шагам митигейшн. Лучше найти и исправить до дедлайна, чем разбираться почему синхронизация сломалась в начале июня.

Итог: два действия до 1 июня. Найти cloud-привилегированные учётки с onPremisesImmutableId. Проверить аудит Agent ID Administrator с февраля. Это займёт час — и закроет серьёзный вектор атаки.

#windows #entra #activedirectory #hybrididentity #security #sysadmin #admin_future

🪟 Windows: Entra hard match — 1 июня через 6 дней. Последний шанс проверить.

Коллеги, срочное напоминание. До дедлайна шесть дней — и это не тот дедлайн который переносят.

С 1 июня 2026 Microsoft Entra ID заблокирует любую попытку Entra Connect Sync или Cloud Sync выполнить hard-match нового объекта пользователя из Active Directory к существующему cloud-managed Entra ID пользователю, которому назначены Microsoft Entra роли. Если cloud-managed пользователь уже имеет onPremisesImmutableId (sourceAnchor) и назначенную роль — Connect Sync или Cloud Sync больше не смогут взять Source of Authority этого пользователя через hard-match с входящим AD-объектом.

Это защита от атаки SyncJacking — когда атакующие манипулируют синхронизацией каталогов чтобы захватить привилегированные cloud-идентичности. Hard match для непривилегированных аккаунтов не затронут. Поведение soft match не изменяется.

Дополнительный дедлайн который многие не заметили: все synchronization services в Microsoft Entra Connect Sync перестанут работать 30 сентября 2026 если не обновиться до версии минимум 2.5.79.0.

# ШАГ 1: Проверяем версию Entra Connect (нужна минимум 2.5.79.0):
Get-ADSyncGlobalSettings | Select-Object Version
# или
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Azure AD Connect" |
    Select-Object AzureADConnectVersion

# Если версия ниже 2.5.79.0 — СРОЧНО обновить:
# Скачать с: entra.microsoft.com -> Identity -> Hybrid management
# -> Entra Connect -> Download

# ШАГ 2: Находим cloud-привилегированные аккаунты которые могут
# сломаться при попытке hard-match после 1 июня:
Connect-MgGraph -Scopes "RoleManagement.Read.Directory","User.Read.All"

$allRoleAssignments = Get-MgRoleManagementDirectoryRoleAssignment -All

$riskyUsers = foreach ($ra in $allRoleAssignments) {
    try {
        $user = Get-MgUser -UserId $ra.PrincipalId `
            -Property OnPremisesImmutableId,DisplayName,UserPrincipalName `
            -ErrorAction Stop
        if ($user.OnPremisesImmutableId) {
            [PSCustomObject]@{
                DisplayName = $user.DisplayName
                UPN = $user.UserPrincipalName
                ImmutableId = $user.OnPremisesImmutableId
                RoleId = $ra.RoleDefinitionId
            }
        }
    } catch {}
}

$riskyUsers | Format-Table -AutoSize
$riskyUsers | Export-Csv "entra_hardmatch_risk.csv" -NoTypeInformation

# ШАГ 3: Если нашли проблемные аккаунты — два варианта:
# Вариант A: Убрать Entra-роль с синхронизированного пользователя
#   и назначить cloud-only аккаунту (правильный путь)
# Вариант B: Убедиться что AD-объект с таким sourceAnchor
#   уже синхронизирован (тогда блокировка не сработает —
#   блокирует только НОВЫЕ hard-match попытки)

# ШАГ 4: Тест синхронизации (запускаем и смотрим ошибки):
Start-ADSyncSyncCycle -PolicyType Delta
Get-ADSyncConnectorRunStatus | Format-Table -AutoSize

Зачем это критично прямо сейчас: если после 1 июня синхронизация попытается hard-match привилегированный аккаунт — она упадёт с ошибкой. Это может заблокировать lifecycle-операции: создание аккаунтов, обновления, отключения. В разгар рабочего дня.

Итог: два действия до пятницы. Проверить версию Entra Connect (должна быть 2.5.79.0+). Запустить скрипт поиска проблемных аккаунтов. Шесть дней — достаточно если начать сейчас.

#windows #entra #activedirectory #hybrididentity #security #sysadmin #admin_future

🪟 Windows: Entra hard match — сегодня 1 июня, блокировка включилась. Что происходит.

Коллеги, доброе утро понедельника с новой реальностью. Сегодня 1 июня 2026 — день когда Microsoft включила принудительную блокировку hard match для привилегированных Entra ID аккаунтов.

Что именно случилось сегодня:

Entra Connect Sync и Cloud Sync теперь блокируют любую попытку hard-match нового AD-объекта к существующему cloud-managed пользователю который имеет Entra роли. Существующие синхронизированные аккаунты не затронуты — блокируются только НОВЫЕ попытки hard match. Soft match поведение не изменяется.

Есть и вторая фаза: 1 июля 2026 — Entra Connect больше не сможет изменять атрибут OnPremisesObjectIdentifier после того как он уже установлен на синхронизированном пользователе. Это предотвращает переназначение уже синхронизированного пользователя на другой on-premises identity. Обе фазы возвращают одинаковую ошибку при блокировке: "Hard match operation blocked due to security hardening".

Если сегодня у тебя упала синхронизация с этой ошибкой:

# 1. Смотрим ошибки синхронизации:
# Entra Admin Center -> Identity -> Hybrid management
# -> Microsoft Entra Connect -> Sync errors

# Через PowerShell:
Get-ADSyncCSObject -ConnectorName "yourDomain.com" |
    Where-Object {$_.ErrorName -ne $null} |
    Select-Object Name, ErrorName, ErrorDetail |
    Format-List

# 2. Диагностируем конкретный аккаунт:
# Ищем cloud-user с onPremisesImmutableId и Entra ролью:
Connect-MgGraph -Scopes "User.Read.All","RoleManagement.Read.Directory"

$user = Get-MgUser -Filter "userPrincipalName eq 'user@domain.com'" `
    -Property OnPremisesImmutableId, Id
$roles = Get-MgUserTransitiveMemberOf -UserId $user.Id |
    Where-Object {$_."@odata.type" -eq "#microsoft.graph.directoryRole"}

Write-Host "ImmutableId: $($user.OnPremisesImmutableId)"
Write-Host "Roles: $($roles.DisplayName -join ', ')"

# 3. ПРАВИЛЬНОЕ РЕШЕНИЕ — убираем роль с синхронизированного аккаунта
# и назначаем cloud-only аккаунту (Best Practice):
# Remove-MgDirectoryRoleMember -DirectoryRoleId <roleId> `
#     -DirectoryObjectId $user.Id
# Создаём cloud-only admin account и назначаем роль ему

# 4. ВРЕМЕННЫЙ обходной путь (НЕ для production):
# Убрать onPremisesImmutableId с cloud-объекта чтобы разрешить hard match
# НО — это уберёт защиту от SyncJacking
# Делать ТОЛЬКО если понимаешь последствия

Контекст зачем это нужно: SyncJacking — атака где злоумышленник с определёнными привилегиями может злоупотребить hard matching синхронизацией в Entra Connect и полностью захватить любой синхронизированный Entra ID аккаунт — включая Active Global Administrator.

Итог: если всё работает — отлично, ты подготовился. Если упала синхронизация с ошибкой hard match — это не баг, это новая политика безопасности. Best practice: привилегированные роли только на cloud-only аккаунтах. Никогда на синхронизированных.

#windows #entra #activedirectory #hybrididentity #security #sysadmin #admin_future

🧠 Skills: RC4 в Kerberos окончательно похоронен. Если в AD что-то «само сломалось» с лета — проверяйте это первым

Коллеги, второй разбор на сегодня. Тема не просто горит — она уже сгорела у тех, кто проспал таймлайн обновлений Microsoft. Если сервисы внезапно начали сыпать ошибками аутентификации, дело наверняка в протоколах шифрования.

📌 ФАКТЫ (CVE-2026-20833, этапы выпиливания RC4)
Январь 2026 — Режим аудита: включен мониторинг событий KDCSVC с кодами 201–209 в журнале System без блокировки трафика.

Апрель 2026 — Дефолтный AES: для всех аккаунтов без явно заданных алгоритмов шифрования дефолтом стал AES. Фолбэк на устаревший RC4 был практически отключен.

Июль 2026 — Полный отказ: режим аудита окончательно удален из кода. Параметр реестра RC4DefaultDisablementPhase больше не учитывается операционной системой, а фолбэк на RC4 вырезан из протокола на уровне KDC.

Что ломается: любые учетные записи, у которых атрибут msDS-SupportedEncryptionTypes равен 0x4 / 0x7 (только RC4/DES) или вообще не задан, если клиент или сервис не умеют согласовывать AES.

💥 КТО В ЗОНЕ РИСКА
Сервисные учетки (gMSA / sMSA / обычные пользователи с SPN) с древними паролями: в базе NTDS банально отсутствуют AES-ключи до тех пор, пока учетке не сбросят пароль.

Linux-интеграции и демоны с устаревшими keytab: Samba, прокси-серверы, Java-бэкенды, Tomcat, веб-SSO, где keytab нарезался сто лет назад под RC4 (rc4-hmac).

Legacy-железо: древние СХД, прошивки принтеров/МФУ и сетевые сканеры с доменной авторизацией.

🛠 ДИАГНОСТИКА ЧЕРЕЗ POWERSHELL
Выполняем на контроллере домена или рабочей станции с RSAT:

PowerShell

# 1. Поиск сервисных учеток (с SPN) без явного AES или застрявших на RC4
Get-ADUser -LDAPFilter '(&(servicePrincipalName=*)(|(!(msDS-SupportedEncryptionTypes=*))(msDS-SupportedEncryptionTypes=4)(msDS-SupportedEncryptionTypes=7)))' `
  -Properties servicePrincipalName, msDS-SupportedEncryptionTypes, PasswordLastSet |
  Select SamAccountName, msDS-SupportedEncryptionTypes, PasswordLastSet

# 2. Мониторинг запросов билетов с шифрованием RC4 (TicketEncryptionType = 0x17)
Get-WinEvent -LogName Security -MaxEvents 2000 -FilterXPath `
  "*[System[EventID=4769] and EventData[Data[@Name='TicketEncryptionType']='0x17']]" |
  ForEach-Object { ([xml]$_.ToXml()).Event.EventData.Data |
    Where-Object { $_.Name -in 'TargetUserName','ServiceName','IpAddress' } |
    ForEach-Object { "$($_.Name)=$($_.'#text')" } } | Select-Object -First 60

# 3. Проверка событий KDC в журнале System (ошибки согласования типов шифрования)
Get-WinEvent -FilterHashtable @{
    LogName      = 'System'; 
    ProviderName = 'Microsoft-Windows-Kerberos-Key-Distribution-Center'; 
    Id           = 201..209
} -MaxEvents 50 -ErrorAction SilentlyContinue

🔧 РЕШЕНИЕ ПРОБЛЕМЫ
Включить флаг в реестре для возврата к RC4 больше нельзя — лазейку закрыли. Выход только один: планомерно переводить всё на AES.

PowerShell

# Шаг 1. Явно разрешаем использование современных типов шифрования
Set-ADUser svc_app -KerberosEncryptionType AES128,AES256

# Шаг 2. ОБЯЗАТЕЛЬНО меняем пароль (только в этот момент генерируются хеши AES!)
Set-ADAccountPassword svc_app -Reset

# Шаг 3. Перевыпускаем keytab для Linux-хостов с поддержкой AES256
# Через ktpass:
# ktpass /princ HTTP/app.corp.local@CORP.LOCAL /pass * /crypto AES256-SHA1 /ptype KRB5_NT_PRINCIPAL /out app.keytab
# Либо через msktutil:
# msktutil --enctypes 0x18 --auto-update

💡 В ЧЁМ СУТЬ

Времени на плавную раскатку больше нет — фолбэка нет физически. Отдельный маркер при ревизии: колонка

PasswordLastSet

. Если у сервисной учетки пароль не трогали с 2012 года, то помимо отсутствия AES-ключей вы получаете готовую дыру для атак Kerberoasting с мгновенным подбором слабого хеша в офлайне.

План на смену: выгрузить сервисные аккаунты без AES, запланировать смену паролей с владельцами сервисов и пересобрать ключевые keytab-файлы. Это час спокойной работы, который избавит вас от ночного дежурства при падении SSO.

#skills #activedirectory #kerberos #rc4 #aes #security #windows #powershell #sysadmin #admin_future

🛡 ПЛАН ДЕЙСТВИЙ (ЧЕКЛИСТ)
Собрать Event ID 4024 с парка: выгрузить события с машин под управлением 24H2 и Server 2025 — это готовый перечень узлов, которые потеряют связь при переключении режима.
Аудит политик на серверах NPS: локализовать все сетевые политики, где активен PEAP-MSCHAPv2, и оценить охват инфраструктуры.
Пилотное внедрение EAP-TLS: настроить шаблон сертификата Workstation Authentication, включить автоподписку (Auto-Enrollment) через GPO и подготовить новую сетевую политику на NPS.
Глобальный аудит NTLM: активировать GPO «Сетевая безопасность: ограничения NTLM: Аудит…» (события 8001–8004) для выявления всех оставшихся в домене NTLM-зависимостей перед Этапом 3.

#activedirectory #ntlm #nps #radius #wifi #security #windows #powershell #sysadmin #admin_future

🗓 Windows Server 2022: 13 октября заканчивается основная поддержка. Что это значит на практике

Коллеги, вторник. Ровно через неделю — октябрьский Patch Tuesday и официальная смена жизненного цикла у самой массовой серверной ОС в текущих корпоративных контурах.

📌 ФАКТЫ
13 октября 2026 года — официальное завершение фазы Mainstream Support для всех редакций Windows Server 2022.

14 октября 2031 года — окончание расширенной поддержки (Extended Support).

Что прекращается: закрывается выпуск несекьюрных хотфиксов (non-security bugfixes), перестают приниматься запросы на изменение функционала (DCR) и аннулируются бесплатные инциденты технической поддержки.

Что остаётся: регулярные ежемесячные кумулятивные обновления безопасности (LCU) будут выходить в штатном режиме ещё 5 лет.

⚠️ ГДЕ НА САМОМ ДЕЛЕ ЗАРЫТ РИСК
Повода для паники нет — серверы не превратятся в тыкву. Однако этот рубеж традиционно запускает процесс бюджетирования и планирования миграций на Windows Server 2025. И вот здесь заложена классическая граната:

В Windows Server 2025 подписание SMB-трафика (SMB Signing) включено и обязательно по умолчанию для всех исходящих и входящих клиентских подключений.

Если просто накатить новую ОС или смигрировать файловый сервер без ревизии, мгновенно отвалятся:

Старые сетевые МФУ (сканирование по SMB в сетевую папку);

Древние офисные NAS и прошивки встроенных систем;

Недоконфигурированные Linux-хосты со старыми демонами Samba, где подпись отключена ради производительности.

🛠 ДИАГНОСТИКА ИНФРАСТРУКТУРЫ ДО СТАРТА МИГРАЦИИ
Выполняем на контроллере домена или серверах через PowerShell:

PowerShell

# 1. Инвентаризация: считаем точное количество инстансов Server 2022 в домене
Get-ADComputer -Filter 'OperatingSystem -like "*Server 2022*"' |
  Measure-Object | Select-Object Count

# 2. Проверяем текущую политику требования подписи SMB на сервере и клиенте
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature

# 3. Аудит с хоста: смотрим, какие текущие сессии висят БЕЗ цифровой подписи (Signed = False)
Get-SmbConnection | Select-Object ServerName, ShareName, Dialect, Signed

💡 В ЧЁМ СУТЬ

Windows Server 2022 без проблем и спешки доживёт до 2031 года в статусе надёжной «рабочей лошадки».

Но если вы уже тестируете или закупаете лицензии под Server 2025, главная задача прямо сейчас — не перенос ролей, а инвентаризация сетевых шар и легаси-оборудования без SMB signing. Иначе в первый же день после миграции техподдержка утонет в тикетах «бухгалтерия не может отсканировать документы».

#windowsserver #lifecycle #smb #activedirectory #migration #powershell #sysadmin #admin_future

⏱️ Ubuntu 27.04 переходит на ntpd-rs. Повод проверить, кто вообще задаёт время в вашей сети

Коллеги, среда. Время — сервис, о котором вспоминают, только когда внезапно разваливается аутентификация в Kerberos.

📌 ФАКТЫ
Планы Canonical: в релизе Ubuntu 26.10 пакет ntpd-rs включён в архив для открытого тестирования, а начиная с Ubuntu 27.04 он станет системной службой времени по умолчанию.

Архитектурная причина: переход на memory-safe реализацию протокола NTP на языке Rust со встроенной поддержкой NTS (Network Time Security).

Критичность точного времени: от стабильности часов напрямую зависят валидация цепочек TLS-сертификатов, работа тикетов Kerberos, корреляция меток в журналах SIEM и сквозной аудит событий.

🛠 ПРОВЕРКА ЗА МИНУТУ
1. Хосты под управлением Linux
Bash

# Общий статус службы времени и синхронизации
timedatectl

# Текущее смещение, стратум и активный источник (chrony)
chronyc tracking

# Детальный список апстрим-серверов и их состояние
chronyc sources -v

2. Инфраструктура Windows / Active Directory
PowerShell

# Общий статус службы Windows Time и текущее смещение
w32tm /query /status

# Фактический источник синхронизации для хоста
w32tm /query /source

# Замер расхождения времени с контроллером домена в реальном времени
w32tm /stripchart /computer:dc01 /samples:5 /dataonly

⚠️ ТИПОВЫЕ ОШИБКИ В СЕТЯХ
Неверный источник на контроллере: источник у DC определяется как Local CMOS Clock или VM IC Time Synchronization Provider — в итоге время всего домена задаётся батарейкой BIOS материнской платы либо дрейфующими часами гипервизора.

Нарушение иерархии FSMO: внешний стратум NTP настроен не на держателе роли PDC Emulator, а на произвольном контроллере домена.

Конфликт синхронизации на виртуальных DC: на виртуальных машинах контроллеров домена оставлена включённой интеграция времени с хостом виртуализации (Integration Services / VMware Tools Time Sync).

💡 В ЧЁМ СУТЬ

Протокол Kerberos по умолчанию допускает расхождение часов не более 5 минут.

Иерархия времени в инфраструктуре должна быть строго монолитной:

Внешний доверенный NTP-пул → PDC Emulator → остальные DC домена → рядовые серверы и клиенты.

Любая самодеятельность в этой цепочке превращается в причину «плавающих» и трудноуловимых сбоев входа в домен.

#skills #ntp #time #activedirectory #kerberos #ubuntu #linux #sysadmin #admin_future

📊 Октябрьский Patch Tuesday: 1 411 уязвимостей — абсолютный рекорд. Что ставить первым

Коллеги, среда. Разбираем вчерашний массивный релиз Microsoft строго по инженерному алгоритму приоритизации.

📌 ФАКТЫ
Масштаб пакета: закрыто 1 411 уязвимостей (против рекордных ~970 в сентябре).

Критический сегмент: 70 бюллетеней со статусом Critical (57 RCE, 11 Elevation of Privilege, 2 Spoofing).

Внеочередные фиксы: ещё 348 уязвимостей закрыты редмондской командой ранее в течение месяца (преимущественно инфраструктура Azure и облачные сервисы).

🔴 ПРИОРИТЕТ 1 — СЕГОДНЯ (ЭКСПЛУАТАЦИЯ В WILD)
CVE-2026-96951 (Windows Shell, CVSS 8.8): обход механизма защиты Mark of the Web (MotW).

Активно эксплуатируется в атаках, внесена в каталог CISA KEV со строгим дедлайном устранения до 16 октября.

Позволяет вредоносному вложению или загруженному из сети исполняемому файлу запускаться без предупреждения SmartScreen — классический первичный вектор целевого фишинга.

Таргет наката: рабочие станции пользователей и терминальные фермы.

🟠 ПРИОРИТЕТ 2 — ЭТА НЕДЕЛЯ (СЕРВЕРНАЯ ИНФРАСТРУКТУРА)
CVE-2026-70229 (Active Directory Domain Services, CVSS 8.1): удалённое исполнение кода (RCE) на контроллерах домена. Рейтинг Microsoft Exploitability: «Exploitation More Likely».

CVE-2026-70571 (Exchange Server, CVSS 8.1): сетевое RCE в почтовом бэкенде, «Exploitation More Likely».

CVE-2026-70187 (Remote Desktop Services, CVSS 8.1): уязвимость RCE в стеке RDS.

Пул RCE в Microsoft Outlook (5 уязвимостей, CVSS 9.8): исполнение произвольного кода без взаимодействия с пользователем — триггерится прямо через область предварительного просмотра (Reading Pane).

Hyper-V (две RCE, CVSS 8.8): побег из виртуальной машины на хост гипервизора («Exploitation Less Likely»).

🟡 ОБРАТИТЬ ВНИМАНИЕ (АРХИТЕКТУРНЫЕ ОБХОДЫ)
CVE-2026-108398 (.NET Framework, CVSS 7.8): обход политик целостности кода Windows Defender Application Control (WDAC). Уязвимость раскрыта публично Джеймсом Форшоу (Google Project Zero), PoC доступен в исследовательских кругах.

💡 В ЧЁМ СУТЬ ДЛЯ СИСАДМИНА

За пугающей цифрой в 1 411 CVE скрывается стандартное правило Парето: реально горящих проблем — около десяти.

Оптимальный порядок развёртывания:

Рабочие станции и ноутбуки — закрыть MotW (

CVE-2026-96951

) и превью Outlook, перекрыв входящий фишинг.

Контроллеры домена (AD DS) — строго поочерёдно, контролируя репликацию (

repadmin /replsummary

) после каждого узла.

Exchange Server и RDS Gateway/Session Hosts — обязательно со снятием свежего бэкапа состояния системы/ВМ и предварительным тестом на пилотной ноде.

Изолированный бэкенд и внутренние сервисы — в рамках штатного сервисного окна выходных дней.

#patchtuesday #windows #activedirectory #exchange #cve #security #sysadmin #admin_future