Re: [Freeipa-users] SSS problems with eDirectory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/23/2010 06:15 PM, Simo Sorce wrote: On Fri, 23 Jul 2010 17:17:11 -0400 Scott Duckworth sduc...@clemson.edu wrote: I've learned that this attribute does exist in our tree, but it's not being populated when we add users to groups since our proxy user does not have rights to write groupMembership to users. I'm trying to find out if we can get our hands on native eDirectory tools that keep groupMembership of posixAccount and member of posixGroup in sync. Still, if groupOf/groupMembership is not required by rfc2307bis, it would be nice if SSSD did not require it. Yes, we should handle this gracefully, at least through an option. If a user has a groupOf/groupMembership attribute pointing to a group outside of ldap_group_search_base, will this be handled gracefully? Yes, the entry will simply be ignored if not resolvable. Simo. I was discussing this with Dmitri this morning. I propose that we should probably do the following: After retrieving the user entry, verify whether the entry contains at least one memberOf attribute. If it does, continue processing as we do now (since it will be more efficient). If not, then we should slip into compatibility mode where we will search all groups for member=userdn Does this seem sensible? - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxNjp8ACgkQeiVVYja6o6MkagCfRVK6+fEOs/3PUp2HiGeACu4g iWYAoKkgwvH5wJooMh1MCuyUewrbu692 =vwp8 -END PGP SIGNATURE- ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] SSS problems with eDirectory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/23/2010 05:45 PM, Scott Duckworth wrote: On Thu, Jul 22, 2010 at 5:24 PM, Sumit Bose sb...@redhat.com I can prepare a special build for you which prints the LDAP_OPT_DIAGNOSTIC_MESSAGE LDAP option and let you use wireshark. But I'm afraid this has to wait until tomorrow, it's nearly half to midnight, here. That may be useful to others, too. Why not put it in the production build? I have just built a scratch build in Koji containing two additional patches: 1) Print the LDAP_OPT_DIAGNOSTIC_MESSAGE as Sumit suggested. This patch will likely go upstream, as you are correct that it is very useful. 2) Custom for you, there is a patch included that will allow you to perform auth unencrypted, so you can examine the wire data. This patch will NOT go upstream, since we really don't want people doing this in the real world. Please try the build available at http://koji.fedoraproject.org/koji/taskinfo?taskID=2351272 (it will only be available for about two weeks from today) - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxNj2UACgkQeiVVYja6o6MhZQCdEUKpx2R0DSA1ARLQmwqlPpyh Rv0AoKnIfR2ZkaNziIHpvHPaZ7i3cIeR =k+lz -END PGP SIGNATURE- ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] SSS problems with eDirectory
On Mon, 26 Jul 2010 09:33:22 -0400 Stephen Gallagher sgall...@redhat.com wrote: I was discussing this with Dmitri this morning. I propose that we should probably do the following: After retrieving the user entry, verify whether the entry contains at least one memberOf attribute. If it does, continue processing as we do now (since it will be more efficient). If not, then we should slip into compatibility mode where we will search all groups for member=userdn Does this seem sensible? yes and no. Actually we should really have a switch that tells us whether we fully trust memberof to give us the complete picture (IPA case) or if we should use it only as a hint (AD and servers that do not use memberof at all). In AD for example we currently return only direct memberships because in AD member/memberof are linked attributes, this means memberof does not contains DNs of indirect group memberships. I believe eDirectory is probably the same even when their memberof-equivalent attribute is set (assuming they support nesting at all). Of course we can also have a switch to allow searching for nested groups or not, so that we do not cause unnecessary searches on deployments that do not use any form of nesting. The parameter should actually probably be an integer that determines the level of nesting we allow to search at runtime, with 0 meaning none and any other value up to a maximum we define allowing deeper and deeper nesting. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] SSS problems with eDirectory
On Thu, Jul 22, 2010 at 03:30:23PM -0400, Scott Duckworth wrote: There are almost 120,000 users in our directory, and we currently have ~200 Linux systems that might use SSSD, soon scaling to 500 systems. I imagine that even 500 systems is only a medium-scale installation compared to some sites. I recentl had a look at rhel6beta which offers sssd and nscd/nslcd. Had implemented ldap authorization/authentication with sssd when i dis- covered that netgroups are not available yet. Mainly used with pam_access and sudo here for authorization. Do you mind what you are using instead in your environment? Or are these users just all authorized to do the same? Christian ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] SSS problems with eDirectory
On Thu, Jul 22, 2010 at 11:19:44AM -0400, Scott Duckworth wrote: On Thu, Jul 22, 2010 at 11:07 AM, Sumit Bose sb...@redhat.com wrote: On Thu, Jul 22, 2010 at 10:19:37AM +0200, Sumit Bose wrote: On Wed, Jul 21, 2010 at 03:22:29PM -0400, Scott Duckworth wrote: ... something bad happened isn't very useful. And since SSS refuses to try and authenticate users without an encrypted connection, I can't easily use wireshark and friends to debug at the protocol level. While I could probably patch the source to print the actual LDAP error with ldap_err2string(), or maybe gdb the process and set a breakpoint when things go wrong to hopefully get some more useful information, this is beyond what I'd normally consider doing when deploying new software. Any suggestions? I'm currently installing eDirectory and I will try to reproduce the behaviour you have found. I have run some basic authentication test with eDirectory 8.8-SP5 and everything worked fine. I have to admit that I have used the current master of sssd which includes a lot of changes to the LDAP code. Would you mind to test our current beta release from http://kojipkgs.fedoraproject.org/packages/sssd/1.2.91/21.fc14/ . It is for rawhide but should work fine on F13, too. Sure, I'll give it a shot and report back what I find. I also didn't use LDAP aliases. Can you check if setting DEREF in /etc/openldap/ldap.conf helps? If not, can you give a short description how aliases are used in your case so that I can set up a similar environment? Setting DEREF to always in /etc/openldap/ldap.conf works. Aliasing is only nice, so authentication is working for you now? needed for one DN in our tree: everyone's default group is aliased to another DN in another branch of the tree. I wish there were some way to enable aliasing on a per-map basis (e.g. only groups or only users) so that you'd only take the performance hit where necessary, but I'm not aware of any NSS LDAP client that does this. The reason might be that the OpenLDAP libraries do not let you specify the deref option in the exported ldap_search routines. It is only an option for the whole connection. bye, Sumit Thanks. bye, Sumit Moving on... We will need to dereference LDAP aliases but I have not yet been able to find a setting to enable this. I also have not found the equivalent of the I have added a RFE to sssd trac (https://fedorahosted.org/sssd/ticket/568). As a sort term fix you can add the appropriate DEREF option to /etc/openldap/ldap.conf. pam_password_prohibit_message setting in /etc/ldap.conf; while not strictly required, it is nice to refer users to the proper way to change passwords in our environment. Currently there is only a configurable message if password resets by root fail. I have added https://fedorahosted.org/sssd/ticket/569 to track this. bye, Sumit Any help would be appreciated. Thanks! Scott Duckworth, Systems Programmer II Clemson University School of Computing ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] SSS problems with eDirectory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/22/2010 11:47 AM, Scott Duckworth wrote: yum localinstall libcollection-0.5.0-21.fc14.* libini_config-0.6.0-21.fc14.* sssd-1.2.91-21.fc14.* sssd-client-1.2.91-21.fc14.* requires python 2.7. Adding python-2.7-3.fc14.* and python-libs-2.7-3.fc14.* results in a slew of dependency resolution errors. If I get the chance in the few days, I'll try it under rawhide. Sorry, that was the wrong package. Please try: http://koji.fedoraproject.org/koji/buildinfo?buildID=182852 The one Sumit sent you mistakenly was from an in-progress rebuild of python for Fedora 14. This one uses Python 2.6 and should install cleanly on Fedora 13. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkxIdB8ACgkQeiVVYja6o6MpMQCfch5jTZlOHvuWaBNePVFVLK7s Fg4AoItYQ6rNj8lwxwLb0pSgZfYdzhtL =jdnq -END PGP SIGNATURE- ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] SSS problems with eDirectory
[snip] Uhmmm this may be a side effect of your directory not having memberof I think we need to add special code to handle servers that use rfc2307bis schema but that do not use memberof. Are we sure that this is the case? Is there any chance we can get a schema file that shows what is the schema used on the server? May be it is one of the early drafts of the rfc2307bis that is implemented in the server? I think the ldapsearch results listing any one user and a group he is a member in your server of will be very helpful. -- Thank you, Dmitri Pal Engineering Manager IPA project, 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] SSS problems with eDirectory
On Thu, 22 Jul 2010 17:59:03 -0400 Dmitri Pal d...@redhat.com wrote: [snip] Uhmmm this may be a side effect of your directory not having memberof I think we need to add special code to handle servers that use rfc2307bis schema but that do not use memberof. Are we sure that this is the case? Is there any chance we can get a schema file that shows what is the schema used on the server? May be it is one of the early drafts of the rfc2307bis that is implemented in the server? I think the ldapsearch results listing any one user and a group he is a member in your server of will be very helpful. memberof is not required by rfc2307bis. Actually it is not even mentioned by rfc2307bis, so it is our fault if we depend on it. rfc2307bis actually mentions only uniquemember. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
