Видимость LDAP

[Андрей Добров]

Есть возможность ограничить видимость объектов в LDAP от eDirectory?
В идеале чтоб совсем ничего, кроме серверов.
Т.е. ни пользователей ни групп в поиске не отображалось.

[Иван Левшин aka Ivan L.]

Права доступа же. LDAP в eDirectory - просто один из способов организации доступа, если в контексте учетной записи, с которой было установлено соединение (BindDN) нет прав на что-то, это что-то и не будет доступно/видно.

[Андрей Добров]

Права доступа же. LDAP в eDirectory - просто один из способов организации доступа, если в контексте учетной записи, с которой было установлено соединение (BindDN) нет прав на что-то, это что-то и не будет доступно/видно.

Берем софтину Ldap Browser от Softerra.
Имея адрес сервера даже без реплики - подключаемся с правами анонимуса.
Видим все объекты в дереве.
Что самое неприятное, это видимость аккаунтов и групп в которые пользователи входят.
Если учесть что у пользователей и для групп - всегда писались комментарии что это такое и к чему приложить, ситуация несколько неприятная.
Не смог найти на просторах официального предложения. Видел странный пост на немецком форуме что надо поиграться с Public. Но сообщение аж 20 летней давности и ни каких комментариев.
Посмотрел на public..... понял не мой вариант, надо быть супер гуру в eDirectory чтоб не остаться с неработающем каталогом.

[skoltogyan]

Да, Вы правы. надо изменять права у [Public]
в былые времена это описано было так и тут

https://www.novell.com/documentation/edir873/?page=/documentation/edir873/edir873/data/h0000007.html
Connecting to eDirectory from LDAP

All LDAP clients bind (connect) to Novell eDirectory as one of the following types of users:

[Public] User (Anonymous Bind)
Proxy User (Proxy User Anonymous Bind)
NDS or eDirectory User (NDS User Bind)

The type of bind the user authenticates with determines the content that the LDAP client can access. LDAP clients access a directory by building a request and sending it to the directory. When an LDAP client sends a request through LDAP Services for eDirectory, eDirectory completes the request for only those attributes that the LDAP client has the appropriate access rights to.

For example, if the LDAP client requests an attribute value (which requires the Read right) and the user is granted only the Compare right to that attribute, the request is rejected.

Standard login restrictions and password restrictions still apply. However, any restrictions are relative to where LDAP is running. Time and address restrictions are honored, but address restrictions are relative to where the eDirectory login occurred---in this case, the LDAP server.

Connecting As a [Public] User

An anonymous bind is a connection that does not contain a username or password. If an LDAP client without a name and password binds to LDAP Services for eDirectory and the service is not configured to use a Proxy User, the user is authenticated to eDirectory as user [Public].

User [Public] is a non-authenticated eDirectory user. By default, user [Public] is assigned the Browse right to the objects in the eDirectory tree. The default Browse right for user [Public] allows users to browse eDirectory objects but blocks user access to the majority of object attributes.

The default [Public] rights are typically too limited for most LDAP clients. Although you can change the [Public] rights, changing them will give these rights to all users. Because of this, we recommend that you use the Proxy User Anonymous Bind. For more information, see Connecting As a Proxy User.

To give user [Public] access to object attributes, you must make user [Public] a trustee of the appropriate container or containers and assign the appropriate object and attribute rights.

можно запретить для anonymous bind так:

https://support.microfocus.com/kb/doc.php?id=3932155#
Situation
Applied the above eDirectory updates, NLDAP version 10410.87, or higher.
LDAP server is not accepting bind requests from clients.
LDAP appears to load fine.
How to disable anonymous binds in LDAP
How to restrict anonymous binds in LDAP.
Resolution

Make sure the EDIR870x.EXE or EDIR870x.TGZ files are installed on your platform, then use the proper platform specific schema extention utility to extend schema with the LDAP.SCH file and associate the attribute to the LDAP server object. Below are the NetWare, NT and UNIX procedures.
NETWARE:

This should first be run on a RW or Master of Root!


a. From the NetWare Console type "LOAD NWCONFIG" - Select Directory Options - Extend Schema
b. Authenticate as admin or a user with admin rights to root. Change the path by pressing F3 - Specify the location of the LDAP.SCH file in the 8703 patch (\NW\SYS\SYSTEM\SCHEMA
c. Force the schema synch process by running the following commands on the console:

SET DSTRACE=ON
SET DSTRACE=+SCHEMA
SET DSTRACE=*SSD
SET DSTRACE=*SSA
Wait for an "All Processed = Yes" on the Directory Services Screen then continue to the ConsoleOne Section of this TID.
NT:

This should first be run on a RW or Master of Root
a. Choose Start - Control Panel - Novell eDirectory Services - Highlight the INSTALL.DLM module - Click Start
b. Choose "Install additional schema files." - Click Next - Authenticate as Admin or a user with admin rights to root
c. Browse to the LDAP.SCH file contained in EDIR870x.EXE (IE., C:\8703\NT\NDS\LDAP.SCH ) - Click Finish
d. Force a Schema Synch Process from either Novell eDirectory Services - DSTRACE or from iManager DSTRACE.
e. Wait for an "All Processed = Yes" on the Directory Services Screen then continue to the ConsoleOne Section of this TID.
UNIX:

This should be run on a RW or Master of Root then
a. Type the following command:
ndssch /usr/lib/nds-schema/ldap.sch
b. Authenticate as admin or a user with admin rights to root, and type the admin password when prompted.
c. Force the schema synch process by running the following commands on the console:

ndstrace
set dstrace=nodebug
dstrace +scma +scmd
set dstrace=*ssd
set dstrace=*ssa
Wait for an "All Processed = Yes" on the Directory Services Screen then continue with the ConsoleOne section
CONSOLEONE:

Now a new attribute, ldapBindRestrictions, has been added to schema and associated with the LDAP server class. Now we can associate it to our LDAP server and then populate it with a value.
1. Load ConsoleOne
2. Browse to your LDAP server object
3. Right click - Properties - Other Tab
4. Click on the Attribute Add button - Scroll to the ldapBindRestrictions attribute - OK
5. To disable anonymous binds put a value of 1 in the attribute value field. To allow such connections put in a value of 0.
6. Select Apply - OK

Note: In 8.7.1, a property tab is available for this setting to be toggled on or off. Also the schema will automatically extend for this funtion.
Additional Information
This new build of NLDAP (available with the eDirectory 8.7.0.3 and 8.7.0.4 Update) allows for the disabling of anonymous binds. If the schema update file included in the patch, LDAP.SCH, is not run then when the new NLDAP module loads clients will not be able to bind. To accomplish this a new LDAP server attribute, ldapBindRestrictions, needs to be added to eDirectory's schema and associated to the LDAP server object. If NLDAP loads and does not see this attribute either due to not running the new LDAP.SCH included in these patches or schema not having synchcronized to the server then NLDAP will refuse all bind requests.

Formerly known as TID# 10077872
Formerly known as TID# NOVL84851

[Иван Левшин aka Ivan L.]

Сергей все верно описал. [Root] - "все аутентифицированные", [Public] - "все неаутентифицированные", это псевдоклассы. Собственно анонимус - это [Public], кто-то у Вас прав ему дал на корень дерева, скорее всего. Отрезать можно либо Inheritance Rights Filter (IRF), либо прямо удалением назначения. Но со вторым методом надо быть аккуратным, потому как если [Public] вообще оторвать права, пользователи не смогут зайти в сеть, насколько я помню.