User logon name pre windows 2000 что это

Подключал намедни линуксовый сервис для авторизации через AD, еле нашел описание соответствий атрибутов и их полей, да и те все на английском, что не очень удобно при русскоязычной системе, потому что хрен поймешь какие параметры за что отвечают. Чтобы каждый раз не выискивать их adexplorer’ом, решил составить таблицу основных атрибутов Active Directory.

Стоит отметить, что пользовательский displayName ≠ CN = Full nameПолное имя = namе, что можно видеть на последнем скрине.

Для более наглядного понимая приложу скрины:

Атрибут userAccountControl

Иногда надо понять включена или отключена учетная запись в AD. Или что еще с ней вообще происходит. За это отвечает атрибут userAccountControl, который является суммой нескольких свойств атрибутов. При этом, значение 512 является значением по умолчанию при всех снятых флагах на вкладке «Учетная запись» и каждый дополнительный параметр прибавляется к нему. Например, значения атрибута userAccountControl для наиболее распространенных случаев:
512 — Включена (Enabled)
514 (512+2) — Отключена (Disabled)
66048 (512+65536) — Включена, срок действия пароля не ограничен (Enabled, password never expires)
66050 (512+65536+2) — Отключена, срок действия пароля не ограничен (Disabled, password never expires)

Список основных значений атрибутов userAccountControl:

Подробное описание всех атрибутов

Обновлено 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.

Одной из проблем в 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

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

Каждый
компьютер с операционными системами
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.

Предложенные варианты схем основаны на личном проектном опыте и в результате анализа достоинств и недостатков в ИТ-инфраструктурах, которые приходилось встречать.

Я приведу аргументы практически для каждого решения, принятого при проектировании предлагаемых ниже схем. Буду рад увидеть альтернативные мнения в комментариях.

Содержание:

• Поиск по неполным данным
• Учетные записи пользователей
• Группы
• Сетевые устройства
• Организационные подразделения
• Другие объекты
• Годные ссылки

Поиск по неполным данным

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

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

Учетные записи пользователей

Логины

В среде AD в качестве логина могут использоваться 2 формата:

• User Principal Name (UPN) [userPrincipalName]: upnlogin@argnon.pro
• User logon name (pre-Windows 2000) [sAMAccountName]: argonsamlogin

Имеется возможность для учётки пользователя задать разные значения upnlogin и samlogin, однако это не практично, если того не требуют особые обстоятельства. Далее по тексту под словом «логин» я буду понимать одинаковое значение для атрибутов userPrincipalName и sAMAccountName.

Примечание

В неполном поиске участвует только sAMAccountName.

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

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

Всем вышеперечисленным требованиям удовлетворяет следующая схема:

• только латинские буквы — чтобы избежать проблем со сторонними (например, Linux Samba Server) и не очень (даже Remote Desktop Gateway, входящий в Windows Server 2008 R2 не работает, если встретит не латинские буквы в логине) приложениями, а также с аппаратурой (отсутствие русской раскладки, поддержки кодировки).
• не более 10 букв — для случаев ввода с не очень удобных устройств (мобильников, экранных клавиатур)
• содержать в себе фрагменты имени и фамилии хозяина — для удобства идентификации учётки с конкретным пользователем.

По последнему пункту могут быть споры, и я хочу обосновать свою точку зрения. Популярны два подхода именования учеток:

• личный — основанный на именах
• обезличенный — основанный на табельных номерах и прочих идентифицирующих данных

Некоторых мазохистов может привлекать обезличенный способ именования логинов своей стандартностью и предсказуемостью. В логине вида mza-t90361 можно закодировать массу информации, однако пользы от этого не будет никому, а неудобств доставит массу:

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

Итак, надеюсь, я показал, почему считаю обезличенную схему именования учёток пользователей неудачной. Далее я приведу свой ход рассуждений по созданию более удачной, «личной» схемы именования.

При формировании логина на основании имени и фамилии пользователя тоже возникают трудности. Ныне популярна такая схема именования:

<Имя>.<Фамилия> [Игорь Романовский > Igor.Romanovsky]

Согласен, выглядит красиво, однако, возникнут проблемы:

• с длинными именами и фамилиями [Иннокентий Петропавловский > Innokenty.Petropavlovsky]
• с трудностями однозначной транслитерации [Евгений Дряхлых > Eugene Dryakhlykh и еще массы вариантов]

Выход — сокращать логин, например, так:

<1я-буква-имени><часть-фамилии> [Евгений Баев > ebaev]

<часть-фамилии><1я-буква-имени> [Алексей Бармин > barmina]

Выше показаны несчастные случаи, когда сочетание буквы имени и фамилии дает результат, который вряд ли понравится владельцу логина, и объяснения про унификацию логинов вряд ли станут утешением.

Возможный выход из ситуации — как-то разделять фрагменты имени и фамилии, например, точкой:

<1я-буква-имени>.<часть-фамилии> [Игорь Романовский > i.rom]

Этот вариант мне очень нравится, но все же имеет следующие недостатки:

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

На основе приведенных выше размышлений, я предлагаю следующую схему, которая меня полностью устраивает:

<часть-имени><часть-фамилии> [Алексей Волков > alvol, Фёдор Бондарчук > fbond, Феликс Бунин > felixb]

Прелесть схемы в том, что части имени и фамилии выбираются так, чтобы:

• выглядело благовидно
• избежать коллизии
• логин оставался кратким

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

Служебные логины

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

• на предприятии используются несколько обезличенных «ролевых» учетных записей типа Administrator, NetAdmin, WebAdmin, TechSupport…
• ими пользуется куча народа, исполняющего соответствующие роли

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

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

• использовать отдельные личные учетки для выполнении административных задач, с логинами вида a-login, где вместо login — обычный логин данного пользователя
• привилегии на выполнение административных операций всегда назначать на уровне ролевых групп безопасности

Display Name

Значение атрибута displayName учетной записи отображается в заголовке меню Пуск вошедшего в систему пользователя, в контактах адресной книги Exchange, в поле От исходящих почтовых сообщений и во многих других местах, где требуется отобразить «дружественное» имя.

При создании пользователя в Active Directory предлагается заполнить поля имени, инициалов и фамилии. На основе этих данных предлагается значение атрибута Display Name по следующей схеме:

<Firstname> <Initials>. <Lastname>

Примечание

Путем редактирования некоторых параметров в AD эту схему можно изменить (например, на Lastname, Firstname), но на то нет веских причин. Советские времена, когда к людям было принято обращаться тов. Фамилия прошли, в современном деловом обществе принято обращаться по Имя Фамилия.

Для Display Name можно задать произвольное значение, что удобно:

• для служебных учетных записей, которые не имеют имён и фамилий
• если в поле AD «имя» введено Имя Отчество(так как под отчество нет отдельного поля), а отображать нужно в формате Имя Фамилия

Full Name

В момент создания пользователя значение Display Name присваивается другому атрибуту пользователя — cn (Canonical Name, часто он упомиается как Full Name). Значение cn широко используется в Active Directory:

• является частью фундаментального атрибута distinguishedName, который представляет собой путь к объекту в пределах AD (CN=Firstname Lastname,OU=Test Accounts,DC=argon,DC=pro), из него же формируется Canonical Name (fadmin.ru/Test Accounts/Firstname Lastname)
• именно это имя отображается в поле Full Name в оснастке Active Directory Users and Computers
• по этому параметру выполняется неполный поиск объектов в AD

Стоит обратить внимания на следующие особенности:

• атрибуты Display Name и Full Name напрямую не связаны, и после создания учетки их можно редактировать как угодно
• значение Full Name должно быть уникальным в пределах своего Organization Unit, к Display Name таких требований не предъявляется
• оба значения Display Name и Full Name следует держать согласованными, если нет необходимости в обратном, для чего редактирования первого нужно аналогично отредактировать и второе значение.

Группы

На имена групп нет таких строгих ограничений, как на логины, но есть смысл придерживаться схожих правил:

• избегать нелатинских символов и пробелов
• стремиться к кратким названиям

В дополнение к вышеперечисленному, удобно, чтобы имена групп соответствовали следующим характеристикам:

• чем-то явно отличались от логинов
• отражали назначение группы (например, из имен Техподдержка и Бухгалтерия не понять, что есть группа безопасности, а что — группа рассылки)
• признаки, содержащиеся в имени, следовали в порядке значимости (например, ExchangeAdmins и ExchangeHelpdesk, а не Администраторы Exchange и Техническая поддержка Exchange)

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

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

Итак, я предлагаю следующую схему именования групп:

g<p>-<Name>

где:

• g — признак отличия имени группы от логина
• p — назначение группы, принимает значения:
  • f — функциональная
  • r — ресурсная
  • d — распространения
  • a — административная
• Name — собственно, имя группы; при необходимости, содержит признаки принадлежности к области действия, например:
  • GlobHelpdesk
  • MscPrinters

Пример имён групп:

• gf-Operators
• gr-ProjectDocs
• gd-AllCompany
• ga-Helpdesk

Примечание

Назначение группы определяется ролевой моделью привилегий (также известной как UGLP), в которой:

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

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

Сетевые устройства

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

Примеры неудачных имен с попыткой их расшифровать и комментариями:

• SR-PSSRV001 (сервер-принт-сервер-сервер-номер001) — слово «сервер» закодировано 3 раза, порядковый номер 3-разрядный, хотя таких серверов всего 2 штуки
• SR-msExch04 (сервер, почтовый сервер-эксчендж сервер-номер04) — многократно закодировано слово «сервер», но нет данных о его размещении
• W-430400764 (рабочая станция-43регион, офис 04, инвентарный номер 00764) — без таблицы — не найти!
• МАШЕНЬКА-ПК (без комментариев)

Для сетевых устройств (компьютеров, принтеров, роутеров, мобильников…) я предлагаю гибкую схему именования, которая основана на следующих правилах:

• нелатинские символы исключены
• имя должно содержать некие признаки, которые позволяют удобно классифицировать устойства
• классификационные признаки должны следовать в порядке значимости
• имя должно быть достаточно описательным, чтобы свести к минимуму обращения к таблицам для идентификации устройства
• если требуется совместимость с Netbios, длину имени следует ограничить 15 символами

А вот и схема:

<Site>-<Class>-<[Type]Name[Number]>

• Site — признак расположения компьютера (определение сайта в терминологии AD вполне подходит), такие как HQ, NOC, MSC, KZN и прочее.

• Class — класс устройства, например:

  • SR — сервер

  • WS — рабочая станция

  • MB — мобильное устройство

  • DV — другое сетевое устройство

• Type — опциональное дальнейшее уточнение назначения устройства (зависит от класса), например:

  • DC — контроллер домена

  • PR — принтер

  • DT — десктоп

  • LT — ноутбук

• Name — имя устройства, краткое и описательное, например:

  • ExMB — сервер почтовых ящиков Exchange

  • Gate — шлюз

  • Proxy — …

• Number — опциональный номер, если подобных устройств несколько. Разрядность номера следует планировать заранее, но и фиксировать количество разрядов для абсолютно всех устройств не стоит, так большая разрядность уместна в редких случаях, а в большинстве случаев достаточно номера в пределах десятка.

Примеры имен, образованных по такой схеме:

• NOC-SR-DCLAB18 (сайт NOC, сервер, контроллер домена LAB, номер 18)
• MSC-SR-MONITOR (сайт MSC, сервер, занимается мониторингом)
• NOC-CL-HV4 (сайт NOC, кластер Hyper-V, номер 4)
• NOC-CL-HV4-N7 (сайт NOC, кластер Hyper-V номер 4, узел номер 7)
• HQ-SR-EXMB3 (сайт HQ, cервер, Exchange c ролью Mailbox, номер 3)
• KOS-WS-DTFIN06 (сайт KOS, рабочая станция, настольная, финансовый отдел, номер 06)
• EXT-WS-LTIROM (внешний сайт, рабочая станция, ноутбук пользователя с логином irom)
• NOC-DV-ROUTER12 (сайт NOC, устройство, маршрутизатор, номер 12)
• EXT-MD-WMIROM (внешний сайт, мобильное устройство, windows mobile пользователя с логином irom)

Организационные подразделения

Существующих несколько моделей построения структуры OU и делегирования. Здесь я не буду пытаться описать их все, это хорошо сделано в более серьёзной литературе.

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

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

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

• противоречива и изменчива
• не применима к управлению ИТ-инфраструктурой

Я предлагаю строить структуру OU по следующей концепции:

• Создавать структуру OU исходя в первую очередь из удобства делегирования полномочий.
• Для тонкого назначения групповых политик на пользователей, рабочие станции и сервера использовать ролевую модель, основанную на членстве в группах в безопасности. Не эффективно пытаться строить ролевую модель на OU. Непременно найдутся объекты, которые исполняют несколько ролей, но архитектура AD предусматривает членство объекта только в одном OU.

При этом придерживаться следующих технических особенностей:

• в именах OU не использовать нелатинских символов и пробелов
• придерживаться принципов краткости и не избыточности
• умеренно использовать иерархию (глубокая вложенность замедляет выполнение некоторых операций)
• активно пользоваться полем Description
• избегать использования встроенных контейнеров Users и Computers для хранения в них объектов, назначения политик
• не создавать своих контейнеров (куда-то вложенных) с именами Users и Computers — могут быть проблемы совместимости

Пример структуры OU, который следует вышеизложенным рекомендациям:

• lab.fadmin.ru — домен
  • Company – сразу отделяем наше дерево иерархии от встроенных объектов AD
    • Global
    • Kazan
    • Kirov– уровень территориальной принадлежности
      • Services – служебные пользователи и группы, управляет которыми только IT-отдел
      • Comps – компьютеры: сервера и рабочие станции
      • Accounts – учетные записи и группы рядовых пользователей, управление которыми можно делегировать простым пользователям (конечно, через другие группы безопасности, прав на управление которыми у данного пользователя не будет)
    • Moscow

Другие объекты

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

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

ссылки

• The 12 Mighty Chores of Active Directory Administration in Depth
• Оптимизация AD: Cтруктура орг. подразделений(OU) служит для делегирования прав и назначения групповых политик
• RFC 2142 — Mailbox Names for Common Services, Roles and Functions

This basic article is intended to provide a background in different Active Directory user name and domain name formats and how they are used by applications for basic and integrated authentication process within Windows Server.

The guidance provided throughout is targeted towards working with Microsoft Lync, Exchange, and third-party solutions or applications which support direct registration and authentication to these Microsoft UC platforms.

In most environments registration is as simple as typing in a SIP Address, username, and password which is the same information that native Lync and Outlook clients will leverage for connectivity and authentication. But in some more complex environments it may be necessary to known more specific information about the user accounts used to authenticate clients as these Active Directory deployments can often times use a variety of mismatched user name and domain name formats.

Thus it is beneficial to understand the following concepts in order to identify what is often simply a failure to register due to incorrect entering account credential information.  The specifications and limitations of these formats are detailed in this TechNet article.

Domain Names

Active Directory supports two separate types of domain name formats since it’s introduction into Windows Server 2000.

Legacy Domain Name

The Legacy Domain Name parameter, which is also commonly referred to as the NetBIOS Domain Name, is a carryover from Windows NT and is limited to 15-characters. (NetBIOS names are 16-characters in length but the last character is hidden and is used to identify the name record type.) This is the value commonly used with the DOMAINusername format when signing into various Microsoft applications and even though it is not case-sensitive this string is traditionally shown all in uppercase as a matter of good practice.  Although it is considered a legacy format it is still the most prevalently used format today for user authentication.

DNS Domain Name

The DNS Domain Name parameter was added in Active Directory with the release of Windows 2000 and supports up to 24-characters for the hostname portion, but the Fully Qualified Domain Name can be much longer (e.g. subdomain1.subdomain2.domain.com).

As indicated in the screenshots above the sample environment is using a legacy domain name that is shorter than 15 characters so the same string can be used for both formats. This is ideal and is the general best practice used in the field; to select shorter domain names when designing an Active Directory forest so that authentication can be simplified across Microsoft and third-party applications which may use one or both formats. Unfortunately this is not always the case as mergers and divestitures over time can lead to more complicated Active Directory environments. Although newer versions of Windows Server does allow for these domain names to be changed post-deployment this is almost never actually attempted in the field due to the massive impact on the entire environment.

Alternatively the following screenshot shows an AD domain in which the two type use entirely different values (verylongdnsdomainname.com vs. SHORTNAME).

User Names

Just as with domain names there are two different formats in Active Directory for storing user names:

Legacy User Logon Name

The User Logon Name (Pre-Windows 2000) is the legacy format from Windows NT and is often referred to using the raw attribute name of sAMAccountName. This field is limited to a maximum of 20 characters and is used in conjunction with the legacy (or NetBIOS) domain name.

User Logon Name

The User Logon Name is a the newer username format which is often mistakenly referred to as the User Principal Name (UPN).  That term is used to indicate the entire user name and domain name format.comprised of the User Logon Name and the UPN Suffix which is shown in the drop-down menu in the screenshot below.

Just as with domain name formats the user names can also be unique. Depending on the naming conventions used in the directory it is more common to have long user names truncated to 20 characters in the legacy user name field. In the complex example shown below a user name of 36 characters (e.g. abcdefghijklmnopqrstuvwxyz0123456789) is automatically truncated to only 20 characters in the legacy field.

Authentication Formats

Once the user name and domain name formats are clearly identified then they are assembled into pairs in specific formats to be used for authentication. The ubiquitous NTLM authentication used in Windows Server can support two different formats.

Legacy

The legacy format requires that the Legacy (NetBIOS) Domain Name value is used with the legacy User Logon Name (sAMAccountName).

Simple Example: SCHERTZjeff

Complex Example: SHORTNAMEabcdefghijklmnopqrst

User Principal Name

The newer User Principal Name format is comprised of the User Logon Name (not the legacy sAMAccountName) and the UPN Suffix assigned to the specific user account.

Simple Example: jeff@schertz.local

Complex Example: abcdefghijklmnopqrstuvwxyz0123456789@verylongdnsdomainname.com

It is important to understand that although the DNS Domain Name is the default assigned UPN Suffix for all user accounts created in the domain this value can be changed and customized in Active Directory. So in the event that the Active Directory namespace (e.g. schertz.local) does not match the Lync SIP Domain namespace (e.g. mslync.net) it is still possible to provide a simplified user sign-in experience by defining an additional UPN suffix which matches the SIP domain and then assigning that suffix to all desired user accounts.

• The following screenshot shows how an additional UPN suffix (e.g. mslync.net) can be added to the forest using the Active Directory Domains and Trusts application.

• Once this is defined then it will appear as a choice for all user accounts in the domain and can be selected in the Active Directory Users and Computer utility.

In the example above it would be possible to provide the same ‘string’ to users as both their SIP Address and User Principal Name even when separate namespaces are used between AD and Lync.  This approach allows Lync users to enter the same information for both their Sign-In Address and their User Name.  In fact in a recent Cumulative Update for the Lync client the sign-in behavior was changed to actually assume that the AD user name is the same as the SIP address during the first authentication attempt, and then if that fails (due to unique values being used for both) then the User Name field will be presented to the user to fill-out for a second attempt.  This change in behavior makes the client more ‘cloud’ friendly as the default configuration for Office 365 and most hosted deployments of Lync will set these fields to the same values.

Hopefully this post has provided some clarity between the different user name formats and in turn help reduce confusion when signing.  When the credentials are known to be accurate and in the proper format this make issues much easier to troubleshoot as it takes the uncertainty of out of equation.