Anonymous_User Absent Member.
Absent Member.
3031 views

eDirectory: restrict access to one object

Possibly a stupid question, but anyway: I have OES on SLES9 running for
authentication services to a samba PDC running on the very same machine
as well as several Linux clients using ldap-pam. The eDirectory contains
an object which I need for the PDC, but which I do not want the Linux
machines to have read access to.
From the manuals it does not become apparent to me how to accomplish
this: will I have to reconfigure the clients or is it possible to
restrict the access to an entry in the eDirectory on the server side,
for example allow read access for specific IPs only?

Günther
Labels (2)
0 Likes
8 Replies
Brunold Rainer
New Member.

Re: eDirectory: restrict access to one object

Günther,

so does that sles 9 server have vmware installed where you run those systems in a virtual environment ?

What type of edirectory object is that ?

How do you think those users are able to access or read that object ? Do you think about anonymous access to that object or about authenticated access ?

Do they have some rights to do that or are they in the same container and edirectory rights a inherited to them ?

Rainer
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: eDirectory: restrict access to one object

brunold wrote:
> Günther,
>
> so does that sles 9 server have vmware installed where you run those
> systems in a virtual environment ?


There are several Xen virtual machines running, but the majority of
systems are conventional 'real' systems. It is a small office network.

> What type of edirectory object is that ?


A privileged user I need for administration of the samba PDC.

> How do you think those users are able to access or read that object ?
> Do you think about anonymous access to that object or about
> authenticated access ?


All Linux clients use anonymous access only, e.g. my own entry as seen
from the client:
# ldapsearch -x -LLL "(cn=schwarz)"
dn: cn=schwarz,ou=USERS,o=MYCOMPANY
uamPosixSalt: Fy
loginShell: /bin/bash
homeDirectory: /nfs/home/schwarz
gecos: Guenther Schwarz
gidNumber: 602
mail: Guenther.Schwarz@mycompany.invalid
uidNumber: 527
uid: schwarz
givenName:: R8OUIXI=
sn: schwarz
ou:: VGhlb3JldGlzY2GVycGh5c2lr
objectClass: posixAccount
objectClass: uamPosixUser
objectClass: inetOrgPerson
objectClass: Top
objectClass: organizationalPerson
objectClass: Person
objectClass: ndsLoginProperties
objectClass: sambaSamAccount
objectClass: sambaAccount
groupMembership: cn=users,ou=USERS,o=MYCOMPANY
cn: schwarz


> Do they have some rights to do that or are they in the same container
> and edirectory rights a inherited to them ?


All clients in the subnet have read access to o=MYCOMPANY. From
/etc/ldap.conf:

base o=MYCOMPANY
pam_password nds
nss_initgroups_ignoreusers sambaadmin,ldap
nss_schema rfc2307bis
nss_map_attribute uniqueMember member
ssl start_tls
ldap_version 3
pam_filter objectclass=posixAccount
nss_base_passwd o=MYCOMPANY
nss_base_shadow o=MYCOMPANY
nss_base_group o=MYCOMPANY
tls_checkpeer no

Here sambaadmin is the special user I do not want the Linux clients to
have access to. Despite the nss_initgroups_ignoreusers entry I get:

# ldapsearch -x -LLL "(cn=sambaadmin)"
dn: cn=sambaadmin,o=MYCOMPANY
loginShell: /bin/bash
homeDirectory: /home/sambaadmin
gidNumber: 600
nspmPasswordPolicyDN: cn=Samba Default Password Policy,cn=Password
Policies,cn
=Security
uidNumber: 600
uid: sambaadmin
[...]
cn: sambaadmin

As a consequence sambaadmin can login on any machine in the network
which is unwanted and a potential security issue.

Günther
0 Likes
Brunold Rainer
New Member.

Re: eDirectory: restrict access to one object

Guenther,

I would use imanager to browse to the sambaadmin user and check the trustees of that object. There should be some Public rights set which are provided for users that are not authenticated. When you compare them with what you can see when you run a anonymous ldap search should be nearly the same.

If htis is the case an option might be to just remove those public rights. Please note them before eleting sou you can restore them if they are needed anywhere.

If those are not equal or similar it might be the case that ldap uses a proxy user which has more rights. So an anonymous user would inherit the rights of that proxy user and see more then the public rights show.

Can you check those public rights ?

Rainer
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: eDirectory: restrict access to one object

brunold wrote:
> Guenther,
>
> I would use imanager to browse to the sambaadmin user and check the
> trustees of that object. There should be some Public rights set which
> are provided for users that are not authenticated. When you compare
> them with what you can see when you run a anonymous ldap search should
> be nearly the same.
>
> If htis is the case an option might be to just remove those public
> rights. Please note them before eleting sou you can restore them if
> they are needed anywhere.
>
> If those are not equal or similar it might be the case that ldap uses a
> proxy user which has more rights. So an anonymous user would inherit the
> rights of that proxy user and see more then the public rights show.
>
> Can you check those public rights ?


Thanks for your suggestions which seem to put me on the right track:

Roles and Tasks
Rights
Modify Trustees
(search object) sambaadmin.MYCOMPANY
[Public] assigned rights

Oject name: sambaadmin
Trustee name: [Public]

gives a list of read/write/modify checkboxes for cn, homeDirectory,
uidnumber etc. If I disable read access to uidnumber as an example I can
still see it from the Linux clients even after waiting overnight for
nscd to reload:

# ldapsearch -x -LLL "(cn=sambaadmin)" | grep uid
uidNumber: 600

But then I do find an object ldap_proxy.MYCOMPANY which is used as a
proxy user (section LDAP options in iManager). So the task seems now to
tell ldap_proxy not to distribute the attributes of sambaadmin. I have
no idea how to accomplish this 🙂

Sorry for posting silly questions. I did not set up this OES myself and
I do consider it to be overly complicated for the small and simple
network it provides a LDAP for.

Günther
0 Likes
Brunold Rainer
New Member.

Re: eDirectory: restrict access to one object

Günther,

you can add a inherited rights filter to the sambaadmin that should prevent it from being found by the ldapsearch command.

Open iManager, browse to the object adn then select to modify the inherited rights filter. There you can add a filter for each attribute of the user (eg. uid) and then remove the read right (so it will be filtered). After that apply the changes and run the ldap search again.

Rainer
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: eDirectory: restrict access to one object

brunold wrote:
> Günther,
>
> you can add a inherited rights filter to the sambaadmin that should
> prevent it from being found by the ldapsearch command.
>
> Open iManager, browse to the object adn then select to modify the
> inherited rights filter. There you can add a filter for each attribute
> of the user (eg. uid) and then remove the read right (so it will be
> filtered). After that apply the changes and run the ldap search again.


Thanks once more. That's what I tried now:

Rights
Modify enherited rights filter
(search object) sambaadmin.MYCOMPANY
add
UID - uncheck 'read' box

And that is the result on the client side:

ldapsearch -x -LLL "(cn=sambaadmin)" | grep uid
uidNumber: 600
uid: sambaadmin

Also disabling read access to CN and uniqueID has seemingly no effect.

😕

Günther
0 Likes
Brunold Rainer
New Member.

Re: eDirectory: restrict access to one object

Günther,

can you try the same for the attribute uidnumber ? I just want to make sure that we do not have the problem because of ldap to edirectory attribute mapping. The edirectory attribute uidnumber is mapped to the ldap attribute uidNumber.

First remove just the read and write options, then use the ldapsearch again to see if something has changed. If nothing has changed, remove the other options as well and see ig then something has changed.

By the way, rereading your post about the public rights, you wrote

... gives a list of read/write/modify checkboxes for cn, homeDirectory, uidnumber etc.
...

You know that a anonymous user get's that public rights and you assigned it write and modify to that attributes ? So I can change them without having to authenticate to the edirectory ! I can rename all your users without a login !

Rainer
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: eDirectory: restrict access to one object

brunold wrote:
> Günther,
>
> can you try the same for the attribute uidnumber ?


Bingo, that works 🙂
Rights
Modify Inherited Rights Filter
(search) sambaadmin.MYCOMPANY
Add Property
Show all properties in schema
uidNumber [ ] read

Check on client:
ldapsearch -x -LLL "(cn=sambaadmin)" | grep uid
uid: sambaadmin

So I can't see the Linux uid anymore. Note that I still need the entry
in the Trustees part. If I check the 'read' box there I can see the uid
with ldapsearch despite the Rights Filter defined as above.

> I just want to make
> sure that we do not have the problem because of ldap to edirectory
> attribute mapping. The edirectory attribute uidnumber is mapped to the
> ldap attribute uidNumber.


Obviously there is a problem. But then I won't touch this mapping unless
I absolutely have to.

> By the way, rereading your post about the public rights, you wrote
>
> .. gives a list of read/write/modify checkboxes for cn, homeDirectory,
> uidnumber etc.
> ..
>
> You know that a anonymous user get's that public rights and you
> assigned it write and modify to that attributes ? So I can change them
> without having to authenticate to the edirectory ! I can rename all
> your users without a login !


For
Trustee name: [Public]
only the 'read' boxes are checked, of course. The configuration is,
where ever possible, from default values, and people at Novell won't be
that stupid (though they managed to mess up attributes for the iManager
files in the Open Workgroup Server SBS. But then I do not use this
product, and this is completely unrelated to my question).

Thanks again. Your help is very much appreciated.

Günther
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.