Як виконати міграцію домену Active Directory для сервера безпеки Dell

• Dell Security Management Server (раніше Dell Data Protection | Enterprise Edition) встановлюється і приєднується домен.
• Існуючий домен було додано до розділу "домен" під консоллю WebUI.
• На сервері активовано кінцеві точки.
• Потрібне перенесення домену.
• Ми також плануємо перенести історію SID об'єктів AD.
• Кінцеві точки мають повне підключення до сервера та можуть відновлювати політики старого домену перед початком процесу міграції домену.
• Зашифровані дані на кінцевих точках повністю доступні, кінцеві точки активовані, і їх можна деактивувати та повторно активувати. Ми можемо підтвердити, що активація відбувається без будь-яких проблем за допомогою швидкого WSDeactivate будь-яких кінцевих точок.

Загальні кроки не надто складні, але потрібно розуміти, що при неправильному виконанні всього процесу дані можуть бути втрачені або може знадобитися відновлення машин. Нарешті, хоча цей процес можна виконати на будь-якій версії Dell Security Management Server і клієнта, Dell Technologies рекомендує встановити принаймні 8.3.0 клієнт і сервер 8.5, оскільки з тих пір було внесено кілька вдосконалень, які спрощують загальний процес міграції на стороні Dell Security Management Server. Нижче наведено огляд того, як працює загальний процес, і деякі з найбільш хвилюючих питань.

Насамперед потрібно зрозуміти, чи потрібна міграція домену. Бувають ситуації, наприклад, коли компанія переходить, наприклад, на Office 365, де достатньо додати псевдонім і встановити його як основний UPN для користувачів AD. Це не справжня міграція домену, і жодних інших дій щодо захисту даних Dell не потрібно | Сервер Enterprise Edition, ніж додавання нового псевдоніма до списку псевдонімів домену в розділі Налаштування, Список псевдонімів доменів . Якщо створюється новий домен і об'єкти AD потрібно перенести зі старого виведеного з експлуатації домену на новий, саме тоді необхідно планувати міграцію домену.

Щоразу, коли планується міграція домену, першим кроком є можливість перенесення також історії SID. Щоб міграція домену була успішною на стороні сервера Dell Security Management, потрібно зберегти історію SID, інакше об'єкти AD вважаються новими для нашого сервера керування безпекою Dell, і, отже, після повторної активації ми не можемо використовувати ті самі ключі шифрування. Dell вимагає перенести історію SID. Ми не збираємося витрачати час на те, як виконується міграція домену, оскільки це не Dell Data Protection | Завдання шифрування, але існує кілька інструментів як ADMT від Microsoft, які дозволяють організації перенести домен A на домен B. Як зазначалося вище, перенесення історії SID потрібне для того, щоб ми зберігали стійкість щодо ключів. Перенесення історії SID означає, що ми додаємо до атрибута SID історію в AD попереднього переходу SID старого користувача, гарантуючи безперервність у перенесених об'єктах.

Як правило на стороні АД:

• Коли будь-який об'єкт перейменовується, значення атрибута objectSID (SID) не змінюється. Коли ви переміщуєте об'єкт з одного домену в інший, то objectSID повинен змінитися, так як частина його є предметно-специфічною, а старий SID додається до SIDHistory (за умови, що він мігрується). Ви можете переглянути SIDHistory за допомогою ADSI Edit (можна переглядати в шістнадцятковому або десятковому дробі). Якщо значень немає, то немає журналу SID або об'єкт ніколи не переміщався з іншого домену.
• SIDhistory доступно лише під час міграції облікових записів між доменами або лісами.

Нижче наведено скріншот того, як визначити, чи SIDHistory було перенесено за допомогою редактора атрибутів:

Після того, як ми підтвердили, що SIDHistory перенесених користувачів і машин також були переміщені, ми можемо рухатися вперед із конфігурацією Dell Security Management Server. Якщо потрібно отримати додаткові відомості про те, як виконати міграцію домену та зберегти журнал SID, перегляньте наведену нижче документацію Microsoft.

• https://www.microsoft.com/en-us/download/details.aspx?id=19188
• https://technet.microsoft.com/en-us/library/cc974332(v=ws.10).aspx
• https://technet.microsoft.com/en-us/library/cc974384(v=ws.10).aspx

Нижче показано, що відбувається під час міграції домену на стороні сервера Dell Security Management Server.

1. На стороні клієнта:
   • Ми вирішуємо UPN користувачів на SID. Шукаємо їхній SID у файлі сховища. Ми його не знаходимо.
   • Ми вирішуємо, що це новий користувач, і звертаємося до Сервера безпеки, передавши пароль UPN як типовий запит на активацію.
2. На стороні сервера:
   • Отримуємо запит на активацію. Ми зв'язуємося з Active Directory та шукаємо UPN. Потім ми сортуємо користувача, і в рамках цього процесу сортування ми помічаємо, що SID у таблиці сутностей не збігається з SID у AD. Ми розглянемо SIDHistory щоб перевірити наявність ідентифікатора SID у нашій таблиці сутностей. Якщо ми його не знайдемо, ми викидаємо виняток, і активація не вдається, оскільки ми вже маємо цей SCID. Коли ми знаходимо SID, ми оновлюємо таблицю сутностей новим SID (у частині UID першою частиною є домен, а ми оновлюємо її та оновлюємо частину домену кінцевої точки).
   • Потім ми передаємо клієнту старі ключі, політику, DCID і так далі (ніби це була повторна активація).
3. Повернутись до клієнта:
   • Кінцева точка отримує цю інформацію та додає запис у файл credsys.vlt, що користувач активований , і користувач у цей момент увійшов у систему як зазвичай.

Ключовим моментом на стороні сервера Dell Security Management є розуміння того, чи потрібно додавати новий домен під веб-інтерфейсом, щоб змусити працювати з новими та старими користувачами під час активації або повторної активації.

Під час міграції домену ми не додаємо новий домен до консолі Dell Security Management Server, ЯКЩО там є кореневий домен старого та нового перенесеного домену. Досить додати новий домен у вигляді псевдоніма в розділі "Налаштування", "Список псевдонімів доменів". (І ми припускаємо, що існує двонаправлена довіра між батьківським і новим дочірнім доменом.) Сервісний обліковий запис для кореневого домену має бути налаштовано, можливо, у батьківському домені. Якщо, натомість, ми переносимо домен A.local на B.local, і ці два домени не є дочірніми доменами одного кореневого домену або вони належать до іншого лісу, нам потрібен новий домен, який додається під нашою консоллю, оскільки ми повинні прив'язати всі існуючі кінцеві точки до нового домену та нового облікового запису служби.

Розуміння вищесказаного, як правильно налаштувати Dell Security Management Server, є ключовим моментом, оскільки в іншому випадку ми стикаємося з кількома проблемами після міграції. Розуміння того, яка довіра існує між цими доменами та їхніми кореневими доменами (якщо такі є), а також який список їхніх поточних доменів у консолі Dell Security Management Server також є життєво важливим. Правило просте, якщо у вас є якась довіра між батьком/дитиною, то наявність під Dell Data Protection | Сервера Enterprise Edition, кореневого домену та псевдонімів на місці достатньо. В іншому випадку ми повинні додати стільки дочірніх доменів під Dell Security Management Server, скільки їх реальних субдоменів, і це правило поширюється і на міграцію доменів.

Нарешті, як і в цілому, ми ніколи не повинні додавати одночасно дочірній і батьківський домени, оскільки наявність одного і того ж користувача, потенційно видимого на обох рівнях, порушує для нас речі. І видалення домену (поки що) не є повністю підтримуваним завданням на стороні Dell Security Management Server.

Якщо клієнт працює на версії 8.2.1 або ранішої, а сервер на версії 8.3.1 або ранішої, WSDeactivate є обов'язковим кроком, оскільки ми не перейменовували частину домену кінцевої точки на стороні сервера автоматично. Цього не можна сказати про останні збірки нашого Dell Security Management Server або кінцевої точки.

Старі домени не можна видалити з бази даних Dell Security Management Server вручну або за допомогою консолі. Це пов'язано з тим, що Dell Security Management Server шукає користувача або групу, а потім визначає, що це членство в домені. У зв'язку з цим, що має статися, коли домен видаляється, усі об'єкти, які є частиною цього домену, також мають бути видалені. Жоден з варіантів не підтримується на даному етапі. Dell вивчає можливість змінити цю поведінку в майбутніх збірках Dell Security Management Server, хоча на даному етапі це не підтримується і не є життєздатним завданням. До речі, якщо ми вирішуємо позначити (вручну) домен як видалений у базі даних, ми починаємо отримувати помилку, яка викидається в журналах сервера кожні 15 хвилин для всіх пов'язаних осиротілих користувачів і груп.

Якщо Shield видаляється на перенесеній кінцевій точці, тут потрібні ті самі кроки, які потрібні для примусової звичайної (недоменної) повторної активації проти того самого ідентифікатора Shield ID. У звичайних зашифрованих файлах ми повинні застосувати той самий DCID у реєстрі, перш ніж дозволити кінцевій точці повторно активуватися проти Dell Data Protection | Enterprise Edition Server або Dell Security Management Server. Якщо у вас виникнуть запитання, зверніться до служби технічної підтримки за додатковою допомогою.

Ні, нова ліцензія домену не потрібна, оскільки Dell Data Protection | Сервер корпоративної версії 8.x. На старіших версіях Dell Data Protection | Enterprise Edition Server, нова ліцензія все ще потрібна. Зверніться до служби технічної підтримки для отримання додаткової інформації.