Обработка учетных записей Azure с помощью поставщика WinNT ADSI для локального компьютера

У меня возникли проблемы с поиском хорошей документации, которая точно объясняет, как учетные записи AzureAD обрабатываются в локальных группах, и я получаю смешанные результаты, из-за чего мне трудно написать надежный API, который дает точные результаты для определения членства в группах для различных типов компьютер.

В этой статье дается хороший обзор возможных путей при использовании провайдера , но я считаю, что это не так уж и обширно. Когда компьютер присоединен к домену, все довольно просто. Однако, когда компьютер не присоединен к домену, я могу заметить, что объекты обычно имеют путь, соответствующий имени рабочей группы и имени компьютера. Например, встроенная группа обычно имеет ADsPath:

WinNT://<workgroup name>/<computer name>/Administrators

Итак, обычно это что-то вроде:

WinNT://WORKGROUP/MyComputer/Administrators

Если существует учетная запись, присоединенная к Azure Active Directory, даже если сам компьютер не присоединен к Azure Active Directory, эта учетная запись все равно может появляться в различных местах. Например, если Джон Доу настроил свой домашний компьютер с помощьюиразмещен в Azure Active Directory, то учетная запись Джона будет отображаться как .

Однако эта учетная запись на самом деле не известна локальному компьютеру. Просматривая раздел «Управление компьютером», вы не найдете этого пользователя в списке локальных пользователей. Предполагая, что именно он использовался для настройки, он будет найден как член группы локального компьютера.

Перечисление членовгруппы, мы можем определить, что путь ADS этой учетной записи — . Однако этот путь ADS на самом деле не работает. Попытка найти объект по этому пути вернет ошибку, обычно такую:

      Run-time error '-2147024843 (80070035)':

Automation error
The network path was not found. 

Однако мы можем определить SID этого пользователя и вместо этого использовать SID, аналогичный этому формату:

WinNT://S-1-12-1-123456789-1234567890-1234567890-1223456778

Это вернет действительный объект. Однако класс другой; теперь это , а не a, как мы получили, когда перечисляли членов встроенной группы.

Как следствие, если создать новую локальную группу и попытаться добавить пользователя в интерактивном режиме, это не удастся, поскольку в качестве местоположения установлено имя компьютера. Использование не удастся. Однако если добавить участника в новую локальную группу программным способом, можно использовать путь SID AD, чтобы затем успешно добавить ту же учетную запись AzureAD в эту группу.

Когда вы снова откроете членов группы через управление компьютером, теперь будет отображатьсяв пользовательском интерфейсе. Это также, а не. ADsPath также, что по-прежнему недействительно.

В результате невозможно использовать встроенныйметод группы ADS, чтобы определить, является ли учетная запись AzureAD членом этой локальной группы или нет. Я определил, что можно сравнить SID, который вроде бы работает и более надежен. Однако недостатком этого подхода является то, что этот подход очень медленный, и подсчет членства в группе, даже с коротким замыканием при обнаружении совпадения, происходит очень медленно.

Я надеюсь, что существует лучший способ определить членство в группе даже для учетной записи Azure на компьютере. API уже хорошо работал как для проверки локальных групп в рабочей группе, так и для групп домена на компьютере, присоединенном к домену. Однако учетные записи Azure — это новое звено в механизме.

Насколько я знаю, это как-то связано с провайдером ADS, и, следовательно, особенности получения данных на каких языках не имеют значения, поэтому будет один и тот же ответ, используете ли вы командную строку, WMI, powershell или или API-интерфейсы Win32.