Подготовка немаршрутизируемого домена к синхронизации службы каталогов

Поддержка нескольких доменов верхнего уровня

Для создания федерации нескольких доменов верхнего уровня с Azure AD необходимо выполнить некоторые дополнительные настройки, которые не требуются при создании федерации с одним доменом верхнего уровня.

При добавлении домена в федерацию с Azure AD необходимо установить несколько свойств для этого домена в Azure. Важным свойством является IssuerUri. Это свойство, содержащее универсальный код ресурса (URI), который используется Azure AD для идентификации домена, с которым связан маркер. URI не должен разрешаться, но обязан быть действительным. По умолчанию Azure AD устанавливает для этого универсального кода ресурса (URI) значение идентификатора службы федерации в локальной конфигурации службы AD FS.

Примечание

Идентификатор службы федерации — это URI, который уникально идентифицирует службу федерации. Служба федерации — это экземпляр AD FS, который работает как служба токенов безопасности.

Для просмотра IssuerUri можно воспользоваться командой PowerShell .

Проблема возникает при добавлении нескольких доменов верхнего уровня. Предположим, что у вас настроена федерация между Azure AD и локальной средой. В этом документе используется домен bmcontoso.com. Теперь добавляется второй домен верхнего уровня, bmfabrikam.com.

Пр попытке преобразовать домен bmfabrikam.com в федеративный домен происходит ошибка. Причина в том, что в Azure AD существует ограничение, при котором свойство IssuerUri не может иметь одно и то же значение для нескольких доменов.

Параметр SupportMultipleDomain

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

Этот параметр заставляет Azure AD настроить IssuerUri таким образом, чтобы он был основан на имени домена. Значение IssuerUri будет уникальным в различных каталогах в Azure AD. Использование параметра позволяет успешно выполнить команду PowerShell.

Просмотрев параметры домена bmfabrikam.com, вы увидите следующее:

не изменяет другие конечные точки, в которых адрес службы федерации по-прежнему задан как adfs.bmcontoso.com.

Параметр также гарантирует, что система AD FS содержит правильное значение издателя для маркеров, выпущенных для Azure Active Directory. Это значение задается путем получения части домена имени участника-пользователя и его использования в качестве домена в IssuerUri, то есть .

Таким образом, при проверке подлинности в Azure AD или Microsoft 365 для обнаружения домена в Azure AD используется элемент IssuerUri в маркере пользователя. Если совпадение не найдено, аутентификация завершится ошибкой.

Например, если UPN пользователя имеет значение [email protected], элементу IssuerUri в маркере (издатель AD FS) будет присвоено значение . Этот элемент будет соответствовать конфигурации Azure AD, и аутентификация пройдет успешно.

Ниже приведено пользовательское правило утверждения, которое реализует эту логику.

Важно!

Чтобы использовать параметр -SupportMultipleDomain при попытке добавить новые или преобразовать существующие домены, необходимо заранее настроить федеративное отношение доверия для этих доменов.

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

При включении 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.

Известные проблемы приложений и обходные решения

Программное обеспечение как услуга (SaaS) и бизнес-приложения часто используют имена участников-пользователей для поиска пользователей и хранения сведений о профилях пользователей, включая роли. На приложения, использующие JIT-подготовку для создания профиля пользователя при первом входе пользователей в приложение, могут повлиять изменения имен участников-пользователей.

Известная проблема
Изменение UPN пользователя может нарушить связь между пользователем Azure Active Directory и профилем пользователя, созданным в приложении. Если приложение использует JIT-подготовку, оно может создать совершенно новый профиль пользователя. В результате от администратора приложения потребуется внести изменения вручную, чтобы исправить эту связь.

Обходное решениеАвтоматическая подготовка пользователей Azure Active Directory позволяет автоматически создавать, обслуживать и удалять удостоверения пользователей в поддерживаемых облачных приложениях. Если в приложениях настроить автоматическую подготовку пользователей, имена участников-пользователей автоматически обновятся в приложениях. Протестируйте приложения в рамках последовательного развертывания, чтобы убедиться, что на них не влияет изменение имен участников-пользователей.
Если вы разработчик, попробуйте добавить в приложение поддержку SCIM, чтобы включить автоматическую подготовку пользователей из Azure Active Directory.

«Диспетчер учетных данных» – место, в котором Windows хранит пароли и другие данные для входа

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

Что такое «Диспетчер учетных данных»?

«Диспетчер учетных данных» – это «цифровой сейф», в котором Windows хранит учетные данные (имя пользователя, пароли и т.д.) для других компьютеров в сети, серверов или веб-сайтов.

Эти данные использует как сама операционная система, так и приложения, которые знают, как их использовать, например: инструменты, входящие в состав Windows Live Essentials, Microsoft Office, Internet Explorer или приложения для запуска виртуальных машин.

Учетные данные разделены на три категории:

«Учетные данные Windows» – используются только Windows и ее службами. К примеру, Windows может использовать эти данные для автоматического входа в общие папки на другом компьютере в вашей сети. Или, для хранения пароля домашней группы, к которой вы присоединены. Пользователь может изменять или удалять такие учетные данные, но это мы затронем в последующих разделах данное статьи.
«Учетные данные на основе сертификата» – они используются вместе со смарт-картами, в основном в сложных сетевых бизнес-средах. Большинству из вас никогда не потребуется использовать эти учетные данные и этот раздел на ваших компьютерах будет пуст, но если вы хотите узнать о них больше, почитайте эту статью от Microsoft.
«Общие учетные данные» – используются некоторыми программами для получения разрешения на использование определенных ресурсов. Самыми часто используемыми общими учетными данными является Windows Live ID, который используется программами, включенными в пакет Windows Live Security Essentials.

Все эти учетные данные автоматически сохраняются и управляются Windows и приложениями, которые вы используете. Для просмотра учетных данных, хранящихся на компьютере, или для удаления или редактирования некоторых из них, используется «Диспетчер учетных данных».

«Учетные данные для Интернета» создаются и удаляются через встроенные в Internet Explorer функции для управления паролями. Вы не сможете создавать эти данные через «Диспетчер учетных данных» – можно только просматривать существующие и удалять их.

Как открыть «Диспетчер учетных данных»?

Один из способов открытия «Диспетчера учетных данных»: откройте «Панель управления», затем перейдите в раздел «Учетные записи пользователей и Семейная безопасность», ну а дальше выберите «Диспетчер учетных данных».

Наиболее распространенные учетные данные

На большинстве компьютеров с Windows 7 и Windows 8 вы увидите в основном одни и те же учетные данные. Среди наиболее распространенных:

Детали для входа в домашнюю группу – здесь хранится имя пользователя (HomeGroupUser$) с паролем для доступа к домашней группе.
virtualapp/didlogical – об этих учетных данных известно очень мало. Некоторые говорят, что они используются функциями виртуализации, включенными в Windows 7 и Windows 8.
WindowsLive – данные для входа в Windows Live ID.

Добавление учетных данных

Процесс добавления учетных данных очень простой. Во-первых, определитесь с типом учетных данных. Как из трех вам нужен?

Предположим, вы хотите добавить «Учетные данные Windows» для того, чтобы вы могли открывать папки на другом компьютере.

Нажмите на ссылку «добавить учетные данные Windows».

Дальше вам нужно ввести необходимые данные для входа. Сначала введите IP-адрес или имя компьютера. Далее введите имя пользователя, которое будет использоваться для входа. Кстати, не забудьте ввести имя компьютера перед именем пользователя, как показано на скриншоте ниже. Теперь введите пароль и нажмите кнопку «OK».

Учетные данные сохраняться и будут автоматически использоваться при каждом доступе к данному компьютеру вашей сети.

Удаление учетных данных

Для удаления учетных данных, сперва найдите их и раскройте, кликнув на их название или на стрелку справа.

Затем нажмите на ссылку «Удалить».

Вас попросят подтвердить удаление. Нажмите на кнопку «Да».

Учетные данные удалены и больше не будут использоваться.

Редактирование существующих учетных данных

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

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

Изменение правил утверждений служб федерации Active Directory

Службы AD FS поддерживают обширный язык утверждений, с помощью которого можно создавать настраиваемые правила утверждений. Дополнительные сведения см. в разделе Роль языка правил утверждений.

Далее рассматривается, как можно создавать пользовательские правила для некоторых сценариев, связанных с использованием Azure AD и федерации AD FS.

Неизменяемый идентификатор, зависящий от наличия значения в атрибуте

Azure AD Connect позволяет указывать атрибут, используемый в качестве привязки к источнику, когда объекты синхронизируются с Azure AD. Если значение в настраиваемом атрибуте не пустое, можно выдать утверждение неизменяемого идентификатора.

Например, можно выбрать в качестве привязки к источнику атрибут ms-ds-consistencyguid и настроить выдачу ImmutableID как ms-ds-consistencyguid в случае наличия у атрибута значения. Если у атрибута нет значения, в качестве неизменяемого идентификатора следует выдать objectGuid. Можно создать набор пользовательских правил утверждения, как описано ниже.

Правило 1. Атрибуты запросов

В этом правиле запрашиваются значения ms-ds-consistencyguid и objectGuid для пользователя из Active Directory. Измените имя хранилища на имя соответствующего хранилища в развертывании AD FS. Измените тип утверждений на определенный в федерации для objectGuid и ms-ds-consistencyguid.

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

Правило 2. Проверка наличия ms-ds-consistencyguid для пользователя

Это правило определяет временный флаг с именем idflag, который получает значение useguid, если ms-ds-concistencyguid для пользователя не заполнен. Логика такого решения в том, что службы AD FS запрещают пустые утверждения. Поэтому при добавлении утверждений и в правило 1 вы получаете утверждение msdsconsistencyguid, только если значение для пользователя заполнено. Если оно не заполнено, службы AD FS определяют, что значение окажется пустым, и немедленно его опускают. objectGuid имеют все объекты, поэтому такое утверждение всегда будет присутствовать после выполнения правила 1.

Правило 3. Выдача ms-ds-consistencyguid в качестве неизменяемого идентификатора, если он присутствует

Это неявная проверка Exist . Если значение для утверждения существует, выполняется его выдача в качестве неизменяемого идентификатора. В предыдущем примере используется утверждение nameidentifier . Его потребуется заменить соответствующим типом утверждения для неизменяемого идентификатора в конкретной среде.

Правило 4. Выдача objectGuid в качестве неизменяемого идентификатора при отсутствии ms-ds-consistencyGuid

В этом правиле просто выполняется проверка временного флага idflag. На основе его значения определяется, следует ли выдавать утверждение.

Примечание

Последовательность этих правил важна.

Единый вход с помощью UPN поддомена

Можно включить несколько доменов в федерацию с помощью Azure AD Connect, как описано в разделе . Azure AD Connect версии 1.1.553.0 и более поздней создает корректное правило утверждения для issuerID автоматически. Если вы не можете использовать Azure AD Connect версии 1.1.553.0 или более поздней, рекомендуется использовать средство Правила утверждений Azure AD RPT для создания и установки корректных правил утверждений для доверия проверяющей стороне Azure AD.

Портал Azure

Создание настраиваемой роли

Примечание

Настраиваемые роли создаются и управляются на уровне всей организации и доступны только на странице «Обзор» организации.

Войдите на портал Azure или в центр администрирования Azure AD.
Последовательно выберите Azure Active Directory > Роли и администраторы и Новая пользовательская роль.
На вкладке Основные сведения укажите в качестве имени роли «Управление назначениями пользователей и групп» и в качестве описания роли «Предоставление разрешений на управление назначениями пользователей и групп», а затем нажмите кнопку Далее.
На вкладке Разрешения в поле поиска введите «microsoft.directory/servicePrincipals/appRoleAssignedTo/update», а затем установите флажки рядом с нужными разрешениями и нажмите Далее.
На вкладке Отзыв и создание проверьте разрешения и нажмите кнопку Создать.

Назначение роли пользователю с помощью портала Azure

Войдите на портал Azure или в центр администрирования Azure AD.
Выберите Azure Active Directory > Роли и администраторы.
Выберите роль Предоставление разрешений на управление назначениями пользователей и групп.
Выберите Добавить назначение, выберите нужного пользователя и нажмите кнопку Выбрать, чтобы добавить назначение роли пользователю.

Советы по назначению

Чтобы предоставить уполномоченным разрешения на управление доступом пользователей и групп для всех корпоративных приложений в масштабах всей организации, начните со списка Роли и администраторы на уровне организации на странице Обзор Azure Active Directory для вашей организации.
Чтобы предоставить уполномоченным разрешения на управление доступом пользователей и групп для конкретного корпоративного приложения, перейдите к этому приложению в AAD и откройте список Роли и администраторы для этого приложения. Выберите новую настраиваемую роль и укажите сведения для назначения пользователя или группы. Уполномоченные могут управлять доступом пользователей и групп только для конкретного приложения.
Чтобы проверить назначение настраиваемой роли, войдите как уполномоченный и откройте страницу приложения Пользователи и группы, чтобы убедиться, что параметр Добавить пользователя включен.

Сколько агентов сквозной аутентификации следует установить?

Установка нескольких агентов сквозной аутентификации обеспечивает . Но эта установка не поддерживает детерминированную балансировку нагрузки между агентами аутентификации.

Рассмотрим ожидаемую пиковую и среднюю нагрузку запросов на вход для клиента. В качестве измерения производительности один агент аутентификации может обрабатывать от 300 до 400 операций аутентификации в секунду на стандартном сервере с четырехъядерным ЦП и 16 ГБ ОЗУ.

Чтобы оценить объем трафика, используйте следующие рекомендации по выбору размеров:

Размер полезных данных каждого запроса составляет (0.5K + 1K * число_агентов) байт, т. е. отправляемых данных из Azure AD в агент аутентификации. Здесь «число_агентов» указывает количество агентов аутентификации, зарегистрированных в клиенте.
Размер полезных данных каждого ответа составляет 1 КБ, т. е. отправляемых данных из агента аутентификации в Azure AD.

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

Примечание

Существует системное ограничение в 40 агентов проверки подлинности для каждого клиента.

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 FS, а не сторонних поставщиков удостоверений.

Exchange и Skype для бизнеса

если вы используете альтернативный идентификатор входа с Exchange и Skype для бизнеса, взаимодействие с пользователем зависит от того, используется ли сегмент HMA или нет.

Примечание

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

или см. Дополнительные сведения о гибридной современной проверке подлинности

предварительные требования для Exchange и Skype для бизнеса

Ниже приведены предварительные требования для достижения единого входа с альтернативным ИДЕНТИФИКАТОРом.

для Exchange Online должна быть включена современная проверка подлинности.
для Skype для бизнеса (сфб) Online должна быть включена современная проверка подлинности.
Exchange в локальной среде должна быть включена современная проверка подлинности. на всех серверах Exchange требуется Exchange 2013 CU19 или Exchange 2016 CU18. в среде нет Exchange 2010.
Skype для бизнеса в локальной среде должна быть включена современная проверка подлинности.
необходимо использовать Exchange и Skype клиенты, для которых включена современная проверка подлинности. Все серверы должны работать под СФБ Server 2015 CU5.
Skype для бизнеса Клиенты, поддерживающие современные проверки подлинности
- iOS, Android, Windows Phone
- СФБ 2016 (MA по умолчанию включен, но убедитесь, что он не был отключен).
- СФБ 2013 (MA по умолчанию отключен, поэтому убедитесь в том, что MA включен.)
- СФБ Mac Desktop
Exchange Клиенты, поддерживающие современные проверки подлинности и поддерживающие АЛТИД регкэйс

поддерживаемая версия Office

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

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

Шаг 1. обновление до требуемой версии Office

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

Шаг 2. обновление до требуемой версии Windows

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

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

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

Добавление в RegKey	Имя, тип и значение данных RegKey	Windows 7/8	Windows 10	Описание
HKEY_CURRENT_USER\Software\Microsoft\AuthN	DomainHintREG_SZcontoso.com	Обязательно	Обязательно	Значение этого RegKey — проверенное имя пользовательского домена в клиенте Организации. Например, компания Contoso Corp может предоставить значение Contoso.com в этом окне реестра, если Contoso.com является одним из проверенных имен пользовательских доменов в Contoso.onmicrosoft.com клиента.
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity	енаблеалтернатеидсуппортREG_DWORD1	требуется для Outlook 2016 proplus	требуется для Outlook 2016 proplus	значение этого regkey может быть 1/0, чтобы указать Outlook приложению, следует ли использовать улучшенную логику проверки подлинности с альтернативным идентификатором.
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\contoso.com\sts	*REG_DWORD1	Обязательно	Обязательно	Этот RegKey можно использовать для установки STS в качестве доверенной зоны в параметрах Интернета. Развертывание Standard AD FS рекомендует добавлять AD FS пространство имен в зону местной интрасети для Internet Explorer.

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

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

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

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

Примечание

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

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

Имеется настроенный домен Active Directory windom.net. Требуется настроить веб-сервер араche2 на сервере с Ubuntu так, чтобы он обслуживал два виртуальных хоста, — windom.net (он же www.windom.net) и sandbox.windom.net, — в которых пользователи проходили бы Kerberos-аутентификацию в Active Directory. Примерная DNS-зона:

windom.net      A      10.10.0.3  # Корень домена, A-запись указывает на ip-адрес веб-сервера
|
|\ gate         A      10.10.0.1  # Шлюз 
|\ ads          A      10.10.0.2  # Контроллер домена на MS Windows 2003 R2
|\ webserver    A      10.10.0.3  # Веб-сервер на Ubuntu 14.04, apache-2.4.7, mod_auth_kerb-5.4.1
|\ www          CNAME  webserver  # Ссылка на webserver для VitrualHost apache2, общий портал
 \ sandbox      CNAME  webserver  # Ссылка на webserver для VitrualHost apache2, ресурс для разработчиков

С одной стороны, подобная конфигурация уже много раз хорошо документирована в Интернет и нет смысла повторяться. С другой стороны, для работы mod_auth_kerb требуется keytab-файл с принципалами сервисов apache2. Сначала мне казалось, что там должны быть такие принципалы:

HTTP/[email protected]
HTTP/[email protected]
HTTP/[email protected]
HTTP/[email protected]

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

HTTP/[email protected]
HTTP/[email protected]

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

Итак, задача: сформировать в среде Active Directory рабочий keytab-файл с несколькими принципалами сервисов для его использования в apache2.

userPrincipalName

Атрибут userPrincipalName — это имя входа для пользователя. атрибут состоит из имени участника-пользователя (UPN), которое является наиболее распространенным именем для входа Windows пользователей. Пользователи обычно используют свое имя участника-пользователя для входа в домен. Этот атрибут является индексированной строкой с одним значением.

UPN — это имя входа в стиле Интернета для пользователя, основанное на стандарте RFC 822. Имя участника-пользователя короче различающегося имени, и его легче запомнить. По соглашению оно должно сопоставляться с адресом электронной почты пользователя. Точка UPN заключается в объединении пространств имен электронной почты и входа в систему, чтобы пользователю было достаточно запомнить только одно имя.

Формат имени участника-пользователя

Имя участника-пользователя состоит из префикса (имя участника-пользователя) и суффикса (имя субъекта-пользователя). Префикс объединяется с суффиксом с помощью символа «@». Например, «someone@ example.com». Имя участника-пользователя должно быть уникальным среди всех объектов субъекта безопасности в пределах леса каталога. Это означает, что префикс имени участника-пользователя можно использовать повторно, не используя тот же суффикс.

Суффикс имени участника-пользователя имеет следующие ограничения.

Это должно быть DNS-имя домена, но не обязательно должно быть именем домена, содержащего пользователя.
Это должно быть имя домена в текущем лесу домена или альтернативное имя, указанное в атрибуте упнсуффиксес контейнера секций в контейнере конфигурации.

Управление UPN

Имя участника-пользователя может быть назначено, но не является обязательным при создании учетной записи пользователя. При создании имени участника-пользователя изменения в других атрибутах объекта User, таких как переименование или перемещение пользователя, не затрагиваются. Это позволяет пользователю при реструктуризации каталога иметь то же имя входа. Однако администратор может изменить имя участника-пользователя. При создании нового объекта пользователя следует проверить локальный домен и глобальный каталог на наличие предложенного имени, чтобы убедиться, что оно еще не существует.

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