Запрошенная операция не может быть завершена компьютер должен иметь доверие для делегирования
Не удается найти описание события с кодом 10837 из исходного MsiInstaller. Либо компонент, вызывающий это событие, не установлен на вашем локальном компьютере, либо установка повреждена. Вы можете установить или восстановить компонент на локальном компьютере.
Если событие возникло на другом компьютере, отображаемую информацию нужно было сохранить вместе с событием.
Следующая информация была включена в мероприятие:
Продукт: НАЗВАНИЕ НАШЕГО ПРОДУКТА -- Запрашиваемая операция не может будет завершена. Компьютер должен быть доверенным для делегирования и Текущая учетная запись пользователя должна быть настроена для разрешения делегирования.
После поиска выяснилось, что это вызвано недавно выпущенным исправлением безопасности для установщика Windows. Когда я удаляю KB2918614, программа установки снова начинает работать, и если я переустанавливаю KB2918614, MSI снова перестает работать.
ОБНОВЛЕНИЕ: это не похоже на проблему с удаленным выполнением WMI, так как это также происходит, когда мы пытаемся установить MSI удаленно с помощью Powershell, WinRM и командлета Invoke-Commmand -ComputerName TargetComputer . . Изменился способ работы установщика Windows в 2008 R2 после установки KB2918614, который теперь не позволяет пользовательскому действию завершить свою задачу.
Я бы попробовал разрешить делегирование, хотя бы в качестве эксперимента. Я подозреваю, что проблема связана не с доступом MSI к удаленным ресурсам, а с олицетворением (или нет) в различных частях установки. Чистое предположение, но установка перемещается между учетной записью пользователя и системной учетной записью во время установки, и, возможно, в среде домена происходит что-то, что требует делегирования для передачи на контроллер домена или от него, что-то в этом роде.
Мы разработали MSI и надеемся найти способ переписать его, чтобы обойти эту проблему для наших клиентов. Я проверил, не был ли файл заблокирован, но в свойствах файла не было параметра «Безопасность»: «Этот файл получен с другого компьютера» или «Разблокировать».
Мы также столкнулись с проблемами при удаленном выполнении MSI после применения этого обновления MS. Сегодня я разговаривал с представителем Microsoft, который сказал, что это известная проблема, над которой работают. Он сказал мне, что они надеются выпустить дополнительный патч, исправляющий это где-то в период с середины октября до начала ноября.
Я связался с Microsoft сегодня, и мне сказали, что найденное здесь исправление должно решить проблему: support2.microsoft. com/kb/3000988. Однако я вижу, что в ответе ниже проголосовали против. Кто-нибудь устанавливал этот патч, и у них он не работал?
Из того, что я понимаю,
Симптомы
- Следующее поведение происходит в Windows 8.1 и Windows Server 2012 R2 после установки MS14-066, KB2992611, KB3000850 или более новых обновлений, которые включают эти исправления.
- Такое же поведение также происходит во всех версиях Windows 10 и более поздних версиях Windows. Пользователи домена, которые впервые войдите на новый компьютер на сайте, который обслужил контроллер домена только для чтения (RODC), испытывают следующие ошибки и проблемы.
Решение
Убедитесь, что рабочие станции и серверы, присоединенные к домену, имеют доступ к RWDCs.
Запустите следующую командную строку, чтобы убедиться, что RWDC существует и находится в нормальном состоянии:
Используйте NETLOGON. ЖУРНАЛ и сетевой след с предоставленными примерами журнала в этой статье для проверки разрешения имен и подключения к RWDC.
Чтобы определить, столкнулись ли вы с этой проблемой, попробуйте открыть CREDMAN в панели управления. Если попытка не удается с ошибкой 0x80090345, вы проверили это.
По возможности перейдите на компьютер на сайт, на котором существует RWDC, а затем войдите в систему впервые. После этого будет создан мастер-кей DPAPI, и проблема будет решена.
Если у вас нет доступа к RWDC и если пользователь не будет перемещаться между машинами, для решения проблемы можно использовать следующую запись реестра.
Настройка этого значения до 1 вызывает локальное резервное копирование основных ключей DPAPI вместо использования резервного копирования домена. Кроме того, все ранее созданные клавиши не вызывают вызовы для контроллера домена, за исключением ограниченных случаев, как поясняется ниже. Этот параметр реестра применяется только к учетным записям домена. Локальные учетные записи всегда используют локальные резервные копии.
Не используйте этот ключ реестра, если пользователи домена войдите на более чем один компьютер! Так как клавиши отрабатываются локально, любое не локальное изменение пароля может вызвать ситуацию, в которой все клавиши DPAPI завернуты с помощью старого пароля, а затем восстановление домена невозможно. Этот ключ реестра следует устанавливать только в среде, в которой допустима потеря данных.
Справочники
Этот параметр политики определяет, какие пользователи могут установить параметр Доверенный для делегирования на объект пользователя или компьютера. Делегирование учетной записи безопасности обеспечивает возможность подключения к нескольким серверам, и каждое изменение сервера сохраняет учетные данные проверки подлинности исходного клиента. Делегирование проверки подлинности — это возможность, которую используют клиентские и серверные приложения, если у них несколько уровней. Это позволяет общедоступным службам использовать учетные данные клиента для проверки подлинности приложения или службы баз данных. Чтобы эта конфигурация была возможной, клиент и сервер должны работать под учетные записи, доверенные для делегирования.
Только администраторы, которым можно доверять учетным данным компьютера и пользователей, могут настроить делегирования. Администраторы домена и Enterprise администраторы имеют эти учетные данные. Процедура, позволяющая доверять пользователю для делегирования, зависит от уровня функциональности домена.
Пользователь или машинный объект, который получает это право, должен иметь доступ к флагам управления учетной записью. Серверный процесс, работающий на устройстве (или в пользовательском контексте), которому доверяется делегирование, может получить доступ к ресурсам на другом компьютере с помощью делегирования учетных данных клиента. Однако учетная запись клиента должна иметь доступ к флагам управления учетной записью на объекте.
Вопросы безопасности
В этом разделе описывается, каким образом злоумышленник может использовать компонент или его конфигурацию, как реализовать меры противодействия, а также рассматриваются возможные отрицательные последствия их реализации.
Групповая политика
Это право пользователя определяется в объекте групповой политики контроллера домена по умолчанию и в локальной политике безопасности рабочих станций и серверов.
Параметры применяются в следующем порядке с помощью объекта групповой политики (GPO), который перезаписывал параметры на локальном компьютере при следующем обновлении групповой политики:
- Параметры локальной политики
- Параметры политики сайта
- Параметры политики домена
- Параметры политики подразделения
Когда локальный параметр серый, он указывает, что GPO в настоящее время контролирует этот параметр.
Дополнительные сведения о настройке политики можно найти здесь.
Дополнительная информация:
Мой MSI закодирован через загрузчик exe. Но на самом деле это не имеет значения. Даже ручной вызов msiexec через строку cmd ведет себя так же.
Любые входы / решения, кто-нибудь?
Это слово от людей службы поддержки MS Enterprise.
Временное решение 1. Распространение хэша.
Захватите хэш-файл* на одном компьютере и распространите его на другие компьютеры. Хэш-файлы создаются в каталоге «%windir%\installer». Соглашение об именах выглядит следующим образом: «SourceHash * Этот файл создается только в том случае, если Продукт установлен с установленным на компьютере KB2918614. Этот каталог скрыт. Откройте приглашение cmd, используя «запуск от имени администратора». Перейдите по этому пути и откройте папку с помощью «проводника». команда. [Мне не удалось решить проблему с помощью этого подхода — возможно, потому, что для доступа к этому каталогу требуются права администратора, которых может не быть у самого установщика Windows]
Временное решение 2: внесение в белый список.
Только если вы доверяете приложению, что оно всегда имеет цифровую подпись и не содержит ничего вредоносного (даже в будущем).
Шаг 1. Включите белый список
В разделе «HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer» создайте DWORD: «SecureRepairPolicy» и установите для него значение 2.
Шаг 2. Добавьте приложение в белый список
Создайте новый ключ «SecureRepairWhitelist» в разделе «HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer» и создайте StringValues с кодами продукта (включая цветочные скобки <>) продукта.
. К сожалению, оба этих обходных пути требуют прав администратора!
Спасибо, мистер DebugBreak! Это действительно меня немного разогрело. Судя по всему, патч все равно пересматривается, так что нам (надеюсь) не придется возиться с этим материалом.
Вот мой автоматический способ использования белого списка реестра, упомянутого на сайте Microsoft.
Теперь, прежде чем запускать команду установки на удаленном компьютере, я просматриваю MSI и извлекаю код продукта с помощью Get-ProductCodeFromMSI, а затем использую Add-GuidToWhitelist для добавления каждого идентификатора GUID в список на этом компьютере. Вот пример:
Перед этим каждую машину можно протестировать и отремонтировать для обходного пути с помощью команд Test-SecureRepairPolicy и Repair-SecureRepairPolicy соответственно.
Get-ProductCodeFromMSI потребует, чтобы указанная DLL была размещена где-то и разблокирована — эту DLL можно получить из набора инструментов Wix.
Код функций, на которые я ссылаюсь, находится здесь:
Я тоже сталкиваюсь с проблемой. Я получил сценарий powershell для установки MSI на удаленных машинах (используя командлет Invoke-Command и предоставив учетные данные вместе со сценарием), но внезапно мне не удалось установить MSI, что, я полагаю, также из этого исправления безопасности.
После запуска установочного файла MSI вручную на целевом компьютере с использованием учетной записи домена (с удаленного рабочего стола) неожиданно сценарий powershell может запустить установку MSI с использованием учетной записи домена, но все равно не удалось установить, если я использовал локальную учетную запись администратора целевого компьютера.
Я предпочитаю добавить это как комментарий, но у меня недостаточно представителей для этого. Если у другого есть какое-либо решение или объяснение этого, я бы тоже хотел это знать. Спасибо.
Это должно быть сделано с файлами SourceHash в каталоге \windows\installer. Этот файл можно открыть с помощью Orca, вы можете прочитать его содержимое. Он содержит имя файла, спецификатор хеш-алгоритма и хэш. В Windows 2k3 этот хэш представляет собой хэш base64ed sha256 с измененным последним байтом.
Если вы переименуете файл SourceHash для своего продукта, я обнаружил, что обновление сработало, и после этого будет создан новый файл SourceHash. Затем вы можете сравнить два исходных хеш-файла. В случае, который я расследую, когда вы различаете два файла, отличается только хэш, указанный для исходного msi. После успешного обновления хэш нового msi, указанный в исходном хэш-файле, будет совпадать с хэшем источника установки. Сломанный файл исходного хэша, очевидно, был сгенерирован из модифицированного/другого исходного MSI, хотя я пока не смог определить, какой именно.
У меня точно такая же проблема. Не удалось установить MSI с помощью Invoke-Command PoSH. Я обнаружил, что если я устанавливаю любой MSI на сервер локально под той же учетной записью, которая используется для Invoke-Command, проблема устраняется, и Invoke-Command начинает работать как обычно.
Ответ Microsoft: Это обновление для системы безопасности устраняет обнаруженную пользователями уязвимость в Microsoft Windows. Эта уязвимость делает возможным несанкционированное получение прав, если злоумышленник запускает специально созданное приложение, которое пытается восстановить ранее установленное приложение. Злоумышленник должен иметь действительные учетные данные для входа в систему и иметь возможность локального входа в систему, чтобы воспользоваться этой уязвимостью.
Удалите приложение и переустановите его с установленным обновлением безопасности. (файл sourcehash, созданный с обновлением безопасности)
Вручную скопируйте файл sourcehash в папку c:\windows\installer. Поскольку файл исходного хэша создается на основе файлов приложения, файл исходного хэша, созданный на компьютере A, можно использовать на компьютере B.
Пожалуйста, включите необходимые команды в сам ответ. Обратная ссылка для получения дополнительной информации разрешена, но не одобряется, если не раскрывается прямая ссылка на другую сторону. Но убедитесь, что каждый ответ сам по себе полностью автономен.
У меня тоже такое было на разных серверах. После нескольких часов копания я обнаружил, что они не могут добраться до контроллеров домена. Проверьте настройки DNS и убедитесь, что они могут достичь AD. После исправления эта ошибка исчезла.
Если вы выполняете через psexec, простое добавление аргумента -s также устраняет ошибку. Затем он запускается как пользователь удаленной системы, и UAC не требуется.
Описывает лучшие практики, расположение, значения, управление политикой и **** соображения безопасности для обеспечения доверия к компьютерам и учетным записям пользователей для настройки политики безопасности делегирования.
Ошибка:
И, в этом сравнении, почему-то это несоответствие! (Найдено их в подробных журналах MSI).
Как только это не удается, он ищет Значение политики машины "AlwaysInstallElevated" Значение политики пользователя "AlwaysInstallElevated"
Теперь, если вы используете тихую установку "qn", эта ошибка вызывается: MSI_LUA: приглашение на высоту отключено для бесшумных установок.
Изменение параметров смены пароля компьютера
Смена пароля в домене происходит следующим образом:
Каждые 30 дней рабочая станция отправляет ближайшему контролеру домена запрос на изменение пароля учетной записи компьютера. Контролер принимает запрос, пароль изменяется, а затем изменения передаются на все контролеры в домене при следующей репликации.
Некоторые параметры смены пароля можно изменять. Например, можно изменить временной интервал или совсем отключить смену паролей. Сделать это можно как для отдельных компьютеров, так и для групп.
Если настройки необходимо применить к группе компьютеров, то проще всего использовать групповую политику. Настройки, отвечающие за смену паролей, находятся в разделе Computer Configuration — Policies — Windows Settings — Security Settings — Local Policies — Security Options. Нас интересуют следующие параметры:
Disable machine account password change — отключает на локальной машине запрос на изменение пароля;
Maximum machine account password age — определяет максимальный срок действия пароля компьютера. Этот параметр определяет частоту, с которой член домена будет пытаться изменить пароль. По умолчанию срок составляет 30 дней, максимально можно задать 999 дней;
Refuse machine account password changes — запрещает изменение пароля на контролерах домена. Если этот параметр активировать, то контролеры будут отвергать запросы компьютеров на изменение пароля.
Для одиночной машины можно воспользоваться настройками реестра. Для этого в разделе HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters есть два параметра :
DisablePasswordChange — если равен 1, то запрос на обновление пароля компьютера отключен, 0 — включен.
MaximumPasswordAge — определяет максимальный срок действия пароля компьютера в днях. При желании можно задать более 1 миллиона дней .
И в разделе HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters , только у контролеров домена, параметр:
RefusePasswordChange — если равен 1, то запрещает контролеру домена принимать запрос на изменение пароля. Этот параметр надо задать на всех контролерах в домене.
Вот вроде и все про доверительные отношения. Как видите, доверие в домене — штука тонкая, так что старайтесь его не терять.
Новый вещи:
- Они создают файл с именем «SourceHash» в папке %windir%\Windows\Installer. Это делается для каждого продукта, установленного на машине (с уже установленным KB2918614).
- SECREPAIR- Они вычисляют «Сохраненное значение хэша» и «Текущий хэш» для данного MSI.
Значения по умолчанию
В следующей таблице перечислены фактические и эффективные значения политики по умолчанию для последних поддерживаемых версий Windows. Значения по умолчанию также можно найти на странице свойств политики.
Тип сервера или объект групповой политики | Значение по умолчанию |
---|---|
Default Domain Policy | Не определено |
Политика контроллера домена по умолчанию | Не определено |
Параметры по умолчанию для автономного сервера | Не определено |
Действующие параметры по умолчанию для контроллера домена | Администраторы |
Действующие параметры по умолчанию для рядового сервера | Администраторы |
Действующие параметры по умолчанию для клиентского компьютера | Администраторы |
Противодействие
Учетные записи включить компьютер и пользователей, которые должны доверять праву пользователя делегирования, следует заявить только в том случае, если существует явная необходимость в его функциональных возможностях. При назначении этого права следует изучить использование ограниченной делегирования для управления делегированием учетных записей. На контроллерах домена это право по умолчанию назначено группе администраторов.
Примечание: Нет причин назначать это право пользователю любому пользователю на серверах-членах и рабочих станциях, принадлежащих домену, так как оно не имеет смысла в этих контекстах. Она актуальна только для контроллеров домена и автономных компьютеров.
Описание для Event ID 10837 из источника MsiInstaller не может быть найденный. Либо компонент, который повышает это событие, не установлен на ваш локальный компьютер или установка повреждена. Вы можете установить или отремонтировать компонент на локальном компьютере.
Если событие возникло на другом компьютере, отображаемая информация должен был быть сохранен с событием.
В мероприятии была включена следующая информация:
Продукт: НАШИМ НАЗВАНИЕ ПРОДУКТА - Запрошенная операция не может будет завершена. Компьютер должен быть доверен для делегирования, а текущая учетная запись пользователя должна быть настроена для делегирования.
После поиска похоже, что это вызвано недавно выпущенным патчем для защиты для установщика Windows. Когда я удалю KB2918614, программа установки снова начнет работать, и если я переустановит KB2918614, MSI перестанет работать снова.
ОБНОВЛЕНИЕ. Это не проблема с удаленным выполнением WMI, как это происходит, когда мы пытаемся установить MSI удаленно с помощью командлета Powershell, WinRM и Invoke-Commmand -ComputerName TargetComputer . . Существует изменение в том, как работает установщик Windows в 2008 R2 после установки KB2918614, который теперь запрещает выполнение пользовательским действием задачи.
Возможные значения
- Определяемый пользователей список учетных записей
- Не определено
Управление политикой
В этом разделе описываются функции, средства и рекомендации, которые помогут вам управлять этой политикой.
Изменение этого параметра может повлиять на совместимость с клиентами, службами и приложениями.
Перезагрузка устройства не требуется для того, чтобы этот параметр политики был эффективным.
Изменения прав пользователя вступают в силу при его следующем входе в учетную запись.
Причина
Когда пользователь впервые входит на компьютер и пытается шифровать данные впервые, операционная система должна создать предпочтительный DPAPI MasterKey, основанный на текущем пароле пользователя. При создании мастера DPAPI предпринята попытка создать копию этого ключа, обратившись к RWDC. Если резервное копирование сбой, MasterKey не может быть создан и 0x80090345 возвращается ошибка.
Этот сбой — это новое поведение, которое было внедрено KB2992611. В старых операционных системах и на системах, не установленных на KB2992611, если клиент не может связаться с RWDC во время резервного копирования MasterKey, создание ключевого ключа по-прежнему разрешено и создается локальное резервное копирование.
То есть устаревшее поведение выполняет локальное резервное копирование основной клавиши, если отсутствует RWDC.
В соответствии с сводкой разработки, в соответствии с данными о том, что коды RODCs не хранят секреты, коды RODCs не хранят и не обрабатывают резервное копирование MasterKey. Поэтому на сайтах, где нет RWDC, могут возникать проблемы, описанные в разделе "Симптомы".
Если предпочтительный главный ключ существует, но истек срок действия (истек срок действия пароля), предпринята попытка создания нового ключа. Если невозможно создать резервное копирование домена нового ключа, клиент возвращается к старому, и поведение, описанное в разделе "Симптомы", не происходит.
Проблема возникает только в том случае, если нет masterKey и если пользователь не входил на компьютер раньше.
Рекомендации
- Нет причин назначать это право пользователю любому пользователю на серверах-членах и рабочих станциях, принадлежащих домену, так как оно не имеет смысла в этих контекстах. Она актуальна только для контроллеров домена и автономных устройств.
Новый материал:
- Они создают файл по имени "SourceHash " под % Windir%\Windows\Installer. Это делается для каждого установленного продукта на машине (с уже установленным KB2918614).
- SECREPAIR- Они вычисляют "Сохраненное значение хеша" и "Текущий хэш" для данного MSI.
Дополнительная информация:
Мой MSI ivkoded через загрузочный exe. Но это не имеет большого значения. Даже ручной вызов линии msiexec через cmd ведет себя одинаково.
Любые входы/решения, кто-нибудь?
Ответ 2
Это слово от пользователей поддержки MS Enterprise.
Обходной путь 1: Распределение хешей.
Захватите хэш файл * на одной машине и распространите их на другие машины. Хэш файлы создаются в каталоге "% windir%\installer". Соглашение об именах выглядит следующим образом: "SourceHash * Этот файл создается только в том случае, если на компьютере установлен продукт с установленным KB2918614. Этот каталог скрыт. Откройте приглашение cmd с помощью "run as administrator". Перейдите к этому пути и откройте папку с помощью "explorer". команда. [Я не мог решить проблему с использованием этого подхода, возможно, потому, что для доступа к этому каталогу требуются права администратора, которые сам установщик Windows не может иметь]
Обходной путь 2: Белый список.
Только если вы доверяете приложению, что оно всегда подписано цифровой подписью и не содержит никаких вредоносных (даже в будущем).
Шаг 1: Включить белый список
В разделе "HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer" создайте DWORD: "SecureRepairPolicy" и установите значение "2".
Шаг 2: добавьте приложение в белый список
Создайте новый ключ "SecureRepairWhitelist" в разделе "HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer" и создайте StringValues с кодами продуктов (включая цветочные скобки <>) продукта.
. К сожалению, обе эти обходные пути нуждаются в привилегиях администратора!
Ответ 3
Вот мой автоматический способ использования работы с белым списком реестра, упомянутого на сайте Microsoft.
Теперь, прежде чем я запустил свою команду установки на удаленную машину, я посмотрю на MSI и извлечу код продукта с помощью Get-ProductCodeFromMSI, а затем с помощью Add-GuidToWhitelist добавит каждый GUID в список на этом компьютере. Вот пример:
Прежде чем это сделать, каждую машину можно протестировать и отремонтировать для обходного пути, используя Test-SecureRepairPolicy и Repair-SecureRepairPolicy, соответственно.
Get-ProductCodeFromMSI потребует, чтобы DLL была помещена где-то и разблокирована. Эта DLL может быть получена из набора инструментов Wix.
Код для функций, которые я ссылаюсь здесь:
Ответ 4
Я также сталкиваюсь с проблемой. Я получил powershell script для установки MSI на удаленных компьютерах (с помощью командлета Invoke-Command и предоставления учетных данных вместе с script), но внезапно ему не удалось установить MSI, который, как я полагаю, также и из этого исправления безопасности.
После запуска файла установки MSI вручную на целевом компьютере с использованием учетной записи домена (с удаленного рабочего стола) неожиданно Powerwill script может запустить установку MSI с использованием учетной записи домена, но все равно не удалось установить, если я использовал учетную запись локального администратора целевой машины.
Я предпочитаю добавлять это в качестве комментария, но мне не хватает репутации для этого. Если у другого есть какое-то решение или объяснение, я тоже хотел бы это узнать. Спасибо.
Ответ 5
Это должно быть связано с файлами SourceHash в каталоге \windows\installer. Этот файл можно открыть с помощью Orca, вы можете прочитать содержимое. Он содержит имя файла, спецификатор алгоритма хэша и хэш. В Windows 2k3 этот хэш - это base64ed sha256 hash с последним байтом.
Если вы переименуете файл SourceHash для своего продукта в сторону, я обнаружил, что обновление выполнено, и после этого создается новый файл SourceHash. Затем вы можете разделить два хэш файла источника. В случае, когда я исследую, когда вы меняете два файла, только хэш, указанный для исходного msi, отличается. После успешного обновления хэш нового msi, указанного в исходном хеш файле, будет соответствовать настройке источника установки. Сломанный файл sourcehash, очевидно, был сгенерирован из модифицированного/другого источника MSI, хотя я пока не смог определить, какой из них.
Ответ 6
У меня та же проблема. MSI не удалось установить с помощью команды Invoke-Command PoSH. Я обнаружил, что если я устанавливаю MSI на сервере локально под той же учетной записью, которая используется для Invoke-Command, проблема исправлена, и Invoke-Command начинает работать как обычно.
Ответ 7
Ответ Microsoft: Это обновление для системы безопасности устраняет уязвимость в Microsoft Windows. Уязвимость может позволить повысить привилегию, если злоумышленник запускает специально созданное приложение, которое пытается восстановить ранее установленное приложение. Злоумышленник должен иметь действительные учетные данные для входа и иметь возможность локально локально использовать эту уязвимость.
Удалите приложение и переустановите его с установленным обновлением безопасности. (файл-источник, сгенерированный с обновлением безопасности)
Вручную скопируйте файл sourcehash в папку c:\windows\installer. Поскольку файл sourcehash создается на основе файлов приложений, файл sourcehash, сгенерированный на компьютере A, можно использовать на компьютере B.
Ответ 8
У меня тоже было это на разных серверах. После нескольких часов рытья я обнаружил, что они не могут добраться до контроллеров домена. Проверьте настройки DNS и убедитесь, что они могут достигнуть AD. После исправления эта ошибка исчезла.
Ответ 9
Если вы выполняете psexec, просто добавление аргумента -s также устраняет ошибку. Затем он запускается как пользователь удаленной системы и UAC не требуется.
В этой статье предоставляется решение для решения проблем резервного копирования DPAPI MasterKey, которые возникают при невозможности RWDC.
Применяется к: Windows 10, версия 1809, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
Исходный номер КБ: 3205778
Ошибка:
И, в этом сравнении, почему-то эти нестыковки! (Нашел их в подробных журналах MSI).
Как только это не удается, он ищет Значение политики компьютера «AlwaysInstallElevated» Значение политики пользователя «AlwaysInstallElevated»
Теперь, если вы выполняете автоматическую установку «qn», возникает эта ошибка: MSI_LUA: Запрос на повышение прав отключен для автоматической установки.
Общие проблемы
Открытие диспетчера учетных данных не удается с ошибкой 0x80090345, которая сопопомна следующему:
Сохранение пароля RDP не удается без видимых ошибок.
Изменение пароля займет больше времени, чем ожидалось.
Explorer зависает при шифровании файла.
В Office и Office 365, добавление новой учетной записи в Почта Windows Live 2012 г. не удается с ошибками 0x80090345.
Outlook создание профиля не удается при следующей ошибке:
Зашифрованное подключение к почтовому серверу не доступно.
SQL служба не запускается в учетной записи домена и вызывает следующую ошибку:
Невозможно инициализировать шифрование SSL из-за невозможности найти допустимый сертификат и невозможно создать самозаверяемый сертификат.
SQL Server сбой при следующей ошибке:
Ошибка(ы): SQL серверной установки столкнулась со следующей ошибкой: "создание кода ошибки документа XML 0x8410001.
Пользователи домена не могут управлять SQL базами данных из SMSS. (SQL Server Management Studio). Эта проблема возникает, когда база данных передается с SSMS DataBasesCustomerDatabaseTablesTablesTable -> -> -> .
Если щелкнуть правой кнопкой мыши таблицу, а затем выбрать Дизайн, возникает следующая ошибка:
Запрашиваемая операция не может быть выполнена. Компьютер должен быть доверенным для делегирования, а учетная запись текущего пользователя должна быть настроена, чтобы разрешить делегировать. Это исключение возникло из System_Security_ni! System.Security.Cryptography.ProtectedData.Protect(Byte[], Byte[], System.Security.Cryptography.DataProtectionScope)."
Установка WAP ADFS не создает самозаверяемого сертификата и вызывает следующую ошибку:
Исключение: ошибка произошла при попытке создания сертификата доверия прокси.
Установка ADLDS на сайте, на который распространяется только RODC, сбой при следующей ошибке:
Введите допустимый пользователь и пароль для выбранной учетной записи службы
В этой ситуации в журнале AdamInstall.log показано следующее:
adamsetup D20.10F8 0255 15:30:22.002 Введите GetServiceAccountError
adamsetup D20.10F8 0256 15:30:22.002 Введите допустимые имя пользователя и пароль для выбранной учетной записи службы.
adamsetup D20.10F8 0257 15:30:22.002 ADAMERR_SERVICE_INVALID_CREDS
Пример сетевого следа, взятый во время сбоя, показывает, что ADLDS отправляет неправильный пароль, а запрос Kerberos TGT сбой с KDC_ERR_PREAUTH_FAILED:
Event ID 4625 входит в журнал безопасности сервера ADLDS следующим образом:
ID события: 4625
Ключевые слова: сбой аудита
Описание. Учетная запись не смогла войти в систему.
..
Сведения о сбоях:
Причина отказа: неизвестное имя пользователя или плохой пароль.
Состояние: 0xC000006D
Состояние sub: 0xC000006A
..
Сведения о процессе:
Имя процесса вызова: C:\Windows\ADAM\adaminstall.exe
Где состояние и состояние sub переводится как:
Во всех случаях NETLOGON. LOG показывает запрос DsGetDcName на вызовы для печатных контроллеров домена:
Location
Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment
ОТВЕТЫ
Ответ 1
Из того, что я понимаю,
Уязвимость
Ненадлежащее использование учетных записей компьютера и пользователей, которые можно доверять праву пользователя делегирования, может позволить несанкционированным пользователям выдать себя за других пользователей в сети. **** Злоумышленник может использовать эту привилегию, чтобы получить доступ к сетевым ресурсам и затруднить определение того, что произошло после инцидента с безопасностью.
Дополнительные сведения
Статья | Details |
---|---|
Windows защиты данных | Windows защиты данных |
Сервер удаленного протокола BackupKey фактически не выполняет удаленное резервное копирование секретов. Вместо этого сервер обертывание каждого секрета и возвращает его клиенту. Клиент несет ответственность за хранение секрета до тех пор, пока он не понадобится снова, после чего клиент может попросить сервер развернуть секрет
Как и учетные записи пользователей, учетные записи компьютеров в домене имеют свой пароль. Пароль этот нужен для установления так называемых «доверительных отношений» между рабочей станцией и доменом. Пароли для компьютеров генерируются автоматически и также автоматически каждые 30 дней изменяются.
Для восстановления доверительных отношений существует несколько способов. Рассмотрим их все по порядку.
Способ первый
Открываем оснастку «Active Directory Users and Computers» и находим в ней нужный компьютер. Кликаем на нем правой клавишей мыши и в контекстном меню выбираем пункт «Reset Account». Затем заходим на компьютер под локальной учетной записью и заново вводим его в домен.
Примечание. Кое где встречаются рекомендации удалить компьютер из домена и заново завести. Это тоже работает, однако при этом компьютер получает новый SID и теряет членство в группах, что может привести к непредсказуемым последствиям.
Способ этот довольно громоздкий и небыстрый, т.к. требует перезагрузки, однако работает в 100% случаев.
Способ второй
Заходим на компьютер, которому требуется сбросить пароль, открываем командную консоль обязательно от имени администратора и вводим команду:
Netdom Resetpwd /Server:SRV1 /UserD:Administrator /PasswordD:*
где SRV1 — контролер домена, Administrator — административная учетная запись в домене. Дополнительно можно указать параметр /SecurePasswordPrompt, который указывает выводить запрос пароля в специальной форме.
В открывшемся окне вводим учетные данные пользователя и жмем OK. Пароль сброшен и теперь можно зайти на компьютер под доменной учетной записью. Перезагрузка при этом не требуется.
Что интересно, в рекомендациях по использованию и в справке написано, что команду Netdom Resetpwd можно использовать только для сброса пароля на контролере домена, другие варианты использования не поддерживаются. Однако это не так, и команда также успешно сбрасывает пароль на рядовых серверах и рабочих станциях.
Еще с помощью Netdom можно проверить наличие безопасного соединения с доменом:
Или сбросить учетную запись компьютера:
где WKS1 — рабочая станция, которой сбрасываем учетку.
Способ достаточно быстрый и действенный, однако есть одно но: по умолчанию утилита Netdom есть только на серверах с установленной ролью Active Directory Domain Services (AD DS). На клиентских машинах она доступна как часть пакета удаленного администрирования Remote Server Administration Tools (RSAT).
Способ третий
Еще одна утилита командной строки — Nltest. На компьютере, который потерял доверие, выполняем следующие команды:
Nltest /query — проверить безопасное соединение с доменом;
Самый быстрый и доступный способ, ведь утилита Nltest по умолчению есть на любой рабочей станции или сервере. Однако, в отличие от Netdom, в которой предусмотрен ввод учетных данных, Nltest работает в контексте запустившего ее пользователя. Соответственно, зайдя на компьютер под локальной учетной записью и попытавшись выполнить команду можем получить ошибку доступа.
Способ четвертый
PowerShell тоже умеет сбрасывать пароль копьютера и восстанавливать безопасное соеднение с доменом. Для этого существует командлет Test-ComputerSecureChannel . Запущенный без параметров он выдаст состояние защищенного канала — True или False.
Для сброса учетной записи компьютера и защищенного канала можно использовать такую команду:
Test-ComputerSecureChannel -Server SRV1 -Credential Contoso\Administrator -Repair
где SRV1 — контролер домена (указывать не обязательно).
Для сброса пароля также можно также воспользоваться такой командой:
Reset-ComputerMachineChannel -Server SRV1 -Credential Contoso\Administrator
Способ быстрый и удобный, не требующий перезагрузки. Но и здесь есть свои особенности. Ключ -Credential впервые появился в PowerShell 3.0. Без этого параметра командлет, запущенный из под локального пользователя, выдает ошибку доступа. Получается что данный метод можно использовать только на Windows 8 и Server 2012, ведь для остальных ОС PowerShell 3.0 пока недоступен.
Как видите, способов восстановления доверительных отношений более чем достаточно. Однако если проблема приобретает постоянный характер, то проще подойти к ее решению с другой стороны.
Читайте также: