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 <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>>
Cc: Rob Crittenden <rcrit...@redhat.com<mailto:rcrit...@redhat.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 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