Назад | Перейти на главную страницу

Права пользователя Active Directory

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

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

Моя проблема в следующем:

Я могу изменить пароль пользователя, используя эти строки кода (запись - это запись пользователя в AD):

entry.Invoke("ChangePassword", new object[] { oldpassword, newPassword });
entry.CommitChanges();

Но несколькими строками позже его описание не обновляется:

entry.InvokeSet("description", new object[] { UserPasswordStatus.PasswordChanged.ToString() });
entry.CommitChanges();

В результате возникает «System.UnauthorizedAccessException: общая ошибка отказа в доступе».

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

У меня вопрос: что именно мне нужно изменить, чтобы пользователь мог изменить свое описание? Очевидно, я бы хотел, чтобы он был универсальным и применялся по умолчанию для всех моих пользователей.

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

Я определенно не советовал бы давать пользователю Active Directory полный контроль над его или ее учетной записью даже на секунду. Даже на миллисекунду. Однажды аудитор безопасности узнает, зацепится за этот факт и начнет омрачать ваш разум страхом и сомнением и, по сути, просто заставит вас ненавидеть жизнь в целом.

Мне даже не очень нравится идея дать пользователю возможность изменять свое собственное описание, так как многие администраторы используют это поле описания для своих целей и не хотят, чтобы пользователи возились со своими собственными атрибутами. и добавление «остроумных» фраз в их описания и типичных вещей, которые делают пользователи.

Но в любом случае подумайте об этом ...

Учетные записи пользователей наследуют унаследованные разрешения от OU (Organization Unit), в котором они находятся. Итак, если все пользователи вашего приложения находятся в определенном OU, вы можете изменить ACL для этого OU, чтобы включить SELF, Allow, Write Description так что каждый пользователь, созданный в этом OU, унаследует то же разрешение. На самом деле это может отображаться как «Записать общую информацию» или «Записать общедоступную информацию», поскольку атрибут «описание» фактически является членом набор свойств. Большим результатом этого подхода является то, что вам нужно внести изменение ACL только один раз, вместо того, чтобы динамически корректировать ACL в коде каждый раз, когда пользователь входит в веб-приложение.

Удачи и берегись АдминSDHolder!

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