Всё в ажуре 👌
У меня есть клиент, который широко задействует облачные сервисы Microsoft - Azure AD, Office 365, SharePoint, Teams. Это удобно для крупной финансовой организации с большим и гибким штатом подрядчиков. Поскольку решения Microsoft интегрированы между собой, адаптация (onboarding) новых сотрудников упрощается и ускоряется. Мне есть с чем сравнить, причем в том же бизнесе 💲
В качестве одного из способов присоединения подрядчика к компании предлагается ВМ Hyper-V. Пользователи сами устанавливают Windows 10 Pro из MCT. На этапе OOBE они входят в аккаунт организации, и система получается Azure AD Joined. Дальше Intune, политики, шифрование, VPN. При этом компания не несет расходов на железо, т.к. ВМ крутится на ПК подрядчика 💻
И вот на такой ВМ у меня отвалился доступ к Jira и Confluence с аккаунтом организации. Я мог обойти с VPN, но должно же работать и без! Написал в чат поддержки 🎧
Агент сходу сказал - выполните команды и перезагрузитесь.
Ладно. Я забэкапил VHDX, перезагрузился и... не смог войти в систему :) 👀
Действительно, учетная запись одна, и локального пароля у нее нет в принципе. Есть лишь аккаунт в AAD, откуда я только что сам выпилился 😎 ПИН-кода на экране входа тоже не было. Я возлагал на него надежды, но не попробуешь - не узнаешь :) Шифрование BitLocker исключает создание нового аккаунта извне, если что.
Стало даже любопытно, как поддержка будет решать проблему. Но терпения надолго не хватило, и я закрыл тикет :) Интереснее было понять причину такого странного совета. Опытный коллега предположил, что у меня ВМ была Hybrid Azure AD Joined.
Однако к локальному домену я не присоединялся, что подтвердила команда
В этой компании системы на VDI просто присоединены к домену. Да, добавление аккаунта организации в Параметрах регистрирует устройство в AAD, Azure AD registered devices. Но это видно в списке рабочих аккаунтов, а в состоянии устройства так:
👉 Два главных вывода из этой истории.
1. "Доверяй, но проверяй" - полезный принцип. Без раздумий вставлять в консоль найденный в Интернетах или выданный техподдержкой код - плохая идея. В любой непонятной ситуации включайте критическое мышление.
2. Резервные копии всегда экономит время и нервы, бывает и деньги.
А какая инфраструктура в вашей организации?
☁️ - Azure AD Joined
🌤 - Hybrid Azure AD Joined
⛰ - просто домен
🤷♂️ - рабочая группа / не знаю / другое
У меня есть клиент, который широко задействует облачные сервисы Microsoft - Azure AD, Office 365, SharePoint, Teams. Это удобно для крупной финансовой организации с большим и гибким штатом подрядчиков. Поскольку решения Microsoft интегрированы между собой, адаптация (onboarding) новых сотрудников упрощается и ускоряется. Мне есть с чем сравнить, причем в том же бизнесе 💲
В качестве одного из способов присоединения подрядчика к компании предлагается ВМ Hyper-V. Пользователи сами устанавливают Windows 10 Pro из MCT. На этапе OOBE они входят в аккаунт организации, и система получается Azure AD Joined. Дальше Intune, политики, шифрование, VPN. При этом компания не несет расходов на железо, т.к. ВМ крутится на ПК подрядчика 💻
И вот на такой ВМ у меня отвалился доступ к Jira и Confluence с аккаунтом организации. Я мог обойти с VPN, но должно же работать и без! Написал в чат поддержки 🎧
Агент сходу сказал - выполните команды и перезагрузитесь.
dsregcmd /leave
gpupdate /force
Я почитал справку к dsregcmd и обеспокоился последствиями такого решения 🤔 Однако агент заявил, что действует по инструкции - проблема популярная, все будет в ажуре! Ладно. Я забэкапил VHDX, перезагрузился и... не смог войти в систему :) 👀
Действительно, учетная запись одна, и локального пароля у нее нет в принципе. Есть лишь аккаунт в AAD, откуда я только что сам выпилился 😎 ПИН-кода на экране входа тоже не было. Я возлагал на него надежды, но не попробуешь - не узнаешь :) Шифрование BitLocker исключает создание нового аккаунта извне, если что.
Стало даже любопытно, как поддержка будет решать проблему. Но терпения надолго не хватило, и я закрыл тикет :) Интереснее было понять причину такого странного совета. Опытный коллега предположил, что у меня ВМ была Hybrid Azure AD Joined.
Однако к локальному домену я не присоединялся, что подтвердила команда
dsregcmd /status на резервном VHDX:AzureAdJoined : YES
EnterpriseJoined : NO
DomainJoined : NO
🧩 Разгадку я случайно узнал через пару месяцев. Коллега не ошибся, агент действительно ожидал у меня гибридный #AAD. Инструкция предназначалась для пользователей VDI, которых в этой организации на порядок больше чем с локальными ВМ. Нас перестали поддерживать через чат, о чем даже не предупредили 🤷♂️В этой компании системы на VDI просто присоединены к домену. Да, добавление аккаунта организации в Параметрах регистрирует устройство в AAD, Azure AD registered devices. Но это видно в списке рабочих аккаунтов, а в состоянии устройства так:
AzureAdJoined : NO
EnterpriseJoined : NO
DomainJoined : YES
DomainName : CONTOSO
Видимо, агент поддержки счел, что я присоединился к Azure AD, что породило конфликт, препятствующий доступу к искомым ресурсам. Он решил удалить устройство из AAD, восстанавливая статус-кво. А предварительно оценить ситуацию - это не уровень первой линии поддержки ;)👉 Два главных вывода из этой истории.
1. "Доверяй, но проверяй" - полезный принцип. Без раздумий вставлять в консоль найденный в Интернетах или выданный техподдержкой код - плохая идея. В любой непонятной ситуации включайте критическое мышление.
2. Резервные копии всегда экономит время и нервы, бывает и деньги.
А какая инфраструктура в вашей организации?
☁️ - Azure AD Joined
🌤 - Hybrid Azure AD Joined
⛰ - просто домен
🤷♂️ - рабочая группа / не знаю / другое
😎 Нюансы беспарольного входа в организации
Пятничная тру стори в продолжение вчерашнего поста про беспарольную MSA. У меня есть клиент с Microsoft 365. Соответственно, там Azure AD, учетная запись организации, #2FA, Microsoft Authenticator - стандартный набор.
В приложении Authenticator есть опция включения беспарольного входа. Один сотрудник решил ее активировать и... у его учетной записи #AAD заблокировался доступ ко всем ресурсам организации 🤦♂️ Соответственно, работать он уже не мог.
Дальше чат поддержки, индусы, стандартные скрипты несколько дней - все как мы любим :) В итоге объяснение выдали такое, что у этой фичи контроль по географическому местоположению. Компания иностранная, а сотрудник был из России.
Видимо, при заявке на регистрацию устройства для беспарольного входа передается IP-адрес, а на "русских хакеров" стоят флаги, поэтому учетная запись блокируется автоматически. В итоге доступ вернули, но сказали пользоваться парольным входом ✌️
Пятничная тру стори в продолжение вчерашнего поста про беспарольную MSA. У меня есть клиент с Microsoft 365. Соответственно, там Azure AD, учетная запись организации, #2FA, Microsoft Authenticator - стандартный набор.
В приложении Authenticator есть опция включения беспарольного входа. Один сотрудник решил ее активировать и... у его учетной записи #AAD заблокировался доступ ко всем ресурсам организации 🤦♂️ Соответственно, работать он уже не мог.
Дальше чат поддержки, индусы, стандартные скрипты несколько дней - все как мы любим :) В итоге объяснение выдали такое, что у этой фичи контроль по географическому местоположению. Компания иностранная, а сотрудник был из России.
Видимо, при заявке на регистрацию устройства для беспарольного входа передается IP-адрес, а на "русских хакеров" стоят флаги, поэтому учетная запись блокируется автоматически. В итоге доступ вернули, но сказали пользоваться парольным входом ✌️
