Re: [Fedora-directory-users] Ideas for fds - roles / forward groups [Auf Viren geprüft]
by Frerk.Meyer＠Edeka.de
I hate to leave this most interesting discussion but I'm going on vacation
and I won't be able to follow it for the next weeks. But I'll be back.
I think the most important work in the near future is to promote the
nsroles and make it a standard in the OSS ( hoping for OpenLDAP to adopt
it)
before we get some other de-facto Industry Standard.
Frerk Meyer
EDEKA Aktiengesellschaft
GB Datenverarbeitung
Frerk Meyer
CC Web Technologien
New-York-Ring 6
22297 Hamburg
Tel: 040/6377 - 3272
Fax: 040/6377 - 41268
mailto:frerk.meyer@edeka.de
18 years, 10 months
RE: [Fedora-directory-users] Ideas for fds - roles / forward groups [Auf Viren geprüft]
by Frerk.Meyer＠Edeka.de
ns* attribute names:
Yes, it is a good habit to mark proprietary attributes. The trouble
is to change the name afterwards is cumbersome. Every application
which does not make the role attribute name configurable has to be changed
and compiled again. Nevertheless ist would we right thing to do.
Since it is a virtual attribute anyway the LDAP server may for some time
generate two attributes with name nsrole and ldapRole or something,
documenting nsrole as deprecated.
Roles for authorization in LDAP:
Yes, I admit it: I wanted to mention ACIs as an example of using
nsrole for authorization but for the sake of simplicity I deleted what
I had written because in ACIs you may use group membership
to and mix both. So the names are misleading anyways: You
may use roles for group definition and groups for authorization
via ACIs as well.
Java-LDAP Interface: too simple, too narrow
In fact I was really surprised how bad the interface of the
Sun Java App Server 7 to the Sun Directory Server 5.x
is: Suns App Server JNDIRealm isn't able to use nsroles but
Tomcat 5.x is able to do it (I havent't looked at AppServer 8).
Both are very limited since they cannot
use ACIs to define Java security. They even cannot lookup the
roles after authenticaton, so changes are ignored.
I wrote my own security realm so java applications can use
ACIs to dynamically define authorization. But it is not integrated
with the J2EE Security Manager, my Java knowledge isn't enough
and maybe it isn't possible at all.
Frerk Meyer
EDEKA Aktiengesellschaft
GB Datenverarbeitung
Frerk Meyer
CC Web Technologien
New-York-Ring 6
22297 Hamburg
Tel: 040/6377 - 3272
Fax: 040/6377 - 41268
mailto:frerk.meyer@edeka.de
18 years, 10 months
[Fedora-directory-users] roles and access control
by Gary Mann
a question: we have a requirement where only users that have a role are
able to see role membership. so if i have role A, i can see the
membership for role A (search on nsRole=<roleA>) but cannot necessarily
see role B members, etc. the same restriction applies when pulling the
nsRole attribute.
is there any way (via aci) to support this? i've implemented a plugin
(actually 2 - a computed attribute and preop) that supports this but
wanted to make sure that i wasn't missing something in aci setup that
would accomplish the same thing.
Thanks,
Gary
18 years, 10 months
Re: [Fedora-directory-users] Ideas for fds - roles / forward groups [Auf Viren geprüft]
by Frerk.Meyer＠Edeka.de
LDAP groups and LDAP roles: pro LDAP roles, but call them forward groups
and use them
The naming is a misfortune: nsrole = netscape roles
First because they have their proprietary origin in the name.
Second because most applications use LDAP groups to determine
application roles, and LDAP roles are just another kind of group
definition but no roles at all. They became roles by interpreting them
in an application for authorization.
In SQL/RDBMS only newbies make the mistake to try to represent
a 1:n relation by storing all primary keys of B in a record of A.
SQL records are not multivalued so this mistake does not happen
that much. Everone learned to do it the other way around.
But in LDAP this mistake is the standard for groups. And people
adhere to it because it is the 'STANDARD'.
Static LDAP roles do it like in every RDBMS, so it's right but
non standard. I should become standard IMHO.
OpenLDAP has no roles because it implements the standard.
Netscape/Sun/FDS implement roles but nobody uses it because
it is not the standard.
But in MS-ADS - as I learned here - there is an attribute in every entry
representing group memberships. So they set their own standard,
as usual.
If the OSS community doesn't start to use the roles feature, soon
we will have to adhere to the MS standard and use ADS.
Frerk Meyer
EDEKA Aktiengesellschaft
GB Datenverarbeitung
Frerk Meyer
CC Web Technologien
New-York-Ring 6
22297 Hamburg
Tel: 040/6377 - 3272
Fax: 040/6377 - 41268
mailto:frerk.meyer@edeka.de
18 years, 10 months
Re: [Fedora-directory-users] Ideas for fds - Tree DNs, roles [Auf Viren geprüft]
by Frerk.Meyer＠Edeka.de
On the topic of Tree DN as groups - evil or not - :
My application does not depend on the DN of the
person which is logged in. Instead it just depends on
application roles. BUT: I have implemented some
of the application roles by using LDAP roles inherited in the tree and
some by LDAP groups. The LDAP adapter (JNDIRealm
from Tomcat) unifies group membership and attribute values
to application roles. So I save administrative work with roles.
If an application role is identitical to some struture in the
DIT I save administrative work by using LDAP roles.
If the application role is orthogonal to the structure of the DIT
or I have exceptions I have to use static groups.
If in the future I cannot go on with LDAP roles I can change to
LDAP groups without changing the application.
If I don't use the tree structure in the DIT at all, it'll come
through the back door where I need dozends of groups which
mimic the trees in the end like
company_a_user
company_a_departement_b_user
company_a_department_b_subdivsion_c_user
and that's not really better.
Or how do you organize your groups?
A subtree is a topological group. It was meant so in the beginning
in X.500. If implementations don't support changes of that topology
it's not an argument against the concept.
I guess the problem lies deeper. If the use of (all sophisticated)
LDAP functions is to complicated to application developers,
the development plattforms need an LDAP adapter which abstracts
users and roles. It's like an object/relational mapping to escape
from doing SQL/JDBC by hand for every SQL-dialect out there.
Frerk Meyer
EDEKA Aktiengesellschaft
GB Datenverarbeitung
Frerk Meyer
CC Web Technologien
New-York-Ring 6
22297 Hamburg
Tel: 040/6377 - 3272
Fax: 040/6377 - 41268
mailto:frerk.meyer@edeka.de
18 years, 10 months
Re: [Fedora-directory-users] Ideas for fds [Auf Viren geprüft]
by Frerk.Meyer＠Edeka.de
Actually there are more kinds of 'groups' in a FDS / Netscape/ Sun LDAP
Directory Server
than just group entries:
1) Treenodes / Entry DN
Every node defines a group of its subnodes and leaves.
If a person entries is under some organisation and organisationunit nodes,
it is member of the organisations and organisationalunits. Membership
can be deduced from the DN of that entry. Search all person in a subtree
are the member of that 'group'
2) Classical static groups
A group entry has a multivalued attributes with references (DNs) of all
members.
Best for the question: who are the members of a group
Worst for the question: to which groups does an entry belong
3) 'Reverse' or 'forward referencing' groups aka NSroles
A person entry has multivalued attribute with references (DNs) to all group
(role) entries
it is member of.
Best for the question: to which groups does an entry belong (the most often
used case!)
Worst for the question: who are the members of a group (if no clever
indexing/caching)
4) Simple 'group' attribute
Some simple entry attribute holds the names of all groups/roles an entry is
member of.
There is no special entry for that group or entry, just membership by name.
'Department'
are something similiar is a candidate for this.
5) Filtered Groups/ Roles
Most flexible membership through arbitrary matching criteria through
LDAP search string (beware of the performance!)
6) Hierarchical groups/roles
Groups or Roles which may contain other groups or roles
So in this broader sense LDAP-Clients/Applications should get smarter and
have
should have a more flexible configuration,
or they should use adapters which abstract the whole LDAP-Server like in
Security-Reams of Java Application Servers where the source for
authorization
and authentication can be exchanged with a database or property file.
Fropm my experience the Apache Jakarta Tomcat 5.5.7 supports NSRoles in its
JNDIRealm out of the box even without mentioning it. It combines the
membership
in LDAP Groups AND LDAP Roles to provide an application with the sum as
Java/Application roles.
I implemented my own custom Realm according to the JAAS standard and
therefore
I'm able even to interpret filtered and hierarchical groups/roles and hide
them
from the application. It is possible to use the declarative Access Control
Instructions
in a java application, which is not possible with standard realms.
But as long as someone has to support some closed source, braindead, legacy
code with an over-simplified LDAP connection I would be against curring
that disease
on the server-side, perpetuing the problem into the future and encouraging
those
implementations even in future developments.
Instead some kind of LDAP-Proxy-Super-Adapter comes to my mind: it would
use and understand all those variations of groups and present them to an
application
as being a classical static group. It would be very configurable in every
aspect.
Otherwise I'm afraid to much of application logic moves into the directory
server like PL/SQL only for LDAP.
Frerk Meyer
EDEKA Aktiengesellschaft
GB Datenverarbeitung
Frerk Meyer
CC Web Technologien
New-York-Ring 6
22297 Hamburg
Tel: 040/6377 - 3272
Fax: 040/6377 - 41268
mailto:frerk.meyer@edeka.de
18 years, 10 months
Antwort: Re: [Fedora-directory-users] Ideas for fds [Auf Viren geprüft]
by Frerk.Meyer＠Edeka.de
>>1) Treenodes / Entry DN
>Right. But then moving an entry from one group to another becomes
>problematic. Even if the server supports the modrdn or subtree rename
>operation, it can be a problem for apps that expect the entry DN not to
>change.
Most applications first search the DN of a person by its uid (or email
adress or cn) so the DN
may vary.
Second I currently use the hierarchical approach because NSroles are
inherited along
the tree. So if the user help desk creates a user in the right tree leave,
they automatically
get the roles inherited they need for our applications. No manual
administration of static groups
needed. I wouldn't even need NSroles, if all node names would be translated
to Java/Applications-Roles
in the Java-World.
It would be really great if a moved person would belong to the same groups
and roles
afterwards. Today I correct it manually and have to write a tool that does
it automatically.
>>3) 'Reverse' or 'forward referencing' groups aka NSroles
>>Best for the question: to which groups does an entry belong (the most
often
>>used case!)
>Is this really the most often used case? Which applications use this
case?
Every Java Application I know of. For a use rto login there is always this
sequence:
- anonymous bind to search the users DN from uid
- try to bind with DN and password
- if success get all group memberships of this user:
o search all group entries where the DN is member
o read attribute NSRoles
o return the sum of both as java/application-roles
Tomcat returns the LDAP group membership as their 'cn' and
the NSroles membership with their 'dn'. Only my LoginRealm is able to
return both by their 'cn'.
Another wish: rename nodes which have leaves.
Frerk Meyer
EDEKA Aktiengesellschaft
GB Datenverarbeitung
Frerk Meyer
CC Web Technologien
New-York-Ring 6
22297 Hamburg
Tel: 040/6377 - 3272
Fax: 040/6377 - 41268
mailto:frerk.meyer@edeka.de
18 years, 10 months
[Fedora-directory-users] Ideas for fds
by Jeff Clowser
One of those things I always had a love/hate relationship with in the
Netscape/Sun directory server was dynamic lists.
Loved 'em because you could create email lists and aci groups that were
self maintaining based on ldap filter criteria.
Hated 'em because no third party app's knew how to use them - most apps
see groups as groupofmembers or groupofuniquemembers with a list of dn's
in member/uniquemember.
It would be nice to have a dynamic group like Netscape's groupOfUrls
(i.e. an ldap url defines members), but have the members returned to
clients as uniquemembers of the group. In this way, you could create
dynamic groups that are much more useful.
For example, if I created:
cn: hr users
objectclass: top
objectclass: groupofuniquenames
objectclass; groupofurls
memberurl: ldap:///<basedn>??sub?(department=hr)
...
and did a search to retrieve it, the people that match the memberurl
would be returned dynamically as uniquemember values.
Issues I see with this:
1. Server load - if I have a lot of these groups and do a search that
returns all groupofurl entries, it could take a lot of resources to
generate that dynamically.
2. Assuming this is inherited from groupofuniquenames, what happens if
I add static members to uniquemember? I would say return the merged
list. How do we know if a value is static or dynamic, to do things like
removing a static member? We don't, but this is similar to the issues
using class of service where attributes are dynamically added.
(Actually, would it be possible to implement this using class of
service? Hmmm...)
- Jeff
18 years, 10 months
[Fedora-directory-users] Hello! Fedora-directory build error
by sang jun song
OS : Solaris 5.8 (SPAC)
Compiler: gcc (3.3)
make: GNU Make 3.80
I build External Requirement. and success.
but building the LDAP source occured error.
CVSROOT=:pserver:anonymous@cvs.fedora.redhat.com:/cvs/dirsec ; export
CVSROOT
cvs login => OK
cvs -z3 co -r FedoraDS71_20050526_RTC ldapserver
=> OK
error
==================================================================
#make NS_USE_GCC=1 USE_PERL_FROM_PATH=1 BUILD_DEBUG=full
cat: cannot open ./SOLARIS/buildnum.dat
nsconfig.mk:1578: modules.mk: No such file or directory
re-making ./modules.mk ...
cat: cannot open ./SOLARIS/buildnum.dat
if test ! -d SOLARIS; then mkdir SOLARIS; fi;
/SunONE/perl2exe/perl5/bin/perl buildnum.pl -p SOLARIS
NSOS_RELEASE is: 5.8
/SunONE/perl2exe/perl5/bin/perl pumpkin.pl 120 pumpkin.dat
if test ! -d ./built/SOLARIS-domestic-full-normal-slapd; then mkdir -p
/built/SOLARIS-domestic-full-normal-slapd; fi;
if test ! -d ./built/SOLARIS-domestic-full-normal-slapd/include; then
mkdir -p ./built/SOLARIS-domestic-full-normal-slapd/include; fi;
/SunONE/perl2exe/perl5/bin/perl dirver.pl -v "7.1" -o
built/SOLARIS-domestic-full-normal-slapd/include/dirver.h
if test ! -d ./built/SOLARIS-domestic-full-normal-slapd/include; then
mkdir -p ./built/SOLARIS-domestic-full-normal-slapd/include; fi;
/SunONE/perl2exe/perl5/bin/perl dirver.pl -v "3.1" -o
built/SOLARIS-domestic-full-normal-slapd/include/sdkver.h
The components are up to date
==== Starting LDAP Server ==========
gmake NO_JAVA=1 nsCommon
gmake[1]: Entering directory `/SunONE/ldap/ldapserver'
cd config; gmake NO_JAVA=1 export SERVER_BUILD=1 XCFLAGS=
USE_PTHREADS= NS_PRODUCT=DIRECTORY_SERVER VERSION= NS_USE_NATIVE=
NSPR_BASENAME=libnspr21 DIST=
OBJDIR=/SunONE/ldap/ldapserver/built/SOLARIS-domestic-full-normal-slapd
FASTTIME_HEADER_DEST=/SunONE/ldap/ldapserver/built/SOLARIS-domestic-full
-normal-slapd/include
FASTTIME_TARGET_DEST=/SunONE/ldap/ldapserver/built/SOLARIS-domestic-full
-normal-slapd
NSINSTALL=/SunONE/ldap/ldapserver/built/SOLARIS-domestic-full-normal-sla
pd/nsinstall
gmake[2]: Entering directory `/SunONE/ldap/ldapserver/config'
gcc -Wall -Wno-format -o
/SunONE/ldap/ldapserver/built/SOLARIS-domestic-full-normal-slapd/nsinsta
ll.o -c -DXP_UNIX -g -DSVR4 -DSYSV -DNSPR -D__svr4 -D__svr4__ -DSOLARIS
-DHAVE_WEAK_IO_SYMBOLS -DNSPR20 -D_PR_NTHREAD -D_REENTRANT
-D_SVID_GETTOD -DSOLARIS_55_OR_GREATER -MDupdate
/SunONE/ldap/ldapserver/built/SOLARIS-domestic-full-normal-slapd/.md
-DDEBUG -UNDEBUG -DDEBUG_root -DTRACING -DSERVER_BUILD -DNETSCAPE
-DLAYERS -DUNIX_EMBED -DX_PLUGINS -DUNIX_LDAP -DNSPR -DNSPR20
-I../include -I/usr/dt/include -I/usr/openwin/include -I/usr/dt/include
-I/usr/openwin/include nsinstall.c
gcc: cannot specify -o with -c or -S and multiple compilations
gmake[2]: ***
[/SunONE/ldap/ldapserver/built/SOLARIS-domestic-full-normal-slapd/nsinst
all.o] Error 1
gmake[2]: Leaving directory `/SunONE/ldap/ldapserver/config'
gmake[1]: *** [nsCommon] Error 2
gmake[1]: Leaving directory `/SunONE/ldap/ldapserver'
make: *** [buildDirectory] Error 2
========================================================================
===========
How can I sovled this a problem?
Help me.
<http://www.korea.com>
<http://event.korea.com/main/moviepreview.asp>
18 years, 10 months
[Fedora-directory-users] Windows Sync over SSL problem
by Brian Peters
Hi all,
I'm having problems setting up a Windows Sync Agreement in the FDS.
Here's the situation:
I've set up my Active Directory server on a Windows 2000 Server box with
an SSL connection using a self-signed cert. I then installed FDS on a
Fedora Core 3 box and set that up with an SSL connection, again using a
self-signed cert. I installed the AD cert into the FDS database with
trusted peer status. These machines are on the same network with no
firewalls or anything in between.
I tested out the connection using ldapsearch on the FDS box using simple
authentication over SSL, and I was able to query the Active Directory
perfectly fine.
The next step was to set up the Windows Sync Agreement. You have to
turn on changelog and replication first, so I did so, choosing Single
Master replication. In the Windows Sync Agreement wizard, I filled in
all the fields and saved the agreement.
When the replicator fired up, all the Active Directory entries sync'ed
perfectly fine with the FDS server (i.e. I was able to query FDS and see
the sync'ed AD entries). The problem was that the status of the Windows
sync showed that it was still syncing. So basically, it wouldn't
attempt to sync again and the server wouldn't shut down cleanly because
it thought it was still syncing. I tried setting up Windows sync over
the non-SSL port, and it works perfectly fine.
So, I did some digging into this and this is what I was able to
determine. After the sync begins, I took a look at netstat on both the
FDS and AD servers, and it showed an ESTABLISHED connection between a
random port on FDS and the ldaps port on AD. The connection stayed
ESTABLISHED for about 15 minutes (keep in mind that it took seconds to
actually do the sync). After 15 minutes, the AD side showed a socket
state of FIN_WAIT_2 and the FDS side went to CLOSE_WAIT. After a couple
more minutes, the socket connection disappeared from the AD side, but
the FDS side stayed in CLOSE_WAIT. I think the longest I let it sit was
just over an hour or so, and neither the sync status in FDS nor the
socket state changed.
I also took a look at a tcpdump of the AD sync from the FDS machine,
which showed a normal-looking transfer, but the first FIN,ACK was issued
by the AD machine 15 minutes after the initial connection. Comparing
this to a tcpdump of an ldapsearch, the first first FIN,ACK is sent from
the FDS box, which is followed by a FIN,ACK from the AD, and so on. So,
it seems that the AD side is expecting a FIN,ACK, but after 15 minutes
it gives up waiting, sends a FIN,ACK and gets out of there.
I'm basically stuck at this point, and just wondering if anyone else has
seen this behavior and/or has any suggestions. Thanks in advance.
- Brian
18 years, 10 months
