I went to review the ‘ip_provider’ and that looks like a ‘sssd.conf’ setting.  
The sssd RPM isn’t located on the 5.5 clients; nor is it in the YUM Channels 
for 5.5 base and 5.5 patch.  So is the recommendation here to find any 5.X 
version of sssd RPM and use that for this configuration?  Sorry, being a newbie 
on this product realistically isn’t helping here I’m sure …

The ipa-advise, is that part of the ipa-client RPM?  That too, doesn’t exist on 
the 5.5 distribution as well.  Even the version required to fix the openssl 
only worked with the 5.7 base version.  Am I complete doomed for 5.5?  Cards 
are stacked for sure.  Nonetheless …

I feel so close though…  Auth and Sudo works on 5.5 but something as simple as 
users changing passwords seems so simple to provide?

Jeffrey Stormshak, RHCSA | Sr. Linux Engineer
Platform Systems | IT Operations Infrastructure
CCC Information Services, Inc.
Phone: (312) 229-2552

From: Jakub Hrozek <jhro...@redhat.com<mailto:jhro...@redhat.com>>
Date: Tuesday, November 24, 2015 at 2:25 AM
To: Rob Crittenden <rcrit...@redhat.com<mailto:rcrit...@redhat.com>>
Cc: Jeffrey Stormshak <jstorms...@cccis.com<mailto:jstorms...@cccis.com>>, 
"freeipa-users@redhat.com<mailto:freeipa-users@redhat.com>" 
<freeipa-users@redhat.com<mailto:freeipa-users@redhat.com>>
Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question

On Mon, Nov 23, 2015 at 09:32:52PM -0500, Rob Crittenden wrote:
Jeffrey Stormshak wrote:
> Jakub/Rob -
> Thanks for the feedback.  I was finally able to ditch the ‘binddn’ and
> was able to get SSL working upon upgrading the OpenSSL from the 5.5 base
> to the one supplied in 5.7 base. The SSL is fully authenticating and
> with sudo access.  However, I’m riddled by the following item below.
>  I’m hoping that someone/somewhere encountered this issue and was able
> to resolve it using this legacy 5.5.  See details provided below.  All
> thoughts/suggestions are truly appreciated !!
>
> *
> *
>
> $ id -a
>
> uid=1403200001(pmoss) gid=7000(sysadmin) groups=7000(sysadmin)
>
>
>
> $ passwd
>
> Changing password for user pmoss.
>
> Enter login(LDAP) password:
>
> New UNIX password:
>
> Retype new UNIX password:
>
>
>
> LDAP password information update failed: Insufficient access
>
> Insufficient 'write' privilege to the 'userPassword' attribute of entry
> 'uid=pmoss,cn=users,cn=compat,dc=linuxcccis,dc=com'.
>
> 

>
> passwd: Permission denied
>
> *
> *
>
> # ipa user-show pmoss --all --rights | grep -i userpass  ->
> attributelevelrights: {u'userpassword': u'swo’, …
>
>
> pmoss shows *u'userpassword': u'swo'*
>
> ‘swo’ translates to ‘search,write,delete’
>
>
> Why wouldn’t the above be enough rights to be able to change ‘pmoss’
> personal password?  Thoughts ?
Because it is a different part of the tree.
Did you use ipa-advise to get the configuration? If so which profile?
It looks like that recommends using the compat tree.  It's been forever
since I've manually configured a RHEL 5 system so I don't know if that
is correct or not.

Using the compat tree for users and groups (which implies
id_provider=ldap, not ipa) is the right thing to do if you also want to
use AD trust users on an RHEL-5 client.

Otherwise, just use id_provider=ipa (but still point sudo to ou=sudoers)

I'm pretty sure that nss_ldap supports RFC2307bis but it's really just a
distant memory.
rob
> *Jeffrey Stormshak, RHCSA | Sr. Linux Engineer*
>
> Platform Systems | IT Operations Infrastructure
>
> CCC Information Services, Inc.
>
> Phone: (312) 229-2552
>
>
> From: Jakub Hrozek <jhro...@redhat.com<mailto:jhro...@redhat.com> 
> <mailto:jhro...@redhat.com>>
> Date: Monday, November 23, 2015 at 1:58 AM
> To: Jeffrey Stormshak <jstorms...@cccis.com<mailto:jstorms...@cccis.com> 
> <mailto:jstorms...@cccis.com>>
> Cc: Rob Crittenden <rcrit...@redhat.com<mailto:rcrit...@redhat.com> 
> <mailto:rcrit...@redhat.com>>,
> "freeipa-users@redhat.com<mailto:freeipa-users@redhat.com> 
> <mailto:freeipa-users@redhat.com>"
> <freeipa-users@redhat.com<mailto:freeipa-users@redhat.com> 
> <mailto:freeipa-users@redhat.com>>
> Subject: Re: [Freeipa-users] Oracle Linux 5.5 - Legacy Question
>
> On Sat, Nov 21, 2015 at 02:21:52AM +0000, Jeffrey Stormshak wrote:
>
>     Rob -
>     Here’s the test configurations/data when I manipulate the
>     BINDDN/BINDPW fields to get get both AUTH and SUDO to work in Linux
>     5.5.  I have three questions below that I would like to get your
>     comments on or see what you may recommend on this.  I’m seriously
>     perplexed on this as to why its working this way …  Please
>     advise.  Thanks!
>     **************************************************************
>     AUTH successful on login; SUDO fails with the message listed
>     below !!
>     **************************************************************
>     [mjsmith@chi-infra-idm-client2 ~]$ sudo -l
>     sudo: ldap_sasl_bind_s(): Server is unwilling to perform
>
>
> Looks like the bind didn't finish successfully, can you look into
> debugging sudo itself? The debugging changed a bit between releases, but
> The sudo documentation would tell you..
>
>     [sudo] password for mjsmith:
>     Sorry, user mjsmith may not run sudo on chi-infra-idm-client2.
>     *****************************************************
>     *****************************************************
>     # grep -iv ‘#’ /etc/ldap.conf
>     *****************************************************
>     base dc=linuxcccis,dc=com
>     uri ldap://chi-infra-idm-p1.linuxcccis.com/
>     binddn uid=admin,cn=users,cn=compat,dc=linuxcccis,dc=com
>     bindpw secret_pass
>     timelimit 15
>     bind_timelimit 5
>     idle_timelimit 3600
>     nss_initgroups_ignoreusers
>     
> root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm
>     pam_password md5
>     sudoers_base ou=SUDOers,dc=linuxcccis,dc=com
>     *************************************************
>     User Account AUTH and SUDO works when
>     commenting both the binddn and bindpw fields !!
>     *************************************************
>     vi /etc/ldap.conf … Comment these two fields …
>     #binddn uid=admin,cn=users,cn=compat,dc=linuxcccis,dc=com
>     #bindpw secret_pass
>     ************************************************
>     This file unchanged during the above testing !!
>     ************************************************
>     /etc/sudo-ldap.conf:
>     binddn uid=sudo,cn=sysaccounts,cn=etc,dc=linuxcccis,dc=com
>     bindpw secret_pass
>     ssl start_tls
>     tls_cacertfile /etc/ipa/ca.crt
>     tls_checkpeer yes
>     bind_timelimit 5
>     timelimit 15
>     uri ldap://chi-infra-idm-p1.linuxcccis.com
>     sudoers_base ou=SUDOers,dc=linuxcccis,dc=com
>     QUESTIONS:
>     1) What BINDN account needs to be specified to allow the
>     BINDDN/BINDPW to work for SUDO?
>     2) Why does the AUTH work when setting values in the BINDDN/BINDPW,
>     but SUDO then fails?
>     3) If I leave BINDDN/BINDPW blank, what security risks are being
>     introduced by leaving it that way?
>
>
> Anyone on the network can read sudo rules. I guess in theory, the
> attacker might target accounts who are allowed to run sudo rules as a
> gateway for getting elevated privileges on the machine..
>

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to