Обзор технологии Workplace Join в Windows Server 2012 R2
В Windows Server 2012 R2 появился новый функционал, предоставляющий возможность регистрации личных мобильный устройств пользователей в домене Active Directory. Новая функция Workplace Join (или Подключение к рабочему месту) представляет собой компромиссное решение между подключением к ресурсам корпоративной сети с полностью «неуправляемого» устройства и полным контролем над компьютером через включение его в домен AD (т.е. клиентское устройство раньше могло быть либо в домене Windows, либо нет). Workplace Join представляет собой нечто среднее между этими двумя крайними вариантами.
После регистрации устройств (личных компьютерах, смартфонах и планшетах пользователей) в корпоративной сети через Workplace Join, администраторы получают возможность управлять доступом этих устройств к различным корпоративными ресурсам. Однако в отличии от «классических» машин домена, на мобильные устройства не будут действовать групповые политики, управляющие конфигурацию и параметрами безопасности компьютеров. Т.е. управлять настройками мобильного устройства администратор сети не может.
Основные возможности Workplace Join
Архитектора Workplace Join
Для работы технологии Workplace Join необходим контроллер домена с Windows Server 2012 R2 с установленной ролью служб сертификации, а схема AD должна быть расширена до версии Windows Server 2012 R2.
Следующим ключевым компонентом Workplace Join является служба регистрации устройств DRS (Device Registration Service). Данная функция является одним из компонентов роли Active Directory Federation (ADFS) в Windows Server 2012 R2.
Кроме того требуется веб сервер IIS с установленной ролью Windows Identity Foundation.
Служба DRS отвечает за регистрацию учетной записи устройства и аутентификацию его в Active Directory. После аутентификации администратор может управлять доступом мобильного пользователя к ресурсам корпоративной сети, использовать данную аутентификацию в качетве второго фактора аутентификации (для многофакторной аутентификации), а пользователь прозрачно (по SSO, не вводя свой пароль для каждого корпоративного сервиса) пользоваться ресурсами сети.
При установке клиента Workplace Join на мобильном устройстве пользователь должен указать корпоративный email и пароль для доступа в домен (естественно, что пользователь должен иметь учетную запись в домене Active Directory). При регистрации мобильного устройства через Workplace Join, служба DRS создает в Active Directory новый объект (типа msDS-Device), который привязывается через подтверждение к ученой записи пользователя — владельца устройства. На мобильный девайс пользователя устанавливается сертификат user@device, который связан с объектом данного устройства в AD. Таким образом, подтверждается «владение» пользователя конкретным устройством и оно признается доверенным. В дальнейшем данное доверенное устройство можно использовать для многофакторной проверки подлинности без смарт-карты или аппаратного токена.
Объект типа «device» создается в специальном контейнере Active Directory — RegisteredDevices.
После регистрации в сети пользователь может начать пользоваться ресурсами корпоративной сети.
Вся процедура для конечного пользователя выглядит крайне простой и прозрачной.
Клиент Workplace Join для мобильных устройств
Для поддержки Workplace Join на клиентах на конечное устройство необходимо установить клиент. Существует версия клиента Workplace Join для:
Клиент Workplace Join для устройств на базе Android на данный момент находится в разработке. Поддержки Windows Phone пока не запланирована.
Настройка Workplace Join в Windows 8.1
Для регистрации в сети через Workplace Join в Windows 8.1, в настройке подключений в разделе Network появилась отдельная вкладка Workplace. Для подключения к корпоративной сети достаточно указать имя пользователя (в формате itpro@winitpro.ru) и нажать кнопку Join.
После ввода пароля пользователя в домене появится информационное сообщение:
This device has joined your workplace network
Пошаговое руководство: присоединение к рабочему месту с устройства Windows
Доступ к веб-приложению до регистрации устройства
В этом пошаговом руководстве осуществляется доступ к веб-приложению компании до присоединения устройства к рабочему месту. На веб-странице отображаются утверждения, включенные в маркер безопасности. Обратите внимание, что в список утверждений не включены сведения об устройстве. Возможно, вы также заметили отсутствие единого входа.
Доступ к веб-приложению до использования функции присоединения к рабочему месту на устройстве
Выполните вход на Клиент1 со своей учетной записью Майкрософт.
На веб-странице перечислены все утверждения маркера безопасности. В маркере безопасности присутствуют только пользовательские утверждения.
Закройте Internet Explorer.
Обратите внимание, что система снова предложит ввести учетные данные. Вы не подключены к рабочему месту с устройства с использованием функции присоединения к рабочему месту, следовательно, единый вход не реализован.
Присоединение устройства с использованием функции присоединения к рабочему месту
Для успешного присоединения к рабочему месту клиентский компьютер (Клиент1) должно доверять сертификату SSL, использованному для настройки служб федерации Active Directory (AD FS) в разделе Step 2: Configure the Federation Server with Device Registration Service (ADFS1). Он также должен иметь возможность проверить информацию об отзыве сертификата. В случае проблем с присоединением к рабочему месту можно просмотреть журнал событий на компьютере Клиент1.
Чтобы просмотреть журнал событий, откройте компонент «Просмотр событий», последовательно разверните разделы Журналы приложений и служб, Корпорация Майкрософт, Windows и выберите Присоединение к рабочему месту.
Присоединение устройства с использованием функции присоединения к рабочему месту
Выполните вход на Клиент1 со своей учетной записью Майкрософт.
На экране Запуск откройте панель Чудо-кнопки и выберите чудо-кнопку Параметры. Выберите Изменение параметров компьютера.
На странице Параметры ПК выберите Сеть и нажмите кнопку Рабочее место.
Когда появится запрос на ввод учетных данных, введите roberth@contoso.com и пароль: roberth@contoso.com. Нажмите кнопку ОК.
Должно отобразиться сообщение: «Это устройство присоединено к сети вашей рабочей области».
Доступ к веб-приложению после присоединения к рабочему месту
В этой части демонстрации осуществляется доступ к веб-приложению компании с устройства, подключенного с помощью функции присоединения к рабочему месту. На веб-странице отображаются утверждения, включенные в маркер безопасности. Обратите внимание, что список утверждений содержит сведения об устройстве и пользователе. Вы также заметите, что единый вход теперь реализован.
Доступ к веб-приложению после присоединения к рабочему месту
Выполните вход на Клиент1 со своей учетной записью Майкрософт.
На веб-странице перечислены утверждения маркера безопасности. Токен содержит утверждения пользователя и заявки на доступ.
Закройте Internet Explorer.
Обратите внимание, что система не предлагает снова ввести учетные данные. Вы подключены к рабочему месту с устройства с использованием функции присоединения к рабочему месту, следовательно, единый вход реализован.
Automatic registration failed at join phase
Я пытаюсь настроить автоматическое объединение AAD для Windows 10, как описано здесь: Ссылка
У нас есть два внутренних сервера ADFS 3.0 (Server 2012R2). Они настроены с использованием Azure AD Connect для федерации с Office 365 на четырех UPN:
Серверы ADFS отображаются с использованием балансировщика нагрузки на уровне TCP на странице Ссылка с сертификатом, подписанным публичным центром сертификации. Серверы ADFS не запускают DRS, поскольку мы намереваемся сделать это с помощью Azure AD.
Объединенная аутентификация с Office 365 успешна для пользователей, созданных с любым из этих суффиксов UPN, но только после изменения третьего правила, как описано в Ссылка
Выполнены все предварительные шаги в статье Azure:
Все CNAME для enterpriseiseregistration.windows.net
Однако, несмотря на то, что вся другая проверка подлинности работает нормально, автоматический AADJ-процесс выходит из строя на всех существующих клиентских компьютерах под управлением Windows 10 Enterprise. Следующие ошибки присутствуют в журнале событий Microsoft / Windows / User Device Registration :
Идентификатор события 305
Идентификатор события 304
dsregcmd.exe
Подобные ошибки появляются, если я пытаюсь запустить C: windows system32 dsregcmd.exe / debug из командной строки SYSTEM:
2 ответа
Я понимаю ваше разочарование этим. Я просто потратил около 20 часов на устранение неполадок с автоматическим присоединением AAD. Я запускаю последнюю версию AD Connect и запускаю ферму ADFS на сервере 2016. Я НЕ разрешил AD Connect настраивать мои ADFS-серверы.
У меня была такая же ошибка. Проблема заключалась в отсутствии претензии ImmutableID. Эта ссылка оказалась лучшим ресурсом для настройки соединения azure AD: Ссылка
Здесь есть скрипт, который автоматически добавляет необходимые правила требований. Теперь, когда я практически понимаю весь этот процесс внутри и снаружи, могу сказать, что скрипт действительно работает и добавляет правильные правила требований.
Однако то, что вводит в заблуждение, заключается в том, как настроить пару переменных в скрипте. Итак, я думал, что я уточню, основываясь на моем обучении, надеюсь, что это сэкономит время.
Не меняйте никаких других компонентов скрипта и убедитесь, что вы запускаете его только один раз. Если вам нужно запустить его снова, вам нужно вручную удалить правила выдачи добавленных требований из доверия RP, или они будут дублированы.
Еще одна полезная вещь, которую нужно знать, когда дело доходит до устранения неполадок в Windows 10, использует DSREGCMD. Он должен работать как SYSTEM, поэтому вам понадобится что-то вроде PSEXEC.
Это приведет к немедленной регистрации Azure и сообщит подробную информацию о сбое. Во время тестирования Windows 7 работала нормально, но Windows 10 не присоединилась к AD. Если проблемой ImmutableID является ошибка, вы увидите, что ошибка: AADSTS90019: идентификационная информация, найденная в запросе или подразумеваемая всеми предоставленными учетными данными, отсутствует.
Если вы включили проверенный домен, если у вас его не было, или вы ошибаетесь, вы увидите: AADSTS50107: Запрошенный объект области федерации your specified domain не существует.
Windows Server 2016 – User Device Registration Error Event >
When logging into the server you can see these Errors Appearing
SOLUTION :
1. Go the the Tasks Scheduler and look for MicrosoftWindowsWorkplace Join
2. DISABLE the tasks Automatic-Device-Join
Log out and back in and check the Event Log again.
Share this:
Like this:
Related
This entry was posted on Monday, November 6th, 2017 at 12:05 pm and is filed under Server, Windows. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
Leave a Reply Cancel reply
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Even when you followed the Hybrid Azure AD join instructions to set up your environment (https://docs.microsoft.com/en-us/azure/active-directory/device-management-hybrid-azuread-joined-devices-setup ), you still might experience some issues with the computers not registering with Azure AD.
If you are looking for troubleshooting guide for the issue when Azure AD Conditional Access policy is treating your successfully joined station as Unregistered, see my other recent post – https://s4erka.wordpress.com/2019/04/05/azure-ad-conditional-access-policies-troubleshooting-device-state-unregistered/
To check if the device was joined to Azure AD run “dsregcmd /status” command in command prompt and look at AzureAdJoined value. For the Azure AD registered devices, it should be set to YES.
If the AzureAdJoined says NO, next step will be to collect information from the Application and Services – Microsoft – Windows – User Device Registration – Admin logs.
First thing, try to locate and read the text description in the error to see if it gives any clue.
Below are some examples of the errors and possible solutions to try.
User Device Registration Admin log – EventID 304 or 305 – adalResponseCode: 0xcaa1000e – recommended step is to check the AD FS claim rules per mentioned above article. It is important to have the AD FS claim rules in the described order and if you have multiple verified domains, do not forget remove any existing IssuerID rule that might have been created by Azure AD Connect or other means.
User Device Registration Admin log –wmain: Unable to retrieve access token 0x80004005 – recommended step is to check the AD FS claim rules.
User Device Registration Admin log – EventID 305 – AdalErrorCode: 0xcaa90006 – make sure the computer is able to reach and authenticate to specified in the error text description Identity Provider endpoint.
User Device Registration Admin log – EventID 204 – Error code: 0x801c03f2 (“The device object by the given id (xxx) is not found.”) – make sure the on-premises computer object is synchronized to Azure AD. Run the Delta Azure AD Connect sync.
User Device Registration Admin log – EventID 304 (309, 201 and 233 coming before it) – Error code: 0x801c0021 (Error code: 0x80072efe in EventID 201) (Or in the User Device Registration Debug logs EventID 500 with message “wmain TenantInfi::Discover failed with error code 0x801c0021”) – most likely the network or proxy didn’t allow the connection to Azure AD device registration endpoints or IdP to complete authentication. Also see next error description for the recommended troubleshooting steps.
User Device Registration Debug log – EventID 502 – Error code: 0x80072ee7 (“WinHttpRequest ::OnCallback: The callback handling failed with error code: 0x80072ee7”) – most likely the network or proxy d >
If there is a failure, you might want to configure correct proxy settings in the same IE opened as System Account.
User Device Registration Admin log – 0xCAA90022 Could not discover endpoint for Integrate Windows Authentication. Check your ADFS settings. It should support Integrate Widows Authentication for WS-Trust 1.3. (error message is self explanatory). In case your IdP is not AD FS consult your IdP documentation.
User Device Registration Admin log – 0xCAA9002b with this error from ADAL – ADALUseWindowsAuthenticationTenant failed, unable to perform integrated auth. Check your STS settings. It should support Integrate Widows Authentication for WS-Trust 1.3. (error message is self explanatory). In case your IdP is not AD FS consult your IdP documentation.
User Device Registration Admin log – 0x801c001d. Failed to lookup the registration service information from Active Directory. Recommended to check the Service Connection Point settings in on-premises Active Directory.
Sometimes the error description of the User Device Registration Admin log event is not providing enough information and you have to enable the User Device Registration Debug log to get more information.
To enable debug logs open Event Viewer – check “Show Analytic and Debug Logs” and browse to Application and Services – Microsoft – Windows – User Device Registration – right click on Debug log and select Enable log.
Example 1:
Log Name: Microsoft-Windows-User Device Registration/Admin
Source: Microsoft-Windows-User Device Registration
Date: 2/9/2018 10:17:49 AM
Event ID: 304
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: XXX
Description:
Automatic registration failed at join phase. Exit code: An unexpected internal error has occurred in the Platform Crypto Provider.
User Device Registration Debug log –
Log Name: Microsoft-Windows-User Device Registration/Debug
Source: Microsoft-Windows-User Device Registration
Date: 2/9/2018 10:23:30 AM
Event ID: 500
Task Category: None
Level: Information
Keywords:
User: SYSTEM
Computer: XXX
Description:
wmain: failed with error code 0x80290407.
Most likely this error is an indication that the TPM is not supporting Azure AD join requirements (https://docs.microsoft.com/en-us/windows/security/hardware-protection/tpm/tpm-recommendations ).
Next steps for this particular issue I would recommend for these stations are:
Example 2:
Log Name: Microsoft-Windows-User Device Registration/Admin
Source: Microsoft-Windows-User Device Registration
Date: 4/17/2018 12:44:10 PM
Event ID: 304
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: XXX
Description:
Automatic registration failed at join phase. Exit code: Keyset does not exist. Server error: empty.
After running dsregcmd /debug /join see following in the output:
Most likely this error indicates that the machine was imaged from the already Azure AD registered computer. Also it might indicate the TPM issues (see the TMP troubleshooting steps mentioned above).
If the fist is true, try renaming the “C:ProgramDataMicrosoftCryptoKeys” folder and re-running the dsregcmd /debug /join.
Example 3:
Log Name: Microsoft-Windows-User Device Registration/Admin
Source: Microsoft-Windows-User Device Registration
Date: 5/16/2018 8:44:03 AM
Event ID: 305
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: XXX
Description:
Automatic registration failed at authentication phase. Unable to acquire access token. Exit code: Unspecified error. Server error: AdalMessage: ADALUseWindowsAuthenticationTenant failed, unable to preform integrated auth
AdalErrorCode: 0xcaa9002c
This error usually indicates an issue with connecting to AD FS farm. Check if Windows Integrated Authentication is enabled for Intranet, is working correctly for Intranet and WSTrust windows endpoints are enabled in AD FS.
Automatic device join что это
Вопрос
We are facing one strange issue with hybrid AD Join operation. Windows 10 Devices are not performing Hybrid AD Join automatically however devices are synced to cloud but registration is pending.
I found that task scheduler «\Microsoft\Windows\Workplace Join\Automatic-Device-Join ” is disabled.
there is no GPO or registry setting deployed that can disable this task.
Все ответы
The Task will get disabled if Workplace Join discovery fails.
For troubleshooting the failure, look in event viewer> Applications and Service Logs > Microsoft > Windows > Workplace Join > Admin
here are some common issues and fixes:
Also refer to a step-by step guide on joining Azure AD:
If you find my reply helpful, please “Mark as Answer” and “Vote”
From the information you provided, it seems there’s some issue on joining the device to Azure AD. We can try Nelson’s suggestion to see if it can be fixed.
Also we can run “dsregcmd /status” on the device and confirm that the device is properly hybrid-joined if both AzureAdJoined and DomainJoined are set to YES. And the SSO State section displays AzureAdPrt as YES. We can see more details in the following link:
https://docs.microsoft.com/en-us/windows/client-management/mdm/enroll-a-windows-10-device-automatically-using-group-policy
Another log event viewer> Applications and Service Logs > Microsoft > Windows >AAD, we can also check it to see if there’s any finding.
However, if the issue still can’t be resolved. I suggest to submit s request to Azure AD forum. They are more professional on Azure AD join process.
Automatic device join что это
Вопрос
We are facing one strange issue with hybrid AD Join operation. Windows 10 Devices are not performing Hybrid AD Join automatically however devices are synced to cloud but registration is pending.
I found that task scheduler «\Microsoft\Windows\Workplace Join\Automatic-Device-Join ” is disabled.
there is no GPO or registry setting deployed that can disable this task.
Все ответы
The Task will get disabled if Workplace Join discovery fails.
For troubleshooting the failure, look in event viewer> Applications and Service Logs > Microsoft > Windows > Workplace Join > Admin
here are some common issues and fixes:
Also refer to a step-by step guide on joining Azure AD:
If you find my reply helpful, please “Mark as Answer” and “Vote”
From the information you provided, it seems there’s some issue on joining the device to Azure AD. We can try Nelson’s suggestion to see if it can be fixed.
Also we can run “dsregcmd /status” on the device and confirm that the device is properly hybrid-joined if both AzureAdJoined and DomainJoined are set to YES. And the SSO State section displays AzureAdPrt as YES. We can see more details in the following link:
https://docs.microsoft.com/en-us/windows/client-management/mdm/enroll-a-windows-10-device-automatically-using-group-policy
Another log event viewer> Applications and Service Logs > Microsoft > Windows >AAD, we can also check it to see if there’s any finding.
However, if the issue still can’t be resolved. I suggest to submit s request to Azure AD forum. They are more professional on Azure AD join process.
