Меню

Синхронизация active directory с office 365



Ошибка синхронизации Active Directory с Portal Office 365

Ошибка синхронизации Active Directory с Portal Office 365

Добрый день! Уважаемый читатель, IT блога Pyatilistnik.org. Лет 10 назад, слово облако, вызывало у людей исключительно одну ассоциацию, белого пушистого комочка на голубом небе. Прошло немного лет, и в нашу жизнь ворвались технологии виртуализации, а с ними и облачные сервисы, давшие еще одно представление об этом слове. Есть такая замечательная организация Microsoft, подсадившая большую часть мира на ее офисные продукты и Active Directory. Благодаря нынешним технологиям, компаниям уже не обязательно разворачивать у себя инфраструктуру, в виде AD, все теперь можно делать в облаках, в данном случае оно называется Azure. Я как-нибудь более подробно расскажу про него, но не сегодня. Сейчас я хочу описать ситуацию, когда у меня на портале Azure по управлению лицензиями Office 365, нет нужного мне пользователя, который почему-то вообще числится, что он удален. Мы разберемся с процессом синхронизации локальной базы данных Active Directory с AD Azure и поправим получение офисных лицензий для сотрудника.

Описание проблемы

Как я и описал выше, моя компания купила некое количество лицензий на офисные продукты Microsoft Office 365. Распределение и управление лицензиями осуществляется, через специальный портал. Пользователи из локальной баз Active Directory синхронизируются с базой данных AD Azure. После чего сотрудникам назначаются лицензии. Сегодня ко мне поступила заявка, о том, что у пользователя выскакивает окно в котором сообщает ему, что есть проблемы с активацией офисного пакета. У пользователя установлена Windows 10. В какой-то момент у него стали появляться вот такие предупреждения.

Пользователь пробует перевойти .но в итоге получает все те же предупреждения.

Переходим на административный портал управления Active Directory Azure и Office 365, напоминаю, это адрес https://portal.office.com. Перейдите в раздел Microsoft 365 Admin Center. Найдите в нем вкладку пользователи и попробуйте найти вашего сотрудника, среди активных учетных записей. Лично в моем случае я не смог найти. Проверил синхронизации, все вроде хорошо.

Дай думаю загляну ради интереса в раздел «Удаленные пользователи». И какого же было мое удивление, когда я обнаружил тут нужного мне сотрудника. Он был в Microsoft 365 Admin Center отключен, хотя в моем локальном Active Directory с учетной записью проблем не было.

Если выбрать удаленную учетную запись, то у вас будет одно, доступное действие, это восстановить. У вас откроется окно восстановления, в котором вас предупредят:

Английский вариант: Before you restore Овчинникова you need to make sure you have a product license available. Restoring Овчинникова will restore all associated data, assign product licenses, and give access to all services they could access before they were deleted.

Пробую выбрать автоматическое создание пароля, просто было интересно. так как я знал, что синхронизация односторонняя и только в сторону Active Directory Azure.

В восстановлении отказано с формулировкой, что мой пользователь был удален в Microsoft 365 Admin Center более месяца назад.

Из сложившейся ситуации я сделал вывод, что есть явная проблема с синхронизацией локально Active Directory и Azure, и то что я вижу, что якобы все синхронизируется не есть правда. Я решил сделать принудительную синхронизацию. Перед этим я посмотрел в какой OU находится учетная запись нужного мне сотрудника. Далее вы переходите на сервер, где установлена утилита Synchronization Service Azure AD Connect. И запускаем Synchronization Service.

В Synchronization Service Manager, переходите на вкладку с коннекторами (Connectors), выбираете вашу организацию и переходите в ее свойства (Properties)

Так как у меня стоит выборочная синхронизация из локального AD в AD Azure, то я полез в «Configure Directory Partitions», где нужно нажать кнопку «Containers», у вас будут запрошены учетные данные.

Проверяем все ли OU в которых у вас нужные пользователи выбраны для синхронизации с Azure Active Directory и сохраняем настройки.

Далее щелкаете на вкладке «Connectors» по вашей компании и выбираете «Run».

Выбираете полное импортирование «Full Import»

Вы уже должны заметить эффект вышеуказанных настроек в главном окне программы на вкладке «Operations». Будет запущено задание Full import в моем примере его статус in-progress, то есть в процессе выполнения. Синхронизация побежала.

Дожидаемся процесса синхронизации с облаком Microsoft. В самом низу у вас будет поле «Sinchronizatio Statistic» в котором вам покажут, сколько учетных записей было добавлено, удалено и обновлено. Я решил посмотреть кого добавили.

Читайте также:  Как отключить вертикальную синхронизацию в css

В списке Distinguished Name я вижу нужного мне сотрудника. Думаю, что победа.

Перехожу на портал управления лицензиями и пользователями, пробую поиск среди активных учетных записей, но сотрудника все нет. Думаю нужно наверное слегка подождать, прошел час, эффекта не было, сотрудник все числился в удаленных. Меня это не устроило и я стал искать варианты, как его удалить от туда. Для этого Microsoft имеет оболочку «Microsoft Azure Active Directory Module for Windows PowerShell». Найти ее можно на том же сервере, где у вас установлен Synchronization Service. Запускаем его от имени администратора.

Чтобы произвести подключение к порталу Office 365 нужно использовать вот такой командлет.

У вас выскочит форма аутентификации, где нужно будет указать данные для доступа к порталу https://portal.office.com.

Далее нам необходимо найти удаленного пользователя в AD Azure и его ObjectID, так как удалять нужно именно по нему.

В моем случае я получил два пользователя, меня интересует верхний, я вижу его ObjectId, для удаления учетной записи есть такая конструкция

Вас попросят подтвердить, после чего учетная запись будет удалена из удаленных на портале, сделаем снова запрос на поиск и видим, что остался всего один пользователь.

Через минут 10 нужный мне пользователь уже присутствовал на портале, но он был не лицензирован.

В двух словах, выбираете расположение, например Россия и далее указываете какие офисные продукты вы назначаете сотруднику. Если пользователь все так же будет получать «Ошибка учетной записи. К сожалению, сейчас нам не удается загрузить вашу учетную запись. Чтобы устранить эту проблему, войдите в систему еще раз», то просто разлогиньте его учетную запись из продуктов Microsoft на его компьютере и заново пройдите аутентификацию.

Источник

Синхронизация active directory с office 365

Синхронизация локального каталога Active Directory с Office 365 ( Azure AD Connect )

Предыдущая статья про синхронизацию с помощью устаревшего коннектора Azure Active Directory Sync tool — в Архиве.

Новый коннетор Azure AD Connector вовсе не новый. Он уже используется с лета 2015 года. Однако, когда я вперый раз настраивал синхронизацию локального каталога AD с облаком Office 365 его ещё не было и я использовал коннектор Azure Active Directory Sync Tool. Примерно через год MS уведомил, что старый коннектор через год-другой поддерживаться не будет. С одной стороны, можно подумать, что этот-другой год можно будет работать с устаревшим коннектором, как MS взяла и. «отключила» его. Однажды, зайдя в Панель Управления Office 365, я увидел, что синхронизация не работает, а в логах написано — несоответствие версии коннектора. Пришлось устанавливать Azure AD Connector.

Изначально мне не понравился Azure AD Connector из-за того, что не было ясно где теперь управлять фильтрами синхронизации. С помощью ТП выяснилось, что фильтры управляются в отдельном приложении «Synchronization Rules Editor». Но настроив его однажды я просто перестал париться из-за какого-то «нового» коннетора.

На днях руководство поставило задачу — резервное копирование Exchange Online, One Drive for business, SharePoint Online в локальное хранилище. С одной стороны, облачные сервисы подразумевают собственное резервное копирование. Для Exchange по умолчанию это 14 дней хранения удалённых писем, для SharePoint и OneDrive это до 500 копий, сделанных перед изменением файлов. Но есть одно «но» — пользователь может зайти в средства восстановления и удалить всё безвозвратно. По этому была поставлена задача реализовать резервное копирование в локальное хранилище. Погуглив, был найдет Layer2 Cloud Connector, который синхронизирует как в обе стороны, так и в одну. Есстествено, я не стал бы тестироваь его с рабочей инфраструктурой, а в тестовой среде. Так мы подошли к моменту, как создать тестовую среду локального AD и синхронизировать её в облако Office 365. Данной статье будет рассмотрена только подробная синхронизация каталога в облако. Настройка контроллера домена на базе Windows Server 2016 описана в этой статье. Необходимо добавить дополнительнй суффикс UPN (такой же как и почтовый домен) в оснастке «Active Directory Domain and Trusts». Для сервера синхронизации будет использоваться отдельный сервер. Для начала надо зарегистрировать пробную версию Office 365. Подключаем домен:

Во время добавления домена exonix.ru выяснилось, что мой домен уже привязан к другой моей тестовой учётной записи Office 365, которую я использовал для первой статьи про синхронизацию каталога. Данную учётную запись, я не использовал уже больше года.

Читайте также:  Отменить синхронизацию времени домен

Для того, чтобы отключить домен от этой учтёной записи Office 365, необходимо выполнить следующие действия (в веб-админке этого не получится, т.к. у меня остались там синхронизированные пользователи). Пропустите данный шаг , если выполняете настройку синхронизации впервые:
— установить Sing-In assistant.
— установить Windows Azure PowerShell cmdlets. x64.x32.
— подключится через PowerShell и выполнить следующие команды:

Поиск всего, связаного с моим доменом:

В текстовых файлах я нашёл своих двух пользователей, которых я не мог удалить в веб-интерфейсе (и не мог поменять им адрес электронной почты):

Удаляем пользователя и домен:

Возвращаемся к настройке Office 365. Добавление пользователей можно пропустить:

Если домен уже имеет свои ДНС сервера, то стоит переключиться на самостоятельное управление. В противном случае, можно делегировать домен ДНС серверам от MS (у регистратора прописать предложенные MS сервера).

В ДНС зону домена необходимо добавить все следующие записи. У каждого клиента MS записи будут одинаковыми, кроме MX записи.

Далее, я переключаюсь в бразузер IE, т.к. Chrome не захотел запускать утилиту проверки локальной инфраструктуры:

Возвращаемся в Chrome.

Никакая очистка среды не нужна (если не будет настоятельно требоваться):

Скачиваем Azure AD Connect :

Запускаем, выбираем Настроить (Customize):

И начинается самое интересное. Azure AD Connect в настоящее время предлагает больше способов синхронизации. Если в первый раз я использовал синхронизацию паролей в облако, то сейчас я решил попробовать «сквозную аутентификацию» (Pass-through authentication). В этом случае пользователь, который пробует войти в Office 365, авторизуется не Office 365, а локальным сервером через установленный агент. А это значит, что теперь не нужно запускать синхронизацию, после смены пароля (или ждать до 30 минут). К сожалению, пока не удалось найти хоть какие-то логи на локальных серверах об авторизации пользователей.

Вводим учётные данные от Office 365:

Вводим учётные данные от локального AD:

Если нужного домена нет, значит его не добавили как дополнительный UPN.

Выбираем только те организационные еденицы, ресурсы которых будут синхронизироваться с Office 365. Это второй большой плюс Azure AD Connect (после сквозной авторизации).

Оставляем по умолчнию (для одного домена):

Самый главный плюс (на мой взгляд) — синхронизация на основе членства у Группе! Просто напишите имя группы и нажмите Resolve:

Выставляем нужные опции (хотя я не уверен, что синхронизация паролей теперь нужна). Запись пароля из Облака в локальную AD возможна только в том случае, если имеется подписка Azure AD.

Собственно, итоговый лог и скажет о невозможности настроить обратную запись паролей (из Office 365 в локальный AD):

У меня был один тестовый пользователь, который входит в группу для синхронизации AADC. Т.к. больше никаких настроек с ним не производилось, то он «синхронизировался» в таком виде (домен входа exonixgmbh.onmicrosoft.com). Такой пользователь не сможет войти в Office 365, т.к. его «не существует» в локальном AD.

Для того, чтобы пользователь смог пользоваться Office 365, надо синхронизировать его правильный UPN и почту:

Включаем циклическую синхронизацию (каждые 30 минут):

А вот так можно запускать синхронизацию вручную:

Если нужно добавить ещё несколько OU для синхронизации, то это можно сделать в Synchronization Service. Фильтры синхронизации правятся в Synchronization Rules Editor. Оба приложения запускаются с повышенными правами!

Ещё нужно добавить, что если пользователь имеет несколько почтовых псевдонимов (Alias), то он должен быть записан в атрибут proxyAddresses, где заглавные буквы SMTP означают главный почтовый адрес, от которого будет уходить почта:

На этом настройка синхронизации локальный учётных записей пользователей завершена. Если сравнивать её с предыдущим коннектором, то это как настраивать DirectAccess на 2012 и 2012 R2 серверах. Т.к. в предыдущем коннекторе нужно было сделать много чего вручную, а в Azure AD Connect — практически всё делается автоматом + синхронизация на основе членства в группе. Мне определённо нравится этот коннектор )

Источник

Настройка служб ADFS для Office 365 для единого входа

Office 365 ProPlus переименован в Майкрософт 365 корпоративные приложения. Для получения дополнительной информации об этом изменении прочитайте этот блог.

В этом видеоролике показано, как настроить службу федерации Active Directory (ADFS) для совместной работы с Office 365. Он не охватывает сценарий прокси-сервера ADFS. В этом видео рассказывается о службах ADFS для Windows Server 2012 R2. Однако процедура также применима к ADFS 2,0, за исключением шагов 1, 3 и 7. В каждом из этих действий вы можете ознакомиться с разделом «Примечания для ADFS 2,0» для получения дополнительных сведений об использовании этой процедуры в Windows Server 2008.

Читайте также:  Нелинейная динамика систем фазовой синхронизации

Полезная заметка для действий, описанных в видео

Шаг 1: Установка служб федерации Active Directory

Добавьте ADFS с помощью мастера добавления ролей и компонентов.

Примечания для ADFS 2,0

Если вы используете Windows Server 2008, вам необходимо скачать и установить ADFS 2,0 для работы с Office 365. Вы можете получить ADFS 2,0 на следующем веб-сайте центра загрузки Майкрософт:

После установки с помощью центра обновления Windows Скачайте и установите все соответствующие обновления.

Шаг 2: запрос сертификата из стороннего центра сертификации для имени сервера федерации

Для Office 365 требуется доверенный сертификат на сервере ADFS. Поэтому необходимо получить сертификат от стороннего центра сертификации (CA).

При настройке запроса сертификата убедитесь, что имя сервера федерации Добавлено в поле Общее имя .

В этом видеоролике объясняется, как создать запрос подписи сертификата (CSR). Необходимо отправить файл CSR в сторонний центр сертификации. ЦС возвратит подписанный сертификат. Затем выполните следующие действия, чтобы импортировать сертификат в хранилище сертификатов компьютера:

  1. Запустите Цертлм. msc, чтобы открыть хранилище сертификатов локального компьютера.
  2. В области навигации разверните узел Личные, разверните Сертификат, щелкните папку Сертификаты правой кнопкой мыши и выберите команду Импорт.

Имя сервера федерации

Имя службы федерации — это доменное имя сервера ADFS, доступное из Интернета. Пользователь Office 365 будет перенаправлен в этот домен для проверки подлинности. Поэтому убедитесь, что вы добавляете общедоступную запись A для доменного имени.

Шаг 3: Настройка служб ADFS

Вы не можете вручную ввести имя в качестве имени сервера федерации. Имя определяется именем субъекта (общим именем) сертификата в хранилище сертификатов локального компьютера.

Примечания для ADFS 2,0

В службах ADFS 2,0 имя сервера федерации определяется сертификатом, который привязываются к «веб-сайту по умолчанию» в Internet Information Services (IIS). Перед настройкой ADFS необходимо присоединить новый сертификат к веб-сайту по умолчанию.

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

Шаг 4: Загрузка средств Office 365

Модуль Windows Azure Active Directory для Windows PowerShell и устройство синхронизации Azure Active Directory доступны в портале Office 365. Чтобы получить средства, щелкните Активные пользователи, а затем выберите пункт единый вход: Настройка.

Шаг 5: Добавление домена в Office 365

В видеоролике не объясняется, как добавить и проверить домен в Office 365. Для получения дополнительных сведений об этой процедуре, ознакомьтесь со статьей Проверка домена в Office 365.

Шаг 6: подключение ADFS к Office 365

Чтобы подключить ADFS к Office 365, выполните следующие команды в модуле каталога Windows Azure для Windows PowerShell.

Note (Примечание ) В команде Set – MsolADFSContext укажите полное доменное имя сервера ADFS во внутреннем домене, а не имя сервера федерации.

Если команды выполняются успешно, вы увидите следующее:

  • На сервер ADFS добавляется отношение доверия с проверяющей стороной Microsoft Office 365, определяющее платформу.
  • Пользователи, использующие имя пользовательского домена в качестве суффикса адреса электронной почты для входа на портал Office 365, перенаправляются на сервер ADFS.

Шаг 7: Синхронизация локальных учетных записей пользователей Active Directory с Office 365

Если имя внутреннего домена отличается от имени внешнего домена, используемого в качестве суффикса адреса электронной почты, необходимо добавить имя внешнего домена в качестве альтернативного суффикса UPN в локальный домен Active Directory. Например, внутреннее доменное имя — «Company. local», но имя внешнего домена — «company.com». В этом случае необходимо добавить «company.com» в качестве альтернативного суффикса имени участника-пользователя.

Синхронизируйте учетные записи пользователей с Office 365 с помощью средства синхронизации каталогов.

Примечания для ADFS 2,0

Если вы используете ADFS 2,0, то перед синхронизацией учетной записи с Office 365 необходимо изменить имя учетной записи пользователя «Company. local» на «company.com». В противном случае пользователь не будет проверяться на сервере ADFS.

Шаг 8: Настройка клиентского компьютера для единого входа

После добавления имени сервера федерации в зону местной интрасети в Internet Explorer используется проверка подлинности NTLM, когда пользователи пытаются пройти проверку подлинности на сервере ADFS. Таким образом, они не получают запроса на ввод учетных данных.

Администраторы могут реализовать параметры групповой политики, чтобы настроить решение единого входа на клиентских компьютерах, присоединенных к домену.

Источник