Имя входа пользователя пред windows 2000

Обновлено 22.07.2020

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов в рунете Pyatilistnik.org. В прошлый раз мы с вами разобрали всевозможные виды RAID массивов и как и где их применяют. Движемся дальше и сегодня я вам хочу рассказать, о интересной ситуации при создании учетной записи в Active Directory, при попытке это осуществить я получил ошибку «Windows не удается создать новый объект пользователя«. Давайте разбираться в чем дело.

Описание ситуации вызвавшей ошибку

Появилась у меня тут задача создать одну сервисную учетную запись, с помощью которой планировалось запускать сервис на сервере. В качестве имени было выбрано proxy. Когда я открыл оснастку «Active Directory — Пользователи и компьютеры», то на финальном шаге, где нужно было нажать кнопку «Готово» я получил ошибку:

В английском варианте это будет выглядеть вот так:

Устранение ошибки имя входа используется в Windows 2000

Если внимательно вчитаться, то Active Directory нам сообщает, что в вашем домене присутствует учетная запись у которой такой же SamAccountName.

Напоминаю прописные истины Active Directory:

• Имя входа пользователя (пред-Windows 2000), оно же SamAccountName должно быть уникальным в домене, чтобы обеспечить обратную совместимость с Windows NT 4.0.
• Имя входа пользователя (Usеr Principal Name, UPN) оно же UserPrincipalName, должно быть уникальным в рамках всего леса.

Так, что если вы видите ошибку «Windows не удается создать новый объект пользователя, так как уже используется имя входа» при создании нового пользователя, она связана по трем причинам:

1. У вас есть дублирующая учетная запись пользователя в домене с таким же SamAccountName
2. У вас есть контакт у которого такое же имя
3. Вы пытаетесь создать учетную запись, SamAccountName, которой зарезервирован самой системой и Active Directory.

Перед тем, как мы все решим проблему, я бы хотел вам привести пример с моим тестовым пользователем Барбоскиным Геннадием Викторовичем. Вот о каком значении идет речь в ошибке barboskin.g (Имя входа пользователя (пред-Windows 2000)).

То же самое вы можете вывести через PowerShell и командлет Get-ADUser:

Поиск существующих SamAccountName

Ранее у меня была похожая задача, где мне нужно было производить поиск одинаковых SamAccountName в рамках леса, советую так же посмотреть. Но тут мои поиску сужаются в рамки домена. Искать вы можете двумя методами, через оснастку ADUC и через PowerShell, я не говорю про сторонние утилиты.

Напоминаю, что в моем примере я хотел создать учетную запись PROXY, давайте осуществим поиск по ней.

Как видим PowerShell ничего не нашел

Тоже самое я проделаю и через оснастку «Пользователи и компьютеры«. Для этого нажмите значок лупы и на уровне леса произведите поиск по нужному вам значению. В моем примере по имени PROXY ничего не нашлось и я все продолжал получать ошибку «Windows не удается создать новый объект пользователя, так как уже используется имя входа PROXY, предназначенное для более ранних версий, чем Windows 2000».

Зарезервированные имена в Active Directory

Когда я давным давно готовился к сертификационным экзаменам Microsoft, я много читал при подготовке к ним и припомнил, что Microsoft резервирует красивые имена SamAccountName для себя, под различные встроенные группы и учетные записи, вот подробный список:

• • ANONYMOUS
  • AUTHENTICATED USER
  • BATCH
  • BUILTIN
  • CREATOR GROUP
  • CREATOR GROUP SERVER
  • CREATOR OWNER
  • CREATOR OWNER SERVER
  • DIALUP
  • DIGEST AUTH
  • INTERACTIVE
  • INTERNET
  • LOCAL
  • LOCAL SYSTEM
  • NETWORK
  • NETWORK SERVICE
  • NT AUTHORITY
  • NT DOMAIN
  • NTLM AUTH
  • NULL
  • PROXY
  • REMOTE INTERACTIVE
  • RESTRICTED
  • SCHANNEL AUTH
  • SELF
  • SERVER
  • SERVICE
  • SYSTEM
  • TERMINAL SERVER
  • THIS ORGANIZATION
  • USERS
  • WORLD

И если вы обратите внимание, тут присутствует то имя PROXY, которое запрещено.

Еще я нашел нюансы в этой таблице, сама Microsoft пишет, что все эти имена запрещены к использованию в операционных системах Windows Server 2003 и выше, но есть нюансы. Я для тестирования решил создать на своем контроллере домена Windows Server 2012 R2, учетную запись SERVICE

А вот уже в Windows Server 2016 ее уже нельзя создать, так как там уже она зарезервирована под служебную. Уровень домена Active Directory у меня был Windows Server 2012

Дополнительные ссылки

• https://docs.microsoft.com/en-us/powershell/module/activedirectory/get-aduser?view=winserver2012-ps
• https://support.microsoft.com/en-us/help/909264/naming-conventions-in-active-directory-for-computers-domains-sites-and

На этом у меня все, вы теперь поняли причины по которым вы не сможете создать учетную запись в Active Directory. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.

Локальные учетные записи

Каждый
компьютер с операционными системами
Windows NT/2000/XP/2003 (если это не сервер,
являющийся контроллером домена) имеет
локальную базу данных учетных записей,
называемую базой данных SAM. Эти БД
обсуждались при описании модели
безопасности «Рабочая группа».
Локальные пользователи и особенно
группы используются при назначении
прав доступа к ресурсам конкретного
компьютера даже в доменной модели
безопасности. Общие правила использования
локальных и доменных групп для управления
доступом будут описаны ниже.

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

Доменные
учетные записи пользователей (а также
компьютеров и групп) хранятся в специальных
контейнерах AD. Это могут быть либо
стандартные контейнерыUsers для
пользователей и Computers для
компьютеров, либо созданное администратором
Организационное подразделение (ОП).
Исключение составляют учетные записи
контроллеров домена, они всегда хранятся
в ОП с названием Domain
Controllers.

Рассмотрим
на примерах процесс создания учетных
записей пользователей в БД Active Directory и
разберем основные свойства доменных
учетных записей. Учетные записи для
компьютеров создаются в процессе
включения компьютера в домен.

Создание доменной учетной записи

1. Откроем
   административную консоль » Active
   Directory – пользователи и компьютеры «.

2. Щелкнем
   правой кнопкой мыши на контейнере, в
   котором будем создавать учетную запись,
   выберем в меню команду » Создать »
   и далее — » Пользователь «.

3. Заполним
   поля » Имя «,
   » Фамилия «,
   например, » Иван »
   и » Иванов »
   (в английской версии — First
   Name, Last
   Name ),
   поле » Полное
   имя »
   ( Full
   Name )
   заполнится само.

4. Введем
   » Имя
   входа пользователя »
   ( User
   logon name ),
   например, User1.
   К этому имени автоматически приписывается
   часть вида » @<имя
   домена> «,
   в нашем примере — » @world.ru »
   (полученное имя должно быть уникальным
   в масштабах леса).

5. В
   процессе формирования имени входа
   автоматически заполняется » Имя
   входа пользователя (пред-Windows 2000) »
   ( User
   logon name (pre- Windows 2000) ),
   создаваемое для совместимости с прежними
   версиями Windows (данное имя должно быть
   уникально в масштабе домена). В каждой
   организации должны быть разработаны
   схемы именования пользователей (по
   имени, фамилии, инициалам, должности,
   подразделению и т.д.) В нашем примере
   получится имя «WORLDUser1 «.
   Нажмем кнопку » Далее »
   (рис.
   6.43):

Рис.
6.43. 

1. Вводим
   пароль пользователя (два раза, для
   подтверждения).

2. Укажем
   начальные требования к паролю:

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

• Запретить
  смену пароля пользователем (полезно
  и даже необходимо для учетных записей
  различных системных служб);

• Срок
  действия пароля не ограничен (тоже
  используется для паролей учетных
  записей служб, чтобы политики домена
  не повлияли на функционирование этих
  служб, данный параметр имеет более
  высокий приоритет по сравнению с
  политиками безопасности);

• Отключить
  учетную запись.

Нажмем
кнопку » Далее »
(рис.
6.44):

Рис.
6.44. 

1. Получаем
   итоговую сводку для создаваемого
   объекта и нажимаем кнопку » Готово «.

Внимание!
В упражнениях лабораторных работ дается
задание настроить политики, которые
сильно понижают уровень требований к
паролям и полномочиям пользователей:

• отключается
  требование сложности паролей,

• устанавливается
  минимальная длина пароля, равная 0 (т.е.
  пароль может быть пустым),

• устанавливается
  минимальный срок действия паролей 0
  дней (т.е. пользователь может в любой
  момент сменить пароль),

• устанавливается
  история хранения паролей, равная 0 (т.е.
  при смене пароля система не проверяет
  историю ранее используемых паролей),

• группе
  «Пользователи» дается право
  локального входа на контроллеры домена.

Данные
политики устанавливаются исключительно
для удобства выполнения упражнений,
которые необходимо выполнять с правами
простых пользователей на серверах-контроллерах
домена. В реальной практике администрирования
такие слабые параметры безопасности
ни в коем случае устанавливать нельзя,
требования к паролям и правам пользователей
должны быть очень жесткими (политики
безопасности обсуждаются далее в этом
разделе).

Правила
выбора символов для создания пароля:

• длина
  пароля — не менее 7 символов;

• пароль
  не должен совпадать с именем пользователя
  для входа в систему, а также с его обычным
  именем, фамилией, именами его родственников,
  друзей и т.д.;

• пароль
  не должен состоять из какого-либо слова
  (чтобы исключить возможность подбора
  пароля по словарю);

• пароль
  не должен совпадать с номером телефона
  пользователя (обычного или мобильного),
  номером его автомобиля, паспорта,
  водительского удостоверения или другого
  документа;

• пароль
  должен быть комбинацией букв в верхнем
  и нижнем регистрах, цифр и спецсимволов
  (типа @#$%^*&()_+ и
  т.д.).

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

Соседние файлы в папке OC

• #
• #
• #
• #
• #
• #
• #
• #

Одной из проблем в Active Directory является множество имен, которые можно использовать для обозначения или описания объекта. Большинство этих имен являются атрибутами (или свойствами) объекта. Путаница возникает из-за того, что один и тот же атрибут может иметь разное имя, в зависимости от используемого провайдера. Кроме того, имя одного атрибута может ссылаться на другой атрибут, что также не добавляет ясности. Ну и наконец, у атрибутов существуют методы (функции), которые вычисляют значение имени из других атрибутов.

Попробуем разобраться в этой ситуации на примере объекта пользователя. Для этого откроем оснастку Active Directory Users and Computers (ADUC) и создадим новую учетную запись. При создании мы указываем Имя (First name), Фамилию (Last name) и инициалы (Initials), из которых формируется полное имя (Full name). Ну и целых два имени для входа — User logon name и User logon name (pre-Windows 2000).

А теперь перейдем к редактору атрибутов и посмотрим что получилось.  Для этого необходимо в оснастке ADUC в меню View отметить пункт Advanced Features.

Открываем редактор атрибутов и видим знакомые имена, но под совершенно разными названиями.

Полному имени здесь соответствуют целых три атрибута —  name, displayName и cn. Можно подумать, что это одно и то же, но нет — это совершенно разные атрибуты пользователя.

Полное имя (name) и общее имя (Common name, cn) — это два разных атрибута, хотя возвращают они одно и то же значение. Это происходит потому, что атрибут name аналогичен относительному отличительному имени (Relative Distinguished Name, RDN), а RDN — это часть отличительного имени (Distinguished Name, DN). Так если DN равно ″CN=Иванов Иван Иванович,CN=Users,DC=Test,DC=local″, то RDN будет ″CN=Иванов Иван Иванович″. Отсюда получаем, что если cn = ″Иванов Иван Иванович″, то name = ″cn=Иванов Иван Иванович″. 

Получается довольно запутанно. Но если посмотреть с практической точки зрения, то можно сказать так — изменить значение атрибута cn мы не можем, оно всегда будет равно значению атрибута name.

Отображаемое имя (displayName) по умолчанию формируется по такому же принципу, как полное (name) и общее (cn) имена, однако не зависит от их значений. Для проверки изменим полное имя нашего пользователя. Как видите, полное и отображаемое имена изменяются независимо друг от друга.

А в редакторе атрибутов видим, что вместе со значением атрибута name изменилось и значение cn, хотя его мы и не меняли.

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

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

Идем дальше. Имя соответствует атрибуту givenName, а фамилия — атрибуту sn (Surname). Может найдется и отчество? Давайте попробуем поискать его с помощью PowerShell, командой:

Get-ADUser ivanov_ii -Properties * | select *name

Нашелся атрибут с названием OtherName, возможно это оно и есть?

Зададим этому атрибуту значение:

Get-ADUser ivanov_ii -Properties * | Set-ADUser -OtherName "Иванович"

и проверим что получилось. А получилось сразу два новых атрибута — OtherName и MiddleName, оба с заданным значением.

На самом деле это просто два названия одного и того же атрибута:

cn: OtherName
ldapDisplayName: MiddleName

При этом если в PowerShell мы видим оба имени, то в оснастке ADUC отображается только одно MiddleName.

Переходим к именам входа (logon names), которых у пользователя тоже два.

Если посмотреть в редакторе атрибутов, то User logon name (pre-Windows 2000) скрывается под именем sAMAccountname, а User logon name соответствует атрибуту userPrincipalName.

Давайте немного углубимся в детали и посмотрим, чем же отличаются эти два имени.

sAMAccountName — имя учетной записи SAM. Предназначено для для совместимости со старыми (до Windows 2000) операционными системами. Впрочем это не означает, что sAMAccountName не используется в качестве имени для входа в современных системах Windows. sAMAccountname должно быть уникальным в рамках домена, имеет ограничение в 20 символов и работает в сочетании с NETBIOS именем домена, например TESTivanov_ii. sAMAccountName является обязательным атрибутом пользователя.

userPrincipalName (UPN) — имя участника-пользователя. Это новый формат указания имени пользователя для входа в систему, основанный на интернет-стандарте RFC 822. Для входа используется сочетание имени пользователя с доменным суффиксом, например ivanov_ii@test.local. Имя участника-пользователя должно быть уникальным среди всех объектов-участников безопасности в лесу доменов. Максимальная длина UPN составляет 1024 символа. UPN не является обязательным атрибутом, оно может быть не назначено при создании учетной записи пользователя.

И еще два важных имени, которые есть у пользователя. Это DistinguishedName (различающееся имя) и CanonicalName (каноническое имя). Оба эти атрибута однозначно определяют объект в Active Directory.
Различающееся имя включает в себя относительное отличительное имя объекта (RDN), а также полный путь к контейнеру, содержащему объект в Active Directory, например  ″CN=Иванов Иван Иванович,CN=Users,DC=Test,DC=local″. Каноническое имя — это то же различающееся имя объекта, но в каноническом виде, например ″test.local/Users/Иван Иванович Иванов″.

Примечание. CanonicalName является конструируемым атрибутом (constructed attribute). Такие атрибуты не хранятся явным образом в AD, а вычисляются на лету при получении соответствующих запросов.

Как видите, у пользователя в Active Directory множество различных имен. Чтобы немного их упорядочить я составил небольшую табличку, в которую внес все атрибуты пользователя, так или иначе имеющие отношение к его имени.

Ну а теперь главное) Как вы думаете, нужны ли все эти имена для создания учетной записи пользователя. Чтобы выяснить это, откроем редактор атрибутов и отфильтруем все атрибуты кроме обязательных (Mandatory). И оказывается, что для пользователя обязательными являются всего два имени — CommonName (cn) и sAMAccountName. Безо всех остальных пользователь может легко обойтись.

На этом все. А все возможные атрибуты пользователя в схеме Active Directory можно посмотреть вот здесь : https://learn.microsoft.com/en-us/windows/win32/adschema/c-user?redirectedfrom=MSDN