LINUX.ORG.RU
ФорумAdmin

Авторизация в AD через промежуточный сервер

 pam-ldap, ,


0

1

Дано: есть сервер с двумя интерфейсами, один смотрит в локальную сеть предприятия, второй - в изолированную сеть, в которой также живут несколько других машин. В локальной сети предприятия живет AD в лице нескольких контроллеров на оффтопике. На сервере, описываемом мной, линукс, на машинах в изолированной сети - тоже.

Нужно, чтобы можно было авторизоваться с реквизитами из AD как на сервере, так и на изолированных машинах. Я так понимаю, что на сервере должен использоваться модуль pam_ldap, но можно ли его настроить так, чтобы он «проксил» запросы на авторизацию в домене от изолированных машинах? Будет ли при этом он виден в AD как ещё один контроллер?

Есть ли вообще по этому вопросу годные книжки? Ман по самбе - это хорошо, но хотелось бы какое-нибудь содержательное описание реальной инфраструктуры.

★★★

Последнее исправление: pianolender (всего исправлений: 1)

Поставь на этом сервере TCP прокси, который будет проксировать LDAP-запросы на контроллеры AD с серверов в изолированной сети. Ну а на них уже ставь pam_ldap или всё что душе угодно, указывая тот сервер в качестве LDAP-сервера.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

А в случае, если вычислительных узлов (тех машин в изолированной сети) 20, 40, 60 - разве не лучше было бы кешировать авторизацию? Так можно сделать?

pianolender ★★★
() автор топика
Последнее исправление: pianolender (всего исправлений: 1)
Ответ на: комментарий от pianolender

Нет, LDAP нельзя. Ставишь HA-Proxy в режиме балансировки сразу на все домен-контроллеры, нагрузка будет распределяться.

blind_oracle ★★★★★
()

pam_ldap на active_directory плохо встаёт, если в AD нет поддержки набора реквизитов под unix. Если их нет, то придётся городить велосипед.

IMHO в любом случае, лучше использовать sssd вместо pam_ldap - он умеет кэшировать реквизиты на случай недоступности LDAP-сервера, что вельми полезно.

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

умеет кэшировать реквизиты на случай недоступности LDAP-сервера, что вельми полезно.

Воооот. То, что и хотелось.

pianolender ★★★
() автор топика
Ответ на: комментарий от no-dashi

У меня он нормально с AD работает, конфиг такой:

uri ldap://127.0.0.1
ldap_version 3
base OU=Пользователи,DC=domain,DC=ru

binddn CN=service_ldap_ro,CN=Users,DC=domain,DC=ru
bindpw xxx

scope sub
timelimit 30
bind_timelimit 10
bind_policy hard

idle_timelimit 3600

pam_filter objectclass=user
pam_login_attribute sAMAccountname

pam_groupdn CN=proxy_socks_access,OU=Proxy,OU=Groups,DC=domain,DC=ru
pam_member_attribute member

blind_oracle ★★★★★
()
Ответ на: комментарий от pianolender

Нигде, я юзаю его только для авторизации в сокс-прокси.

Да, про айдишники я забыл, юникс-аттрибуты в AD таки нужны будут, но у меня в схеме они уже давно есть, не вижу проблем с их добавлением.

blind_oracle ★★★★★
()
Ответ на: комментарий от pianolender

Sssd -да, к AD подцепляется при наличии атрибутов. А аутентификация делается через виндовый же kerberos - опять же через Sssd.

no-dashi ★★★★★
()
Ответ на: комментарий от pianolender

Ну, в принципе никто не мешает (наверное) запихать uid-ы и gid-ы в какие-то обычные аттрибуты в схеме AD, но это не особо красиво.

А так вроде как в AD POSIX аттрибуты идут по дефолту - посмотрел схему относительно свежего домена - там uid/gidnumber/loginShell и т.п. есть, хз достаточно ли их.

blind_oracle ★★★★★
()
Ответ на: комментарий от blind_oracle

Достаточно - не суть важно, где хранить, главное, чтобы пользователи имели одинаковые айдишники на разных машинах, чтобы, примонтировав общий /home, не иметь проблем с доступом.

Значит, надо просто указать, что айдишники хранятся в AD, ок.

pianolender ★★★
() автор топика
Ответ на: комментарий от pianolender

Неможно.

Во-первых, я аутентифицируюсь не в AD.

Во-вторых, он здесь более-менее есть: OpenLDAP + openssh (комментарий)

В-третьих, консультации я оказываю только за деньги, и помогаю советом только если мне «не влом». Но - я эту задачу решал, ничего сложного там нет - пробежаться по AD с ldapsearch, подпилить названия атрибутов - и всё заработает.

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

Вот кстати. Помнится, ты что-то делал насчёт сетевой интеграции виндовых и линуксовых сервисов и обещал выложить результаты, если получится что-нибудь. «Что-нибудь» получилось?

geekless ★★
()
Ответ на: комментарий от geekless

Ну, в общем-то, я получил вполне работоспособную схему в аспектах, связанных с аутентификацией и авторизацией, включая SSO: http://vikki.logotek.ru/~viking/opendirectory/

Всяческие AD-шные фишки типа group policy делали мои студенты на дипломную работу, но мы же знаем уровень проработки темы студентами, так что отдавать это в паблик я пока не стал.

no-dashi ★★★★★
()
Ответ на: комментарий от pianolender

Более-менее рабочий конфиг для SSSD с ActiveDirectory. sssduser - это обычный юзер, который заведён в AD. Конфиг немного отличается от «канонического», но вполне себе рабочий, всё что нужно от вендосервера - учётка юзера под SSSD и последующая корректная настройка атрибутов.

[sssd]
config_file_version = 2
services = nss, pam
domains = COMPANY

[nss]

[pam]

[domain/COMPANY]

id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
enumerate = true
min_id = 1000
max_id = 65535

ldap_tls_reqcert = never
ldap_uri = ldap://ip.of.any.dc
ldap_default_bind_dn = COMPANY\sssduser
ldap_default_authtok_type = password
ldap_default_authtok = sssduserPassword

ldap_user_search_base = cn=users,dc=company,dc=ru?subtree?(uidnumber=*)
ldap_group_search_base = cn=users,dc=company,dc=ru?subtree?(gidnumber=*)
ldap_user_home_directory = unixHomeDirectory
ldap_user_object_class = user
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber
ldap_user_gecos = displayname
ldap_user_name = msSFU30Name
ldap_user_principal = msSFU30Name

ldap_schema = rfc2307
ldap_group_object_class = group
ldap_group_name = samaccountname

cache_credentials = true
krb5_server = ip.of.any.dc
krb5_kpasswd = ip.of.any.dc
krb5_realm = COMPANY.RU

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

всё что нужно от вендосервера - учётка юзера под SSSD и последующая корректная настройка атрибутов

ldap_user_name = msSFU30Name

Так SFU все-таки надо включать? Это штатный компонент системы, или нужно отдельно скачивать? А то в оффтопике 2008 r2 я только SUA нашел, и, судя по описанию, это что-то другое.

pianolender ★★★
() автор топика
Последнее исправление: pianolender (всего исправлений: 1)
Ответ на: комментарий от pianolender

А не надо никаких «маппингов». Объект должен содержать всё что необходимо, всякие «маппинги» нужны только есл искрещиваются независсимые источники. Если источники связанные, или это один источник - не трахай моск, заведи на объекте нужные реквизиты.

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

А при каком уровне логирования от sssd можно получить информацию о том, почему не удалось вытащить юзера? А то я узнаю об этом от pam_sss, а он причину не называет.

pianolender ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.