🪟 Windows: Entra Passkeys на Windows — пароли официально умирают с этой недели

Коллеги, новость которую стоит знать прямо сейчас, потому что она касается твоих пользователей и твоих политик — молча, без запроса разрешения.

Microsoft Entra passkeys на Windows достигли General Availability с конца апреля 2026. Функция позволяет создавать device-bound passkeys в контейнере Windows Hello и аутентифицироваться через лицо, отпечаток или PIN. Важно: расширяет passwordless-аутентификацию на устройства, которые не присоединены к Entra ID — включая личные и общие Windows-устройства.

Ключевое изменение по сравнению с preview: больше не требуется явно разрешать Windows Hello AAGUID через allow-list в passkey-профиле. Если ваш профиль допускает device-bound, non-attested passkeys — пользователи начнут регистрировать passkeys на Windows автоматически, без дополнительной настройки администратором.

# Проверяем текущее состояние FIDO2/passkey политики в Entra
# Нужна роль Authentication Policy Administrator

# Через Graph API (требует модуль Microsoft.Graph):
Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"

Get-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
  -AuthenticationMethodConfigurationId "fido2" |
  Select-Object -ExpandProperty AdditionalProperties

# Что проверить в Entra Admin Center:
# Identity → Security → Authentication methods → Policies → Passkey (FIDO2)
# Смотрим: включён ли, какие группы в scope, есть ли Key Restrictions

# Если хотим ЗАБЛОКИРОВАТЬ Windows Hello passkeys (только для конкретных сред):
# Добавляем Windows Hello AAGUID в block list профиля
# Windows Hello AAGUIDs:
# 9ddd1817-af5a-4672-a2b9-3e3dd95000a9 (Windows Hello hardware)
# 6028b017-b1d4-4c02-b4b3-afcdafc96bb2 (Windows Hello software)

# Проверяем зарегистрированные passkeys пользователя:
Get-MgUserAuthenticationFido2Method -UserId "user@domain.com" |
  Select-Object DisplayName, CreatedDateTime, AaGuid

Зачем это нужно:
Passkeys криптографически привязаны к устройству и никогда не передаются по сети — атакующий не может их украсть при фишинге или через вредоносное ПО для обхода MFA. Функция закрывает брешь в безопасности, которая оставляла личные и общие устройства с паролями после недавней волны атак на Entra SSO.

Итог: действие сегодня — зайди в Entra и убедись что знаешь, что будет происходить с passkeys в твоём тенанте. «Включилось само» — не оправдание на следующем аудите.

#windows #entra #passkeys #fido2 #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