Комментарии 21
Добавлю, что нельзя клонировать машины для развертывания на них Exchange Server без sysprep со сменой SID. Сталкивались, проблемы, не делайте так.
Кроме того, был возможен следующий сценарий для рабочих групп — две машины с одинаковым SID, локальные администраторы с разными паролями. Локальный администратор каждой машины может открывать административные сетевые ресурсы другой машины.
Так же можно вспомнить, что у VMware есть утилита quickprep для «генерализации» виртуальной машины без смены локального SID. Используется с linked clone. Для большинства сценариев вполне работоспособна.
Проблемы с WSUS мне не встречались, есть старая статья support.microsoft.com/en-us/kb/903262, в которой говорится что проблемы с WSUS связаны не с SID, а процессом генерализации.
Кроме того, был возможен следующий сценарий для рабочих групп — две машины с одинаковым SID, локальные администраторы с разными паролями. Локальный администратор каждой машины может открывать административные сетевые ресурсы другой машины.
Так же можно вспомнить, что у VMware есть утилита quickprep для «генерализации» виртуальной машины без смены локального SID. Используется с linked clone. Для большинства сценариев вполне работоспособна.
Проблемы с WSUS мне не встречались, есть старая статья support.microsoft.com/en-us/kb/903262, в которой говорится что проблемы с WSUS связаны не с SID, а процессом генерализации.
Коротко и ясно.
Пара вопросов, если можно:
1. Добавление к рабочей группе будет сопроваждаться добавлением машине «Domain SID»? И если да, то где он будет храниться, только на самой машине?
2. В чем разница между рабочей группой и домашней группой, в контексте «Domain SID»?
Спасибо.
Пара вопросов, если можно:
1. Добавление к рабочей группе будет сопроваждаться добавлением машине «Domain SID»? И если да, то где он будет храниться, только на самой машине?
2. В чем разница между рабочей группой и домашней группой, в контексте «Domain SID»?
Спасибо.
Спасибо за отзыв.
1. Нет — domain SID свойство исключительно домена (это идентификатор аккаунта компьютера в рамках домена), поэтому добавление в рабочую группу на него не влияет. Логин на любой компьютер в рабочей группе осуществляется исключительно локальными аккаунтами.
2. Как следует из п.1, разницы никакой нет в данном контексте.
1. Нет — domain SID свойство исключительно домена (это идентификатор аккаунта компьютера в рамках домена), поэтому добавление в рабочую группу на него не влияет. Логин на любой компьютер в рабочей группе осуществляется исключительно локальными аккаунтами.
2. Как следует из п.1, разницы никакой нет в данном контексте.
Вспоминая свое далекое доадминское прошлое. И о том как делать не нужно :).
Удаленный офис. Рабочая машина с переустановленной «с нуля» виндой. Создается локальный аккаунт с административными правами, с аналогичным доменному логином и паролем. Далее путем нехитрой социальной инженерии компьютер загоняется в домен. И вуаля. Недавний студент, ничего не понимающий в MS AD, процессе аутентификации и прочих страшных словах, имеет одновременно нормальный доступ ко всем доменным ресурсам и полноценный локальный админский аккаунт на своем рабочем ПК.
Что говорит о том, что по крайне мере в Win Server 2000 в AD с sid-ами все было не так уж и уникально :).
Удаленный офис. Рабочая машина с переустановленной «с нуля» виндой. Создается локальный аккаунт с административными правами, с аналогичным доменному логином и паролем. Далее путем нехитрой социальной инженерии компьютер загоняется в домен. И вуаля. Недавний студент, ничего не понимающий в MS AD, процессе аутентификации и прочих страшных словах, имеет одновременно нормальный доступ ко всем доменным ресурсам и полноценный локальный админский аккаунт на своем рабочем ПК.
Что говорит о том, что по крайне мере в Win Server 2000 в AD с sid-ами все было не так уж и уникально :).
Если в наличии имелся аккаунт с «аналогичным доменному логином и паролем», то в чем цимес социальной инженерии для загона машины в домен? :)
В том что доменный аккаунт был аккаунтом доменного пользователя. А не админа домена. А из под пользователя машину в домен не загонишь.
А! Изначально прочитал, что локальный админский аккаунт создается с логином паролем аналогичным аккаунту домен админа, а не простого доменного пользователя. Спасибо за пояснение — тогда действительно красивый лайфхак получился!
Я немного врежусь в тред.
При дефолтных настройках контроллера домена на котором, расшарена папка с правами Everyone можно:
С ПК, находящегося в рабочей группе, на котором локальный пользователь (не важно админ или нет) имеет такой же логин и пароль как и у доменного пользователя (тобишь не имеющего административных прав в домене) — можно заходить на расшаренную папку на КД без ввода каких либо паролей.
ПК можно ввести в домен с правами обычного доменного пользователя, но требуется что бы были права локального админа на ПК. И совершить сиё действо можно не более 10 раз для доменного аккаунта без административных прав.
зыю
Я полагал ранее, что должна существовать учетная запись ПК в AD, и только тогда можно будет ввести ПК в домен под пользовательской учеткой, но токачто сделанное тестирование ради фана, показало, что учетная запись ПК созданная заранее не обязательна.
Server 2012 R2 + Win7 Pro
При дефолтных настройках контроллера домена на котором, расшарена папка с правами Everyone можно:
С ПК, находящегося в рабочей группе, на котором локальный пользователь (не важно админ или нет) имеет такой же логин и пароль как и у доменного пользователя (тобишь не имеющего административных прав в домене) — можно заходить на расшаренную папку на КД без ввода каких либо паролей.
ПК можно ввести в домен с правами обычного доменного пользователя, но требуется что бы были права локального админа на ПК. И совершить сиё действо можно не более 10 раз для доменного аккаунта без административных прав.
зыю
Я полагал ранее, что должна существовать учетная запись ПК в AD, и только тогда можно будет ввести ПК в домен под пользовательской учеткой, но токачто сделанное тестирование ради фана, показало, что учетная запись ПК созданная заранее не обязательна.
Server 2012 R2 + Win7 Pro
Дефолтные настройки домена AD — авторизованный пользователь может добавить до 10 компьютеров и без наличия админских привилегий.
Поддерживаю предыдущего оратора — где именно тут «социальная инжинерия»?
Поддерживаю предыдущего оратора — где именно тут «социальная инжинерия»?
1. загонишь до 10 раз. на момент 2003 и насколько помню и далее.
2. такие фишки устраняются легко политикой сброса локальных админов и установкой своих, и после перезагрузки вы идете опять устанавливать винду и применять социалку. на 3-4 итерации вас «погладят по головке». Хотите иметь админ доступ к тачке — лично у меня такое правило — хотите, получите, но мне не звоните по вопросам «че то у меня не работает ....». Покупаете тортик/пиво/одеваете платье с глубоким вырезом (последнее только если вы очаровательная девушка) и идете социалить к админу.
2. такие фишки устраняются легко политикой сброса локальных админов и установкой своих, и после перезагрузки вы идете опять устанавливать винду и применять социалку. на 3-4 итерации вас «погладят по головке». Хотите иметь админ доступ к тачке — лично у меня такое правило — хотите, получите, но мне не звоните по вопросам «че то у меня не работает ....». Покупаете тортик/пиво/одеваете платье с глубоким вырезом (последнее только если вы очаровательная девушка) и идете социалить к админу.
как быстро откомментили, опять же 1 пункт легко устраняется групповыми политиками, ибо зоопарк надоедает через полгода
Пункт 1 работает на самом деле начиная с Win Server 2000. Но исходя из того что из под «обычного доменного пользователя» PC в домен не добавлялся, админы организации были не совсем «просты» :). И по всей видимости параметр ms-DS-MachineAccountQuota скорректирован :).
Удивляет то, что суть коммента была про «неправильное» получение прав локального админа на своем PC обычным пользователем AD, но всех комментирующих задело за больное всего одна фраза, имеющая косвенное отношение к делу.
Да и описываемые события происходили 1,5 десятка лет назад как минимум.
Удивляет то, что суть коммента была про «неправильное» получение прав локального админа на своем PC обычным пользователем AD, но всех комментирующих задело за больное всего одна фраза, имеющая косвенное отношение к делу.
Да и описываемые события происходили 1,5 десятка лет назад как минимум.
НЛО прилетело и опубликовало эту надпись здесь
Кстати, если у Лады приварить колёса, вместо того что бы завернуть болты, она тоже поедет.
НЛО прилетело и опубликовало эту надпись здесь
Один раз настроить MDT.
НЛО прилетело и опубликовало эту надпись здесь
WIM там трогать не приходится. К примеру, обновления обычно интегрируют через Sysprep and Capture, который легко заскриптовать.
Не стоит клонировать/развёртывать образ машины, которая УЖЕ добавлена в домен
Зависит от ПО. В VMware View у вас не будет работать создавание клонов (Full и Linked), если шаблон не был добавлен в домен перед этим.
Займусь некропостингом:
еще один повод сменить sid.
Если вдруг вы решите купить лицензию на avira endpoint, то с удивлением обнаружите, что лицензии учитываются по sid, а не по имени компьютера. При этом в тапки может влезть только один. В результате в лицензионном центре отображается только один комп (у меня 2 записи, вместо 4), на один sid, а лицензия подхватывается только на последнем активированном ПК.
еще один повод сменить sid.
Если вдруг вы решите купить лицензию на avira endpoint, то с удивлением обнаружите, что лицензии учитываются по sid, а не по имени компьютера. При этом в тапки может влезть только один. В результате в лицензионном центре отображается только один комп (у меня 2 записи, вместо 4), на один sid, а лицензия подхватывается только на последнем активированном ПК.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Смена SID при клонировании и массовом развёртывании