Hello I am using freeradius (1.0.1) with SUN directory server (5.2) Authentication (username:password) works well but I do not know how to use LDAP for group mapping (to Ldap-Group). The problem: in SUN DS there are groups defined in two ways (If you use SUN JES system) =================================================== "subscribe group" $ ldapsearch cn=gprs_subscr dn: cn=gprs_subscr,ou=Groups,dc=myorg cn: gprs_subscr objectClass: groupofurls objectClass: groupofuniquenames objectClass: top objectClass: iplanet-am-managed-assignable-group objectClass: iplanet-am-managed-group memberURL: ldap:///dc=myorg??sub?memberof=cn=gprs_subscr,ou=Groups,dc=myorg iplanet-am-group-subscribable: false =================================================== or "filteredgroup" =================================================== $ ldapsearch cn=gprs_filter dn: cn=gprs_filter,ou=Groups,dc=myorg cn: gprs_filter objectClass: groupofurls objectClass: groupofuniquenames objectClass: top objectClass: iplanet-am-managed-filtered-group objectClass: iplanet-am-managed-group memberURL: ldap:///dc=myorg??sub?(&(uid=k*)(o=mysuborg)) =================================================== How should I set groupmembership_filter or how should I use do_xlat (I probably misunderstand the feature) Thanks for any help -- Petr Klíma e-mail: qaxi@seznam.cz
Petr "Qaxi" Klíma wrote:
Hello
I am using freeradius (1.0.1) with SUN directory server (5.2)
Authentication (username:password) works well but I do not know how to use LDAP for group mapping (to Ldap-Group).
The problem:
in SUN DS there are groups defined in two ways (If you use SUN JES system)
=================================================== "subscribe group" $ ldapsearch cn=gprs_subscr dn: cn=gprs_subscr,ou=Groups,dc=myorg cn: gprs_subscr objectClass: groupofurls objectClass: groupofuniquenames objectClass: top objectClass: iplanet-am-managed-assignable-group objectClass: iplanet-am-managed-group memberURL: ldap:///dc=myorg??sub?memberof=cn=gprs_subscr,ou=Groups,dc=myorg iplanet-am-group-subscribable: false ===================================================
or
"filteredgroup" =================================================== $ ldapsearch cn=gprs_filter dn: cn=gprs_filter,ou=Groups,dc=myorg cn: gprs_filter objectClass: groupofurls objectClass: groupofuniquenames objectClass: top objectClass: iplanet-am-managed-filtered-group objectClass: iplanet-am-managed-group memberURL: ldap:///dc=myorg??sub?(&(uid=k*)(o=mysuborg)) ===================================================
How should I set groupmembership_filter or how should I use do_xlat (I probably misunderstand the feature)
The FreeRADIUS ldap module supports *static* ldap groups. These groups are implemented either as a group entry containing member DN's or as a group membership attribute in the user entries. What you are looking for (evaluating the memberURL attribute during group evaluation) cannot be done in an efficient way. The memberURL is mostly an informational attribute used when browsing groups. You will have to use one of the two methods supported for ldap groups to work. Dynamic groups are costly and should be implemented on the ldap server side.
Thanks for any help
Kostas Kalevras napsal(a):
Petr "Qaxi" Klíma wrote:
"filteredgroup" =================================================== $ ldapsearch cn=gprs_filter dn: cn=gprs_filter,ou=Groups,dc=myorg cn: gprs_filter objectClass: groupofurls objectClass: groupofuniquenames objectClass: top objectClass: iplanet-am-managed-filtered-group objectClass: iplanet-am-managed-group memberURL: ldap:///dc=myorg??sub?(&(uid=k*)(o=mysuborg)) ===================================================
How should I set groupmembership_filter or how should I use do_xlat (I probably misunderstand the feature)
The FreeRADIUS ldap module supports *static* ldap groups. These groups are implemented either as a group entry containing member DN's or as a group membership attribute in the user entries. What you are looking for (evaluating the memberURL attribute during group evaluation) cannot be done in an efficient way. The memberURL is mostly an informational attribute used when browsing groups.
Hmm .. SUN Java Enterprise server is using it as authoritative user<>group mapping ...
You will have to use one of the two methods supported for ldap groups to work. Dynamic groups What methods?
groupofuniquenames and ... ???
are costly and should be implemented on the ldap server side.
How to do it? Are there any suggestions (there are other DS which uses souch group "filtering" (SUN,Netscape,RedHat (they are from the same nest), but Apache DS too ...)
-- Petr Klíma e-mail: qaxi@seznam.cz
Petr "Qaxi" Klíma wrote:
Kostas Kalevras napsal(a):
Petr "Qaxi" Klíma wrote:
"filteredgroup" =================================================== $ ldapsearch cn=gprs_filter dn: cn=gprs_filter,ou=Groups,dc=myorg cn: gprs_filter objectClass: groupofurls objectClass: groupofuniquenames objectClass: top objectClass: iplanet-am-managed-filtered-group objectClass: iplanet-am-managed-group memberURL: ldap:///dc=myorg??sub?(&(uid=k*)(o=mysuborg)) ===================================================
How should I set groupmembership_filter or how should I use do_xlat (I probably misunderstand the feature)
The FreeRADIUS ldap module supports *static* ldap groups. These groups are implemented either as a group entry containing member DN's or as a group membership attribute in the user entries. What you are looking for (evaluating the memberURL attribute during group evaluation) cannot be done in an efficient way. The memberURL is mostly an informational attribute used when browsing groups.
Hmm .. SUN Java Enterprise server is using it as authoritative user<>group mapping ...
This is moving away from being a freeradius configuration issue. Implementing group evaluation through memberURL means that we have to run the corresponding query on each group lookup. That's as costly as the number/2 of entries present on each group hence it will take a lot of time and will polute the ldap server caches with not necessary entries. Group lookup is already quite costly as it is so i don't think implementing memberURL can add something. Also IMHO evaluating memberURL is the ldap server's job not the radius server.
You will have to use one of the two methods supported for ldap groups to work. Dynamic groups
What methods?
groupofuniquenames and ... ???
And a group membership attribute in the user entry like memberOf
are costly and should be implemented on the ldap server side.
How to do it? Are there any suggestions (there are other DS which uses souch group "filtering" (SUN,Netscape,RedHat (they are from the same nest), but Apache DS too ...)
You could probably acieve what you are looking for with Class Of Service in the SUN One Directory Server
participants (2)
-
"Petr \"Qaxi\" Klíma" -
Kostas Kalevras