не удается выполнить присоединение к домену так как ид безопасности этого домена совпадает
Устранение неполадок с присоединением к домену с помощью управляемого домена доменных служб Azure Active Directory
При попытке присоединить виртуальную машину или подключить приложение к управляемому домену доменных служб Azure Active Directory (Azure AD DS) может появиться сообщение о том, что операцию выполнить не удается. Чтобы устранить проблемы с присоединением к домену, определите, на каком из перечисленных этапов они возникают:
Проблемы подключения при присоединении к домену
Если виртуальная машина не может найти управляемый домен, обычно это связано с сетевым подключением или настройками. Чтобы найти и устранить проблему, выполните следующие действия:
Настройка группы безопасности сети
При создании управляемого домена также создается группа безопасности сети с соответствующими правилами для надлежащей работы домена. Если вы изменяете или создаете дополнительные правила группы безопасности сети, вы можете непреднамеренно заблокировать порты, которые Azure AD DS использует для подключения и проверки подлинности. Эти правила группы безопасности сети могут вызывать такие проблемы, как ошибка синхронизации паролей, ошибка входа пользователей в систему или проблемы с подключением к домену.
Если проблемы с подключением продолжают возникать, выполните следующие действия по устранению неполадок:
Проблемы с учетными данными во время присоединения к домену
Если появится диалоговое окно с запросом учетных данных для присоединения к управляемому домену, виртуальная машина сможет подключиться к домену с помощью виртуальной сети Azure. Процесс присоединения к домену завершается сбоем при проверке подлинности в домене или о время авторизации на домене с использованием введенных учетных данных.
Чтобы устранить неполадки, связанные с учетными данными, выполните следующие действия:
Дальнейшие действия
Дополнительные сведения о процессе присоединения к домену в Active Directory см. в разделе Проблемы с соединением и проверкой подлинности.
Если у вас по-прежнему возникают проблемы при присоединении виртуальной машины к управляемому домену, перейдите в раздел справки и отправьте запрос в службу поддержки для Azure Active Directory.
ИД безопасности домена совпадает с ИД безопасности компьютера
Бывает, что вы клонируете вируталки а потом их нужно подключить к домену.
запустить командную строку с правами Администратора,
C:\Windows\System32\Sysprep\Sysprep.exe /oobe /generalize
Вот тебе ещё лайфхак. Перед созданием шаблона, запусти sysprep с выключением компьютера. Потом снимаешь шаблон и при развертывании не надо будет каждый раз делать эту команду
То есть пост о решении проблемы. решение которой прямо написано в самой ошибке?
Вот давайте хоть на Пикабу AD для чайников не разводить
Мдя. Какова будет тема следующего поста? Параметры команды ping?
Еще полезный совет: держишь 5 секкунд кнопку ВКЛ на корпусе сервера и тишинааааа
.local так-то не рекомендуют использовать
/проверил, точно ли я на Пикабу/
Механизм самоуничтожения в Linux — это самоуверенность пользователя
Windows 95
Всем привет, попались в руки два очень интересных аппарата.
первый: travelmate 4000m
Скелетор — линуксоид
Тэги к хорошо зашедшему на Пикабу посту намекают: Гений заработал за три дня 3 миллиарда. Для этого пришлось обмануть целую страну, но и вы бы ему поверили. В любом случае, было интересно покопаться в источниках и каналах распространения этой сатирической (для ЛЛ) новости, по которой вполне можно снять фильм в стиле «Друзей Оушена».
В конце мая 2021 года СМИ обошла новость о самозванце, который, представившись сотрудником Microsoft, убедил власти африканской страны заплатить ему огромную сумму в обмен на пожизненное обслуживание операционной системы. Мы проверили, так ли это было.
Каково же было удивление руководителей Зимбабве, когда через год Microsoft снова выставил им счёт. Политики поняли, что их обманули, связались с офисом корпорации и узнали, что никакого Джона Дусона там не знают. Более того, компания не отправляла своих сотрудников в командировку в Африку. Оказалось, что все работы Дусона сводились к обновлению Windows до десятой версии. Правда, такую возможность Microsoft предоставляла всем своим пользователям бесплатно и без помощи Дусона. На данный момент у политиков нет зацепок, где искать Джона, и полиция продолжает поиски. Офицеры считают, что Дусон, возможно, находится на территории Южной Африки.
С теми или иными деталями данный текст распространили такие русскоязычные ресурсы, как Medialeaks, Geekville, «Блокнот», iGiuides и ряд других сайтов. Некоторые из них ссылались на публикацию на англоязычном ресурсе bokdaily, из которой позаимствовали и фотографию афериста, так что источник информации следует искать за рубежом.
Как минимум на четырёх зарубежных ресурсах (bok daily, MadyCap, Global Nea, Ihlayanews) один и тот же текст появился 24 мая, раньше, чем на каком-либо из российских сайтов. И больше нигде. Нет подобных новостей даже при поиске на зимбабвийском языке шона.
Более детальное изучение показывает, что раньше всего указанная новость была размещена именно на Global Nea, однако на практике это не имеет никакого значения.
Как вы, наверное, догадались, мы имеем дело с очередным сайтом сатирических новостей и его зеркалами. Самый известный подобный российский ресурс — ИА «Панорама»
(@ia.panorama) — не скрывает своей шуточной направленности, но и с ним нередко случаются казусы в виде перепечаток более серьёзными сайтами. Само собой, не обходит подобная судьба и материалы с Global Nea, где соответствующее предупреждение отсутствует.
Впрочем, внимательные читатели могли заподозрить, что новость о Зимбабве вымышлена, и по другим косвенным признакам. Например, очевидно, что в суверенной и относительно мирной стране должно быть официальное представительство Microsoft (пусть иногда и отвечающее сразу за несколько стран) и чиновникам не нужен «человек от Билла Гейтса». Кроме того, в наши дни подобные операции можно осуществить и в интернете — в частности, у корпорации есть страничка для проживающих в Зимбабве. Страна участвует и в других проектах, связанных с Microsoft.
Итак, новость, вызвавшая ажиотаж в ряде российских СМИ, как мы убедились, является сатирической.
Ещё нас можно читать в Телеграме, в Фейсбуке и в Вконтакте. Традиционно уточняю, что в сообществах отсутствуют спам, реклама и пропаганда чего-либо (за исключением здравого смысла), а в день публикуем не больше двух постов.
Смена SID при клонировании и массовом развёртывании
Привет, Хабр! Упомянутая в заголовке тема всё ещё порождает множественные дискуссии и недопонимание между системными администраторами. В своей статье я постараюсь ответить на следующие вопросы:
В основу рассуждений была взята популярная статья Марка Руссиновича (доступна также на русском языке), которую довольно часто неправильно интерпретируют (судя по комментариям и «статьям-ответам»), что приводит к неприятным последствиям. Добро пожаловать под кат.
Что такое SID, его типы и чем отличается Machine SID от Domain SID?
В первую очередь, важно различать SID компьютера (Machine SID) и SID домена (Domain SID), которые являются независимыми и используются в разных операциях.
Machine SID и Domain SID состоят из базового SID’а (base SID) и относительного SID’а (Relative SID = RID), который «приклеивается» в конец к базовому. Базовый SID можно рассматривать как сущность, в рамках которой можно определить группы и аккаунты. Машина (компьютер) является сущностью, в рамках которой определяются локальные группы и аккаунты. Каждой машине присваивается machine SID, и SID’ы всех локальных групп и аккаунтов включают в себя этот Machine SID с добавлением RID в конце. Для примера:
| Machine SID для машины с именем DEMOSYSTEM | S-1-5-21-3419697060-3810377854-678604692 |
| DEMOSYSTEM\Administrator | S-1-5-21-3419697060-3810377854-678604692-500 |
| DEMOSYSTEM\Guest | S-1-5-21-3419697060-3810377854-678604692-501 |
| DEMOSYSTEM\CustomAccount1 | S-1-5-21-3419697060-3810377854-678604692-1000 |
| DEMOSYSTEM\CustomAccount2 | S-1-5-21-3419697060-3810377854-678604692-1001 |
Именно SID’ы (а не имена) хранятся в токенах доступа (access tokens) и дескрипторах безопасности (security descriptors), и именно SID’ы используются при проверке возможности доступа к объектам системы Windows (в том числе, например, к файлам).
На машине вне домена используются локальные SID’ы, описанные выше. Соответственно, при соединении с машиной удалённо используется локальная аутентификация, поэтому даже имея 2 или более машин с одинаковым machine SID в одной сети вне домена, проблем с логином и работой внутри системы не будет, т.к. SID’ы в операциях удалённой аутентификации попросту не используются. Единственный случай, в котором возможны проблемы, это полное совпадение имени пользователя и пароля на двух машинах – тогда, например, RDP между ними может глючить.
Когда машина добавляется в домен, в игру вступает новый SID, который генерируется на этапе добавления. Machine SID никуда не девается, так же как и локальные группы, и пользователи. Этот новый SID используется для представления аккаунта машины в рамках домена. Для примера:
| Domain SID для домена BIGDOMAIN | S-1-5-21-124525095-708259637-1543119021 |
| BIGDOMAIN\DEMOSYSTEM$ (аккаунт машины (computer account)) | S-1-5-21-124525095-708259637-1543119021-937822 |
| BIGDOMAIN\JOHNSMITH (аккаунт пользователя (user account)) | S-1-5-21-124525095-708259637-1543119021-20937 |
Таким образом, машина DEMOSYSTEM теперь имеет два независимых SID’а:
• Machine SID, определяющая машину как сущность, в рамках которой заданы группы и аккаунты (первая строчка в первой таблице).
• SID аккаунта машины (computer account SID) в рамках домена BIGDOMAIN (вторая строчка во второй таблице).
Основная суть в том, что SID’ы должны быть уникальны в пределах окружения (authority), к которому они применимы. Другими словами, если машине DEMOSYSTEM присвоен machine SID S-1-5-21-3419697060-3810377854-678604692-1000, то неважно, что у другой машины в той же сети будет идентичный machine SID, т.к. этот SID используется только локально (в пределах машины DEMOSYSTEM). Но в пределах домена BIGDOMAIN computer SID у обоих машин должен быть уникальным для корректной работы в этом домене.
Смена SID при клонировании или развёртывании
В применении к продукту Acronis Snap Deploy 5 (основное предназначение — массовое развёртывание систем из мастер-образа), в котором функциональность смены SID-а присутствовала с самой первой версии, это означает, что мы, как и многие пользователи, ошибочно пошли на поводу у устоявшегося мнения, что менять SID нужно.
Однако исходя из вышесказанного, ничего страшного в развёртывании (или клонировании) машины без изменения Machine SID вовсе нет, в случае если это развёртывание происходит до добавления машины в домен. В противном случае — возникнут проблемы.
Из этого правила есть одно исключение: нельзя клонировать машину, если в дальнейшем роль этого клона планируется повышать (promote) до уровня домена контроллера. В этом случае Machine SID домен контроллера будет совпадать с computer SID в созданном домене, что вызовет проблемы при попытке добавления оригинальной машины (из которой производилось клонирование) в этот домен. Это, очевидно, относится только к серверному семейству Windows.
Проблемы, связанные со сменой SID
Пересмотреть точку зрения на функциональность смены SID нас подтолкнул выпуск новой версии Windows. При первом тестовом развёртывании образа Windows 10 со сменой SID на получившейся машине обнаружилось, что кнопка Start перестала нажиматься (и это оказалось только вершиной «айсберга»). Если же развёртывать тот же образ без смены SID, то такой проблемы не возникает.
Основная причина в том, что эта опция вносит изменения практически во всю файловую систему развёртываемой машины. Изменения вносятся в реестр Windows, в разрешения NTFS (NTFS permissions) для каждого файла, в SID’ы локальных пользователей (так как SID пользователя включает в себя в том числе и machine SID; подробнее тут) и т.д.
В случае с Windows 10 большая часть ключей реестра не могла быть модифицирована («Error code = C0000005. Access violation» и другие ошибки) и, как следствие, наша функция смены SID’а отрабатывала не до конца, что и приводило к трагической гибели практически нерабочей копии Windows 10.
Было принято решение убрать эту опцию в случае, если в мастер-образе мы находим Windows 10 (или Windows Server 2016). Решение было принято на основе теоретических выкладок описанных выше плюс, естественно, было подтверждено практикой при тестировании недавно вышедшего обновления Acronis Snap Deploy 5 во множестве комбинаций: с и без переименования машин после развёртывания, с добавлением в домен и рабочую группу, развёртывание из мастер-образов снятых от разных состояний мастер-машины (она была добавлена в домен или рабочую группу в разных тестах) и т.д.
Использование Sysprep
Начиная с Windows NT клонирование (развертывание) ОСи с использованием только NewSID никогда не рекомендовалось самим Microsoft. Вместо этого рекомендуется использовать родную утилиту Sysprep (см. KB314828), которая, помимо смены SID’а, также вносит большое число других изменений, и с каждой новой версией Windows их становится только больше. Вот небольшой (неполный) список основных вносимых изменений:
Таким образом, клонирование/развертывание без использования Sysprep может повлиять (читай «скорее всего, сломает») на функциональность Windows Update, Network Load Balancing, MSDTC, Vista и выше Key Manager Activation (KMS), который завязан на CMID (не путать с Machine SID), также изменяемый Sysprep’ом, и т.д.
Итого
Повторяя TL;DR из начала статьи, основной вывод можно сделать такой: для подготовки образа машины к клонированию/развёртыванию следует использовать sysprep в подавляющем большинстве случаев. 
При присоединению к домену произошла ошибка: Совпадает ИД безопасности
Столкнулся с проблемой при клонировании виртуальных машин на VMWare ESXi. Сейчас опять наткнулся но уже с VMWare workstation. Возможно как-то клонировать машины необходимо по другому и возможно для этого существуют инструменты. Но в рамках этой статьи буду решать средствами виндовс
При присоединению к домену «xaxa» произошла следующая ошибка:
Не удаётся выполнить присоединение к домену, так как ИД безопасности этого домена совпадает с ИД безопасности данного компьютера. Это признак установки неправильно клонированной операционной системы. Чтобы создать новый ИД безопасности компьютера, запустите на этом компьютере программу Sysprep. Дополнительные сведения см. на веб-сайте http://go.microsoft.com/fwlink/?Linkid=168895
В решении этой проблемы нам поможет утилита SYSPREP
Ждём пока она завершит работу
Соглашаемся с лицензионным соглашением
Придумываем сложный админский пароль
После настроек авторизуемся в системе. Нам опять придётся указать имя компьютера и перезагрузиться.
Документация и ссылки по SYSPREP и NTDSUTIL для вкуривания:
сброс ИД безопасности Windows
| Снимок.JPG | |
| Описание: | |
| Размер файла: | 43.25 KB |
| Просмотрено: | 9160 раз(а) |
 _________________ Rossomaha [ ЗА IP БЕЗ ЦЕНЗУРЫ ] | |
Активный участник
Зарегистрирован: 24.11.2010
Пользователь #: 92,751
Сообщения: 1032
Rossomaha [ ЗА IP БЕЗ ЦЕНЗУРЫ ]
Зарегистрирован: 14.12.2006
Пользователь #: 48,281
Сообщения: 5244
Rossomaha [ ЗА IP БЕЗ ЦЕНЗУРЫ ]
Зарегистрирован: 22.06.2009
Пользователь #: 79,673
Сообщения: 1353
| newsid.rar | ||
| Описание: | Скачать | |
| Название файла (не более 120 мегов 1 файл): | newsid.rar | |
| Размер файла: | 58.5 KB | |
| Скачено: | 136 раз(а) | |
Зарегистрирован: 14.12.2006
Пользователь #: 48,281
Сообщения: 5244
- не удается выполнить операцию так как этот файл открыт в другой программе как удалить
- не удается выполнить чтение с файла или с диска что делать