IT-блоги • Set-ADUser: изменить атрибуты пользователя в Active Directory из PowerShell
Командлет Set-ADUser позволяет изменить значения свойств (атрибутов) пользователя в Active Directory из PowerShell.Традиционно для изменения параметров пользователей AD используется графическая mmc оснастка Active Directory Users and Computers (ADUC). С помощью этой оснастки вы можете отредактировать свойства пользователя или расширенные атрибуты на вкладке Attribute Editor. Однако в консоли ADUC вы не сможете выполнить операцию массового изменения атрибутов у множества пользователя (частично это возможно с помощью сохранённых запросов). В этой статье мы рассмотрим несколько примеров использования командлета Set-ADUser для редактирования свойств пользователей в AD.
Add-WindowsCapability –online –Name “Rsat.ActiveDirectory.DS-LDS.Tools
Как изменить свойства пользователя в AD с помощью PowerShell?
У командлета Get-ADUser есть около 50 параметров, привязанных к атрибутам AD (City, Company, Department, Description, EmailAddress, MobilePhone, Organization, UserPrincipalName и т.д.). Список доступных для использования атрибутов можно вывести командой:
Имя пользователя, свойства которого нужно измененить в AD указывается в обязательном параметре Identity (можно указать в виде sAMAccountName, SID, Distinguished Name или objectGUID).
Например, с помощью командлета Get-ADUser получим значение атрибута Title (должность) у пользователя:
Теперь изменим его должность в AD:
set-aduser a.novak –title “Системный администратор”
Можно изменить значения сразу нескольких атрибутов. Например, зададим новый email адрес и список компьютеров, на которые разрешен вход пользователю:
Set-ADUser a.novak –EmailAddress [email protected] –LogonWorkstations ‘msk-PC213,msk-PC165’
Следующая команда отключит учетную запись пользователя в домене:
Значения остальных атрибутов пользователя (в том числе extensionAttribute, и кастомных атрибутов) в AD можно изменить с помощью следующих параметров командлета Get-ADUser:
Например, чтобы изменить телефон пользователя, можно использовать команду:
Добавить новое значение в атрибут extensionAttribute10:
Очистить значение атрибута:
Можно изменить значение сразу нескольких атрибутов:
Также с помощью этих параметров можно изменить значения мульти-строковых атрибутов. Например, добавим пользователю сразу несколько ProxyAddresses:
Массовое изменение атрибутов пользователей в AD
Вы можете изменить атрибуты сразу нескольких пользователей. Например, следующая команда изменит значение атрибута UserAccountControl и заставит всех пользователей из указанной OU изменить пароль при следующем входе:
Можно массово обновить параметры пользователей в AD значениями из CSV файла. Например, у вас есть CSV файл, который содержит список учетных записей, должностей и телефонов (формат файла: SamAccountName, Title, MobilePhone).
Чтобы внести изменения в свойства пользователей из файла, выполните PowerShell команду:
Import-Csv «C:\ps\modifyad_users.csv» | foreach
Как сохранить имя компьютера в свойствах пользователя в AD?
В одной из предыдущих статей мы показывали, как добавить информацию о пользователе в свойства компьютера в AD с помощью командлета Set-ADComputer. Рассмотрим другой подход – попробуем записать в свойства пользователя информацию о том, на каком компьютере он залогинен.
Это позволит вам быстро найти имя компьютера, на котором в данный момент работает пользователь.
Наш сайт является информационным посредником. Сообщить о нарушении авторских прав.
Атрибуты профиля пользователя
Профиль пользователя Azure Active Directory (Azure AD) B2C поставляется со встроенным набором атрибутов, таких как имя, фамилия, город, почтовый индекс и номер телефона. Вы можете расширить профиль пользователя с помощью собственных данных приложения без использования внешнего хранилища данных.
Большинство атрибутов, которые могут использоваться с профилями пользователей Azure AD B2C, также поддерживаются Microsoft Graph. В этой статье описаны поддерживаемые атрибуты профиля пользователя Azure AD B2C. Здесь также указаны атрибуты, которые не поддерживаются Microsoft Graph, и атрибуты Microsoft Graph, которые не следует использовать с Azure AD B2C.
Не следует использовать встроенные или атрибуты расширения для хранения конфиденциальных персональных данных, таких как учетные данные, идентификационные номера государственных организаций, данные владельцев платежных карт, данные финансовых счетов, сведения медицинского характера или конфиденциальные биографические сведения.
Также поддерживается и интеграция с внешними системами. Например, вы можете использовать Azure AD B2C для проверки подлинности, а доверенным источником данных о пользователях назначить внешнюю систему CRM или базу данных лояльности клиентов. Дополнительные сведения см. в решении, посвященном удаленному профилю.
Ресурс типа «пользователь» в Azure AD
В таблице ниже представлены атрибуты ресурса типа «пользователь», которые поддерживаются профилем пользователя Azure AD B2C Directory. В ней приведены сведения о каждом атрибуте.
)
| Имя | Тип | Описание | Портал Azure | Маршруты пользователей | Настраиваемая политика |
|---|---|---|---|---|---|
| AccountEnabled | Логическое | Указывает на то, включена или отключена ли учетная запись пользователя: true, если учетная запись включена, в противном случае — false. | Да | нет | Persisted, Output |
| ageGroup | Строка | Возрастная группа пользователя. Возможные значения: null, Undefined, Minor, Adult, NotAdult. | Да | нет | Persisted, Output |
| alternativeSecurityId (удостоверения) | Строка | Единственное удостоверение пользователя от внешнего поставщика удостоверений. | нет | нет | Input, Persisted, Output |
| alternativeSecurityIds (удостоверения) | Альтернативная коллекция securityId | Коллекция удостоверений пользователя от внешних поставщиков удостоверений. | нет | нет | Persisted, Output |
| city | Строка | Город, в котором находится пользователь. Максимальная длина — 128 символов. | Да | Да | Persisted, Output |
| consentProvidedForMinor | Строка | Предоставлено ли согласие для несовершеннолетнего. Допустимые значения: null, granted, denied или notRequired. | Да | нет | Persisted, Output |
| country | Строка | Страна или регион, в котором находится пользователь. Пример «США» или «Соединенное Королевство». Максимальная длина — 128 символов. | Да | Да | Persisted, Output |
| createdDateTime | Дата и время | Дата создания объекта «пользователь». Только для чтения. | нет | нет | Persisted, Output |
| creationType | Строка | Если учетная запись пользователя была создана как локальная учетная запись для клиента Azure Active Directory B2C, то используется значение LocalAccount или nameCoexistence. Только для чтения. | нет | нет | Persisted, Output |
| dateOfBirth | Дата | Дата рождения. | нет | нет | Persisted, Output |
| department | Строка | Название отдела, в котором работает пользователь. Максимальная длина — 64 символа. | Да | нет | Persisted, Output |
| displayName | Строка | Отображаемое имя пользователя. Максимальная длина — 256 символов. | Да | Да | Persisted, Output |
| facsimileTelephoneNumber 1 | Строка | Номер телефона факсимильного аппарата пользователя. | Да | нет | Persisted, Output |
| givenName | Строка | Имя пользователя. Максимальная длина — 64 символа. | Да | Да | Persisted, Output |
| jobTitle | Строка | Название должности пользователя. Максимальная длина — 128 символов. | Да | Да | Persisted, Output |
| immutableId | Строка | Идентификатор, который обычно используется для пользователей, перенесенных из локальной службы Active Directory. | Нет | нет | Persisted, Output |
| legalAgeGroupClassification | Строка | Юридическая классификация возрастных групп. Только для чтения и вычисляется на основе свойств ageGroup и consentProvidedForMinor. Допустимые значения: NULL, minorWithOutParentalConsent, minorWithParentalConsent, minorNoParentalConsentRequired, notAdult и adult. | Да | нет | Persisted, Output |
| legalCountry 1 | Строка | Страна или регион для юридических целей. | нет | нет | Persisted, Output |
| mailNickName | Строка | Псевдоним почты для пользователя. Максимальная длина — 64 символа. | нет | нет | Persisted, Output |
| mobile (mobilePhone) | Строка | Основной номер сотового телефона для пользователя. Максимальная длина — 64 символа. | Да | нет | Persisted, Output |
| netId | Строка | Идентификатор сети. | нет | нет | Persisted, Output |
| objectId | Строка | Глобальный уникальный идентификатор (GUID), который является уникальным идентификатором пользователя. Пример 12345678-9abc-def0-1234-56789abcde. Только для чтения, неизменяемый. | Только для чтения | Да | Input, Persisted, Output |
| otherMails | Коллекция строк | Список других адресов электронной почты этого пользователя. Например: [«bob@contoso.com», «Robert@fabrikam.com»]. Примечание. Символы с диакритическими знаками не допускаются. | Да (дополнительный адрес электронной почты) | нет | Persisted, Output |
| password | Строка | Пароль для локальной учетной записи во время создания пользователя. | нет | нет | Persisted |
| passwordPolicies | Строка | Политика пароля. Это строка, состоящая из имени другой политики через запятую. Например: «DisablePasswordExpiration, DisableStrongPassword». | Нет | нет | Persisted, Output |
| physicalDeliveryOfficeName (officeLocation) | Строка | Расположение офиса в компании пользователя. Максимальная длина — 128 символов. | Да | нет | Persisted, Output |
| postalCode | Строка | Почтовый индекс для почтового адреса пользователя. Почтовый индекс зависит от страны или региона пользователя. В США этот атрибут содержит ZIP-код. Максимальная длина — 40 символов. | Да | нет | Persisted, Output |
| preferredLanguage | Строка | Предпочитаемый язык для пользователя. Формат предпочитаемого языка основан на стандарте RFC 4646. Имя языка состоит их двухбуквенного кода культуры ISO 639 в нижнем регистре (определяет язык) и двухбуквенного кода субкультуры ISO 3166 в верхнем регистре (определяет страну или регион). Например: en-US или es-ES. | Нет | нет | Persisted, Output |
| refreshTokensValidFromDateTime (signInSessionsValidFromDateTime) | Дата и время | Все маркеры обновления, выданные до этого времени, являются недействительными, и приложения будут получать ошибку при использовании недействительного маркера обновления для получения нового маркера доступа. В этом случае приложению потребуется получить новый маркер обновления, выполнив запрос авторизации. Только для чтения. | нет | нет | Выходные данные |
| signInNames (удостоверения) | Строка | Уникальное имя для входа пользователя локальной учетной записи любого типа в каталоге. Используйте этот атрибут, чтобы получить пользователя со значением входа без указания типа локальной учетной записи. | Нет | нет | Входные данные |
| signInNames.userName (удостоверения) | Строка | Уникальное имя пользователя локальной учетной записи в каталоге. Используйте этот атрибут, чтобы создать или получить пользователя с указанным именем пользователя для входа. Указание этого параметра только лишь в PersistedClaims во время операции исправления приведет к удалению других типов signInNames. Чтобы добавить новый тип signInNames, необходимо также сохранить существующий signInNames. Примечание. В имени пользователя не допускаются символы с диакритическими знаками. | Нет | нет | Input, Persisted, Output |
| signInNames.phoneNumber (удостоверения) | Строка | Уникальный номер телефона локальной учетной записи в каталоге. Используйте этот атрибут, чтобы создать или получить пользователя с указанным номером телефона. Указание этого параметра только в PersistedClaims во время операции Patch приведет к удалению других типов signInNames. Чтобы добавить новый тип signInNames, необходимо также сохранить существующий signInNames. | нет | нет | Input, Persisted, Output |
| signInNames.emailAddress (удостоверения) | Строка | Уникальный адрес электронной почты локальной учетной записи в каталоге. Используйте этот параметр, чтобы создать или получить пользователя с указанным адресом электронной почты для входа. Указание этого параметра только в PersistedClaims во время операции Patch приведет к удалению других типов signInNames. Чтобы добавить новый тип signInNames, необходимо также сохранить существующий signInNames. | нет | нет | Input, Persisted, Output |
| state | Строка | Область или край в адресе пользователя. Максимальная длина — 128 символов. | Да | Да | Persisted, Output |
| streetAddress | Строка | Почтовый адрес организации пользователя. Максимальная длина — 1024 символа. | Да | Да | Persisted, Output |
| strongAuthentication AlternativePhoneNumber 1 | Строка | Дополнительный номер телефона пользователя для многофакторной проверки подлинности. | Да | нет | Persisted, Output |
| strongAuthenticationEmailAddress 1 | Строка | SMTP-адрес для пользователя. Пример: «bob@contoso.com». Этот атрибут используется для входа с помощью политики имени пользователя для хранения адреса электронной почты пользователя. Адрес электронной почты, который затем используется в потоке сброса пароля. В этом атрибуте не допускается использование символов с диакритическими знаками. | Да | нет | Persisted, Output |
| strongAuthenticationPhoneNumber 2 | Строка | Основной номер телефона пользователя для многофакторной проверки подлинности. | Да | нет | Persisted, Output |
| surname | Строка | Фамилия пользователя. Максимальная длина — 64 символа. | Да | Да | Persisted, Output |
| telephoneNumber (первая запись businessPhones) | Строка | Основной номер телефона организации пользователя. | Да | нет | Persisted, Output |
| userPrincipalName | Строка | Имя участника-пользователя (UPN) этого пользователя. UPN — это атрибут, который является именем пользователя для входа через Интернет на основе интернет-стандарта RFC 822. Домен должен присутствовать в коллекции подтвержденных доменов клиента. Это свойство является обязательным при создании учетной записи. Неизменяемый. | нет | нет | Input, Persisted, Output |
| usageLocation | Строка | Требуется для пользователей, которым будут назначены лицензии в соответствии с юридическим требованием для проверки доступности служб в странах и регионах. Не допускает значения NULL. Двухбуквенный код региона или страны (в соответствии со стандартом ISO 3166). Примеры: «US», «JP» и «GB». | Да | нет | Persisted, Output |
| userType | Строка | Значение строки, которое будет использоваться для классификации типов пользователей в вашем каталоге. Значение должно быть «Member». Только для чтения. | Только для чтения | нет | Persisted, Output |
| userState (externalUserState) 3 | Строка | Только для учетной записи Azure AD B2B. Указывает, является ли приглашение PendingAcceptance или Accepted. | нет | нет | Persisted, Output |
| userStateChangedOn (externalUserStateChangeDateTime) 2 | Дата и время | Показывает метку времени для последних изменений в свойстве UserState. | нет | нет | Persisted, Output |
1 Не поддерживается Microsoft Graph
2 Дополнительные сведения см. в статье об атрибуте номера телефона для MFA
3 Не следует использовать с Azure AD B2C
Требуемые атрибуты
Чтобы создать учетную запись пользователя в каталоге Azure AD B2C, укажите следующие необходимые атрибуты:
Удостоверения — укажите по крайней мере один объект (локальную или федеративную учетную запись).
Профиль пароля — если вы создаете локальную учетную запись, укажите профиль пароля.
Атрибут отображаемого имени
Имя displayName отображается для пользователя на портале Azure в разделе управления пользователями, а также передается приложению в маркере доступа Azure AD B2C. Это свойство обязательно.
Атрибут identities
Учетная запись клиента (потребителя, партнера или гражданина) может быть связана с удостоверениями следующих типов.
Пользователь с учетной записью потребителя может использовать для входа в систему несколько удостоверений. Эту роль могут выполнять имя пользователя, адрес электронной почты, идентификатор сотрудника, удостоверение личности и т. д. Одна учетная запись может иметь несколько удостоверений (локальных и федеративных) с одним и тем же паролем.
Следующий атрибут identities определяет удостоверение локальной учетной записи с именем для входа, адресом электронной почты в качестве имени для входа и удостоверением социальных сетей.
Для федеративных удостоверений значение issuerAssignedId является уникальным идентификатором пользователя для приложения или учетной записи разработки, как определено поставщиком удостоверений. Настройте политику Azure AD B2C для того же идентификатора приложения, который был ранее назначен поставщиком удостоверения социальных сетей или другим приложением в той же учетной записи разработки.
Свойство профиля пароля
Для локального удостоверения обязательным является атрибут passwordProfile, который содержит пароль пользователя. Атрибут forceChangePasswordNextSignIn указывает, должен ли пользователь сбрасывать пароль при следующем входе в систему. Для обработки принудительного сброса пароля необходимо настроить поток принудительного сброса пароля.
Для федеративного (социального) удостоверения атрибут passwordProfile не требуется.
Атрибут политики паролей
Политика паролей Azure AD B2C (для локальных учетных записей) основывается на политике высокой надежности пароля в Azure Active Directory. В политиках регистрации, входа и сброса пароля Azure AD B2C предусмотрено использование надежного пароля, а срок действия паролей не истекает.
Атрибут номера телефона для многофакторной проверки подлинности
Если для многофакторной проверки подлинности (MFA) задан номер телефона, то он используется для идентификации пользователя. Чтобы добавить, обновить, получить или удалить номер телефона программным способом, используйте метод проверки подлинности с помощью телефона в API MS Graph.
Атрибуты расширения
Каждое приложение, взаимодействующее с пользователями, имеет уникальные требования к сбору информации. Клиент Azure AD B2C поставляется со встроенным набором сведений, хранящихся в свойствах, таких как имя, фамилия и почтовый индекс. С помощью Azure AD B2C можно расширить набор свойств, хранящихся в каждой учетной записи пользователя. Дополнительные сведения см. в статье Добавление атрибутов пользователя и настройка ввода данных пользователем в Azure Active Directory B2C.
При определении атрибута в расширении схемы поддерживаются следующие типы данных:
Актуализируем учетные данные Active Directory
Многие помнят то чувство, когда компания расширяется до тех размеров, когда рабочих групп недостаточно, и поднимается первый домен Active Directory: «О, уж теперь-то все будет как следует!» Ан нет, домен потихонечку разрастается, создаются новые учетки, блокируются старые, добавляются, удаляются компьютеры, девушки выходят замуж, меняют фамилии и, в конце концов, база данных службы каталогов выглядит, как полный швах. В этом топике мы наладим связь между базой Active Directory и кадровой системой предприятия, а также создадим механизм для поддержания данных сотрудников в AD в актуальном состоянии.
Первым делом, мы опишем требования, которые мы должны предъявить к учетным записям сотрудников. А эти требования мы постараемся прикинуть, исходя из потребностей пользователя. Не секрет, что многие корпоративные системы, использующие аутентификацию через Active Directory, для отображения и в своих админках, и просто в ходе работы зачастую используют разнообразные поля учетных записей AD: это и Sharepoint, и Citrix, и многие-многие другие. В качестве примера такой системы я возьму известный всем MS Outlook, да не полностью, а лишь его адресную книгу, которая черпает свои данные напрямую из Active Directory.
Механизм
Само собой ясно, что для того, чтобы связать персону из кадровой системы и персону из Active Directory, необходимо иметь некий идентификатор, связывающий эти две записи. Обычно таким идентификатором является табельный номер сотрудника, он присваивается при приеме на работу и более никогда не меняется, вместе с тем, я встречался с ситуациями, когда и табельный номер не статичен, в этом случае такой идентификатор следует выдумать.
Сведения о пользователе Active Directory не исчерпываются сведениями, которые можно увидеть в оснастке Active Directory Users and Computers (устоявшееся сокращение ADUC), причем очень далеко не исчерпываются. На самом деле объект пользователя имеет триллион атрибутов, и эти атрибуты даже могут быть добавлены администратором схемы. Например, есть такой атрибут, как carLicense, содержащий информацию о водительском удостоверении, или drink, характеризующий любимый напиток пользователя. В общем, Microsoft в этом смысле предусмотрела многое.
Использовать в моем примере я буду атрибуты employeeID для хранения идентификатора пользователя, и flags, для чего именно, сообщу чуть позже.
К делу
Первым делом следует проставить employeeID, который у нас представляет табельный номер, всем пользователям. Если пользователей мало, то сделать это проще всего через ADSI Edit, если их чуть больше, то можно прикрутить скрипт для прописывания, например вот так. А если пользователей много, расстановку идентификаторов необходимо делегировать, хочется приятный интерфейс и используются дополнительные фенечки, то можно создать вот такую дополнительную вкладку в ADUC:
впрочем, создание такой вкладки это само по себе тема для отдельного топика.
Второе тонкое место в том, что иногда случается так, что для некоторых людей менять следует только некоторые атрибуты. Есть, например, у нас сотрудник, назовем его Кудрымунбеков Садруддин Фатхулларович, но все его называют просто Сан Саныч. А есть генеральный директор, должность которого в кадрах записана не иначе, как Генеральный Директор Открытого Акционерного Общества Дальней Космической Связи «Рога И Копыта», которого в AD лучше бы просто оставить точно со связью, но точно без рогов и копыт. Таким образом, мы видим необходимость в закладывании в логику работы нашего приложения некоторых исключений, а хранить эти исключения мы будем там же, в Active Directory в атрибуте flags. Этот атрибут имеет величину в четыре байта, а значит, устанавливая тот или иной бит в то или иное значение, мы сможем при необходимости запомнить аж 32 исключения. Впрочем, использовать мы все равно будем только шесть.
Переходим к реализации на powershell:
Создадим тестовую среду, абсолютно произвольно присвоим имена учетным записям:
Теперь запускаем скрипт с параметрами. Разумеется, его можно зашедулить и выполнять по расписанию, только не забыть учетной записи, от имени которой выполняется задание, присвоить право входа в качестве пакетного задания:
Как видим, после выполнения, мы получили хорошие читаемые имена, отличные должности и великолепные наименования компаний:
Конечно, путем неглубокой модификации скрипта, мы можем заполнять пользователю все: от телефонов и адресов до пресловутых любимых напитков, был бы источник. А если скрипт запускать с определенной регулярностью, то мы добиваемся того, что все данные о пользователях будут актуальны.
upd Подправил маленькую ошибочку, перенес обнуление флажков во внутрь цикла