Ldap

Итак, дано:

Настройка сервисов:

user = rootgroup = root

group_authorization {    if (&LDAP-Group[*] == "CN=vpn_admins,OU=vpn-groups,DC=domain,DC=local") {            update reply {                &Fortinet-Group-Name = "vpn_admins" }            update control {                &Auth-Type := PAM                &Reply-Message := "Welcome Admin"                }        }    else {        update reply {        &Reply-Message := "Not authorized for vpn"            }        reject        }}

ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldap

ldap {        server = 'domain.local'        identity = 'CN=freerad_user,OU=users,DC=domain,DC=local'        password = "SupeSecretP@ssword"        base_dn = 'dc=domain,dc=local'        sasl {        }        user {                base_dn = "${..base_dn}"                filter = "(sAMAccountname=%{%{Stripped-User-Name}:-%{User-Name}})"                sasl {                }                scope = 'sub'        }        group {                base_dn = "${..base_dn}"                filter = '(objectClass=Group)'                scope = 'sub'                name_attribute = cn                membership_filter = "(|(member=%{control:Ldap-UserDn})(memberUid=%{%{Stripped-User-Name}:-%{User-Name}}))"                membership_attribute = 'memberOf'        }}

client fortigate {    ipaddr = 192.168.1.200    secret = testing123    require_message_authenticator = no    nas_type = other}

#%PAM-1.0auth       sufficient   pam_google_authenticator.soauth       include      password-authaccount    required     pam_nologin.soaccount    include      password-authpassword   include      password-authsession    include      password-auth

• Freeradius проверяет наличие пользователя в домене и в определенной группе и, в случае успеха, производится проверка OTP токена.

[root@freeradius ~]# yum install -y shellinabox

[root@freeradius ~]#systemctl enable --now shellinaboxd

• Пользователь логинится на машину через браузер.
• Проверяется доменный ли пользователь. Если нет, то никаких действий не предпринимается.
• Если пользователь доменный, проверяется принадлежность к группе администраторов.
• Если не админ, проверяется настроен ли Google Autheticator. Если нет, то генерируется QR-код и logout пользователя.
• Если не админ и Google Authenticator настроен, то просто logout.
• Если админ, то опять проверка Google Authenticator. Если не настроен, то генерируется QR-код.

# .bash_profile# Get the aliases and functionsif [ -f ~/.bashrc ]; then        . ~/.bashrcfi# User specific environment and startup programs# Make several commands available from user shellif [[ -z $(id $USER | grep "admins") || -z $(cat /etc/passwd | grep $USER) ]]  then    [[ ! -d $HOME/bin ]] && mkdir $HOME/bin    [[ ! -f $HOME/bin/id ]] && ln -s /usr/bin/id $HOME/bin/id    [[ ! -f $HOME/bin/google-auth ]] && ln -s /usr/bin/google-authenticator $HOME/bin/google-auth    [[ ! -f $HOME/bin/grep ]] && ln -s /usr/bin/grep $HOME/bin/grep    [[ ! -f $HOME/bin/figlet ]] && ln -s /usr/bin/figlet $HOME/bin/figlet    [[ ! -f $HOME/bin/rebel.tlf ]] && ln -s /usr/share/figlet/rebel.tlf $HOME/bin/rebel.tlf    [[ ! -f $HOME/bin/sleep ]] && ln -s /usr/bin/sleep $HOME/bin/sleep  # Set PATH env to <home user directory>/bin    PATH=$HOME/bin    export PATH  else    PATH=PATH=$PATH:$HOME/.local/bin:$HOME/bin    export PATHfiif [[ -n $(id $USER | grep "domain users") ]]  then    if [[ ! -e $HOME/.google_authenticator ]]      then        if [[ -n $(id $USER | grep "admins") ]]          then            figlet -t -f $HOME/bin/rebel.tlf "Welcome to Company GAuth setup portal"            sleep 1.5            echo "Please, run any of these software on your device, where you would like to setup OTP:Google Autheticator:AppStore - https://apps.apple.com/us/app/google-authenticator/id388497605Play Market - https://play.google.com/stor/apps/details?id=com.google.android.apps.authenticator2&hl=enFreeOTP:AppStore - https://apps.apple.com/us/app/freeotp-authenticator/id872559395Play Market - https://play.google.com/store/apps/details?id=org.fedorahosted.freeotp&hl=enAnd prepare to scan QR code."            sleep 5            google-auth -f -t -w 3 -r 3 -R 30 -d -e 1            echo "Congratulations, now you can use an OTP token from application as a password connecting to VPN."          else            figlet -t -f $HOME/bin/rebel.tlf "Welcome to Company GAuth setup portal"            sleep 1.5            echo "Please, run any of these software on your device, where you would like to setup OTP:Google Autheticator:AppStore - https://apps.apple.com/us/app/google-authenticator/id388497605Play Market - https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=enFreeOTP:AppStore - https://apps.apple.com/us/app/freeotp-authenticator/id872559395Play Market - https://play.google.com/store/apps/details?id=org.fedorahosted.freeotp&hl=enAnd prepare to scan QR code."            sleep 5            google-auth -f -t -w 3 -r 3 -R 30 -d -e 1            echo "Congratulations, now you can use an OTP token from application as a password to VPN."            logout        fi      else        echo "You have already setup a Google Authenticator"        if [[ -z $(id $USER | grep "admins") ]]          then          logout        fi    fi  else    echo "You don't need to set up a Google Authenticator"fi

Настройка Fortigate:

• Создаем Radius-сервер
  
  
• Создаем необходимые группы, в случае необходимости разграничения доступа по группам. Имя группы на Fortigate должно соответствовать группе, которая передается в Vendor Specific Attribute Fortinet-Group-Name.
  
  
• Редактируем необходимые SSL-порталы.
  
  
• Добавляем группы в политики.
  
  

• Есть возможность аутентификации по OTP на Fortigate опенсорс решением.
• Исключается ввод доменного пароля пользователем при подключении по VPN, что несколько упрощает процесс подключения. 6-цифровой пароль ввести проще, чем тот, который предусмотрен политикой безопасности. Как следствие, уменьшается количество тикетов с темой: Не могу подключиться к VPN.

Что такое single sign-on?

Технология единого входа (Single sign-on SSO) метод аутентификации, который позволяет пользователям безопасно аутентифицироваться сразу в нескольких приложениях и сайтах, используя один набор учетных данных.

Как работает SSO?

SSO базируется на настройке доверительных отношений между приложением, известным как провайдер услуг, и системой управления доступами, например, OneLogin. Такие доверительные отношения часто базируются на обмене сертификатом между системой управления доступами и провайдером услуг. Такой сертификат может использоваться, чтобы обозначить идентификационную информацию, которая отправляется от системы управления доступами провайдеру услуг, таким образом провайдер услуг будет знать, что информация поступает из надежного источника. В SSO идентификационные данные принимают форму токенов, содержащих идентификационные значения информации о пользователе такие, как email или имя пользователя.

Порядок авторизации обычно выглядит следующим образом:

1. Пользователь заходит в приложение или на сайт, доступ к которому он хочет получить, то есть к провайдеру услуг.
2. Провайдер услуг отправляет токен, содержащий информацию о пользователе (такую как email адрес) системе SSO (так же известной, как система управления доступами), как часть запроса на аутентификацию пользователя.
3. В первую очередь система управления доступами проверяет был ли пользователь аутентифицирован до этого момента. Если да, она предоставляет пользователю доступ к приложению провайдера услуг, сразу приступая к шагу 5.
4. Если пользователь не авторизовался, ему будет необходимо это сделать, предоставив идентификационные данные, требуемые системой управления доступами. Это может быть просто логин и пароль или же другие виды аутентификации, например одноразовый пароль (OTP One-Time Password).
5. Как только система управления доступами одобрит идентификационные данные, она вернет токен провайдеру услуг, подтверждая успешную аутентификацию.
6. Этот токен проходит сквозь браузер пользователя провайдеру услуг.
7. Токен, полученный провайдером услуг, подтверждается согласно доверительным отношениям, установленным между провайдером услуг и системой управления доступами во время первоначальной настройки.
8. Пользователю предоставляется доступ к провайдеру услуг.

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

Что такое токен в контексте SSO?

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

Является ли технология SSO безопасной?

Ответом на этот вопрос будет "в зависимости от ситуации".

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

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

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

Как внедрить SSO?

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

• С какими типами пользователей вы работаете и какие у них требования?
• Вы ищете локальное или облачное решение?
• Возможен ли дальнейший рост выбранной программной платформы вместе с вашей компанией и ее запросами?
• Какие функции вам необходимы, чтобы убедиться в том, что процесс авторизации проходят только проверенные пользователи? MFA, Adaptive Authentication, Device Trust, IP Address Whitelisting, и т.д?
• С какими системами вам необходимо интегрироваться?
• Нужен ли вам доступ к программному интерфейсу приложения (API)?

Что отличает настоящую SSO от хранилища или менеджера паролей?

Важно понимать разницу между SSO (Технологией единого входа) и хранилищем или менеджерами паролей, которые периодически путают с SSO, но в контексте Same Sign-On что означает такой же/одинаковый вход, а не единый вход (Single Sign-On). Говоря о хранилище паролей, у вас может быть один логин и пароль, но их нужно будет вводить каждый раз при переходе в новое приложение или на новый сайт. Такая система попросту хранит ваши идентификационные данные для других приложений и вводит их когда это необходимо. В данном случае между приложением и хранилищем паролей не установлены доверительные отношения.

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

В чем разница между программным обеспечением единого входа и решением SSO?

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

Бывают ли разные типы SSO?

Когда мы говорим о едином входе (SSO), используется множество терминов:

• Federated Identity Management (FIM)
• OAuth (OAuth 2.0 в настоящее время)
• OpenID Connect (OIDC)
• Security Access Markup Language (SAML)
• Same Sign On (SSO)

На самом деле, SSO это часть более крупной концепции под названием Federated Identity Management, поэтому иногда SSO обозначается, как федеративная SSO. FIM просто относится к доверительным отношениям, созданным между двумя или более доменами или системами управления идентификацией. Система единого входа (SSO) это характеристика/фича, доступная внутри архитектуры FIM.

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

OpenID Connect (OIDC) это уровень аутентификации, наложенный на базу OAuth 2.0, чтобы обеспечить фунциональность SSO.

Security Access Markup Language (SAML) это открытый стандарт, который также разработан для обеспечения функциональности SSO.

Система Same Sign On, которую часто обозначают, как SSO, на самом деле, не похожа Single Sign-on, т.к не предполагает наличие доверительных отношений между сторонами, которые проходят аутентификацию. Она более привязана к идентификационным данным, которые дублируются и передаются в другие системы когда это необходимо. Это не так безопасно, как любое из решений единого входа.

Также существуют несколько конкретных систем, которые стоит упомянуть, говоря о платформе SSO: Active Directory, Active Directory Federation Services (ADFS) и Lightweight Directory Access Protocol (LDAP).

Active Directory, который в настоящее время именуется, как Active Directory Directory Services (ADDS) это централизованная служба каталогов Microsoft. Пользователи и ресурсы добавляются в службу каталогов для централизованного управления, а ADDS работает с такими аутентификационными протоколами, как NTLM и Kerberos. Таким образом, пользователи, относящиеся к ADDS могут аутентифицироваться с их устройств и получить доступ к другим системам, интегрированным с ADDS. Это и есть форма SSO.

Active Directory Federation Services (ADFS) это тип управления федеративной идентификацией (Federated Identity Management system), которая также предполагает возможность Single Sign-on. Он также поддерживает SAML и OIDC. ADFS преимущественно используется для установления доверительных отношений между ADDS и другими системами, такими как Azure AD или других служб ADDS.

Протокол LDAP (Lightweight Directory Service Protocol) это стандарт, определяющий способ запроса и организации информационной базы. LDAP позволяет вам централизованно управлять такими ресурсами, как пользователи и системы. LDAP, однако, не определяет порядок авторизации, это означает, что он не устанавливает непосредственный протокол, используемый для аутентификации. Но он часто применяется как часть процесса аутентификации и контроля доступа. Например, прежде, чем пользователь получит доступ к определенному ресурсу, LDAP сможет запросить информацию о пользователе и группах, в которых он состоит, чтобы удостовериться, что у пользователя есть доступ к данному ресурсу. LDAP платформа на подобие OpenLDAP обеспечивает аутентификацию с помощью аутентификационных протоколов (например, Simple Authentication и Security Layer SASL).

Как работает система единого входа как услуга?

SSO функционирует также, как и многие другие приложения, работающие через интернет. Подобные OneLogin платформы, функционирующие через облако, можно отнести к категории решений единого входа Software as a Service (SaaS).

Что такое App-to-App (приложение-приложение) SSO?

В заключение, возможно вы слышали о App-to-App SSO. Пока еще такой подход не является стандартным. Такое понятие больше используется SAPCloud для обозначения процесса передачи идентификационных данных пользователя из одного приложения в любое из других, состоящих в их экосистеме. В какой-то степени такой метод присущ OAuth 2.0, но хочется снова подчеркнуть, что это не стандартный протокол или метод. В настоящее время он является характерным только для SAPCloud.

Введение

LDAP, или Lightweight Directory Access Protocol, является открытым протоколом, используемым для хранения иполучения данных изкаталога сиерархической структурой. Обычно используемый для хранения информации оборганизации, ееактивах ипользователях, LDAP является гибким решением для определения любого типа сущностей иихсвойств.

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

Что такое служба каталогов?

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

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

Что такое LDAP?

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

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

Основные компоненты данных LDAP

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

Атрибуты

Сама информация вLDAP-системе восновном хранится вэлементах, называемых атрибутами. Атрибуты, восновном, являются парами ключ-значение. Вотличие отнекоторых других систем, ключи имеют предопределённые имена, которые продиктованы выбранным для данной записи объектными классами (обэтом мыпоговорим чуть позже). Более того, данные ватрибуте должны соответствовать типу, определённому висходном определении атрибута.

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

email: admin@example.com

При обращении катрибуту иего данным (когда оннезадан), две стороны соединяются знаком равенства:

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

Записи

Атрибуты сами посебе неочень полезны. Чтобы иметь смысл, они должны быть связаны счем-то. ВLDAP выиспользуете атрибуты впределах записи (entry). Запись, посути, представляет собой набор атрибутов под именем, используемым для описания чего-либо.

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

Пример записи, отображаемой вLDIF (LDAP Data Interchange Format), будет выглядеть примерно так:

dn: sn=Ellingwood,ou=people,dc=digitalocean,dc=comobjectclass: personsn: Ellingwoodcn: Justin Ellingwood

Приведенный выше пример может быть валидной записью всистеме LDAP.

DIT

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

Например, если можно иметь записи как для пользователя, так идля объекта инвентаризации, как кто-то сможет отличить ихдруг отдруга? Один изспособов отличить записи разных типов это создание отношений игрупп. Это взначительной степени зависит оттого, где находится запись при еесоздании. Все записи добавляются всистему LDAP ввиде веток надеревьях, называемых Data Information Trees, или DIT-ы.

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

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

Впримере записи вразделе выше мывидим одно указание наDIT, встроке dn:

Эта строка называется distinguished name (dn, отличительное имя) записи (подробнее обэтом позже) ииспользуется для идентификации записи. Она функционирует как полный путь докорня DIT. Вданном случае унас есть запись под названием sn=Ellingwood, которую мысоздаем. Прямым родителем является запись сименем ou=people, которая, вероятно, используется вкачестве контейнера для записей, описывающих людей. Родители этой записи произошли отдоменного имени digitalocean.com, которое выступает как корень нашей DIT.

Определение компонентов данных LDAP

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

Определения атрибутов

Атрибуты определяются сиспользованием достаточно сложного синтаксиса. Они должны указывать имя атрибута, любые другие имена/названия, которые могут быть использованы для ссылки наатрибут, тип данных, атакже множество других метаданных. Эти метаданные могут описывать атрибут, указывая LDAP, как сортировать или сравнивать значение атрибута, ипояснять, как онсоотносится сдругими атрибутами.

Например, это определение для атрибута name:

attributetype (<nobr>2.5.4.41</nobr> NAME 'name' DESC 'RFC4519: common supertype of&nbsp;name attributes' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX <nobr>1.3.6.1</nobr>.4.1.1<nobr>466.115.121.1</nobr>.15{32768})

name это имя атрибута. Номер впервой строке это глобально уникальный OID (object id, идентификатор объекта), присвоенный атрибуту, чтобы отличить его отвсех остальных атрибутов. Остальная часть записи определяет, как можно сравнить запись вовремя поиска, иимеет указатель, поясняющий, где найти информацию потребуемому типу данных атрибута.

Одной изважных частей определения атрибута является то, можетли атрибут быть задан взаписи более одного раза. Например, вопределении может быть определено, что фамилия может быть определена взаписи только один раз, ноатрибут niece позволительно указывать несколько раз водной записи. Атрибуты поумолчанию многозначны идолжны содержать флаг <nobr>SINGLE-VALUE</nobr>, если ихможно задавать взаписи только один раз.

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

Определения классов объектов

Атрибуты собираются всущностях, называемых ObjectClass (классы объектов). ObjectClasses это просто группировка связанных атрибутов, которая былабы полезна при описании конкретной вещи. Например, person это objectClass.

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

Таким образом, если Высоздаете запись для описания человека, тоobjectClass person (или любой изболее специфических объектов objectClasses, производных отperson обэтом мыпоговорим позже) позволяет использовать все атрибуты внутри этого objectClass:

dn: . . .objectClass: person

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

cn: Общее имя (Common name)

description: Понятное человеку описание записи

seeAlso: Ссылка насвязанные записи

sn: Фамилия (Surename)

telephoneNumber: Номер телефона

userPassword: Пароль пользователя

Атрибут objectClass может использоваться несколько раз, если вам нужны атрибуты изразных классов объектов, ноесть правила, которые диктуют, что разрешено. ObjectClasses может быть нескольких типов.

Два основных типа ObjectClasses это структурный (structural) идополнительный (auxiliary). Запись должна должна иметь ровно один структурный класс, номожет иметь ноль или более вспомогательных классов, используемых для дополнения списка атрибутов, доступных этому классу. Структурный ObjectClasses используется для создания иопределения записи, авспомогательные ObjectClasses-ы добавляют дополнительную функциональность через дополнительные атрибуты.

Определения ObjectClass определяют, являютсяли предоставляемые атрибуты обязательными (обозначаются спецификацией MUST) или необязательными (обозначаются спецификацией MAY). Несколько ObjectClasses могут предоставлять одни итеже атрибуты, акатегоризация атрибута MAY или MUST может варьироваться отobjectClass-а кobjectClass-у.

Вкачестве примера, объект Класс person определяется так:

objectclass (<nobr>2.5.6.6</nobr> NAME 'person' DESC 'RFC2256: a&nbsp;person' SUP top STRUCTURAL MUST (sn&nbsp;$ cn) MAY (userPassword $ telephoneNumber $ seeAlso $ description))

Это определяется как структурный объектClass, что означает, что онможет быть использован для создания записи. Созданная запись должна содержать заданными атрибуты surname иcommonname, иможет, при желании, содержать аттрибуты userPassword, telephoneNumber, seeAlso, или description.

Схемы

Определения ObjectClass иопределения атрибутов, всвою очередь, сгруппированы вконструкции, известной как schema (схема). Вотличие оттрадиционных реляционных баз данных, схемы вLDAP представляют собой просто наборы взаимосвязанных ObjectClasses иатрибутов. Один DIT может иметь много различных схем, так что онможет создавать нужные ему записи иатрибуты.

Схемы часто включают дополнительные определения атрибутов имогут требовать атрибутов, определенных вдругих схемах. Например, объектный класс person, окотором мыговорили выше, требует, чтобы атрибут surname или sn был установлен для любых записей, использующих объектный класс person. Если они неопределены всамом LDAP-сервере, схема, содержащая эти определения, может быть использована для добавления этих определений всловарь сервера.

Формат схемы, посути, является просто комбинацией вышеперечисленных записей, например:

. . .objectclass (<nobr>2.5.6.6</nobr> NAME 'person' DESC 'RFC2256: a&nbsp;person' SUP top STRUCTURAL MUST (sn&nbsp;$ cn) MAY (userPassword $ telephoneNumber $ seeAlso $ description))attributetype (<nobr>2.5.4.4</nobr> NAME ('sn' 'surname') DESC 'RFC2256: last (family) name(s) for which the entity is&nbsp;known by' SUP name)attributetype (<nobr>2.5.4.4</nobr> NAME ('cn' 'commonName') DESC 'RFC4519: common name(s) for which the entity is&nbsp;known by' SUP name). . .

Организация данных

Мырассмотрели общие элементы, которые используются для построения записей вLDAP системе ипоговорили отом, как эти строительные блоки определяются всистеме. Однако мыеще немного говорили отом, как организована иструктурирована сама информация вLDAP DIT.

Размещение записей вDIT

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

Верхний DIT это самая широкая категория, под которой каждый последующий узел является чьим-то потомком. Обычно самая верхняя часть записи просто используется как метка, называющая организацию, для которой DIT используется. Эти записи могут быть иметь любой объектный класс, нообычно они строятся сиспользованием доменных компонентов (dc=example,dc=com для управляющей информации LDAP, связанной сexample.com), местоположений (l=new_york,c=us для организации или сегмента вНью-Йорке), или подразделений организации (ou=marketing,o=Example_Co).

Записи, используемые для организации (используемые как папки) часто используют объектный класс organizationalUnit, что позволяет использовать простой описательную метку атрибут сназванием ou=. Такого рода записи часто используются для общих категорий взаписи DIT верхнего уровня (пример часто используемых ou=people, ou=groups иou=inventory). LDAP оптимизирован для поиска информации подереву внаправлении вправо-влево, аневверх-вниз, поэтому зачастую лучше поддерживать иерархию DIT неглубокой, собобщенными организационными ветвями, идальнейшим указанием наразличия через задание определенных атрибутов.

Именование (Naming) иссылочные записи (Referencing Entries) вDIT

Мыссылаемся назаписи поихатрибутам. Это означает, что каждая запись должна иметь однозначный атрибут или группу атрибутов насвоем уровне виерархии DIT. Этот атрибут или группа атрибутов называется относительное отличительное имя или RDN (отrelative distinguished name), инесет туже функцию, что иимя файла вкаталоге.

Чтобы однозначно ссылаться назапись, выиспользуете её RDN всочетании совсеми RDN её родительских записей. Эта цепочка RDN ведет назад, вверх поиерархии DIT иуказывает однозначный путь ксоответствующему элементу. Мыназываем эту цепочку RDN различимым именем или DN (отdistinguished name). Выдолжны указать DNдля записи вовремя создания, чтобы система LDAP знала, где разместить новую запись, имогла убедиться, что RDN записи уже неиспользуется другой записью.

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

Например, запись для человека поимени Джон Смит может быть помещена под запись People ворганизации example.com. Так как ворганизации может быть несколько Джонов Смитов, идентификатор пользователя может быть лучшим выбором для RDN записи. Запись может быть указана вот так:

dn: uid=jsmith1,ou=People,dc=example,dc=comobjectClass: inetOrgPersoncn: John Smithsn: Smithuid: jsmith1

Нам пришлось использовать объектный класс inetOrgPerson, чтобы получить доступ катрибуту uid вданном случае (кроме того, мыещё имеем доступ ковсем атрибутам, определенным вобъектном классе person, причина этого будет понятна вследующем разделе).

Наследование вLDAP

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

Наследование объектных классов

Каждый objectClass это класс, который описывает характеристики объектов данного типа.

Однако, вотличие отпростого наследования, объекты вLDAP могут быть, ичасто являются, экземплярами нескольких классов (некоторые языки программирования предоставляют аналогичную функциональность посредством множественного наследования). Это возможно потому, что LDAP под классом понимает просто набор атрибутов, которые онДОЛЖЕН (MUST) или может (MAY) иметь. Это позволяет указать для записи несколько классов (хотя только один структурный объектный класс может идолжен присутствовать), врезультате чего объект просто имеет доступ кобъединенной коллекции атрибутов сострожайшими определениями MUST или MAY, имеющими приоритет.

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

objectclass (<nobr>2.5.6.7</nobr> NAME 'organizationalPerson' SUP person STRUCTURAL. . .

Родительским объектом является объектный класс, следующий заидентификатором SUP. Класс-родитель должен быть тогоже типа, как иопределяемый объектный класс (например, STRUCTURAL или AUXILIARY). Дочерний объектный класс автоматически наследует атрибуты итребования атрибутов родителя.

При назначении объектного класса конкретной записи, Вам нужно только указать самого последнего потомка цепочки наследования, чтобы иметь доступ ковсему набору атрибутов. Впредыдущем разделе мыиспользовали это для указания inetOrgPerson вкачестве единственного objectClass для нашей записи John Smith, втоже время получив доступ катрибутам, определенным вобъектных классах person иorganizationalPerson. Иерархия наследования inetOrgPerson выглядит следующим образом:

inetOrgPerson -> organizationalPerson -> person -> top

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

Наследование атрибутов

Точно также, сами атрибуты могут указать родительский атрибут всвоем определении. Вэтом случае атрибут наследует свойства, которые были установлены вродительском атрибуте.

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

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

Вариации протокола LDAP

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

Стоит упомянуть, что выможете увидеть некоторые варианты вобычном формате:

ldap://: Это основной протокол LDAP, позволяющий получить структурированный доступ кслужбе каталогов.

ldap://: Этот вариант используется для доступа кLDAP поверх SSL/TLS. Обычно трафик LDAP нешифруется, нобольшинство реализаций LDAP поддерживают подобный вариант доступа. Такой способ шифрования LDAP-соединений насамом деле устарел, ивместо него рекомендуется использовать шифрование STARTTLS. Если выработаете сLDAP через незащищенную сеть, настоятельно рекомендуется шифрование.

ldapi://: Это используется для указания LDAP через IPC. Это часто используется для безопасного соединения слокальной LDAP-системой вадминистративных целях. Онсвязывается через внутренние сокеты вместо того, чтобы использовать открытый сетевой порт.

Все три формата используют протокол LDAP, нопоследние два указывают надополнительную информацию отом, как ониспользуется.

Заключение

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