Samaccountname vs userprincipalname

Step 2: Change the UPN in the Azure AD

To change a single user’s UPN in the
Azure AD, you can use the following cmdet.

Import-Module MSONLINE

Connect-MSOLSERVICE

Set-MsolUserPrincipalName -UserPrincipalName <Current UPN>
-NewUserPrincipalName <New UPN>

For bulk changes, below mentioned
PowerShell script is recommended.

1.Prepare CSV file of users
in the below format. Save the file as ‘Change-UPN-AzureAD-Users.csv’. You can use any other file name. Just remember to use it in the next
step if you change it.
Example CSV format:

SamAccountName	NewUserprincipalName
sandeep.verma	[email protected]

2.Type
the following and hit enter when completed:

Import-Module MSONLINE

Connect-MSOLSERVICE

Import-Csv .\Change-UPN-AzureAD-Users.csv | foreach-object {

Write-host “Changing UPN for user $($_.UserPrincipalName) to $($_.NewUserPrincipalName)”
-Foregroundcolor Cyan

Set-MsolUserPrincipalName -UserPrincipalName $_.UserPrincipalName -NewUserPrincipalName
$_.NewUserPrincipalName }

3.Verify by GUI or
PowerShell.

Import-Csv .\Change-UPN-AD-Users.csv |
foreach-object {Get-ADUser -identity $_.SamAccountName | Select SamAccountName,
UserPrincipalName

Note:

If you try changing the UPN from a
managed domain to a federated domain, the following error will appear.

Set-MsolUserPrincipalName : You must provide a
required property: Parameter name: FederatedUser.SourceAnchor

If you have such a scenario, leave a comment for help.

Как управлять учетными записями пользователей в Active Directory. Часть 1: Создание и удаление пользователей

Пользовательские учетные записи одни из самых популярных объектов в AD. Они нужны для аутентификации и авторизации на рабочих компьютерах и во многих сервисах, интегрированных с AD. Решение различных проблем связанных с УЗ пользователей, а так же управление ими является одной из главных рутин для администраторов и специалистов хелпдеска. Данное руководство поможет вам сделать это несколькими способами. Чтобы управлять УЗ пользователей, необходимо войти на контроллер домена или сервер или устройство с установленными средствами удаленного администрирования сервера (RSAT) для Active Directory Domain Services.

Для того чтобы не было ошибок доступа, нам нужен аккаунт администратора домена или группы операторов учетных записей (Account Operators group), либо УЗ, которая делегирована на создание пользовательских объектов в домене или в нужной нам организационной единице (OU), которую мы будем использовать для хранения аккаунтов.

Создание учетной записи пользователя с помощью ADUC

Запустите Active Directory Users and Computers (dsa.msc).

Перейдите в нужную вам OU (organizational unit) или контейнер. На панели задач нажмите на значок New User, или щелкните правой кнопкой мыши пустое место в главном окне и выберите New -> User из меню, или щелкните правой кнопкой по выбранному вами OU или контейнеру и выберите New -> User.

Появится окно New Object — User, укажите параметры для вашего пользователя:

Full Name, введите полное имя в поле Full Name или введите отдельно фамилию и имя в поля First Name и Last Name.
User logon name — Имя логина пользователя, данный параметр создаст атрибут userPrincipalName и атрибут sAMAccountName, которые пользователь будет вводить при входе в систему.

Нажмите Next и укажите Пароль, затем наберите его во втором поле и отметьте нужные настройки, обычно для нового пользователя нужно отметить «User must change password at next logon«(Пользователь должен сменить пароль при следующем входе).

Нажмите Next и Finish. Поздравляем, учетная запись пользователя успешно создана!

Создание УЗ пользователя с помощью cmd.exe

Используйте следующую команду с необходимыми параметрами для создания объекта пользователя в контейнере «Users«, имя пользователя в примере будет GSoul:

dsadd.exe user «CN=GSoul,CN=Users,DC=office,DC=local» -upn [email protected] -fn «Gordon» -ln «Soul» -display «Gordon Soul» -pwd «P@&&W0rd»

Создание учетной записи пользователя с помощью Windows PowerShell

Запустите следующий код PowerShell с правами администратора:

Import-Module ActiveDirectory New-ADUser -Name FRobinson -Path «CN=Users,DC=office,DC=local» -GivenName «Frank» -Surname «Robinson» -sAMAccountName FRobinson

Как удалить учетную запись пользователя

Для того чтобы удалить пользователя из Active Directory, используйте один из следующих методов

Обратите внимание, что это не приведет к полному удалению УЗ, если у вас настроена корзина AD Recycle Bin

Удаление учетной записи пользователя с помощью Active Directory Users and Computers

Чтобы удалить пользователя из домена, откройте Active Directory Users and Computers (dsa.msc).

Нажмите на меню View, включите Advanced Features. Перейдите в OU или контейнер, где находится объект пользователя, который вы собираетесь удалить. В меню Action выберите Find.

В поле Name введите имя пользователя, которого вы хотите удалить, и нажмите кнопку «Find now«. В списке результатов поиска выберите нужного пользователя.

Щелкните правой кнопкой мыши на пользователя и выберите из списка пункт «Delete«, а затем «Yes«.

Удаление учетной записи пользователя с помощью командной строки

Следующая команда удаляет пользователя «GSoul» из контейнера “Users” из домена office.local:

dsrm.exe «CN=Gregory Soul,CN=Users,DC=office,DC=local»

Удаление учетной записи пользователя с помощью Windows PowerShell

Используйте следующий PowerShell код для удаления пользователя из AD, синтаксис для примера использован такой же, как и в примере выше:

Import-Module ActiveDirectory Remove-ADUser -Identity «CN=GSoul,CN=Users,DC=office,DC=local»

Вопросы по синхронизации и безопасности хэша паролей

При включении Azure AD DS необходимо использовать устаревшие хэши паролей для проверки подлинности NTLM + Kerberos. Azure AD не хранит пароли в виде открытого текста, поэтому эти хэши нельзя создать автоматически для существующих учетных записей пользователей. После создания и сохранения хэши паролей в форматах, совместимых с NTLM и Kerberos, всегда хранятся в Azure AD в зашифрованном виде.

Ключи шифрования являются уникальными для каждого арендатора Azure AD. Эти хэши шифруются таким образом, что только доменные службы Azure AD DS имеют доступ к ключам шифрования. Другие службы или компоненты в Azure AD не имеют доступа к этим ключам.

Затем устаревшие хэши паролей синхронизируются из Azure AD в контроллеры домена для управляемого домена. Диски для этих контроллеров управляемых доменов в Azure AD DS шифруются при хранении. Хранение и защита этих хэшей паролей выполняется в контроллерах домена (аналогично хранению и защите паролей в локальной среде AD DS).

Для облачных сред Azure AD: , чтобы создать и сохранить в Azure AD необходимые хэши паролей. Для любой облачной учетной записи пользователя в Azure AD хэши паролей сохраняются и создаются в совместимых форматах NTLM и Kerberos после включения доменных служб Azure AD. Пароли всех учетных записей пользователей облака должны быть изменены, прежде чем учетные данные будут синхронизированы с Azure AD DS.

Для гибридных учетных записей пользователей, синхронизируемых из локальной среды AD DS с помощью службы Azure AD Connect, необходимо настроить Azure AD Connect для синхронизации хэшей паролей в совместимых форматах NTLM и Kerberos.

One-to-one mapping

По умолчанию, каждый сертификат привязывается только к учётной записи, в свойствах которой он опубликован. На практике вы будете с этим работать в 99% случаев использования явного маппинга сертификата к учётной записи.

Суть этого метода заключается в том, что определённые свойства сертификата должны быть описаны в атрибуте altSecurityIdentities (доступно через Attribute Editor) свойств учётной записи пользователя. Вот как можно создать маппинг one-to-one в консоли Active Directory Users and Computers:

Откройте оснастку Active Directory Users and Computers (dsa.msc);
В меню View установите флажок на Advanced Features;
Выберите учётную запись пользователя, с которой будут связываться сертификаты группы работников;
В контекстном меню выберите Name Mappings;
В открывшемся окне, кнопкой Add добавляете необходимые сертификаты.

Смотрите, здесь уже используется (и не отключается) маппинг по Issuer DN Name и Subject DN Name. Т.е. если контроллеру предъявляют сертификат с такими же значениями полей Subject и Issuer, он привяжет этот сертификат к этой учётной записи, где настроен маппинг. Если снять чек-бокс «Use Subject for alternate security identity», любые сертификаты, выданные конкретным сервером CA будут мапиться к этой учётной записи и это будет many-to-one certificate mapping. Но не следует использовать маппинг только по издателю. О более гибких примерах маппинга мы поговорим ниже. Вот пример:

В данном случае любой сертификат с конкретным Subject DN, который выдан конкретным CA будет мапиться к рассматриваемой учётной записи.

Создание пользователей c помощью VBScript

VBScript является одним из самых мощных инструментов, предназначенных для автоматизации административных задач. Данный инструмент позволяет создавать сценарии, предназначенные для автоматизирования большинства действий, которые могут выполняться посредством пользовательского интерфейса. Сценарии VBScript представляют собой текстовые файлы, которые обычно пользователи могут редактировать при помощи обыкновенных текстовых редакторов (например, Блокнот). А для выполнения сценариев нужно просто дважды щелкнуть мышью по значку самого сценария, который откроется с применением команды Wscript. Для того чтобы создать пользовательскую учетную запись в VBScript не существует определенной команды, поэтому вам сначала нужно подключиться к контейнеру, затем использовать библиотеку адаптеров Active Directory Services Interface (ADSI) при помощи инструкции Get-Object, где выполняется строка запроса LDAP, предоставляющая собой моникер протокола LDAP:// с DN именем объекта. Например, Set objOU=GetObject(“LDAP://OU=Маркетинг,OU=Пользователи,dc=testdomain,dc=com”). Вторая строка кода активирует метод Create подразделения для создания объекта конкретного класса с конкретным отличительным именем, например, Set objUser=objOU.Create(“user”,”CN= Юрий Соловьев”). В качестве третьей строки указывается метод Put, где нужно указать наименование атрибута и его значение. Последняя строка данного сценария подтверждает сделанные изменения, то есть objUser.SetInfo().

Пример использования:

Set objOU=GetObject(“LDAP://OU=Маркетинг,OU=Пользователи,dc=testdomain,dc=com”
Set objUser=objOU.Create(“user”,”CN= Юрий Соловьев”)
objUser.Put “sAMAccountName”,”Yuriy.Soloviev”
objUser.Put “UserPrincipalName” [email protected]”
objUser.Put “givenName”,”Юрий”
objUser.Put “sn”Соловьев”
objUser.SetInfo()

UPN scenarios

The following are example scenarios of how the UPN is calculated based on the given scenario.

Scenario 1: Non-verified UPN suffix – initial synchronization

On-Premises user object:

mailNickName : <not set>
proxyAddresses : {SMTP:[email protected]}
mail : [email protected]
userPrincipalName : [email protected]

Synchronized the user object to Azure AD Tenant for the first time

Set Azure AD MailNickName attribute to primary SMTP address prefix.
Set MOERA to <MailNickName>@<initial domain>.
Set Azure AD UserPrincipalName attribute to MOERA.

Azure AD Tenant user object:

MailNickName : us1
UserPrincipalName : [email protected]

Scenario 2: Non-verified UPN suffix – set on-premises mailNickName attribute

On-Premises user object:

mailNickName : us4
proxyAddresses : {SMTP:[email protected]}
mail : [email protected]
userPrincipalName : [email protected]

Synchronize update on on-premises mailNickName attribute to Azure AD Tenant

Update Azure AD MailNickName attribute with on-premises mailNickName attribute.
Because there is no update to the on-premises userPrincipalName attribute, there is no change to the Azure AD UserPrincipalName attribute.

Azure AD Tenant user object:

MailNickName : us4
UserPrincipalName : [email protected]

Scenario 3: Non-verified UPN suffix – update on-premises userPrincipalName attribute

On-Premises user object:

mailNickName : us4
proxyAddresses : {SMTP:[email protected]}
mail : [email protected]
userPrincipalName : [email protected]

Synchronize update on on-premises userPrincipalName attribute to Azure AD Tenant

Update on on-premises userPrincipalName attribute triggers recalculation of MOERA and Azure AD UserPrincipalName attribute.
Set MOERA to <MailNickName>@<initial domain>.
Set Azure AD UserPrincipalName attribute to MOERA.

Azure AD Tenant user object:

MailNickName : us4
UserPrincipalName : [email protected]

On-Premises user object:

mailNickName : us4
proxyAddresses : {SMTP:[email protected]}
mail : [email protected]
userPrincipalName : [email protected]

Synchronize update on on-premises mail attribute and primary SMTP address to Azure AD Tenant

After the initial synchronization of the user object, updates to the on-premises mail attribute and the primary SMTP address will not affect the Azure AD MailNickName or the UserPrincipalName attribute.

Azure AD Tenant user object:

MailNickName : us4
UserPrincipalName : [email protected]

Scenario 5: Verified UPN suffix – update on-premises userPrincipalName attribute suffix

On-Premises user object:

mailNickName : us4
proxyAddresses : {SMTP:[email protected]}
mail : [email protected]
userPrincipalName : [email protected]

Synchronize update on on-premises userPrincipalName attribute to the Azure AD Tenant

Update on on-premises userPrincipalName attribute triggers recalculation of Azure AD UserPrincipalName attribute.
Set Azure AD UserPrincipalName attribute to on-premises userPrincipalName attribute as the UPN suffix is verified with the Azure AD Tenant.

Azure AD Tenant user object:

MailNickName : us4
UserPrincipalName : [email protected]

How to Add Alternative UPN Suffix in Active Directory?

In Active Directory, you can add additional (alternative) UPN suffixes using the Active Directory Domains and Trusts graphic console or PowerShell.

Open a PowerShell console and run the Get-ADForest command from the AD PowerShell module. The command below will list all assigned UPN suffixes in the forest:

If the list is empty, it means that you are using a default UPN suffix matching your DNS domain name.

To add an alternative UPN suffix (for example, ), run this command:

Make sure that the suffix appeared in UPNSuffixes:

You can add multiple unique UPN suffixes. Usually, it is worth doing if you have users from different organizations (brands) in your domain and you want to use different UPN suffixes for them.

You can also add a UPN suffix using the Active Directory Domains and Trusts console;
Run the snap-in;
Open the Active Directory Domains and Trusts properties;
Add a new suffix to the Alternative UPN suffixes box and click Add.

Kerberoasting

Реализация протокола Kerberos в Windows использует имена участников службы (SPN) для определения того, какую учетную запись задействовать для шифрования билета службы. В Active Directory существует два варианта SPN: SPN на основе хоста и произвольные SPN. Первый вариант SPN связан с учетной записью компьютера домена, а второй обычно (но не всегда) — с учеткой пользователя домена.

В документации Microsoft написано буквально следующее: «Когда в Active Directory создается новая учетная запись компьютера, для встроенных служб автоматически создаются имена участников-служб. В действительности имена участников-служб создаются только для службы HOST, а все встроенные службы используют имя участника-службы HOST». Но так как пароль учетной записи компьютера по умолчанию рандомный и меняется каждые 30 дней, оператор в контексте данной атаки, как правило, не обращает внимания на имена SPN на основе хоста.

Произвольные имена участников-служб также могут быть зарегистрированы для учетных записей пользователей домена. Наример, учетная запись службы, которая управляет несколькими экземплярами MSSQL. Таким образом, учетная запись пользователя по умолчанию будет иметь SPN для каждого экземпляра MSSQL, для которого она зарегистрирована. Эта учетная запись хранится в атрибуте профиля пользователя.

Как следует из специфики работы Kerberos, любой пользователь может запросить TGS для любой службы, имеющей зарегистрированное SPN для учетной записи пользователя или компьютера в Active Directory. Таким образом, зная учетные данные любого пользователя домена и SPN учетных записей из домена, оператор может запросить TGS от имени пользователя для данных экземпляров SPN. А взломав TGS, узнать пароли от этих учетных записей.

Схема атаки Kerberoasting

Выполнить атаку можно как удаленно, так и при наличии непосредственного доступа к системе. Но для начала нужно получить все SPN из системы. Если есть доступ, следует использовать встроенное решение setspn.

Получение SPN с помощью setspn

Указанным способом мы получаем SPN пользователя , а это означает, что он уязвим к такой атаке. Локально получить билет можно с помощью Rubeus.

Получение билета с помощью Rubeus

Для удаленного получения SPN и билета необходимы учетные данные любого пользователя домена.

Получение билета с помощью impacket

Для взлома используется hashcat.

Результат работы hashcat

Kerberoasting можно также выполнить, перехватив сетевой трафик и захватив билеты Kerberos TGS в случае MITM.

Терминология

Если вы не знакомы с AD, здесь приведены некоторые ключевые слова, которые будет полезно знать.

Домен(Domain) : Имя,используемое для группы компьютеров и аккаунтов.
SID : Каждый компьютер,присоединяющийся к сети должен иметь уникальный SID / Системный идентификатор.
SMB : Блок сообщения сервера.
NETBIOS: Network naming protocol used as an alternative to DNS. Mostly legacy, but still used in Windows Networking.
WINS: Windows Information Naming Service. Used for resolving Netbios names to windows hosts.
Winbind: Protocol for windows authentication. Протокол для авторизации windows.

Изменение метода входа пользователя

После начальной настройки Azure AD Connect с помощью мастера можно изменить метод входа пользователя с федерации на синхронизацию хэша паролей или сквозную аутентификацию, используя задачи, доступные в Azure AD Connect. Повторно запустите мастер Azure AD Connect. Отобразится список задач, которые можно выполнить. Из списка задач выберите Смена имени пользователя для входа.

На следующей странице вам будет предложено ввести учетные данные для Azure AD.

На странице Вход пользователя выберите нужный вариант входа в систему.

Примечание

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

Управление подразделениями

Организационная единица или, подразделение (OU) — это субконтейнер в AD, в который можно помещать пользователей, группы, компьютеры и другие объекты AD. OU могут быть вложенными, и к ним можно применять групповые политики.

Создание подразделения

В контекстном меню контейнера выберите пункт «Создать»→«Подразделение».
Откроется окно «Создать подразделение — ADMC»:
В поле «Имя» введите название подразделения.
Нажмите кнопку «ОК».

Для изменения подразделения следует в контекстном меню подразделения выбрать соответствующее действие:

Переименовать подразделение

В контекстном меню подразделения выбрать пункт «Переименовать».
Откроется окно «Переименовать объект — ADMC»:
Измените название подразделения.
Нажмите кнопку «ОК» для сохранения изменений.

Удалить подразделение

В контекстном меню подразделения выберите пункт «Удалить».
Подтвердите удаление, нажав кнопку «Да»:

Примечание: Если при создании подразделения был отмечен пункт «Защитить от удаления», то сразу удалить подразделение не получится, необходимо сначала снять данную отметку в окне свойств подразделения:

Переместить подразделение

В контекстном меню подразделения выбрать пункт «Переместить…».
В диалоговом окне «Выбор контейнера — ADMC» выберите контейнер, в который следует переместить подразделение.
Нажмите кнопку «ОК».

Local Administrator Password Solution

Local Administrator Password Solution (LAPS) — система, предназначенная для управления паролями локальных администраторов на компьютерах домена. Она позволяет администратору домена периодически менять пароль учетной записи локальных администраторов, делегировать права на чтение и сброс пароля для пользователей или групп Active Directory, а также обеспечивает хранение паролей в расширенном атрибуте объекта компьютера в Active Directory. Система состоит из трех компонентов: агента, модуля PowerShell для настройки системы, Active Directory для хранения паролей.

Есть два способа обнаружить LAPS.

На всех хостах, где установлен LAPS, в папке C:\Program Files\LAPS\CSE\ будет файл AdmPwd.dll.
Конфигурации LAPS определяются в объектах групповой политики. Командой Get-DomainGPO -Identity «*LAPS*» можно поискать любой объект групповой политики, у которого есть слово LAPS в отображаемом имени.

1
2
3
4
5

displaynameLAPS

…

gpcfilesyspath\\test.local\SysVol\test.local\Policies\{C3801BA8-56D9-4F54-B2BD-FE3BF1A71BAA}

distinguishednameCN={C3801BA8-56D9-4F54-B2BD-FE3BF1A71BAA},CN=Policies,CN=System,DC=testlab,DC=local

…

GPRegistryPolicy

1	Parse-PolFile»\\test.local\SysVol\test.local\Policies\{C8701BA8-56D9-4123-B6B2-FE3FA5031BAA}\Machine\Registry.pol»

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29