Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Viewing attributes in LDAP

6 views
Skip to first unread message

Jay Hendry

unread,
Jan 19, 2004, 6:46:54 AM1/19/04
to
Hi

We are trying to get a RADIUS server, as part of a login, to check if a
user is a member of a specific group. This should be possible using the
memberOf attribute from a Netware LDAP server. When we look at the
available attributes visible to the RADIUS box this is not one of them. If
we look at the LDAP server using Softerra's LDAP browser we can confirm
that the attribute cannot be seen. How can we make additional attributes
visible under the LDAP server?

Thanx

Jay

AndersG

unread,
Jan 19, 2004, 7:21:37 AM1/19/04
to
Jay Hendry,

> How can we make additional attributes
> visible under the LDAP server?
>
If you can see those from an LDAP browser, but nit from RADIUS, then I
suspect a rights issue. What an LDAP client can see depends on his
rights. What is the RADIUS box logging in as?

- Anders Gustafsson, Engineer, CNE6, ASE
NSC Volunteer Sysop (http://support-forums.novell.com)
Pedago, The Aaland Islands (N60 E20)
Using VA 4.52 build 277 (32-bit) on Windows 2000 build 2195

Jay Hendry

unread,
Jan 19, 2004, 8:08:19 AM1/19/04
to
AndersG <dal...@nomail.to.me> wrote in news:VA.0000461e.012dfc13
@nomail.to.me:

Hi

No the attribute can't be seen either at the LDAP browser or at the
RADIUS. What do we change to give rights to specific attributes please?

Thanx

Jay

AndersG

unread,
Jan 19, 2004, 8:27:10 AM1/19/04
to
Jay Hendry,

> No the attribute can't be seen either at the LDAP browser or at the
> RADIUS. What do we change to give rights to specific attributes please?

Those are governed by DS rights. Ie what that user can see. What version
of DS/eDir?

Jay Hendry

unread,
Jan 19, 2004, 8:56:15 AM1/19/04
to
AndersG <dal...@nomail.to.me> wrote in
news:VA.0000462...@nomail.to.me:

Hi

eDir 8.6.2 with ds.nlm 10350.23, nldap.nlm 10350.15

Thanx

Jay

AndersG

unread,
Jan 19, 2004, 1:40:22 PM1/19/04
to
Jay Hendry,

> eDir 8.6.2 with ds.nlm 10350.23, nldap.nlm 10350.15
>
OK. Should be no problems there. Just make sure the user you use for
logins have read rights to that attribute.

Jay Hendry

unread,
Jan 20, 2004, 4:09:49 AM1/20/04
to
AndersG <dal...@nomail.to.me> wrote in news:VA.00004622.00496209
@nomail.to.me:

Hi again

Thats the bit we can't find the solution to - cant seem to find anything
in C1. Any pointers to a TID or anything would sure help.

Thanx

Jay

AndersG

unread,
Jan 20, 2004, 5:17:39 AM1/20/04
to
Jay Hendry,

> Thats the bit we can't find the solution to - cant seem to find anything
> in C1. Any pointers to a TID or anything would sure help.
>
Where is this user relative to the users you want to check the group
membership of? If in the same OU or above, then they should already have
those rights. If not, then highligt the top ou where users are, rightclick,
trustees.

Add trustees, select user, Add property, group membership and give read and
compare.

- Anders Gustafsson, Engineer, CNE6, ASE

Jay Hendry

unread,
Jan 21, 2004, 5:19:39 AM1/21/04
to
AndersG <dal...@nomail.to.me> wrote in
news:VA.0000463...@nomail.to.me:

Hi again

This is the setup.

The LDAP server and LDAP group exist in a subcontext one level down from
the root. They are part of our iChain and Portal installation and both
objects appear to only have one or two trustees. Admin from the root
context does not show up as having any rights to them?

We have users in contexts one level down from root but these are in
different contexts to the LDAP objects.

Currently the RADIUS server is setup to bind using the user name of the
user who we want to check their group membership. This does not seem to
work. I have tried setting the group that these users are a member of to
have trustee rights to the LDAP group object again without success.

Thanx

Jay

AndersG

unread,
Jan 21, 2004, 5:48:29 AM1/21/04
to
Jay Hendry,

> Currently the RADIUS server is setup to bind using the user name of the
> user who we want to check their group membership.
>
That should definitely work. Are you sayinmg it does the LDAP bind as that
used (as opposed to an anonymous bind), but then fails to read the group
membership?
0 new messages