Перенос / перенос паролей Active Directory в базу данных - PullRequest
0 голосов
/ 29 марта 2012

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

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

Мы можем просто переместить эти паролик новой базе данных SQL, но как мы собираемся проверить пароль?Какой алгоритм шифрования и соль мы будем использовать?

Спасибо,

1 Ответ

0 голосов
/ 29 марта 2012

Большую часть этого месяца я провел, работая с заказчиком, который объединяет различные леса Active Directory в один домен. Мы не использовали никаких сторонних инструментов - только стандартные утилиты Microsoft, то есть Active Directory Migration Tool (ADMT) v3 и Exchange Mizard Wizard (один из инструментов развертывания Exchange Server 2003), - но они, похоже, справляются со своей задачей.

Поскольку перенос нескольких сотен пользователей в новые учетные записи (с новыми паролями) вызовет огромное количество обращений в службу поддержки, я хотел, чтобы DLL-библиотека миграции паролей ADMT работала. Это заняло некоторое время, но с помощью моих коллег из службы поддержки предприятия (фактически, вызова PSS) мы нашли выход. Это то, что требовалось:

(Для справки, исходный и целевой домены находились в функциональном режиме домена Windows Server 2003 и леса и работали под управлением Windows Server 2003 с набором пакетов обновления 1 и 2.)

Make sure that there is a trust in place between the source and target domains.
Install ADMT by running admtsetup.exe and follow the installation wizard on the computer that will be used for the migration (I used a domain controller in the source domain but ideally you would have dedicated computers for migration activities and it seems logical that this should be in the target domain).
If not already created by ADMT, create a new domain local group called domainname$$$. This group must be empty, and is required in order to migrate the sIDHistory information between source and target accounts.
On the domain controller that will be used to export the account information (usually the DC holding the PDC Emulator operations master role for the source domain), create/set a value of 1 for a DWORD registry key called TcpipClientSupport in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\.
In both the source and target domains, ensure that success and failure auditing is enabled for account management.
On a computer with ADMT installed, create a password encryption key for each source domain, by shelling out to a command prompt and entering the following commands:
cd %systemroot%\ADMT
admt key /option:create /sourcedomain:<em>domainname</em> /keyfile:<em>filename</em>.pes
(the domainname can be specified in NetBIOS or DNS format.)
On the domain controller in the source domain that holds the PDC Emulator operations master role, connect to the computer with ADMT installed (e.g. via the c$ administration share) and access the %systemroot%\ADMT\PES folder.
Run pwdmig.exe to install the ADMT Password Migration DLL and follow the installation wizard. During the installation, supply the password encryption (.PES) file that was created earlier.
This is the step that’s not in the instructions – even though the password encyption file was supplied during the installation of the ADMT Password Migration DLL, it still needs to be imported manually on the PDC Emulator, by shelling out to a command prompt and entering the following commands:
cd %systemroot%\ADMT
admt key /option:import /sourcedomain:<em>domainname</em> /keyfile:<em>filename</em>.pes
On the domain controller that will be used to export the account information, create/set a value of 1 for a DWORD registry key called AllowPasswordExport in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\. Note that this key constitutes a security risk and should only be enabled during the period of migration.
Restart the computer with the ADMT Password Migrator DLL installed.
Start the Password Export Server service.

Большая часть этого точно соответствует документации - главное отличие заключается в необходимости вручную импортировать файл шифрования пароля. Без этого я получал следующее сообщение:

Ошибка Невозможно установить сеанс с сервером экспорта паролей. Сервер экспорта исходного пароля и целевой сервер не имеют одинакового ключа шифрования для исходного домена.

Наконец, какие разрешения требуются? Я использовал локальную систему для службы сервера экспорта паролей. Для всего остального я использовал учетную запись, которая была создана в обоих лесах с одинаковыми паролями и которая была членом группы администраторов домена. Это немного излишне, и передовая практика предполагает использование учетной записи с минимально необходимыми разрешениями. В основном требуется учетная запись:

Domain administrator in the source domain.
Local administrator on the computer on which ADMT is installed.
Delegated permissions on OUs that are targets for resource migration in the target domain, including the extended right to Migrate SID History (visible in the Security for an object using the Advanced Features view in Active Directory Users and Computers).

Дополнительные рекомендации можно найти в Руководстве по миграции ADMT v3.

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