Hello, I am trying to setup a few of my users to have the ability to su - jira or another user using FreeIPA. Here is what happens when I am logged in as the user and try to su - jira [user1@jira02 ~]$ sudo su - process[sudo] password for user1:Sorry, user user1 is not allowed to execute '/bin/su - jira' as root on jira02.example.net.[user1@jira02 ~]$ [andrew.meyer@jira02 ~]$ ipa sudorule-show su_jira Rule name: su_jira Enabled: TRUE Host category: all RunAs User category: all RunAs Group category: all User Groups: developers, ops_sudoers Sudo Allow Command Groups: jira_access Sudo Option: !authenticate[andrew.meyer@jira02 ~]$
[andrew.meyer@jira02 ~]$ ipa sudocmd-find su_jira_cmds----------------------1 Sudo Command matched---------------------- Sudo Command: /usr/bin/su - jira,/usr/bin/sudo su - jira,/bin/su - jira,/bin/sudo - jira Description: su_jira_cmds----------------------------Number of entries returned 1---------------------------- What am I doing wrong?
On Thu, Nov 09, 2017 at 02:07:03AM +0000, Andrew Meyer via FreeIPA-users wrote:
Hello, I am trying to setup a few of my users to have the ability to su - jira or another user using FreeIPA. Here is what happens when I am logged in as the user and try to su - jira [user1@jira02 ~]$ sudo su - process[sudo] password for user1:Sorry, user user1 is not allowed to execute '/bin/su - jira' as root on jira02.example.net.[user1@jira02 ~]$ [andrew.meyer@jira02 ~]$ ipa sudorule-show su_jira Rule name: su_jira Enabled: TRUE Host category: all RunAs User category: all RunAs Group category: all User Groups: developers, ops_sudoers Sudo Allow Command Groups: jira_access Sudo Option: !authenticate[andrew.meyer@jira02 ~]$
[andrew.meyer@jira02 ~]$ ipa sudocmd-find su_jira_cmds----------------------1 Sudo Command matched---------------------- Sudo Command: /usr/bin/su - jira,/usr/bin/sudo su - jira,/bin/su - jira,/bin/sudo - jira Description: su_jira_cmds----------------------------Number of entries returned 1---------------------------- What am I doing wrong?
I would first run "sudo -l" to see if the user is able to run any sudo commands at all.
Then I'd proceed to sudo debugging from https://docs.pagure.org/SSSD.sssd/users/sudo_troubleshooting.html#obtaining-... to see what data was transferred to sudo and how did sudo evaluate them.
Ok so I did that and the rules are coming down just like I thought: [user1@jira02 ~]$ sudo -lMatching Defaults entries for rob.lloyd on jira02: !visiblepw, always_set_home, match_group_by_gid, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE 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 user1 may run the following commands on jira02: (ALL : ALL) NOPASSWD: /usr/bin/su - jira,/usr/bin/sudo su - jira,/bin/su - jira,/bin/sudo - jira[user1@jira02 ~]$ But i'm not able to execute...I will look into the debugger and see what I get. This is all new territory for me. If you have any ideas, thank you in advance.
On Thursday, November 9, 2017 1:47 AM, Jakub Hrozek via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On Thu, Nov 09, 2017 at 02:07:03AM +0000, Andrew Meyer via FreeIPA-users wrote:
Hello, I am trying to setup a few of my users to have the ability to su - jira or another user using FreeIPA. Here is what happens when I am logged in as the user and try to su - jira [user1@jira02 ~]$ sudo su - process[sudo] password for user1:Sorry, user user1 is not allowed to execute '/bin/su - jira' as root on jira02.example.net.[user1@jira02 ~]$ [andrew.meyer@jira02 ~]$ ipa sudorule-show su_jira Rule name: su_jira Enabled: TRUE Host category: all RunAs User category: all RunAs Group category: all User Groups: developers, ops_sudoers Sudo Allow Command Groups: jira_access Sudo Option: !authenticate[andrew.meyer@jira02 ~]$
[andrew.meyer@jira02 ~]$ ipa sudocmd-find su_jira_cmds----------------------1 Sudo Command matched---------------------- Sudo Command: /usr/bin/su - jira,/usr/bin/sudo su - jira,/bin/su - jira,/bin/sudo - jira Description: su_jira_cmds----------------------------Number of entries returned 1---------------------------- What am I doing wrong?
I would first run "sudo -l" to see if the user is able to run any sudo commands at all.
Then I'd proceed to sudo debugging from https://docs.pagure.org/SSSD.sssd/users/sudo_troubleshooting.html#obtaining-... to see what data was transferred to sudo and how did sudo evaluate them. _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Our sudo is set up to use local files with the rule citing a group, with the group in IPA. sssd gets a fresh groups list for the user at login, so there should be no caching issues. This should be sufficient if you’re just interested in sudo root or a few fairly fixed things. If you’re using sudo in more complex ways and the requirements change a lot, then having the whole thing in IPA would certainly be a win.
On Nov 9, 2017, at 8:48 AM, Andrew Meyer via FreeIPA-users <freeipa-users@lists.fedorahosted.orgmailto:freeipa-users@lists.fedorahosted.org> wrote:
Ok so I did that and the rules are coming down just like I thought:
[user1@jira02 ~]$ sudo -l Matching Defaults entries for rob.lloyd on jira02: !visiblepw, always_set_home, match_group_by_gid, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE 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 user1 may run the following commands on jira02: (ALL : ALL) NOPASSWD: /usr/bin/su - jira,/usr/bin/sudo su - jira,/bin/su - jira,/bin/sudo - jira [user1@jira02 ~]$
But i'm not able to execute...I will look into the debugger and see what I get. This is all new territory for me. If you have any ideas, thank you in advance.
On Thursday, November 9, 2017 1:47 AM, Jakub Hrozek via FreeIPA-users <freeipa-users@lists.fedorahosted.orgmailto:freeipa-users@lists.fedorahosted.org> wrote:
On Thu, Nov 09, 2017 at 02:07:03AM +0000, Andrew Meyer via FreeIPA-users wrote:
Hello, I am trying to setup a few of my users to have the ability to su - jira or another user using FreeIPA. Here is what happens when I am logged in as the user and try to su - jira [user1@jira02mailto:user1@jira02 ~]$ sudo su - process[sudo] password for user1:Sorry, user user1 is not allowed to execute '/bin/su - jira' as root on jira02.example.nethttp://jira02.example.net.[user1@jira02mailto:user1@jira02 ~]$ [andrew.meyer@jira02mailto:andrew.meyer@jira02 ~]$ ipa sudorule-show su_jira Rule name: su_jira Enabled: TRUE Host category: all RunAs User category: all RunAs Group category: all User Groups: developers, ops_sudoers Sudo Allow Command Groups: jira_access Sudo Option: !authenticate[andrew.meyer@jira02mailto:andrew.meyer@jira02 ~]$
[andrew.meyer@jira02mailto:andrew.meyer@jira02 ~]$ ipa sudocmd-find su_jira_cmds----------------------1 Sudo Command matched---------------------- Sudo Command: /usr/bin/su - jira,/usr/bin/sudo su - jira,/bin/su - jira,/bin/sudo - jira Description: su_jira_cmds----------------------------Number of entries returned 1---------------------------- What am I doing wrong?
I would first run "sudo -l" to see if the user is able to run any sudo commands at all.
Then I'd proceed to sudo debugging from https://docs.pagure.org/SSSD.sssd/users/sudo_troubleshooting.html#obtaining-...https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.pagure.org%2FSSSD.sssd%2Fusers%2Fsudo_troubleshooting.html%23obtaining-logs&data=02%7C01%7Chedrick%40rutgers.edu%7C0d27a7e55c1544f0577d08d52778b7be%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636458321797558546&sdata=Po8Z%2FCZDAObeD3k%2BW0HRlb00lbcMBPINWVzwyOGSWuo%3D&reserved=0 to see what data was transferred to sudo and how did sudo evaluate them.
_______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.orgmailto:freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.orgmailto:freeipa-users-leave@lists.fedorahosted.org
_______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.orgmailto:freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.orgmailto:freeipa-users-leave@lists.fedorahosted.org
Charles,Not sure my boss wants to do it that way. How do you deploy new rules? Puppet, Ansible? Also here is the logs from sssd: (Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSudoRunAsExtUserGroup](Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [externalUser](Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [entryUSN](Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.net]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 8(Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.net]]] [sdap_op_add] (0x2000): New operation 8 timeout 6(Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.net]]] [sdap_process_result] (0x2000): Trace: sh[0x55848d200b40], connected[1], ops[0x55848d265290], ldap[0x55848d2272e0](Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.net]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list(Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.net]]] [sdap_process_result] (0x2000): Trace: sh[0x55848d200b40], connected[1], ops[0x55848d265290], ldap[0x55848d2272e0](Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.net]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set(Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.net]]] [sdap_get_generic_op_finished] (0x2000): Total count [0](Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.net]]] [sdap_op_destructor] (0x2000): Operation 8 finished(Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.net]]] [sdap_search_bases_ex_done] (0x0400): Receiving data from base [cn=sudo,dc=example,dc=net](Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.net]]] [ipa_sudo_fetch_rules_done] (0x0040): Received 0 sudo rules(Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.net]]] [ipa_sudo_fetch_cmdgroups] (0x0400): About to fetch sudo command groups(Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.net]]] [ipa_sudo_fetch_cmdgroups] (0x0400): No command groups needs to be downloaded(Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.net]]] [ipa_sudo_fetch_cmds] (0x0400): About to fetch sudo commands(Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.net]]] [ipa_sudo_fetch_cmds] (0x0400): No commands needs to be downloaded(Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.net]]] [ipa_sudo_fetch_done] (0x0400): About to convert rules(Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.net]]] [sysdb_sudo_purge_byrules] (0x0400): About to remove rules from sudo cache(Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.net]]] [sdap_sudo_set_usn] (0x0400): SUDO USN value is empty.(Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.net]]] [ipa_sudo_refresh_done] (0x0400): Sudo rules are successfully stored in cache(Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.net]]] [ipa_sudo_smart_refresh_done] (0x0400): Successful smart refresh of sudo rules(Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.net]]] [be_ptask_done] (0x0400): Task [SUDO Smart Refresh]: finished successfully(Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.net]]] [be_ptask_schedule] (0x0400): Task [SUDO Smart Refresh]: scheduling task 900 seconds from last execution time [1510240137](Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.net]]] [sdap_process_result] (0x2000): Trace: sh[0x55848d200b40], connected[1], ops[(nil)], ldap[0x55848d2272e0](Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.net]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list
On Thursday, November 9, 2017 8:17 AM, Charles Hedrick via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Our sudo is set up to use local files with the rule citing a group, with the group in IPA. sssd gets a fresh groups list for the user at login, so there should be no caching issues. This should be sufficient if you’re just interested in sudo root or a few fairly fixed things. If you’re using sudo in more complex ways and the requirements change a lot, then having the whole thing in IPA would certainly be a win.
On Nov 9, 2017, at 8:48 AM, Andrew Meyer via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote: Ok so I did that and the rules are coming down just like I thought: [user1@jira02 ~]$ sudo -lMatching Defaults entries for rob.lloyd on jira02: !visiblepw, always_set_home, match_group_by_gid, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE 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 user1 may run the following commands on jira02: (ALL : ALL) NOPASSWD: /usr/bin/su - jira,/usr/bin/sudo su - jira,/bin/su - jira,/bin/sudo - jira[user1@jira02 ~]$ But i'm not able to execute...I will look into the debugger and see what I get. This is all new territory for me. If you have any ideas, thank you in advance.
On Thursday, November 9, 2017 1:47 AM, Jakub Hrozek via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On Thu, Nov 09, 2017 at 02:07:03AM +0000, Andrew Meyer via FreeIPA-users wrote:
Hello, I am trying to setup a few of my users to have the ability to su - jira or another user using FreeIPA. Here is what happens when I am logged in as the user and try to su - jira [user1@jira02 ~]$ sudo su - process[sudo] password for user1:Sorry, user user1 is not allowed to execute '/bin/su - jira' as root onjira02.example.net.[user1@jira02 ~]$ [andrew.meyer@jira02 ~]$ ipa sudorule-show su_jira Rule name: su_jira Enabled: TRUE Host category: all RunAs User category: all RunAs Group category: all User Groups: developers, ops_sudoers Sudo Allow Command Groups: jira_access Sudo Option: !authenticate[andrew.meyer@jira02 ~]$
[andrew.meyer@jira02 ~]$ ipa sudocmd-find su_jira_cmds----------------------1 Sudo Command matched---------------------- Sudo Command: /usr/bin/su - jira,/usr/bin/sudo su - jira,/bin/su - jira,/bin/sudo - jira Description: su_jira_cmds----------------------------Number of entries returned 1---------------------------- What am I doing wrong?
I would first run "sudo -l" to see if the user is able to run any sudo commands at all.
Then I'd proceed to sudo debugging from https://docs.pagure.org/SSSD.sssd/users/sudo_troubleshooting.html#obtaining-... to see what data was transferred to sudo and how did sudo evaluate them. _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
_______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
_______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Remember, we don’t have new rules. We just use sudo for sudo to root. So we just have a static rule based on a group, with the group in IPA.
On Nov 9, 2017, at 9:57 AM, Andrew Meyer <andrewm659@yahoo.commailto:andrewm659@yahoo.com> wrote:
Charles, Not sure my boss wants to do it that way. How do you deploy new rules? Puppet, Ansible?
Also here is the logs from sssd:
(Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.nethttp://mgt.stl.exampleblend.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSudoRunAsExtUserGroup] (Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.nethttp://mgt.stl.exampleblend.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [externalUser] (Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.nethttp://mgt.stl.exampleblend.net]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [entryUSN] (Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.nethttp://mgt.stl.exampleblend.net]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 8 (Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.nethttp://mgt.stl.exampleblend.net]]] [sdap_op_add] (0x2000): New operation 8 timeout 6 (Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.nethttp://mgt.stl.exampleblend.net]]] [sdap_process_result] (0x2000): Trace: sh[0x55848d200b40], connected[1], ops[0x55848d265290], ldap[0x55848d2272e0] (Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.nethttp://mgt.stl.exampleblend.net]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.nethttp://mgt.stl.exampleblend.net]]] [sdap_process_result] (0x2000): Trace: sh[0x55848d200b40], connected[1], ops[0x55848d265290], ldap[0x55848d2272e0] (Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.nethttp://mgt.stl.exampleblend.net]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.nethttp://mgt.stl.exampleblend.net]]] [sdap_get_generic_op_finished] (0x2000): Total count [0] (Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.nethttp://mgt.stl.exampleblend.net]]] [sdap_op_destructor] (0x2000): Operation 8 finished (Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.nethttp://mgt.stl.exampleblend.net]]] [sdap_search_bases_ex_done] (0x0400): Receiving data from base [cn=sudo,dc=example,dc=net] (Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.nethttp://mgt.stl.exampleblend.net]]] [ipa_sudo_fetch_rules_done] (0x0040): Received 0 sudo rules (Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.nethttp://mgt.stl.exampleblend.net]]] [ipa_sudo_fetch_cmdgroups] (0x0400): About to fetch sudo command groups (Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.nethttp://mgt.stl.exampleblend.net]]] [ipa_sudo_fetch_cmdgroups] (0x0400): No command groups needs to be downloaded (Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.nethttp://mgt.stl.exampleblend.net]]] [ipa_sudo_fetch_cmds] (0x0400): About to fetch sudo commands (Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.nethttp://mgt.stl.exampleblend.net]]] [ipa_sudo_fetch_cmds] (0x0400): No commands needs to be downloaded (Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.nethttp://mgt.stl.exampleblend.net]]] [ipa_sudo_fetch_done] (0x0400): About to convert rules (Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.nethttp://mgt.stl.exampleblend.net]]] [sysdb_sudo_purge_byrules] (0x0400): About to remove rules from sudo cache (Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.nethttp://mgt.stl.exampleblend.net]]] [sdap_sudo_set_usn] (0x0400): SUDO USN value is empty. (Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.nethttp://mgt.stl.exampleblend.net]]] [ipa_sudo_refresh_done] (0x0400): Sudo rules are successfully stored in cache (Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.nethttp://mgt.stl.exampleblend.net]]] [ipa_sudo_smart_refresh_done] (0x0400): Successful smart refresh of sudo rules (Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.nethttp://mgt.stl.exampleblend.net]]] [be_ptask_done] (0x0400): Task [SUDO Smart Refresh]: finished successfully (Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.nethttp://mgt.stl.exampleblend.net]]] [be_ptask_schedule] (0x0400): Task [SUDO Smart Refresh]: scheduling task 900 seconds from last execution time [1510240137] (Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.nethttp://mgt.stl.exampleblend.net]]] [sdap_process_result] (0x2000): Trace: sh[0x55848d200b40], connected[1], ops[(nil)], ldap[0x55848d2272e0] (Thu Nov 9 08:53:57 2017) [sssd[be[mgt.stl.exampleblend.nethttp://mgt.stl.exampleblend.net]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list
On Thursday, November 9, 2017 8:17 AM, Charles Hedrick via FreeIPA-users <freeipa-users@lists.fedorahosted.orgmailto:freeipa-users@lists.fedorahosted.org> wrote:
Our sudo is set up to use local files with the rule citing a group, with the group in IPA. sssd gets a fresh groups list for the user at login, so there should be no caching issues. This should be sufficient if you’re just interested in sudo root or a few fairly fixed things. If you’re using sudo in more complex ways and the requirements change a lot, then having the whole thing in IPA would certainly be a win.
On Nov 9, 2017, at 8:48 AM, Andrew Meyer via FreeIPA-users <freeipa-users@lists.fedorahosted.orgmailto:freeipa-users@lists.fedorahosted.org> wrote:
Ok so I did that and the rules are coming down just like I thought:
[user1@jira02 ~]$ sudo -l Matching Defaults entries for rob.lloyd on jira02: !visiblepw, always_set_home, match_group_by_gid, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE 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 user1 may run the following commands on jira02: (ALL : ALL) NOPASSWD: /usr/bin/su - jira,/usr/bin/sudo su - jira,/bin/su - jira,/bin/sudo - jira [user1@jira02 ~]$
But i'm not able to execute...I will look into the debugger and see what I get. This is all new territory for me. If you have any ideas, thank you in advance.
On Thursday, November 9, 2017 1:47 AM, Jakub Hrozek via FreeIPA-users <freeipa-users@lists.fedorahosted.orgmailto:freeipa-users@lists.fedorahosted.org> wrote:
On Thu, Nov 09, 2017 at 02:07:03AM +0000, Andrew Meyer via FreeIPA-users wrote:
Hello, I am trying to setup a few of my users to have the ability to su - jira or another user using FreeIPA. Here is what happens when I am logged in as the user and try to su - jira [user1@jira02mailto:user1@jira02 ~]$ sudo su - process[sudo] password for user1:Sorry, user user1 is not allowed to execute '/bin/su - jira' as root on jira02.example.nethttps://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjira02.example.net%2F&data=02%7C01%7Chedrick%40rutgers.edu%7C4d6c855c393e4bc91e4608d5278413e7%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636458370588378514&sdata=AP%2FoLm1lI%2Bqt0UJbKNUuesrn0ISVf79u2qVmODLC4Zw%3D&reserved=0.[user1@jira02mailto:user1@jira02 ~]$ [andrew.meyer@jira02mailto:andrew.meyer@jira02 ~]$ ipa sudorule-show su_jira Rule name: su_jira Enabled: TRUE Host category: all RunAs User category: all RunAs Group category: all User Groups: developers, ops_sudoers Sudo Allow Command Groups: jira_access Sudo Option: !authenticate[andrew.meyer@jira02mailto:andrew.meyer@jira02 ~]$
[andrew.meyer@jira02mailto:andrew.meyer@jira02 ~]$ ipa sudocmd-find su_jira_cmds----------------------1 Sudo Command matched---------------------- Sudo Command: /usr/bin/su - jira,/usr/bin/sudo su - jira,/bin/su - jira,/bin/sudo - jira Description: su_jira_cmds----------------------------Number of entries returned 1---------------------------- What am I doing wrong?
I would first run "sudo -l" to see if the user is able to run any sudo commands at all.
Then I'd proceed to sudo debugging from https://docs.pagure.org/SSSD.sssd/users/sudo_troubleshooting.html#obtaining-...https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.pagure.org%2FSSSD.sssd%2Fusers%2Fsudo_troubleshooting.html%23obtaining-logs&data=02%7C01%7Chedrick%40rutgers.edu%7C0d27a7e55c1544f0577d08d52778b7be%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636458321797558546&sdata=Po8Z%2FCZDAObeD3k%2BW0HRlb00lbcMBPINWVzwyOGSWuo%3D&reserved=0 to see what data was transferred to sudo and how did sudo evaluate them.
_______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.orgmailto:freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.orgmailto:freeipa-users-leave@lists.fedorahosted.org
_______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.orgmailto:freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.orgmailto:freeipa-users-leave@lists.fedorahosted.org
_______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.orgmailto:freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.orgmailto:freeipa-users-leave@lists.fedorahosted.org
Did you try the command as defined in the sudo rule? sudo /usr/bin/su - jira
Also why not just create a sudo rule in IPA with:
Sudo Option:!authenticate User Groups:developers, ops_sudoers Host category: all Sudo Allow Commands: all ----->>>RunAs User category: these will be external users if not controlled through IPA (only on the server), or just select the users and add them RunAs Group category: all
They basically can now run any command as that user... to include becoming them with the following command.Which basically you are saying that anyways with su... sudo -u {user} -i
Yes, This is exactly what I did. However something is weird and the policy is not being activated...maybe its a priority thing?
On Friday, November 10, 2017 7:17 AM, Aaron Cole via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Did you try the command as defined in the sudo rule? sudo /usr/bin/su - jira
Also why not just create a sudo rule in IPA with:
Sudo Option:!authenticate User Groups:developers, ops_sudoers Host category: all Sudo Allow Commands: all ----->>>RunAs User category: these will be external users if not controlled through IPA (only on the server), or just select the users and add them RunAs Group category: all
They basically can now run any command as that user... to include becoming them with the following command.Which basically you are saying that anyways with su... sudo -u {user} -i _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
did you try to setup a new rule with run the user group allowed to run on defined hosts, all commands, as those particular users, and then use sudo -u {user} -i?
I have not done that yet. I will do that though.
On Friday, November 10, 2017 1:54 PM, Aaron Cole via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
did you try to setup a new rule with run the user group allowed to run on defined hosts, all commands, as those particular users, and then use sudo -u {user} -i? _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
i prefer making people use sudo over giving permissions to su. it's purely a preference though...
freeipa-users@lists.fedorahosted.org
-
Aaron Cole -
Andrew Meyer -
Charles Hedrick -
Jakub Hrozek