Re: [Freeipa-users] ldap-filter, LDAP_MATCHING_RULE_IN_CHAIN, apache 2.2
On 03/21/2013 09:04 AM, Jan-Frode Myklebust wrote: Serverdefault has a hack for supporting nested groups on RHEL5/apache-2.2 involving a ldap filter using LDAP_MATCHING_RULE_IN_CHAIN on Active Directory, ref: http://serverfault.com/a/424706 Does anybody know if a similar filter can be created for an with IPA/389ds backend ? In IPA/389 each user has a full list of the DNs of the groups he is a member of. Also the member attribute in the group is the list of DNs of all members and member groups. IPA/389 supports a dereference control. But the question is: what are you trying to accomplish? If you need to check whether the user is a member of the group it is a simple search using member attribute as a filter. -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ldap-filter, LDAP_MATCHING_RULE_IN_CHAIN, apache 2.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/21/2013 09:04 AM, Jan-Frode Myklebust wrote: Serverdefault has a hack for supporting nested groups on RHEL5/apache-2.2 involving a ldap filter using LDAP_MATCHING_RULE_IN_CHAIN on Active Directory, ref: http://serverfault.com/a/424706 Does anybody know if a similar filter can be created for an with IPA/389ds backend ? Just as an FYI (slightly off-topic), we discovered in SSSD that the problem with this approach on Active Directory is that the matching rule searches are not indexed, so on large AD deployments it can take seconds (sometimes tens of seconds) to return the results. FreeIPA's solution is much simpler and more elegant. When group memberships are stored in the server, we create backlinks at save-time. All users contain an attribute 'memberOf' that automatically handles nestings. So if GroupB is a member of GroupA and UserC is a member of GroupB, then UserC will have: memberOf: cn=GroupB,... memberOf: cn=GroupA,... So you can always get the complete list of groups a user belongs to with: ldapsearch connection_args -H ldap://ipaserver.example.com \ -b user_dn -s base (objectClass=*) memberOf Or the complete set of users in a group with: ldapsearch connection_args -H ldap://ipaserver.example.com \ -b user_search_base \ ((objectClass=posixUser)(memberOf=cn=groupname,...)) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFMTB4ACgkQeiVVYja6o6PFcgCgmVVlXHup70Ecnm8OcY4VIhYr yJUAnRlyDeJ3HA+WveLT0WrQw/I0IqZZ =H/Yx -END PGP SIGNATURE- ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ldap-filter, LDAP_MATCHING_RULE_IN_CHAIN, apache 2.2
This works: Require ldap-attribute memberof=cn=cactiaccess,cn=groups,cn=accounts,dc=example,dc=net but only if I also provide a username/password for apache to bind as. Doesn't work with unauthenticated binds. -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ldap-filter, LDAP_MATCHING_RULE_IN_CHAIN, apache 2.2
On 03/22/2013 09:12 AM, Jan-Frode Myklebust wrote: This works: Require ldap-attribute memberof=cn=cactiaccess,cn=groups,cn=accounts,dc=example,dc=net but only if I also provide a username/password for apache to bind as. Doesn't work with unauthenticated binds. -jf Because anonymous binds are rightly turned off by default, you can turn them on on the server but this is a security risk as well as storing passwords in the file. You need to assess what is the least of two evils for your environment. The best would have been for apache to support GSSAPI for that matter but based on the link you sent this is not the case. IMO you should file and RFE for them to support GSSAPI bind and not only bind with the password. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ldap-filter, LDAP_MATCHING_RULE_IN_CHAIN, apache 2.2
On Fri, Mar 22, 2013 at 09:59:14AM -0400, Dmitri Pal wrote: Because anonymous binds are rightly turned off by default, They are? I don't think I've ever explicitly turned on anonymous binds, and my directories are open to anonymous searches. The confusing thing is that not all attributes are available when doing anonymous binds. Are there any way to configure how open we want the directory to be? The best would have been for apache to support GSSAPI for that matter but based on the link you sent this is not the case. IMO you should file and RFE for them to support GSSAPI bind and not only bind with the password. Newer apache supports nested groups, and all the needed attributes for that seems to be available trough anonymous binds.. so no GSSAPI is needed (for us) there. IMHO it's seems inconsistent that memberOf attribute is hidden for anonymous searches on the user, but member attribute on groups is not. Same information, different places in the tree. -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ldap-filter, LDAP_MATCHING_RULE_IN_CHAIN, apache 2.2
On 03/22/2013 10:20 AM, Jan-Frode Myklebust wrote: On Fri, Mar 22, 2013 at 09:59:14AM -0400, Dmitri Pal wrote: Because anonymous binds are rightly turned off by default, They are? I don't think I've ever explicitly turned on anonymous binds, and my directories are open to anonymous searches. The confusing thing is that not all attributes are available when doing anonymous binds. Are there any way to configure how open we want the directory to be? I thought you are using IPA or DS and in the latest versions we turned that off. The best would have been for apache to support GSSAPI for that matter but based on the link you sent this is not the case. IMO you should file and RFE for them to support GSSAPI bind and not only bind with the password. Newer apache supports nested groups, and all the needed attributes for that seems to be available trough anonymous binds.. so no GSSAPI is needed (for us) there. IMHO it's seems inconsistent that memberOf attribute is hidden for anonymous searches on the user, but member attribute on groups is not. Same information, different places in the tree. Sounds like it does not understand 2307bis schema and assumes only 2307 which is very limiting in group membership aspect. -jf -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ldap-filter, LDAP_MATCHING_RULE_IN_CHAIN, apache 2.2
Dmitri Pal wrote: On 03/22/2013 10:20 AM, Jan-Frode Myklebust wrote: On Fri, Mar 22, 2013 at 09:59:14AM -0400, Dmitri Pal wrote: Because anonymous binds are rightly turned off by default, They are? I don't think I've ever explicitly turned on anonymous binds, and my directories are open to anonymous searches. The confusing thing is that not all attributes are available when doing anonymous binds. Are there any way to configure how open we want the directory to be? I thought you are using IPA or DS and in the latest versions we turned that off. We don't disable anonymous binds by default. We do suppress memberOf for anonymous searches. The best would have been for apache to support GSSAPI for that matter but based on the link you sent this is not the case. IMO you should file and RFE for them to support GSSAPI bind and not only bind with the password. Newer apache supports nested groups, and all the needed attributes for that seems to be available trough anonymous binds.. so no GSSAPI is needed (for us) there. IMHO it's seems inconsistent that memberOf attribute is hidden for anonymous searches on the user, but member attribute on groups is not. Same information, different places in the tree. Sounds like it does not understand 2307bis schema and assumes only 2307 which is very limiting in group membership aspect. -jf ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ldap-filter, LDAP_MATCHING_RULE_IN_CHAIN, apache 2.2
On 03/22/2013 11:01 AM, Rob Crittenden wrote: Dmitri Pal wrote: On 03/22/2013 10:20 AM, Jan-Frode Myklebust wrote: On Fri, Mar 22, 2013 at 09:59:14AM -0400, Dmitri Pal wrote: Because anonymous binds are rightly turned off by default, They are? I don't think I've ever explicitly turned on anonymous binds, and my directories are open to anonymous searches. The confusing thing is that not all attributes are available when doing anonymous binds. Are there any way to configure how open we want the directory to be? I thought you are using IPA or DS and in the latest versions we turned that off. We don't disable anonymous binds by default. On the new installs? I thought we do. We do suppress memberOf for anonymous searches. Interesting. Good to know. The best would have been for apache to support GSSAPI for that matter but based on the link you sent this is not the case. IMO you should file and RFE for them to support GSSAPI bind and not only bind with the password. Newer apache supports nested groups, and all the needed attributes for that seems to be available trough anonymous binds.. so no GSSAPI is needed (for us) there. IMHO it's seems inconsistent that memberOf attribute is hidden for anonymous searches on the user, but member attribute on groups is not. Same information, different places in the tree. Sounds like it does not understand 2307bis schema and assumes only 2307 which is very limiting in group membership aspect. -jf -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ldap-filter, LDAP_MATCHING_RULE_IN_CHAIN, apache 2.2
On Fri, 2013-03-22 at 15:20 +0100, Jan-Frode Myklebust wrote: On Fri, Mar 22, 2013 at 09:59:14AM -0400, Dmitri Pal wrote: Because anonymous binds are rightly turned off by default, They are? I don't think I've ever explicitly turned on anonymous binds, and my directories are open to anonymous searches. The confusing thing is that not all attributes are available when doing anonymous binds. Are there any way to configure how open we want the directory to be? The best would have been for apache to support GSSAPI for that matter but based on the link you sent this is not the case. IMO you should file and RFE for them to support GSSAPI bind and not only bind with the password. Newer apache supports nested groups, and all the needed attributes for that seems to be available trough anonymous binds.. so no GSSAPI is needed (for us) there. Using SSSD would probably be a better bet, you get caching for free and *much* lower latency when stuff is in the mmap cache. IMHO it's seems inconsistent that memberOf attribute is hidden for anonymous searches on the user, but member attribute on groups is not. Same information, different places in the tree. The reason we suppress memberof is that we use grouping for more than just posix groups memberships. We use it also for delegation, HBAC, Roles and sudo rules, so to avoid leaking information about privileges a user may have it was decided to block memberof for unauthenticated binds. The reasoning was that clients that can take correctly advantage of freeipa's memberof can also authenticate in a secure way. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
