В данном глоссарии даются краткие определения терминов, в которых могут содержаться ссылки на дополнительную информацию как с этого, так и с других сайтов.
Термин | Перевод | Пояснение |
anonymous | анонимное соединение | Сессия описывается как анонимная, если при её инициализации (посылке bind) не передаётся ни DN, ни пароля (данных для проверки подлинности). Если при посылке bind передаётся только DN и не передаётся пароль, LDAP определяет состояние, которое называется неавторизованное соединение (unauthorized). В OpenLDAP реальный эффект такого подсоединения — создание анонимной сессии. |
ASN.1 | Abstract Syntax Notation One, абстрактная нотация синтаксиса, разработанная ITU-T (стандарты серии X.208/X.680), представляет собой язык описания и кодирования правил для представления данных. ASN.1 используется для кодирования блоков данных протокола (protocol data unit (PDU), известных также как сообщения (message), блоки (block) или фреймы (frame)) с помощью разных систем кодирования, включая BER (Basic Encoding Rules X.690), CER (Canonical Encoding Rules), DER (Distinguished Encoding Rules), XER (XML Encoding Rules) и PER (Packed Encoding Rules X.691). В случае LDAP используется только простейший BER, а не ужасно сложный PER. ASN.1-описание OID. Обзор СИНТАКСИСА ASN.1. | |
Attribute | атрибут | В записи данные содержатся в парах атрибут-значение (так называемых AVA). Каждый атрибут имеет имя (а также, иногда, короткую форму имени) и принадлежит одному или нескольким объектным классам (входит в их состав). Характеристики атрибутов полностью описываются в определениях ASN.1. Один или несколько атрибутов могут быть включены в набор схемы. В зависимости от определений ASN.1 атрибута, в записи возможна одна (SINGLE-VALUE) или более одной (по умолчанию) пары атрибут-значение с одним и тем же именем атрибута. Один (или несколько) атрибутов, называемых атрибутами именования или RDN, должны всегда уникально идентифицировать запись. Атрибуты делятся на пользовательские (userApplication) и операционные (dSAOperation). |
authenticated | соединение с проверкой подлинности | Сессия описывается как соединение с проверкой подлинности, если при её инициализации (посылке примитива bind) передаётся DN пользователя и секретная последовательность. |
AUXILIARY | Вспомогательный объектный класс | В записи DIT может присутствовать (или впоследствии быть добавлено) любое количество вспомогательных объектных классов. Вспомогательный объектный класс не может использоваться для создания записи, наоборот, для этого должен использоваться один и только один структурный объектный класс. Вспомогательный объектный класс содержит один или несколько атрибутов. |
AVA | Attribute Value Assertion, утверждение значения атрибута. Пара имя_атрибута=значение_атрибута. Например, cn=joe — это AVA. | |
Base | базовая запись | базовая запись (известная также как корневая запись, суффикс) — один из многочисленных терминов, используемых для описания записи самого верхнего уровня в DIT или контексте именования. Похоже, что термин base происходит от того, что в поисковых диапазонах LDAP URL и других видов поиска обычно применяется значение base. Root DSE является своего рода супер-корневой записью. Об именовании корневой записи. |
BER | Basic Encoding Rules (основные правила кодирования) двоичный формат ITU-T (определён в X.690) для форматирования полей ASN.1 для передачи в рамках протокола. В ряде случаев, особенно в поисковых фильтрах, LDAP использует простые строки, а не двоичную кодировку (BER). | |
bind | подсоединение | При установке соединения с сервером LDAP первая операция в последовательности операций называется подсоединением (bind). Операция подсоединения посылает dn записи, которая будет использоваться для аутентификации, и пароль, который будет использоваться (обычно хранящийся в атрибуте userPassword). В случае анонимного соединения оба этих значения будут NULL. При операции bind не разрешён поиск, поэтому используемый для аутентификации DN должен совпадать с DN, с которым запись создавалась изначально. Дополнительная информация по этой теме. |
Chaining | сцепление | Если во время операции поиска LDAP-серверу встречается запись с объектным классом Referral, она может быть возвращена клиенту, запрашивающему операцию поиска, в качестве отсылки, либо сервер может быть настроен (с помощью директивы overlay chain) на разрешение отсылки (следование по отсылке) с использованием процесса, называемого сцеплением. По умолчанию OpenLDAP возвращает отсылки, но может быть сконфигурирован на выполнение сцепления с соответствующим повышением нагрузки на сервер. Дополнительная информация. |
Client | клиент | Клиент или LDAP-клиент — программа, с помощью которой производится доступ к LDAP-серверу. Большинство стандартных веб-браузеров (MSIE и Gecko) предоставляют ограниченные возможности клиента LDAP при использовании LDAP URL. LDAP-браузеры и веб-интерфейсы — типичные примеры LDAP-клиентов. Список Open Source клиентов. В некоторых случаях, например, при взаимной аутентификации, LDAP-сервер сам временно выступает в качестве LDAP-клиента. |
cn (commonName) | общепринятое имя | cn (и его псевдоним commonName) — один из самых широко используемых атрибутов. В его ASN.1-определении нет никакой полезной информации относительно его возможного применения, поэтому он широко используется как атрибут, в который помещается имя или название "чего-то там", чаще всего, объекта реального мира (имена большинства других атрибутов отражают цели их использования в каталогах DAP/LDAP, например, sn (surname) или gn (givenName)). cn — один из немногих атрибутов, которые являются частью иерархии, в данном случае вышестоящий (SUP) атрибут — name. |
Component Matching | соответствие компонентов | Соответствие компонентов (RFC 3687) предоставляет сразу и альтернативный (но более громоздкий) синтаксис поискового фильтра для простых атрибутов, и метод, с помощью которого компоненты (части или экземпляры) составных атрибутов могут быть найдены и извлечены. Дополнительная информация. |
contextCSN | Порядковый номер изменения (Change Sequence Number, CSN) контекста (наибольший entryCSN из используемых в контексте или в диапазоне синхронизационного поиска). CSN (и entryCSN, и contextCSN) широко используются в операциях репликации в стиле syncrepl OpenLDAP. contextCSN входит в SyncCookie. Назначение CSN определяется только в просроченном черновом RFC draft-chu-ldap-csn-xx.txt и, для версии 2.4, в этой статье FAQ, в состав его входит метка времени (timestamp) — включая микросекунды, счётчик operation-within-second (6 байт), 3 байта идентификатора реплики (определённого в ServerID) и 6 байт операции counte-within-modify. | |
consumer | потребитель | Так называется сервер, который использует (потребляет) сервисы, предоставляемые сервером-поставщиком. Пример потребителя — используемый в репликации Sync-клиент (RFC 4533). |
CSN | Порядковый номер изменения (Change Sequence Number, CSN) используется в OpenLDAP для идентификации изменений в конфигурациях с репликацией. Назначение CSN определяется только в просроченном черновом RFC draft-chu-ldap-csn-xx.txt и, для версии 2.4, в этой статье FAQ, в состав его входит метка времени (timestamp) — включая микросекунды, счётчик operation-within-second (6 байт), 3 байта идентификатора реплики (определённого в ServerID) и 6 байт операции counte-within-modify. | |
DAP | Directory Access Protocol, протокол доступа к каталогу. Термин X.500 для основанного на OSI сетевого протокола, который предназначен для осуществления доступа к DSA, и в котором подразумевается модель данных каталога. | |
DIT | Directory Information Tree, информационное дерево каталога (также известное как naming-context). DIT — это иерархия объектов, составляющих структуру локального каталога. Одним LDAP-сервером может поддерживаться более одного DIT. Эта информация предоставляется Root DSE. Дополнительная информация здесь. | |
DN | Distinguished Name, уникальное имя. DN состоит из серии RDN, уникально описывающих атрибуты именования по пути ВВЕРХ по DIT от требуемой записи до корневой записи каталога. DN записывается СЛЕВА НАПРАВО и выглядит примерно так:
DN: uid=bill,ou=people,dc=smokeyjoe,dc=comДополнительная информация. | |
DSA | Directory System Agent, системный агент каталога. Термин X.500, означающий любую службу каталогов, предоставляющая доступ через DAP или LDAP, например LDAP-сервер. | |
DSE | DSA Specific Entry (DSE), специфичная для DSA запись. Контрольная запись в локальном сервере каталогов. | |
entry | запись | Так называется объект, содержащийся в каталоге LDAP. У каждой записи (за исключением базовой, корневой или суффикса DIT) есть одна родительская запись и ноль или более дочерних записей (объектов). Запись должна содержать один и только один структурный объектный класс, но может содержать любое количество вспомогательных объектных классов. Записи могут быть трёх типов: записи-объекты (самый распространённый тип записи), состоящие из из пользовательских данных, содержащихся в атрибутах, входящих в состав объектных классов; записи-псевдонимы, построенные на объектном классе alias, имеющем в своём составе единственный атрибут aliasedObjectName; подзаписи, используемые для хранения административной или операционной информации, относящейся (каким-либо образом) к родительской записи данной подзаписи. Информационное содержимое записи состоит из одного или нескольких атрибутов, один (или несколько) из которых используется в качестве атрибута именования (или, правильнее, RDN) для уникальной идентификации данной записи в DIT. |
entryCSN | Порядковый номер изменения (Change Sequence Number, CSN) записи. CSN (и entryCSN, и contextCSN) широко используются в операциях репликации в стиле syncrepl OpenLDAP. Назначение CSN определяется только в просроченном черновом RFC draft-chu-ldap-csn-xx.txt и, для версии 2.4, в этой статье FAQ, в состав его входит метка времени (timestamp) — включая микросекунды, счётчик operation-within-second (6 байт), 3 байта идентификатора реплики (определённого в ServerID) и 6 байт операции counte-within-modify. | |
entryUUID | Атрибут, содержащий универсальный уникальный идентификатор (Universally Unique ID, UUID) записи в DIT. В настоящее время серверы должны создавать атрибут entryUUID при добавлении новой записи в любой DIT. UUID определён в RFC 4122, а его LDAP-реализация и синтаксис entryUUID — в RFC 4530. В этом RFC определён синтаксис entryUUID, а также правила соответствия uuidMatch и uuidOrderingMatch. | |
EQUALITY | EQUALITY определяет правило сравнения атрибута, когда тот используется в поисковом фильтре, НЕ содержащем шаблоны сравнения; то есть, и содержимое, и длина значения атрибута должны точно совпадать. Когда в поисковом фильтре используются шаблоны сравнения, это называется substring (подстрока) и применяется правило SUBSTR. Определение атрибута. | |
filter | фильтр | Поиск LDAP осуществляется путём определения базового DN, диапазона и поискового фильтра. |
LDAP | Lightweight Directory Access Protocol, облегчённый протокол доступа к службам каталогов. Термин IETF, означающий основанный на TCP/IP сетевой протокол для осуществления доступа к DSA. Отличается от спецификации X.500 DAP некоторым уменьшением функциональности. | |
LDIF | LDAP Data Interchange Format, формат обмена данными LDAP. Термин IETF, означающий текстовый формат для загрузки (импорта) и сохранения (экспорта) записей в LDAP-каталоги. LDIF определён в RFC 2849). | |
matchingRule | правило соответствия | Метод, с помощью которого в операциях поиска сравниваются атрибуты. matchingRule — определение ASN.1, содержащее OID, (обычно) имя, например caseIgnoreMatch (OID = 2.5.13.2), и тип данных, с которыми он оперирует, например DirectoryString. Дополнительная информация. |
name space | пространство имён | Термин, используемый для описания всех DN, лежащих в (или находящихся внутри, или ограниченных) заданным DIT; то есть, если корневая запись DIT — dc=example,dc=com, то говорят, что cn=people,dc=example,dc=com находится внутри этого пространства имён, а ou=people,dc=example,dc=net — нет, поскольку находится внутри пространства имён dc=example,dc=net. |
naming attribute | атрибут именования | Один из атрибутов, атрибут именования (известный также как RDN), используется для уникальной идентификации каждой записи в DIT. Сумма всех атрибутов именования (или RDN), определяющих путь к записи в DIT, называется DN. |
naming context | контекст именования | Известен также как namingContexts или DIT. Определяет уникальное пространство имён, начинающееся с корневого DN (DN суффикса) и включающее его в себя. Контексты именования, поддерживаемые LDAP-сервером, перечислены в операционном атрибуте namingContexts записи rootDSE. |
objectClass | объектный класс | Объектные классы — это коллекции атрибутов. Они определяют:
|
OID | идентификатор объекта | Object IDentifier (OID) представляет собой разделённое точками значение, например 2.5.6.2 (OID объектного класса country), которое уникально определяет объект и того, кто несет ответственность за определение этого объекта. OID, используемые в LDAP. |
Operational | операционные объекты | Операционные объекты используются сервером LDAP для предоставления информации об этом сервере, а также для управления поведением сервера. Они располагаются в Root DSE, и их можно опросить, чтобы выведать все секреты вселенной. Операционные атрибуты, такие как entryCSN, используются сервером LDAP для контроля работы каталога. Они не могут быть созданы или модифицированы конечным пользователем. Операционные атрибуты можно прочитать, указав значение + (плюс) в разделе запрашиваемых атрибутов поискового запроса. |
ORDERING | ORDERING определяет правило сравнения атрибута, когда тот используется в поисковом фильтре, содержащем операторы >= или <=. Определение атрибута. | |
Organizational Unit | подразделение организации | organizationalUnit (ou) определяет произвольное подразделение организации и может использоваться на нескольких уровнях иерархии. Его значение, как правило, соотносится с контекстом, в котором оно используется. Так, в контексте определения формата имени корневой записи ITU (формат ou,c), скорее всего, это будет название компании или организации; в контексте более низких уровней иерархии это может быть 'people', или 'manufacturing', или 'usa', или 'usa-manufacturing', или что-нибудь другое, что имеет смысл в отношении тех объектов, которые будут там располагаться. |
Ports | порты | LDAP использует протокол TCP/IP и по умолчанию подключается к порту 389 (ldap) для доступа без SSL и к порту 636 при использовании SSL (ldaps). Большинство LDAP-серверов предлагают параметры конфигурации, с помощью которых можно изменить эти предлагаемые по умолчанию номера портов. |
primary | первичное имя | Первичное имя — это первое имя из тех, которые встречаются в определении типа атрибута. При индексировании атрибута с помощью атрибута olcIndex (директивы index) в cn=config/slapd.conf ДОЛЖНО быть использовано первичное имя. Пример:
attributetype ( 2.5.4.3 NAME ( 'cn' 'commonName' ) SUP name )В этом примере cn является первичным именем этого атрибута. |
Principal DN | DN принципала | При создании (добавлении) записи в DIT, используя LDIF (или LDAP-клиент), она ассоциируется начальному DN. У этого DN 'создания' нет специального ассоциированного ему термина в стандартах. Если запись будет использоваться для аутентификации, то DN создания должен быть таким же, какие используются при подсоединениях (Bind DN). При использовании подобным образом, DN создания иногда называется DN принципала (Principal DN), особенно в контексте Microsoft AD. Дополнительная информация по этой теме. |
provider | поставщик | Так называется сервер, предоставляющий сервисы, которые потребляются (или используются) одним или несколькими другими серверами или клиентами. Пример поставщика — используемый в репликации Sync-сервер (RFC 4533). Если брать грубо, то можно утверждать примерное равенство поставщик = главный сервер, потребитель = подчинённый сервер, на объяснение же всех тонкостей разницы могут уйти часы. |
RDN | Relative Distinguished Name, относительное уникальное имя (часто также встречается неверная запись этого термина как Relatively Distinguished Name). Это имя даётся атрибуту (атрибутам), которые уникальны на данном уровне иерархии. RDN могут быть с одним значением или с несколькими значениями, в последнем случае для создания RDN два или более атрибута объединяются с помощью знака '+' (плюс), например cn+uid. Термин RDN имеет значение только в случае использования в качестве части DN для уникального описания атрибутов по пути ВВЕРХ по DIT от выбранной записи (или места начала поиска) до корневой записи каталога (или, более корректно, Root DSE). Дополнительная информация. | |
referral | отсылка | Отсылкой называется возвращаемое от LDAP-сервера LDAP-клиенту имя (обычно LDAP URL) другого LDAP-сервера, который может содержать (или не содержать) запрашиваемую информацию. О конфигурировании отсылок. LDAP-серверы могут быть настроены на автоматическое разрешение отсылок (следование по отсылкам) с использованием процесса, называемого сцеплением. |
root | корневая запись | Корневая запись (известная также как базовая запись, суффикс) — один из многочисленных терминов, используемых для описания записи самого верхнего уровня в DIT. Root DSE является своего рода супер-корневой записью. Об именовании корневой записи. |
olcRootDn/rootdn | olcRootDn/rootdn — это запутанно названные атрибут/директива настройки OpenLDAP, определяющие DN администратора для каждого DIT, который может обходить обычные правила доступа (ACL) к каталогу. DN, заданный в olcRootDn/rootdn, не обязательно должно указывать на присутствующую в каталоге запись или даже каким-либо образом быть связанно со структурой DIT, то есть это может быть DN из любого пространства имён (за исключением DIT OLC (cn=config), в котором в olcRootDn должен быть указан DN в пределах cn=config, например, cn=admin,cn=config). | |
Root DSE | Концептуально — запись самого верхнего уровня в иерархии LDAP, можно сказать super root (супер-корневая запись). Обычно невидима, то есть к ней нельзя получить доступ с помощью нормальных операций. Иногда её путают с root (корневой записью), она же base (базовая запись), она же suffix (суффикс). DSE расшифровывается как DSA Specific Entry (специфичная для DSA запись), в свою очередь DSA расшифровывается как Directory System Agent (системный агент каталога, то есть любая служба каталогов, предоставляющая доступ через DAP или LDAP). Информация по rootDSE в OpenLDAP может быть получена путём запроса объектного класса OpenLDAProotDSE или, в любом LDAP-сервере (включая OpenLDAP), путём запроса установки анонимного подсоединения с пустым базовым DN (""). Эта информация будет содержать данные о поддерживаемых версиях протокола, сервисах и контекстах именования (DIT). | |
scope | диапазон | Используется в двух значениях:
|
Schema | схема данных, набор схемы данных | Пакет определений атрибутов и объектных классов, описываемых в ASN.1, которые могут быть (номинально) связаны друг с другом. Набор (наборы) схемы данных с упакованными в них объектными классами и атрибутами, которые будут использоваться (на которые будут ссылаться) LDAP-приложения (DIT), должны быть переданы LDAP-серверу и определяться им, поэтому он должен уметь читать и разбирать все эти милые ASN.1-вещицы. В OpenLDAP наборы схемы определяются в ветке cn=schema,cn=config (OLC) или с помощью директивы include файла slapd.conf. |
search | поиск | Поиск LDAP осуществляется путём определения базового DN, диапазона и поискового фильтра. |
session | сессия | Сессия возникает между LDAP-клиентом и сервером когда клиент посылает команду bind. Сессия может быть либо анонимной, либо с проверкой подлинности. |
slapd | slapd — это имя демона (службы), обеспечивающей выполнение сервиса OpenLDAP. slapd предоставляет локальную службу LDAP и настраивается либо с помощью OLC (cn=config), либо с помощью файла slapd.conf. | |
slapd.conf | slapd.conf — статический конфигурационный файл, используемый slapd и, если настроено, slurpd. В OpenLDAP версии 2.3+ представлена альтернативная возможность конфигурации времени исполнения slapd.d (cn=config) или OLC. | |
slurpd | В OpenLDAP до версии 2.4 slurpd был демоном, предоставляющим сервис репликации LDAP. Он настраивался с помощью файлов slapd.conf и ldap.conf. Дополнительная информация по репликации. Репликация в стиле slurpd устарела и в OpenLDAP версии 2.4+ была заменена на репликацию в стиле syncrepl. | |
STRUCTURAL | Структурный объектный класс | Объектные классы могут быть структурными (STRUCTURAL) или вспомогательными (AUXILIARY). Для создания записи должен быть использован один и только один структурный объектный класс. Структурный объектный класс содержит один или несколько атрибутов. |
subentry | подзапись | Подзаписи используются для предоставления операционной или административной информации. Они определены в RFC 3672 (и упоминаются в RFC 4512 и RFC 4533). Пример подзаписи — cn=subschema, которая располагается в атрибуте subschemaSubentry записи rootDSE, и содержит коллекцию типов атрибутов, правил соответствия, объектных классов и синтаксисов LDAP, поддерживаемых LDAP-сервером. Подробнее о подзаписях. |
subordinate | нижестоящий | В документации OpenLDAP термин нижестоящая база данных (DIT) используется для определения DIT, на которую происходит отсылка в объекте referral. Поскольку с помощью объектов referral DIT, на который происходит отсылка, делегируется осуществление поиска остальной части DN, такие DIT могут быть представлены в виде иерархии, и DIT, на которую происходит отсылка, будет нижестоящей в такой иерархии. К сожалению, в OpenLDAP используется также термин вышестоящий, определение которого является гораздо более сомнительным. Конфигурация и использование отсылок. |
subSchema | подсхема | subSchema представляет собой подзапись записи rootDSE LDAP-серверов, совместимых с LDAP версии 3. Она определяется с использованием базовой DN cn=subschema (как правило, хотя фактическое имя подзаписи можно определить путём опроса атрибута subschemaSubentry записи rootDSE) и содержит коллекцию объектных классов, синтаксисов LDAP, правил соответствия и типов атрибутов, поддерживаемых данным LDAP-сервером. |
SUBSTR | SUBSTR определяет правило сравнения атрибута, когда тот используется в поисковом фильтре, содержащем один или несколько шаблонов сравнения. Когда в поисковом выражении (фильтре) нет шаблонов сравнения, применяется правило EQUALITY. Определение атрибута. | |
substring | подстрока | Подстроками являются любые строковые значения, используемые в поисковых фильтрах и содержащие шаблоны сравнения. Форма сравнения, например, с учётом или без учёта регистра символов, задаётся правилом SUBSTR в определении атрибута. |
subtype | подтип | В LDAPv3 есть возможность определять подтипы. В настоящий момент уже определено два: binary (в RFC 2251) и lang (в RFC 2596). Подтипы могут использоваться, когда указывается атрибут и квалификация поиска, например cn;lang-en-us=smith требует выполнения поиска с использованием американского английского (US english). Этот подтип не влияет на кодировку, поскольку UTF-8 (применяемый для cn) позволяет использовать все языковые типы. Подтипы lang не чувствительны к регистру символов. |
suffix | суффикс | Суффикс (известный также как корневая запись, базовая запись) — один из многочисленных терминов, используемых для описания записи самого верхнего уровня в DIT. Обычно этот термин используется, поскольку данная запись указывается в атрибуте olcSuffix (директиве suffix). Root DSE является своего рода супер-суффиксом. Об именовании корневой записи. |
superior | вышестоящий | В документации OpenLDAP термин вышестоящая база данных (DIT) используется для определения DIT, от которой в объекте referral происходит отсылка на другое DIT. Поскольку с помощью объектов referral DIT, на который происходит отсылка, делегируется осуществление поиска остальной части DN, такие DIT могут быть представлены в виде иерархии, и DIT, содержащий объект referral, будет вышестоящим по отношению к DIT, на который происходит отсылка. DIT, являющийся назначением отсылки, называется нижестоящим. Конфигурация и использование отсылок. Также термин "вышестоящий" (SUP) используется в контексте иерархии атрибутов и объектных классов. |
supportedExtension | поддерживаемые расширения | Спецификации LDAP (RFC) допускают дополнительные возможности и расширения. Если LDAP-сервер поддерживает какое-то конкретное расширение, его OID будет опубликован в rootDSE. В RFC3674 определён атрибут supportedFeatures записи rootDSE, в котором и содержится список поддерживаемых возможностей и расширений. |
SyncCookie | Куки, посылаемое поставщиком потребителю во время репликации в стиле sysncrepl. Подробное описание и настройка репликации. | |
syncrepl | Метод репликации, основанный на протоколе синхронизации содержимого LDAP (LDAP Content Synchronization protocol, RFC 4533) и реализованный в OpenLDAP версии 2.2. Начиная с OpenLDAP версии 2.4, все остальные методы репликации являются устаревшими. Название термина происходит от атрибута/директивы конфигурации olcSyncrepl/syncrepl. Дополнительныя информация по репликации. | |
types | типы данных | Термин типы (они же типы данных) обычно используется для указания на ASN.1 СИНТАКСИС атрибута. Типы данных LDAP. |
unauthorized | неавторизованное соединение | Сессия описывается как неавторизованная, если при её инициализации (посылке bind) передаётся DN без пароля (данных для проверки подлинности). В OpenLDAP реальный эффект такого подсоединения — создание анонимной сессии (это должно быть явно разрешено с помощью olcAllow/allow bind_anon_dn). |
Проблемы, комментарии, предположения, исправления (включая битые ссылки) или есть что добавить? Пожалуйста, выкроите время в потоке занятой жизни, чтобы написать нам, вебмастеру или в службу поддержки. Оставшийся день Вы проведёте с чувством удовлетворения.
Нашли ошибку в переводе? Сообщите переводчикам!
Copyright © 1994-2019 ZyTrax, Inc. Все права защищены. Последнее изменение страницы: 4 апреля 2018 г.
Переведено участниками проекта Pro-LDAP.ru в 2011-2019 г.