Could not write changed password to ad error 0x80070032 - Исправление ошибок и поиск оптимальных решений проблем

Remove From My Forums

Question
After deploying LAPS to OU, many computers getting Event ID: 7

Source: AdmPwd

The computer does not have the necessary permission to write the local administrator password to its object in Active Directory. Please submit an AD Request to have permissions set on your Department OU.

Answers

Hi,

According to my research, this could be missing the Write permission on ms-MCS-AdmPwdExpirationTime and ms-MCS-AdmPwd attributes of all computer accounts to the SELF built-in account. Please refer to the following steps.

To make sure computer accounts can update the password and expiration timestamp of its own built-in Administrator password, we need to add the Write permission on ms-MCS-AdmPwdExpirationTime and ms-MCS-AdmPwd attributes of all computer accounts to the SELF
built-in account. And we can use the following PowerShell to do this:

Set-AdmPwdComputerSelfPermission –Identity ManagedWorkstations –Verbose

Best Regards,

Alvin Wang

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact
tnmff@microsoft.com.
- Marked as answer by
  
  Friday, June 2, 2017 1:30 AM

Lately, I was facing error 7 Could not write changed password to AD. Error 0x80070032. in the Application Log at one of my servers. I’m aware that this critical event is often caused by insufficient rights for LAPS. But in this case, the server was not yet configured with LAPS. The OU where the server was located wasn’t configured for LAPS either. I had NOT run Set-AdmPwdComputerSelfPermission -OrgUnit “servers” yet.

In this post, I’ll show you the steps on how to fix event 7 AdmPwd for objects that don’t have LAPS installed and configured.

To prevent error 7 Could not write changed password to AD. Error 0x80070032 from occurring approximately every 90 minutes, follow these steps:

Start Active Directory Users and Computers (dsa.msc)
In the main window, first enable Advanced Features
Navigate to the Organizational Unit where the computer object is located
Double-click the Computer Object. Go to tab Security
Click Advanced
Click Add. In the new windows named Permission Entry for <computer name>, click select a principal. Type SELF , click “check names” to validate and click OK
Scroll down to “Write ms-Mcs-AdmPwd” and check the box. Finding this permission can be cumbersome if you have a lot of permissions on the list.
Click OK to save the changes.

That’s it. The computer object now has permission to change its own password.

To validate the changes are effective, you should wait another 90 minutes and search for event 7, source AdmPwd, in the Application Log. You might be able to speed things up by running a group policy update (gpupdate /force), but I didn’t test this out. And since you probably have fixed the error with the above’s steps, you are not going to see error 0x80070032 appear again

If this article did not help you solve your problem, please leave a comment! This website is visited thousands of times a day. There is a good chance that I or someone else has an answer to your question.

In addition, if you have a better solution for this problem, please leave a comment too! It may help me improve this article, as well as you may help other users facing this issue.

Источник

Прочитано:
3 114

В виду того факта, что на текущем рабочем месте в качестве домен контроллеров используется серверная операционная система Windows Server 2008 R2 Standard, то мне нужно адаптировать заметку где я в лабораторных условиях разобрал ,как практически развернуть LAPS на Server 2012 R2 Standard. Когда я это делал на Server 2008 R2, то столкнулся с некоторыми нюансами которые по началу были не привычны, но все завершилось успешно.

Так сказать я хочу задокумментировать в шагах на будущее исполнение, сперва проделываем внедрение на одном крупном городе России, а после буду делать на другом и из-за этого важно иметь под рукой собственные наработки.

Что имею:

ОС: Windows Server 2008 R2 Standard (со всеми обновлениями на момент написания данной заметки)
Домен: polygon.local
FQDN-имя: srv-dc.polygon.local

Шаг №1: Авторизуюсь на домен контроллере с права учетной записи вхожей в группу «Domain Admins» и для внедрения LAPS понадобится, также быть в группе «Schema Admins»

Шаг №2: Запускаю файл установки (для удобства я его переименовал в lapsx64.msi), установка стандартна, точнее просто устанавливаем все:

AdmPwd GPO Extension
Management Tools
Fat client UI
PowerShell module
GPO Editor Template

Шаг №3: Расширяем схему, данными действиями будет организовано добавление двух атрибутов к объекту компьютера:

Start — All Programs — Accessories — Windows PowerShell — и через правый клик мышью запускаю консоль PowerShell с правами администратора («Run as administrator»)

PS C:Windowssystem32> import—module AdmPwd.ps

Import—Module : Could not load file or assembly ‘file:///C:Windowssystem32WindowsPowerShellv1.0ModulesAdmPwd.psAdmPwd.PS.dll’ or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.

At line:1 char:14

+ import—module <<<< AdmPwd.ps

+ CategoryInfo : NotSpecified: (:) [Import—Module], BadImageFormatException

+ FullyQualifiedErrorId : System.BadImageFormatException,Microsoft.PowerShell.Commands.ImportModuleCommand

PS C:Windowssystem32> get—host

Name : ConsoleHost

Version : 2.0

InstanceId : 02bd6acb—c8fb—434d—9440—17a018254760

UI : System.Management.Automation.Internal.Host.InternalHostUserInterface

CurrentCulture : en—US

CurrentUICulture : en—US

PrivateData : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy

IsRunspacePushed : False

Runspace : System.Management.Automation.Runspaces.LocalRunspace

PS C:Windowssystem32> $PSVersionTable

Name Value

—— ———

CLRVersion 2.0.50727.8806

BuildVersion 6.1.7601.17514

PSVersion 2.0

WSManStackVersion 2.0

PSCompatibleVersions {1.0, 2.0}

SerializationVersion 1.1.0.1

PSRemotingProtocolVersion 2.1

Дело в том, что в случае данной ошибке выше мне нужно просто обновить PowerShell с текущей 2 версии на 5.1, для этого устанавливаю пакет: Win7AndW2K8R2-KB3191566-x64.msu. Затем перезагружаю систему.

После установка модуля (AdmPwd.ps) в консоли PowerShell происходит без каких либо ошибок:

PS C:Windowssystem32> get—host | findstr /I «Version»

Version : 5.1.14409.1005

PS C:Windowssystem32> import—module AdmPwd.ps

PS C:Windowssystem32> update—AdmPwdADSchema

Operation DistinguishedName Status

————— ————————— ———

AddSchemaAttribute cn=ms—Mcs—AdmPwdExpirationTime,CN=Schema,CN=Configuration,DC=p... Success

AddSchemaAttribute cn=ms—Mcs—AdmPwd,CN=Schema,CN=Configuration,DC=polygon,DC=local Success

ModifySchemaClass cn=computer,CN=Schema,CN=Configuration,DC=polygon,DC=local Success

Шаг №4: Настройка LAPS сводится к выполнению следующих шагов в консоли PowerShell:

PS C:Windowssystem32> import—module AdmPwd.ps

На заметку: Отобразить все OU в домене:

PS C:Windowssystem32> Get—ADObject —Filter { ObjectClass —eq ‘organizationalunit’ }

или

Именование OU можно узнать через оснастку «Active Directory - пользователи и компьютеры» — через правый клик на OU "Свойства" - "Редактор атрибутов" - атрибут "distinguishedName" и нажимаем «Просмотр» и копируем именование OU контейнера.

PS C:Windowssystem32> Set—AdmPwdComputerSelfPermission —OrgUnit MSKTEST

или

PS C:Windowssystem32> Set—AdmPwdComputerSelfPermission —OrgUnit OU=MSKTEST,DC=polygon,DC=local

Name DistinguishedName Status

—— ————————— ———

MSKTEST OU=MSKTEST,DC=polygon,DC=local Delegated

PS C:Windowssystem32> Set—AdmPwdReadPasswordPermission —OrgUnit MSKTEST —AllowedPrincipals ‘GROUP_LAPS’

Name DistinguishedName Status

—— ————————— ———

MSKTEST OU=MSKTEST,DC=polygon,DC=local Delegated

Проверяю, что реально применились права на доступ группе GROUP_LAPS к просмотру расширенных/добавленных атрибутов компьютеров внутри OU с целью извлечения паролей на учетную запись локального администратора или переименованную если изменяли функционал GPO:

PS C:Windowssystem32> Find—AdmPwdExtendedRights —identity MSKTEST | format—table ExtendedRightHolders

ExtendedRightHolders

——————————

{NT AUTHORITYSYSTEM, POLYGONDomain Admins, POLYGONGROUP_LAPS}

из вывода видно, что доступ к расширенным атрибутам OU=MSKTEST есть у системы, Администраторов домена (по умолчанию) и теперь у группы GROUP_LAPS

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

Шаг №5: Копирую файл групповых политик в общее хранилище:

PS C:Windowssystem32> xcopy /Y «C:WindowsPolicyDefinitionsAdmPwd.admx» C:WindowsSYSVOLdomainPoliciesPolicyDefinitions

C:WindowsPolicyDefinitionsAdmPwd.admx

1 File(s) copied

PS C:Windowssystem32> xcopy /Y «c:WindowsPolicyDefinitionsen-USAdmPwd.adml» c:WindowsSYSVOLdomainPoliciesPolicyDefinitionsen—US

C:WindowsPolicyDefinitionsen—USAdmPwd.adml

1 File(s) copied

PS C:Windowssystem32>

Шаг №6: Создаю политику где целью будет установка агента LAPS в зависимости от архитектуры компьютера, а также некоторая доработка:

PS C:Windowssystem32> xcopy /Y «c:softlaps*.msi» C:WindowsSYSVOLsysvolpolygon.localscripts

C:softlapslapsx64.msi

C:softlapslapsx86.msi

2 File(s) copied

Политика именуется у меня, как GPO_MSK_LAPS

На заметку: Если в Security Filtering Вы конкретно указали группу компьютеров или компьютеры вместо Authenticated Users, то обязательно следует перейти во вкладку Delegation и добавить Authenticated Users и дать права на чтение, в противном случае политика работать не будет. Это очень важно. Почему политика не применяется следует смотреть расширенные логи на компьютере.

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

Computer Configuration — Policies — Windows Settings — Security Settings — Local Policies — Security Options:

Accounts: Rename administrator account: отмечаю галочкой Define this policy settings и указываю, как именуется административная учетная запись на компьютере: Администратор
Accounts: Administrator account status: отмечаю галочкой Define this policy setting и ставлю статус Enabled.

Computer Configuration — Policies — Preferences — Control Panel Settings — Local Users and Groups

New — Local User

Action: Update
User name: Administrator (built-in)
Password never expires: отмечаю галочкой
Account never expires: отмечаю галочкой

New — Local Group

Action: Update
Group name: Administrators (built-in)
Delete all member users: отмечаю галочкой
Delete all member groups: отмечаю галочкой

через Add указываю если есть групп(ы/у) делегированных доменных учетных записей которые будут обладать правами администратора на рабочих станциях и добавляю также «Domain Admins»

Не забываем указать установку агента, через Computer — Configuration — Policies — Software Settings — Software installation

одна x64-битная установка
вторая x86-битная установка с обязательным сниманием галочки «Make this 32-bit x86 application available to Win64 machines.»
Ниже скриншот для наглядного понимания.

Затем в эту же политику добавляю настройки применительно к LAPS. В конечном итоге политика должна выглядеть так: (смотрим вкладку Settings и разворачиваем каждую настройку)

По настройке LAPS см. либо документацию, либо мою заметку.
Password Settings: Enabled
Password Complexity: Large letters + small letters + numbers + specials
Password Length: 8
Password Age (Days): 30

Т.к. политика применяется только к компьютерам в определенной OU то дополнительно стоит деактивировать нацеливание на пользоваталей:

Group Policy Management — GPO_MSK_LAPS — вкладка Details

GRO Status: User configuration settings disabled

На заметку: Настройка Password Length должно быть равно или больше через предопределено в Default Domain Policy.

По итогу применения политики получаем, что в установлен LAPS клиент, активирована локальная учетная запись «Администратор», и группы «Администраторы» удалены все кроме «Администраторы домена», «Делегированные администраторы". А пароль на локальную учетную запись «Администратор» теперь генерируется через LAPS посредством преднастроенной политики, просмотреть его можно только через оснастку LAPS UI определенной группе и конечно же «Администраторам домена» кроме прочего через оснастку LAPS UI и «Active Directory Users and Computer» включением показа расширенных атрибутов.

Проверяю, что после загрузки W7X64 в OU=MSKTEST я могу через PowerShell с домен контроллера извлечь пароль локального администратора:

PS C:Windowssystem32> get—adcomputer —filter * —searchbase «ou=msktest,dc=polygon,dc=local» | get—admpwdpassword —Comp

utername {$_.Name}

ComputerName DistinguishedName Password ExpirationTimestamp

—————— ————————— ———— ——————————

W7X64 CN=W7X64,OU=MSKTEST,DC=polygon,DC=local 1/1/0001 12:00:00 AM

Если пароль не отображается, то на ПК нужно сделать:

gpupdate /force и перезагрузиться, если все равно пароль не назначается, то смотрим логи на ПК:

Просмотр событий:

Имя журнала: Приложение
Источник: AdmPwd
Код события: 5
Уровень: Ошибка
Описание: Validation failed for new local admin password against local password policy. Error 0x80070a90

Решение ошибки: Встроенная учетная запись «Администратор» должна быть включена и у нее должен быть установлен пароль соответствующий требованиям политики Default Domain Policy

Если ошибка:

Просмотр событий:

Имя журнала: Приложение
Источник: AdmPwd
Код события: 7
Уровень: Ошибка
Описание: Could not write changed password to AD. Error 0x80070032.

Решение ошибки: нет прав на изменение атрибутов добавленных путем расширения схемы.

PS C:Windowssystem32> Set—AdmPwdComputerSelfPermission —OrgUnit msktest

и после я вижу назначенный пароль:

PS C:Windowssystem32> get—adcomputer —filter * —searchbase «ou=msktest,dc=polygon,dc=local» | get—admpwdpassword —Comp

utername {$_.Name}

ComputerName DistinguishedName Password ExpirationTimestamp

—————— ————————— ———— ——————————

W7X64 CN=W7X64,OU=MSKTEST,DC=polygon,DC=local vJDH.3pw 8/3/2019 11:16:57 PM

Или узнать все пароли всех компьютеров для всего домена:

PS C:Windowssystem32> get—adcomputer —filter * —searchbase «DC=polygon,DC=local» | get—admpwdpassword —Computername {$_.Name}

Таким образом удобно отслеживать, как применяется политика в течении дня покуда компьютеры после перезагрузки применяют политику.

Итого я адаптировал заметку работы с LAPS на Windows Server 2008 R2 Standard, опираясь на рассмотренные действия я могу внедрять данный функционал и в других организациях. На этом я прощаюсь, с уважением Олло Александр aka ekzorchik.

Источник

Forums
Microsoft Windows Boards
Windows Server 2012

You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.

Event ID 7 “Could not write changed password to AD. Error 0x80070032

Thread starter

kate_Admin
Start date

Sep 14, 2018

kate_Admin

After deploying LAPS to OU, many computers getting Event ID: 7

Source: AdmPwd

The computer does not have the necessary permission to write the local administrator password to its object in Active Directory. Please submit an AD Request to have permissions set on your Department OU.

Forums
Microsoft Windows Boards
Windows Server 2012

This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.

Источник

GRAVITSAPA.INFO

›

Windows

›

Устраняем ошибку 0x80070032 в Windows

Устраняем ошибку 0x80070032 в Windows

5058 просмотров
Windows

20 Дек 2020

Что бы устранить ошибку 0x80070032 , попробуйте выполнить следующие процедуры:

Полностью удалите всё из папки C:WindowsSoftwareDistributionDownload и перезагрузите компьютер;
Если первый пункт не помог, то заходим в редактор реестра (Win + R и прописываем regedit), заходим в ветку HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControl -> удаляем в ней папку MiniNT -> перезагружаем компьютер;
Если всё ещё появляется ошибка, то попробуйте проверить включены ли некоторые службы -> нажмите Win + R и введите services.msc -> найдите службы «Планировщик заданий» и «Журнал событий Windows» -> по очереди на каждую нажмите правой кнопкой мыши и клацните «Свойства» -> убедитесь, что «Тип запуска: Автоматически» и запустите, если остановлено -> перезагрузите ПК;
И ещё вариант, который вполне эффективен и против многих других ошибок — воспользоваться утилитой FixWin (ссылка на официальный сайт). Утилита хоть и на английском языке, но интуитивно понятная.

Кроме это есть ещё вариант, как убрать ошибку 0x80070032 (сначала прочтите, потом пробуйте):

Откройте папку C:WindowsServiceProfilesLocalServiceAppDataLocalMicrosoftNGC -> удалите всё содержимое;
Зайдите в «Настройки» -> «Учётные записи» -> «Варианты входа» -> «Пин-код для Windows Hello» -> добавьте новый ПИН;
Так же можно не удалять содержимое папки NGC, попробуйте сначала в настройках удалить ПИН и добавить новый.

Пишите комменты, делитесь статьёй в соц. сетях 😉

Ещё статьи по теме:

Как купить правильный лицензионный ключ для Windows 10 на Ebay?
Причина ошибок 0х80041004, 0х80041006, 0x80041009
Как выключить самопроизвольное изменение яркости на ноутбуке?
Исправляем ошибку «…на компьютере отсутствует rtl120.bpl…»
Как выбрать редакцию Windows 10 Pro во время чистой установки?

Оставь свой коммент

Источник

Обновлено 04.07.2017

Добрый день уважаемые читатели и подписчики блога, продолжаем с вами изучать виртуализацию операционных систем на базе гипервизора Hyper-V. Сегодня я хочу с вами рассмотреть вот такой интересный вопрос, почему при миграции виртуальной машины между хостами Hyper-V у вас появляется ошибка 0x80070032. Ее я видел первый раз в жизни, так как до этого все проходило как по маслу.

Итак, расскажу небольшую предысторию, есть два сервера с Hyper-V ролью, один на Windows Server 2012 R2, а второй на Windows Server 2016 R2. Задача, переместить с 2016 r2 все виртуальные машины на 2012 r2, scvmm не используется, так как его нет и единственным вариантом сделать задачу, это воспользоваться встроенным механизмом перемещения, доступным через оснастку.

В результате попытке перевезти виртуальную машину, выскочила вот эта проблема.

При выполнении перемещения возникла ошибка. Сбой при миграции виртуальной машины в исходном расположении миграции. Не удалось установить соединение с узлом: Такой запрос не поддерживается. (0x80070032).

Не удалось установить соединение из-за неподдерживаемой версии протокола (версия протокола 6.0)

Причины ошибки 0x80070032

Давайте рассмотрим возможные причины данной проблемы:

Если обратиться к документации Microsoft относительно ее гипервизора, то там написано, что миграция без scvmm1 не может быть осуществлена с более новой версии Hyper-V на меньшую, именно мой случай. (https://technet.microsoft.com/ru-ru/library/dn282278.aspx?f=255&MSPPError=-2147217396)
Если же у вас версии либо одинаковые, либо вы делаете миграцию на более новую версию, то проверьте включена ли у вас динамическая миграция. Если нет, то посмотрите по ссылке.

Со вторым вариантом, все понятно, включаете Kerberos и динамическую миграцию, а вот в первом случае, вас спасет функция экспорта виртуальной машины Hyper-V, перенос ее по сети на другой хост и импортирование. В итоге вы избежите ошибку 0x80070032 на гипервизоре Microsoft.

Июл 4, 2017 12:01

Источник

Question

Answers

Event ID 7 “Could not write changed password to AD. Error 0x80070032

kate_Admin

Устраняем ошибку 0x80070032 в Windows

Ещё статьи по теме:

Оставь свой коммент

Причины ошибки 0x80070032