Несколько вопросов по LUM

[Константин Ошмян]

Приветствую!

Попробовал поставить на стенде Linux User Management (LUM) - посмотреть, что это такое, чтобы научиться с этим работать. Вроде бы - всё запустилось и работает (пользователи логинятся, домашние директории создаются), но возникли некоторые вопросы. Буду благодарен, если кто-нибудь пояснит.

1. В качестве Linux-а использовался лабораторный сервер, поставленный с дистрибутива OES SP2. При начальной установке была выбрана минимальная конфигурация (т.е. безо всяких там новелловских примочек типа eDirectory, iFolder, NSS и т.д. - только SLES9). Насколько я понимаю из доки, для успешного логина в дерево NDS (живущее на отдельном лабораторном сервере NetWare 6.5 SP5) мне нужно на Линукс поставить только пакет novell-lum. Он, в свою очередь, требует ещё двух пакетов - NLDAPbase и NLDAPsdk; ладно - всего три. Однако, почему-то при установке этого novell-lum-а YaST у меня потребовал поставить ещё кучу всякого добра, которое я ставить совсем не собирался - NDSBase, novell-imanager с множеством всяких novell-iManчего-то-там (что, в свою очередь, повлекло установку apache2 и novell-tomcat4) и т.д.
Это так и было задумано или же просто мне не повезло?

2. При установке задавались вопросы про некоего Proxy user-а. В документации он описан как-то бедно: сказано просто, что от его имени производится поиск по дереву через LDAP, и всё. А ведь его пароль прописывается в открытом виде в /etc/nam.conf, да ещё доступ к этому файлу - 0644, т.е. разрешён на чтение всем желающим.
Какие же права и на что именно нужны этому пользователю?
И кому именно и какие нужны права на файл nam.conf?

3. Если на LDAP-сервере (напомню, у меня им работает NW6.5SP5 c eDirectory 8.7.3.7) попытаться помониторить, какие запросы приходят с Линукса, то наблюдается нечто непонятное. Сначала (после старта namcd) происходят вещи понятные - как и описано в документации, идёт поиск объектов UNIX Config, UNIX Workstation, групп, пользователей (для обновления кэша) и т.п. О вот потом - почему-то постоянно лезут какие-то запросы на поиск, хотя никакой активности на Линуксе в это время (вроде попыток логина) не происходит. Устанавливается соединение, делается три поиска, разрывается соединение - и так 24 раза в минуту (т.е. в среднем каждые 2,5 секунды). Для чего? Или это у меня что-то не так настроено?

Вот пример одного фрагмента. На сервере делаем:

Код: Выделить всё

dstrace
dstrace -all
dstrace +ldap
dstrace file on

ровно через минуту - dstrace file off. В результате в SYS:SYSTEM\DSTRACE.LOG имеем 24 раза примерно следующее:

Код: Выделить всё

DoUnbind on connection 0x8ae72ee0
New TLS connection 0x8ae729a0 from 192.168.0.80:36875, monitor = 0x1c4, index = 3
Connection 0x8ae72ee0 closed
Monitor 0x1c4 initiating TLS handshake on connection 0x8ae729a0
DoTLSHandshake on connection 0x8ae729a0
Completed TLS handshake on connection 0x8ae729a0
DoBind on connection 0x8ae729a0
Bind name:cn=lumproxy,o=oes, version:3, authentication:simple
Sending operation result 0:"":"" to connection 0x8ae729a0
DoSearch on connection 0x8ae729a0
Search request:
   base: "cn=UNIX Workstation - itm1,ou=lum-ws,o=oes"
   scope:0  dereference:0  sizelimit:0  timelimit:0  attrsonly:0
   filter: "(objectclass=*)"
   attribute: "groupMembership"
Sending search result entry "cn=UNIX Workstation - itm1,ou=lum-ws,o=oes" to connection 0x8ae729a0
Sending operation result 0:"":"" to connection 0x8ae729a0
DoSearch on connection 0x8ae729a0
Search request:
   base: "cn=lum-test,o=oes"
   scope:0  dereference:0  sizelimit:0  timelimit:0  attrsonly:0
   filter: "(objectclass=*)"
   attribute: "cn"
   attribute: "gidNumber"
Sending search result entry "cn=lum-test,o=oes" to connection 0x8ae729a0
Sending operation result 0:"":"" to connection 0x8ae729a0
DoSearch on connection 0x8ae729a0
Search request:
   base: "cn=lum-test,o=oes"
   scope:0  dereference:0  sizelimit:0  timelimit:0  attrsonly:0
   filter: "(objectclass=posixGroup)"
   attribute: "uniqueMember"
Sending search result entry "cn=lum-test,o=oes" to connection 0x8ae729a0
Sending operation result 0:"":"" to connection 0x8ae729a0

(в данном случае lum-test - это Linux-enabled группа). Искомые объекты и атрибуты через LDAP данным пользователем (а также анонимно) видны.

Что с этим делать?

4. А существует ли аналог LUM для других *NIX-систем? Интересует, в первую очередь, SUN Solaris и IBM AIX.

Заранее спасибо.

[Андрей Тр. aka RH]

2. При установке задавались вопросы про некоего Proxy user-а. В документации он описан как-то бедно: сказано просто, что от его имени производится поиск по дереву через LDAP, и всё. А ведь его пароль прописывается в открытом виде в /etc/nam.conf, да ещё доступ к этому файлу - 0644, т.е. разрешён на чтение всем желающим.
Какие же права и на что именно нужны этому пользователю?

Вообще, LDAP proxy user - это реинкарнация Public, в обычном объекте класса user. Можно права урезать и посильнее - в зависимости от ваших нужд, выдать их только на конкретные атрибуты / объекты - к которым будет необходим доступ по LDAP. Есть вот такой ТИД - What is an LDAP proxy user? ( в котором, кстати, написано : "Important note: A proxy user must have a blank password in order to work correctly. This is very different from having NO password. If any user has no password, then they do not have a public/private key pair to compare against when attempting login. A blank password will generate a public/private key pair, although the actual string for the password is empty.". У нас этому пользователю пароль все-таки назначен непустой ). И есть еще вот такая статейка : Creating an LDAP proxy user object ( но это уже про прописывание proxy user в свойствах LDAP server ).

[Константин Ошмян]

Андрей, спасибо за ответ!

Похоже, что мы про разных Proxy Users говорим. В данных тобой ссылках речь идёт о прокси-юзере, который прописывается в свойствах объекта "LDAP GROUP - имя_сервера" и используется при анонимном доступе по LDAP. Я же спрашивал про того прокси-юзера, который создаётся и настраивается при установке LUM - судя по приведённому логу, он и в самом деле используется LUM-ом при LDAP-поиске; но этот поиск идёт не анонимно, а после явной привязки именно этим пользователем:

DoTLSHandshake on connection 0x8ae729a0
Completed TLS handshake on connection 0x8ae729a0
DoBind on connection 0x8ae729a0
Bind name:cn=lumproxy,o=oes, version:3, authentication:simple
Sending operation result 0:"":"" to connection 0x8ae729a0
DoSearch on connection 0x8ae729a0
[...и так далее]

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

На самом деле, с правами я разобрался - надо было просто внимательно посмотреть на то, какие права оказались назначенными в моём тестовом дереве после установки LUM. Оказалось интересно:

1) созданному при установке LUM прокси-пользователю lumproxy в дереве не назначено вообще никаких прав (кроме стандартных - на самого себя)

2) права, которыми он реально пользовался, проистекали из прав, назначенных объекту [Public]. Вот их перечень (вдруг кому пригодится) :
на корень дерева:
- [Entry Rights] - Browse
- CN - Compare,Read
На объект Organization (он был указан в качестве base-name при установке LUM) тоже было выдано право Browse на сам объект, а также права Compare и Read на следующие атрибуты:
- Description
- gecos
- gidNumber
- homeDirectory
- loginShell
- memberUid
- uamPosixSalt
- uamPosixWorkstationContext
- uamPosixWorkstationList
- uidNumber
Все права - наследуемые (т.е. с галочкой "Inheritable").

3) как результат - в настройках LUM-а можно вообще убрать (закомментировать) строчки про прокси-юзера - в этом случае LDAP-поиск ведётся с анонимной привязкой, в результате чего LDAP-сервером используются права, назначенные [Public]-у (перечисленные выше, фактически - те же, которыми пользовался LUM Proxy User). Всё работает:

DoTLSHandshake on connection 0x8ae72540
Completed TLS handshake on connection 0x8ae72540
DoBind on connection 0x8ae72540
Treating simple bind with empty DN and no password as anonymous
Bind name:NULL, version:3, authentication:simple
Sending operation result 0:"":"" to connection 0x8ae72540
DoSearch on connection 0x8ae72540
Search request:
[...и так далее]

А из первоначальных вопросов наиболее актуальными остались вопросы 3 и 4. По вопросу 3 - народ, у кого стоит LUM - проверьте у себя, пожалуйста: это только у меня такое или так и должно быть? А по вопросу 4 - это, наверное, к официальным продавцам надо...

[psix]

по поводу других систем есть на Coolsolution как потавить на sles 9

[Константин Ошмян]

по поводу других систем есть на Coolsolution как потавить на sles 9

Это я читал. В двух словах: берёте rpm от OES (SLES), ставите, настраиваете.

Я имел в иду совсем другие системы - не-Linux: например, SUN Solaris (SPARC & x86), IBM AIX, HP PA_RISC.

[Константин Ошмян]

В общем, я так понял, что раз никто не отзывается - то, видимо, аналога LUM для не-Linux платформ (Solaris, AIX, HP-UX) пока нет, а если и есть - то глубоко законспирированные.

Тогда остаётся открытым только вопрос номер три.

Народ! У кого установлен LUM - можете у себя посмотреть? Если Linux-станция настроена ходить по LDAP к серверу NetWare, то помониторьте в течение минуты LDAP-трафик. Для этого на консоли сервера NetWare надо набрать

Код: Выделить всё

dstrace
dstrace -all
dstrace +ldap
dstrace file on

а через минуту -

Код: Выделить всё

dstrace -all
dstrace file off
unload dstrace

Будет ли у Вас так же, как и у меня, в файле SYS:SYSTEM\DSTRACE.LOG просматриваться, что от одной и той же рабочей станции (под Linux c LUM-ом) было два десятка соединений (при том, что на этой рабочей станции никто в это время ничего не делал)

Заранее спасибо.

[Алексей Волков]

В общем, я так понял, что раз никто не отзывается - то, видимо, аналога LUM для не-Linux платформ (Solaris, AIX, HP-UX) пока нет, а если и есть - то глубоко законспирированные.

Был такой продукт "Account Management 3.0". Возможно, что там что-то есть...