Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Intraforest migration SQL-Server 2005\2008  [new]
ZCaRZa
Member

Откуда:
Сообщений: 5
Хотелось бы уточнить модель миграции SQL-сервера из исходного домена в целевой в пределах леса. Если у кого есть ссылки по данной теме с радостью приму их :)

Всё что написано ниже - моё ИМХО, которое появилось на свет в результате прочтения ADMT Migration guide.


Дано:
Лес. Он состоит из 3-х доменов (1 корневой (domain) и 2 дочерних). Исходным доменом является 1-ый дочерний домен (ishodniy.domain), целевым доменом - 2-ой дочерний (celevoi.domain) соответственно. Между доменами сущевствуют транзитивные отношения, которые возникают в результате дефолтных двусторонних трастов с корневым доменом. В исходном домене имеется MS SQL Server 2005\2008 - (sql1.ishodniy.domain). Сервис базы данных запускается под учетной записью исходного домена ishodniy\service_sql. Аутентификация пользователей на этом SQL-сервере производится посредством Windows Authentication (используются учётные записи ishodniy\usr1, ishodniy\usr2 и т.д.). На данном сервере SQL имеются 2 базы: base1, base2. В каждой базе созданы логины, которые соответствуют уч. записям пользователей АД, которые имеют доступ к этому серверу, например: base1 login:usr1 - ishodniy\usr1. Каждому логину назначены роли разного типа и уровня доступа к базам.

Требуется:
Мигрировать объекты АД (уч. записи пользователей, сервиса SQL, сервера SQL) из исходного домена в целевой. Причём привязки логинов баз данных с уч. записями пользователей АД - должны сохраниться. Так эе должны сохраниться роли, которые назначены каждому из логинов баз данных сервера SQL.

Как я это вижу и как это подтверждается моими тестами:
1) Провожу миграцию учётных записей пользователей из исходного домена в целевой. Получается: celevoi\usr1, celevoi\usr2..
Проверяю доступ к базам данных SQL-сервера sql1.ishodniy.domain, используя рабочую станцию, которая находится в целевом домене с установленным на ней SQL Management Studio и учетные записи пользователей, которые смигрировал в целевой домен. Работоспособность не нарушена. Доступ сохранился. Базы открываются. Таблицы выводятся. Так же можно через удалнный рабочий стол подключится к sql1.ishodniy.domain и запустить SQL Management Studio напрямую, используя учётные записи celevoi\usr1, celevoi\usr2.. - доступ так же сохранился.

ВОпрос: SID History?

2) Провожу сканирование sql1.ishodniy.domain на сервисные учётные записи. АДМТ выявляет ishodniy\service_sql.
3) Мигрирую учётную запись ishodniy\service_sql в целевой домен. Она становится celevoi\service_sql.
4) Провожу миграцию сервера SQL. Сервак переезжает в целевой домен и становится sql1.celevoi.domain. Служба баз данных после миграции запустится под учётной записью celevoi\service_sql.

Проверяю доступ аналогичным путём (как и в пункте 1), используя учётные записи пользователей целевого домена, я аутентифицируюсь на SQL-сервере, который переехал в целевой домен (sql1.celevoi.domain). В итоге доступ к базам данных сохранился. Работоспособность не нарушена.

ВОпрос: SID History?

Есть лишь один момент... если открыть свойства логинов баз данных или взглянуть на логины самого сервера SQL, которые связаны с доменными учётными записями пользователей, то они по прежднему будут выглядеть ishodniy\usr1.... И если эти логины( сервера SQL) удалить, а потом заново создать, указывая уже учётные записи пользователей celevoi\usr1, celevoi\usr2.., то привязки не разрушатся. Тем самым доступ созраняется в полной мере, каким он был в исходном домене, а так же мы избавляемся от всех хвостов исходного домена.

ВОпрос: Всё ли правильно? Может быть я что-то упустил... или возможно эти привязки остаются по другим неким причинам, не связанным с SID History?
4 фев 13, 16:05    [13873252]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить