[Freeipa-users] Oracle Linux 5.5 - Legacy Question

[Jeffrey Stormshak]

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 ?

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..

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20151124/405849b5/attachment.htm>