«Тонкие клиенты»
«Тонкий клиент» (thin client) — разновидность интеллектуального терминала. Правильнее - его программное обеспечение, которое позволяет загружать и выполнять сетевые приложения (клиентские скрипты, Java-апплеты, ActiveX-приложения и т.п.) в некотором программном окружении (например, в браузере или виртуальной машине).
Протоколы удаленного управления
telnet
Служба удаленного управления telnet (Teletype Network) ) — одна из самых старых сетевых технологий Internet (первая спецификация — RFC 158 от 19.05.1971 г.). Текущая спецификация telnet — RFC 854/STD 8 – Telnet Protocol Specification. По умолчанию сервер telnet принимает входящие подключения на 23-ий порт TCP (см. Сетевые сервисы).
Протокол telnet изначально разрабатывался для использования в гетерогенных сетях. В его основе — концепция сетевого виртуального терминала (Network Virtual Terminal, NVT) — механизма абстрагирования от специфики ввода/вывода различных аппаратных и программных платформ. Так, например, в UNIX в качестве символа перехода на другую строку используется LF (код 13), в то время как в MS-DOS и Windows — пара символов CR-LF (коды 10 и 13). Сетевой виртуальный терминал NVT предлагает использование унифицированного набора символов, который используется для преобразования кодов клиента и сервера.
Хотя в сессии telnet выделяют клиентскую и серверную сторону, протокол является симметричным и обе стороны взаимодействуют через NVT, обмениваясь данными двух типов:
Прикладными данными (т.е. данными, которые идут от пользователя к серверному приложению и обратно);
Опциями протокола telnet, служащими для уяснения возможностей и предпочтений сторон.
Прикладные данные проходят через протокол без изменений т.е. на выходе второго виртуального терминала мы видим именно то, что было введено на вход первого. С точки зрения протокола эти данные - просто последовательность байтов (октетов), по умолчанию принадлежащих набору ASCII. Если же установлена опция Binary — то последовательность любых данных в двоичном представлении.
Все значения октетов прикладных данных кроме \377 (десятичное 255) передаются по транспорту как есть. Октет \377 передаётся последовательностью \377\377 из двух октетов. Это связано с тем, что октет \377 используется для кодирования опций протокола.
Telnet поддерживает четыре режима передачи:
Полудуплексный режим. NVT по умолчанию это полудуплексное устройство, которое требует исполнения специальной команды (GO AHEAD, GA) от сервера, перед тем как будет принят ввод от пользователя. Ввод пользователя отображается локальным эхом от NVT клавиатуры на NVT принтер, таким образом, от клиента к серверу посылаются только полные строки.
Посимвольный. Каждый вводимый символ отправляется серверу отдельно от других. Сервер отражает эхом (опция ECHO — RFC 857) большинство символов и эти символы отражаются на экране клиента.
Блочный. Отправка данных производится по принципу "строка за один раз".
Линейный режим (linemode). В данном случае этот термин означает реальную опцию linemode (RFC 1184). Эта опция обсуждается клиентом и сервером и корректирует все недостатки в режиме строка за один раз.
С точки зрения безопасности протокол telnet уязвим для любого вида атак, к которым уязвим его транспорт, т.е. протокол TCP. В протоколе не предусмотрено использование ни шифрования, ни проверки подлинности данных. Поэтому telnet можно использовать в полностью контролируемой сети или с применением защиты на сетевом уровне (различные реализации виртуальных частных сетей). По причине ненадёжности от telnet как средства управления операционными системами давно отказались.
Иногда клиенты telnet используются для доступа к другим символьно-ориентрованным протоколам на основе транспорта TCP (HTTP, IRC, SMTP, POP3 и прочим). Однако, использование клиента telnet в этом качестве может привести к ошибкам, связанным с неправильной трактовкой сервером опций протокола (листнг 3).
Листинг 1. Использование telnet в качестве веб-браузера
aag@stilo.asoiu:~> telnet 4stud.asoiu 80
Trying 194.188.210.1...
Connected to 4stud.asoiu.
Escape character is '^]'.
HTTP/1.1 400 Bad Request
Date: Wed, 03 Oct 2012 06:01:43 GMT
Server: Apache/2.2.17 (Linux/SUSE)
Content-Length: 307
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
<hr>
<address>Apache/2.2.17 (Linux/SUSE) Server at 4stud.asoiu Port 80</address>
</body></html>
Connection closed by foreign host.
rlogin
Протокол rlogin (англ. remote login — удаленный вход в систему, RFC 1282, порт сервера - 513) позволяет пользователям рабочих станций UNIX подключаться к удаленным серверам UNIX через сеть Internet и работать так же, как при прямом подключении терминала к машине. Помимо rlogin существуют еще несколько подобных протоколов: rsh (remote shell), rcp (remote copy). Утилиты rlogin, rsh и rcp часто объединяют под общим названием r-команд.
Впервые появившаяся в составе 4.2BSD UNIX, программа rlogin (и остальные r-команды) одно время была исключительно популярной в этой среде. В качестве средства терминального доступа rlogin очень похожа на telnet, но из-за тесной интеграции с ОС нашла ограниченное применение в других системах.
В rlogin отсутствуют многие опции, свойственные telnet, в частности режим согласования параметров между клиентом и сервером. Однако rlogin предусматривает хотя бы минимальные средства защиты на основе доверительных отношений между хостами: на сервере rlogin в специальных системных файлах (обычно /etc/hosts.equiv и $HOME/.rhosts) администратор может перечислить компьютеры, доступ с которых к данному серверу будет разрешен без пароля. Пользователи других компьютеров (не перечисленных в этих файлах) могут войти на сервер лишь после ввода пароля (который как и в telnet передается в открытом виде). Но, доверительные отношения между хостами тоже не панацея, и могут устанавливаться лишь в изолированных сетях. Дело в том, что такие техники несанкционированного доступа, как подмена IP-адресов (IP-spoofing) и доменных имен (DNS-spoofing), делают r-сервисы в Интернет незащищенными. Поэтому современные дистрибутивы UNIX-подобных ОС включают не фактические r-команды, а замещающие ссылки на их SSH-аналоги: scp, sftp и др.(см. man rlogin в Ubuntu, выводящий руководство по OpenSSH).
SSH (Secure Shell)
SSH (англ. Secure SHell - безопасная оболочка) — безопасный протокол дистанционного управления компьютером. Основная спецификация - RFC 4251. The Secure Shell (SSH) Protocol Architecture, входящий порт - 22. По сравнению с протоколами telnet и rlogin, ssh отличается, в первую очередь, высокой защищенностью за счет поддержки криптостойких алгоритмов шифрования и рядом дополнительных возможностей.
SSH позволяет не только использовать защищенную оболочку на удаленном хосте, но и туннелировать графический интерфейс (X11 forwarding), превращая клиентов, использующих X-Window System, в графические терминалы. SSH также способен (при надлежащем конфигурированиии) передавать через безопасный канал любой другой сетевой протокол - port forwarding. Криптографическая защита протокола SSH не фиксирована, возможен выбор различных алгоритмов шифрования.
Согласно Указу Президента Российской Федерации № 334 от 03.04.95 физическим лицам и организациям, включая государственные, частные и акционерные, запрещена эксплуатация систем криптографии, не прошедших сертификации в ФАПСИ. А SSH (а иже с ним PGP) является именно такой системой.
Не стоит думать, что нам пытаются запретить защищать конфиденциальную информацию: организации не только могут, но и обязаны защищать важную информацию. Только для этого они должны применять сертифицированные средства. Применяя свободное, но несертифицированное ПО на основе ssh, SSL, PGP и т.п. следует помнить, что его использование чревато разбирательством со стороны спецслужб.
Сервис SSH использует по умолчанию порт 22 и объединяет протоколы трех уровней:
Протокол аутентификации (The Secure Shell (SSH) Authentication Protocol, RFC 4252) — этот уровень предоставляет несколько механизмов для аутентификации пользователя: здесь может использоваться традиционная парольная аутентификация, аутентификация, основанная на публичном ключе и т.д.
Протокол транспортного уровня (The Secure Shell (SSH) Transport Layer Protocol, RFC 4253) — обеспечивает взаимодействие алгоритма и обмен ключами. Обмен ключами позволяет аутентифицировать сервер и создать криптографически защищённое соединение: обеспечивая целостность, конфиденциальность и дополнительное сжатие.
Протокол соединения (The Secure Shell (SSH) Connection Protocol, RFC 4254) — создает безопасный (шифруемый) канал, представляя его в виде нескольких логических каналов, которые используются для различных целей (различных видов служб).
Поддержка SSH реализована во всех UNIX системах и на большинстве из них в типовую поставку включено как клиентское, так и серверное ПО (см. man ssh). Для не-UNIX систем имеются как платное, так и бесплатное клиентское ПО (SecureCRT, putty). Серверное ПО - платное.
X-Window System
[актуальную информацию см. в man Xorg]
Практически все задачи управления UNIX могут выполняться в текстовом режиме, однако администраторы нередко предпочитают графический интерфейс, как более удобный. Вдобавок, некоторыми приложениями UNIX можно управлять только в графической среде. Программное обеспечение X-server, отвечающее за вывод графической информации, имеется для множества платформ, включая DOS, Windows, Macintosh, UNIX и т.д.
Следует иметь в виду, что применение X Window System предполагает наличие достаточно большой пропускной способности сети. Система прекрасно работает в локальных сетях, но очень медленно — по глобальным каналам. Поэтому при использовании X Window System на домашнем компьютере администратора управление лучше осуществлять через терминальные утилиты наподобие xterm, а не посредством графических утилит.
При подключении к серверу UNIX (на котором запускаются клиенты X11) аутентификация может осуществляться двумя методами: через терминальные утилиты (telnet, rlogin и т. п.) и через менеджер дисплеев X (X Display Manager, xdm). В первом варианте передачи пароля в открытом виде можно избежать, применяя вместо telnet и rlogin уже упоминавшиеся программы ssh и OTP. В случае X Display Manager пароли по умолчанию передаются в открытом виде. Поэтому при удаленном управлении сервером UNIX по общедоступным сетям xdm пользоваться не стоит.
Очень осторожно администраторы должны подходить к вопросу использования сервера UNIX в качестве сервера X (т. е., говоря понятным языком, к запуску графической оболочки X11 на сервере UNIX). X Window System устроена так, что пользователь может со своей машины запустить клиента X на удаленном сервере X и перехватывать на нем ввод/вывод информации. В результате злоумышленник получает возможность считывать конфиденциальную информацию с сервера X, включая пароли, вводимые пользователем на сервере X (хотя эмулятор терминала xterm позволяет блокировать перехват пароля, этой возможностью редко кто пользуется).
На серверах X применяются две схемы аутентификации клиентов: по имени хоста и с помощью «магических плюшек» (MIT-MAGIC-COOKIE-1). При аутентификации по имени хоста на сервере X создаются системные файлы, где перечисляются хосты, откуда разрешено запускать клиентские программы X на данном сервере X. Но подобную защиту никак не назовешь достаточной, так как с помощью подмены IP-адресов или доменных имен злоумышленник может провести атаку на X11. При использовании же схемы «магических плюшек» (их поддержка встроена в протокол XDMCP, на основе которого функционирует X Display Manager) аутентификация осуществляется на основании учетных записей пользователей. Чтобы иметь право запустить клиента на сервере X, пользователь в своем домашнем каталоге машины-клиента X11 должен иметь системный файл с записанным секретным кодом сервера X. Этот секретный код и называется магической плюшкой. Беда только в том, что плюшка передается по сети в открытом виде, поэтому данный метод также вряд ли можно считать безопасным.
В X Window System 11 Release 5 добавлены еще две схемы (XDM-AUTHORIZATION-1 и SUN-DES-1), напоминающие схему MIT-MAGIC-COOKIE-1, но использующие алгоритм шифрования DES. Однако из-за экспортных ограничений такие схемы в комплект поставки X Window System не включают. Исходя из вышеприведенных соображений, запускать серверное ПО X11 на сервере UNIX можно лишь в том случае, когда запрещен доступ клиентов X11 с других компьютеров.
Remote Desktop Protocol *
RDP (англ. Remote Desktop Protocol, протокол удалённого рабочего стола) — открытый протокол прикладного уровня, разработанный Microsoft и изначально предназначенный для подключения графических терминалов к Windows Terminal Server. Клиенты существуют практически для всех версий Windows (включая Windows CE и Mobile), Linux, Free BSD, Mac OS X. По-умолчанию используется порт TCP 3389. Офицальное название Майкрософт для клиентского ПО - Remote Desktop Connection или Terminal Services Client (TSC), в частности, клиент в Windows XP/2003/vista называется mstsc.exe.
RDP-клиент, - Remote Desktop - позволяет вам, находясь на одном компьютере, удаленно управлять другим. Например, если вам нужно зайти в свой компьютер, находящийся в офисе, из дома (предположим, что вы заблаговременно настроили свой рабочий компьютер), то вы можете с помощью инструмента Remote Desktop получить доступ ко всем данным, находящимся на рабочем компьютере, включая файлы, приложения и сетевые соединения. Вы даже можете слышать звук, с которым открываются файлы (спрашивается: зачем? прим. aag).
Фактически Remote Desktop позволяет не только получать доступ к файлам удаленного компьютера, но и на самом деле видеть рабочий стол таким, какой он есть на удаленном компьютере. Более того, если удаленный компьютер работает в операционной системе Windows 2000 или .NET Server, то на нем могут удаленно работать несколько пользователей одновременно.
Технология Terminal Services является основой для работы удаленного помощника , который позволяет вашему другу или работнику технической поддержки устанавливать соединение с вашим компьютером, видеть ваш рабочий стол и управлять компьютером.
Для соединения инструмент Remote Desktop использует LAN, виртуальную частную сеть (VPN) или интернет-соединение. Работа удаленного рабочего стола сильно зависит от скорости установленного соединения.
Remote Desktop поддерживает работу в двух режимах:
Remote Desktop (Удаленный рабочий стол) - подходит для использования в локальной сети и требует установки программного обеспечения на компьютере-клиенте.
Remote Desktop Web Connection (Интернет-подключение к удаленному рабочему столу) - требует на клиентской машине только наличия браузера Internet Explorer, но на сервере для нее необходимо установить и настроить большее количество программ.
Remote Desktop поддерживает 24-битные цвета - это позволяет варьировать качество картинки в широких пределах.
Переадресация ресурсов позволяет, например, использовать файловую систему удаленного компьютера в качестве сетевого ресурса общего доступа.
Переадресация звуков позволяет компьютеру-клиенту воспроизводить звуки, которые генерируются на компьютере-сервере. При проигрывании звуков Remote Desktop также учитывает пропускную способность полосы частот. Вместо того чтобы перегружать соединение звуковым сигналом при изменении пропускной способности, Remote Desktop снижает качество звука.
Remote Desktop-сервер и Remote Desktop-клиент пользуются общим буфером. Это позволяет им свободно обмениваться информацией.
Веб-технологии удаленного управления
Всемирная Паутина (World Wide Web) оказывает все большее влияние на средства управления сетевой средой. Уже сейчас многие маршрутизаторы, коммутаторы, сетевые принтеры допускают управление через web-браузеры. Но список этот далеко не исчерпывается ими и Web вторгается и в сферу управления сетевыми ОС. Вначале из Web можно было управлять лишь серверами HTTP и FTP, но этот список постоянно расширяется и охватывает теперь СУБД (например, phpMyAdmin как веб-интерфейс к СУБД MySQL), файловые системы, межсетевые экраны, сетевые службы DNS, DHCP и многое другое (пример - Webmin для управления UNIX-подобными системами). Несмотря на все увеличивающееся количество подобных решений, до полнофункциональных специализированных административных систем они не доросли. Основная проблема здесь в том, что для многих приложений и, особенно, сетевых устройств пароль по HTTP передается в открытом виде.
Централизованное управление ресурсами. Службы каталогов
Централизованное управление ресурсами сети подразумевает концентрацию данных об этих ресурсах в базе данных службы каталогов. Каталог хранит сведения о пользователях, компьютерах, принтерах, сетевых сервисах и т.п.
Что такое служба каталогов?
Служба каталогов — это сетевой сервис, представляющий централизованные средства управления ресурсами автоматизированной системы. Под ресурсами подразумеваются все компоненты сетевой инфраструктуры, которые используются для выполнения функций АСУ: пользователи, файлы и каталоги, устройства, сетевые сервисы и т.д. (рис.1).
Рис. 1. Служба каталогов
Как правило, служба каталогов состоит из базы данных, в которой размещены сведения о сетевых ресурсах и серверного ПО, представляющего механизмы доступа к этой базе. Как база данных сервиса каталогов, так и ее управляющая программа могут быть распределены на несколько серверов (рис. 2).
Рис. 2. Распределенная служба каталогов
Основными функциями службы каталогов являются следующие:
Управление пользователями и группами (создание/удаление, настройка прав доступа).
Управление ресурсами (представление в общий доступ, установка ограничений, удаленное администрирование и т.п.).
Разграничение прав доступа (как правило, на уровне пользователей, групп и отдельных ресурсов).
Среди дополнительных функций сервиса каталогов можно указать, например, такие:
поиск ресурсов;
распространение сетевых политик;
интеграция с другими сервисами.
Сетевая политика — совокупность правил, определяющих методы и средства взаимодействия с общими ресурсами в корпоративной сети.
Сетевые ресурсы в службе каталогов обычно представлены в виде иерархической структуры. Такой способ наиболее близок к реальной организационной модели подавляющего большинства предприятий и организаций. Корень иерархии описывает предприятие в целом, нижележащие уровни — подразделения и отдельные элементы. Для единообразного обращения к любому элементу иерархии протокол взаимодействия представляет унифицированную схему адресации — либо собственную, либо совместимую со стандартными схемами.
Рассмотрим основные особенности некоторых сервисов каталогов, различных по представляемым возможностям.
Популярные службы каталогов
Network Information Service (NIS/YP)
NIS (Сетевая Информационная Служба) — служба каталогов, разработанная и реализованная Sun Microsystems для систем на основе UNIX. NIS первоначально назывались Yellow Pages (YP), но из-за проблем с торговым знаком Sun изменила это название. Старое название (yp) используется в названиях утилит NIS.
NIS - это иерархическая система, в которой существует три типа хостов: основные (master) серверы,вторичные (slave) серверы и клиентские машины (рис. 3). В качестве источников данных для клиентов используются системные файлы (в терминах NIS — карты ресурсов) основного сервера NIS: passwd, hosts, group, services и прочие. В сети может быть один основной сервер NIS и ни одного или более вторичных серверов. Вторичные серверы хранят копии общих файлов основного сервера для обеспечения избыточности. Клиенты могут быть настроены как на работу с основным сервером NIS, так и со вторичными. Чтобы получить доступ к запрашиваемой информации клиент должен являться членом домена NIS.
Рис. 3. Структура Network Information Service (NIS)
Домен NIS — это совокупность доверенных ресурсов с уникальным в пределах сети именем. Имя домена NIS и способ именования ресурсов напоминает адресацию в системе доменных имен (DNS), но никакого отношения к DNS не имеет. Информация о домене хранится на основном сервере NIS и реплицируется на вторичные сервера наравне с прочими ресурсами. Один основной сервер может вести базы нескольких доменов NIS.
Общий доступ реализуется по следующей схеме: когда клиентскому приложению требуется доступ к некоему ресурсу, то локальные обращения (например, к файлу hosts) транслируются в вызовы удаленных процедур сервера NIS, с которым связан клиент. Поскольку NIS использует RPC, то NIS-серверы работают на тех портах, которые им представляет сервис RPC (т.е. у службы NIS нет выделенного номера порта, в отличие от, например, ftp-сервера или веб-сервера).
Установление связи с сервером NIS выполняется путем широковещательной рассылки запросов. Если в сети имеется несколько серверов (основной и несколько вторичных), то клиент NIS (обычно это программа ypbind) будет использовать адрес первого ответившего и направлять все свои запросы на этот сервер. Время от времени ypbind будет проверять доступность сервера. Если тот не ответит за разумное время, то клиент снова начнет процедуру опроса сети в поисках «живого» сервера.
Сервис NIS поддерживается большинством UNIX-систем общего назначения и представляет простые и удобные средства для организации централизованного управления сетью. NIS хорошо интегрируется с такими сетевыми сервисами, как например DHCP или NFS.
Среди сновных проблемы NIS выделим две:
использовании RPC, что может привести к неработоспособности клиентов при недоступности NIS-сервера;
передача карт в открытом виде, что может привести к нарушению информационной безопасности.
Из-за второго недостатка NIS не рекомендуется применять в публичных сетях. Для устранения недостатков NIS были разработаны усовершенствованные спецификации протокола (NYS и NIS+), но они не столь популярны.
Практическое задание по развертыванию NIS в локальной сети приведено в этой лабораторной работе. Исходную спецификацию NIS можно получить на сервере Sun Microsystems (теперь Oracle), в разделе документации (Network Information Service), а практические советы по планированию и развертыванию этой службы — например, на сервере Linux Documentation Project (NIS-HOWTO).
LDAP
Модель OSI определяет самые разные аспекты взаимодействия открытых систем. Имеется в ней и спецификация X.500, описывающая службу каталогов. X.500 — это серия рекомендаций разработанныхITU-T в 1993 г. и получивших статус международного стандарта (ISO/IEC 9594-1). Спецификация X.511 описывает протокол DAP для доступа к каталогам X.500. DAP, принятый в качестве международного стандарта, оказался избыточным и сложным в реализации и на его основе были разработаны адаптированные версии, среди которых NDS и LDAP.
Протокол LDAP (Lightweight Directory Access Protocol, упрощенный протокол доступа к каталогу) — бинарный клиент-серверный протокол прикладного уровня, предназначенный для доступа к распределенной службе каталогов через Интернет. Этот протокол может использоваться как в качестве шлюза к любым X.500-совместимым каталогам (рис. 4), так и в качестве основного сервиса каталогов (рис. 5). Спецификация текущей версии (LDAP v3) приведена в RFC 4510.
Рис. 4. LDAP в роли шлюза к каталогу X.500
Рис. 5. LDAP в качестве самостоятельного сервиса
В терминах X.500 каталог представляет собой «совокупность открытых систем, совместно предоставляющих службы каталогов». Проще говоря, это распределенная клиент-серверная база данных, доступ к которой возможен через унифицированные интерфейсы. Пользователь каталога, который может быть человеком или другим каким-то объектом, получает доступ к каталогу (Directory) с помощью клиентского приложения (DUA). Клиент взаимодействует с одним или более серверами через агентов системы каталогов (DSA) (рис. 4).
LDAP устанавливает порядок взаимодействия между клиентом и сервером на основе обмена сообщениями. Сообщения определяют запрашиваемые клиентом операции, ответы сервера и формат передаваемых данных. LDAP — это сессионный протокол, требующий установления, поддержания и разрыва соединения между клиентом и сервером, поэтому основным транспортом для него является TCP. Для сервиса LDAP имеется стандартный порт 389 (TCP/UDP, см. описание «хорошо известных» (well-known) портов в локальном файле /etc/services).
Основной единицей информации, хранимой в каталоге, является отдельная запись (entry). Каждая запись представляет какой-либо реальный объект: человека, компьютер, организацию и т.д. Запись описывает объект через набор присущих ему атрибутов. Атрибуты представляют собой пары вида «имя — значение». Фактическое значение атрибута зависит от его типа (рис. 6).
Рис. 6. Записи и атрибуты LDAP
Записи хранятся в иерархической структуре, называемой «Информационное дерево каталога» (Directory Information Tree, DIT). Обращение к записям осуществляется по их уникальным именам (DN, distinguished name). DN включает полный путь к записи от корня DIT и этим напоминает путь к файлу в файловой системе. Помимо DN используется и относительное уникальное имя (RDN, relative distinguished name).
Если сравнивать DN и RDN с именами файлов, то DN можно представить так:
/home/user/documents/somefile.txt
а, соответственно, RDN так:
somefile.txt
По сути же, DN есть цепочка из RDN'ов элементов структуры разного уровня.
В LDAP используется унифицированная схема именования и набор обязательных и опциональных атрибутов предопределенных типов, которые имеют короткие алиасы. Некоторые типы атрибутов записей приведены в табл. 1. Простой пример DIT с несколькими записями приведен на рис. 7.
Таблица 1. Атрибуты записей LDAP
Тип атрибута |
Краткая запись (алиас) |
Пояснение |
CommonName |
cn |
Общее имя |
StateOrProvinceName |
st |
Географическое название региона |
OrganizationName |
o |
Название организации |
OrganizationalUnitName |
ou |
Название структурного подразделения |
CountryName |
c |
Страна |
StreetAddress |
street |
Улица (как часть адреса) |
domainComponent |
dc |
Элемент домена |
userid |
uid |
Уникальный идентификатор пользователя |
Рис. 7. Пример (и не более того!) информационного дерева каталога (DIT) в LDAP
LDAP изначально ориентирован на использование в сильно распределенной среде, поэтому каталог или его части могут быть размещены на различных серверах. Клиент может обращаться к любому из серверов LDAP. Доступ к ним может осуществляться по реферальному (рис. 8) или цепочечному (рис. 9) принципам.
|
|
Рис. 8. Реферальный опрос LDAP-серверов. |
Рис. 9. Опрос «по цепочке» |
В случае реферальной обработки запросов LDAP-сервер возвращает клиенту, вместо ответа, информацию о том, на каком из серверов можно получить нужные данные. При цепочечной обработке LDAP-сервер сам опрашивает другие сервера в поисках ответа на клиентсткий запрос.
Репликация каталога LDAP может выполняться по следующим сценариям:
multi-master — все LDAP-серверы равноправны, в сети отсутствует четко определенный сервер, управляющий данными;
master-slave — главный (master) сервер управляет всеми изменениями каталога и рассылает их на подчиненные (slave) серверы. Этот сценарий может быть расширен до делегирования функций синхронизации одному из подчиненных серверов, который и будет реплицировать данные на остальные slave-серверы.
Наиболее известной (но не единственной) открытой реализацией протокола LDAP является проект Open LDAP.
Active Directory
Начиная с версии Windows 2000 Server Microsoft стала использовать собственную, LDAP-совместимую службу каталогов Active Directory. Об особенностях этой системы централизованного управления вы можете почитать здесь и здесь.
Промежуточное ПО. Назначение, функции и виды middleware.