none
Вопросы по Azure AD Connect (так для понимания) RRS feed

  • Вопрос

  • Доброго коллеги!

    Развернул тестовый полигон на виртуалке. Создал себе учетку для освоения Azure Portal. Разбираюсь. Настроил на Hyper-V контроллер домена Windows Servee 2008R2, поставил на него Azure AD Connect. Специально поставил не самую свежую версию, такую же, которая у нас пока на работе в Продакшене - 1.4.18.0. На тестовом полигоне вроде все синкается, все нормально. Ставлю эксперименты. Тестовый полигон стараюсь максимально по версиям ОС и софту приблизить к продакшену на работе, чтобы потом было проще там все менять, что понадобится.

    Теперь что хотел спросить.

    1) На работе у Azure AD Connect статус автообновления стоит "Приостановлено". (ХЗ почему, может когда нам помогали его переустановить года два назад, тот чел. режим такой включил?) Вот я и на полигоне у себя поставил такую же версию в Экспресс режиме, но она встала в режиме Автообновление. Хоть и почитал в доках, не могу понять когда он запустит автообнову? И как в ручную обновлять тогда, если не дожидаться пока автообнова сработает? Я скачал последний инсталлятор Azure Ad Connect - в свойствах версия вроде как 1.6.2.4. Его просто поверх надо будет накатить и версия обновится? У нас вроде все стандартно, правила и политики по умолчанию не меняли. Синкается в Azure все что в домене.

    2) Теперь исходя из первого вопроса, я попробовал накатить сверху скаченный инсталлятор. А он мне говорит, что ОС не поддерживается и нужна минимум 2012 или выше. Во как. 2008R2 похожу до свидания? Тогда как правильно сделать, если я в Продакшене у себя на работе подниму новый сервак для Azure AD Connect (сейчас тоже имеется там отдельный на 2008R2), на новом сервере, скажем 2019, мне просто с нуля установить Azure Ad Connect и так же задать синкать весь домен? Он не затрет ни чего в облаке? Ну у меня почему-то такое сомнения...., что при поднятии сервера синхронизации с нуля, будет выполнена первичная синхронизация, и ни чего не потрется в облаке или не задвоится? По идее он же смотрит атрибут ObjectGUID и если в облаке есть такая уже запись он просто с ней работать начинает как и раньше (на старом сервере)?

    3) Не понял еще вот что - почему так... Сменил на тестовом полигоне специально пароль глобального админа, который указывался в мастере первичной настройки Azure AD Connect. Но при этом синхронизация не "сломалась" она продолжается обычном режиме и все изменения нормально синкаются. Разве она не далжна вывалиться в ошибку из-за того что в облаке пароль глобального админа сменился? Ведь когда я первый раз настраивал, я задавал в мастере настройки пароль глобального админа, а пароль локальной учетки из AD которая будет с земли слать данные (для синка ведь используется две учетки - глобальный админ и учетка из AD с правами enterprise admin) пока не трогал. Уверен что если у учетки из локального AD сменить пароль которая указана в синхронизаторе, то синх сломается.

    Спасибо. Буду благодарен за комменты.



    • Изменено ItDen 20 марта 2021 г. 13:11
    20 марта 2021 г. 13:04

Все ответы

  • WS 2008 R2 снят с поддержки в январе 2020г.

    Глобальный администратор AAD в синхронизации не участвует, равно как и администратор наземного AD.

    Учетные записи требуются для подключения к AAD и AD в целях изменения параметров и тому подобного. 

    Для синхронизации AAD Connect создает специальные учетные записи в AAD и AD.

    Установка нового AAD Connect не должна вызвать дублирование учетных записей в AAD, перед включением синхронизации не забудьте выключить старый AAD Connect. С другой стороны, вы же пишете, что это испытательный полигон, вот и проведите эксперимент, чтобы знать из личного опыта, а не со слов других людей.


    20 марта 2021 г. 13:20
  • 1) Я скачал последний инсталлятор Azure Ad Connect - в свойствах версия вроде как 1.6.2.4. Его просто поверх надо будет накатить и версия обновится?

    да.

    2) Тогда как правильно сделать, если я в Продакшене у себя на работе подниму новый сервак для Azure AD Connect (сейчас тоже имеется там отдельный на 2008R2), на новом сервере, скажем 2019, мне просто с нуля установить Azure Ad Connect и так же задать синкать весь домен?
    статья по миграции Azure AD connect на другой сервер - ccылка. Это хорошо, что у вас есть тестовый полигон, есть на чём протестировать миграцию, только в AD создайте много учётных записей, чтобы было с чем сравнивать.
    3) Ведь когда я первый раз настраивал, я задавал в мастере настройки пароль глобального админа, а пароль локальной учетки из AD которая будет с земли слать данные (для синка ведь используется две учетки - глобальный админ и учетка из AD с правами enterprise admin) пока не трогал
    эти учётные записи нужны для начальной настройки, потом всё будет работать с системной учётной запись MSO_бла_бла_что_то_там
    20 марта 2021 г. 14:33
  • эти учётные записи нужны для начальной настройки, потом всё будет работать с системной учётной запись MSO_бла_бла_что_то_там

    т.е. смена паролей у учетных записей которые задавались при начальной настройке (глоб.админ и учетка в локальной AD с правами enterprise admin) не нарушит синх? Спасибо за информацию. Но странно, когда ведь пытаешься изменить параметры, к примеру синхронизации, в Azure AD Connect, он запрашивает ввод этих учетных данных. Или получается что это ему надо только для подключения к источникам данных?

    Спасибо.


    • Изменено ItDen 21 марта 2021 г. 8:00
    21 марта 2021 г. 7:51
  • WS 2008 R2 снят с поддержки в январе 2020г.

    Глобальный администратор AAD в синхронизации не участвует, равно как и администратор наземного AD.

    Учетные записи требуются для подключения к AAD и AD в целях изменения параметров и тому подобного. 

    Для синхронизации AAD Connect создает специальные учетные записи в AAD и AD.

    Установка нового AAD Connect не должна вызвать дублирование учетных записей в AAD, перед включением синхронизации не забудьте выключить старый AAD Connect. С другой стороны, вы же пишете, что это испытательный полигон, вот и проведите эксперимент, чтобы знать из личного опыта, а не со слов других людей.


    Спасибо за информацию. Как раз это переспросил в посте выше. Что учетки глоб. админа и учетка с правами enterprise admin нужны походу для подключения и на синхронизацию не влияют получается если сменится у них пароль? А я все время считал что влияет)).

    Да про 2008R2 я в курсе. Но у нас пока еще не куплены лицензии на новые версии софта, вот ждем. Тогда и сделаю переход на новую ОС.

    А еще можно спросить почему так:?

    Заметил разницу вот в чем. Установленный два года назад на работе в Продакшене Azure AD Connect использует привязку к источнику данных ObjectGUID, а установленный почти при таких же условиях той же версии Azure AD Connect на тестовом полигоне использует mS-DS-ConsistencyGUID. Почитал про это, но не очень понял почему та же версия и стала использовать другой атрибут.

    Спасибо

    21 марта 2021 г. 7:58
  • эти учётные записи нужны для начальной настройки, потом всё будет работать с системной учётной запись MSO_бла_бла_что_то_там

    т.е. смена паролей у учетных записей которые задавались при начальной настройке (глоб.админ и учетка в локальной AD с правами enterprise admin) не нарушит синх? Спасибо за информацию. Но странно, когда ведь пытаешься изменить параметры, к примеру синхронизации, в Azure AD Connect, он запрашивает ввод этих учетных данных. Или получается что это ему надо только для подключения к источникам данных?

    Спасибо.


    Не должна. Но у нас один "очень умный админ" настроил работу синхронизации вообще через у.з. Domain\Administrator. А когда другой администратор сказал что у.з. надо заблокировать в целях безопасности - естественно у нас всё упало 🤣🤣🤣

    Учётные данные вводятся любого доменного админа только для подключения. 

    21 марта 2021 г. 8:40

  • А еще можно спросить почему так:?

    Заметил разницу вот в чем. Установленный два года назад на работе в Продакшене Azure AD Connect использует привязку к источнику данных ObjectGUID, а установленный почти при таких же условиях той же версии Azure AD Connect на тестовом полигоне использует mS-DS-ConsistencyGUID. Почитал про это, но не очень понял почему та же версия и стала использовать другой атрибут.

    Спасибо

    Видимо поменялись настройки по умолчанию или вы их поменяли во время установки на этом шаге:

    21 марта 2021 г. 8:44

  • А еще можно спросить почему так:?

    Заметил разницу вот в чем. Установленный два года назад на работе в Продакшене Azure AD Connect использует привязку к источнику данных ObjectGUID, а установленный почти при таких же условиях той же версии Azure AD Connect на тестовом полигоне использует mS-DS-ConsistencyGUID. Почитал про это, но не очень понял почему та же версия и стала использовать другой атрибут.

    Спасибо

    Видимо поменялись настройки по умолчанию или вы их поменяли во время установки на этом шаге:

    Да, нет. Настройку на тестовом полигоне делал Экспресс вариант, там вообще минимум чего надо выбирать и этот атрибут я точно не трогал!

    Это я к тому, что если на продакшене сейчас привязка к ObjectGUID, а я когда начну переносить на новый сервер Azure AD Connect и он выберет при параметрах по умолчанию новый атрибут mS-DS-ConsistencyGUID, то как отреагируют интересно имеющиеся данные в облаке? Они просто перепривяжутся ), если можно так сказать или ждать каких-то неожиданностей(.

    21 марта 2021 г. 8:54