При присоединении к домену произошла следующая ошибка не удается завершить выполнение функции

Не удается выполнить присоединение к домену так как ид безопасности этого домена совпадает

Сообщения: 86
Благодарности: 2

При попытке подключения компьютера с Win7Ultimate в домен выдает ошибку:
Не удалось выполнить операцию присоединения. Это может быть вызвано тем, что существующая учетная запись компьютера с именем «Qwerty» была изначально создана с использованием других учетных данных. Либо используйте другое имя компьютера, либо попросите администратора удалить устаревшие конфликтующие учетные записи. ошибка: Отказано в доступе.

ИД безопасности домена совпадает с ИД безопасности компьютера ⁠ ⁠

Бывает, что вы клонируете вируталки а потом их нужно подключить к домену.

и выдает ошибку:

запустить командную строку с правами Администратора,

C:WindowsSystem32SysprepSysprep.exe /oobe /generalize

Там же, блядь, в ошибке написано что случилось и что делать. К чему этот пост?

Вот тебе ещё лайфхак. Перед созданием шаблона, запусти sysprep с выключением компьютера. Потом снимаешь шаблон и при развертывании не надо будет каждый раз делать эту команду

То есть пост о решении проблемы. решение которой прямо написано в самой ошибке?

Вот давайте хоть на Пикабу AD для чайников не разводить

Мдя. Какова будет тема следующего поста? Параметры команды ping?

Когда поднимаешь виртуалку в hyper-v просто указываешь — создать уникальный ид и все.

Еще полезный совет: держишь 5 секкунд кнопку ВКЛ на корпусе сервера и тишинааааа

.local так-то не рекомендуют использовать

/проверил, точно ли я на Пикабу/

Проброс видеокарты в виртуальную машину (копия с Хабра)⁠ ⁠

1. Вступление

Две разные системы (win + linux) на одной аппаратной базе — реальность. В этом нет ничего нового или инновационного (на данный момент времени), но если требуется максимальная производительность гостевой системы, то не обойтись без проброса реальных устройств в виртуальную машину. Проброс сетевых карт, usb-контроллеров (etc) экстраординарных особенностей не несёт, а вот попытка «шаринга» ресурсов видеокарты и процессора вполне может принести некоторое количество проблем.

Итак, а для чего, собственного говоря, городить системы с полнофункциональным использованием ресурсов GPU и CPU? Самый простой и очевидный ответ — игры (широко известный факт — если не большинство, то очень многие, написаны под ОС Windows). Другой вариант — полноценное рабочее место с возможностью запуска требовательных приложений (например, CAD-софта), быстрым бэкапом (скопировать файл ВМ куда проще, чем создавать полную копию HDD/SSD) и опцией полного контроля сетевого трафика гостевой системы.

2. Аппаратная часть

Процессор: Intel(R) Core(TM) i5-9400F CPU @ 2.90GHz

Материнская плата: ASRock Z390 Phantom Gaming 4S

Видеокарта 0 (для проброса в ВМ): Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X]

Видеокарта 1 (для хост-системы): Park [Mobility Radeon HD 5430]

USB-контроллер (для проброса в ВМ и последующего подключения периферийных устройств, например, клавиатуры): VIA Technologies, Inc. VL805 USB 3.0 Host Controller

3. Настройки ОС

В качестве хост-системы выбрана ОС AlmaLinux 8 (вариант установки«Server with GUI»). Долгое время пользовался CentOS 7/8, поэтому, думаю, выбор тут очевиден.

Первое, что необходимо сделать, — это ограничить использование видеокарты, предназначенной для использования в ВМ, хост-системой. Для этого применяем ряд команд и настроек:

1) с помощью команды «lspci -nn | grep RX» получаем уникальные идентификаторы видеокарты. Т. к. видеокарта RX-серии, то, соответственно, ищем в выводе lspci (утилита устанавливается посредством команды «dnf install pciutils») по этим двум символам. Вывод получим примерно такой (выделенные подстроки — это и есть искомые идентификаторы устройств) —

«02:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X] [1002:699f] (rev c7)

02:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Baffin HDMI/DP Audio [Radeon RX 550 640SP / RX 560/560X] [1002:aae0]», где 1002:699f — идентификатор VGA-контроллера, а 1002:aae0 — встроенной аудиокарты. Также запоминаем идентификаторы «02:00.0» и «02:00.1»;

2) добавив к команде «lspci -nn» ключ «k» («lspci -nnk») находим в выводе устройство «1002:699f» и запоминаем значение «Kernel driver in use». В моём случае — это «amdgpu»;

3) в файле «/etc/default/grub» находим строку, начинающуюся с «GRUB_CMDLINE_LINUX», и добавляем после «quiet» значения «intel_iommu=on iommu=on rd.driver.pre=pci-stub pci-stub.ids=1002:67ff,1002:aae0», где «intel_iommu / iommu» – параметры, отвечающие за поддержку технологии IOMMU (технология взаимодействия виртуальных машин с реальным оборудованием), «rd.driver.pre=pci-stub» — указание на принудительную первоочередную загрузку фиктивного драйвера pci-sub, «pci-stub.ids» — перечисление устройств, для которых при загрузке ядра необходимо использовать фиктивный драйвер (т.е. происходит изоляция устройств для дальнейшего использования в виртуальных машинах). Если на хост-машине используется CPU от AMD, то «intel_iommu» меняем на «amd_iommu»;

4) в файл «/etc/modprobe.d/local.conf» добавляем строки «blacklist amdgpu» и «options pci-stub ids=1002:699f,1002:aae0», где «blacklist amdgpu» — явное указание на запрет использования драйвера AMD для графических устройств, а «options pci-stub ids=1002:699f,1002:aae0» — явное указание на использование фиктивного драйвера для соответствующих идентификаторов устройств;

5) выполняем команду «grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg» (т.е. пересоздаём конфигурационный файл загрузчика GRUB). Если речь не про EFI-загрузку, то команда выглядит так — «grub2-mkconfig -o /boot/grub2/grub.cfg»;

6) выполняем команду «dracut —regenerate-all —force» для пересоздания образа initramfs (initial RAM disk image, загружаемый в оперативную память файл с образом файловой системы), используемого при загрузке Linux в качестве первоначальной корневой файловой системы;

7) перезагружаем хост виртуализации.

Смысл этих настроек в том, чтобы ограничить использование определённых устройств при загрузке. Например, до прописания параметров в выводе команды «lspci -v» для VGA-контроллера будет присутствовать подстрока «Kernel driver in use: amdgpu», а после перезагрузки – «Kernel driver in use: pci-stub». При старте же ВМ с Windows (и после проброса устройств) – “Kernel driver in use: vfio-pci” (в чём можно убедиться после запуска созданной ВМ). Важный момент — используемая для хост-системы видеокарта должна использовать драйвера, отличные от используемых для пробрасываемой видеокарты, например, в моём случае используется «Radeon HD 5430», драйвер для которой — это «radeon» (в выводе «lspci -v» – «Kernel driver in use: radeon»).

4. Установка софта для виртуализации

1) «dnf install epel-release».

2) «dnf install qemu-kvm qemu-img libvirt virt-install libvirt-client virt-viewer virt-manager seabios numactl perf cockpit cockpit-machines xauth virt-top libguestfs-tools».

4) Optional. «dnf install perl» (Perl – one love).

5. Настройки ВМ QEMU-KVM via virt-manager

Предварительно скачиваем iso-образ Windows 10 и драйвера Virtio от RedHat (тоже в виде iso-образа).

При первоначальной установке всегда ставим галочку «Customize configuration before install».

1) Указываем iso-образ устанавливаемой операционной системы (например, Windows 10). Также добавляем дополнительное устройство вида «CD-ROM» и монтируем в доп. устройство iso-образ с драйверами Virtio.

2) Для виртуального HDD (куда планируется установка ОС) выставляем: «Bus type = Virtio». Тип виртуального диска — qcow2 или raw.

3) Для более эффективной работы размещаем основной виртуальный диск для ВМ на SSD.

4) Модель сетевой карты — virtio.

5) Overview: chipset = “Q35”, firmware = “UEFI x86_64: /usr/share/OVMF/OVMF_CODE.secboot.fd”.

6) OS Information: Operation System = “Microsoft Windows 10”.

7) CPU (соответствующие блоки в XML должны выглядеть именно так, если речь про аналогичную аппаратную конфигурацию):

Удаляем из конфигурации ВМ: «Tablet», «Display VNC», «Channel qemu-ga», «Video VGA».

9) Добавляем (через «Add Hardware → PCI Host Device») нужные устройства (VGA-контроллер, встроенный в видеокарту аудиконтроллер и отдельный USB-контроллер), ориентируясь на выделенный идентификатор «02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X] (rev c7)» (пример вывода «lspci»).

10) Подключаем монитор к проброшенной видеокарте, а «мышь» с клавиатурой — к проброшенному USB-контроллеру.

11) Запускаем процесс установки («Begin installation»). В процессе установки указываем инсталлятору на образ Virtio в качестве драйвер-источника для HDD.

12) После установки заходим в диспетчер задач и для неизвестных устройств указываем в качестве драйвер-источника диск с Virtio. Также инсталлируем драйвера видеокарты.

Если всё сделано правильно, то в диспетчере задач Windows вы увидите реальную видеокарту и 4 ядра CPU с расшаренными ресурсами процессора (Кэш L1 + L2 + L3).

Устранение неполадок с присоединением к домену с помощью управляемого домена доменных служб Azure Active Directory

При попытке присоединить виртуальную машину или подключить приложение к управляемому домену доменных служб Azure Active Directory (Azure AD DS) может появиться сообщение о том, что операцию выполнить не удается. Чтобы устранить проблемы с присоединением к домену, определите, на каком из перечисленных этапов они возникают:

• Если вы не получаете запрос проверки подлинности, виртуальная машина или приложение не смогут подключиться к управляемому домену Azure AD DS.
  • Начните устранять неполадки подключения при присоединении к домену.
  • Начните устранять неполадки, связанные с учетными данными во время присоединения к домену.

  Проблемы подключения при присоединении к домену

  Если виртуальная машина не может найти управляемый домен, обычно это связано с сетевым подключением или настройками. Чтобы найти и устранить проблему, выполните следующие действия:

  1. Убедитесь, что виртуальная машина подключена к той же или одноранговой виртуальной сети, что и управляемый домен. В противном случае виртуальная машина не сможет найти домен и подключиться к нему для присоединения.
     • Если виртуальная машина не подключена к той же виртуальной сети, убедитесь, что пиринг между виртуальными сетями или VPN-подключение активны или подключены, чтобы трафик правильно перенаправлялся.
  2. Выполните проверку связи по DNS-имени управляемого домена, например ping aaddscontoso.com .
     • Если ответ на запрос проверки связи не приходит, попробуйте проверить связь с IP-адресами домена, отображаемого на странице обзора на портале управляемого домена, например ping 10.0.0.4 .
     • Если есть связь с IP-адресом, но не с доменом, это может указывать на неправильную настройку DNS. Убедитесь, что для виртуальной сети настроены DNS-серверы управляемого домена.
  3. Попробуйте очистить кэш сопоставителя DNS на виртуальной машине, например ipconfig /flushdns .

  Настройка группы безопасности сети

  При создании управляемого домена также создается группа безопасности сети с соответствующими правилами для надлежащей работы домена. Если вы изменяете или создаете дополнительные правила группы безопасности сети, вы можете непреднамеренно заблокировать порты, которые Azure AD DS использует для подключения и проверки подлинности. Эти правила группы безопасности сети могут вызывать такие проблемы, как ошибка синхронизации паролей, ошибка входа пользователей в систему или проблемы с подключением к домену.

  Если проблемы с подключением продолжают возникать, выполните следующие действия по устранению неполадок:

  1. Проверьте работоспособность управляемого домена на портале Azure. Если у вас есть оповещение для AADDS001, правило группы безопасности сети блокирует доступ.
  2. Проверьте необходимые порты и правила группы безопасности сети. Убедитесь, что ни одно из правил группы безопасности сети, которые не применяются к виртуальной машине или виртуальной сети, из которых выполняется подключение, не блокирует эти сетевые порты.
  3. После устранения проблем с конфигурацией группы безопасности сети предупреждение AADDS001 исчезнет со страницы работоспособности примерно через 2 часа. Когда сетевое подключение станет доступно, попробуйте присоединить виртуальную машину к домену еще раз.

  Проблемы с учетными данными во время присоединения к домену

  Если появится диалоговое окно с запросом учетных данных для присоединения к управляемому домену, виртуальная машина сможет подключиться к домену с помощью виртуальной сети Azure. Процесс присоединения к домену завершается сбоем при проверке подлинности в домене или о время авторизации на домене с использованием введенных учетных данных.

  Чтобы устранить неполадки, связанные с учетными данными, выполните следующие действия:

  1. Для указания учетных данных рекомендуется использовать формат имени участника-пользователя, например dee@contoso.onmicrosoft.com . Убедитесь, что имя участника-пользователя правильно настроено в Azure AD.
     • Имя для входа в формате SAMAccountName для вашей учетной записи может создаваться автоматически, если в клиенте зарегистрировано несколько пользователей с одинаковым префиксом имени участника-пользователя или если этот префикс слишком длинный. Таким образом, имя для входа в формате SAMAccountName для вашей учетной записи может отличаться от ожидаемого или используемого в локальном домене.
  2. Попробуйте использовать данные учетной записи пользователя, которая входит в управляемый домен, для присоединения виртуальных машин к управляемому домену.
  3. Убедитесь, что вы включили синхронизацию паролей и подождали достаточно долго, чтобы начальная синхронизация паролей завершилась.

  Дальнейшие действия

  Дополнительные сведения о процессе присоединения к домену в Active Directory см. в разделе Проблемы с соединением и проверкой подлинности.

  Если у вас по-прежнему возникают проблемы при присоединении виртуальной машины к управляемому домену, перейдите в раздел справки и отправьте запрос в службу поддержки для Azure Active Directory.