Обновите изображения пользователей в Azure Active Directory с помощью Graph API (служба Windows c # .Net) - PullRequest
0 голосов
/ 22 марта 2019

Администратор моей сети настроил локальный (на прем) каталог Active Directory MS на сервере MS Windows 2008, и теперь они перешли в Azure Active Directory в гибридном режиме, например, с синхронизацией обеих каталогов.

Ранее я написал службу Windows для запуска на машине, на которой установлен MS AD, и что эта служба на самом деле делает, как показано ниже

1: настройте конфигурацию перед запуском службы, напримерКонтроллер домена, BaseDN и учетные данные администратора.

2: Служба запускается через заданный интервал и получает пользователей с локального веб-сервера интрасети, которые необходимо обновить в AD.(Идентификатор пользователя, имя, изображение и т.*

4: после успешного поиска я могу получить экземпляр DirectoryEntry пользователя и обновить его уменьшенное изображение Photo.

Ниже приведен краткий код

foreach (var userInDB in usersList)
            {
                string webServerAddress = ConfigurationManager.AppSettings["WebserverAddress"];
                string ImagePath = webServerAddress + userInDB.ImagePath;
                try
                {
                    using (DirectorySearcher dsSearcher = new DirectorySearcher(myLdapConnection))
                    {
                        dsSearcher.Filter = "(&(objectClass=user) (cn="+ userInDB.UserName+"))";
                        SearchResult result = dsSearcher.FindOne();

                        if (result != null)
                        {
                            using (DirectoryEntry user = new DirectoryEntry(result.Path))
                            {
                                using (var webClient = new WebClient())
                                {

                                    byte[] userImage = webClient.DownloadData(ImagePath);
                                    byte[] userImageThumbnail =CreateThumbnail(userImage,96);
                                    Log4Net.WriteLog("Image File Converted to bytes", LogType.GENERALLOG);

                                    user.Properties["thumbnailPhoto"].Clear();
                                    user.Properties["thumbnailPhoto"].Add(userImageThumbnail);
                                    user.CommitChanges(); 
                                }
                            }
                            new UserServices().UpdateUser(userInDB.UserId);
                        }
                        else
                        {

                        }
                    }
                }
                catch (Exception ex)
                {
                    Log4Net.WriteException(ex);
                }
            }

Пока все хорошо,Служба отлично работает и синхронизирует изображения моих пользователей с локального веб-сервера интрасети в Local AD.

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

1: я могу использовать Graph API и обновить пользователей следующим HTTP-запросом

PATCH /users/{id | userPrincipalName}/photo/$value  

1: Являются ли userPrincipalName и CN общими идентификационными данными, например (у меня очень мало знаний об администрировании сети, и я не настроил эти локальные AD и Azure AD, поэтому понятия не имеювот почему Local AD синхронизируется с Azure AD).Мне нужно быть уверенным, что я получу доступ к пользователю в Azure AD, указав то же имя пользователя (для userPrincipalName), которое я использовал для доступа к нему в Local AD (для CN).

2: Моя вторая проблема заключается в том, что, поскольку я просмотрел документацию по настройке API-интерфейса MS Graph, например,

(i) Зарегистрируйте свое приложение.

(ii) Настройте разрешения для Microsoft Graph на своемприложение.

(iii) Получить согласие администратора.

(iv) Получить токен доступа.

(v) Использовать токен доступа для вызова Microsoft Graph.

Я не совсем понимаю 3-й пункт, хотя, например, почему этот сценарий подходит для службы Windows, работающей самостоятельно после определенного интервала?Это единовременная работа, чтобы получить согласие администратора и использовать сервис позже без него.Существует ли сценарий, по которому мы можем получить разрешение администратора для зарегистрированного приложения за один раз (предпочтительно в отдельном приложении) и использовать службу Windows для последующего доступа к Azure AD без проблем.

3: Мое третье и последнее беспокойство по поводу всего этого сценария заключается в том, что " Мне действительно нужно делать все это? "

Я просмотрел несколько статей, таких как

https://support.office.com/en-ie/article/active-directory-connect-and-office-365-856f2f62-a6e8-4ab0-817b-adabd8f27332#ID0EAABAAA=Course_Overview

о Active Directory Connect и Office 365. Разве недостаточно обновить Local On Prem AD с помощью службы Windows и настроить Azure AD на автоматическое обновление (синхронизацию), например, чтобы разрешитьСетевой администратор должен настроить оба каталога на автоматическую синхронизацию.

Нужно ли обновлять Local AD и Azure AD по отдельности?(в одной службе Windows или 2 службы Windows?)

Итог: Я новичок в Azure AD или даже в AD, приведенное выше описание является результатом моих быстрых НИОКР, я еще не разработал полную среду для реализации решения, например Получение бесплатногоучетная запись разработчика для Office 365, настройте локальную AD на моем сервере Windows, зарегистрируйте мое приложение на портале регистрации приложений Microsoft и выполните остальную часть работы.Потому что перед тем, как перейти к настройке среды, мне нужно заранее проконсультироваться с экспертами по Azure AD, чтобы я шел в правильном направлении и какое решение подходит для описанного выше сценария. Чтобы повторить это снова"Я хочу обновить изображения пользователя с моего локального веб-сервера интрасети до Azure AD"

, пожалуйста, предложите мне лучшие строки для подражания.

Спасибо и всего наилучшего,

1 Ответ

0 голосов
/ 22 марта 2019

У вас есть несколько вопросов в вашем вопросе, но я постараюсь ответить на каждую часть:

1: общие имена userPrincipalName и CN

Да, ваша AD должна иметь userPrincipalName для каждого пользователя.Вы должны быть в состоянии найти пользователя и затем получить его Upn из AD.

2: это разовая работа для получения согласия администратора и последующего использования сервиса без него.Существует ли сценарий, по которому мы можем получить разрешение администратора для зарегистрированного приложения за один раз (предпочтительно в отдельном приложении) и использовать службу Windows для последующего доступа к Azure AD без проблем.

Да, администратор соглашается с приложением один раз (если вам не нужно менять области разрешения).Для этого типа решения (без пользовательского интерфейса) вы должны рассмотреть возможность использования потока учетных данных клиента вместо делегированной аутентификации.С учетными данными клиента вы получаете Идентификатор приложения и Секрет и используете их для получения токена доступа каждый раз, когда он вам нужен.Вам не нужно, чтобы пользователь входил как часть процесса аутентификации, и вам не нужно обрабатывать токены обновления. поток аутентификации учетных данных клиента

3: Моя третья и последняя проблема по поводу всего этого сценария заключается в том, что «Мне действительно нужно делать все это?»

Ты, наверное, грустишь.AD Connect синхронизирует миниатюру фотографии с AAD, однако, если пользователь обновляет свою фотографию в O365, миниатюра больше не будет автоматически синхронизироваться из AAD в Office 365 (EXO / SPO).Это нарушает синхронизацию, и вам, вероятно, потребуется отправить фотографии в Microsoft Graph, который поместит фотографию в EXO, если у пользователя есть почтовый ящик, из которого большая часть O365 извлекает его фотографию.Короткий ответ, да, вы, вероятно, должны.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...