[Freeipa-users] Oracle Linux 5.5 - Legacy Question

[Jakub Hrozek]

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 <jhrozek at redhat.com <mailto:jhrozek at redhat.com>>
> > Date: Monday, November 23, 2015 at 1:58 AM
> > To: Jeffrey Stormshak <jstormshak at cccis.com <mailto:jstormshak at cccis.com>>
> > Cc: Rob Crittenden <rcritten at redhat.com <mailto:rcritten at redhat.com>>,
> > "freeipa-users at redhat.com <mailto:freeipa-users at redhat.com>"
> > <freeipa-users at redhat.com <mailto:freeipa-users at 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 at 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..
> > 
>