Недоліком додати UPN замість того, щоб намагатися виправити наше доменне ім’я AD?

На жаль, я успадкував домен Active Directory, ім'ям якого є ім'я DNS, яке компанія не має - ми називатимемо її ABC.com. Я хотів би, щоб це було щось під company.com замість цього (за відповіддю MDMarra на ім'я AD, я, мабуть, використовую ad.company.com, оскільки ви ніколи не хочете використовувати ім'я DNS, яке ви використовуєте для чого-небудь іншого), але сувора вимога до Тепер можна буде перемістити електронну пошту до Office 365 цього року та використовувати синхронізацію каталогів. Для цього виглядає як мінімум, мені потрібна відповідна UPN до нашого домену електронної пошти (company.com). Гаразд, процес додавання другого UPN здається досить простим . Тестування та переміщення облікових записів до тих пір, поки всі вони не з’являться на потрібному UPN, здається достатньо розумним.

Чи є якийсь мінус просто зробити це? Чи зрештою прибуде похмурий технічний борг, якщо ми залишимося на цьому "невласне" доменне ім'я ABC.com безстроково?

Для довідки, у нас є єдиний ліс, єдиний домен із усім (ліс, функціональний рівень, всі постійні округи) на рівні 2012R2 та Exchange 2010 на цьому домені. В AD існує близько 150 користувачів та 450 комп’ютерів (багато автоматизованих програм / тестів). Хоча я безпечно орієнтувався у нас з 2003 року до 2012R2, я ні в якому разі не називаю себе експертом AD.

Схоже, не рекомендується перейменувати домени, і оскільки у нас на домені є Exchange 2010, я не вірю, що це навіть буде можливим.

Як я це бачу, я міг:

• додати другий UPN і зробити це. Я можу впоратися з необхідністю вручну встановити UPN на речі під час їх створення / додавання ...
• додайте до лісу другий домен, перемістіть усе, і завжди майте цей застарілий кореневий домен назавжди, який я не можу видалити
• створити другий ліс, ліс <-> ліс довіряй, роби все так, як мені дуже хочеться в цьому новому лісі з нуля ... перемісти все, і врешті-решт прибрати початковий ліс. Дійсно повільний, дуже ретельно, випробуваний вперед і назад, і, мабуть, з великими витратами (як мінімум за витрачений час). У світі сновидінь це здається найкращим, але я не впевнений, що можу виправдати діловий випадок для цього (якщо хтось не заявить, що відбудеться похмурий приїзд жатки).
• ??? щось інше я не думав

Отже, екзистенційна криза з приводу того, що ви не володієте доменом, який ви використовуєте внутрішньо, - з точки зору Office 365, це добре. Office 365 піклується про перевірку доменів електронної пошти, якими ви користуєтесь, а не ваш домен AD. Тож підхід, який ви застосували, змінивши UPN-адреси на відповідність електронних адрес користувачів, є відповідним і правильним.

Тепер, з точки зору суто AD, ви ніколи не зможете отримати сертифікат третьої сторони для цього внутрішнього домену DNS, оскільки ви не володієте ним. Це може бути або не бути проблемою для вас. Ви також ніколи не зможете довіритися іншому домену, який має те саме ім’я, тому в маловірогідному випадку, якщо ви злитеся з компанією, яка є власником цього домену, і вони також використовують це ім’я, у вас виникнуть кошмари міграції. Я б уявив, що ймовірність цього десь близька до 0.

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