Re: [Freeipa-users] sudo / sssd integration problems
no problem, thanks for trying! I just figured it out. yum -y install libsss_sudo fixed it. Should this package be a dependency that gets pulled in when IPA client is installed? shall I file a bug? Thanks, Brian --- Brian Cook Solutions Architect, Red Hat, Inc. 407-212-7079 On Mar 21, 2013, at 8:50 PM, Brian Cook bc...@redhat.com wrote: Those packages are installed. The second part is against what I am trying to accomplish. My sudo rule is already created in IPA. I just need SSSD to fetch it. Thanks, Brian On Mar 21, 2013, at 8:37 PM, John Moyer john.mo...@digitalreasoning.com wrote: I had sudo issues similar to this, I can't remember the exact fix. I have the following two things in my notes. The second command would obviously need you to add the people you want to be able to sudo to the admins group after you add this. yum install ipa-client fprintd-pam -y echo %admins ALL=(ALL) NOPASSWD: ALL /etc/sudoers Thanks, _ John Moyer On Mar 21, 2013, at 11:27 PM, Brian Cook bc...@redhat.com wrote: Running F18 and following the instructions here: http://jhrozek.fedorapeople.org/sssd/1.9.1/man/sssd-sudo.5.html When I try to run sudo -l as any user I get the following error: bash-4.2$ sudo -l sudo: Unable to dlopen /usr/lib64/libsss_sudo.so: (null) sudo: Unable to initialize SSS source. Is SSSD installed on your machine? Nothing particularly interesting in the log with debug at 5. Can someone point me in the right direction? Thanks, Brian sssd.conf: [domain/example.com] debug_level = 5 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = example.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = ipadevel.example.com chpass_provider = ipa ipa_server = ipadevel.example.com ldap_tls_cacert = /etc/ipa/ca.crt sudo_provider = ldap ldap_uri = ldap://ipadevel.example.com ldap_sudo_search_base = ou=sudoers,dc=example,dc=com ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/ipadevel.example.com ldap_sasl_realm = EXAMPLE.COM krb5_server = ipadevel.example.com [sssd] services = nss, pam, ssh, sudo config_file_version = 2 domains = example.com [nss] [pam] [sudo] debug_level=5 [autofs] [ssh] [pac] ___ 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] sudo / sssd integration problems
We already have a bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=924395 This should be fixed along with ticket adding sudo configuration support to ipa-client-install: https://fedorahosted.org/freeipa/ticket/3358 Martin On 03/22/2013 07:13 AM, Brian Cook wrote: no problem, thanks for trying! I just figured it out. yum -y install libsss_sudo fixed it. Should this package be a dependency that gets pulled in when IPA client is installed? shall I file a bug? Thanks, Brian --- Brian Cook Solutions Architect, Red Hat, Inc. 407-212-7079 On Mar 21, 2013, at 8:50 PM, Brian Cook bc...@redhat.com mailto:bc...@redhat.com wrote: Those packages are installed. The second part is against what I am trying to accomplish. My sudo rule is already created in IPA. I just need SSSD to fetch it. Thanks, Brian On Mar 21, 2013, at 8:37 PM, John Moyer john.mo...@digitalreasoning.com mailto:john.mo...@digitalreasoning.com wrote: I had sudo issues similar to this, I can't remember the exact fix. I have the following two things in my notes. The second command would obviously need you to add the people you want to be able to sudo to the admins group after you add this. yum install ipa-client fprintd-pam -y echo %admins ALL=(ALL) NOPASSWD: ALL /etc/sudoers Thanks, _ John Moyer On Mar 21, 2013, at 11:27 PM, Brian Cook bc...@redhat.com mailto:bc...@redhat.com wrote: Running F18 and following the instructions here: http://jhrozek.fedorapeople.org/sssd/1.9.1/man/sssd-sudo.5.html When I try to run sudo -l as any user I get the following error: bash-4.2$ sudo -l sudo: Unable to dlopen /usr/lib64/libsss_sudo.so: (null) sudo: Unable to initialize SSS source. Is SSSD installed on your machine? Nothing particularly interesting in the log with debug at 5. Can someone point me in the right direction? Thanks, Brian sssd.conf: [domain/example.com http://example.com/] debug_level = 5 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = example.com http://example.com/ id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = ipadevel.example.com http://ipadevel.example.com/ chpass_provider = ipa ipa_server = ipadevel.example.com http://ipadevel.example.com/ ldap_tls_cacert = /etc/ipa/ca.crt sudo_provider = ldap ldap_uri = ldap://ipadevel.example.com ldap_sudo_search_base = ou=sudoers,dc=example,dc=com ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/ipadevel.example.com http://ipadevel.example.com/ ldap_sasl_realm = EXAMPLE.COM http://example.com/ krb5_server = ipadevel.example.com http://ipadevel.example.com/ [sssd] services = nss, pam, ssh, sudo config_file_version = 2 domains = example.com http://example.com/ [nss] [pam] [sudo] debug_level=5 [autofs] [ssh] [pac] ___ Freeipa-users mailing list Freeipa-users@redhat.com mailto:Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com mailto: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] EXTERNAL: Re: Winsync Issues
Hey Rich,
I found out the issue. Thank you for pointing me in the right direction.
The user I am using for Password Sync has a login name of idmpasssync but the
display name was IDM Password Sync. I changed the display name to idmpasssync
and I was able to do the ldapsearch.
I just ran the ipa-replica-manage command and was able to make a connection.
Thanks again,
Matt
From: Rich Megginson [mailto:rmegg...@redhat.com]
Sent: Thursday, March 21, 2013 5:00 PM
To: Joseph, Matthew (EXP)
Cc: freeipa-users@redhat.com
Subject: Re: EXTERNAL: Re: [Freeipa-users] Winsync Issues
On 03/21/2013 01:45 PM, Joseph, Matthew (EXP) wrote:
Hey Rich,
I've changed the password multiple times now and it's still not accepting the
password. I've even set it as simple as password.
I forgot to mention in my initial post that my domain looks more like this.
Domain1.domain2.ca
So my command looks like cn=idmpasssync,cn=users,dc=domain1,dc=domain2,dc=ca
That shouldn't make a difference should it?
As long as that is the DN you are using with ldapsearch -D, and the same as the
DN you are passing to ipa-manage-replica, that should be fine.
Let's take a step back. Do you know the windows admin password? If so, try
this:
ldapsearch -xLLL -ZZ -h adserver.domain.ca -D
cn=administrator,cn=idmpasssync,cn=users,dc=domain1,dc=domain2,dc=ca -w
'admin password' -s base -b
cn=idmpasssync,cn=users,dc=domain1,dc=domain2,dc=ca
From: Rich Megginson [mailto:rmegg...@redhat.com]
Sent: Thursday, March 21, 2013 4:31 PM
To: Joseph, Matthew (EXP)
Cc: freeipa-users@redhat.commailto:freeipa-users@redhat.com
Subject: Re: EXTERNAL: Re: [Freeipa-users] Winsync Issues
On 03/21/2013 01:26 PM, Joseph, Matthew (EXP) wrote:
Hey Rich,
Tried the command you listed below and it says ldap_bind: Invalid Credentials
(49)
This means you have the wrong password.
If I take away the -w 'WindowsIDMPassSyncPW' then it will bring back the
results of the LDAP search.
This means it is doing an anonymous search of which AD allows.
Try this:
ldapsearch -xLLL -ZZ -h adserver.domain.ca -D
cn=idmpasssync,cn=users,dc=domain,dc=ca -w 'WindowsIDMPassSyncPW' -s base -b
cn=users,dc=domain,dc=ca
From: Rich Megginson [mailto:rmegg...@redhat.com]
Sent: Thursday, March 21, 2013 4:12 PM
To: Joseph, Matthew (EXP)
Cc: freeipa-users@redhat.commailto:freeipa-users@redhat.com
Subject: EXTERNAL: Re: [Freeipa-users] Winsync Issues
On 03/21/2013 12:37 PM, Joseph, Matthew (EXP) wrote:
Hello,
I'm currently in the processing of installing/configuring IPA 2.2.0-16 on a
Red Hat 6.4 Server and I'm running into some issues trying to get IPA to
replicate to a Windows 2003 SP2 DC.
Here is the steps I took (I used the Red Hat Identity Management Guide)
1) Create idmpasssync user under AD and give him the permissions requested
2) Download IPA cert from web gui
3) Installed IPA cert under Trusted Root Certificates Authorities
4) Exported Windows cert to Red Hat Server
5) Copied both IPA and Windows certs to /etc/openldap/cacerts
6) Run the following command
a. Ipa-replica-manage connect -winsync -binddn
cn=idmpasssync,cn=users,dc=domain,dc=ca -bindpw WindowsIDMPassSyncPW -
passsync WindowsIDMPassSyncPW -cacert /etc/openldap/cacerts/windows.cer
adserver.domain.ca -v
7) After running that command I get the following error;
a. Added CA Certificate /etc/openldap/cacerts/windows.cer to certificate
database for IPAserver.domain.ca
ipa: INFO: Failed to connect to AD server adserver.domain.ca
ipa: INFO: The error was: {'info': 80090308: LdapErr: DSID-0C090334, comment:
AcceptSecurityContext error, data 525, vece', 'desc': 'Invalid Credentials'}
Failed to setup winsync replication
I checked the IPA logs and it says the same thing above, no new information
I know I entered the password correctly and I even changed it on the Active
Directory side just to make sure.
Can anyone see what I am doing wrong on this configuration?
Try this:
ldapsearch -xLLL -ZZ -h adserver.domain.ca -D
cn=idmpasssync,cn=users,dc=domain,dc=ca -w 'WindowsIDMPassSyncPW' -s base -b
Matt
___
Freeipa-users mailing list
Freeipa-users@redhat.commailto: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] 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] libsssd_sudo as dependency to ipa-client
On Thu, Mar 21, 2013 at 06:58:00PM +0100, Jakub Hrozek wrote: On Thu, Mar 21, 2013 at 11:39:27PM +0600, Arthur Fayzullin wrote: HI! I have configured sssd_sudo integration on EL6.4 and it works nice! But then I've checked this: [afaizullin@domen00 ~]$ sudo package-cleanup --leaves [sudo] password for afaizullin: Loaded plugins: fastestmirror libertas-usb8388-firmware-5.110.22.p23-3.1.el6.noarch libhugetlbfs-utils-2.12-2.el6.x86_64 libsss_sudo-1.9.2-82.4.el6_4.x86_64 libtopology-0.3-7.el6.x86_64 libunistring-0.9.3-5.el6.x86_64 so if I or someone will activate yum clean_requirements_on_remove option, there is probability that libsss_sudo package will be removed as orphaned dependency. Isn't think true in general for all plugin-like packages? That is why I think, that this package should be dependency to ipa-client package. I'm actually wondering whether it would make sense to fold libsss_sudo and libsss_autofs back to sssd proper. They are very small, so they wouldn't increase the footprint of small systems and users are regularly tripping over the requirement to install the dependencies separately. I filed this as https://fedorahosted.org/sssd/ticket/1845 ___ 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] Slow ipa performance -- why so many ldap lookups ?
On Thu, Mar 21, 2013 at 09:57:50PM +0100, Jan-Frode Myklebust wrote: On Thu, Mar 21, 2013 at 03:29:38PM +0100, Jakub Hrozek wrote: I see several failures related to the SELinux processing: --- (Thu Mar 21 08:23:57 2013) [sssd[be[example.net]]] [ipa_selinux_get_maps_done] (0x0400): No SELinux user maps found! (Thu Mar 21 08:23:57 2013) [sssd[be[example.net]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, Success) [Success] (Thu Mar 21 08:23:57 2013) [sssd[be[example.net]]] [be_pam_handler_callback] (0x0100): Sending result [4][example.net] (Thu Mar 21 08:23:57 2013) [sssd[be[example.net]]] [be_pam_handler_callback] (0x0100): Sent result [4][example.net] --- 4 is an internal error code, it would manifest in your /var/log/secure as System Error. No system errors are logged to /var/log/secure: Mar 21 11:30:01 ipa1 CROND[1161]: pam_unix(crond:session): session closed for user root Mar 21 11:33:27 ipa1 sshd[1204]: pam_access(sshd:account): access denied for user `janfrode' from `login2.example.net' Mar 21 11:33:33 ipa1 sshd[1216]: pam_unix(sshd:session): session opened for user janfrode by (uid=0) Mar 21 11:33:39 ipa1 su: pam_unix(su-l:session): session opened for user root by janfrode(uid=15019) What state is SELinux on the client machine? Are there any AVC denials? Selinux is in enforcing mode. No denials logged. When upgrading to v2.2, and also when initializing a v2.2 replica we got the following error: Applying LDAP updates ipa : ERRORUpdate failed: Object class violation: attribute ipaSELinuxUserMapOrder not allowed Then maybe SSSD is tripping over the absence of the SELinux map order. At least that's the way I read the SSSD code, it relies on the presence of the ipaSELinuxUserMapOrder attribute. What does: $ ipa config-show --all --raw | grep -i selinux say? Does the problem go away if you set: selinux_provider = none In the config file in the domain section? ___ 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] Slow ipa performance -- why so many ldap lookups ?
On Fri, Mar 22, 2013 at 04:19:39PM +0100, Jakub Hrozek wrote: Then maybe SSSD is tripping over the absence of the SELinux map order. At least that's the way I read the SSSD code, it relies on the presence of the ipaSELinuxUserMapOrder attribute. What does: $ ipa config-show --all --raw | grep -i selinux say? Nada: [janfrode@ipa1 ~]$ ipa config-show --all --raw | grep -i selinux [janfrode@ipa1 ~]$ Does the problem go away if you set: selinux_provider = none In the config file in the domain section? I have added this to one of my clients. Will report back if the problem is gone or happens again. -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 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
