Learn more about these different git repos.
Other Git URLs
https://bugzilla.redhat.com/show_bug.cgi?id=814414 (Red Hat Enterprise Linux 6)
Description of problem: Installed IPA server and configured one client. Configured HBAC to allow me to ssh to the client and disabled the default HBAC Rule. Configured sudo on client and attempted to sudo to execute a command. The sudo was denied. The sssd log reads: Apr 19 15:22:17 celeno sudo: pam_sss(sudo:auth): received for user tuser1: 4 (System error) Version-Release number of selected component (if applicable): sssd-1.8.0-22.el6.x86_64 ipa-server-2.2.0-9.el6.x86_64 sudo-1.7.4p5-8.el6.x86_64 Steps to Reproduce: 1. Install IPA server machine 2. Install IPA client machine 3. ipa hbacrule-disable allow_all 4. Add ipa user, tuser1 5. Add HBAC rule, hostcat=all, service=sshd, user=tuser1 6. Add sudo command /usr/bin/less 7. Add sudorule less and set hostcat=all 8. Add /usr/bin/less to rule 9. Add user tuser1 to rule 10. configure client machine to do sudo per documentation: http://docs.fedorapr oject.org/en-US/Fedora/15/html/FreeIPA_Guide/configuring-sudo.html#proc-Enterpr ise_Identity_Management_Guide-Server_Configuration_for_Sudo_Rules-How_to_config ure_your_server_to_use_Sudo_rules 11. Log into client as tuser1 12. sudo /usr/bin/less LDAP Config Summary =================== uri ldap://ipa.rcritten.redhat.com ldap_version 3 sudoers_base ou=SUDOers,dc=rcritten,dc=redhat,dc=com binddn uid=sudo,cn=sysaccounts,cn=etc,dc=rcritten,dc=redhat,dc=com bindpw password bind_timelimit 5000 timelimit 15 ssl start_tls tls_checkpeer (yes) tls_cacertfile /etc/ipa/ca.crt =================== sudo: ldap_initialize(ld, ldap://ipa.rcritten.redhat.com) sudo: ldap_set_option: debug -> 0 sudo: ldap_set_option: ldap_version -> 3 sudo: ldap_set_option: tls_checkpeer -> 1 sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt sudo: ldap_set_option: timelimit -> 15 sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5) sudo: ldap_start_tls_s() ok sudo: ldap_sasl_bind_s() ok sudo: no default options found in ou=SUDOers,dc=rcritten,dc=redhat,dc=com sudo: ldap search '(|(sudoUser=tuser1)(sudoUser=%tuser1)(sudoUser=ALL))' sudo: found:cn=less,ou=sudoers,dc=rcritten,dc=redhat,dc=com sudo: ldap sudoHost 'ALL' ... MATCH! sudo: ldap sudoCommand '/usr/bin/less' ... MATCH! sudo: Command allowed sudo: user_matches=1 sudo: host_matches=1 sudo: sudo_ldap_lookup(0)=0x02 [sudo] password for tuser1: Sorry, try again. [sudo] password for tuser1: sudo: 1 incorrect password attempt A snapshot of /var/log/secure is: Apr 19 15:22:14 celeno sudo: pam_unix(sudo:auth): authentication failure; logname=root uid=0 euid=0 tty=/dev/pts/1 ruser=tuser1 rhost= user=tuser1 Apr 19 15:22:16 celeno sudo: pam_sss(sudo:auth): authentication success; logname=root uid=0 euid=0 tty=/dev/pts/1 ruser=tuser1 rhost= user=tuser1 Apr 19 15:22:16 celeno sudo: pam_sss(sudo:account): Access denied for user tuser1: 6 (Permission denied) Apr 19 15:22:17 celeno sudo: pam_unix(sudo:auth): conversation failed Apr 19 15:22:17 celeno sudo: pam_unix(sudo:auth): auth could not identify password for [tuser1] Apr 19 15:22:17 celeno sudo: pam_sss(sudo:auth): system info: [Cannot read password] Apr 19 15:22:17 celeno sudo: pam_sss(sudo:auth): authentication failure; logname=root uid=0 euid=0 tty=/dev/pts/1 ruser=tuser1 rhost= user=tuser1 Apr 19 15:22:17 celeno sudo: pam_sss(sudo:auth): received for user tuser1: 4 (System error) Apr 19 15:22:17 celeno sudo: tuser1 : 1 incorrect password attempt ; TTY=pts/1 ; PWD=/home/tuser1 ; USER=root ; COMMAND=/usr/bin/less Apr 19 15:22:30 celeno su: pam_unix(su-l:session): session closed for user tuser1 The reproducing machine was reaped, I no longer have it. I re-enabled the allow_all HBAC rule and sudo started working.
Jakub, please attempt to reproduce this issue and determine its severity.
blockedby: => blocking: => coverity: => feature_milestone: => owner: somebody => jhrozek tests: => 0 testsupdated: => 0 upgrade: => 0
The issue turned out to be not nearly as critical as the opening comment suggested.
I could only reproduce the "System Error" when I entered a blank password:
su - ldapuser Password: <hit enter>
We don't allow blank password in the SSSD for authentication, also because in LDAP, an empty password means anonymous access. SSH wouldn't pass a blank password at all.
I'm going to lower the priority to minor and move the ticket to 1.9 as agreed on the meeting. If we don't fix it, we don't fix it...
priority: critical => minor
Replying to [comment:2 jhrozek]:
Sorry, I actually forgot to change the milestone.
milestone: NEEDS_TRIAGE => SSSD 1.9.0
I thought this was fixed with an earlier patch but I was wrong. Anyway, the fix is going to be easy.
status: new => assigned
Fields changed
patch: 0 => 1
master: 383fa7e
resolution: => fixed status: assigned => closed
Metadata Update from @sgallagh: - Issue assigned to jhrozek - Issue set to the milestone: SSSD 1.9.0
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/2352
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.