Доступ запрещен с помощью команды NET USER через сеанс SSH

Доступ запрещен с помощью команды NET USER через сеанс SSH

Я использую ssh-клиент для входа на сервер, чтобы выдавать команды смены пароля из приглашения. Проблема возникает при попытке сделать это на сервере домена. Я вхожу, используя учетную запись администратора (не учетную запись администратора) и пытаюсь изменить пароль для пользователя (net user Имя_пользователя пароль /домен), и получаю следующую ошибку:

Произошла системная ошибка 5.

В доступе отказано.

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

решение1

Несмотря на то, что вы утверждаете, что проверили членство в группах, на самом деле похоже, что у вашей учетной записи «администратор» нет того же членства в группах, что и у учетной записи «администратор».

Windows «whoami.exe» (не Cygwin whoami) с параметром «/ALL» покажет вам членство в группах каждого пользователя, чтобы вы могли сравнить их.

(Теоретически можно было бы изменить разрешения объектов пользователей в AD, чтобы лишить пользователя «admin» права менять свой пароль, при этом «admin» по-прежнему оставался бы членом тех же групп, что и «Administrator», но я думаю, что это крайне маловероятно.)

Чтобы полностью исключить любую возможность использования cygwin SSH, почему бы не войти локально на серверный компьютер с учетными данными «admin» и не попробовать ввести «NET USER» из командной строки NT?

Редактировать:

На самом деле нет никаких настроек групповой политики, которые бы как таковые влияли на возможность смены паролей. Если ваша учетная запись "admin" является членом "Enterprise Admins", она должна иметь возможность сбросить пароль любой другой учетной записи в Active Directory. Как я уже сказал выше, есть "твики", которые можно было бы сделать в AD, чтобы изменить это поведение, но я считаю крайне маловероятным, что что-то из этого было бы сделано. Я думаю, что происходит что-то еще.

Если у вас не включен аудит сбоев событий управления учетными записями, сейчас самое время либо создать новый объект групповой политики, связанный с вашим подразделением «Контроллеры домена» (предпочтительно), либо изменить объект групповой политики «Контроллеры домена по умолчанию» (непредпочтительно — вам действительно следует оставить этот объект групповой политики «в наличии») и включить аудит сбоев событий управления учетными записями. Откройте «Конфигурацию компьютера», «Параметры Windows», «Параметры безопасности», «Локальные политики» и «Политику аудита» и включите аудит сбоев в «Управлении учетными записями».

Запустите «gpupdate» на компьютерах контроллеров домена, снова попробуйте использовать «NET USER» и проверьте журнал событий безопасности на всех контроллерах домена, чтобы узнать, на каком из них зафиксирована неудачная смена пароля.

Мне бы хотелось выяснить, что происходит. Как я уже сказал, я ожидаю, что это что-то простое, что упускается из виду... Посмотрим...

решение2

Первая учетная запись администратора, имеет ли она членство в группе администраторов домена или операторов учетных записей в домене? Или у нее есть делегированное право на сброс пароля в учетной записи пользователя? Поскольку вы указываете /domain, изменение вносится в учетную запись пользователя домена, поэтому права должны быть на уровне домена.

решение3

После многих лет попыток отследить такого рода проблемы, теперь, если я хочу создать учетную запись "администратора", я всегда делаю это путем копирования учетной записи администратора. В AD Users and Computers щелкните правой кнопкой мыши учетную запись администратора и выберите "Копировать". Экономит много времени!

Конечно, вопрос о том, является ли наличие нескольких учетных записей администратора хорошей практикой, является спорным...

Дж.Р.

решение4

Пользователь сети? Фуууу. Вам следует использоватьДСМОД.

DSMOD user userDN -pwd newPassword -d yourDomain.loc -u yourDomain\yourAdminUserAcct

Если вы не знаете userDN, используйте это:

DSQUERY user -name userName -d yourDomain.loc -u yourDomain\yourAdminUserAcct

Если вы хотите чего-то поинтереснее, вы можете передать результат DSQUERY прямо в DSMOD, например так:

DSQUERY user -name userName -d yourDomain.loc -u yourDomain\yourAdminUserAcct | DSMOD user -pwd newPassword -d yourDomain.loc -u yourDomain\yourAdminUserAcct

Если вы хотите установитьПользователь должен сменить пароль при следующем входе в системуфлаг, затем добавить-mustchpwd дав строку аргумента DSMOD, например так:

DSQUERY user -name userName -d yourDomain.loc -u yourDomain\yourAdminUserAcct | DSMOD user -pwd newPassword -d yourDomain.loc -u yourDomain\yourAdminUserAcct -mustchpwd yes

Связанный контент