Поделиться через

Устранение ошибки с недостаточными правами доступа

  • Статья

Проблема

Подготовка входящих пользователей в Active Directory работает должным образом для большинства пользователей. Но для некоторых пользователей журналы подготовки отображают следующую ошибку:

ERROR: InsufficientAccessRights-SecErr: The user has insufficient access rights.. Access is denied. \nError Details: Problem 4003 - INSUFF_ACCESS_RIGHTS. 
OR

ERROR: 
"Message":"The user has insufficient access rights.",
"ResponseResultCode":"InsufficientAccessRights",
"ResponseErrorMessage":"00002098: SecErr: DSID-03150F94, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0",
The user has insufficient access rights.

В журналах подготовки отображается код ошибки: HybridSynchronizationActiveDirectoryInsufficientAccessRights

Причина

Учетная запись provAgentgMSA$ GMSA агента подготовки по умолчанию имеет разрешение на чтение и запись для всех объектов пользователей в домене. Существует две возможные причины, которые могут привести к приведенной выше ошибке.

  • Причина-1. Объект пользователя является частью подразделения, который не наследует разрешения на уровне домена.
  • Причина-2. Объект пользователя принадлежит защищенной группе Active Directory. При проектировании пользовательские объекты управляются разрешениями, связанными с специальным контейнером AdminSDHolder. Это объясняет, почему provAgentgMSA$ учетная запись не может обновить эти учетные записи, принадлежащие защищенным группам Active Directory. Вы можете попытаться переопределить и явно предоставить учетной provAgentgMSA$ записи доступ на запись к учетным записям пользователей, но это не будет работать. Чтобы защитить привилегированные учетные записи пользователей от неправильного использования делегированных разрешений, существует фоновый процесс с именем SDProp , который выполняется каждые 60 минут и гарантирует, что пользователи, принадлежащие защищенной группе, всегда управляются разрешениями, определенными в контейнере AdminSDHolder . Даже при добавлении provAgentgMSA$ учетной записи в группу доменных Администратор не будет работать.

Разрешение

Сначала подтвердите, что вызывает проблему. Чтобы проверка, если причина-1 является источником проблемы:

  1. Откройте консоль управления Пользователи и компьютеры Active Directory.
  2. Выберите подразделение, связанное с пользователем.
  3. Щелкните правой кнопкой мыши и перейдите к свойствам —> безопасность —> Дополнительно. Если отображается кнопка "Включить наследование", она подтверждает, что причина-1 является источником проблемы.
  4. Нажмите кнопку "Включить наследование", чтобы разрешения на уровне домена применимы к этому подразделению.

    Примечание.

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

Если причина-1 не является источником проблемы, то потенциально причина-2 является источником проблемы. Существует два возможных варианта разрешения.

Вариант 1. Удаление затронутого пользователя из защищенной группы AD, чтобы найти список пользователей, управляемых этим AdminSDHolder разрешением, Cx может вызвать следующую команду:

Get-AdObject -filter {AdminCount -gt 0}

Справочные статьи:

  • Ниже приведен пример скрипта PowerShell, который можно использовать для очистки флага Администратор Count и повторного включения наследования для затронутых пользователей.
  • Выполните действия, описанные в этой статье. Поиск потерянных учетных записей для поиска потерянных учетных записей (учетных записей, которые не являются частью защищенной группы, но по-прежнему имеют флаг Администратор Count задано значение 1)

Вариант 1 может не всегда работать

Существует процесс, называемый процессом распространения дескриптора безопасности (SDPROP), который выполняется каждый час на контроллере домена с ролью FSMO эмулятора PDC. Это процесс, который задает AdminCount атрибут 1. Основной функцией SDPROP является защита учетных записей Active Directory с высоким уровнем привилегий, что они не могут быть удалены или иметь права, измененные случайно или намеренно, пользователями или процессами с меньшими привилегиями. Существует процесс, называемый процессом распространения дескриптора безопасности (SDPROP), который выполняется каждый час на контроллере домена с ролью FSMO эмулятора PDC. Это процесс, который задает AdminCount атрибут 1. Основной функцией SDPROP является защита учетных записей Active Directory с высоким уровнем привилегий. Процесс SDPROP гарантирует, что учетные записи не могут быть удалены или иметь права случайно или намеренно изменены пользователями или процессами с меньшими привилегиями.

Справочные статьи, объясняющие причину подробно:

Вариант 2. Изменение разрешений по умолчанию контейнера Администратор SDHolder

Если вариант 1 недоступен и не работает должным образом, попросите Cx проверка с администратором AD и администраторами безопасности, если они могут изменить разрешения AdminSDHolder по умолчанию контейнера. В этой статье объясняется важность AdminSDHolder контейнера. После получения внутреннего утверждения Cx для обновления AdminSDHolder разрешений контейнера существует два способа обновления разрешений.

  • Использование ADSIEdit , как описано в этой статье.
  • Использование DSACLS скрипта командной строки. Ниже приведен пример скрипта, который может использоваться в качестве отправной точки, и Cx может настроить его в соответствии с их требованиями.

$dcFQDN = "<FQDN Of The Nearest RWDC Of Domain>"
$domainDN = "<Domain Distinguished Name>"
$domainNBT = "<Domain NetBIOS Name>"
$dsaclsCMD = "DSACLS '\\$dcFQDN\CN=AdminSDHolder,CN=System,$domainDN' /G '$domainNBT\provAgentgMSA$:RPWP;<Attribute To Write To>'"
Invoke-
Expression $dsaclsCMD | Out-Null

Если Cx нуждается в дополнительной помощи по устранению неполадок с локальными разрешениями AD, обратитесь в службу поддержки Windows Server. В этой статье о проблемах Администратор SDHolder с Microsoft Entra Подключение приведены дополнительные примеры использования DSACLS.

Вариант 3. Назначение полного управления учетной записи provAgentgMSA

Назначьте разрешения полного управления учетной provAgentGMSA записи. Этот шаг рекомендуется, если возникают проблемы с перемещением объекта пользователя из одного подразделения контейнера в другой, если объект пользователя не принадлежит защищенной группе пользователей.

В этом сценарии попросите Cx выполнить следующие действия и повторно выполнить операцию перемещения.

  1. Войдите в контроллер домена AD в качестве администратора.
  2. Откройте командную строку PowerShell с run правами администратора.
  3. В командной строке PowerShell выполните следующую команду DSACLS , которая предоставляет универсальный полный доступ к учетной записи агента подготовки GMSA. dsacls "dc=contoso,dc=com" /I:T /G "CN=provAgentgMSA,CN=Managed Service Accounts,DC=contoso,DC=com:GA"

Замените корневой узел или соответствующий dc=contoso,dc=com контейнер подразделения. Если вы используете пользовательский GMSA, обновите значение DN для provAgentgMSA.

Вариант 4. Пропустить учетную запись GMSA и использовать созданную вручную учетную запись службы, этот параметр следует использовать только в качестве временного обходного решения для разблокировки, пока проблема с разрешением GMSA не будет расследована и устранена. Наша рекомендация — использовать учетную запись GMSA. Вы можете задать параметр реестра, чтобы пропустить конфигурацию GMSA и перенастроить агент подготовки Microsoft Entra Подключение, чтобы использовать созданную вручную учетную запись службы с нужными разрешениями.

Следующие шаги