On Wed, Aug 12, 2015 at 07:30:52PM +0700, Dewangga Bachrul Alam wrote: > Hello! > > I'm having problem with sudo command, the sudo command was sucessfully > initiated. But user still requested for password. For example : > > ipa-client $ sudo -l > Matching Defaults entries for subhan on this host: > requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS > DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1 > PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE > LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY > LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL > LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", > secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin > > User subhan may run the following commands on this host: > (subhan) NOPASSWD: /bin/tail, /usr/bin/tail > > ipa-server $ ipa user-show subhan > User login: subhan > First name: [REMOVED] > Last name: [REMOVED] > Home directory: /home/subhan > Login shell: /bin/bash > Email address: [REMOVED] > UID: 642000007 > GID: 642000007 > Job Title: Developer > Account disabled: False > Password: False > Member of groups: g_gmt_developer, developer > Member of Sudo rule: gmt_developer > Member of HBAC rule: gmt_webserver > Kerberos keys available: False > SSH public key fingerprint: [REMOVED] > > ipa-server $ ipa sudocmd-find > ----------------------- > 2 Sudo Commands matched > ----------------------- > Sudo Command: /bin/tail > Sudo Command Groups: reading-files > > Sudo Command: /usr/bin/tail > Sudo Command Groups: reading-files > > ipa-server $ ipa sudorule-show gmt_developer > Rule name: gmt_developer > Enabled: TRUE > Users: subhan > User Groups: g_gmt_developer > Host Groups: gmt_webserver > Sudo Allow Command Groups: reading-files > RunAs Users: subhan > Sudo Option: !authenticate > > > ipa-client $ sudo tail -f /var/log/nginx/access.log > [sudo] password for subhan: > ipa-client $ sudo tail /var/log/nginx/access.log > [sudo] password for subhan: > > There's nothing information from sssd_sudo.log about this issue.
In general sssd acts as a cache of the sudo rules, the decision to auth or not is done by sudo. So on the sssd side you can make sure the sudo option value was fetched, but you'll probably get a more useful debugging from sudo itself. -- 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