Меню

Синхронизация файлов в домене



Синхронизация с Active Directory

Синхронизация предназначена для автоматического поддержания всех данных сотрудников и компании, сохраняемых в настройках комплекса, в актуальном состоянии. Все сделано таким образом, чтобы администраторы не выполняли двойную работу при изменении данных в Active Directory — не будет необходимости изменять эти данные в настройках комплекса. Примеры: уволился или добавился сотрудник, изменилась структура компании, добавились подчиненные у начальников и т.д.
Настроив автоматическую синхронизацию один раз, администратору не нужно будет посещать вкладки настроек «Пользователи базы», «Структура компании», «Досье сотрудников» — синхронизатор все будет выполнять сам автоматически (получая данные из Active Directory и записывая их в базу настроек комплекса).

Важно:
— Синхронизация возможна только при использовании Microsoft SQL Server (MySQL не поддерживается!).
— Настройки синхронизации, также как и саму синхронизацию, администратор может проводить со своей машины, которая входит или не входит в один из доменов компании.
— Если в компании несколько администраторов, то каждый может работать со своей машины.
— Вход в программу глобальных настроек может быть выполнен под администратором БД или же специально созданным пользователем через меню «Утилиты».
— Необходима учетная запись в домене, которая имеет права на чтение из Active Directory.
— Если в ходе синхронизации необходимо синхронизировать установки клиентских машин, то машина, с которой выполняется синхронизация, должна быть в домене, а также учетная запись в домене должна дополнительно иметь права на копирование файлов, запись в реестр и запуск служб на удаленных машинах домена.
— При удаленном доступе к контроллеру домена необходимо открыть на нем порт LDAP (обычно TCP 389).

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

Здесь указывается список доменов компании, с которыми необходимо производить синхронизацию.
Между доменами должно быть установлено доверие (Trust).
Контроллер домена не является обязательным для указания (обязателен только при удаленном доступе).
Сервер комплекса может быть один для всех доменов или разный (в случае использования нескольких серверов).

Здесь указываются группы, OU или одиночные компьютеры/пользователи для трех типов синхронизации:

1) Синхронизация клиентских установок — указываются группы/машины, на которые должен быть установлен клиент комплекса. Таким образом, в ходе синхронизации происходит установка клиентов на те машины, где клиент еще не установлен. Автоматическое удаление клиентов также возможно, однако управляется настройкой на вкладке настроек «Общие настройки» для компьютера. Там же находится и опция автоматического обновления клиентов.

2) Синхронизация выборочного наблюдения — указываются группы/пользователи, для которых будет выполняться выборочное наблюдение. Таким образом, вручную список пользователей на этой странице настроек заполнять будет не нужно. В ходе синхронизации список будет обновляться автоматически!

3) Синхронизация прав начальников — указываются группы/пользователи в одной из ролей (см. ниже).
Роли начальников:
«Супервизор» — данному начальнику доступны отчеты по всем сотрудникам компании (все домены).
«Суперпользователь» — доступны отчеты только по сотрудникам своего домена.
«Пользователь» — настраиваемые вручную права. После синхронизации на вкладке настроек «Пользователи базы» необходимо самостоятельно выбрать отделы или сотрудников, за которыми будет наблюдать данный начальник.
«Начальник» — доступны отчеты по себе самому и своим подчиненным. Что это означает? Если для каких-то сотрудников в AD установлен «Manager» (начальник), то у этого начальника появится поле directReports, которое и будет использоваться для создания прав доступа. Т.е. данный начальник сможет наблюдать только за самим собой, своими подчиненными и подчиненными своих подчиненных (и т.д. рекурсивно по иерархии подчинения вниз).

Приоритеты ролей: если один начальник входит сразу в несколько ролей, то для решения данного конфликта приоритеты расставлены в вышеописанном порядке.
В ходе синхронизации происходит заполнение данных на вкладке «Пользователи базы».

Внимание! Стандартные группы «Компьютеры домена» и «Пользователи домена» использовать нельзя! Вместо этого нужно указывать сам домен в таком же формате (DC=. DC=. ).

Аналогично предыдущей вкладке «Объекты», но только указываются группы, OU или одиночные компьютеры/пользователи для сопоставления их с профилями клиентских настроек. См. раздел «Группы» в настройках комплекса.
Данная вкладка служит для того, чтобы не заполнять вручную раздел «Группы» в настройках комплекса, а синхронизировать с Active Directory.
Важно! Если пользователь входит в две и более групп, которые выбраны здесь и для которых установлены разные профили настроек, то конечная выборка профиля настроек для этого пользователя будет непредсказуемой!

В больших компаниях может быть необходимо выполнять синхронизацию только лишь с выбранными отделами/подразделениями в AD, а не со всей иерархией. В таком случае необходимо выбрать нужные контейнеры AD на этой вкладке (выбранный отдел автоматически включит все отделы нижнего уровня!). Если же данный список пуст, то синхронизация будет производиться полностью по всей иерархии домена(ов).

Вкладка «Клиентские машины»

Здесь можно посмотреть список машин, на которые уже установлен клиент и тех машин, на которые должен быть установлен клиент, но еще не установлен.
Существует возможность вручную выбрать и установить клиентов на машины.
Удаленная установка осуществляется этим способом.

Здесь настраиваются параметры синхронизации:
«Игнорировать отключенные учетные записи» — если учетная запись компьютера или пользователя AD отключена, то обрабатываться синхронизатором не будет.
«Пинговать машины перед установкой клиента» — рекомендуется для ускорения процесса установки (для выключенных машин).
«Таймаут пинга» — время в мсек ожидания ответа от клиентской машины. Если в логах частые ошибки 11010 при включенных машинах, то имеет смысл увеличить данное значение.
«Название компании» — используется при синхронизации иерархии как верхний ее уровень.
«Строить иерархию на базе групп» — игнорировать реальное расположение компьютеров/пользователей в иерархии Active Directory и вместо этого строить иерархию используя группы, в которых находятся компьютеры/пользователи.
«Опции синхронизации досье» — указывайте названия полей AD для синхронизации досье.
«Настройки очистки лога» — очистка лога также происходит в ходе синхронизации.

Можно выполнить синхронизацию вручную (будет создан новый консольный процесс) или же добавить задание в планировщик заданий Windows для автоматической синхронизации по расписанию.
Важно: задание в планировщике должно выполняться от имени текущего пользователя Windows!

Здесь можно смотреть результаты работы как ручной, так и автоматической синхронизации, а также отслеживать изменения настроек.

Какие параметры не синхронизируются и меняются вручную

После успешной синхронизации можно менять вручную следующие параметры, которые не подлежат синхронизации:
— На вкладке «Пользователи базы» все пользователи с логинами SQL (не логины Windows).
— На вкладке «Пользователи базы» для пользователей с логинами Windows «Базовые права».
— На вкладке «Пользователи базы» для пользователей с логинами Windows «Доп. запреты» для роли «Пользователь».
— На вкладке «Досье сотрудников» все досье пользователей, не входящих в состав домена(ов).
— На вкладке «Досье сотрудников» параметр «Профиль».

Как настроить автоматическую отправку отчетов начальникам/сотрудникам

После успешной синхронизации можно вручную настроить права начальникам на отправку отчетов (вкладка «Пользователи базы») если в этом есть необходимость.
Далее эти начальники хотя бы один раз должны зайти в свой «Личный кабинет» (через веб-интерфейс БОСС) и включить там авто-генерацию отчетов.
Чтобы сотрудники могли получать отчеты на свои e-mail о своих же действиях необходимо указание их e-mail в карточке AD, а также включение соотв. разрешения в правах их начальника (лучше это разрешение включить у начальника верхнего уровня иерархии подчинения, а не у множества нижестоящих начальников).
Опции генерации отчетов должны быть настроены в серверных настройках (разделы «Генератор отчетов»).

Источник

Windows Server 2012 R2. Work Folders – синхронизация файлов между устройствами

Начинаем знакомиться с новыми возможностями и ключевыми усовершенствованиями, которые нас ожидают в новом обновлении серверной линейки Microsoft — Windows Server 2012 R2, До даты официального выпуска осталось чуть больше месяца (а это, напомним, случится 18 октября 2013 года). Сегодня речь пойдет о новом функционале Windows Server 2012 R2 под названием Work Folders.

Нередка ситуация, когда работник для работы с корпоративными данными используется больше чем два устройства (например, ноутбук и планшет). В этой ситуации, чтобы пользователи всегда работали с актуальными версиями своих данных, перед ИТ-службой встает задача синхронизации файлов. Для этих целей можно воспользоваться SkyDrive, DropBox или походим сервисом. Однако не всегда возможно хранить данные в «облаке», хотя бы из соображений конфиденциальности и безопасности. Новая функция Windows Server 2012 R2 Work Folders (или «Рабочие папки») – позволяет пользователям синхронизировать свои личные файлы в корпоративной сети с любыми своими устройствами. По сути, Work Folders является аналогом Dropbox для корпоративных пользователей.

Благодаря «Рабочим папкам» на платформе Windows Server 2012 R2 возможно организовать функциональный и безопасный сервис репликации файлов пользователей между несколькими устройствами. Work Folders на базе файлового сервера позволяет организовать «корпоративный SkyDrive. Помимо всего прочего, к пользовательским данным на корпоративном файловом сервере можно применять такие политики, как квотирование (Quota), блокировка запрещенных типов файлов (File Screening), а также динамический контроль доступа (Dynamic Access Control) и т.д., т.е. полный комплекс мер по обеспечению защиты информации.

Как и Dropbox, Work Folders позволяет хранить копии файлов на стороне сервера и клиента, и при каждом подключении клиента к серверу выполняется синхронизация данных. Благодаря данной функции пользователь может синхронизировать свои рабочие папки со своим мобильным устройством (ноутбуком, планшетом и т.д.) и осуществлять редактирование документов, даже без подключения к корпоративной сети (offline). При следующем соединении с корпоративной сетью клиент Work Folders осуществит синхронизацию изменений.

Читайте также:  Как синхронизировать сони с нокиа

На данный момент технологию Work Folders поддерживают только устройства под управлением Windows 8.1, в которую клиент Work Folders уже встроен. В ближайшем будущем будет добавлена поддержка популярных мобильных устройств: девайсов на Windows 7, Windows 8, Android, а также iOS.

Служба синхронизации Work Folder должна работать на Windows 2012 R2 с установленной ролью файлового сервера. Work Folder также возможно интегрировать со службой Active Directory Rights Management Services, позволяющей обеспечить защиту пользовательских данных.

Настройка Work Folder на Windows Server 2012 R2

Функционал Work Folders в Windows Server 2012 R2 входит в состав роли File and Storage Services и включить его можно с помощью консоли Server Manager или PowerShell.

При установке функционала Work Folders также будет установлен сервер IIS Web Core, являющийся обязательным компонентом технологии и необходимый для обслуживания клиентов.

После установки функции, нужно открыть консоль Server Manager ->File Server -> Work Folders и указать каталог, в котором будут храниться «Рабочие папки» пользователей.

Следующий шаг – выбор структуры папок. Имена подпапкок (каталоги конечных пользователей сервиса) могут содержать только имена пользователей (псевдонимы) или их полные email адреса.

Затем нужно указать список пользователей и групп, имеющих доступ к данной папке. Если нужно, чтобы у администратора сервера не было доступа к данным пользователей, отметьте флажок «Disable inherited permissions and grant users exclusive access to their files».

Далее необходимо указать будут ли на клиентских устройствах применяться политики защиты данных, такие как шифрование (на клиенте Windows 8.1 используется EFS) и защита данных паролем.

«Рабочие папки» синхронизируется посредством веб сервера IIS по протоколу HTTPS, поэтому для работы придется настроить на IIS шифрование SSL/TLS. После окончания работы мастера, нужно создать новый сертификат типа Web Server Template, содержащий FQDN имя сервера.

  1. Если для подключения предполагается использовать внешний домен, необходимо в соответствующей DNS зоне создать CNAME/ A запись.
  2. Для предоставления удаленного доступа к Work Folders возможно воспользоваться DirectAccess или новой функцией Windows Server 2012 R2 — Web Application Proxy

Данный сертификат необходимо выбрать в качестве SSLсертификата на сайте IIS.

Настройка Work Folder на клиенте

Следующий этап – настройка клиента Work Folder на пользовательском девайсе. Отметим, что для работы «Рабочих папок», клиент не обязательно должен состоять в тот же домене Windows, что и сервер Work Folder.

  1. Откройте панель управления и запустите апплет Work Folders.
  2. Система предложит указать email адрес пользователя (требует корректной настройки DNS зоны домена), или Url сервера с ролью Work Folders.
  3. Т.к. политка на сервере Work Folders требует защиты данных с помощью шифрования и пароля, необходимо подтвердить, что вы согласны применить эти политики на своем устройстве.
  4. После этого в панели управления появится информация о «Рабочих папках» (объем доступного пространства на сервер, время последней синхронизации, ошибки и т.д.).
  5. Содержимое «Рабочих папок» доступно их проводника Windows или любого файлового менеджера (по умолчанию Work Folders хранятся в каталоге c:\users\username\WorkFolders).
  6. Если скопировать или переместить в данную папку любой файл, то после следующей синхронизации, он будет скопирован на корпоративный файловый сервер и будет доступен пользователю на других мобильных и стационарных устройствах пользователя с настроенными Рабочими папками.

Настройка Work Folder с помощью групповой политики

Настроить Work Folder на клиентах возможно также с помощью групповой политик. Это удобно в случае необходимости массовой использования данной технологии на ПК домена. Интересующая нас политика находится в разделе Users Configurations-> Policies > Administrative Templates > Windows Components > Work Folders и называется Specify Work Folders settings. Чтобы задать сервер «Рабочих папок», активируйте эту политику и укажите URL путь к серверу.

Чтобы клиенты настраивали оставшиеся параметры Work Folders автоматически, также активируйте политику Force automatic setup for all users (раздел GPO: Computer Configurations> Policies > Administrative Templates > Windows Components > Work Folders.

Функционал Work Folder разработан Microsoft в рамках общего ИТ тренда под названием BYOD (Bring Your Own Device), в концепции которого пользователи могут использоваться свои личные мобильные устройства для прозрачного и безопасного доступа к корпоративным ресурсам. Одно из главных преимуществ концепции BYOD для копаний – отсутствие необходимости обеспечения сотрудников устройствами доступа (ноутбуки, телефоны, планшетные компьютеры), все, что нужно от компании – предоставить пользователям удобные службы удаленного подключений к корпоративной сети и сервисы предоставления корпоративных ресурсов.

Источник

Синхронизация объектов и учетных данных в управляемом домене доменных служб Azure Active Directory How objects and credentials are synchronized in an Azure Active Directory Domain Services managed domain

Объекты и учетные данные в управляемом домене доменных служб Azure Active Directory (Azure AD DS) могут быть созданы локально в домене или синхронизированы из клиента Azure Active Directory (Azure AD). Objects and credentials in an Azure Active Directory Domain Services (Azure AD DS) managed domain can either be created locally within the domain, or synchronized from an Azure Active Directory (Azure AD) tenant. При первом развертывании AD DS Azure автоматическая односторонняя синхронизация настраивается и запускается для репликации объектов из Azure AD. When you first deploy Azure AD DS, an automatic one-way synchronization is configured and started to replicate the objects from Azure AD. Эта односторонняя синхронизация продолжает выполняться в фоновом режиме, чтобы поддерживать управляемый домен Azure AD DS в актуальном состоянии с изменениями из Azure AD. This one-way synchronization continues to run in the background to keep the Azure AD DS managed domain up-to-date with any changes from Azure AD. Из Azure AD DS не выполняется синхронизация с Azure AD. No synchronization occurs from Azure AD DS back to Azure AD.

В гибридной среде объекты и учетные данные из локального домена AD DS можно синхронизировать с Azure AD с помощью Azure AD Connect. In a hybrid environment, objects and credentials from an on-premises AD DS domain can be synchronized to Azure AD using Azure AD Connect. После успешной синхронизации этих объектов в Azure AD автоматическая фоновая синхронизация делает эти объекты и учетные данные доступными для приложений, использующих управляемый домен. Once those objects are successfully synchronized to Azure AD, the automatic background sync then makes those objects and credentials available to applications using the managed domain.

На следующей схеме показано, как работает синхронизация между Azure AD DS, Azure AD и дополнительной локальной AD DSной средой. The following diagram illustrates how synchronization works between Azure AD DS, Azure AD, and an optional on-premises AD DS environment:

Синхронизация из Azure AD в Azure AD DS Synchronization from Azure AD to Azure AD DS

Учетные записи пользователей, членства в группах и хэши учетных данных синхронизируются одним способом из Azure AD в Azure AD DS. User accounts, group memberships, and credential hashes are synchronized one way from Azure AD to Azure AD DS. Этот процесс синхронизации выполняется автоматически. This synchronization process is automatic. Вам не нужно настраивать и отслеживать этот процесс синхронизации, а также управлять им. You don’t need to configure, monitor, or manage this synchronization process. Начальная синхронизация может занять несколько часов в течение нескольких дней в зависимости от числа объектов в каталоге Azure AD. The initial synchronization may take a few hours to a couple of days, depending on the number of objects in the Azure AD directory. После завершения начальной синхронизации изменения, внесенные в Azure AD, такие как изменения паролей или атрибутов, автоматически синхронизируются с AD DS Azure. After the initial synchronization is complete, changes that are made in Azure AD, such as password or attribute changes, are then automatically synchronized to Azure AD DS.

Когда пользователь создается в Azure AD, он не синхронизируется с AD DS Azure, пока не изменит свой пароль в Azure AD. When a user is created in Azure AD, they’re not synchronized to Azure AD DS until they change their password in Azure AD. При смене пароля хэши паролей автоматически создаются и сохраняются в Azure AD для аутентификации Kerberos и NTLM. This password change process causes the password hashes for Kerberos and NTLM authentication to be generated and stored in Azure AD. Хэши паролей необходимы для успешной проверки подлинности пользователя в Azure AD DS. The password hashes are needed to successfully authenticate a user in Azure AD DS.

Процесс синхронизации является одним способом или однонаправленным. The synchronization process is one way / unidirectional by design. Обратная синхронизация изменений из Azure AD DS обратно в Azure AD не выполняется. There’s no reverse synchronization of changes from Azure AD DS back to Azure AD. Управляемый домен в основном доступен только для чтения, за исключением пользовательских подразделений, которые можно создать. A managed domain is largely read-only except for custom OUs that you can create. Нельзя вносить изменения в атрибуты пользователей, пароли пользователей или членство в группах в пределах управляемого домена. You can’t make changes to user attributes, user passwords, or group memberships within a managed domain.

Синхронизация атрибутов и сопоставление с Azure AD DS Attribute synchronization and mapping to Azure AD DS

В следующей таблице перечислены некоторые общие атрибуты и их синхронизация с Azure AD DS. The following table lists some common attributes and how they’re synchronized to Azure AD DS.

Читайте также:  Драйвер для синхронизации андроида
Атрибут в AD DS Azure Attribute in Azure AD DS Источник Source Примечания Notes
UPN UPN Атрибут имени участника -пользователя в клиенте Azure AD User’s UPN attribute in Azure AD tenant Атрибут UPN из клиента Azure AD синхронизирован как есть в Azure AD DS. The UPN attribute from the Azure AD tenant is synchronized as-is to Azure AD DS. Самым надежным способом входа в управляемый домен является использование имени участника-пользователя. The most reliable way to sign in to a managed domain is using the UPN.
SAMAccountName SAMAccountName Атрибут mailNickname пользователя в клиенте Azure AD или автоматически сформированный User’s mailNickname attribute in Azure AD tenant or autogenerated Источником атрибута SamAccountName является атрибут mailNickname в клиенте Azure AD. The SAMAccountName attribute is sourced from the mailNickname attribute in the Azure AD tenant. Если несколько учетных записей пользователей имеют одинаковый атрибут mailNickname , то SamAccountName создается автоматически. If multiple user accounts have the same mailNickname attribute, the SAMAccountName is autogenerated. Если длина префикса mailNickname или имени участника -пользователя превышает 20 символов, SamAccountName создается автоматически в соответствии с ограничением в 20 символов для атрибутов SamAccountName . If the user’s mailNickname or UPN prefix is longer than 20 characters, the SAMAccountName is autogenerated to meet the 20 character limit on SAMAccountName attributes.
Пароли Passwords Пароль пользователя из клиента Azure AD User’s password from the Azure AD tenant Устаревшие хэши паролей, необходимые для проверки подлинности NTLM или Kerberos, синхронизируются с клиентом Azure AD. Legacy password hashes required for NTLM or Kerberos authentication are synchronized from the Azure AD tenant. Если клиент Azure AD настроен для гибридной синхронизации с помощью Azure AD Connect, эти хэши паролей помещаются из локальной среды AD DS. If the Azure AD tenant is configured for hybrid synchronization using Azure AD Connect, these password hashes are sourced from the on-premises AD DS environment.
Основной идентификатор безопасности (SID) пользователя или группы Primary user/group SID Автоматически сформированный Autogenerated Основной идентификатор безопасности учетных записей пользователей или групп создается автоматически в AD DS Azure. The primary SID for user/group accounts is autogenerated in Azure AD DS. Этот атрибут не соответствует идентификатору безопасности основного пользователя или группы объекта в локальной среде AD DS. This attribute doesn’t match the primary user/group SID of the object in an on-premises AD DS environment. Это несоответствие связано с тем, что управляемый домен имеет другое пространство имен SID, чем локальный домен AD DS. This mismatch is because the managed domain has a different SID namespace than the on-premises AD DS domain.
Журнал идентификаторов безопасности для пользователей и групп SID history for users and groups Локальный основной идентификатор безопасности пользователя и группы On-premises primary user and group SID Атрибут SIDHistory для пользователей и групп в Azure AD DS настроен в соответствии с соответствующим идентификатором безопасности основного пользователя или группы в локальной среде AD DS. The SidHistory attribute for users and groups in Azure AD DS is set to match the corresponding primary user or group SID in an on-premises AD DS environment. Эта функция позволяет выполнять перенос локальных приложений в Azure AD DS проще, так как не требуется повторно использовать ресурсы ACL. This feature helps make lift-and-shift of on-premises applications to Azure AD DS easier as you don’t need to re-ACL resources.

Войдите в управляемый домен, используя формат имени участника-пользователя Атрибут SamAccountName , например AADDSCONTOSO\driley , может быть автоматически создан для некоторых учетных записей пользователей в управляемом домене. Sign in to the managed domain using the UPN format The SAMAccountName attribute, such as AADDSCONTOSO\driley , may be auto-generated for some user accounts in a managed domain. Автоматически созданный пользователь SamAccountName может отличаться от префикса имени участника-пользователя, поэтому не всегда надежный способ входа в систему. Users’ auto-generated SAMAccountName may differ from their UPN prefix, so isn’t always a reliable way to sign in.

Например, если несколько пользователей имеют одинаковый атрибут mailNickname или пользователи имеют более длинные префиксы имени участника-пользователя, SamAccountName для этих пользователей может быть создан автоматически. For example, if multiple users have the same mailNickname attribute or users have overly long UPN prefixes, the SAMAccountName for these users may be auto-generated. Используйте формат имени участника-пользователя, например driley@aaddscontoso.com , для надежного входа в управляемый домен. Use the UPN format, such as driley@aaddscontoso.com , to reliably sign in to a managed domain.

Сопоставление атрибутов для учетных записей пользователей Attribute mapping for user accounts

В следующей таблице показано, как определенные атрибуты для пользовательских объектов в Azure AD синхронизируются с соответствующими атрибутами в AD DS Azure. The following table illustrates how specific attributes for user objects in Azure AD are synchronized to corresponding attributes in Azure AD DS.

Атрибут пользователя в Azure AD User attribute in Azure AD Атрибут пользователя в Azure AD DS User attribute in Azure AD DS
AccountEnabled accountEnabled userAccountControl (задает или удаляет значение ACCOUNT_DISABLED) userAccountControl (sets or clears the ACCOUNT_DISABLED bit)
city city l l
country country co co
department department department department
displayName displayName displayName displayName
емплойидид employeedId employeeId employeeId
facsimileTelephoneNumber facsimileTelephoneNumber facsimileTelephoneNumber facsimileTelephoneNumber
givenName givenName givenName givenName
jobTitle jobTitle title title
mail mail почта mail
mailNickname mailNickname msDS-AzureADMailNickname msDS-AzureADMailNickname
mailNickname mailNickname SAMAccountName (иногда может быть автоматически создан) SAMAccountName (may sometimes be autogenerated)
manager manager manager manager
mobile mobile mobile mobile
objectid objectid msDS-AzureADObjectId msDS-AzureADObjectId
onPremiseSecurityIdentifier onPremiseSecurityIdentifier sidHistory sidHistory
passwordPolicies passwordPolicies userAccountControl (задает или удаляет значение DONT_EXPIRE_PASSWORD) userAccountControl (sets or clears the DONT_EXPIRE_PASSWORD bit)
physicalDeliveryOfficeName physicalDeliveryOfficeName physicalDeliveryOfficeName physicalDeliveryOfficeName
postalCode postalCode postalCode postalCode
preferredLanguage preferredLanguage preferredLanguage preferredLanguage
proxyAddresses proxyAddresses proxyAddresses proxyAddresses
Состояние state st st
streetAddress streetAddress streetAddress streetAddress
surname surname sn sn
TelephoneNumber telephoneNumber TelephoneNumber telephoneNumber
userPrincipalName userPrincipalName userPrincipalName userPrincipalName

Сопоставление атрибутов для групп Attribute mapping for groups

В следующей таблице показано, как определенные атрибуты для групповых объектов в Azure AD синхронизируются с соответствующими атрибутами в AD DS Azure. The following table illustrates how specific attributes for group objects in Azure AD are synchronized to corresponding attributes in Azure AD DS.

Атрибут Group в Azure AD Group attribute in Azure AD Атрибут Group в AD DS Azure Group attribute in Azure AD DS
displayName displayName displayName displayName
displayName displayName SAMAccountName (иногда может быть автоматически создан) SAMAccountName (may sometimes be autogenerated)
mail mail почта mail
mailNickname mailNickname msDS-AzureADMailNickname msDS-AzureADMailNickname
objectid objectid msDS-AzureADObjectId msDS-AzureADObjectId
onPremiseSecurityIdentifier onPremiseSecurityIdentifier sidHistory sidHistory
proxyAddresses proxyAddresses proxyAddresses proxyAddresses
securityEnabled securityEnabled groupType groupType

Синхронизация из локальной AD DS в Azure AD и Azure AD DS Synchronization from on-premises AD DS to Azure AD and Azure AD DS

Azure AD Connect используется для синхронизации учетных записей пользователей, членства в группах и хэшей учетных данных из локальной AD DS среды в Azure AD. Azure AD Connect is used to synchronize user accounts, group memberships, and credential hashes from an on-premises AD DS environment to Azure AD. Атрибуты учетных записей пользователей, таких как UPN и локальный идентификатор безопасности (SID), синхронизируются. Attributes of user accounts such as the UPN and on-premises security identifier (SID) are synchronized. Для входа с помощью AD DS Azure хэши паролей, необходимые для проверки подлинности NTLM и Kerberos, также синхронизируются с Azure AD. To sign in using Azure AD DS, legacy password hashes required for NTLM and Kerberos authentication are also synchronized to Azure AD.

Azure AD Connect следует устанавливать и настраивать только для синхронизации с локальными средами AD DS. Azure AD Connect should only be installed and configured for synchronization with on-premises AD DS environments. Установка Azure AD Connect в управляемом домене для синхронизации объектов обратно в Azure AD не поддерживается. It’s not supported to install Azure AD Connect in a managed domain to synchronize objects back to Azure AD.

При настройке обратной записи изменения из Azure AD синхронизируются с локальной AD DSой средой. If you configure write-back, changes from Azure AD are synchronized back to the on-premises AD DS environment. Например, если пользователь изменяет пароль с помощью функции самостоятельного управления паролями Azure AD, пароль обновляется в локальной среде AD DS. For example, if a user changes their password using Azure AD self-service password management, the password is updated back in the on-premises AD DS environment.

Всегда используйте последнюю версию Azure AD Connect. В этом случае у вас точно будут исправления для всех известных ошибок. Always use the latest version of Azure AD Connect to ensure you have fixes for all known bugs.

Синхронизация из локальной среды с несколькими лесами Synchronization from a multi-forest on-premises environment

Многие организации имеют довольно сложную локальную среду AD DS, включающую несколько лесов. Many organizations have a fairly complex on-premises AD DS environment that includes multiple forests. Azure AD Connect поддерживает синхронизацию пользователей, групп и хэшей учетных данных из сред с несколькими лесами в Azure AD. Azure AD Connect supports synchronizing users, groups, and credential hashes from multi-forest environments to Azure AD.

Azure AD имеет гораздо более простое и неструктурированное пространство имен. Azure AD has a much simpler and flat namespace. Чтобы предоставить пользователям надежный доступ к приложениям, защищенным с помощью Azure AD, устраните конфликты имен участников-пользователей между учетными записями пользователей в разных лесах. To enable users to reliably access applications secured by Azure AD, resolve UPN conflicts across user accounts in different forests. Управляемые домены используют плоскую структуру подразделений, аналогичную Azure AD. Managed domains use a flat OU structure, similar to Azure AD. Все учетные записи пользователей и группы хранятся в контейнере AADDC Users , несмотря на синхронизацию из разных локальных доменов или лесов, даже если иерархическая структура подразделений настроена локально. All user accounts and groups are stored in the AADDC Users container, despite being synchronized from different on-premises domains or forests, even if you’ve configured a hierarchical OU structure on-premises. Управляемый домен выполняет сведение всех иерархических структур подразделений. The managed domain flattens any hierarchical OU structures.

Как уже было описано выше, синхронизация из Azure AD DS обратно в Azure AD не выполняется. As previously detailed, there’s no synchronization from Azure AD DS back to Azure AD. Вы можете создать пользовательское подразделение (OU) в Azure AD DS а затем — пользователей, группы или учетные записи служб в этих пользовательских подразделениях. You can create a custom Organizational Unit (OU) in Azure AD DS and then users, groups, or service accounts within those custom OUs. Ни один из объектов, созданных в пользовательских подразделениях, не синхронизирован обратно в Azure AD. None of the objects created in custom OUs are synchronized back to Azure AD. Эти объекты доступны только в управляемом домене и не отображаются с помощью командлетов Azure AD PowerShell, Microsoft Graph API или пользовательского интерфейса управления Azure AD. These objects are available only within the managed domain, and aren’t visible using Azure AD PowerShell cmdlets, Microsoft Graph API, or using the Azure AD management UI.

Что не синхронизировано с Azure AD DS What isn’t synchronized to Azure AD DS

Следующие объекты или атрибуты не синхронизируются из локальной AD DS среды в Azure AD или Azure AD DS. The following objects or attributes aren’t synchronized from an on-premises AD DS environment to Azure AD or Azure AD DS:

  • Исключенные атрибуты: Вы можете исключить определенные атрибуты из синхронизации с Azure AD из локальной AD DS среды с помощью Azure AD Connect. Excluded attributes: You can choose to exclude certain attributes from synchronizing to Azure AD from an on-premises AD DS environment using Azure AD Connect. Эти исключенные атрибуты в Azure AD DS недоступны. These excluded attributes aren’t then available in Azure AD DS.
  • Групповые политики: Групповые политики, настроенные в локальной среде AD DS, не синхронизируются с Azure AD DS. Group Policies: Group Policies configured in an on-premises AD DS environment aren’t synchronized to Azure AD DS.
  • Папка SYSVOL: Содержимое папки SYSVOL в локальной среде AD DS не синхронизируется с Azure AD DS. Sysvol folder: The contents of the Sysvol folder in an on-premises AD DS environment aren’t synchronized to Azure AD DS.
  • Объекты компьютеров: Объекты-компьютеры для компьютеров, присоединенных к локальной среде AD DS, не синхронизируются с Azure AD DS. Computer objects: Computer objects for computers joined to an on-premises AD DS environment aren’t synchronized to Azure AD DS. Эти компьютеры не имеют отношения доверия с управляемым доменом и принадлежат к локальной среде AD DS. These computers don’t have a trust relationship with the managed domain and only belong to the on-premises AD DS environment. В AD DS Azure отображаются только объекты компьютеров, присоединенные к управляемому домену, которые явно присоединены к домену. In Azure AD DS, only computer objects for computers that have explicitly domain-joined to the managed domain are shown.
  • Атрибуты SIDHistory для пользователей и групп: Идентификаторы безопасности основного пользователя и основной группы из локальной AD DS среды синхронизируются с AD DS Azure. SidHistory attributes for users and groups: The primary user and primary group SIDs from an on-premises AD DS environment are synchronized to Azure AD DS. Однако существующие атрибуты SIDHistory для пользователей и групп не синхронизируются из локальной AD DS среды в Azure AD DS. However, existing SidHistory attributes for users and groups aren’t synchronized from the on-premises AD DS environment to Azure AD DS.
  • Структуры подразделений (OU): Подразделения, определенные в локальной среде AD DS, не синхронизируются с AD DS Azure. Organization Units (OU) structures: Organizational Units defined in an on-premises AD DS environment don’t synchronize to Azure AD DS. В Azure AD DS два встроенных подразделения — один для пользователей и один для компьютеров. There are two built-in OUs in Azure AD DS — one for users, and one for computers. Управляемый домен имеет плоскую структуру подразделений. The managed domain has a flat OU structure. Вы можете создать пользовательское подразделение в управляемом домене. You can choose to create a custom OU in your managed domain.

Вопросы по синхронизации и безопасности хэша паролей Password hash synchronization and security considerations

При включении AD DS Azure необходимо использовать устаревшие хэши паролей для проверки подлинности NTLM + Kerberos. When you enable Azure AD DS, legacy password hashes for NTLM + Kerberos authentication are required. Azure AD не хранит пароли в виде открытого текста, поэтому эти хэши не могут быть автоматически созданы для существующих учетных записей пользователей. Azure AD doesn’t store clear-text passwords, so these hashes can’t be automatically generated for existing user accounts. После создания и сохранения хэшей паролей, совместимых с NTLM и Kerberos, всегда хранятся в Azure AD в зашифрованном виде. Once generated and stored, NTLM and Kerberos compatible password hashes are always stored in an encrypted manner in Azure AD.

Ключи шифрования уникальны для каждого клиента Azure AD. The encryption keys are unique to each Azure AD tenant. Эти хэши шифруются так, что только AD DS Azure имеет доступ к ключам дешифрования. These hashes are encrypted such that only Azure AD DS has access to the decryption keys. Другие службы или компоненты в Azure AD не имеют доступа к этим ключам. No other service or component in Azure AD has access to the decryption keys.

Затем старые хэши паролей синхронизируются из Azure AD в контроллеры домена для управляемого домена. Legacy password hashes are then synchronized from Azure AD into the domain controllers for a managed domain. Диски для этих управляемых контроллеров домена в Azure AD DS шифруются неактивных данных. The disks for these managed domain controllers in Azure AD DS are encrypted at rest. Эти хэши паролей хранятся и защищаются на этих контроллерах домена аналогично хранению и защите паролей в локальной среде AD DS. These password hashes are stored and secured on these domain controllers similar to how passwords are stored and secured in an on-premises AD DS environment.

Для облачных сред Azure AD Пользователи должны сбросить или изменить свой пароль , чтобы создать и сохранить в Azure AD необходимые хэши паролей. For cloud-only Azure AD environments, users must reset/change their password in order for the required password hashes to be generated and stored in Azure AD. Для любой облачной учетной записи пользователя в Azure AD хэши паролей сохраняются и создаются в совместимых форматах NTLM и Kerberos после включения доменных служб Azure AD. For any cloud user account created in Azure AD after enabling Azure AD Domain Services, the password hashes are generated and stored in the NTLM and Kerberos compatible formats. Все учетные записи пользователей облака должны изменить свой пароль, прежде чем они будут синхронизированы с Azure AD DS. All cloud user accounts must change their password before they’re synchronized to Azure AD DS.

Для гибридных учетных записей пользователей, синхронизированных из локальной среды AD DS с помощью Azure AD Connect, необходимо настроить Azure AD Connect для синхронизации хэшей паролей в форматах, совместимых с NTLM и Kerberos. For hybrid user accounts synced from on-premises AD DS environment using Azure AD Connect, you must configure Azure AD Connect to synchronize password hashes in the NTLM and Kerberos compatible formats.

Дальнейшие действия Next steps

Дополнительные сведения об особенностях синхронизации паролей см. в статье как работает синхронизация хэшей паролей с Azure AD Connect. For more information on the specifics of password synchronization, see How password hash synchronization works with Azure AD Connect.

Чтобы начать работу с Azure AD DS, создайте управляемый домен. To get started with Azure AD DS, create a managed domain.

Источник