Включение/отключение SID History

Немало уже копий сломал и бессонных ночей провел, осуществляя миграции при помощи утилиты Active Directory Migration Tools (ADMT), однако наибольшие затруднения у меня вызывали проблемы использования SID history  при миграциях в разные домены. Этот пост – небольшая заметка для самого себя о том, как работает SID History.

Что такое SID History

SID History – это атрибут объекта в Active Directory, который хранит старый Security IDentifier(SID), наиболее часто применяется при различного рода миграций. Итак, представьте ситуацию:  у вас есть два домена старый и новый, и вам нужно переместить пользователей в новый домен, но так, чтобы новые учетки в новом домене сохранили доступ к их старым папкам и файлам. Это необходимо для того, чтобы уменьшить трудоемкость и «нервозность» процесса миграции, чтобы администратору не пришлось переназначать разрешения на сетевые шары, папки, приложения и т.д. Чтобы иметь возможность использовать SID history, вам необходимо отключить фильтрацию SID (SID Filtering ) и активировать SID History и доверительные отношения между двумя доменами.

Чтобы включить «SID History on a trust», воспользуйтесь следующей командой:

netdom trust domain.local /domain:microsoft.com /enableSIDhistory:yes

Что такое SID Filtering

SID Filtering  – эта мера безопасности, которая призвана защитить ваше новое окружение от потенциального злоумышленника, который может проникнуть из старого домена. Хотя вы можете подумать, что старый домен после миграции не несет угрозы, так как не нужен, я, учитывая мой опыт миграций, могу сказать, что в большинстве случаев старый домен остается активным еще некоторый (иногда длительный) период времени, но вся административная работа с ним (установка обновлений и патчей, управление доступом и анализ логов) сводится к минимальному набору работ или не ведется совсе. Это и создает потенциально небезопасную среду, уязвимостями в которой  может воспользоваться злоумышленник и проникнуть в старый домен.

Именно по этой причине SID Filtering – это неплохая, но не обязательная функция, которая полностью блокирует использование SID History, которая так важна при осуществлении миграции.  Следующая команда позволяет отключить SID Filtering:

Netdom trust domain.local  /domain: microsoft.com /quarantine:No /userD: domain_admin /passwordD: adminpa$$

отключить спам-фильтр Gmail

как оказалось Gmail не предоставляет возможности выключить спам фильтр. Поэтому пойдем другим путем 🙂

Следующие действия создают фильтр при которых письма никогда не попадут в спам:

  • логинимся на gmail.com
  • нажимаем “настройки” (иконка в виде шестеренки в правом углу экрана). Выбираем “настройки”
  • заходим в “Фильтры”
  • нажимаем “Создать новый фильтр” (внизу ссылка)
  • в поле “Нет” пишем любую абракадабру, например, faw9ptdfu43ddfg98ru39df9sdf3flkosw
  • нажимаем “Создать фильтр в соответствии с этим запросом”
  • на второй части создания фильтра ставим галочку возле “Никогда не отправлять в спам”
  • нажимаем кнопку “создать фильтр”

Все, теперь все письма будут приходить минуя спам фильтр, останется только предупреждение о спаме при открытии письма через web

 

ввод компьютера в домен Active Directory без связи с доменом

Автономный ввод в домен Active Directory

Илья Рудь

Хотелось бы поделиться новой возможностью появившейся с выходом Windows 7 и Windows Server 2008 R2. В оригинале называется она – «offline domain join». Спорить о том, как правильно перевести на родной язык данный термин можно долго. Я остановился на варианте «автономный ввод в домен». В чем суть? Она проста. Если при введении предыдущих версий ОС в домен вам было необходимо иметь сетевое соединение с контроллером домена, то при вводе Windows 7/2008 R2 это не обязательно. Сфера применения данной возможности мне пока ясна не до конца, если у вас есть мысли, прошу поделиться в комментариях. Будем считать, что вы администрируете два леса Active Directory, не связанных между собой. Перед вами стоит задача настроить рабочую станцию, отправить ее в другой филиал и соответственно в другой лес AD. И естественно вы хотите сделать так, чтобы по приезду в место назначения этот компьютер можно было подключить в сеть и начать работать.

Важно: Для
использования «offline domain join» не нужно поднимать режим работы домена
или леса. Более того, не нужно иметь контроллеры домена Windows 2008 или 2008
R2. Для «Автономного
ввода в домен» используется утилита «djoin»,
которая присутствует в Windows 7/2008 R2. Т.е достаточно хотя бы одного
компьютера Windows 7/2008 R2, работающего в домене назначения.

Логика работы «Автономного ввода в домен»

1. На любом контроллере Windows 2008 R2 или клиентском
Windows 7 в домене назначения запускаем утилиту «djoin» со следующими ключами:

djoin /provision
/domain itband.ru /machine Win7-PC /dcname DC-SQL2005 /downlevel /savefile C:\blob.txt


itband.ru
– имя вашего домена


Win7-PC
– имя клиентского компьютера, который должен автономно
войти в домен


DC-SQL2005
– имя контроллера домена

/downlevel – ключ указывается, если у вас контроллер домена
Windows Server 2003

C:\blob.txt
путь к файлу с метаданными

После ввода данной команды формируется текстовый файл
содержащий необходимые данные для того, чтобы компьютер мог войти в домен
(информация об имени домена, контроллера домена, SID домена и т.д.) Плюс к
этому, в Active Directory создается объект «компьютер» для будущего клиента. Файл в
кодировке base64. Подробней
о данном файле.

Рис. 1. Первый шаг,
использование Djoin

2. Вторым шагом необходимо доставить данный файл blob.txt на компьютер, который должен
автономно войти в домен. Какими средствами вы это сделаете, зависит от вас.
Хоть по почте пересылайте.

3. Доставив данный файл на клиентский компьютер, необходимо
запустить командную строку и выполнить «djoin» со следующими ключами:

djoin /requestODJ
/loadfile C:\blob.txt /windowspath
%SystemRoot% /localos

Произойдет импортирование данных из файла в каталог Windows.
Теперь при следующей загрузке операционной системы и доступности контроллера у
вас будет возможность войти в домен Active Directory.

Рис. 2. Третий шаг,
использование Djoin

С одной стороны функционал более чем интересный, с другой
появляется гипотетическая возможность того, что кто-то сможет перехватить или
завладеть таким файлом «Приглашением» и включить свой компьютер в домен, не
имея никаких на это прав. Или это просто паранойя?

На текущий момент информации по «offline domain join» очень
мало. В частности я не смог найти, есть ли какой-то срок жизни у такого
файла-приглашения. Хотя если рассуждать логически, можно предположить, что он
(срок жизни) равен сроку жизни пароля объекта «компьютер». Оригинальная
информация на английском языке
.

оригинал статьи