Вопросы Теги

Как включить ОБЗОР-MD5, механизм SASL в Открывает Directory?

Мы создали Открыть ведущее устройство Directory на Йосемити OSX 10.10 + Server.app v4:

$ sudo slapconfig -createldapmasterandadmin admin Administrator 1000

Но это не поддерживает DIGEST-MD5:

$ ldapsearch -x -LLL -b "" -s base supportedSASLMechanisms
dn:
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: CRAM-MD5

Который является проблемой, потому что пользователи не могут пройти проверку подлинности против collabd (для Профиля/Диспетчера устройств или Wiki):

<Error>: [CSAuthService.m:326 667e000 +86ms] Digest did not validate
<Error>: [CSServiceDispatcher.m:261 667e000 +0ms] Caught exception "Invalid Credentials" [CSAuthBadDigest] executing [http]Request{AuthService.validateUsernameAndPasswordDigest:remember:(<<scrubbed>>)}:
(
    0   CoreFoundation                      0x00007fff8d35c64c __exceptionPreprocess + 172
    1   libobjc.A.dylib                     0x00007fff92ec76de objc_exception_throw + 43
    2   CSService                           0x000000010425fc90 -[CSAuthService sessionForDigest:remember:] + 1681
    3   CSService                           0x000000010425f5a7 -[CSAuthService validateUsernameAndPasswordDigest:remember:] + 65
    4   CoreFoundation                      0x00007fff8d23533c __invoking___ + 140
    5   CoreFoundation                      0x00007fff8d235192 -[NSInvocation invoke] + 290
    6   CSService                           0x00000001041dce3d -[CSServiceDispatcher executeRequest:asPartOfBatch:usingServiceImpl:] + 4774
    7   CSService                           0x00000001041dd91e __43-[CSServiceDispatcher executeBatchRequest:]_block_invoke_3 + 83
    8   CSService                           0x00000001041e2a22 -[NSArray(CollabBlockMethods) map:] + 249
    9   CSService                           0x00000001041dd877 __43-[CSServiceDispatcher executeBatchRequest:]_block_invoke_2 + 160
    10  CSService                           0x00000001041e3100 +[CSExecutionTimer recordTime:ofBlock:] + 74
    11  CSService                           0x00000001041e2f3b +[CSExecutionTimer timerNamed:aroundBlock:] + 76
    12  CSService                           0x00000001041dd5c4 __43-[CSServiceDispatcher executeBatchRequest:]_block_invoke + 323
    13  PostgreSQLClient                    0x00000001041400b3 -[PGCConnection transactionInBlock:onError:] + 149
    14  CSService                           0x00000001041dd3fa -[CSServiceDispatcher executeBatchRequest:] + 277
    15  CSService                           0x0000000104253aab +[CSServiceDispatchHTTPRouter routeServiceRequest:response:] + 1024
    16  CSService                           0x00000001041e399e __21-[CSServiceBase init]_block_invoke_6 + 48
    17  CSService                           0x0000000104250af4 __53-[CSRoutingHTTPConnection httpResponseForMethod:URI:]_block_invoke + 92
    18  CSService                           0x00000001042540ea -[CSHTTPBackgroundResponse bounce:] + 284
    19  Foundation                          0x00007fff8e14cb7a __NSThread__main__ + 1345
    20  libsystem_pthread.dylib             0x00007fff9ad2f2fc _pthread_body + 131
    21  libsystem_pthread.dylib             0x00007fff9ad2f279 _pthread_body + 0
    22  libsystem_pthread.dylib             0x00007fff9ad2d4b1 thread_start + 13
)

Как каждый включает DIGEST-MD5?

2
задан 17 December 2014 в 00:24
2 ответа

Попробуйте перечислить поддерживаемые сервером паролей типы хэшей с помощью 

pwpolicy -n /LDAPv3/127.0.0.1 -getglobalhashtypes

... и посмотрите, включает ли он RECOVERABLE (который, я считаю, необходим как для DIGEST-MD5, так и для WEBDAV-DIGEST) (обратите внимание, что это не будет перечислять GSSAPI / Kerberos, поскольку это обрабатывается отдельной службой). К сожалению, у меня нет возможности проверить это право, но если он отсутствует, попробуйте: 

pwpolicy -n /LDAPv3/127.0.0.1 -a admin -setglobalhashtypes RECOVERABLE on

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

1
ответ дан 3 December 2019 в 11:40

Вот что помогло мне решить проблему входа в систему в OS X 10.11.6 с сервером 5.1.7. Эти шаги также решили несколько других проблем, таких как невозможность установить профили из-за проблем с доверием, разрешениями пользователей, невозможность связаться с сервером и т.д.

С https://support.apple.com/en-us/HT200018 :

Проверьте DNS:

  1. Откройте терминал и введите имя хоста для проверки имени вашего сервера.

  2. Откройте Server.app и выберите ваш сервер на боковой панели.

  3. Выберите вкладку Обзор. Полное квалифицированное доменное имя вашего сервера должно быть отображено в поле Host Name (Имя хоста).

    Если квалифицированное доменное имя в окне Server (Сервер) не совпадает с результатами команды hostname (Имя хоста), вам необходимо исправить это перед тем как переходя к следующим шагам в этой статье. Если вы уверены Полностью квалифицированное доменное имя, присвоенное IP-адресу вашего сервера, следующее правильно, используйте помощник по смене имени хоста в сервере, чтобы установить параметр Правильное имя хоста для вашего сервера.

  4. Откройте системные настройки и нажмите на иконку Network (Сеть).

  5. Выберите сетевой интерфейс, который был настроен для вашего сервера. IP-адрес вашего сервера указан здесь.

  6. Обратите внимание на перечисленные DNS-серверы.

    Если вы настроили DNS-сервер на вашем сервере и DNS записи были созданы для этого сервера, ваш сервер должен быть в списке 127.0.0.1 (не IP-адрес сервера).

    Если другой сервер в вашей сети размещает DNS-записи для вашего сервер, IP-адрес этого сервера должен быть указан в списке DNS-серверов. поле.

    Если эта информация неверна, нажмите кнопку "Дополнительно...". а затем вкладка DNS. Можно установить правильный адрес (адреса) DNS сервера. здесь.

Тестирование настроек DNS

Вы можете использовать терминал для тестирования разрешения вашего имени на IP-адрес. Откройте терминал (/Applications/Utilities/Terminal.app) и используйте следующие команды:

Используйте команду "host" для проверки разрешения имени в ip-адресе: 

хост <полностью квалифицированное доменное имя вашего сервера>.

Ожидаемый результат Адрес Вы также можете использовать команду "Хост" для проверки IP-адрес для разрешения имен: 

 хост <ваш ip-адрес>

Ожидаемый результат - указатель доменного имени .inaddr.arpa

В дополнение к этому, Сетевой доступ по умолчанию должен быть установлен на All Networks, и я не уверен, поможет ли это, но включение Push-уведомлений Apple в Settings было еще одним шагом, который я предпринял (MDM полагается на Push в определенной степени).

Далее, если вы размещаете свой хостинг на .local доменном имени, также важно, чтобы сертификат, присвоенный вашему серверу, был подписан центром сертификации Open Directory Certificate Authority на вашем компьютере (в противном случае, конечно, вы захотите использовать сертификат, подписанный действительным центром сертификации). Серверная версия 5 OS X имеет некоторые раздражающие ошибки, когда речь заходит о том, как она автоматически назначает сертификаты различным службам, включая веб-сайты. Что мне нужно было сделать, так это вручную создать новый сертификат, перед тем как делать реекеризацию, я выполнил следующие шаги для сброса сертификатов для системы:

  1. (Опционально) После свежего резервного копирования вашей системы, начните все заново, отключив все службы сервера и удалив Мастер из Open Directory. Затем перейдите к Certificates и удалите все сертификаты, за исключением специальных для любых пользовательских сайтов. Также перейдите в /etc/certificates и убедитесь, что там нет никаких неавторизованных сертификатов, которые не отображаются в приложении Server (если они есть, перейдите в папку temp или удалите).

  2. Далее, в приложении OS X Server, если вы еще этого не сделали, то ВЫКЛЮЧАЙТЕ ВСЕ СЛУЖБЫ. Затем перейдите в приложение OS X Server и сделать Сертификаты > + > Создать Идентификатор Сертификата...

  3. Для имени, я поставил мое имя хоста, но вы можете поставить все, что угодно здесь. Тип личности: Лист. Тип сертификата: SSL-сервер. Отметьте "Позвольте мне переопределить настройки по умолчанию". Нажмите "Продолжить".

  4. Для серийного номера выберите то, что вы еще не использовали. Нажмите "Продолжить".

  5. Для Имени (Общего Имени) убедитесь, что оно совпадает с именем вашего хоста. Остальное не имеет значения. Нажмите Продолжить.

  6. Для центра сертификации выберите тот, который содержит текст "Open Directory Certificate Authority" (Открыть центр сертификации), который должен был быть создан при первой настройке Open Directory. Нажмите кнопку Продолжить.

  7. Установите размер бита сертификата (2048 RSA в порядке).

  8. В разделе "Расширение использования ключей" выберите Key Encipherment (Расширение ключей) и Key Agreement (Соглашение о ключах). Нажмите Continue.

  9. В Key Usage Extension, убедитесь, что выбрали SSL Client Authentication (Аутентификация клиента SSL) и PKINIT Client Authentication (Аутентификация клиента PKINIT) (это может не иметь значения, но я увидел ошибку в журнале iPad, которая указывала на то, что клиенту нужен сертификат, и когда я все сбросил и проверил, он начал работать). Нажмите кнопку продолжить.

  10. Пройдите мимо расширения Basic Constraint Extension. Нажмите и продолжайте.

  11. В теме "Расширение альтернативного имени" убедитесь, что dDNSName установлено на ваше имя хоста, проверенное на шаге Check DNS от Apple, описанном выше. Убедитесь, что IP-адрес включает в себя фактический IP-адрес вашего сервера. Нажмите кнопку Продолжить.

  12. Аутентифицируйтесь и нажмите OK. Теперь новый сертификат должен появиться в области Сертификаты сервера OS X. Выберите Безопасные службы: > Пользовательский. В появившемся окне Сертификаты сервера установите сертификат для ВСЕХ служб (за исключением любых пользовательских веб-сайтов, которым нужен собственный сертификат) на ваш новый сертификат.

  13. (Необязательно.) Если вы удалили ведущее устройство Open Directory на шаге 0, то сделайте новое здесь. По крайней мере, убедитесь, что в Open Directory есть локаль с вашим локальным IP диапазоном, например, 10.1.10.0/24 и т.д.

Далее выполните шаг "rekerberize" ниже, из Apple:

Rekerberize your server:

sudo mkdir /var/db/openldap/migration
sudo touch /var/db/openldap/migration/.rekerberize
sudo slpconfig - первая лодка

Последняя вышеприведенная команда терминала включит сервер Open Directory. Вернитесь к серверному приложению и убедитесь, что Open Directory включена. Затем выполните следующие шаги (первые несколько шагов, на мой взгляд, это только для того, чтобы убедиться, что он может работать с .local сервером):

  1. Убедитесь, что DNS-сервер вашего сервера настроен с записью для имени хоста вашей машины, и установите переадресацию всех остальных DNS-запросов на обычный DNS-сервер. (Это особенно важно, если вы используете .local домен для вашей машины). Добавьте запись для вашего имени хоста и вашего IP, затем включите DNS-сервер.

  2. Теперь включите Websites. Если вы все еще находитесь в стадии тестирования и ваш сервер все еще находится на .local доменном имени, то дважды щелкните по серверному веб-сайту (SSL) и убедитесь, что его SSL-сертификат настроен как новый, который мы создали выше.

  3. Включите диспетчер профилей. Установите его в значение Sign configuration profiles (Подписать профили конфигурации). В показанном сертификате должно быть написано, что он подписан посредническим центром.

  4. В Пользователях создайте пользователя для использования с Profile Manager. Все пользователи, используемые с Менеджером профилей, ДОЛЖНЫ находиться в "Локальной директории", а НЕ в "Локальной сетевой директории"... это ОЧЕНЬ важно... ! Причина в том, что при выходе из OS X Server (даже из Менеджера профилей) это может привести к размонтированию тома, содержащего данные этого пользователя, предотвращая тем самым его дальнейшие входы в систему. См. этот сайт поддержки Apple: https://support.apple.com/en-us/HT203325

  5. В Safari войдите в Менеджер профилей вашего сервера. Если вы хотите, чтобы устройства автоматически настраивались с экрана приветствия, установите флажок в группе Все для "Разрешить регистрацию во время настройки помощника для устройств, настроенных с помощью Apple Configurator" (См. в этом посте Spiceworks & replies.). Если он выключен, то вход пользователя в систему будет без объяснения причин невозможен во время процесса приветствия на "подготовленном" устройстве.

Теперь, если вы используете .local сервер, то для того, чтобы iPad загрузил и установил профили, вам необходимо выполнить следующие шаги:

  1. Выключите Cellular Data iPad и перейдите к WiFi и убедитесь, что он находится в той же подсети, что и ваш сервер.

  2. Если iPad уже настроен мимо экрана приветствия, настройте DNS-сервер iPad на точное совпадение с именем хоста, определенным в шагах Проверка DNS выше (например, mycomputer.local).

    ИЛИ

  3. Если iPad находится на экране приветствия и это контролируемое устройство, настроенное с помощью конфигуратора для загрузки профиля во время установки с вашего .local MDM сервера, то вам нужно включить Internet Sharing на сервере, чтобы создать точку доступа, и использовать ее для первоначального WIFI соединения. Обратите внимание, что для этого необходимо, чтобы сервер DNS был настроен правильно, как описано в разделе Проверка DNS, цитируемом по вышеуказанному сайту поддержки Apple.

Обратите внимание:

- Технически говоря, .local адрес является полностью квалифицированным доменным именем. Если ваши клиенты находятся в одной локальной сети и подсети с сервером, то все будет работать, если сервер имеет .local адрес, пока на сервере активирована служба Push Notification компании Apple. Если вы настроите Менеджер профилей, а затем отключите APN в OS X Server, то вам не будет предложено снова включить его, и все начнет работать.

- В журнале устройства будут зарегистрированы ошибки следующего типа: 

Desc   : The server certificate for “https://my-macbook-pro.local/devicemanagement/api/device/mdm_checkin” is invalid.

- Тогда это потому, что ваш iPad не доверяет сертификату. Это может означать одну из нескольких вещей:

  1. - Это может означать выдачу сертификата. Убедитесь, что подписание профиля включено в менеджере профилей в приложении OS X Server. Если это не так, и вы не хотите, чтобы он был включен, то вам, возможно, потребуется установить и доверять корневому сертификату на вашем устройстве, либо отправив его по электронной почте на устройство, либо разместив его на веб-сайте, а затем загрузив его с этого веб-сайта на устройство. BTW, "корневой сертификат" означает тот, который подписал корень-посредник, который подписал профиль кодовой подписи, используемый для подписи профиля удаленного управления; вы можете увидеть, какой сертификат подписал, зайдя в Keychain Access и просмотрев подробности сертификатов (корни, насколько я знаю, недоступны из самого приложения OS X Server). (Вы можете установить сертификат на устройство iOS, экспортировав его из Keychain Access как . cer, затем поместите его в файл /Библиотека/Сервер/Веб/Данные/Сайты/Ошибка/, затем sudo chown _www:_www CertName.cer, затем на iPad, перейдите к myserver.local/CertName.cer). Однако мне не нужно было этого делать, если я просто подписал cert. Если все это не удается, то повторите все вышеперечисленные шаги, потому что у вас, вероятно, неверный IP или имя хоста или настройки на сертификатах, или Kerberos нужно перезагрузить и т.д.

  2. Это может означать, что ваш клиент не имеет имени хоста сервера в качестве DNS-сервера. Либо установите, что он есть, либо используйте точку доступа к Интернету сервера, описанную выше.

Эта тема обсуждения Apple, в частности, сообщение Линка Дэвиса, также была очень полезна: https://discussions.apple.com/message/30689429#30689429

1
ответ дан 3 December 2019 в 11:40

Теги

Похожие вопросы