Регламент интеграции информационных сервисов с единым

Содержание
1.
Термины и сокращения................................................................................................................. 4
2.
Общие положения ......................................................................................................................... 6
3.
Порядок интеграции информационного сервиса с единым каталогом ................................... 7
4.
План интеграции сервиса с единым каталогом пользователей ................................................ 9
5.
Способы и протоколы интеграции сервиса с единым каталогом ........................................... 10
6.
Требования к информационным сервисам для интеграции с единым каталогом. ............... 12
6.1.
Требования к поддержке форматов логинов (имен пользователей) ............................... 12
6.2.
Требования к сервису по обработке паролей .................................................................... 13
6.3.
Иные требования к сервису ................................................................................................ 14
7.
Технология единого входа (SSO) .............................................................................................. 15
8.
Методы аутентификации при интеграции сервиса с единым каталогом .............................. 17
9.
8.1.
Протоколы SSL и TLS ......................................................................................................... 17
8.2.
Протокол Kerberos ............................................................................................................... 18
8.3.
Протокол NTLM................................................................................................................... 18
8.4.
Протокол SSPI ...................................................................................................................... 19
8.5.
Протоколы RADIUS и TACACS+ ...................................................................................... 19
8.6.
Протокол LDAP ................................................................................................................... 21
8.7.
Протокол IPSec..................................................................................................................... 23
Аутентификация в операционных системах ............................................................................ 24
9.1.
Аутентификация в Windows ............................................................................................... 24
9.2.
Аутентификация в *nix-системах ....................................................................................... 25
10. Аутентификация в веб-сервисах ................................................................................................ 26
10.1.
Общая информация по веб-аутентификации................................................................. 26
10.2.
Федеративная аутентификация ....................................................................................... 26
11. Интеграция сервиса с единым каталогом при помощи Веб-сервера IIS ............................... 28
11.1.
Аутентификация по логину и паролю в IIS ................................................................... 28
11.2.
Федеративная аутентификация в IIS .............................................................................. 30
11.3.
Аутентификация по сертификатам в IIS ........................................................................ 30
12. Авторизация в сервисах .............................................................................................................. 32
13. Обмен данными между единым каталогом и сервисом .......................................................... 34
13.1 Способы получения информации из Active Directory ...................................................... 34
13.2 Данные о пользователях, хранимые в Active Directory .................................................... 35
13.3 Уникальные идентификаторы ............................................................................................ 36
13.4 Объединение данных из каталога и иных систем при интеграции сервиса................... 39
2
14. Методы обнаружения контроллеров домена ............................................................................ 40
14.1 Общие принципы ................................................................................................................. 40
14.2 Получение адресов DNS-серверов ..................................................................................... 41
14.3 Получение адресов контроллеров домена ......................................................................... 42
14.4 Статическое использование DNS-имен контроллеров домена для компьютеров и
серверов подразделений внутри корпоративной сети для протокола LDAP ............................ 43
14.5 Статическое использование DNS-имен контроллеров домена в сегменте DMZ или для
сервисных компьютеров или для протоколов отличных от LDAP ............................................ 43
3
1. Термины и сокращения
УрФУ
Дирекция ИТ,
Дирекция
информационных
технологий
УИТИ
Отдел базовых
сервисов
ПО
ОС
Единый каталог,
АД, AD, Active
Directory
КД, Контроллер
домена
Подразделение
Сервисный
администратор
Active Directory
Администратор
подразделения
Пользователь
Учетная запись
Информационная
система, сервис,
приложение
SSO, технология
единого входа
Аутентификация
Федеративная
аутентификация
Уральский федеральный университет имени первого Президента
России Б.Н. Ельцина
Дирекция информационных технологий УрФУ
Управление информационно-телекоммуникационной
инфраструктуры в Дирекции ИТ
Отдел базовых сервисов в УИТИ Дирекции ИТ
Программное обеспечение
Операционная система
Каталог объектов Microsoft Active Directory. Включает в себя домен
Active Directory «at.urfu.ru», лес Active Directory «at.urfu.ru», DNSзону «at.urfu.ru», дочерние DNS-зоны в зоне «at.urfu.ru» и несколько
обратных DNS-зон
Сервера и контроллеры домена для AD на базе ОС Microsoft
Windows Server 2008 R2 Service Pack 1 или более новой версии с
установленным ПО Active Directory Services
Структурное подразделение УрФУ, соответствующее принятой
организационно-штатной структуре университета. В качестве
Подразделения могут выступать управление, центр, отдел, институт,
департамент, кафедра, лаборатория, сектор и т.п..
Сотрудник ОБС, назначенный в соответствии с регламентом
администрирования
единого
каталога
пользователей
и
обеспечивающий работоспособность Active Directory как сервиса,
предоставляемого подразделениям.
Назначенный в соответствии с регламентом администрирования
администратор в Active Directory, использующий Active Directory в
целях, необходимых подразделению.
Пользователь информационной инфраструктуры и сервисов УрФУ.
Включает в себя сотрудников, студентов, аспирантов, докторантов,
контрагентов и иные типы пользователей.
Учетная запись пользователя в едином каталоге пользователей
AT.URFU.RU. включает Имя учётной записи, Пароль и ряд других
атрибутов.
Набор программного, аппаратного и иного обеспечения,
функционирующий на базе информационной инфраструктуры
УрФУ
работающий
в
комплексе
и
предоставляющий
информационные услуги.
Single Sign-On - механизм единого входа в систему или в
приложение, принцип работы которого состоит в распознавании
любого интерфейса процесса аутентификации и автоматического
заполнения формы ввода пароля для каждого корпоративного
приложения.
Процедура проверки подлинности пользователя путём сравнения
введённого им пароля с паролем в базе данных пользователей.
Комплекс технологий и соответствующая инфраструктура, которые
позволяют использовать единое имя пользователя и/или его
4
Авторизация
мандат/сертификат идентификации для доступа в сетях, которые
установили между собой доверительные отношения и входят в
ассоциацию безопасности, обычно называемую "федерацией".
Предоставление пользователю прав доступа к информационным
ресурсам и прав на выполнение определённых действий в едином
каталоге пользователей.
5
2. Общие положения
2.1 Целью настоящего Регламента является описание порядка и методов интеграции
разрабатываемых и внедряемых в университете информационных сервисов с единым
каталогом пользователей AT.URFU.RU.
2.2 Регламент определяет общие правила интеграции информационных сервисов для
администраторов подразделений и разработчиков информационных сервисов УрФУ.
2.3 Единый
каталог
обеспечивающую
AT.URFU.RU
единые
представляет
механизмы
проверки
собой
централизованную
подлинности
службу,
(аутентификации
и
авторизации) всех пользователей УрФУ на базе технологий Microsoft Active Directory.
Единый каталог обеспечивает инфраструктуру для централизованного управления и
обслуживания компьютеров пользователей в домене Active Directory, а также используется
для поддержки работы и хранения конфигурации корпоративных информационных
сервисов.
2.4 Все информационные сервисы с числом пользователей более 100 должны быть
интегрированы с единым каталогом пользователей.
2.5 Интеграция информационного сервиса с единым каталогом позволяет обеспечить
следующие преимущества:

Аутентификацию пользователей сервиса через Active Directory;

Авторизацию пользователей сервиса через Active Directory;

Получение дополнительных данных о пользователях из Active Directory;

Получение иных данных из Active Directory (например, организационной
структуры университета, списка компьютеров или конфигурации сайтов Active
Directory);

Хранение и изменение конфигурации сервиса в Active Directory (такая
конфигурация
хранится
на
нескольких
площадках
и
автоматически
реплицируется);

Обеспечение технологии единого входа в систему (SSO) для пользователей
сервиса;

Интеграцию с иными сервисами, интегрированными с Active Directory
(например, с Exchange или инфраструктурой PKI).
6
3. Порядок интеграции информационного сервиса с единым каталогом
3.1. Интеграция информационного сервиса или информационной системы подразделения с
Active Directory (единым каталогом пользователей) выполняется и поддерживается
силами структурного подразделения УрФУ, ответственного за предоставляемый
информационный сервис или систему.
3.2. Для интеграции информационного сервиса с единым каталогом подразделение должно
иметь назначенного Администратора подразделения.
3.3. При
отсутствии
назначенного
Администратора
подразделения,
руководителю
подразделения необходимо назначить такого администратора в соответствии с
регламентом администрирования единого каталога пользователей AT.URFU.RU.
3.4. После назначения администратора подразделения, администратор подразделения
получает от Сервисного администратора (сотрудника ОБС) реквизиты учетной записи
с необходимыми полномочиями, а также комплект документации по единому каталогу
пользователей AT.URFU.RU.
3.5. Сервисные администраторы оказывают всю возможную помощь и поддержку
администраторам подразделений для планирования и выполнения интеграции
сервисов с единым каталогом.
3.6. Администратор подразделения должен ознакомиться с полученной документацией по
Active Directory,а также составить и выполнить план интеграции сервиса в
соответствии с рекомендациями, изложенными в следующем разделе данного
документа.
3.7. Внешние подрядчики, при необходимости интеграции внедряемого сервиса с Active
Directory, взаимодействуют с назначенным администратором подразделения, которое
является заказчиком или ответственным за внедрение данного сервиса.
3.8. Администратор подразделения в процессе интеграции сервиса при необходимости
создает временные и гостевые учетные записи, аналогичные обычным учетным
записям сотрудников и студентов УрФУ, а также специальные сервисные учетные
записи. Обычные учетные записи для работы программ использовать запрещено.
3.9. Сервисные
администраторы
Active
Directory
обеспечивают
доступность
и
работоспособность перечисленных далее в регламенте методов и возможностей
интеграции на серверах ОБС.
3.10.
или
При интеграции сложных сервисов, которые требуют внесения принципиальных
больших
изменений
в
структуру
7
Active
Directory,
следует
направить
соответствующий запрос сервисным администраторам Active Directory посредством
обращения в единую техническую службу поддержки Дирекции ИТ.
3.11.
Аналогичный
запрос
выполняется
при
необходимости
делегирования
расширенных полномочий на чтение или управление объектами в Active Directory для
сервисных учетных записей.
3.12.
Сервисные
администраторов
администраторы
подразделений
Active
на
Directory
внесение
могут
изменений
в
отклонить
запрос
единый
каталог
пользователей, если он противоречит регламентам или техно-рабочей документации
по единому каталогу пользователей.
8
4. План интеграции сервиса с единым каталогом пользователей
При интеграции сервиса администратору подразделения нужно выполнить следующие
действия:
4.1 Изучить и проанализировать возможности информационного сервиса по интеграции с
внешними системами аутентификации, авторизации и получения данных и в особенности с
Active Directory (например, используя соответствующую документацию по данному
сервису).
4.2 Изучить предоставляемые и поддерживаемые способы для интеграции сервисов с единым
каталогом пользователей, описанные в данном регламенте.
4.3 Составить требования к интеграции со стороны сервиса.
4.4 Выбрать методы и протоколы интеграции для аутентификации и авторизации, а также для
получения дополнительных данных (в зависимости от требований к интеграции).
4.5 В случае отсутствия общих методов или протоколов, поддерживаемых сервисом и единым
каталогом пользователей, необходимо спланировать доработку сервиса для использования
допустимых способов интеграции и протоколов.
4.6 Составить план интеграции и схему интеграции сервиса с единым каталогом. На этом
этапе следует определить правила авторизации пользователей и список используемых из
Active Directory данных.
4.7 Согласовать план и схему интеграции с сервисными администраторами единого каталога
пользователей. Без согласования плана и схемы поддержка интеграции сервиса
сервисными администраторами может не осуществляться.
4.8 Если для интеграции сервиса требуется доработка сервиса, то необходимо ее выполнить.
4.9 Внести в единый каталог пользователей необходимые для интеграции сервиса изменения
(создать нужные сервисные учетные записи, группы, включить компьютеры в домен).
4.10
Внести в сервис необходимые для интеграции изменения.
4.11
Провести опытно-промешенную эксплуатацию.
4.12
Внести в сервис необходимые для интеграции изменения по результатам опытно-
промышленной эксплуатации.
4.13
Запустить сервис в промышленную эксплуатацию.
9
5. Способы и протоколы интеграции сервиса с единым каталогом
5.1.
Инфраструктура
следующих
способов
единого
каталога
интеграции
с
пользователей
поддерживает
информационными
сервисами
использование
для
выполнения
аутентификации и авторизации пользователей:
1. Протокол Kerberos.
2. Протокол NTLM.
3. Использование Windows Integrated Authentication (SSPI).
4. Протокол LDAP для проверки учетных данных (bind).
5. Протокол LDAP для авторизации пользователей. Возможно подключение как от
имени учетных данных пользователя, так и имени специальных сервисных учетных
записей.
6. Протокол TACACS+.
7. Протокол RADIUS.
8. Интеграция файловых сервисов с DFS.
9. Использование SSL-сертификатов (в том числе смарт-карт) внутреннего центра
сертификации для TLS-аутентификации и авторизации пользователей Active
Directory.
10. Протокол IPSec (используя внутренние протоколы SSL/TLS, Kerberos и NTLM).
11. Возможности
веб-сервера
аутентификации,
для
IIS
авторизации
и
интеграции
возможности
с
Active
интеграции
Directory,
с
для
федеративной
аутентификацией.
12. Протокол OAuth (федеративная аутентификация).
13. Протокол WS-Federation/WS-Trust (федеративная аутентификация).
14. Протокол SAML 2.0 (федеративная аутентификация).
5.2.
Инфраструктура
единого
каталога
пользователей
поддерживает
использование
следующих способов авторизации пользователей и общего доступа (чтения и изменения) к
информации в Active Directory:
1. Протокол LDAP для хранения и изменения данных и конфигурации. Подключение
выполняется от имени сервисных учетных записей.
2. API ADSI для подключения к контроллерам домена по протоколу LDAP.
3. Внутренний SOAP веб-сервис Дирекции ИТ для получения упрощенных данных о
пользователях из Active Directory.
4. Active Directory Web Services (включая возможность использования PowerShell).
10
5. Интеграция с почтовой системой Exchange по протоколам IMAP, SMTP или
Exchange Web Services (EWS).
6. Интеграция с иными сервисами, интегрированными с Active Directory. Возможно
только при согласовании с сервисными администраторами и администраторами
промежуточных сервисов.
5.3. Не поддерживаются любые методы и протоколы интеграции информационных сервисов с
почтовой системой Exchange, за исключением протоколов (EWS, IMAP, SMTP).
5.4. Инфраструктурой единого каталога не поддерживаются следующие протоколы Active
Directory для интеграции сервисов:
1. SAMR (SAM Database Replication);
2. MAPI.
5.5. Протоколы REPL (Replicate Directory Changes), Microsoft Windows NT 4.0 (NetAPI) и SAM
поддерживаются только для системных задач (например, для репликации, подключения
компьютеров к домену или разрешения SID в имя), но не поддерживаются при интеграции
сервисов с единым каталогом.
5.6. В некоторых случаях информационный сервис самостоятельно реализует интеграцию с
Active Directory. Однако он в любом случае использует один из методов, перечисленных
выше. Соответственно, к таким сервисам также применимы рассматриваемые ниже уровни
SSO и требования к методам интеграции.
5.7. В некоторых случаях отдельные методы интеграции сервисов с единым каталогом могут
иметь дополнительные регламенты по использованию. При выборе определенного метода
интеграции информационного сервиса с единым каталогом администратору подразделения
следует уточнить у сервисных администраторов наличие дополнительных регламентов и
инструкцией, которые могут влиять на интеграцию сервисов.
11
6. Требования к информационным сервисам для интеграции с единым
каталогом.
6.1.
Требования к поддержке форматов логинов (имен пользователей)
6.1.1. Если сервис обеспечивает аутентификацию пользователей через Active Directory, то для
интеграции с единым каталогом он должен обеспечить поддержку следующих двух
стандартных форматов имен пользователей (логинов):

Explicit User Principal Name (User Logon Name, Explicit UPN, явный UPN,
содержит значение атрибута «userPrincipalName» учетной записи пользователя).
Это имя должно использоваться всеми новыми пользователями единого
каталога и пользователями, имеющими корпоративную почту в домене
«@urfu.ru». Например: Vladimir.Petrov@urfu.ru

SAM Account Name (Pre-2000 User Logon Name, значение атрибута
«sAMAccountName» учетной записи пользователя). Это имя все еще может
использоваться пользователями, мигрированными из старых доменов, и
администраторами. Например: Vladimir.Petrov
6.1.2. Имя для входа Explicit User Principal Name может меняться пользователем или
администратором на произвольное в течение жизни учетной записи в произвольное
время. Особенно часто User Principal Name меняется непосредственно при получении
учетной записи пользователем. Если приложение или сервис синхронизирует User
Principal Name, то оно должно быть готово к тому, что как только пользователь получит
учетную запись, его User Principal Name будет изменен без уведомления приложения.
Данный факт следует учитывать при синхронизации данного атрибута и не допускать
хранения устаревших значений более чем на 5 минут. Наилучшим вариантом будет
сопоставлению атрибута User Principal Name пользователю непосредственно во время
аутентификации.
6.1.3. Настоятельно
производных
рекомендуется
стандартных
также
обеспечить
форматов
имен,
поддержку
которые
могут
следующих
трех
использоваться
пользователями:

NetBIOS-формат.
Имеет
вид
«AT\SamAccountName»;
Например:
AT\Vladimir.Petrov;

NetBIOS-формат с FQDN. Имеет вид «AT.URFU.RU\SamAccountName»;
Например: AT.URFU.RU\Vladimir.Petrov;

Implicit User Principal Name (Implicit UPN, неявный UPN). Имеет вид
«SamAccountName@AT.URFU.RU». Например: Vladimir.Petrov@AT.URFU.RU.
12
6.1.4. Если сервис поддерживает только один вид имени пользователя, то следует использовать
формат Explicit User Principal Name. В этом случае поддержку пользователей,
использующих формат SAMAccountName, осуществляет администратор сервиса.
Требования к сервису по обработке паролей
6.2.
6.2.1. При передаче любых паролей (как пользователей, так и сервисных учетных записей) на
иные хосты следует проводить аутентификацию хостов (серверов), к которому
осуществляется подключение, в том числе при передаче пароля на контроллер домена
(например, с помощью статического пароля, сертификатов или протокола с взаимной
проверкой - Kerberos).
6.2.2. Если в приложении требуется передача паролей пользователей, администраторов или
сервисных учетных записей, то следует обязательно их шифровать одним из безопасных
методов шифрования (SSL, TLS, AES). Шифровать передачу паролей следует как между
клиентом и сервисом, так и между сервисами, и между сервисом и контроллеров домена.
6.2.3. При
передаче
паролей
следует
полностью
запретить
использование
слабых
криптографических алгоритмов (таких как SSL 2.0, SSL 3.0, RC4, MD5). При
использовании HTTPS следует приоритезировать алгоритмы, обеспечивающие Perfect
Forward Secrecy, а также обеспечить автоматическое перенаправление пользователей с
протокола HTTP на HTTPS, обеспечить secure cookies (флаг secure для передачи только
по безопасному протоколу) и HTTP Strict Transport Security (для того, чтобы браузер при
указании протокола HTTP все равно использовал протокол HTTPS).
6.2.4. Запрещается хранить пароли пользователей в постоянной памяти или длительное время
в
ОЗУ.
Пароли
пользователей
следует
немедленно
удалять
из
ОЗУ
после
аутентификации, когда они уже не требуются для проверки подлинности.
6.2.5. Пароли сервисных учетных записей следует хранить в зашифрованном виде, с запретом
доступа к ключам и шифротекстам обычных пользователей.
6.2.6. Запрещается запрашивать или получать актуальные пароли пользователя для
выполнения диагностики
конкретной
проблемы
с
данным
сервисом
у этого
пользователя. Пользователи не должны передавать свои пароли кому-либо. В случае
необходимости диагностики возможных проблем с конкретным сервисом у пользователя
следует
предусмотреть
иные
способы
диагностики
(логгирование,
имперсонация других пользователей и т.д.).
6.2.7. Необходимо обеспечить следующие ограничения на проверку паролей:
13
отладка,

Допускается не более 50 неуспешных попыток проверки пароля для одного
имени пользователя (логина в регистр в независимом виде) за 5 минут вне
зависимости от количества ip-адресов клиентов, с которых приходят запросы.
При превышении числа попыток аутентификации запрещается проверять
верность логина и пароля через Active Directory для данного логина.
Запрещается сбрасывать счетчики попыток аутентификации при успешном
входе.

Допускается не более 1000 неуспешных попыток проверки пароля за 5 минут с
одного Ip-адреса клиента вне зависимости от используемых логинов. При
превышении числа попыток запрещается проверять верность логина и пароля
через Active Directory для данного ip-адреса клиента. Запрещается сбрасывать
счетчики аутентификации при успешном входе.
6.3.
Иные требования к сервису
6.3.1. Если компьютеры пользователей или сервера для сервисов находятся в корпоративной
сети УрФУ, то они должны иметь корректную IP-адресацию, согласно стандарту ИПадресации УрФУ.
6.3.2. Для выполнения интеграции сервисов с единым каталогом не предоставляется полный
доступ к Active Directory (либо его аналог) администраторам подразделениям и
сервисам,
которые
данными
администраторами
поддерживаются.
Возможно
предоставление полномочий чтения некоторых объектов, полный доступ к какому-либо
специально-выделенному для сервиса контейнеру или организационной единице для
хранения конфигурации, либо возможность записи не влияющего на безопасность
какого-либо атрибута у существующих объектов.
6.3.3. Полное (неограниченное) делегирование Kerberos не предоставляется. Ограниченное
делегирование
на
сервисные
компьютеры
не
предоставляется.
Ограниченное
делегирование Kerberos предоставляются только на компьютеры своего подразделения,
либо с согласия администратора иного подразделения. По возможности, делегирование
Kerberos настраивается администраторами подразделений самостоятельно.
14
7. Технология единого входа (SSO)
Технология единого входа (Single Sign-On) позволяет переходить по ссылке от использования
одного веб-сервиса к другому без повторной аутентификации что избавляет пользователя от
многократного ввода данных своей учётной записи.
7.1. Степень обеспечения технологии единого входа (SSO) для пользователей при интеграции
сервиса с единым каталогом делится на пять уровней (данная категоризация используется как
для обычных приложений, так и для веб-приложений. В нее не входят приложения и сервисы,
не интегрированные с Active Directory):
1. Используются разные учетные данные пользователей в Active Directory и для
сервиса. Active Directory используется только для получения данных и/или
конфигурации сервиса. В данную категорию входит любой сервис, возможно
использующий авторизацию и доступ к данным к Active Directory, но не
выполняющий аутентификацию через Active Directory.
2. Один логин и пароль для Active Directory и для сервиса. Однако логин и пароль
требуется вводить каждый раз при подключении к каждому сервису. При этом
сервис может некоторое время кешировать сессию пользователя. Примеры: FTPсервер «store.urfu.ru»; использование на компьютерах не в домене общих папок
(файловых сервисов), не опубликованных через DFS.
3. Однократный ввод пароля для всех систем или сервисов. Однако логин
требуется вводить каждый раз при подключении к сервису. Например,
использование протокола- OpenID.
4. Для работы сервиса требуется интерактивное подтверждение аутентификации.
Повторный ввод логина и пароля для каждого сервиса не требуется. Например,
использование протоколов SSL/TLS в браузере.
5. Единый
вход
всех
приложений
без
необходимости
интерактивного
подтверждения. Логин и пароль необходимо вводить только один раз для
доступа к первому сервису определенного типа (например, для всех вебсервисов или для всех файловых сервисов). Примеры: использование на
компьютерах не в домене федеративной аутентификации AD FS; использование
на
компьютерах
не
в
домене
общих
папок
(файловых
сервисов),
опубликованных через DFS.
6. Единый вход для всех приложений без необходимости интерактивного
подтверждения. Логин и пароль нужно вводить только при входе пользователя в
15
операционную систему. Примеры: использование на компьютерах в домене
федеративной аутентификация AD FS; использование на компьютерах в домене
общих папок (файловых сервисов).
7.2. При интеграции сервиса с единым каталогом следует обеспечить наивысший техническивозможный (с учетом требований к безопасности и удобства работы пользователей) уровень
SSO по отдельности для каждой возможной категории пользователей или клиентов.
Например, могут быть следующие категории клиентов и пользователей: с ОС Windows или с
ОС *nix, внутри и вне корпоративной сети, интегрированные с Active Directory и нет, и т.д.
7.3. В описанных далее разделах по аутентификации, авторизации и доступа к данным для
каждого метода интеграции указаны возможные уровни SSO, которые метод может
обеспечить при интеграции сервиса с единым каталогом.
16
8. Методы аутентификации при интеграции сервиса с единым
каталогом
Большинство поддерживаемых методов аутентификации обычно поддерживают не
только аутентификацию пользователей, но и аутентификацию сервисов и компьютеров. Ниже
описаны
требования
и
описания
протоколов,
которые
можно
использовать
для
аутентификации и авторизации при интеграции сервиса с единым каталогом.
8.1.
Протоколы SSL и TLS
8.1.1. Сервисными администраторами Active Directory поддерживается инфраструктура PKI,
включающая в себя центры сертификации, веб-клиенты к ним и OCSP-сервера.
8.1.2. Пользователи и сервисы могут получать SSL-сертификаты из внутреннего центра
сертификации единого каталога. Полученные сертификаты можно использовать для
аутентификации пользователей и сервисов по протоколам SSL/TLS (например, на
сайтах и в сетях Wi-Fi). Контроллеры и компьютеры домена настроены на
автоматическое сопоставление выданных сертификатов пользователям из Active
Directory. В каждом сертификате содержится имя пользователя и сервиса и
дополнительная информация (например, email-адрес), которую можно использовать
для авторизации. Также каждый сертификат однозначно можно сопоставить
пользователю из Active Directory.
8.1.3. Сертификаты можно получать одним из следующих способов:

Через веб-интерфейс, доступный по адресу внутри корпоративной сети
«https://ca.urfu.ru».

С помощью оснасток MMC Windows.

Автоматически, при выполнении необходимых настроек на компьютерах
подразделения через групповые политики.
8.1.4. Как правило при аутентификации через SSL/TLS используется уровень SSO равный
трем. В качестве примера сервиса, использующего SSL/TLS-аутентификацию, можно
привести программу активации компьютеров не в домене через KMS-сервер.
8.1.5. Сертификаты можно использовать как для аутентификации пользователей и обычных
сервисов, так и для аутентификации веб-сервисов по протоколу HTTPS. На
компьютеры в домене корневой сертификат устанавливается автоматически. На
компьютеры не в домене корневой сертификат можно установить с сайта
«http://dit.urfu.ru/instrukcii/kornevoi-sertifikat-urfuru/», с сайта «https://ca.urfu.ru/» (только
17
внутри сети, используется взаимная проверка подлинности), а также получить из
хранилища доверенных корневых сертификатов с компьютера в домене.
8.1.6. Рекомендуется для обеспечения безопасности и удобства работы пользователей для
всех серверов не использовать самоподписанные сертификаты, а использовать либо
публичный сертификат, либо сертификат из внутреннего центра сертификации.
8.1.7. SSL и TLS аутентификация доступна внутри и вне корпоративной сети и в DMZ.
8.2.
Протокол Kerberos
8.2.1. При использования данного протокола для интеграции сервиса с единым каталогом
сервис должен поддерживать Kerberos-аутентификацию.
8.2.2. В Active Directory должна быть создана учетная запись (сервисная учетная запись
пользователя, учетная запись компьютера, Management Service Account, Group
Management Service Account) с зарегистрированным SPN (Service Principal Name)
сервиса. Использование учетных записей пользователей, имеющих класс отличной от
сервисной (согласно техно-рабочей документации по Active Directory), для регистрации
SPN не поддерживается.
8.2.3. Компьютер пользователя сервиса должен быть интегрирован с доменом. Если данный
компьютер не интегрирован с доменом, то он может использовать протокол Kerberos
только если размещается внутри корпоративной сети и использует формат имени
«SamAccountName@at.urfu.ru»
(который
обычные
пользователи
не
должны
использовать). Пользователь может вводить логин в таком формате как в клиентской
программе для сервиса, так и при использовании утилиты «runas» с параметром
«/netonly».
8.2.4. Пользователь может использовать логин и пароль для аутентификации, а также смарткарту с SSL-сертификатом из внутреннего центра сертификации.
8.2.5. Для работы протокола Kerberos необходима синхронизация времени в операционной
системе. Время можно получать от контроллеров домена и от NTP-сервера ntp.urfu.ru.
Администраторы ОБС гарантируют периодическую доступность NTP-сервера по DNSимени, но не по IP-адресу. Если администратор сервиса использует IP-адрес в качестве
NTP-сервера, он должен самостоятельно обновлять значение, при изменении значения
в системе DNS.
8.3.
Протокол NTLM
8.3.1. При использовании данного протокола для интеграции сервиса с единым каталогом
сервис должен поддерживать NTLM-аутентификацию.
18
8.3.2. Сервер, на котором развернут сервис, интегрируемый по протоколу NTLM, должен
быть в домене AT.URFU.RU.
8.3.3. Пользователь должен использовать логин и пароль для аутентификации.
8.3.4. Компьютер пользователя может находиться как в домене, так и нет.
8.4.
Протокол SSPI
8.4.1. Протокол SSPI инкапсулирует в себя протоколы Kerberos и NTLM. Этот протокол
также может включать в себя иные протоколы, но они не используются при интеграции
сервисов с Active Directory (например, PKU2U).
8.4.2. При использования данного протокола для интеграции сервиса с единым каталогом
сервис должен поддерживать SSPI-аутентификацию.
8.4.3. Сервер, на котором развернут сервис, интегрируемый по протоколу SSPI должен быть в
домене AT.URFU.RU.
8.4.4. Использование SSPI для интеграции сервиса с единым каталогом может накладывать
на сервис дополнительные требования, которые зависят от используемых внутренних
протоколов. При использовании и NTLM, и Kerberos возможности и требования
обычно объединяются.
8.4.5. Использование SSPI позволяет обеспечить поддержку всех стандартных форматов
имен пользователей.
8.4.6. Аутентификация NTLM, Kerberos или SSPI доступна:

Внутри корпоративной сети;

В DMZ и вне корпоративной сети для компьютеров в домене.
8.4.7. При использовании аутентификации NTLM, Kerberos или SSPI возможно достижение
следующих уровней SSO:

Для компьютеров в домене обеспечивается нависший уровень SSO – 5;

Для компьютеров не в домене обеспечивается уровень SSO – 1;

Для компьютеров не в домене, при использовании возможностей «runas
/netonly» может быть обеспечен уровень SSO – 4.
8.5.
Протоколы RADIUS и TACACS+
8.5.1. Для интеграции сервиса с единым каталогом возможно использовать протоколы
TACACS+ и RADIUS. При этом подразделение может использовать собственные
сервера TACACS+ и RADIUS, либо соответствующие сервера отдела базовых сервисов.
8.5.2. Отделом базовых сервисов протоколы RADIUS и TACACS+ предоставляются через два
сервера:
19

T04-505-RADIUS.at.urfu.ru. (имеет IP-адрес 10.96.242.97);

SK5-410-RADIUS.at.urfu.ru. (имеет IP-адрес 10.32.242.1).
8.5.3. Администраторы ОБС поддерживают статические DNS-адреса и IP-адреса у данных
серверов, однако при возможности использования DNS-имени, следует использовать
его вместо IP-адреса.
8.5.4. Для интеграции через данные протоколы администратор сервиса должен согласовать с
администраторами ОБС технические параметры для интеграции. После этого
администратор подразделения должен определить: какие данные следует передавать
сервису и по каким критериям авторизовать пользователей, как на RADIUS-сервере,
так и на информационном сервисе. Администратор ОБС внесет необходимую
информацию на TACACS+ и RADIUS-сервера.
8.5.5. RADIUS-сервер поддерживает следующие внутренние способы аутентификации
пользователей:

PAP-ASCII;

MS-CHAPv2;

EAP-TLS (использование клиентских сертификатов из внутреннего центра
сертификации);

EAP-PEAP (внутренние протоколы MS-CHAPv2 и GTC).
8.5.6. В качестве формата имени пользователя можно использовать все стандартные
форматы, за исключением Implicit UPN.
8.5.7. Администраторы ОБС гарантируют доступность только одного RADIUS сервера из
двух. Второй сервер может находиться на профилактике. Поэтому администраторы
сервиса должны настроить оба сервера на сервисе и организовать переключение на
второй в случае недоступности первого из серверов.
8.5.8. Подразделение может развертывать собственные сервера RADIUS, например, если к
ним существуют особые требования к аутентификации, доступности, доступу к
настройкам, правилам авторизации и т.д. В качестве ПО можно, например,
использовать Microsoft Network Policy Server, входящий в стандартный комплект
Windows Server Standard. Microsoft NPS поддерживает все стандартные формы имени
пользователя.
8.5.9. Аутентификация RADIUS доступна только внутри корпоративной сети.
8.5.10. Уровень SSO для TACACS-аутентификации – 1.
8.5.11. Уровень
SSO
для
RADIUS-аутентификации
зависит
от
RADIUS-супликанта,
используемого внутреннего способа аутентификации и факта включения клиентского
20
компьютера в домен, и может иметь значения 1 (например, для PAP-ASCII), 3
(например, для EAP-TLS) и 5 (например, для MS-CHAPv2).
8.5.12. Пример сервисов, использующих аутентификацию RADIUS – это Wi-Fi (уровень SSO
для компьютеров в домене – 5, для компьютеров не в домене – 1, при использовании
SSL/TLS - 3).
8.6.
Протокол LDAP
8.6.1. При использовании протокола LDAP для интеграции сервиса с единым каталогом
рекомендуется защищать передаваемые данные с помощью протоколов SSL (т.е.
использование протокола LDAPS) или TLS. Поддерживаются протоколы SSL версии
3.0 и TLS версии 1.0. Протокол SSL версии 2.0 не поддерживается. Сертификаты
LDAP-серверов подписаны корневым сертификатом внутреннего центра сертификации
предприятия,
доступного
по
ссылке
«http://dit.urfu.ru/instrukcii/kornevoi-sertifikat-
urfuru/». Методы получения корневого сертификата указаны в разделе «SSL и TLS». Во
всех сертификатах присутствует DNS-имя домена и DNS-имя сервера. Сертификаты на
КД (не корневой) могут быть заменены в любой момент на аналогичные.
8.6.2. Для определения адресов LDAP-серверов следует использовать методы обнаружения
контроллеров домена, описанные в разделе ниже. Для подключения нужно
использовать стандартные порты 389 или 636 (в зависимости от протокола
LDAP/LDAP+TLS или LDAPS).
8.6.3. При организации подключения по протоколу LDAP с использованием SSL или TLS со
стороны сервиса необходима обязательная проверка срока действия сертификата и
цепочки сертификата. Для всех DNS-имен, по которым осуществляется подключение,
также необходимо проверять имя сертификата на соответствие подключаемому имени
(за исключением одного имени, описанном ниже).
8.6.4. Для аутентификации (как при использовании протокола LDAP для проверки учетных
данных, так и для получения данных) поддерживаются следующие внутренние методы
LDAP:

Simple Bind. При использовании обязательна защита соединения с помощью
SSL/TLS). Несмотря на то, что на текущий момент LDAP-сервера этого не
требуют, данное требование может быть активировано ОБС в любой момент по
соображениям безопасности;

SASL (Kerberos/NTLM/SSPI);

SSL/TLS-аутентификация с использованием клиентских сертификатов из
внутреннего центра сертификации.
21
8.6.5. При использовании аутентификации SASL (Kerberos/NTLM/SSPI) без использования
SSL/TLS сервис должен поддерживать подпись пакетов (LDAP Signing). Несмотря на
то, что на текущий момент LDAP-сервера этого не требуют, данное требование может
быть активировано ОБС в любой момент по соображениям безопасности.
8.6.6. Root DN для подключения – «dc=at,dc=urfu,dc=ru». Если уровень поиска можно
ограничить определенными организационными единицами (OU), то в качестве Root DN
можно указывать distinguishedName этой организационной единицы (например,
«ou=manual, dc=at,dc=urfu,dc=ru»).
8.6.7. Аутентификация по LDAP доступна:

Внутри корпоративной сети;

В DMZ и вне корпоративной сети для компьютеров в домене.
8.6.8. При использовании протокола LDAP-аутентификации как правило уровень SSO равен
1.
8.6.9. Для подключения следует использовать сервисную учетную запись, которой разрешено
подключаться по протоколу LDAP к КД. Администраторы подразделения имеют
полномочия для создания учетных записей с данными параметрами.
8.6.10. В качестве логина для подключения от имени сервисной учетной записи следует
передавать на КД ее UserPrincipalName. Если передача UserPrincipalName не
поддерживается, то возможно передавать Distinguished Name (DN).
8.6.11. Если подключение осуществляется от имени учетных данных, которые указал
пользователь сервиса, то следует передавать их логины на LDAP-сервера в неизменном
виде, если в них имеется один из символов «@» или «\». Если данных символов нет, то
к логину следует добавить суффикс «@at.urfu.ru». Это позволит обеспечить поддержку
всех 5-ти форматов имен, используемых в едином каталоге.
8.6.12. При необходимости чтения каталога, следует запросить у сервисных администраторов
делегирование возможности чтения определенных объектов и их атрибутов в каталоге,
указав сервисную учетную запись, которой такие полномочия требуется делегировать.
8.6.13. Если требуется получить дополнительные атрибуты учетной записи, при наличии
логина пользователя, можно использовать фильтры LDAP. Фильтры зависят от
форматов <USERNAME>, введенным пользователем:

Вариант 1: для пользователей, которые ввели <USERNAME> без символов "@"
и "\".
“(&(samaccountname=<USERNAME>)(objectCategory=person)(objectClass=user)(g
roupsToIgnore=*)(!(street=Administrator)))” (формат имени пользователя
SAMAccounName).
22

Вариант 2: для пользователей, которые ввели <USERNAME> c символом "@".
“(&(userprincipalname=<USERNAME>)(objectCategory=person)(objectClass=user)(
groupsToIgnore=*)(!(street=Administrator)))” (формат имени пользователя Explicit
UserPrincipalName).

Также, если <USERNAME> оканчивается на "@at.urfu.ru", а предыдущий
фильтр ничего не нашел, нужно обрезать "@at.urfu.ru" и попробовать еще один
дополнительный фильтр:
(&(samaccountname=<USERNAME_WITHOUT_SUFFIX>)(objectCategory=person
)(objectClass=user)(groupsToIgnore=*)(!(street=Administrator))) (формат имени
пользователя Implicit UserPrincipalName).

Вариант 3: для пользователей, которые ввели <USERNAME> c символом "\".
Нужно оставить только часть <USERNAME> после символа "\".
“(&(samaccountname=<USERNAME_WITHOUT_PREFIX>)(objectCategory=perso
n)(objectClass=user)(groupsToIgnore=*)(!(street=Administrator)))” (формат имени
пользователя NetBIOS с FQDN и без).
8.7.
Протокол IPSec
8.7.1. Протокол IPSec возможно использовать для аутентификации и авторизации,
ограничивая доступ к сервису на транспортном IP-уровне. IPSec аутентификация может
использовать внутренние методы аутентификации Kerberos, NTLM и SSL/TLS.
8.7.2. Как правило для IPSec уровень SSO – 5.
8.7.3. Пример сервиса, использующего IPSec-аутентификацию, – это сервер KMS активации
компьютеров в домене.
8.7.4. Доступность аутентификации по протоколу IPSec зависит от
внутреннего протокола аутентификации.
23
использования
9. Аутентификация в операционных системах
Для обеспечения уровня SSO выше 1 для обычных приложений и веб-приложений без
федеративной
аутентификации,
потребуется
интеграция
клиентских
компьютеров
пользователей с Active Directory (то есть включение клиентских компьютеров в домен). Для
веб-приложений,
с
интегрированной
федеративной
аутентификацией,
интеграция
компьютеров пользователей с Active Directory потребуется для достижения уровня SSO в 5.
Для обеспечения уровня SSO выше 1 для обычных приложений и веб-приложений без
федеративной аутентификации также потребуется интеграция серверов с Active Directory. Для
веб-приложений с интегрированной федеративной аутентификацией для серверов достаточно
интеграции с федеративной аутентификацией для обеспечения любого уровня SSO.
9.1.
9.1.1.
Аутентификация в Windows
Наилучший способ интеграции компьютеров с ОС Windows - это создать учетную
запись компьютера в Active Directory и включить компьютер в домен Active Directory.
9.1.2.
При включении Windows в домен возможно использование всех стандартных
форматов имен пользователей.
9.1.3.
Если с включение компьютера в домен невозможно, то провести интеграцию ОС с
Active Directory можно с использованием протокола Kerberos. Для этого можно
использовать пакет MIT Kerberos (krb5), либо стандартную утилиту ksetup.exe
(опционально в дополнение к ней для удобства можно использовать инструменты
«runas» или «klogon.exe» ссылка «http://fy.chalmers.se/~appro/nt/klogon/»). Учетная
запись в Active Directory все равно потребуется. Однако в этом случае теряются
некоторые возможности: групповые политики, доступ к LDAP, синхронизация
сертификатов, Secure Channel (автоматическая синхронизация времени, разрешение
SID в имена и т.д.) и другие.
9.1.4.
Если использование протокола Kerberos также невозможно, то можно провести
интеграцию с использованием ПО «pGina», однако в этом случае уровень SSO будет
не выше 1 для большей части сервисов.
9.1.5.
Аутентификация в ОС Windows доступа внутри, вне корпоративной сети и в DMZ.
9.1.6.
Подключать компьютеры к домену могут только администраторы подразделений.
Произвольные пользователи этого делать не могут.
24
9.2.
Аутентификация в *nix-системах
Допускаются следующие методы интеграции *nix-систем с Active Directory:
9.2.1.

Использование
ПО
BeyondTrust
Powerbroker
open/Likewise
open
для
аутентификации и авторизации пользователей;

Использование ПО Centrify Express для аутентификации и авторизации
пользователей;

Использование протокола LDAP для аутентификации и авторизации;

Использование протокола Kerberos выполнения для аутентификации и
авторизации;

Использование winbind.
Использование winbind допускает ряд вариантов:
9.2.2.

Возможно интеграция winbind с krb5 для опциональной поддержки протокола
kerberos.
С
помощью
Kerberos
можно
выполнять
аутентификацию
и
авторизацию;

Возможна интеграция winbind с Active Directory по LDAP для выполнения
авторизации;

В самой полной схеме winbind может быть интегрирован как с krb5, так и с
LDAP.
Для регистрации учетной записи для работы Kerberos в Active Directory и получения
9.2.3.
пароля учетной записи можно выполнить следующую команду:

ktpass /princ ServiceInstance@AT.URFU.RU /mapuser AccountName /pass
Password /out Unixmachine.Keytab
9.2.4.
Apple MAC OS поддерживает интеграцию с Active Directory из коробки.
9.2.5.
Аутентификация в *nix-системах доступна только внутри корпоративной сети.
25
10. Аутентификация в веб-сервисах
10.1. Общая информация по веб-аутентификации
10.1.1. Для веб-приложений возможны следующие методы аутентификации:

Аутентификация с использованием стандартных, описанных ранее протоколов
(например, запрашивая имя пользователя и пароль с помощью метода Forms);

Аутентификация при помощи технологий федеративной аутентификации;

Аутентификация с помощью возможностей веб-сервера IIS (за исключением
метода Forms).
10.1.2. Если
используется один
из стандартных, описанных ранее протоколов, и
аутентификация Forms в веб-приложении, то следует при интеграции сервиса с
единым каталогом обеспечить:

Предоставление информации о том, каким образом возможно получить учетную
запись или сменить пароль (например, указав контакты администратора
подразделения или пользователей, или установив ссылку на соответствующий
сервис в приложении самообслуживания «https://id.urfu.ru/AccessManagement»).

Обработку сообщений о том, что пользователю необходимо перед входом
сменить пароль, а также указание на то, как это можно сделать (например,
реализовав
функционал
соответствующий
самостоятельно
сервис
в
или
установив
приложении
ссылку
на
самообслуживания
«https://id.urfu.ru/ProfileManagement»).
10.2. Федеративная аутентификация
10.2.1. Интеграция веб-приложений с единым каталогом возможна на основе технологий
федеративной аутентификации (на базе использования Active Directory Federation
Services) следующими способами:

Использование веб-приложением протокола WS-Trust/WS-Federation – Passive;

Использование веб-приложением протокола WS-Trust/WS-Federation – Active.
Этот протокол можно использовать также для обычных приложений, в которых
клиент передает свои учетные данные на сервер;

Использование веб-приложением протокола SAML 2.0;

Использование веб-приложением протокола OAuth (поддерживается только
Authorization Code Flow);

Сервисы,
использующие
встроенную
аутентификацию
IIS,
можно
перенастроить на использование федеративной аутентификации с провайдером
26
AD FS с помощью C2WTS (Claims to Windows Token Service). Автоматически
провести настройки можно с помощью FedUtil;

Использование Shibboleth SP с веб-сервером Apache или IIS. Веб-приложение
должно поддерживать Shibboleth SP.
10.2.2. Для выполнения интеграции веб сервиса с единым каталогом в этом случае следует
также использовать регламент интеграции сервисов с федеративной аутентификацией,
описанный в отдельном документе.
10.2.3. При интеграции веб-сервисов при помощи ADFS, сервисы автоматически получают
возможность использования единого входа в систему для веб-приложений. При этом
пользователям, на компьютерах не в домене, потребуется ввести логин и пароль
только один раз для доступа ко всем веб-сервисам (Уровень SSO - 4). Пользователям
на компьютерах в домене не потребуется вводить логин и пароль для доступа к вебсервисам (уровень SSO - 5).
10.2.4. Также
при
использовании
инфраструктуры
федеративной
аутентификации
пользователи сервиса сразу получают возможность (если это необходимо) сменить
пароль перед входом в систему, возможность получить учетную запись и
восстановить пароль.
10.2.5. Интегрированные с ADFS сервисы автоматически получают поддержку всех
стандартных форматов имен пользователей.
10.2.6. Интеграция обычных (не веб) сервисов с Active Directory Federation Services возможна
при помощи протокола WS-Federation – Active.
10.2.7. Сервисы при интеграции с федеративной аутентификацией могут также получить
возможность аутентификации пользователей из иных внешних систем (vk/facebook и
т.д.) и каталогов других организаций.
10.2.8. Для использования возможности аутентификации пользователей из иных внешних
систем и каталогов других организаций необходимо наличие соответствующего
коннектора. Если коннектор к требуемой системе еще не разработан, то
предварительно потребуется его разработка, развертывание и подключение к ADFS.
10.2.9. При
использовании
федеративной
аутентификации
возможно
выполнение
многофакторной аутентификации (например, по сертификату пользователя). Также
для усиления безопасности, сервис может требовать повторной аутентификации
пользователей каждый раз для доступа к сервису.
10.2.10. Федеративная аутентификация доступа внутри и вне корпоративной сети и в DMZ.
27
11. Интеграция сервиса с единым каталогом при помощи Вебсервера IIS
Если веб-приложение работает на веб-сервере IIS, то IIS можно использовать для
интеграции сервиса с Active Directory вместо интеграции веб-приложения. Для этого
требуется, чтобы веб-сервис поддерживал и использовал встроенную в IIS-аутентификацию. В
этом случае клиентами используется один из внутренних методов (NTLM, Basic, SSL/TLS,
SSPI с Kerberos или NTLM, методы федеративной аутентификации, но не Forms) для
аутентификации на веб-сервере IIS через протокол HTTP. Сам веб-сервер для обработки
запросов аутентификации использует механизм операционной системы SSPI.
Через веб-сервер IIS можно реализовать следующие модели аутентификации:

По логину и паролю;

Через сертификаты;

С использованием федеративной аутентификации.
Доступность аутентификации IIS зависит от внутренних используемых протоколов
аутентификации.
Уровень SSO при использовании аутентификации по логину и паролю с внутренним
методом Basic равен 1. Уровень SSO при использовании иных протоколов, соответствует
уровню SSO этих протоколов.
11.1. Аутентификация по логину и паролю в IIS
11.1.1. При аутентификации по логину и паролю (без использования федеративной
аутентификации) следующие методы аутентификации должны быть настроены в вебприложении на веб-сервере:

Windows Integrated Authentication с внутренними протоколами в следующем
порядке: Negotiate (SSPI), NTLM.

Basic (опционально).
11.1.2. Первый внутренний метод Negotiate в методе Windows Integrated Authentication
позволяет обеспечить SSO – 5 для компьютеров в домене (уровень 1 – для остальных
пользователей). Второй метод NTLM в методе Windows Integrated Authentication
требуется для поддержки браузеров, в которых метод Negotiate не поддерживается
или отключен по умолчанию (например, Mozilla Firefox). Внутренний метод Negotiate
должен использовать протоколы Kerberos и NTLM для аутентификации клиентов.
28
Соответственно, объединенные требования к этим протоколам (описанные выше)
должны быть выполнены: веб-сервера должны быть включены в домен, и в Active
Directory должна быть учетная запись с зарегистрированным SPN. Настройка Kernel
Mode Authentication для Windows Integrated Authentication в большинстве случаев
должна быть отключена.
11.1.3. Метод Basic требуется для поддержки браузеров, в которых метод Windows Integrated
Authentication не поддерживается, а также для работы клиентов через Proxy-сервера
(часть прокси-серверов меняет HTTP-заголовки, что ломает Windows Integrated
Authentication). При использовании метода Basic следует указать Realm по умолчанию
для работы формата имени Samaccountname.
11.1.4. Для обеспечения уровня SSO в 5 для компьютеров клиентов, подключенных к домену,
на этих компьютерах требуется настроить браузер. Например, в браузере Internet
Explorer требуется добавить сайт в группу «Локальная сеть» (Local Intranet), а в этой
группе
разрешить
автоматически
аутентифицироваться
на
веб-сайтах
с
использованием учетных данных, использованных для входа в систему (Automatically
logon with current username and password или Automatically logon only in Intranet zone).
В браузере Firefox нужно сделать соответствующие настройки и включить Windows
Integrated Authentication в настройках «about:config». На компьютерах подразделения
настройки браузеров можно провести централизованно через групповые политики.
При добавлении сайтов в группу «Локальная сеть» (Local Intranet) через групповые
политики
следует
использовать
Group
Policy
Registry
Preferences
(путь:
«Software\Microsoft\Windows\CurrentVersion\Internet
Settings\ZoneMap\Domains\urfu.ru\xxx»). Не следует жестко ограничивать список
сайтов (так как они могут добавляться в разных групповых политиках на разных
уровнях).
11.1.5. В качестве имени пользователя при аутентификации на веб-сервисах пользователям
всегда следует использовать формат имени Explicit UPN (User Logon Name), который
и должен использовать по умолчанию всеми пользователями. Все остальные форматы
имен пользователей должны также работать во всех конфигурациях браузеров и
клиентских ОС, за исключением Internet Explorer на Windows-компьютерах не в
домене, на котором просто SAMAccountName (Pre-2000 Windows Logon Name) не
работает. В Internet Explorer на Windows-компьютерах не в домене следует
использовать любой иной формат имени, за исключением просто SAMAccountName.
11.1.6. Аутентификацию Basic не следует использовать без использования Windows
Integrated Authentication, так как при ее использовании учетные данные всех
29
пользователей передаются в открытом виде (даже если клиент поддерживает NTLM
или Kerberos). Единственным исключением являются сервисы, в которых логин и
пароль требуются выполнения действий от имени пользователя на контроллерах
домена в Active Directory (например, сервис uc.urfu.ru). Но при необходимости
выполнения действий от имени пользователя на иных серверах и сервисах следует
использовать
делегирование
Kerberos
(за
более
подробной
информацией
о
делегировании Kerberos следует обратиться к сервисным администраторам Active
Directory).
11.1.7. В Windows Integrated Authentication не следует включать внутренний метод «PKU2U»,
так как он не предназначен для аутентификации через домен. Для исключения ошибок
аутентификации
пользователей
не
следует
включать
внутренний
метод
«Negotiate:Kerberos», за исключением случаев, когда это рекомендуется сервисными
администраторам Active Directory.
11.2. Федеративная аутентификация в IIS
11.2.1. Если веб-приложение поддерживает IIS-аутентификацию, но не поддерживает
федеративную
аутентификацию,
то
веб-сервер
IIS
можно
непосредственно
интегрировать с федеративной аутентификацией вместо интеграции конечного вебприложения (см. подробнее в разделе 10.2 ).
11.2.2. Некоторые
веб-приложения
(например,
SharePoint)
позволяют
одновременно
использовать как аутентификацию IIS (для доступа к документам), так и
федеративную аутентификацию (для доступа пользователей на портал). В этом случае
в веб-приложении для обеспечения наивысшего уровня SSO для разных категорий
клиентов следует использовать как федеративную аутентификацию, так и IISаутентификацию.
11.3. Аутентификация по сертификатам в IIS
11.3.1. На веб-сервере IIS можно также использовать аутентификацию по SSL-сертификатам,
выданных внутренним центром сертификации пользователям из Active Directory.
SSL/TLS-аутентификацию можно использовать вместо и в дополнение к обычной
аутентификации (по логину и пароль или федеративной).
11.3.2. Для поддержки SSL/TLS-аутентификации веб-приложению требуется использование
протокола HTTPS. На веб-сервере IIS нужно активировать опцию «Directory Client
Certificate Authentication» на уровне веб-сервера и настройку «Accept Client
Certificate» или «Require Client Certificate» в зависимости от необходимости разрешать
30
клиентам выполнять Failback на обычную аутентификацию (по логину и пароль или
федеративной) или необходимости использования только SSL/TLS-аутентификации.
11.3.3. Клиенты должны иметь установленный сертификат. Получить они его могут
автоматически через групповые политики или через веб-сервис «ca.urfu.ru» (доступен
только внутри корпоративной сети).
31
12. Авторизация в сервисах
При интеграции сервиса с единым каталогом Active Directory можно использовать не
12.1.
только для аутентификации пользователей, но и для авторизации, используя
следующие инструменты:

Предопределённые группы безопасности (например, Domain Users, Domain
Computers, All Students, All Staff, All Services, All Tutors, IMKN Students, IMKN
Staff, IMKN Computers и т.д.).

Группы безопасности, созданные администратором подразделения. Управлять
членами этих групп могут как администраторы подразделения, так и иные
пользователи (руководители/владельцы сервиса), которым администраторы
подразделения предоставят доступ. Управлять членами этих групп можно как с
помощью оснасток MMC, так и с помощью веб-интерфейса управления
пользователями uc.urfu.ru, так и с помощью собственных/иных программных
средств по протоколу LDAP/ADSI.

Атрибуты пользователей (используемые атрибуты рекомендуется согласовывать
с сервисными администраторами Active Directory, так как часть их них может
быть изменена пользователем самостоятельно, а часть может не всегда
содержать те значения, которые ожидаются).
12.2.
Для авторизации нельзя использовать расположение учетной записи пользователя в
каталоге (организационная единица), так как учетная запись пользователя может быть
перемещена в другую организационную единицу в любой момент в соответствии с
логикой функционирования единого каталога и процессами синхронизации с
кадровыми системами университета.
12.3.
Сервис может реализовывать собственные механизмы авторизации без использования
авторизации через Active Directory. Также сервис может совмещать собственные
методы авторизации с методами авторизации Active Directory (например, по атрибуту
из AD получать данные о пользователе из иной базы данных и на основании них
принимать решение об авторизации).
12.4.
Сервис может выполнять аутентификацию и получать данные из AD, не выполняя
авторизации совсем.
12.5.
При использовании авторизации с помощью групп Active Directory, сервис должен
поддерживать локальные, глобальные и универсальные группы, а также вложенность
групп друг в друга, и при необходимости развёртывать группы. Для протоколов
Kerberos, NTLM, SSPI, RADIUS это обычно поддерживается автоматически. При
32
использовании протокола LDAP для поддержки рекурсивных групп в фильтрах
необходимо либо использовать оператор «LDAP_MATCHING_RULE_IN_CHAIN»
(OID «:1.2.840.113556.1.4.1941:») для LDAP-атрибутов «membefOf» и «member», либо
развертывать группы рекурсивно в программном коде с помощью чтения LDAPатрибутов «membefOf» и «member».
12.6.
Для усиления безопасности сервис может дополнять аутентификацию и авторизацию
через Active Directory собственной реализацией многофакторной аутентификации
(например, через телефон, email, повторный ввод пароля, дополнительный пароль,
сертификат, смарт-карту, сканер отпечатков пальцев, токен и т.д.) для выполнения
дополнительной авторизации.
33
13. Обмен данными между единым каталогом и сервисом
13.1 Способы получения информации из Active Directory
13.1.1. Получать информацию из Active Directory можно следующими двумя способами:

При аутентификации и авторизации пользователя с помощью выбранного при
интеграции протокола аутентификации и авторизации;

С помощью перечисленных выше протоколов доступа к информации Active
Directory.
13.1.2. При получении информации по протоколу LDAP от имени аутентифицированного
пользователя, уровень SSO будет равен 1 (так как сервису необходимо получить от
пользователя логин и пароль для дальнейшего подключения к Active Directory).
13.1.3. При получении информации по протоколу LDAP от имени специальной сервисной
учетной записи уровень SSO может быть любой. Нужно учесть, что обычные
сервисные
учетные
записи
не
могут
читать
информацию
о
большинстве
пользователей из Active Directory и группах безопасности. Если полномочия чтения
сервисной учетной записи необходимы, то нужно сделать запрос сервисным
администраторами
для делегирования сервисной
учетной
записи
требуемых
полномочий.
13.1.4. Сервис может хранить данные и конфигурацию в Active Directory. Для доступа к
данными и конфигурации следует использовать протокол LDAP (либо API над этим
протоколом). Например, вместо прямого подключения по протоколу LDAP в ОС
Windows можно использовать API ADSI (через модель COM+).
13.1.5. Протоколы Active Directory Web Services обычно используются комманлетами
PowerShell из модуля Active Directory. Интегрируемый сервис может использовать как
PowerShell для получения и изменения информации в Active Directory, так и протокол
Active Directory Web Services непосредственно.
13.1.6. SOAP-сервис является единственным предоставляемым методом (так как в Active
Directory дата рождения не хранится), с помощью которого можно определить по
ФИО и дате рождения конкретного пользователя из Active Directory. С помощью
SOAP-сервиса возможно получение иных данных из Active Directory. Доступ и
документация к SOAP-сервису предоставляется сервисными администраторами по
запросу администраторов подразделений.
13.1.7. Протокол REPL можно использовать для получения данных из Active Directory.
Пример использования- SharePoint User Profile Synchronization и DirSync. Репликация
34
паролей и иных секретов всем сервисам подразделений запрещена (за исключением
отдела базовых сервисов). По возможности следует использовать DirSync ACL Mode.
Также использование ACL Security Mode является обязательным. При использовании
ACL Security Mode не потребуется дополнительное делегирование полномочий
сервисными администраторами Active Directory (за исключением полномочий
чтения).
13.1.8. Если Active Directory используется только для получения информации, без
аутентификации, то уровень SSO будет – 0.
13.1.9. Часть методов получения данных может быть доступна только внутри корпоративной
сети (SOAP веб-сервис). Часть методов также доступна вне корпоративной сети и в
DMZ, если компьютер включен в домен (протокол LDAP, API ADSI, Active Directory
Web Services, REPL).
13.2 Данные о пользователях, хранимые в Active Directory
13.2.1. В Active Directory для одного пользователя хранится только одна основная учетная
запись пользователя, а пользователь может являться и сотрудником, и студентом
одновременно, в том числе нескольких институтов. Поэтому одна учетная запись
может одновременно хранить данные о нескольких местах работы пользователя и
нескольких местах учебы пользователя. Интегрируемый сервис должен уметь
обрабатывать такие учетные записи.
13.2.2. Active Directory является авторитативным хранилищем следующих данных о
пользователях:

Аутентификационных данных пользователя (имя пользователя, логин и пароль,
статус активности, сертификат, смарт-карта и т.д.).

Мобильные телефоны пользователя. В AD хранится как основной мобильный
телефон, так и список дополнительных телефонов. Список дополнительных
телефонов может пересекаться или не пересекаться с основным мобильным
телефоном. При наличии списка дополнительных телефонов, основной телефон
обязательно присутствует.

Корпоративный email-адрес пользователя. В AD хранится один основной
корпоративный email-адрес. Соответствующий атрибут всегда заполнен. Потому
если полученный корпоративный email-адрес имеет суффикс «@at.urfu.ru», это
следует интерпретировать как отсутствие корпоративного email-адреса.

Внешний-контактный email-адрес пользователя. В AD хранится как основной
внешний (контактный) email-адрес, так и список дополнительных. Список
35
дополнительных внешних (контактных) email-адресов может пересекаться или
не пересекаться с основным внешним (контактным) email-адресом. При наличии
списка дополнительных внешних (контактных) email-адресов, основной телефон
обязательно основной внешний (контактный) email-адрес.
13.2.3. Если сервису необходимо получить все email-адреса пользователя, то следует
объединить данные из полей: корпоративный email-адрес, основной внешний
(контактный) email-адрес и дополнительные внешние (контактные) email-адреса. Если
сервису необходимо получить один основной email-адрес, то обычно берется
корпоративный email-адрес, если он есть. Если корпоративный email-адрес
отсутствует, то обычно берется основной внешний (контактный) email-адрес.
13.2.4. В Active Directory имеется следующая неавторитативная публичная информация:

Фамилия, имя и отчество на русском языке;

Информация о месте работы пользователя и должности (подразделение,
должность, тип персонала, тип занятости, статус);

Информация о месте учебы пользователя (институт, департамент, кафедра, курс,
уровень ВПО, группа, студенческий номер, форма обучения, статус);

Принадлежность пользователя к подразделению УрФУ.
13.2.5. Публичная
информация
синхронизируется
из
внешних
кадровых
систем
и
предназначена для поиска пользователей, отображения нужных атрибутов в
интерфейсах, а также обработки пользователей вручную. Использовать для
авторизации ее следует с осторожностью. Для этих целей рекомендуется получать
актуальные данные из исходных источников данных (связывая записи в AD и
источниках данных с помощью уникальных идентификаторов). Перечисленные
публичные данные о сотрудниках обрабатываются в соответствии с подписанными
сотрудниками УрФУ заявлениями, в котором они соглашаются, что перечисленные
выше типы данных могут быть включены в общедоступные источники персональных
данных.
13.2.6. Не поддерживается фильтрация или изменение данных, импортируемых из кадровых
систем, как при импорте данных в Active Directory, так как при экспорте данных из
Active Directory. Если приложению, которые с интегрируется с Active Directory, часть
данных не подходит, то приложение самостоятельно должно данные фильтровать или
изменять или получать требуемые данные из кадровых систем непосредственно.
13.3 Уникальные идентификаторы
13.3.1. В Active Directory имеется следующая техническая информация:
36

Уникальные идентификаторы пользователя из внешних источников
данных. Их можно использовать для установления связи учетной записи
пользователя с записью в источнике данных о пользователе;

Уникальные идентификаторы пользователя, используемые в Active
Directory. Их можно использовать как первичный ключ.
13.3.2. В каталоге возможны следующие типы уникальных идентификаторов пользователя из
внешних источников данных:

GUID студента из ЕИСУ (uni);

Хеш индивидуального номера сотрудника из 1С;

Студенческий номер из ИС «Деканат»;

Уникальный идентификатор на основе ФИО и даты рождения.
13.3.3. Все уникальные идентификаторы пользователя из внешних источников данных
хранят тип в виде префикса к идентификатору.
13.3.4. Все уникальные идентификаторы пользователя из внешних источников данных
хранятся в одном и томе же многозначном атрибуте учетной записи пользователя.
Приложение, использующее их, должно уметь получать все идентификаторы из
многозначного атрибута и отличать один тип уникального идентификатора от другого
и вычленять непосредственно идентификатор из строки с типом. Для одной учетной
записи может быть несколько уникальных идентификаторов одного типа. При
добавлении внешних источников данных о пользователей, список типов уникальных
идентификаторов из внешних источников данных может быть расширен.
13.3.5. Атрибуты из внешних баз источников могут хранится в хешированном виде. Поэтому
не следует пытаться искать на основе этой информации запись о пользователе во
внешней базе данных. Однако возможно обратное: имеется возможность найти
учетную запись пользователя в AD на основе информации из внешней базы данных.
13.3.6. Ниже представлен список уникальных идентификаторов пользователя, используемых
в Active Directory:

DistinguishedName учетной записи пользователя (DN) – имя объекта при доступе
по протоколу LDAP. Уникально в определенный момент времени, но может
быть изменено в любой момент времени пользователем, администратором или
ПО синхронизации, например, при перемещении пользователя;

Имя пользователя (User Principal Name, User Logon Name) – имя пользователя
для входа в систему. Уникально в определенный момент времени, но может
меняться пользователем или администратором на произвольное в течение жизни
учетной записи в произвольное время. Особенно часто User Principal Name
37
меняется непосредственно при получении учетной записи. Если приложение
синхронизирует User Principal Name, то оно должно быть готово к тому, что как
только пользователь получит учетную запись, его User Principal Name будет
изменен без уведомления приложения. Данный факт следует учитывать при
синхронизации данного атрибута и не допускать хранения устаревших значений
более чем на 5 минут. Наилучшим вариантом будет сопоставлению атрибута
User Principal Name пользователю непосредственно во время аутентификации;

SamAccountName (Pre-2000 Logon Name). Пользователи не должны знать и
использовать это имя для аутентификации. Уникально в определенный момент
времени. Генерируется при создании учетной записи. Дальнейшее изменение
запрещено все пользователям, программам и администраторам, хотя технически
может быть возможно.

SID принципала безопасности. Основной атрибут и стандартный уникальный
идентификатор, используемый при авторизации в сетях Windows. Не изменяется
после создания учетной записи. Изменение возможно теоретически только при
миграции учетной записи в иной домен (с сохранением значения SID в другой
атрибут – SID History), но так как поддерживается только один домен, то можно
считать этот атрибут неизменным. При аутентификации пользователей по
протоколам SSPI, Kerberos или NTLM рекомендуется использовать данный
уникальный идентификатор для сопоставления или поиска пользователя в Active
Directory.

GUID объекта в Active Directory. Стандартный уникальный идентификатор
любого объекта любого типа в AD. Самый «уникальный» идентификатор. При
возможности следует использовать именно его. Не изменяется после создания
учетной записи. Изменение возможно теоретически только при миграции
учетной записи в иной лес, но так как поддерживается только один лес, то
можно считать атрибут неизменным.
13.3.7. Имена LDAP-атрибутов, в которых хранится перечисленная выше информация и
уникальные идентификаторы, детально описаны в техно-рабочей документации по
единому каталогу пользователей AT.URFU.RU. Администраторы подразделений при
необходимости
могут
получить
данную
документацию
у
Сервисных
администраторов.
13.3.8. При наличии технической возможности в Active Directory могут быть добавлены иные
данные, если они необходимы для аутентификации и авторизации пользователей.
13.3.9. В Active Directory отсутствует и не может быть добавлена следующая информация:
38

Дата рождения пользователя;

Конфиденциальная информация;

Не перечисленный выше любой вид непубличной персональной информации (за
исключением контактных данных);

Финансовые данные.
13.3.10. Полный
список
подразделений
атрибутов
получают
учетных
от
записей
сервисных
пользователей
администраторов
администраторы
Active
Directory.
Администраторы подразделений могут запросить у сервисных администраторов
список атрибутов для иных типов объектов в Active Directory при необходимости.
13.4 Объединение данных из каталога и иных систем при интеграции сервиса
13.4.1. В некоторых случаях данные, полученные из Active Directory разными способами,
требуется сопоставлять друг другу или объединять. Так часто бывает, если данные из
Active Directory получаются одним способом, а аутентификация выполняется иным
способом. Например, данные о пользователя могут получаться по LDAP, а для
аутентификации пользователей использоваться протокол Kerberos.
13.4.2. Для сопоставления данных, следует использовать атрибуты, которые наименее
подвержены изменениям. Это, например, уникальные идентификаторы: Guid или SID
пользователя. Guid следует использовать в общем случае. SID пользователя следует
использовать, если применяется интегрированная Windows-аутентификация, Kerberos,
NTLM или SSPI.
13.4.3. Для сопоставления данных не следует использовать параметры, которые могут
изменяться (например, логин пользователя или студенческий номер).
39
14. Методы обнаружения контроллеров домена
14.1 Общие принципы
14.1.1. Контроллеры доменов являются серверами, поддерживающими работу Active
Directory. Каждый контроллер домена имеет собственную копию базы данных Active
Directory, поддерживающую запись и чтение. Все операции безопасности и проверки
учетных записей выполняются на контроллере домена.
14.1.2. Архитектура
единого
отказоустойчивости
каталога
пользователей
предусматривает
наличие
в
целях
нескольких
обеспечения
одновременно
функционирующих контроллеров домена.
14.1.3. При использовании многих методов интеграции требуется обнаружение адресов
контроллеров домена, к которым необходимо подключаться для выполнения задач
аутентификации, авторизации или обмена данными с единым каталогом.
14.1.4. Список доступных контроллеров домена может изменяться в любой момент времени,
также в интегрируемых с единым каталогом сервисах не следует прописывать
статические DNS-адреса или IP-адреса контролеров домена.
14.1.5. Если адрес контроллера домена был найден, то осуществлять поиск адреса нового
контроллера домена следует в следующих случаях:

Если выбранный контроллер домена стал недоступен;

Если перезапускается приложение, сервис или сервер;

Периодически.
14.1.6. Любой
контроллер
домена
во
время
выполнения
запроса
(особенно
продолжительного) может быть отключен (например, для установки обновлений). Это
штатная ситуация. Приложение (сервис) должно уметь обрабатывать такие ситуации.
В этом случае, следует выполнить поиск адреса нового контроллера домена и
повторить невыполненный запрос на нем.
14.1.7. Архитектура единого каталога пользователей предусматривает, что как минимум
один контроллер домена для записи и как минимум один контроллер домена в
текущем кампусе будет доступен в любой момент времени.
14.1.8. Для исключения необходимости выполнения повторных запросов поиска контроллера
домена не рекомендуется выполнять длительные запросы к Active Directory. Следует
большие запросы разбивать на несколько маленьких.
14.1.9. Для обнаружения адресов контроллеров домена следует использовать следующий
порядок:

Получить IP-адреса DNS-серверов;
40

Используя найденные адреса DNS-сервера, получить DNS-адреса и IP-адреса
контроллеров домена.
14.1.10. Использование DNS-серверов является обязательным. Указание в конфигурации и
подключение к контроллеру домена напрямую по ip-адресам не допускается и не
поддерживается.
14.2 Получение адресов DNS-серверов
14.2.1. Для получения и разрешения имен домена Active Directory и контроллеров домена
возможно использование следующих DNS-серверов:

Внутренние DNS-сервера отдела базовых сервисов;

Публичные DNS-сервера, зарегистрированные в публичном DNS-регистраторе.
14.2.2. Список адресов внутренних DNS-серверов отдела базовых сервисов можно получить
с помощью DHCP-серверов отдела базовых сервисов. Список внутренних DNSсерверов, выдаваемых по протоколу DHCP может измениться без уведомления. Для
получения достоверной информации следует периодически получать новый список от
DHCP-серверов.
14.2.3. Список публичных DNS-серверов можно получить, рекурсивно разрешая DNS-имена,
начиная с корневого домена «.». Список публичных DNS-серверов может измениться
без уведомления – необходимо периодически получать новый список от корневых
DNS-серверов. Через публичные DNS-сервера доступы контроллеры домена только
для чтения.
14.2.4. В каждом из двух списков отдел базовых сервисов обеспечивает работоспособность и
доступность не менее одного DNS-сервера. Это значит, что в каждом списке все DNSсервера, кроме одного, могут быть недоступны. Операционная система или сервис
должны уметь самостоятельно определять доступный и работоспособный DNSсервер.
14.2.5. Разрешение имен домена и контроллеров домена Active Directory через иные DNSсервера не поддерживаются.
14.2.6. Если сервис или сервер не может динамически получать адреса DNS-серверов от
DHCP-сервера отдела базовых сервисов или через публичные DNS-сервера, то
администратор подразделения может указать ip-адреса DNS-серверов статически. Но
в этом случае он должен следить самостоятельно за изменением соответствующего
списка DNS-серверов и, при необходимости, обновлять адреса DNS-серверов
вручную.
41
14.3 Получение адресов контроллеров домена
14.3.1. Статическое подключение только к одному контроллеру домена не допускается и не
поддерживается.
14.3.2. Для получения адресов контроллеров домена следует использовать следующие
автоматические методы:

Службу «DC Locator» на компьютерах с ОС Windows для поиска домен
«at.urfu.ru»;

LDAP Serverless bind с указанием только DNS-имени домена «at.urfu.ru» и/или
Root DN «dc=at,dc=urfu,dc=ru» (либо вложенный Root DN – подробнее в разделе
по LDAP);

DNS-запрос SRV-записей «_ldap._tcp.dc._msdcs.at.urfu.ru.». Для протокола
Kerberos DNS-запросы могут немного иными;

DNS-имен балансировщика «dc.dit.urfu.ru», предоставляемого ОБС внутри
корпоративной сети. По данному DNS-имени доступен один работоспособный
КД. Работоспособность КД определяется автоматически балансировщиком ОБС.
14.3.3. Некоторые из найденных таким образом контроллеров домена могут быть
неработоспособны и не доступны. Операционная система или сервис должны уметь
самостоятельно определять доступный и работоспособный контроллер домена для
выполнения своих задач.
14.3.4. Следует всегда указывать для контроллера домена именно DNS-имена. Требуется
использовать полные DNS-имена домена и КД. Не допускается использование
кратких имен имени домена («at») и КД (без суффикса «at.urfu.ru»).
14.3.5. Если сервис не поддерживает DNS-адреса контроллеров домена, то можно указать IPадреса в порядке по приоритету соответствующих DNS SRV-записей, однако данный
сценарий не поддерживается сервисными администраторами единого каталога. В этом
случае, администратор подразделения должен самостоятельно следить за изменением
списка ip-адресов контроллеров домена и, при необходимости, обновлять ip-адреса
контроллеров домена вручную.
14.3.6. В случае указания DNS-имен КД вручную администратор подразделения должен
самостоятельно следить за изменением списка контроллеров домена, а также их
доступностью и, при необходимости, обновлять адреса контроллеров домена
вручную.
42
14.4 Статическое использование DNS-имен контроллеров домена для
компьютеров и серверов подразделений внутри корпоративной сети для
протокола LDAP
14.4.1. Если сервис не поддерживает возможность работы без указания конкретных серверов,
то следует указывать следующие DNS-адреса для компьютеров и серверов
подразделений внутри корпоративной сети для протокола LDAP:

DNS-имя балансировщика «dc.dit.urfu.ru». Поддерживает только протокол
LDAPS с шифрованием SSL и портом 636. В сертификате данного сервера
имеется только имя «at.urfu.ru». Необходимо, если возможно, проверять в
сертификате наличие имени «at.urfu.ru». Если это невозможно, то нужно не
проверять имя сертификата. Если и это невозможно, то следует не проверять
сертификат вообще.

DNS-имя домена «at.urfu.ru». Поддерживает любые протоколы. Обязательно в
сертификате проверять имя сервера.
14.5 Статическое использование DNS-имен контроллеров домена в сегменте
DMZ или для сервисных компьютеров или для протоколов отличных от
LDAP
14.5.1. Если сервис не поддерживает возможность работы без указания конкретных серверов,
то следует указывать следующие DNS-адреса для сервисных компьютеров или для
протоколов отличных от LDAP:

Список полных DNS-адресов контроллеров домена, доступных в данном
сетевом сегменте, отсортированный по приоритету советующих DNS SRVзаписей;

Последним сервером следует указать DNS-имя домена «at.urfu.ru».
14.5.2. Если имеется ограничение на максимальное число серверов и указать все эти сервера
нельзя, то следует уменьшать список DNS-адресов контроллеров домена. DNS-имя
домена следует указывать всегда.
14.5.3. В случае, если возможно указать только 1 сервер, то нужно указывать только DNSимя домена «at.urfu.ru».
14.5.4. Если возможно указать только 4 сервера внутри сети, нужно указать следующее:

T04-505-PDC-PRI.at.urfu.ru;

SK5-410-PDC-SEC.at.urfu.ru;

T04-505-WDC-PHY.at.urfu.ru;
43

at.urfu.ru.
14.5.5. Если возможно указать только 3 сервера в DMZ, нужно указать следующее:

T04-505-RODC1.at.urfu.ru;

SK5-410-RODC1.at.urfu.ru;

at.urfu.ru.
44
45