Создайте нового пользователя Azure AD с тем же идентификатором, что и у локального пользователя.

Чтобы ответить на предыдущий вопрос мой, я хотел бы знать, возможно ли это или нет.

TLDR; При использовании Microsoft Graph для создания нового пользователя возможно ли, чтобы этот новый пользователь совпадал с существующим локальным пользователем AD?

Ситуация:

У нас есть локальная AD, которая синхронизируется с нашей Azure AD. Процесс синхронизации по умолчанию запускается каждые 30 минут.

У нас есть приложение ASP.NET MVC, которое создает нового пользователя внутри нашего локального AD. После успешного создания я хотел бы принудительно выполнить синхронизацию с Azure AD, потому что у меня есть другие действия, которые нужно применить к этому конкретному пользователю, например назначить ему лицензию.

Я знаю о командлете Start-ADSyncSyncCycle -PolicyType Delta, но мне придется запускать этот командлет из C#, и это может занять X amount времени в зависимости от количества пользователей, которых необходимо синхронизировать.

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

Вопрос:

Из-за потенциальных проблем с запуском командлета Start-ADSyncSyncCycle -PolicyType Delta и X amount времени, которое может потребоваться для запуска, мне было интересно, могу ли я вместо этого использовать Microsoft Graph и создать нового пользователя.

Проблема, которую я думаю столкнусь, заключается в том, что код уже создает локального пользователя AD, а затем, если я использую Microsoft Graph для создания пользователя, я опасаюсь, что это в конечном итоге приведет к созданию другой пользователь.

Единственная причина, по которой я думаю об использовании Graph для создания пользователя, заключается в том, что мне не нужно запускать команду PowerShell, что позволяет избежать X amount времени, необходимого для запуска.

Я предполагаю, что вопрос в том, возможно ли:

  • Создайте локального пользователя AD.
  • Получите какой-нибудь идентификатор от этого вновь созданного пользователя и передайте этот идентификатор пользователю Microsoft Graph create таким образом, у меня не будет двух разных пользователей.

В какой-то момент времени, когда происходит фактический процесс синхронизации, он ничего не сделает с этим конкретным пользователем, поскольку он уже существует в Azure AD.

Я надеюсь, что я понимаю, потому что это сложно объяснить словами

Я приветствую любые различные подходы или идеи.

Искренне


azure-active-directory microsoft-graph-api
person Vlince    schedule 21.03.2017    source источник
comment
Вместо использования Синхронизация паролей для единого входа рассмотрите возможность использования Федерации с AD FS, пользователи которой могут входить в облачные службы Microsoft, такие как Office 365, с помощью тот же пароль, который они используют в своей локальной сети, и пользователи перенаправляются в свой локальный экземпляр AD FS для входа, а проверка подлинности выполняется локально?   -  person Fei Xue - MSFT    schedule 22.03.2017

Ответы (1)


arrow_upward
1
arrow_downward

Это должно быть возможно (хотя я не пробовал). Здесь важно убедиться, что связь, вы устанавливаете свойство onPremisesImmutableId как часть создания. См. https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/resources/user. Я не думаю, что у нас есть примеры создания пользователя с этим набором свойств, но это должно быть просто, а для федеративных пользователей это действительно необходимо. По умолчанию onPremisesImmutableId — это ADObjectId для локального пользователя AD, если вы не настроили ADConnect для использования чего-то другого.

ПРИМЕЧАНИЕ. Вы должны иметь возможность делать то же самое с помощью Azure AD PowerShell — https://docs.microsoft.com/en-us/powershell/azuread/v2/new-azureaduser (хотя здесь это свойство называется immutableId).

Надеюсь это поможет,

person Dan Kershaw - MSFT    schedule 23.03.2017
comment
Итак, если я правильно понимаю, после программного создания локального пользователя AD я должен получить только что созданный ADObjectId. Затем используйте Graph для POST и создайте нового пользователя. В этом POST установите для свойства onPremisesImmutableId значение ADObjectId и вуаля! Для справки, позже в тот же день, когда AD Connect запустится и выполнит свою синхронизацию, ему не нужно будет синхронизировать этот конкретный ADObjectId (или просто игнорировать его), поскольку этот пользователь будет существовать как в локальной AD, так и в Azure AD, верно? - person Vlince; 23.03.2017
comment
Верный. Я думаю, что когда вы устанавливаете свойство onPremisesImmutableId, вам может потребоваться закодировать его на основе 64. Я проверю и вернусь к вам - или вы можете попробовать эксперимент;) - person Dan Kershaw - MSFT; 26.03.2017