proNovell

Есть nw 6.5, стандартный apache сервер, создал дополнительный каталог, установил параметры доступа
Тип с управляемым доступом: Auth LDAP Module
Использовать права eDirectory
Базовое имя DN для поиска: o=ctx
Атрибут поиска: CN
Область поиска: Поддерево
Защищенный LDAP: Да
Сертификат: sys:\public\RootCert.der
Тип лицензии: Der File
Нет

всё перезапустил и обнаружил, что просмотр пользователей ниже чем корневой контекст не происходит, а именно если пользователь создан непосредственно в o=ctx, то всё работает, а вот если он находиться в контейнере ниже уровнем, то залогиниться не возможно.
Подскажите гуру, можно ли это как-то побороть.

Заранее спасибо за совет.

В conf файле посмотри, в правильное ли место в строке контекста попала *, обозначающая поиск в подкаталогах.

Вот кусок конфига:
# SOURCE OBJECT: cn=MUSIC:-Directory,cn=NWEB,cn=NetWare Group,cn=Apache Group,o=контекст

<Directory MUSIC:>
AddDefaultCharset cp866
Options Indexes Multiviews
AllowOverride None
Order deny,allow
Allow from all
AuthType Basic
AuthName "Protected"
AuthLDAPAuthoritative On
AuthLDAPURL ldaps://nweb.ru/o=контекст?cn?sub
require edir-user
</Directory>
# TABLE: (3)

Вообще то ключевое слово это sub И оно у вас есть

AuthLDAPURL ldaps://nweb.ru/o=контекст?cn?sub

если вместо sub поставить one то искать по подконтекстам не будет

Попробуйте написать так

AuthLDAPURL ldaps://nweb.ru/o=контекст?cn

или

AuthLDAPURL ldaps://nweb.ru/?cn

Михаил, попробывал предложенные Вами способы, результат тот же.

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

Как раз сейчас занимаюсь тем же самым - LDAP аутентификацией апача. Вот хороший тид, http://support.novell.com/cgi-bin/searc ... 059954.htm особенно вот это - CONFIGURE DSTRACE TO VIEW RESULTS: как настроить DSTRACE, чтобы посмотреть результат поиска и ошибки.
Но я столкнулся с другой проблемой. С момента появления NDS, Novell декларировала, что Ivanov.buh.org1.corp и Ivanov.econ.org101.corp это совершенно разные объекты и вот теперь этим Ивановым надо попасть в защищенную часть корпоративного сайта, впрочем как и многим другим из org2, org3... org100. Поиск по uid, cn затыкается на одинаковых именах. Может кто нибудь направит на путь истинный?

Орлов Алексей писал(а)::?:

Если указать
AuthLDAPURL ldaps://my.ldap.server/o=org?cn?sub
то пользователи с одинаковым cn, расположенные в разных контекстах аутентифицироваться не могут.

да нет Андрей, я понял вопрос. Нужно подумать...

LDAPOpCacheEntries 0
<Directory volume:/data/secret/tred>
Options Indexes Multiviews
AllowOverride All
Order allow,deny
Allow from all
AuthType Basic
AuthName "Protected"
AuthLDAPEnabled on
AuthLDAPBindDN cn=ldapproxy,o=corp
AuthLDAPBindPassword password
require group cn=tredg,ou=fff,o=corp
AuthLDAPAuthoritative On
AuthLDAPURL ldap://hren.firma.ua/o=corp?cn?sub
</Directory>

Где:
1. tredg - группа куда вкючате тех, кто должен иметь доступ
2. hren.firma.ua - имя хоста, где расположен Ваш сервер .
3. ldapproxy - ldapproxy юзер
4. password - пароль пользователя ldapproxy
5. AuthLDAPURL ldap://hren.firma.ua/o=corp?cn?sub - говорит о том, ЧТО ИСКАТЬ от o=corp и дальше.
6. LDAPOpCacheEntries 0 - говорит о том, что надо КАЖДЫЙ РАЗ смотреть в LDAP имеет этот юзер право или нет на ресурс, как юзер будет обращаться. Без этого ответ от LDAP сервера будет закеширован и как следствие возможна ситуатция - Вы убрали пользователя из группы tredg, а он все еще имеет доступ

А если охото без require group cn=tredg,ou=fff,o=corp



Что вполне логично! Не писать же 1000 юзеров в эту группу, это маразм полный!

Попробывал я описанный способ.
Содал пользователя в корне, дал права на чтение и просмотр, результата не получил, решил всё же остановиться на добавлении пользователей, кому нужно.
Цель этого была такая. Доступ к данным прекрасно работает средствами netstorage, но некоторые мои пользователи любят слушать музон через web, по средствам муз. проигрывателей, т.к. netstorage что-то не позволяет это делать, а вот способ через apache позволяет. Баловство это конечно

Вот результат проверки на полигоне.

Alias /test "SYS:/tmp/html/"
LDAPOpCacheEntries 0
<Directory "SYS:/tmp/html">
Options Indexes Multiviews
AllowOverride All
Order allow,deny
Allow from all
AuthType Basic
AuthName "Protected"
AuthLDAPEnabled on
# AuthLDAPBindDN cn=ldapproxy,o=corp
# AuthLDAPBindPassword password
require group cn=admingrp,o=yaa
AuthLDAPURL ldap://my.ldap.org/o=yaa?cn?sub

Пользователи admin.yaa и user01.u.yaa включены в группу admingrp.yaa также имеются пользователи admin.u.yaa и user00.u.yaa
AuthLDAPBindDN не используется, необходимые права даны паблику.

Последовательные попытки аутентифицироваться под admin, user00 и user01 привели к успеху только в последнем случае:

[2005/12/14 15:05:01] Search request:
base: "o=yaa"
scope:2 dereference:3 sizelimit:0 timelimit:0 attrsonly:0
filter: "(&(objectclass=*)(cn=admin))"
attribute: "cn"
[2005/12/14 15:05:02] Sending search result entry "cn=admin,o=yaa" to connection 0x4013a1c0
[2005/12/14 15:05:02] Sending search result entry "cn=admin,ou=U,o=yaa" to connection 0x4013a1c0
[2005/12/14 15:05:02] Sending operation result 0:"":"" to connection 0x4013a1c0
[2005/12/14 15:05:12] DoSearch on connection 0x4013a1c0

[2005/12/14 15:05:12] Search request:
base: "o=yaa"
scope:2 dereference:3 sizelimit:0 timelimit:0 attrsonly:0
filter: "(&(objectclass=*)(cn=user00))"
attribute: "cn"
[2005/12/14 15:05:12] Sending search result entry "cn=User00,ou=U,o=yaa" to connection 0x4013a1c0
[2005/12/14 15:05:12] Sending operation result 0:"":"" to connection 0x4013a1c0
[2005/12/14 15:05:12] DoBind on connection 0x4013a1c0
[2005/12/14 15:05:12] Bind name:cn=User00,ou=U,o=yaa, version:3, authentication:simple
[2005/12/14 15:05:12] Sending operation result 0:"":"" to connection 0x4013a1c0
[2005/12/14 15:05:12] DoBind on connection 0x4013a1c0
[2005/12/14 15:05:12] Treating simple bind with empty DN and no password as anonymous
[2005/12/14 15:05:12] Bind name:NULL, version:3, authentication:simple
[2005/12/14 15:05:12] Sending operation result 0:"":"" to connection 0x4013a1c0
[2005/12/14 15:05:12] DoCompare on connection 0x4013a1c0
[2005/12/14 15:05:12] compare: dn (cn=admingrp,o=yaa) attr (member) value (cn=User00,ou=U,o=yaa)
[2005/12/14 15:05:12] Sending operation result 5:"":"" to connection 0x4013a1c0
[2005/12/14 15:05:12] DoCompare on connection 0x4013a1c0
[2005/12/14 15:05:12] compare: dn (cn=admingrp,o=yaa) attr (uniquemember) value (cn=User00,ou=U,o=yaa)
[2005/12/14 15:05:12] Sending operation result 5:"":"" to connection 0x4013a1c0
[2005/12/14 15:05:25] DoSearch on connection 0x4013a1c0

[2005/12/14 15:05:25] Search request:
base: "o=yaa"
scope:2 dereference:3 sizelimit:0 timelimit:0 attrsonly:0
filter: "(&(objectclass=*)(cn=user01))"
attribute: "cn"
[2005/12/14 15:05:25] Sending search result entry "cn=User01,ou=U,o=yaa" to connection 0x4013a1c0
[2005/12/14 15:05:25] Sending operation result 0:"":"" to connection 0x4013a1c0
[2005/12/14 15:05:25] DoBind on connection 0x4013a1c0
[2005/12/14 15:05:25] Bind name:cn=User01,ou=U,o=yaa, version:3, authentication:simple
[2005/12/14 15:05:25] Sending operation result 0:"":"" to connection 0x4013a1c0
[2005/12/14 15:05:25] DoBind on connection 0x4013a1c0
[2005/12/14 15:05:25] Treating simple bind with empty DN and no password as anonymous
[2005/12/14 15:05:25] Bind name:NULL, version:3, authentication:simple
[2005/12/14 15:05:25] Sending operation result 0:"":"" to connection 0x4013a1c0
[2005/12/14 15:05:25] DoCompare on connection 0x4013a1c0
[2005/12/14 15:05:25] compare: dn (cn=admingrp,o=yaa) attr (member) value (cn=User01,ou=U,o=yaa)
[2005/12/14 15:05:25] Sending operation result 6:"":"" to connection 0x4013a1c0

Как видим, при аутентификации под админом до проверки членства в группе даже не дошло.

а у Вас в дереве один объект с названием admin ?