Подключение Linux к WinServer c LDAPservice

[CAEman]

На клиентской машине, на которой стояла WinXP32 с аутентификацией с помощью LDAP на Windows сервере, установил openSUSE11.1x86_64.

Задача состоит в том, чтобы вход пользователей оставался прежним - с аутентификацией на сервере windows.

Дополнительная информация.

Нужный windows домен системой обнаруживается, но к LDAP не подключается:

"udevd[719]: llnss_ldap: failed to bind to LDAP server ...: Can't contact LDAP server

udevd[719]: nss_ldap: failed to bind to LDAP server ...: Can't contact LDAP server

udevd[719]: nss_ldap: could not search LDAP server - Server is unavailable

udevd[719]: error resolving user 'root, GROUP=': Connection refused"

Запустил (под wine) ldp.exe (которая подключается к этому LDAP сервису даже с машин, не подключавшихся к серверу вообще), но она выдаёт: "Error <0x51>: Fail to connect to ...", а в консоли, из-под которой я её запустил:

"fixme:winsock:WSALookupServiceBeginW (0x32f8bc 0x00000710 0x32f914) Stub!

fixme:advapi:LsaOpenPolicy ((nu),0x32f834,0x00000001,0x32f84c) stub

fixme:advapi:LsaClose (0xcafe) stub"

С DHCP всё нормально - всё получает с этого win сервера и в и-нет выходит...

Что делать для решения данной задачи (не имея админ-ских прав на сервере)?

Заранее благодарю.

[gogi]

Цитата:

На клиентской машине, на которой стояла WinXP32 с аутентификацией с помощью LDAP на Windows сервере, установил openSUSE11.1x86_64. Задача состоит в том, чтобы вход пользователей оставался прежним - с аутентификацией на сервере windows.

Если аутентификацией с помощью лдап вы называете вендовую AD (на самом деле в АД аутентификация керберос и авторизация лдап), то вам нужен winbind (это прямое и самое простое решение).

Если же вы аутентифицируетесь именно в ЛДАП (наверное, для венды есть такие реализации) то нужно, чтобы в этом каталоге были юниксовые юзеры со своими uid и gid, а также установлены и правильно настроенные pam-ldap и nss-ldap.

Судя по вашим логам, nss-ldap у вас настроен не верно, так как не может подключиться к лдап серверу.

[CAEman]

А по приведённым ниже портам сервера, полученным с помощью PortScan, можно определить, какие там возможны аутентификация и авторизация?

42 open name

53 open domain

88 open kerberos

135 open epmap

139 open netbios-ssn

389 open ldap

445 open microson-ds

464 open kpasswd

593 open hnp-rpc-epmap

636 open ldaps

1025 open blackjack

1027 open unknawn

1034 open activesync

1038 open mtqp

1048 open neod2

3268 open msn-qc

3269 open msn-qc-ssl

3389 open ms-wbt-server

Нужно, в принципе, только, чтобы Linux просто после первого ввода в окне регистрации DM имени и пароля серверного пользователя автоматически создавал одноимённого локального пользователя с uid и gid, которые стоят у него по умолчанию для вновь создаваемых локальных пользователей, и имеющего такой же доступ к папкам сервера, как и зарегистрированный на сервере пользователь.

Можно ли этого добиться с какой-либо установкой аутентификации + авторизации в Linux'e и без каких-либо изменений на Windows сервере?

[gogi]

CAEman писал(а) Fri, 04 September 2009 16:00

А по приведённым ниже портам сервера, полученным с помощью PortScan, можно определить, какие там возможны аутентификация и авторизация? 42 open name 53 open domain 88 open kerberos 135 open epmap 139 open netbios-ssn 389 open ldap 445 open microson-ds 464 open kpasswd 593 open hnp-rpc-epmap 636 open ldaps 1025 open blackjack 1027 open unknawn 1034 open activesync 1038 open mtqp 1048 open neod2 3268 open msn-qc 3269 open msn-qc-ssl 3389 open ms-wbt-server

В данном случае открыт и ldap и kerberos. Все же в 95% в вендовых сетях вся авторизация в АД. Можно предположить, что у вас так же.

Цитата:

Нужно, в принципе, только, чтобы Linux просто после первого ввода в окне регистрации DM имени и пароля серверного пользователя автоматически создавал одноимённого локального пользователя с uid и gid, которые стоят у него по умолчанию для вновь создаваемых локальных пользователей, и имеющего такой же доступ к папкам сервера, как и зарегистрированный на сервере пользователь. Можно ли этого добиться с какой-либо установкой аутентификации + авторизации в Linux'e и без каких-либо изменений на Windows сервере?

Для этого предназначен winbind, входящий в соcтав samba.

Самба клиент вам нужен в любом случае, если хотите пользоваться сетевыми "папками". Кроме этого нужно настроить pam-winbind для сетевой аутентификации пользователей.

[CAEman]

При попытке настройки через winbind выдаётся сообщение:

This host is not a member of the domain...

Join the domain ...?

После утвердительного ответа и ввода имени и пароля пользователя сервера (естественно, не администратора):

Failed to join domain: Failed to set account flags for machine account (NT_STATUS_ACCESS_DENIDED)

При попытке подключения с того же компьютера, но из-под Windows (c тем же именем комп-а):

В домене "..." обнаружена учётная запись для данного компьютера.

Использовать её?

А после утвердительного ответа и ввода пользователя:

Не удалось присоединить этот компьютер к домену из-за следующей ошибки:

Отказано в доступе

(Хотя он уже присоединён через эту Windows, в которой все загружаются нормально.)

Что нужно делать?

[gogi]

CAEman писал(а) Fri, 04 September 2009 19:20

При попытке настройки через winbind выдаётся сообщение: This host is not a member of the domain... Join the domain ...? После утвердительного ответа и ввода имени и пароля пользователя сервера (естественно, не администратора): Failed to join domain: Failed to set account flags for machine account (NT_STATUS_ACCESS_DENIDED) Что нужно делать?

Для того, чтобы ввести машину в домен АД, нужны права администратора домена. Будет ли winbind полноценно работать без ввода машины в домен, я не знаю и не встречал такой реализации (последний сервер с АД я убрал три года назад).

Могу предложить более простой способ, если он вас устроит. Нужно установить kerberos client. Тогда, получив билет пользователя АД (kinit имя_юзера) вы сможете обращаться к дозволенным вам сервисам: например, смонтировать каталог можно mount.cifs с ключем -k. Далее, если хотите вместо kinit набирать этот паролль при входе в систему, нужно установить и настроить pam_krb5 (в случае реализации MIT). Только имейте в виду, что пользователь также должен быть прописан на этой юникс машине (можно и без пароля: на керберос он будет аутентифицироваться, а uid gid ... получать локально).

Подобная реализация описана, например, здесь

http://www.windowsnetworking.com/articles_tutorials/Authenti cating-Linux-Active-Directory.html

[CAEman]

Задача как раз состоит в том, чтобы, не имея админ-ских прав на Win сервере, предоставить пользователям сервера возможность входить на локальных комп-ах с Linux (естественно, без их предварительного создания в Linux'е - создавать вручную тыщу уже имеющихся и постоянно пополняющихся пользователей - это, сами понимаете, как-то не адекватно...) и, желательно, с доступом к их сетевым папкам.

Это решаемо в принципе? Или без допила этих виней (кому только могло стукнуть в голову сделать на них сервер ) никак не обойтись?

[gogi]

CAEman писал(а) Fri, 11 September 2009 14:46

Задача как раз состоит в том, чтобы, не имея админ-ских прав на Win сервере, предоставить пользователям сервера возможность входить на локальных комп-ах с Linux (естественно, без их предварительного создания в Linux'е - создавать вручную тыщу уже имеющихся и постоянно пополняющихся пользователей - это, сами понимаете, как-то не адекватно...) и, желательно, с доступом к их сетевым папкам. Это решаемо в принципе? Или без допила этих виней (кому только могло стукнуть в голову сделать на них сервер ) никак не обойтись?

Можно разделить два различных уровня интеграции. По правилам MS залогиниться в домене AD можно только с машины, введенной в домен. А ввести машину может администратор домена.

Существует ли способ это обойти - я не знаю. Перерывайте информацию по samba и winbind.

Но пользоваться ресурсами windows сервера (напр. расшареными папками) можно и не вводя машину в домен. Например, если на сервере установлена поддержка старых клиентов (до win2000, насколько я знаю, по умолчанию она стоит) то можно примонтировать ресурс с ntlm аутентификацией

$ mount.cifs ... ... -o user=... password=...

Если в домене оставлена только kerberos аутентификация, то можно поступить, как я писал в прошлый раз (kinit + mount.cifs -k).

Логиниться на юникс машину в этих случаях можно с любым логином (напр. одним для всех, или даже автологином).

[CAEman]

gogi писал(а) Fri, 11 September 2009 17:57

Если в домене оставлена только kerberos аутентификация, то можно поступить, как я писал в прошлый раз (kinit + mount.cifs -k).

Логиниться на юникс машину в этих случаях можно с любым логином (напр. одним для всех, или даже автологином).

Однозначно нужно, чтобы у каждого пользователя, зарегистрированного на сервере, создавался свой локальный профиль при первом входе, которым он в дальнейшем мог пользоваться (я не говорю о сохранении его на сервере - пусть на каждой машине будет свой локальный профиль). Всё, что нужно, - это чтобы Linux при вводе в регистрационном окне графического DM имени и пароля пользователя при отсутствии такого зарегистрированного локального пользователя мог сверить введённые имя и пароль с находящимся на win сервере списком и в случае их наличия и соответсвия, создать такого же (имя и пароль) локального пользователя с настройками по умолчанию для вновь создаваемых и его загрузить (с созданием на /home настроенного по умолчанию профиля, например, из /etc/skel). При повторном же входе пользователя (т.е. при уже наличии такого локального пользователя) Linux'у даже не обязательно обращаться к серверу для проверки (с монтированием же сетевых папок, как я понял, проблем нет).

Достаточно ли я чётко изложил задачу минимума (т.е. нет ли мест, допускающих неоднозначное толкование)? Решаема ли она в принципе, и если - да, то как конкретно? Если не было опыта практического её решения, то, хотя бы - теоретические соображения (с учётом всех описанных мной ранее попыток и результатов её решения).

[gogi]

CAEman писал(а) Fri, 11 September 2009 19:05

Однозначно нужно, чтобы у каждого пользователя, зарегистрированного на сервере, создавался свой локальный профиль при первом входе, которым он в дальнейшем мог пользоваться (я не говорю о сохранении его на сервере - пусть на каждой машине будет свой локальный профиль). Всё, что нужно, - это чтобы Linux при вводе в регистрационном окне графического DM имени и пароля пользователя при отсутствии такого зарегистрированного локального пользователя мог сверить введённые имя и пароль с находящимся на win сервере списком и в случае их наличия и соответсвия, создать такого же (имя и пароль) локального пользователя с настройками по умолчанию для вновь создаваемых и его загрузить (с созданием на /home настроенного по умолчанию профиля, например, из /etc/skel). При повторном же входе пользователя (т.е. при уже наличии такого локального пользователя) Linux'у даже не обязательно обращаться к серверу для проверки (с монтированием же сетевых папок, как я понял, проблем нет). Достаточно ли я чётко изложил задачу минимума (т.е. нет ли мест, допускающих неоднозначное толкование)? Решаема ли оCна в принципе, и если - да, то как конкретно? Если не было опыта практического её решения, то, хотя бы - теоретические соображения (с учётом всех описанных мной ранее попыток и результатов её решения).

Задачу вы изложили достаточно ясно. Конкретно такую же решать не приходилось в силу её специфичности. (Не проще ли бы было обратиться к вендовому админу с просьбой ввести машины в домен).

Тем не менее могу сказать определёно, что задача решаема.

Один путь к решению (наверное, не лучший) я вам укажу.

1. Необходимо найти (скорее всего придется написать самому) модуль nss для базы passwd, чтобы он вёл локальную базу вендовых пользователей и на запросы выдавал uid,gid,shell,home. Если имеете даже небольшие навыки программирования на C, то это вполне решаемая задача.

2. Нужно установить и настроить pam_krb5 или аналогичный модуть для аутентификации в AD. Если он не будет стыковаться с вашим модулем nss, то, возможно, самому написать ещё модуль pam для аутентификации в kerberos,например, на основе вызова kinit.

Вот и выбитайте из четырёх: обратиться к вендовому админу, поискать в сети преемлемое решение, изобрести предложенные мной костыли или забросить эту затею.

По теме можно почитать ещё здесь, но, увы, пароль админа АД там известен.

http://www.cyberguru.ru/operating-systems/windows-admin/linu x-authentication.html

[CAEman]

gogi писал(а) Fri, 11 September 2009 19:54

Нужно установить и настроить pam_krb5 или аналогичный модуть для аутентификации в AD.

Т.е., если я Вас правильно понял, Вы считаете, что у линуксовских модулей kerberos 5 или аналогичных (Winbind, LDAP?) проблем с аутентификацией на виндовском сервере нет? Проблема только в создании новых пользователей по результатам этой аутентификации?

Уточните, пожалуйста.

[gogi]

CAEman писал(а) Fri, 11 September 2009 20:07

Т.е., если я Вас правильно понял, Вы считаете, что у линуксовских модулей kerberos 5 или аналогичных (Winbind, LDAP?) проблем с аутентификацией на виндовском сервере нет? Проблема только в создании новых пользователей по результатам этой аутентификации? Уточните, пожалуйста.

Это относится к pam модулям kerberos и winbind (последний, как вы сами видели, требует ввода машины в домен). Молуль pam_ldap может проходить аутентификацию в openldap или в других лдап каталогах, но НЕ в AD, поскольку аутентификация кербесос и лдап существенно различаются.

[CAEman]

Но в моём случае такая аутентификация пройдёт (по LDAP же не проходила, а openLDAP, судя по всему приведённому там нет, или я ошибаюсь?)?

[gogi]

CAEman писал(а) Fri, 11 September 2009 21:02

Но в моём случае такая аутентификация пройдёт (по LDAP же не проходила, а openLDAP, судя по всему приведённому там нет, или я ошибаюсь?)?

Не ошибаетесь, серверы windows поддерживают аутентификацию kerberos, а также ntlm для совместимости со старыми клиентами. Аутентификация ldap там если и реализуема, то только сторонними средствами.

[CAEman]

gogi писал(а) Fri, 11 September 2009 19:54

1. Необходимо найти (скорее всего придется написать самому) модуль nss для базы passwd, чтобы он вёл локальную базу вендовых пользователей и на запросы выдавал uid,gid,shell,home. Если имеете даже небольшие навыки программирования на C, то это вполне решаемая задача. 2. Нужно установить и настроить pam_krb5 или аналогичный модуть для аутентификации в AD. Если он не будет стыковаться с вашим модулем nss, то, возможно, самому написать ещё модуль pam для аутентификации в kerberos,например, на основе вызова kinit.

1. А нельзя ли этот модуль nss (или его содержание) как-нибудь "подцепить" из winbind (там так всё удобно настраивается в yast2, а к программированию я не имею никакого отношения)?

2. Если я Вас правильно понял из последующих сообщений, упомянутой здесь аналогичной альтернативы kerberos'у оказывается нет (без пароля серверного админ-а). В связи с этим возникает вопрос, а вызов kinit не требует ли получения так называемого "билета" с соответствующим вводом пароля серверного админ-а?

Уточните, пожалуйста.

[gogi]

CAEman писал(а) Fri, 18 September 2009 19:48

1. А нельзя ли этот модуль nss (или его содержание) как-нибудь "подцепить" из winbind (там так всё удобно настраивается в yast2, а к программированию я не имею никакого отношения)?

Не знаю, с winbind не возился.

Цитата:

2. Если я Вас правильно понял из последующих сообщений, упомянутой здесь аналогичной альтернативы kerberos'у оказывается нет (без пароля серверного админ-а). В связи с этим возникает вопрос, а вызов kinit не требует ли получения так называемого "билета" с соответствующим вводом пароля серверного админ-а? Уточните, пожалуйста.

- Может быть, кроме керберос, есть смысл поискать информация о pam_ntlm или pam_samba.

- В результате керберос аутентификации Вы получите tgt билет, выданный пользователю, а для этого достаточно ввода пользовательского пароля.

[CAEman]

А Вы не могли бы тогда дать пошаговое руководство настройки кербероса с кинитом без ввода пароля серверного админ-а?

[gogi]

CAEman писал(а) Fri, 18 September 2009 21:45

А Вы не могли бы тогда дать пошаговое руководство настройки кербероса с кинитом без ввода пароля серверного админ-а?

Только в общих чертах. Детальные руководства, если понадобятся, ищите в гугле. Но, вообще говоря, достаточно и манов.

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

1. Установить клиентскую чать керберос. (в дебиане пакет называется krb5-user, у Вас - что-то похожее).

2. Настроить керберос на REALM из домена AD, напр MYORG.RU редактируя файл конфирурации - krb5.conf.

3. Дать команду

$ kinit имя_пользователя

и после запроса ввести пароль.

В результате вы получите супер билет - tgt, который можно использовать для доступа к ресурсам указанного сервера. Юниксовый юзер (uid, gid) после выполнения пункта 3 не изменится.

[CAEman]

Керберос у меня прекрасно настроился прямо из-под Yast (без всяких дедовских способов, таких как редактирование файлов конфигурации) и выдаёт tgt билет.

А вот дальше начинаются проблемы. В и-нете нашёл только описание авторизации через winbind. Через Yast без ввода машины в домен обойтись нельзя, а значит - это "не для нас". Путём ручного редактирования smb.conf, но без последующего запуска "net ads join", winbind после запуска выдаёт в "messages":

"initialize_winbindd_cache: clearing cache and re-creating with version number 1

winbindd/winbindd_util.c:init_domain_list(740)

Could not fetch our SID - did we join?

winbindd/winbindd.c:main(1285)

unable to initialize domain list"

и выгружается (хотя на некоторых форумах утверждают, что должен работать).

Вы писали, что подсоединялись без winbind с помощью "nss модуля":

"Необходимо найти (скорее всего придется написать самому) модуль nss для базы passwd, чтобы он вёл локальную базу вендовых пользователей и на запросы выдавал uid,gid,shell,home."

Этот модуль настраивается через nsswitch.conf? Среди служб в Yast я ничего связанного с nss, кроме winbind, не нашёл. Не могли бы Вы уточнить название модуля (или привести его содержание), а также более подробно описать его настройку?

Заранее благодарю.

[gogi]

Подобного pam модуля я не встречал и даже не снаю, существует ли

такой. Уж слижком специфична задача. Если не прибегать к

написанию своего модуля, то, видимо, придется от чего-то

отказаться: либо аутентифицироваться в АД всем юзерам с одним и теж же юниксовым uid,

либо узнавать пароль админа АД и использовать

winbind.

[CAEman]

Но Вы писали-то свой модуль?

Или можно ли взять за основу etc\init.d\winbind и, что-то изменив в нём (и что конкретно), добиться нужного результата?

[gogi]

Модуль pam мне приходилось писать совсем для другой задачи.

Стоит ли взять ли за основу pam_winbind - не знаю. Нужно

разбираться с его исходниками.

[gogi]

В догонку.

/etc/init.d/winbind - это всего лишь сценарий запуска winbind.

Его изменение в данном случае ни к чему не приведёт.

[CAEman]

Т.е., если я Вас правильно понял, можно только путём правки исходников для бинарника winbindd, в котором уже забит этот обязательный ввод машины в домен, и последующей их компиляции?

А с помощью создания скриптового модуля (с использованием или без существующего winbindd) никак нельзя добиться желаемого результата?

[gogi]

pam модули традиционно пишутся на C. Естественно, с последующей

компиляцией. Ввод машины в домен, насколько я знаю, это

обязательное условие winbind. Так что правки скриптов здесь не

достаточно.