Windows server common name

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

Картинка с сайта: windowsnotes.ru

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

Полному имени здесь соответствуют целых три атрибута —  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) имена, однако не зависит от их значений. Для проверки изменим полное имя нашего пользователя. Как видите, полное и отображаемое имена изменяются независимо друг от друга.

Картинка с сайта: windowsnotes.ru

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

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

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

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

Get-ADUser ivanov_ii -Properties * | select *name

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

Картинка с сайта: windowsnotes.ru

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

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

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

Картинка с сайта: windowsnotes.ru

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

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 именем домена, например TEST\ivanov_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/Иван Иванович Иванов″.

Картинка с сайта: windowsnotes.ru

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

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

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

Картинка с сайта: windowsnotes.ru

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

Цель лекции: Дать представление о планировании стратегии
именования объектов в Active Directory.

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

Соглашение об именовании

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

Чтобы это реализовать, в Active Directory действует соглашение об
именовании, которое должны соблюдать и пользователи, и приложения.
Данное соглашение позволяет логически упорядочить хранение объектов и
предоставить клиентам стандартизированные методы доступа к объектам, —
например, чтобы найти сетевой ресурс, необходимо знать имя объекта или
одно из его свойств. Служба каталогов Active Directory, использующая и
поддерживающая LDAP (стандартный протокол для поиска информации в
каталоге), индексирует все атрибуты всех объектов, хранящихся в
каталоге, и публикует их
[
6
]
. Клиенты, поддерживающие LDAP, могут
выполнять всевозможные запросы к серверу.

Active Directory следует соглашению об именовании, принятому в DNS.
Active Directory поддерживает несколько типов имен, поэтому при работе
с Active Directory можно использовать разные форматы имен
[
3
]
:

• относительные составные имена;
• составные имена;
• канонические имена;
• основные имена пользователей.

Относительные составные имена

Относительное составное имя (RDN) объекта уникально идентифицирует
объект, но только в его родительском контейнере. Таким образом, оно
уникально идентифицирует объект относительно других объектов в том же
самом контейнере. Например: CN=wjglenn, OU=Users, DC=kd, DC=ru.

Здесь относительным составным именем объекта является CN=wjglenn.
RDN родительской организационной единицы (OU) — Users. У большинства
объектов RDN — это тоже самое, что и атрибут Common Name.

Active Directory автоматически создает RDN по информации,
указываемой при создании объекта, и не допускает, чтобы в одном и том
же родительском контейнере существовали два объекта с одинаковыми
RDN.

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

• DC — тэг Domain Component, который идентифицирует часть DNS-имени домена вроде СОМ или ORG;
• OU — тэг Organizational Unit, который идентифицирует организационную единицу, являющуюся контейнером;
• CN — тэг Common Name, который идентифицирует простое имя, присвоенное объекту Active Directory.

Составные имена

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

Вот типичный пример составного имени:
CN=wjglenn, OU=Users, DC=kd, DC=ru.

Это DN означает, что объект пользователя wjglenn содержится в
контейнере Users, в свою очередь содержащемся в домене kd.ru. Если
объект wjglenn переместят в другой контейнер, его DN изменится и будет
отражать новое местоположение в иерархии. DN гарантированно уникальны
в лесу, существование двух объектов с одинаковыми DN невозможно.

Канонические имена

Каноническое имя объекта используется во многом так же, как и
составное. Просто у него другой синтаксис. Составному имени,
приведенному в предыдущем подразделе, соответствовало бы следующее
каноническое имя: kd.ru/Users/wjglenn.

Таким образом, в синтаксисе составных и канонических имен — два
основных отличия. Первое — каноническое имя формируется от корня к
объекту, а второе — в каноническом имени не используются тэги LDAP-атрибутов
(например, CN и DC).

Основные имена пользователей

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

Краткий обзор DNS

DNS является службой разрешения имен и использует иерархическое
пространство имен для поиска компьютеров (см.
рис.
6.1). Корневой
домен обозначается точкой («.»). Он представляет собой
верхний уровень DNS, остальное пространство имен располагается ниже.
На следующем уровне под корневым доменом располагаются домены первого
уровня, включая несколько основных (generic) доменных имен (com, edu,
mil, net, org и т. д.), около двухсот сокращений названий стран,
несколько доменов, которые были введены позже (biz, info, pro и т.
д.). Под доменами верхнего уровня расположены домены второго уровня,
которые обычно относятся к названиям компаний и должны быть
зарегистрированы властями Интернета. Ниже доменов второго уровня
располагаются поддомены. Поддомены обычно относятся к отделам или
подразделениям в пределах компании. Эти поддомены регистрируются и
управляются с DNS-серверов, которые содержат информацию о доменах
второго уровня.

Картинка с сайта: new2.intuit.ru

Рис.
6.1.
Иерархическая структура пространства имен домена

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

DNS-серверы, хранящие информацию о доменах высшего уровня, содержат
также информацию о том, на каких серверах находятся зонные файлы для
доменов следующего уровня. Например, сервер может содержать зонные
файлы для домена com, то есть этот сервер знает обо всех доменах
второго уровня, которые зарегистрированы с доменом com, но он может не
знать отдельные детали о домене второго уровня. Сервер домена высшего
уровня знает, какой компьютер на следующем уровне содержит детали,
касающиеся домена второго уровня, и так продолжается до самого низа
пространства имен DNS. Сервер, ответственный за домен com, может иметь
домен kd, зарегистрированный как домен второго уровня. Этот сервер
может передавать любые запросы на информацию о домене kd на сервер,
который содержит зонные файлы для kd.com.

Использование метода распределенной базы данных означает, что
никакому серверу в Интернете не требуется иметь всю информацию DNS.
Большинство серверов хранят информацию о некоторой части дерева, но
когда приходит запрос, который они не могут выполнить, им известно,
какой DNS-сервер хранит необходимую информацию. DNS-серверы используют
делегированные записи, ретрансляторы (forwarders) и корневые ссылки
для определения того, какой DNS-сервер имеет необходимую
информацию.

Текущие записи, хранящиеся в зонных файлах DNS, называются записями
ресурсов (RR — Resource Records). Записи ресурсов содержат текущую
информацию о домене, на DNS-сервере системы Windows Server 2003 можно
создать двадцать два различных типа записей ресурсов
[
13
]
.

Служба DNS Locator

Служба DNS Locator (указатель DNS ) очень важна для Active
Directory, потому что DNS обеспечивает информацию, которая необходима
клиентам для поиска контроллеров домена в сети.

Чтобы облегчить нахождение контроллеров домена, Active Directory
использует указатель служб (service locator) или записи SRV. Первая
часть SRV-записи идентифицирует службу, на которую указывает запись
SRV
[
13
]
:

• _ldap Active Directory является службой каталога, совместимой с LDAP-протоколом, с контроллерами домена, функционирующими как LDAP-серверы. Записи _ldap SRV идентифицируют LDAP-серверы, имеющиеся в сети. Эти серверы могут быть контроллерами домена Windows Server 2003 или другими LDAP-серверами;
• _kerberos — основной опознавательный протокол для всех клиентов Windows 2000 и Windows XP. SRV-записи _kerberos идентифицируют все ключевые центры распределения (Key Distribution Centers, KDC) в сети. Они могут быть контроллерами домена с Windows Server 2003 или другими KDC-серверами;
• _kpassword идентифицирует серверы изменения паролей Kerberos в сети (это контроллеры домена или с Windows Server 2003, или с другими системами изменения пароля Kerberos);
• _gc — специфическая запись, относящаяся к функции глобального каталога в Active Directory.

Интегрированные зоны Active Directory

Один из самых больших плюсов выполнения DNS в операционной системе
Windows Server 2003 заключается в использовании интегрированных зон
(integrated zones) Active Directory, которые дают множество
преимуществ
[
13
]
.

• Зонная информация больше не хранится в зонных файлах на жестком диске DNS-сервера, она сохраняется в базе данных Active Directory, что обеспечивает дополнительную защиту.
• Процесс зонной передачи заменен репликацией Active Directory. Поскольку зонная информация хранится в Active Directory, данные копируются через нормальный процесс репликации Active Directory. Это означает, что репликация происходит на уровне атрибутов так, что копируются только изменения зонной информации. Трафик репликации между сайтами можно сильно сжать, увеличив пропускную способность. Использование интегрированной зоны Active Directory дает возможность использовать разделы приложений для тонкой настройки репликации информации DNS.
• Интегрированные зоны дают возможность конфигурирования DNS-сервера с несколькими хозяевами. Без Active Directory DNS может поддерживать только один основной сервер имен для каждого домена. Это означает, что все изменения в зонной информации должны быть сделаны на основном сервере имен, а затем переданы на дополнительные серверы имен. С интегрированными зонами Active Directory каждый DNS-сервер имеет перезаписываемую копию доменной информации, так что изменения зонной информации могут быть сделаны в любом месте в организации. Информация затем копируется на все другие серверы DNS.
• Интегрированную зону можно сконфигурировать так, чтобы использовать только безопасные обновления, то есть контролировать, какие пользователи и компьютеры обновляют записи ресурсов в Active Directory.

Самым большим недостатком интегрированной зоны Active Directory
является необходимость установки DNS на контроллере домена Windows
Server 2003, что создает дополнительную нагрузку на него.

Когда зона сконфигурирована как интегрированная зона Active
Directory, можно просматривать информацию DNS в Active Directory

[
6
]
.

Картинка с сайта: ultravds.com

В мире информационных технологий серверы считаются сердцем сети, и их идентификация среди множества других серверов — важный аспект. Имя хоста, присвоенное вашему виртуальному серверу, играет ключевую роль в этой идентификации. Однако, в процессе развития вашей инфраструктуры ситуация может изменяться, и возможно, вам потребуется переименовать ваш VPS. В этой статье мы рассмотрим три основных способа того, как изменить имя хоста в Windows Server 2016, которые должны помочь вам успешно выполнить эту операцию.

В общем смысле, имя хоста — это простое название, присваиваемое устройствам, подключённым к сети. Это имя используется для идентификации устройств в различных электронных средствах связи, таких как интернет. Хост — это метка, присвоенная устройству, которая отличает одно устройство от другого в определённой сети.

Способ первый: Диспетчер Серверов

Для изменения имени сервера с применением графической оболочки Windows необходимо будет воспользоваться Диспетчером Серверов — Server Manager. Чтобы запустить его, откройте стартовое меню и кликните по иконке Server Manager.

Картинка с сайта: ultravds.com

В правой части окна диспетчера перейдите в раздел Local Server и затем уже в основном окне кликните в имя сервера в строке Computer name.

Картинка с сайта: ultravds.com

Далее, в открывшемся окне нажмите кнопку Change.

Картинка с сайта: ultravds.com

И в следующем окне внесите новое имя сервера в строку Computer name. После чего нажмите ОК.

Система предупредит вас о том, что внесённые изменения вступят в силу только после перезагрузки сервера.

В результате ваш VPS изменит своё имя после того, как вы его перезапустите.

Способ второй: PowerShell

Для изменения имени сервера можно также воспользоваться командной оболочкой PowerShell. Чтобы запустить данную оболочку с строке поиска наберите powershell.

Картинка с сайта: ultravds.com

Текущее имя вашего VDS отобразится в PowerShell, если вы наберёте в командной строке следующую команду:

$env:computername

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

Rename-Computer -NewName "WINDOWS-SERVER" -Restart

Здесь WINDOWS-SERVER — новое имя VPS.

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

$env:computername

Способ третий: параметры сервера

Ещё один способ изменения имени хоста — это использование параметров сервера. Что внести изменения в параметры, в стартовом меню перейдите в Settings.

Картинка с сайта: ultravds.com

Далее, кликните в значок System.

Картинка с сайта: ultravds.com

После чего перейдите в раздел About и нажмите на кнопку Rename PC.

Картинка с сайта: ultravds.com

В открывшемся окне введите новое имя сервера в соответствующую строку, после чего нажмите Next.

Картинка с сайта: ultravds.com

Для того, чтобы изменение имени хоста вступило в силу, необходимо перезагрузить VPS. Сделать это можно сразу же, для чего нажмите на Restart now.

Картинка с сайта: ultravds.com

Заключение

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