Network Working Group Request for Comments: 2307 L. Howard, независимый консультант Категория: Experimental Март 1998 года
В этом документе определяется экспериментальный протокол Интернет для сообщества Интернет. Он не определяет какого-либо рода стандарт Интернет. Принимаются обсуждения и предложения по улучшению этого документа. Ограничений на распространение этого документа не накладывается.
Copyright (C) Internet Society (1998). Все права защищены.
В этом документе описан экспериментальный механизм для отображения объектов, связанных с TCP/IP и системами UNIX, в записи X.500 [X500] так, чтобы с ними можно было работать посредством протокола Lightweight Directory Access Protocol [RFC2251]. Предлагается набор типов атрибутов и объектных классов, а также указания по их интерпретации.
Идея этой работы состоит в оказании помощи при развертывании системы LDAP в качестве службы имен организации. Предлагаемый подход не предназначен для использования в качестве стандарта Интернет. Скорее, мы надеемся на появление общего консенсуса, который может стать приемлемым решением подобного рода проблем и в конечном итоге привести к принятию стандарта. Уже есть успешный опыт реализации предлагаемого механизма.
В операционной системе UNIX (R) и её производных (в частности, тех, которые поддерживают TCP/IP и соответствуют спецификации X/Open Single UNIX [XOPEN]) требуется наличие средства просмотра объектов путём сопоставления их с критериями поиска или путём перечисления. (Другие операционные системы, поддерживающие TCP/IP, могут предоставлять некоторые средства разрешения некоторых из этих объектов. Данная схема также применима к подобным средам.)
Упомянутые объекты включают в себя пользователей, группы, IP-службы (которые отображают имена в IP-порты и протоколы, и обратно), IP-протоколы (которые отображают имена в номера IP-протоколов и обратно), RPC (которые отображают имена в номера ONC Remote Procedure Call [RFC1057] и обратно), сетевые группы NIS, информацию по загрузке (параметры загрузки и отображение MAC-адресов), монтирование файловых систем, IP-хосты и сети, а также почтовые псевдонимы RFC822.
Запросы на преобразование выполняются посредством набора C-функций, предоставляемых в системной библиотеке UNIX. Например, системная утилита UNIX "ls", перечисляющая содержимое директории файловой системы, использует библиотечную функцию C getpwuid() для отображения идентификаторов пользователей в регистрационные имена (логины). После того, как запрос был сделан, он будет разрешен с использованием "службы имен", которая поддерживается клиентской библиотекой. В простейшем случае в качестве такой службы имён может выступать набор файлов в локальной файловой системе. Библиотека C открывает эти файлы и выполняется поиск по их содержимому. Другие распространённые службы имён — Network Information Service (NIS) и Domain Name System (DNS). (Последняя обычно используется для разрешения имён хостов, сервисов и сетей.) Преимущество обеих этих служб имён — то, что они имеют распределённую структуру, таким образом позволяя иметь на многих клиентах общий набор объектов.
LDAP — это протокол доступа к распределённой иерархической службе каталогов, который используется для доступа к репозиториям сведений о пользователях и других связанных с сетью объектах. Поскольку LDAP часто не имеет тесной интеграции с операционной системой хоста, может потребоваться хранение сведений, например, о пользователях, как в LDAP, так и в поддерживаемой операционной системой службе имён, например, NIS. При использовании LDAP в качестве первичного средства разрешения таких объектов можно минимизировать указанную избыточность, а также воспользоваться преимуществами масштабируемости LDAP. (Для сравнения, базирующаяся на обычных файлах служба NIS не обладает масштабируемостью и расширяемостью LDAP или X.500.)
Определяемые ниже объектные классы и атрибуты предназначены для представления вышеуказанных объектов в форме, совместимой со службами каталогов LDAP и X.500.
Ключевые слова "MUST" (необходимо), "SHOULD" (следует) и "MAY" (возможно) в данном документе должны интерпретироваться так, как описано в [RFC2119].
В рамках этого документа термин "служба имён" ("nameservice") указывает на сервис (такой как NIS или обычные файлы), используемый операционной системой для разрешения объектов в пределах одного локального контекста именования. Сравните со "службой каталогов" ("directory service"), такой как LDAP, поддерживающей расширяемую схему данных и несколько контекстов именования.
Термин "связанные с NIS объекты" ("NIS-related entities") в широком смысле относится к объектам, которые обычно разрешаются с помощью Network Information Service. (NIS раньше называлась YP.) Развертывание LDAP для разрешения этих объектов не подразумевает, что будет использоваться NIS, ни в качестве шлюза, ни каким-либо другим способом. В частности, классы для хоста и сети подходят для задач общего назначения, и их можно применить в системах, где LDAP или X.500 используются для разрешения хостов и сетей.
Термин "DUA", — пользовательский агент каталога (directory user agent), — указывает на клиент LDAP, запрашивающий эти объекты, такой как шлюз LDAP-NIS или библиотека C. Термин "клиент" ("client") указывает на приложение, которое в конечном итоге позволяет использовать информацию, возвращаемую в результате разрешения. Не имеет значения, находятся ли DUA и клиент в одном адресном пространстве. Действие DUA по доведению этой информации до клиента называется "перепубликацией" ("republishing").
Во избежание путаницы, термин "логин" ("login name") указывает на регистрационное имя пользователя (является значением атрибута uid), а термин "идентификатор пользователя" ("user ID") указывает на целочисленный идентификационный номер пользователя (является значением атрибута uidNumber).
Фразы "разрешение объекта" ("resolving an entity") и "разрешение объектов" ("resolution of entities") указывают, соответственно, на перечисление связанных с NIS объектов заданного типа, и на сравнение их с заданными критериями поиска. В результате успешного "разрешения" ("resolution") возвращаются один или несколько объектов (в результате "совпадения" ("match") возвращается только один объект).
Использование термина UNIX не говорит о том, что этот набор схемы данных одобрен владельцами торговой марки UNIX. Там, где это необходимо, термин "объект TCP/IP" ("TCP/IP entity") используется для указания на протоколы, службы, хосты и сети, а термин "объект UNIX" ("UNIX entity") на все остальные объекты. (Первая категория не требует от операционной системы хоста поддержки интерфейсов, необходимых для разрешения объектов UNIX.)
Определяемые ниже OID наследуются от iso(1) org(3) dod(6) internet(1) directory(1) nisSchema(1).
Ниже кратко изложены атрибуты и классы, определённые в данном документе.
В данном документе определены следующие атрибуты:
uidNumber
gidNumber
gecos
homeDirectory
loginShell
shadowLastChange
shadowMin
shadowMax
shadowWarning
shadowInactive
shadowExpire
shadowFlag
memberUid
memberNisNetgroup
nisNetgroupTriple
ipServicePort
ipServiceProtocol
ipProtocolNumber
oncRpcNumber
ipHostNumber
ipNetworkNumber
ipNetmaskNumber
macAddress
bootParameter
bootFile
nisMapName
nisMapEntry
Кроме того, требуются некоторые атрибуты, определённые в [RFC2256].
В данном документе определены следующие объектные классы:
posixAccount
shadowAccount
posixGroup
ipService
ipProtocol
oncRpc
ipHost
ipNetwork
nisNetgroup
nisMap
nisObject
ieee802Device
bootableDevice
Кроме того, требуются некоторые классы, определённые в [RFC2256].
Ниже представлены определения синтаксисов [RFC2252], используемые в этом наборе схемы. nisNetgroupTripleSyntax отражает триплеты сетевых групп NIS:
( nisSchema.0.0 NAME 'nisNetgroupTripleSyntax'
DESC 'триплет сетевой группы NIS' )
Значения в этом синтаксисе:
nisnetgrouptriple = "(" hostname "," username "," domainname ")"
hostname = "" / "-" / keystring
username = "" / "-" / keystring
domainname = "" / "-" / keystring
Серверы X.500 могут использовать следующее представление этого синтаксиса:
nisNetgroupTripleSyntax ::= SEQUENCE {
hostname [0] IA5String OPTIONAL,
username [1] IA5String OPTIONAL,
domainname [2] IA5String OPTIONAL
}
Синтаксис bootParameterSyntax отражает параметры загрузки:
( nisSchema.0.1 NAME 'bootParameterSyntax'
DESC 'Параметр загрузки' )
в нем:
bootparameter = key "=" server ":" path
key = keystring
server = keystring
path = keystring
Серверы X.500 могут использовать следующее представление этого синтаксиса:
bootParameterSyntax ::= SEQUENCE {
key IA5String,
server IA5String,
path IA5String
}
Значения, соблюдающие эти синтаксисы, кодируются LDAP-серверами как строки.
В этом разделе содержатся определения атрибутов, которые должны быть реализованы DUA, поддерживающими этот набор схемы данных.
( nisSchema.1.0 NAME 'uidNumber'
DESC 'Целое число, уникально идентифицирующее пользователя
в административном домене'
EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE )
( nisSchema.1.1 NAME 'gidNumber'
DESC 'Целое число, уникально идентифицирующее группу
в административном домене'
EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE )
( nisSchema.1.2 NAME 'gecos'
DESC 'Поле GECOS; общепринятое имя'
EQUALITY caseIgnoreIA5Match
SUBSTRINGS caseIgnoreIA5SubstringsMatch
SYNTAX 'IA5String' SINGLE-VALUE )
( nisSchema.1.3 NAME 'homeDirectory'
DESC 'Абсолютный путь к домашней директории'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String' SINGLE-VALUE )
( nisSchema.1.4 NAME 'loginShell'
DESC 'Путь к командной оболочке, назначаемой при входе в систему'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String' SINGLE-VALUE )
( nisSchema.1.5 NAME 'shadowLastChange'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
( nisSchema.1.6 NAME 'shadowMin'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
( nisSchema.1.7 NAME 'shadowMax'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
( nisSchema.1.8 NAME 'shadowWarning'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
( nisSchema.1.9 NAME 'shadowInactive'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
( nisSchema.1.10 NAME 'shadowExpire'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
( nisSchema.1.11 NAME 'shadowFlag'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
( nisSchema.1.12 NAME 'memberUid'
EQUALITY caseExactIA5Match
SUBSTRINGS caseExactIA5SubstringsMatch
SYNTAX 'IA5String' )
( nisSchema.1.13 NAME 'memberNisNetgroup'
EQUALITY caseExactIA5Match
SUBSTRINGS caseExactIA5SubstringsMatch
SYNTAX 'IA5String' )
( nisSchema.1.14 NAME 'nisNetgroupTriple'
DESC 'Триплет сетевой группы'
SYNTAX 'nisNetgroupTripleSyntax' )
( nisSchema.1.15 NAME 'ipServicePort'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
( nisSchema.1.16 NAME 'ipServiceProtocol'
SUP name )
( nisSchema.1.17 NAME 'ipProtocolNumber'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
( nisSchema.1.18 NAME 'oncRpcNumber'
EQUALITY integerMatch
SYNTAX 'INTEGER' SINGLE-VALUE )
( nisSchema.1.19 NAME 'ipHostNumber'
DESC 'IP-адрес в точечно-цифровой нотации, например, 192.168.1.1,
без начальных нулей'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}' )
( nisSchema.1.20 NAME 'ipNetworkNumber'
DESC 'IP-сеть в точечно-цифровой нотации, например, 192.168,
без начальных нулей'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}' SINGLE-VALUE )
( nisSchema.1.21 NAME 'ipNetmaskNumber'
DESC 'IP-маска в точечно-цифровой нотации, например, 255.255.255.0,
без начальных нулей'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}' SINGLE-VALUE )
( nisSchema.1.22 NAME 'macAddress'
DESC 'MAC-адрес в максимальной нотации, шестнадцатеричные цифры,
разделённые двоеточиями, например, 00:00:92:90:ee:e2'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}' )
( nisSchema.1.23 NAME 'bootParameter'
DESC 'Параметр rpc.bootparamd'
SYNTAX 'bootParameterSyntax' )
( nisSchema.1.24 NAME 'bootFile'
DESC 'Имя загрузочного образа'
EQUALITY caseExactIA5Match
SYNTAX 'IA5String' )
( nisSchema.1.26 NAME 'nisMapName'
SUP name )
( nisSchema.1.27 NAME 'nisMapEntry'
EQUALITY caseExactIA5Match
SUBSTRINGS caseExactIA5SubstringsMatch
SYNTAX 'IA5String{1024}' SINGLE-VALUE )
В этом разделе содержатся определения классов, которые должны быть реализованы DUA, поддерживающими этот набор схемы данных.
Объектный класс rfc822MailGroup может (MAY) быть использован для представления почтовой группы в целях раскрытия псевдонимов. Существует несколько альтернативных наборов схемы данных для маршрутизации и доставки почты с использованием каталогов LDAP, рассмотрение которых выходит за рамки этого документа.
( nisSchema.2.0 NAME 'posixAccount' SUP top AUXILIARY
DESC 'Абстракция учётной записи с POSIX-атрибутами'
MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
MAY ( userPassword $ loginShell $ gecos $ description ) )
( nisSchema.2.1 NAME 'shadowAccount' SUP top AUXILIARY
DESC 'Дополнительные атрибуты для теневых паролей'
MUST uid
MAY ( userPassword $ shadowLastChange $ shadowMin
shadowMax $ shadowWarning $ shadowInactive $
shadowExpire $ shadowFlag $ description ) )
( nisSchema.2.2 NAME 'posixGroup' SUP top STRUCTURAL
DESC 'Абстракция группы учётных записей'
MUST ( cn $ gidNumber )
MAY ( userPassword $ memberUid $ description ) )
( nisSchema.2.3 NAME 'ipService' SUP top STRUCTURAL
DESC 'Абстракция службы Internet Protocol.
Отображает IP-порт и протокол (такой как tcp или udp)
в одно или более имён; в отличительном значении
атрибута cn указывается каноническое имя
сервиса'
MUST ( cn $ ipServicePort $ ipServiceProtocol )
MAY ( description ) )
( nisSchema.2.4 NAME 'ipProtocol' SUP top STRUCTURAL
DESC 'Абстракция протокола IP. Отображает номер протокола
в одно или более имён. В отличительном значении
атрибута cn указывается каноническое имя протокола'
MUST ( cn $ ipProtocolNumber $ description )
MAY description )
( nisSchema.2.5 NAME 'oncRpc' SUP top STRUCTURAL
DESC 'Абстракция привязки Open Network Computing (ONC)
[RFC1057] Remote Procedure Call (RPC).
Этот класс отображает номер ONC RPC в имя.
В отличительном значении атрибута cn указывается
каноническое имя сервиса RPC'
MUST ( cn $ oncRpcNumber $ description )
MAY description )
( nisSchema.2.6 NAME 'ipHost' SUP top AUXILIARY
DESC 'Абстракция хоста, IP-устройства. В отличительном значении
атрибута cn указывается каноническое имя хоста. В качестве
структурного класса следует (SHOULD) использовать device'
MUST ( cn $ ipHostNumber )
MAY ( l $ description $ manager ) )
( nisSchema.2.7 NAME 'ipNetwork' SUP top STRUCTURAL
DESC 'Абстракция сети. В отличительном значении
атрибута cn указывается каноническое имя сети'
MUST ( cn $ ipNetworkNumber )
MAY ( ipNetmaskNumber $ l $ description $ manager ) )
( nisSchema.2.8 NAME 'nisNetgroup' SUP top STRUCTURAL
DESC 'Абстракция сетевой группы. Может ссылаться на другие сетевые группы'
MUST cn
MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) )
( nisSchema.2.09 NAME 'nisMap' SUP top STRUCTURAL
DESC 'Общая абстракция карты NIS'
MUST nisMapName
MAY description )
( nisSchema.2.10 NAME 'nisObject' SUP top STRUCTURAL
DESC 'Объект в карте NIS'
MUST ( cn $ nisMapEntry $ nisMapName )
MAY description )
( nisSchema.2.11 NAME 'ieee802Device' SUP top AUXILIARY
DESC 'Устройство с MAC-адресом; В качестве структурного
класса следует (SHOULD) использовать device'
MAY macAddress )
( nisSchema.2.12 NAME 'bootableDevice' SUP top AUXILIARY
DESC 'Устройство с параметрами загрузки; В качестве структурного
класса следует (SHOULD) использовать device'
MAY ( bootFile $ bootParameter ) )
Предпочтительным средством перенацеливания клиентских приложений (использующих общие сервисы библиотеки C) на использование LDAP в качестве источника информации для перечисленных в разделе 5.2 функций является модификация их исходного кода на выполнение прямых запросов LDAP. Поскольку исходные коды коммерческих библиотек C и приложений редко доступны конечному пользователю, есть вариант сэмулировать поведение поддерживаемой службы имён (такой как NIS). (Это позволяет также выполнять кэширование объектов через пространства адресов.) В случае NIS, общедоступны примеры реализации и описание интерфейса RPC.
Средства, с помощью которых операционная система перенацеливается на использование LDAP, зависят от реализации. Например, некоторые операционные системы и библиотеки C поддерживают резольверы с возможностью расширения конечным пользователем посредством использования динамически подгружаемых библиотек и "переключателей" служб имён. Способы указания DUA местонахождения серверов LDAP также зависят от реализации.
Приведённые ниже функции обычно можно найти в библиотеках C большинства UNIX и POSIX-совместимых систем. Рядом с именем функции указан поисковый фильтр LDAP [RFC2254], который можно использовать для нахождения данных при вызове функции. Параметры обозначены шаблонами %s и %d для строковых и целочисленных аргументов, соответственно. Длинные строки разбиты на несколько.
getpwnam() (&(objectClass=posixAccount)(uid=%s))
getpwuid() (&(objectClass=posixAccount)
(uidNumber=%d))
getpwent() (objectClass=posixAccount)
getspnam() (&(objectClass=shadowAccount)(uid=%s))
getspent() (objectClass=shadowAccount)
getgrnam() (&(objectClass=posixGroup)(cn=%s))
getgrgid() (&(objectClass=posixGroup)
(gidNumber=%d))
getgrent() (objectClass=posixGroup)
getservbyname() (&(objectClass=ipService)
(cn=%s)(ipServiceProtocol=%s))
getservbyport() (&(objectClass=ipService)
(ipServicePort=%d)
(ipServiceProtocol=%s))
getservent() (objectClass=ipService)
getrpcbyname() (&(objectClass=oncRpc)(cn=%s))
getrpcbynumber() (&(objectClass=oncRpc)(oncRpcNumber=%d))
getrpcent() (objectClass=oncRpc)
getprotobyname() (&(objectClass=ipProtocol)(cn=%s))
getprotobynumber() (&(objectClass=ipProtocol)
(ipProtocolNumber=%d))
getprotoent() (objectClass=ipProtocol)
gethostbyname() (&(objectClass=ipHost)(cn=%s))
gethostbyaddr() (&(objectClass=ipHost)(ipHostNumber=%s))
gethostent() (objectClass=ipHost)
getnetbyname() (&(objectClass=ipNetwork)(cn=%s))
getnetbyaddr() (&(objectClass=ipNetwork)
(ipNetworkNumber=%s))
getnetent() (objectClass=ipNetwork)
setnetgrent() (&(objectClass=nisNetgroup)(cn=%s))
Разрешение пользователей и групп инициируется функциями с префиксами getpw и getgr, соответственно. В атрибуте uid содержится логин пользователя. В записях с объектным классом posixGroup в атрибуте cn содержится имя группы.
Удобным структурным классом для posixAccount является объектный класс account. Его следует (SHOULD) использовать, если не требуется дополнительных атрибутов.
Предполагается, что типы атрибутов uid и cn используются для формирования RDN в записях с объектными классами posixAccount и posixGroup, соответственно.
Поле GECOS учётной записи в первую очередь определяется значением атрибута gecos. Если атрибут gecos отсутствует, должно (MUST) быть использовано значение атрибута cn. (Наличие атрибута gecos позволяет возвращать клиенту информацию, включаемую в поле GECOS, такую, как номер телефона пользователя, без изменения смысла значения атрибута cn. Этот атрибут также полезен в каталогах, где в поле "общепринятое имя" ("common name") содержатся данные, отличные от полного имени пользователя.)
Записи классов posixAccount, posixGroup или shadowAccount без атрибута userPassword не должны (MUST NOT) использоваться для аутентификации. Клиенту следует возвращать пароль, по которому нельзя найти соответствия, такой как "x".
Значения атрибута userPassword должны (MUST) быть представлены следующим синтаксисом:
passwordvalue = schemeprefix encryptedpassword
schemeprefix = "{" scheme "}"
scheme = "crypt" / "md5" / "sha" / altscheme
altscheme = "x-" keystring
encryptedpassword = encrypted password
Строка encrypted password содержит ключ, захэшированный с использованием алгоритма scheme.
Значения атрибута userPassword, которые не придерживаются данного синтаксиса, не должны (MUST NOT) быть использованы для аутентификация. DUA должен (MUST) последовательно перебирать значения этого атрибута, пока не будет найдено значение, соответствующее указанному синтаксису. Считается, что у пользователя нет пароля, только если поле encryptedpassword представляет собой пустую строку. От DUA не требуется рассматривать схемы шифрования, которые клиент не сможет распознать; в большинстве случаев может быть достаточно рассмотреть только схему "crypt".
Пример атрибута userPassword:
userPassword: {crypt}X5/DBrWPOQQaI
Будущий стандарт может определять LDAPv3-описание атрибута для представления хэшированных пользовательских паролей так, как приведено ниже. Данная схема не должна (MUST NOT) использоваться с LDAPv2 DUA и DSA.
attributetype = attributename sep attributeoption
attributename = "userPassword"
sep = ";"
attributeoption = schemeclass "-" scheme
schemeclass = "hash" / altschemeclass
scheme = "crypt" / "md5" / "sha" / altscheme
altschemeclass = "x-" keystring
altscheme = keystring
Пример атрибута userPassword, представленного с использованием LDAPv3-описания атрибута:
userPassword;hash-crypt: X5/DBrWPOQQaI
DUA может (MAY) использовать эти атрибуты в классе shadowAccount для предоставления сервиса теневых паролей (getspnam() и getspent()). В этом случае DUA не должен (MUST NOT) использовать атрибут userPassword в getpwnam() и подобных вызовах, и вместо этого должен (MUST) возвращать клиенту пароль, по которому нельзя найти соответствия (такой как "x").
Атрибуты ipHostNumber и ipNetworkNumber предназначены для использования вместо атрибута dNSRecord (определённого в RFC1279) с целью упрощения задачи DUA по интерпретации записей в каталоге. Значение атрибута dNSRecord выражает полное представление ресурса, в том числе данные о классе и времени жизни, что является избыточным для данной схемы.
Кроме того, классы ipHost и ipNetwork позволяют представить хост и сеть (соответственно) и все их псевдонимы одной записью в каталоге. Это не всегда возможно, если запись ресурса DNS напрямую отображается в запись LDAP. Реализации, в которых планируется использовать LDAP для управления информацией по зонам DNS, не лишены такой возможности, в них можно просто не использовать классы ipHost и ipNetwork.
В этом документе переопределяется (без претензий на исключительность) определённый в RFC1279 класс ipNetwork, с целью достижения согласованного именования с классом ipHost. Атрибут ipNetworkNumber также используется в объектном классе siteContact [ROSE].
Конечные нули в адресе сети должны (MUST) быть опущены. Можно использовать CIDR-стиль сетевых адресов (например, 192.168.1/24).
IPv6-адреса хостов должны (MUST) быть записаны в их "предпочтительной" форме (как определено в разделе 2.2.1 RFC1884), где указываются все компоненты адреса и опускаются начальные нули каждого компонента. Такая форма записи обеспечивает согласованные средства разрешения ip-хостов по адресу.
В общем случае, предлагается осуществлять однозначное отображение между объектами и записями LDAP, поэтому у каждого объекта должно быть ровно одно представление в DIT. В некоторых случаях это невозможно; например, служба, которая представлена более чем в одной разновидности протокола. Рассмотрим следующую запись:
dn: cn=domain, dc=aja, dc=com
cn: domain
cn: nameserver
objectClass: top
objectClass: ipService
ipServicePort: 53
ipServiceProtocol: tcp
ipServiceProtocol: udp
Эта запись должна (MUST) отображаться в следующие два объекта служб:
domain 53/tcp nameserver
domain 53/udp nameserver
Хотя эти два объекта могут быть представлены двумя отдельными записями LDAP с разными уникальными именами (например, cn=domain+ipServiceProtocol=tcp, ... и cn=domain+ipServiceProtocol=udp, ...), удобнее представлять их в виде одной записи. (Если служба представлена разновидностями протокола с разными портами, то требуется наличие нескольких записей; для формирования их уникальных имён могут быть использованы многозначные RDN.)
За исключением значений атрибута userPassword, которые обрабатываются в соответствии с синтаксисом, рассмотренным в разделе 5.2, любые пустые значения (состоящие из строки нулевой длины) возвращаются DUA клиенту. DUA должен (MUST) отклонять любые записи, не удовлетворяющие схеме данных (отсутствие обязательных атрибутов). При перечислении записей следует (SHOULD) игнорировать те из них, которые не удовлетворяют схеме данных.
Объектный класс nisObject может (MAY) быть использован как общее средство представления объектов NIS. Его использование не рекомендуется; если есть потребность в объектах, не описанных в этом наборе схемы данных, следует разработать соответствующий набор. Разработчикам LDAP-систем настоятельно рекомендуется поддерживать отображения между объектами NIS и объектными классами с возможностью расширения их конечным пользователем. (При использовании класса nisObject для формирования RDN записи может быть использован атрибут nisMapName.)
Для таких объектов как хосты, службы, сети, протоколы и RPC, у которых могут быть один или несколько псевдонимов, для определения канонического имени следует (SHOULD) использовать относительное уникальное имя (RDN) соответствующей записи. Любые другие значения того же атрибута, что формирует RDN, используются в качестве псевдонимов. Например, каноническое имя службы, описанной в разделе 5.5, — "domain", а её единственный псевдоним — "nameserver".
В наборе схемы из этого документа, как правило, определяется только один атрибут для каждого класса, который подходит для формирования отличительного имёни объекта (из претендентов на формирование отличительного имени исключаются любые атрибуты с целочисленным синтаксисом; предполагается, что записи будут отличаться по символьным именам объектов). Обычно используется атрибут common name (cn). Это помогает DUA в определении канонического имени объекта, так как он может проанализировать значение относительного уникального имени. Тогда псевдонимами считаются любые значения атрибута, используемого для формирования относительного уникального имени (например, cn), которые не совпадают с каноническим именем объекта.
Если для формирования относительного уникального имени записи используется атрибут, не входящий в рассматриваемый набор схемы данных (такое может случиться при использовании вспомогательных объектных классов из данного набора), каноническое имя объекта может не присутствовать в RDN. В этом случае для представления канонического имени объекта DUA должен (MUST) выбрать одно из неотличительных значений атрибутов. Поскольку сервер каталогов не гарантирует соблюдения определённого порядка при выборке значений атрибутов, есть вероятность, что однозначно установить отличительное имя объекта не получится. Такая неоднозначность не должна (SHOULD NOT) разрешаться путём отображения одной записи каталога в несколько объектов.
Был разработан сервер NIS, который использует LDAP вместо локальных файлов и поддерживает набор схемы данных, определённый в этом документе.
Для Free Software Foundation была написана эталонная реализация библиотеки C с кодом разрешения. Могут применяться и другие библиотеки C, поддерживающие технологии Name Service Switch (NSS) или Information Retrieval Service (IRS).
Автор документа выпустил в свободный доступ набор скриптов для представления сведений из локальных баз данных, таких как /etc/passwd и /etc/hosts, в форме, подходящей для загрузки в каталог LDAP.
Практически все приведённые соображения безопасности не относятся напрямую к области этого документа. Общеизвестно, что предоставлять доступ непривилегированным пользователям к паролям, захэшированным с помощью широко известных хэш-функций (таких, как crypt()), опасно, поскольку они могут быть подвергнуты атакам по словарю или методом "грубой силы". Возможность хэширования паролей с применением crypt() оставлена только для совместимости с существующими реализациями системы UNIX. В системах, для которых безопасность является критичной, следует (SHOULD) рассмотреть вопрос об использовании сервисов строгой аутентификации для проверки подлинности пользователей.
С другой стороны, доступ к хэшированным паролям можно предоставлять только ряду привилегированных DUA, предоставляющих клиентским приложениям службу "теневых" паролей. Реализация этого подхода может оказаться нетривиальной задачей.
Поскольку данный набор схемы представляет объекты уровня операционной системы, следует (SHOULD) разграничивать доступ к этим объектам (однако, нет практического смысла ограничивать доступ к данным, которые можно будет получить средствами операционной системы уже без ограничения доступа). В частности, важно, чтобы только администраторы могли модифицировать записи, построенные с использованием данного набора схемы, за исключением разрешения принципалам изменять свои пароли (что может быть сделано от имени пользователя клиентским приложением, выполняющим подсоединение к каталогу с правами суперпользователя, тогда можно не назначать пользователям особые права доступа к парольным атрибутам). Например, если пользователям разрешено изменять значение атрибута uidNumber, они могут назначить себе идентификатор, эквивалентный идентификатору суперпользователя, и, тем самым, поставить безопасность системы под угрозу.
Поддерево DIT, сведения из которого публикуются DUA (таким, как шлюз NIS), должно (SHOULD) входить в тот административный домен, который представляет выполняющий публикацию DUA. Например, внешние по отношению к организации принципалы, несмотря на то, что они входят в DIT, не следует рассматривать с точки зрения предоставления тех же полномочий, что и принципалам, входящим в организацию.
Наконец, следует проявлять осторожность при обработке целочисленных атрибутов особого рода (в частности, атрибутов uidNumber и gidNumber), содержащих значения нулевой длины. DUA могут (MAY) интерпретировать такие значения как относящиеся к пользователю "nobody" или группе "nogroup", соответственно.
Автор выражает признательность Leif Hedstrom из Netscape Communications Corporation, Michael Grant и Rosanna Lee из Sun Microsystems Inc., Ed Reed из Novell Inc. и Mark Wahl из Critical Angle Inc. за их существенный вклад в разработку данного набора схемы. Спасибо Andrew Josey из The Open Group за разъяснение аспектов использования торговой марки UNIX, а также Tim Howes и Peter J. Cherny за их поддержку.
UNIX — зарегистрированная торговая марка Open Group.
[RFC1057] Sun Microsystems, Inc., "RPC: Remote Procedure Call: Protocol Specification Version 2", RFC 1057, июнь 1988 г.
[RFC1279] Kille, S., "X.500 and Domains", RFC 1279, ноябрь 1991 г.
[RFC1884] Hinden, R. и S. Deering, "IP Version 6 Addressing Architecture", RFC 1884, декабрь 1995 г.
[RFC2119] Bradner, S., "Ключевые слова для обозначения уровня требований в RFC", BCP 14, RFC 2119, March 1997 г.
[RFC2251] Wahl, M., Howes, T. и S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, декабрь 1997 г.
[RFC2252] Wahl, M., Coulbeck, A., Howes, T. и S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, декабрь 1997 г.
[RFC2254] Howes, T., "The String Representation of LDAP Search Filters", RFC 2254, декабрь 1997 г.
[RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, декабрь 1997 г.
[ROSE] M. T. Rose, "The Little Black Book: Mail Bonding with OSI Directory Services", ISBN 0-13-683210-5, Prentice-Hall, Inc., 1992 г.
[X500] "Information Processing Systems - Open Systems Interconnection - The Directory: Overview of Concepts, Models and Service", ISO/IEC JTC 1/SC21, International Standard 9594-1, 1988 г.
[XOPEN] ISO/IEC 9945-1:1990, Information Technology - Portable Operating Systems Interface (POSIX) - Part 1: Systems Application Programming Interface (API) [C Language]
Luke Howard
PO Box 59, Central Park Vic 3145, Australia
EMail: lukeh@xedoc.com
Примеры в этом разделе приведены для иллюстрации схемы данных, описываемой в этом документе. Они не являются исчерпывающими.
Пример записи с объектным классом posixAccount:
dn: uid=lester, dc=aja, dc=com
objectClass: top
objectClass: account
objectClass: posixAccount
uid: lester
cn: Lester the Nightfly
userPassword: {crypt}X5/DBrWPOQQaI
gecos: Lester
loginShell: /bin/csh
uidNumber: 10
gidNumber: 10
homeDirectory: /home/lester
Соответствующая запись в системном файле паролей UNIX:
lester:X5/DBrWPOQQaI:10:10:Lester:/home/lester:/bin/sh
Пример записи с объектным классом ipHost:
dn: cn=peg.aja.com, dc=aja, dc=com
objectClass: top
objectClass: device
objectClass: ipHost
objectClass: bootableDevice
objectClass: ieee802Device
cn: peg.aja.com
cn: www.aja.com
ipHostNumber: 10.0.0.1
macAddress: 00:00:92:90:ee:e2
bootFile: mach
bootParameter: root=fs:/nfsroot/peg
bootParameter: swap=fs:/nfsswap/peg
bootParameter: dump=fs:/nfsdump/peg
Эта запись представляет хост с каноническим именем peg.aja.com и псевдонимом www.aja.com. Также указаны Ethernet-адрес и четыре параметра загрузки.
Пример записи с объектным классом nisNetgroup:
dn: cn=nightfly, dc=aja, dc=com
objectClass: top
objectClass: nisNetgroup
cn: nightfly
nisNetgroupTriple: (charlemagne,peg,dunes.aja.com)
nisNetgroupTriple: (lester,-,)
memberNisNetgroup: kamakiriad
Эта запись представляет сетевую группу nightfly, содержащую два триплета (пользователь charlemagne, хост peg и домен dunes.aja.com; пользователь lester, хоста нет и любой домен) и одну сетевую группу-члена (kamakiriad).
Наконец, пример использования объектного класса nisObject:
dn: nisMapName=tracks, dc=dunes, dc=aja, dc=com
objectClass: top
objectClass: nisMap
nisMapName: tracks
dn: cn=Maxine, nisMapName=tracks, dc=dunes, dc=aja, dc=com
objectClass: top
objectClass: nisObject
cn: Maxine
nisMapName: tracks
nisMapEntry: Nightfly$4
Эти записи представляют NIS-карту tracks и один объект карты.
Copyright (C) Internet Society (1998). Все права защищены.
Этот документ и его переводы могут быть скопированы и переработаны в другие документы. Производные работы, комментирующие или иным способом поясняющие данный документ, либо оказывающие помощь в его реализации, могут быть подготовлены, скопированы, опубликованы и распространены, целиком или частями, без каких-либо ограничений, при условии, что указанное выше уведомление об авторском праве и этот параграф будут включены во все такие копии и производные работы. Однако, в этот документ как таковой не может быть внесено каких-либо изменений, таких как удаление уведомления об авторских правах или ссылок на Internet Society или другие организации Интернет, за исключением случаев, когда это требуется для разработки стандартов Интернет (при этом должны быть пройдены процедуры получения авторских прав, определённые в стандартах Интернет), либо когда это требуется при переводе на языки, отличные от английского.
Предоставляемые выше ограниченные права являются бессрочными и не подлежат отзыву Internet Society, его наследниками или правопреемниками.
Этот документ и содержащаяся в нём информация распространяются "КАК ЕСТЬ" и INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБЫЕ ГАРАНТИИ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ ПРИВЕДЁННОЙ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШАЕТ КАКИХ-ЛИБО ПРАВ ИЛИ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ПРИГОДНОСТИ ДЛЯ КОНКРЕТНЫХ ЦЕЛЕЙ.