ftpd  auth  required    pam_unix.so  try_first_pass

# OpenSSH with PAM support requires similar modules.

# The session one is a bit strange, though...

sshd  auth  sufficient  /usr/local/lib/pam_ldap.so

sshd  auth  sufficient  pam_skey.so

sshd  auth  sufficient  pam_opie.so  no_fake_prompts

#sshd  auth  requisite  pam_opieaccess.so

#sshd  auth  sufficient pam_kerberosIV.so  try_first_pass

#sshd  auth  sufficient pam_krb5.so  try_first_pass

sshd  auth  required    pam_unix.so  try_first_pass

sshd  account required  pam_unix.so

sshd  password required pam_permit.so

sshd  session required  pam_permit.so

Локально пароль можно вообще не хранить. Для этого при помощи команды vipw отредактируйте файл паролей. Сотрите зашифрованный пароль во втором поле и поставьте там * (звёздочка).

По сведениям, взятым на http://www.padl.com/OSS/nss_ldap.html, FreeBSD 5.1 и выше уже работает с nss_ldap, но проверить это лично не удалось по причине отсутствия дистрибутива.

Осталось прикрутить SSL. Хотя это вовсе не обязательно, наверняка вы захотите использовать шифрование по двум причинам. Первая – безопасность, ведь запросы к ldap, в том числе пароли, передаются в открытом виде, вторая – возможность пользователю самому менять пароль в AD посредством стандартной команды passwd. Необходимо проделать некоторые операции, как на Windows-сервере, так и на клиентских машинах.

На сервере:

n  Убедиться, что поддерживается шифрование 128 bit, иначе вы не сможете удаленно поменять пароль. Windows 2000 sp2 и выше это умеет, в противном случае установите Encryption pack.

n  Установить сервис сертификатов, входящий в дистрибутив. Без этого сервер не будет принимать соединения по протоколу ldaps. В процессе инсталляции сервиса сертификатов будет предложено создать корневой сертификат. Заполнив поля (можно не все), вы получите файл сертификата, лежащий в директории с:. Делать с ним ничего не придется. В журнале событий (event viewer) должна появиться запись о возможности принятия соединений LDAPS (прим.: у меня это сообщение появилось на следующий день, может, потому, что я не перегружал машину, а до этого все попытки коннекта на ldaps:636 терпели неудачу). Проверить, что сервер работает корректно, можно простым способом. С любой Windows-машины в домене или на самом сервере выполните «Start –> Search –> For People».

В свойствах укажите адрес сервера, порт 636, контейнер для поиска.

В данном примере мы ищем объекты в контейнере Users. Если поиск завершился успехом, значит ваш сервер настроен на прием запросов по протоколу LDAPS порт 636.

На клиенте:

Самым простым решением для меня оказалось использование программы stunnel. После установки stunnel нужно поправить два файла stunnel.conf и ldap.conf. Stunnel.conf может выглядеть так: