Понятия
Откройте Directory является архитектурой службы каталогов. Его интерфейс программирования обеспечивает централизованный путь к приложениям и службам для получения информации, хранившей в каталогах. Часто, разыскивающейся информацией является конфигурационная информация, сохраненная в сервере каталогов или в плоских файлах с каждым файлом, имеющим его собственный формат записи и разделители полей. Примеры конфигурационной информации включают пользователей и группы (/etc/passwd и /etc/group), и автосмонтируйте информацию (/mounts). Откройте Directory использует стандартные типы записи и атрибуты для описания конфигурационной информации так, чтобы Открыли, у клиентов Directory нет потребности знать подробные данные кодирования данных и форматов записи.
Откройте Directory's, основной протокол является LDAPv3. Откройте Directory обеспечивает бесшовную интеграцию и автоматическую интеграцию служб каталогов Apple и сторонних служб каталогов включая Active Directory, iPlanet и OpenLDAP.
Откройте Directory Overview
Откройте Directory состоит из демона DirectoryService, и Откройте плагины Directory. Apple обеспечивает, Открывают плагины Directory для LDAPv3, Active Directory, плоских файлов BSD, НИСА и локального хранилища данных DS. Каждый из этих плагинов предоставляет информацию от своего источника данных для всех поддерживаемых типов данных Службы каталогов. Для получения информации о записи Вашего собственного Открывают плагин Directory, видят, Открывают Directory Plug-in Programming Guide.
Открыть интерфейс программирования Directory идентифицирует основные характеристики, которые характерны для многих служб каталогов, и обеспечивает функции, необходимые для поддержки разработки высококачественных приложений, которые могут работать с широким диапазоном несходных служб каталогов.
Узлы
С точки зрения Открывают Directory, служба каталогов является набором одного или более узлов, где узел является местом, которое может искаться информацию. Каждая служба LDAP, сконфигурированная инструментом Directory Access, является отдельным узлом. Соблюдающие правила применяются к узлам.
Узел является или корнем каталога или дочерним элементом другого узла.
Зарегистрированный узел является узлом, в котором зарегистрировался Открыть плагин Directory, Открывают Directory или что администратор зарегистрировал использование инструмента Directory Access.
Узел является набором записей и дочерних узлов.
Запись может принадлежать только одному узлу. Увеличенные записи могут содержать информацию через многократные узлы, но они все еще принадлежат единственному узлу.
Запись имеет тип и может быть не больше, чем одного типа. Примеры типов записи включают пользовательские записи и записи группы.
Запись имеет имя, и введите, это вместе делает запись уникальной в ее узле. Например, не может быть двух пользовательских записей, имеющих имя «администратор», но может быть пользовательская запись, названная «администратором» и записью группы, названной «администратором» в том же узле.
Узлы и записи могут содержать любое число атрибутов.
Атрибут может иметь значение. Определенные атрибуты могут иметь больше чем одно значение.
Значение атрибута является произвольными данными, структура которых неизвестна Открыть интерфейсу программирования Directory. Откройте клиенты Directory ответственны за интерпретацию значения любого определенного атрибута.
Рисунок 1-2 показывает, как Открывают Directory, и плагины Open Directory LDAPv3 могли бы определить местоположение узлов по сети.
Учитывая топологию, показанную на рисунке 1-2, Открыть Directory функционирует для перечисления зарегистрированных узлов (ODSessionCopyNodeNames) мог бы возвратить следующий список:
/LDAPv3/private.example.com |
/LDAPv3/public.example.com |
Первая часть имени узла (LDAPv3 в этом примере), имя плагина, обрабатывающего тот узел.
Поисковые политики и поисковые узлы
Поисковая политика определяет расположения, которые должны искаться и порядок, в котором те расположения ищутся для получения определенных видов информации.
Поисковые узлы проводят поисковую политику, сконфигурированную администраторами через приложение Доступа Каталога. Поисковые узлы просты для, Открывают приложения Directory для нахождения и, как гарантируют, всегда будут доступны. Когда Открыть клиентское приложение Directory использует поисковый узел для поиска информации, оно может запросить полностью определенный путь на любую запись, соответствующую определенные критерии поиска. В результате Откройте, Directory может выполнить чрезвычайно точные поиски с высокой степенью управления типом возвращающейся информации.
Существует четыре поисковых типов узлов:
Узел поиска аутентификации. Используйте этот поисковый узел при поиске информации, которая необходима для аутентификации пользователя. Используйте постоянное сопоставление с образцом
kODNodeTypeAuthenticationдля определения местоположения аутентификации ищут узел. Примеры приложений, использующих узел поиска аутентификации, включают окно входа в систему и приложения, устанавливающие Установки системы.Контакты ищут узел. Используйте этот поисковый узел при поиске контактной информации, такой как адрес электронной почты, телефонный номер или адрес расположения. Используйте постоянное сопоставление с образцом
kODNodeTypeContactsдля определения местоположения контактов ищут узел. Mail.app и Адресная книга используют узел поиска контактов для поиска адресов электронной почты и других типов контактной информации.Сетевой поисковый узел. Используйте этот поисковый узел, консолидирующий все узлы, которые локальны для машины в целях открытия службы, для нахождения служб на локальную сеть. Когда третье лицо Открывает, плагины Directory загружаются, они регистрируются, их узлы с Открывают Directory, таким образом, они могут быть найдены сетевым поисковым узлом. Используйте постоянное сопоставление с образцом
kODNodeTypeNetworkопределять местоположение сетевого поискового узла.Локально размещенные узлы. Используйте локально размещенный узел для нахождения доменов сохраненными на этой машине (т.е. локальный домен плюс любые совместно используемые домены, работающие локально). Хранение данных бэкэнда для этого узла находится в форме plist файлов, хранивших в
/var/db/dslocal. Локальный узел службы каталогов всегда запрашивается сначала при использовании узла поиска аутентификации. С локальным узлом службы каталогов ссылаются/Local/Default. Можно также использовать постоянное сопоставление с образцомkODNodeTypeLocalNodesопределять местоположение локального узла службы каталогов.
Типы записи
Apple определил серию стандартных типов записи. Стандартные типы записи включают, но не ограничиваются пользовательскими записями, записями группы, записями машины и записями принтера.
Провайдеры служб могут определить свои собственные типы записи (известный как собственные типы записи) и призваны опубликовать информацию о них. Разработчики призваны использовать стандартные типы записи Apple, когда это возможно. Для списка стандартных типов записи посмотрите Record_Types.
Стандартные типы атрибута
Apple определил серию стандартных атрибутов. Разработчики могут определить свои собственные атрибуты (известный как собственные атрибуты). Атрибут может требоваться или дополнительный. Каждый тип записи определяет атрибуты, которых он требует.
Откройте клиенты Directory ответственны за интерпретацию значения любого определенного атрибута. Вся конфигурация и открытие информации в службе каталогов могут быть выполнены путем запроса надлежащего значения атрибута.
Посмотрите General Attribute Types и Configuration Attribute Types для полного списка атрибутов.
Собственные типы атрибута
Разработчики могут определить свои собственные атрибуты (известный как собственные атрибуты). Откройте Directory отображает пространство имен каждой системы каталогов на собственные типы, в то время как стандартные типы являются тем же через все, Открывают плагины Directory.
Плагины
Откройте плагины Directory обеспечивают, интерфейс между Открывают Directory и определенное хранилище данных. Можно сконфигурировать, Открывают плагины Directory в области Accounts Установок системы или с приложением Утилиты Каталога.
Аутентификация
Откройте Directory поддерживает аутентификацию на основе в расчете на пользователя. Пользовательские записи имеют атрибут полномочий аутентификации, указывающий:
Тип аутентификации, которая должна использоваться для аутентификации определенного пользователя
Вся требуемая информация для использования указанного метода аутентификации, такого как закодированная информация о пароле
OS X поддерживает следующие типы аутентификации:
Основной, который поддерживает аутентификацию по паролю склепа. Для получения дополнительной информации посмотрите Стандартную аутентификацию.
Аутентификация сервера Пароля Apple, использующая Сервер Пароля OS X для выполнения аутентификации. Для получения дополнительной информации посмотрите Аутентификацию сервера Пароля Apple.
Теневая аутентификация Хеша, использующая соленые хеши SHA 1. Тип хеша может быть сконфигурирован с помощью данных полномочий аутентификации. По умолчанию NT и хеши Диспетчера локальной сети не сохранены в локальных файлах, но хранение их в локальных файлах может быть включено. Это - аутентификация по умолчанию для этой версии OS X. Для получения дополнительной информации посмотрите Теневую Аутентификацию Хеша.
Локальная Кэшируемая Аутентификация пользователя, которая является подходящей для каталогов дома на колесах с помощью основанной на каталоге аутентификации, таких как LDAP. Для получения дополнительной информации посмотрите Локальную Кэшируемую Аутентификацию пользователя.
Аутентификация Версии 5 Kerberos, использующаяся для аутентификации пользователей к системам Kerberos v5. Для получения дополнительной информации посмотрите Аутентификацию Версии 5 Kerberos.
Отключенная Аутентификация пользователя, препятствующая тому, чтобы любая аутентификация имела место. Для получения дополнительной информации посмотрите Отключенную Аутентификацию пользователя.
Пользовательские записи содержат дополнительный атрибут полномочий аутентификации. Атрибут полномочий аутентификации может иметь одно или более значений, указывающих, как аутентификация и изменение пароля должны быть проведены для того пользователя. Формат этого атрибута является разграниченной точкой с запятой строкой, состоящей из полей в следующем порядке:
Версия. Числовое значение, идентифицирующее структуру атрибута. Это поле в настоящее время не используется и обычно является пробелом. Это поле может содержать до трех 32-разрядных целочисленных значений (ASCII 0–9) разделенный периодами (.). Если это поле пусто, или его значение равняется 1, версия является рассмотрением, чтобы быть 1.0.0. Если второе или третье поле пусты; версия интерпретируется как 0. Большая часть клиентского программного обеспечения будет только потребности проверить первую цифру поля версии. Это поле не может содержать точку с запятой (символ ;).
Тег полномочий. Строковое значение, содержащее тип аутентификации для этого пользователя. Каждый тип аутентификации определяет формат поля данных полномочий и указывает, как интерпретируется поле данных полномочий. Поле метки полномочий обрабатывается, поскольку UTF8 представляет в виде строки, в котором продвижение, встроенный, и конечные пробелы является значительным. При сравнении со списком известных типов аутентификации сравнение нечувствительно к регистру. Откройте клиенты Directory, встречающиеся, нераспознанный тип аутентификации должен обработать попытку аутентификации как отказ. Это поле не может содержать символ точки с запятой.
Данные полномочий. Поле, значение которого зависит от типа аутентификации в поле метки полномочий. Это поле может быть пустым и позволяется содержать символы точки с запятой.
Стандартная аутентификация
Открыть клиент Directory, встречающийся с пользовательской записью, содержащей тип Стандартной аутентификации, должен провести аутентификацию с аутентификацией по паролю склепа.
Если пользовательская запись не имеет атрибута полномочий аутентификации, Открыть клиент Directory должен использовать тип Стандартной аутентификации.
Вот некоторые примеры атрибутов полномочий аутентификации, использующих тип Стандартной аутентификации:
;basic; |
1.0.0;basic; |
1;basic; |
Все три примера имеют тот же результат: аутентификация проводится с помощью склепа.
Аутентификация сервера пароля Apple
Тип Аутентификации сервера Пароля Apple требует, чтобы Открыть клиент Directory связался с Простой аутентификацией и Уровнем безопасности (SASL) сервер пароля в сетевом адресе, сохраненном в поле данных полномочий. После контакта с Сервером Пароля Открыть клиент Directory может опросить его для определения надлежащего основанного на сети метода аутентификации, такого как CRAM-MD5, АПОП, NT, Диспетчер локальной сети, DHX или Обзор WebDAV. Обратите внимание на то, что администратор Сервера Пароля может отключить некоторые методы аутентификации в соответствии с политиками локальной защиты.
Поле данных полномочий должно содержать две строки, разделенные единственным двоеточием (символ :). Первая строка начинается с ID SASL. ID SASL предоставлен для Сервера Пароля для идентификации, кто пытается аутентифицировать. Когда пароль создавался для идентификации паролей пользователя в его частной базе данных пароля, реализация Сервера Пароля Apple использует уникальное псевдослучайное 128-разрядное число, закодированное как шестнадцатеричный ASCII, присвоенный. Однако Откройте, клиенты Directory не должны предполагать, что первая строка всегда будет значением фиксированного размера или простым числом.
ID SASL сопровождается запятой (,) и открытый ключ, использующийся, когда клиент бросает вызов Серверу Пароля перед аутентификацией, начинает подтверждать, что не имитируется Сервер Пароля.
Вторая строка является сетевым адресом, состоящим из двух подстрок, разделенных наклонной чертой (/) символ. Первая подстрока является дополнительной и указывает тип сетевого адреса, указанного второй подстрокой. Вторая подстрока является адресом фактической сети. Если первая подстрока и символ наклонной черты не указаны, вторая подстрока, как предполагается, является адресом IPv4.
Если указано, существует три возможных значения для первой подстроки:
IPv4. Клиент может ожидать, что вторая подстрока будет содержать стандартный 32-разрядный сетевой адрес IPv4 в точечном десятичном формате.
IPv6. Клиент может ожидать, что вторая подстрока будет содержать стандартный 64-разрядный сетевой адрес IPv6.
dns. Клиент может ожидать, что вторая подстрока будет содержать полностью определенное доменное имя, представляющее сетевое расположение сервера пароля.
Если поле данных полномочий отсутствует или уродливое, все значение атрибута полномочий аутентификации должно быть проигнорировано и любая попытка аутентифицировать использование, это должно быть отказавшим.
В следующем примере атрибута полномочий аутентификации для Аутентификации сервера Пароля OS X поле версии пусто, таким образом, версия принята к 1.0.0. ID SASL 0x3d069e157be9c1bd0000000400000004. IP-адресом не предшествуют ipv6/, таким образом, IP-адрес, как предполагается, является адресом IPv4.
;ApplePasswordServer;0x3d069e157be9c1bd0000000400000004,1024 35 |
16223833417753121496884462913136720801998949213408033369934701878980130072 |
13381175293354694885919239435422606359363041625643403628356164401829095281 |
75978839978526395971982754647985811845025859418619336892165981073840052570 |
65700881669262657137465004765610711896742036184611572991562110113110995997 |
4708458210473 root@pwserver.example.com:17.221.43.124 |
В следующем примере, появлении dns указывает, что сетевой адрес во второй подстроке является полностью определенным доменным именем.
;ApplePasswordServer;0x3d069e157be9c1bd0000000400000004,1024 35 |
16223833417753121496884462913136720801998949213408033369934701878980130072 |
13381175293354694885919239435422606359363041625643403628356164401829095281 |
75978839978526395971982754647985811845025859418619336892165981073840052570 |
65700881669262657137465004765610711896742036184611572991562110113110995997 |
4708458210473 root@pwserver.example.com:dns/sasl.password.example.com |
Теневая аутентификация хеша
Теневой тип аутентификации Хеша является методом пароля по умолчанию для OS X v10.3 и позже. В то время как системы Сервера OS X хранят определенные хеши по умолчанию, начиная с OS X v10.4, настольные системы OS X не хранят NT и хеши Диспетчера локальной сети по умолчанию. Когда хранение хешей включено, только соленый хеш SHA 1 сохранен. Когда пароль изменяется, все сохраненные версии пароля обновляются.
Если значение поля данных полномочий BetterHashOnly, только хеш NT используется.
Теневая аутентификация открытого текста поддержки аутентификации Хеша (используемый, например, loginwindow) а также NT и методы аутентификации Диспетчера локальной сети. Если надлежащие хеши сохранены, начиная с OS X v10.4, аутентификация ShadowHash также поддерживает CRAM-MD5, DIGEST-MD5, и методы аутентификации APOP.
Вот некоторые примеры должным образом сформированных значений атрибута полномочий аутентификации для Теневой аутентификации Хеша:
;ShadowHash; |
1.0.0;ShadowHash; |
1;ShadowHash; |
В OS X v10.4 и позже, поле данных полномочий может быть настроено со списком хешей, которые должны быть сохранены. Вот пример:
;ShadowHash;HASHLIST:<SALTED-SHA-1,SMB-NT,SMB-LAN-MANAGER> |
Другие допустимые типы хеша CRAM-MD5, RECOVERABLE, и SECURE.
Локальная кэшируемая аутентификация пользователя
Локальная Кэшируемая Аутентификация пользователя используется для каталогов дома на колесах. Поле данных полномочий должно присутствовать. Его формат:
DS Nodename:DS Recordname:ГУИД DS
где двоеточие (:) символ разграничивает три отдельных строки. Требуются все три строки. Первая строка является любым допустимым именем узла в формате UTF-8. Вторая строка является любым допустимым рекордным именем в формате UTF-8. Третья строка является любым допустимым сгенерированным уникальным идентификатором (GUID) в формате UTF-8.
Если поле данных полномочий отсутствует или уродливо, значение атрибута полномочий аутентификации должно быть проигнорировано и должно привести к отказу аутентифицировать любой клиент, делающий попытку аутентификации с помощью него. Никакой другой тип аутентификации не может быть объединен с этим типом аутентификации.
Вот некоторые примеры должным образом сформированных значений атрибута полномочий аутентификации для Локальной Кэшируемой Аутентификации пользователя:
;LocalCachedUser;/LDAPv3/bh1234.example.com:bjensen:AFE453BF-284E-4BCE- |
ADB2-206C2B169F41 |
1.0.0;LocalCachedUser;/LDAPv3/bh1234.example.com:bjensen:AFE453BF-284E- |
4BCE-ADB2-206C2B169F41 |
1;LocalCashedUser;/LDAPv3/bh1234.example.com:bjensen:AFE453BF-284E-4BCE- |
ADB2-206C2B169F41 |
Аутентификация версии 5 Kerberos
Для аутентификации Версии 5 Kerberos поле данных полномочий отформатировано следующим образом:
[UID]; [пользовательский принципал (с областью)]; область; [открытый ключ области]
Дополнительный 128-разрядный UID кодируется таким же образом что касается Аутентификации сервера Пароля Apple.
Дополнительный пользовательский принципал является пользовательским принципалом для этого пользователя в системе Kerberos. Если пользовательский принципал не присутствует, имя пользователя и область используются для генерации основного имени (user@REALM). Это позволяет фиксированному значению полномочий аутентификации быть установленным и примененным ко все пользовательские записи в базе данных.
Требуемая область является именем области Kerberos, которой принадлежит пользователь.
Дополнительный открытый ключ области может использоваться для аутентификации KDC в будущем выпуске.
Следующий пример приводит к пользовательскому принципалу kerbdude@LDAP .EXAMPLE.COM:
;Kerberosv5;0x3f71f7ed60eb4a19000003dd000003dd;kerbdude@LDAP. |
EXAMPLE.COM;LDAP.EXAMPLE.COM;1024 35 |
148426325667675065063924525312889134704829593528054246269765042088452509 |
603776033113420195398827648618077455647972657589218029049259485673725023 |
256091629016867281927895944614676546798044528623395270269558999209123531 |
180552515499039496134710921013272317922619159540456184957773705432987195 |
533509824866907128303 root@ldap.example.com |
Отключенная аутентификация пользователя
Отключенная Аутентификация пользователя используется, чтобы указать, что была отключена учетная запись. Полное предыдущее значение атрибута аутентификации сохраняется в поле данных полномочий и включается левыми и правыми угловыми скобками. Если поле данных полномочий отсутствует, Стандартная аутентификация принята.
Вот некоторые примеры должным образом сформированных значений атрибута полномочий аутентификации для Отключенной Аутентификации пользователя:
;DisabledUser;;ShadowHash; |
;DisabledUser;<;ShadowHash;> |
Левое ( < ) и право ( > ) угловые скобки вокруг старого значения полномочий аутентификации являются дополнительными. Любой инструмент, повторно включающий пользователю, должен проверить, чтобы видеть, используются ли скобки и разделяют их при восстановлении исходного значения полномочий аутентификации.
Многократные значения атрибута аутентификации
Атрибут аутентификации может иметь многократные значения. При изменении пароля пробуют все значения полномочий аутентификации, пока пароль успешно не изменяется, или ошибка происходит. При проверке пароля порядок значений полномочий аутентификации определяет, какое значение используется сначала. Первые полномочия аутентификации, возвращающие что-то другое, чем kODErrorCredentialsMethodNotSupported используется.
Аутентификация по сравнению с авторизацией
Важно отличить аутентификацию и авторизацию:
Аутентификация. Процесс, использующий данные, предоставленные пользователем (обычно пароль) для проверки идентификационных данных того пользователя
Авторизация. Определение того, есть ли у пользователя разрешение получить доступ к определенному набору информации
Откройте Directory позволяет Открыть клиенту Directory использовать любой метод для аутентификации пользователя. Откройте Directory не предоставляет средства для определения, разрешен ли пользователь получить доступ к какому-либо определенному набору информации. Кроме того, Откройте, Directory не обеспечивает модель авторизации. Вместо этого Откройте, клиенты Directory ответственны за предоставление или отклонение пользовательского доступа к определенному набору информации на основе аутентифицируемых идентификационных данных пользователя.
При разработке модели авторизации Откройте, клиенты Directory должны рассмотреть следующее:
Информация авторизации для хранения
Где и как сохранить информацию авторизации
Какие приложения видят, создайте или измените информацию авторизации
Кто разрешен видеть и изменить информацию авторизации
Часто авторизация основывается на членстве в определенной группе. Много служб каталогов хранят информацию авторизации в самой службе каталогов. Эти службы каталогов используют идентификационные данные, в настоящее время использующиеся для доступа к службе каталогов, чтобы определить, предоставить ли доступ к этой информации.
Другие службы каталогов хранят информацию авторизации за пределами службы. Путем обеспечения интерфейса между клиентами служб каталогов и самих служб каталогов, может быть совместно использована информация авторизации, которая сохранена за пределами службы каталогов. Например, Вы могли разработать систему, управляющую авторизацией на основе общего маркера (такого как пользовательская запись в общем каталоге) так, чтобы то, когда администратор создает, удалило или изменило маркер, все службы используют тот же самый маркер для авторизации. Соответственно, Открытый Каталог dsDoDirNodeAuth функция inDirNodeAuthOnlyFlag параметр говорит плагин, используется ли доказательство процесса идентификационных данных для установления доступа к внешнему каталогу или используется ли доказательство процесса идентификационных данных только для проверки пароля.
Вот некоторые пути, которые могли использоваться для установления идентификационных данных, разрешенных получить доступ к внешнему каталогу:
Имейте Открыть клиентское использование Directory предпочтение для установления идентификационных данных «конфигурации», которые могут получить доступ к данному каталогу
Сконфигурируйте Открыть плагин Directory с информацией об идентификационных данных
Будет необходимо для администратора внешнего каталога установить, обеспечить или сконфигурировать идентификационные данные с достаточным доступом так, чтобы служба или плагин могли получить доступ или изменить всю необходимую информацию во внешнем каталоге. Разрешение анонимного доступа для чтения является альтернативой хранению имени пользователя и пароля на каждой клиентской машине. Возможно ли это, зависит от сервера каталогов в использовании.
OS X v10.4 и позже дополнительно использует привязку каталога, которой доверяют, устанавливающую доверительные отношения между клиентской машиной и сервером каталогов.
Собственная аутентификация каталога
Откройте Directory поддерживает механизм, освобождающий, Открывают клиенты Directory от необходимости предоставить определенную информацию об определенном методе аутентификации. Этот механизм вызывают собственной аутентификацией каталога.
При использовании собственной аутентификации каталога для аутентификации пользователя к узлу Открыть клиент Directory передает Открыть плагину Directory имя пользователя, пароль и дополнительную спецификацию, что открытый текст не является приемлемым методом аутентификации.
По получении запроса аутентификации Открыть плагин Directory определяет надлежащий метод аутентификации на основе своей конфигурации (если плагин конфигурируем), или на методах аутентификации плагин был кодирован для обработки. Когда аутентификация успешна, Открыть клиент Directory получает тип аутентификации, который использовал плагин.
Когда открытый текст является единственным доступным методом аутентификации, плагин отклонил бы аутентификацию, если Открыть клиент Directory указывает, что аутентификация открытого текста недопустима.
Прокси каталога
В OS X v10.2 и позже, приложения могут открыть аутентифицируемый, и зашифрованные Открывают сеанс Directory с удаленным демоном DirectoryService по TCP/IP. ODSession класс ответственен за открытие удаленного, Открывают сеансы Directory. После удаленного Открывают, сеанс Directory успешно открыт, Откройте, Directory автоматически отправляет все вызовы для Открытия функций Directory, использующих удаленную ссылку каталога на демона DirectoryService по зашифрованному соединению TCP/IP. Нет ничего, что приложение должно сделать для его действий для вступления в силу в удаленной системе.
Демон DirectoryService
Кэширование
В OS X v10.5 и позже, кэширование службы каталогов обрабатывается в демоне DirectoryService. Кэш DS может быть просмотрен и сброшен с dscacheutil утилита командной строки.
Состав группы
В OS X v10.5 и позже, разрешение состава группы, пользовательское разрешение идентификационных данных и кэширование обрабатываются демоном DirectoryService. Кэширование для состава группы и пользовательских идентификационных данных является отдельным от остальной части кэша службы каталогов. Эта функциональность программно доступна с Членством API. Посмотрите Ссылку Функций принадлежности для получения дополнительной информации о Членстве API. Можно также запросить для группы и пользовательской информации об идентификационных данных с dsmemberutil утилита командной строки.
Утилита командной строки службы каталогов
Утилита командной строки службы каталогов, dscl, воздействует на, Открывают узлы Directory. dscl опции утилиты позволяют Вам создавать, читать и управлять, Открывают данные Directory. Для получения дополнительной информации о dscl утилита, см. страницу справочника для dscl.
Отладка
Включение отладки
Необходимо быть root ввести DirectoryService killall команды, включающие и отключающие журналирование отладки. Следующая команда, выполненная корнем, включает журналирование отладки, если журналирование отладки в настоящее время выключено и отключает журналирование отладки, если журналирование отладки в настоящее время находится на:
killall -USR1 DirectoryService |
Отладочная информация отправляется в /Library/Logs/DirectoryService/DirectoryService.debug.log. Отладочная информация включает ввод для Открытия Directory API calls, результатов, и синхронизация, плюс любой вывод отладочной информации Открывают плагины Directory.
Следующая команда, выполненная корнем, включает журналирование отладки к /var/log/system.log если журналирование отладки в настоящее время находится на, если журналирование отладки в настоящее время выключено и отключает журналирование отладки:
killall -USR2 DirectoryService |
Когда журналированием отладки включают -USR2, вывод отладки включает результаты вызова API и синхронизацию. Журналирование отладки, включенное -USR2 выключен автоматически после 5 минуты.
Конфигурирование отладки
Можно установить уровень журналирования отладки для управления суммой регистрирующейся информации. Следующие наборы команд уровень журналирования к 7 из возможного 7:
sudo defaults write /Library/Preferences/DirectoryService/DirectoryServiceDebug "Debug Logging Priority Level" -int 7 |
Установка уровня журналирования к 0 отключает журналирование отладки.
Можно сконфигурировать DirectoryService, чтобы автоматически позволить отладить каждый раз, когда он запускает со следующей командой:
touch /Library/Preferences/DirectoryService/.DSLogDebugAtStart |
Удалите создаваемый файл для отключения этой установки. Можно также сконфигурировать DirectoryService, чтобы автоматически позволить отладить только в очень следующий раз, когда он запускает со следующей командой:
touch /Library/Preferences/DirectoryService/.DSLogDebugAtStartOnce |