Re: [Freeipa-users] FreeIPA sudo not working on ububtu xenial sssd version 1.13.4-1ubuntu1.1

[James Harrison]

Hi,Was there any out-come to this?
I running: sudo1.8.12-1ubuntu3, which is well behind up to date releases.
Many thanks,James Harrison

  From: James Harrison <jamesaharriso...@yahoo.co.uk>
 To: "freeipa-users@redhat.com" <freeipa-users@redhat.com>; 
"pbrez...@redhat.com" <pbrez...@redhat.com> 
Cc: "pbrez...@redhat.com" <pbrez...@redhat.com>
 Sent: Monday, 9 January 2017, 15:18
 Subject: Re: [Freeipa-users] FreeIPA sudo not working on ububtu xenial sssd 
version 1.13.4-1ubuntu1.1
   
Hi All,I have attached three files from running sudo -i on the same machine 
enrolled into Free IPA. They have the output from various versions of sudo. 
tail -f sudo_debug, syslog, auth.log and sssd/*.log from /var/log to show 
chronological order of events.

The attached files are: sudo-1.8.19-1.txt --- from Debian
sudo-1.8.16-0ubuntu1.2.txt   --- Current released Xenial sudo
sudo1.8.12-1ubuntu3.txt --- Previous sudo from "wily" 
https://launchpad.net/ubuntu/wily/amd64/sudo/1.8.12-1ubuntu3

The machine's /etc/sudo.conf has:Debug sudo /var/log/sudo_debug all@debug
Debug sudoers.so /var/log/sudo_debug all@debug
Plugin sudoers_policy sudoers.so
Plugin sudoers_io sudoers.so

Hope this helps.
Regards,James Harrison

  From: Lukas Slebodnik <lsleb...@redhat.com>
 To: James Harrison <jamesaharriso...@yahoo.co.uk> 
Cc: "freeipa-users@redhat.com" <freeipa-users@redhat.com>; pbrez...@redhat.com
 Sent: Monday, 9 January 2017, 13:09
 Subject: Re: [Freeipa-users] FreeIPA sudo not working on ububtu xenial sssd 
version 1.13.4-1ubuntu1.1
  
On (09/01/17 12:44), James Harrison wrote:
>All,debian 1.8.19-1 doesnt work, but Ubuntu 1.8.12-1ubuntu3 does.
>
Could you provide sudo logs with 1.8.19-1
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO

sssd log files will be helpfull as well.


LS


   

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

Re: [Freeipa-users] FreeIPA sudo not working on ububtu xenial sssd version 1.13.4-1ubuntu1.1

[Lukas Slebodnik]

On (09/01/17 12:44), James Harrison wrote:
>All,debian 1.8.19-1 doesnt work, but Ubuntu 1.8.12-1ubuntu3 does.
>
Could you provide sudo logs with 1.8.19-1
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO

sssd log files will be helpfull as well.


LS

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

Re: [Freeipa-users] FreeIPA sudo not working on ububtu xenial sssd version 1.13.4-1ubuntu1.1

[James Harrison]

All,debian 1.8.19-1 doesnt work, but Ubuntu 1.8.12-1ubuntu3 does.

James
  From: Lukas Slebodnik <lsleb...@redhat.com>
 To: James Harrison <jamesaharriso...@yahoo.co.uk> 
Cc: "freeipa-users@redhat.com" <freeipa-users@redhat.com>
 Sent: Saturday, 7 January 2017, 15:34
 Subject: Re: [Freeipa-users] FreeIPA sudo not working on ububtu xenial sssd 
version 1.13.4-1ubuntu1.1
   
On (06/01/17 17:15), James Harrison wrote:
>Any ideas?
>      From: James Harrison <jamesaharriso...@yahoo.co.uk>
> To: "freeipa-users@redhat.com" <freeipa-users@redhat.com> 
> Sent: Thursday, 5 January 2017, 13:36
> Subject: FreeIPA sudo not working on ububtu xenial sssd version 
> 1.13.4-1ubuntu1.1
>  
>Hi all,I having problems with a FreeIPA client running Ububtu Xenial.
>I can authenticate OK, I get a kerberos ticket, but cannot run sudo.
>I get 1 rule returned, which I expect.
>Many thanks,James Harrison
>
>
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning 
>info for user [x_james.harri...@domain.com]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_rules] (0x0400): 
>Retrieving rules for [x_james.harrison] from [domain.com]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
>"ltdb_callback": 0x1c11d70
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] 
>(0x0200): Searching sysdb with 
>[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=x_james.harrison)(sudoUser=#1082600012)(sudoUser=%admins)(sudoUser=%ipausers)(sudoUser=%x_james.harrison)(sudoUser=+*))(&(dataExpireTimestamp<=1483618197)))]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About to 
>get sudo rules from cache
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] 
>(0x0200): Searching sysdb with 
>[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=x_james.harrison)(sudoUser=#1082600012)(sudoUser=%admins)(sudoUser=%ipausers)(sudoUser=%x_james.harrison)(sudoUser=+*)))]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sort_sudo_rules] (0x0400): Sorting 
>rules with higher-wins logic
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] 
>(0x0400): Returning 1 rules for [x_james.harri...@domain.com]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [reset_idle_timer] (0x4000): Idle 
>timer re-set for client [0x1c0e770][18]
>
Yes, 1 rule was returned for user x_james.harrison.
Can you see something in output of "sudo -l"


>==> sssd/sssd_pam.log <==
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [get_client_cred] (0x4000): Client 
>creds: euid[0] egid[1082600012] pid[5470].
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
>re-set for client [0x2466e50][19]
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [accept_fd_handler] (0x0400): Client 
>connected!
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
>re-set for client [0x2466e50][19]
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): 
>Received client version [3].
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): Offered 
>version [3].
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
>re-set for client [0x2466e50][19]
>
>==> auth.log <==
>Jan  5 12:10:17 pul-lp-sql-00 sudo: pam_unix(sudo:auth): authentication 
>failure; logname=x_james.harrison uid=1082600012 euid=0 tty=/dev/pts/1 
>ruser=x_james.harrison rhost=  user=x_james.harrison
>
I do not understand a reason why there is a failure in auth.log;
because there isn't sssd_pam.log @see above.

>==> sssd/sssd_pam.log <==
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
>re-set for client [0x2466e50][19]
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_cmd_authenticate] (0x0100): 
>entering pam_cmd_authenticate
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): 
>name 'x_james.harrison' matched without domain, user is x_james.harrison
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): command: 
>SSS_PAM_AUTHENTICATE
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: not 
>set
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): user: 
>x_james.harrison
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): service: sudo
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: 
>/dev/pts/1
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: 
>x_james.harrison
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: not 
>set
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): aut

Re: [Freeipa-users] FreeIPA sudo not working on ububtu xenial sssd version 1.13.4-1ubuntu1.1

[James Harrison]

All,1.8.19-1 from Debian does not appear to work too.
James


  From: Lukas Slebodnik <lsleb...@redhat.com>
 To: James Harrison <jamesaharriso...@yahoo.co.uk> 
Cc: "freeipa-users@redhat.com" <freeipa-users@redhat.com>
 Sent: Saturday, 7 January 2017, 15:34
 Subject: Re: [Freeipa-users] FreeIPA sudo not working on ububtu xenial sssd 
version 1.13.4-1ubuntu1.1
   
On (06/01/17 17:15), James Harrison wrote:
>Any ideas?
>      From: James Harrison <jamesaharriso...@yahoo.co.uk>
> To: "freeipa-users@redhat.com" <freeipa-users@redhat.com> 
> Sent: Thursday, 5 January 2017, 13:36
> Subject: FreeIPA sudo not working on ububtu xenial sssd version 
> 1.13.4-1ubuntu1.1
>  
>Hi all,I having problems with a FreeIPA client running Ububtu Xenial.
>I can authenticate OK, I get a kerberos ticket, but cannot run sudo.
>I get 1 rule returned, which I expect.
>Many thanks,James Harrison
>
>
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning 
>info for user [x_james.harri...@domain.com]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_rules] (0x0400): 
>Retrieving rules for [x_james.harrison] from [domain.com]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
>"ltdb_callback": 0x1c11d70
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] 
>(0x0200): Searching sysdb with 
>[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=x_james.harrison)(sudoUser=#1082600012)(sudoUser=%admins)(sudoUser=%ipausers)(sudoUser=%x_james.harrison)(sudoUser=+*))(&(dataExpireTimestamp<=1483618197)))]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About to 
>get sudo rules from cache
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] 
>(0x0200): Searching sysdb with 
>[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=x_james.harrison)(sudoUser=#1082600012)(sudoUser=%admins)(sudoUser=%ipausers)(sudoUser=%x_james.harrison)(sudoUser=+*)))]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sort_sudo_rules] (0x0400): Sorting 
>rules with higher-wins logic
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] 
>(0x0400): Returning 1 rules for [x_james.harri...@domain.com]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [reset_idle_timer] (0x4000): Idle 
>timer re-set for client [0x1c0e770][18]
>
Yes, 1 rule was returned for user x_james.harrison.
Can you see something in output of "sudo -l"


>==> sssd/sssd_pam.log <==
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [get_client_cred] (0x4000): Client 
>creds: euid[0] egid[1082600012] pid[5470].
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
>re-set for client [0x2466e50][19]
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [accept_fd_handler] (0x0400): Client 
>connected!
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
>re-set for client [0x2466e50][19]
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): 
>Received client version [3].
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): Offered 
>version [3].
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
>re-set for client [0x2466e50][19]
>
>==> auth.log <==
>Jan  5 12:10:17 pul-lp-sql-00 sudo: pam_unix(sudo:auth): authentication 
>failure; logname=x_james.harrison uid=1082600012 euid=0 tty=/dev/pts/1 
>ruser=x_james.harrison rhost=  user=x_james.harrison
>
I do not understand a reason why there is a failure in auth.log;
because there isn't sssd_pam.log @see above.

>==> sssd/sssd_pam.log <==
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
>re-set for client [0x2466e50][19]
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_cmd_authenticate] (0x0100): 
>entering pam_cmd_authenticate
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): 
>name 'x_james.harrison' matched without domain, user is x_james.harrison
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): command: 
>SSS_PAM_AUTHENTICATE
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: not 
>set
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): user: 
>x_james.harrison
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): service: sudo
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: 
>/dev/pts/1
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: 
>x_james.harrison
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: not 
>set
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok 

Re: [Freeipa-users] FreeIPA sudo not working on ububtu xenial sssd version 1.13.4-1ubuntu1.1

[Lukas Slebodnik]

On (06/01/17 17:15), James Harrison wrote:
>Any ideas?
>  From: James Harrison 
> To: "freeipa-users@redhat.com"  
> Sent: Thursday, 5 January 2017, 13:36
> Subject: FreeIPA sudo not working on ububtu xenial sssd version 
> 1.13.4-1ubuntu1.1
>   
>Hi all,I having problems with a FreeIPA client running Ububtu Xenial.
>I can authenticate OK, I get a kerberos ticket, but cannot run sudo.
>I get 1 rule returned, which I expect.
>Many thanks,James Harrison
>
>
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning 
>info for user [x_james.harri...@domain.com]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_rules] (0x0400): 
>Retrieving rules for [x_james.harrison] from [domain.com]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
>"ltdb_callback": 0x1c11d70
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] 
>(0x0200): Searching sysdb with 
>[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=x_james.harrison)(sudoUser=#1082600012)(sudoUser=%admins)(sudoUser=%ipausers)(sudoUser=%x_james.harrison)(sudoUser=+*))(&(dataExpireTimestamp<=1483618197)))]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About to 
>get sudo rules from cache
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] 
>(0x0200): Searching sysdb with 
>[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=x_james.harrison)(sudoUser=#1082600012)(sudoUser=%admins)(sudoUser=%ipausers)(sudoUser=%x_james.harrison)(sudoUser=+*)))]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sort_sudo_rules] (0x0400): Sorting 
>rules with higher-wins logic
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] 
>(0x0400): Returning 1 rules for [x_james.harri...@domain.com]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [reset_idle_timer] (0x4000): Idle 
>timer re-set for client [0x1c0e770][18]
>
Yes, 1 rule was returned for user x_james.harrison.
Can you see something in output of "sudo -l"


>==> sssd/sssd_pam.log <==
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [get_client_cred] (0x4000): Client 
>creds: euid[0] egid[1082600012] pid[5470].
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
>re-set for client [0x2466e50][19]
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [accept_fd_handler] (0x0400): Client 
>connected!
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
>re-set for client [0x2466e50][19]
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): 
>Received client version [3].
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): Offered 
>version [3].
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
>re-set for client [0x2466e50][19]
>
>==> auth.log <==
>Jan  5 12:10:17 pul-lp-sql-00 sudo: pam_unix(sudo:auth): authentication 
>failure; logname=x_james.harrison uid=1082600012 euid=0 tty=/dev/pts/1 
>ruser=x_james.harrison rhost=  user=x_james.harrison
>
I do not understand a reason why there is a failure in auth.log;
because there isn't sssd_pam.log @see above.

>==> sssd/sssd_pam.log <==
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
>re-set for client [0x2466e50][19]
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_cmd_authenticate] (0x0100): 
>entering pam_cmd_authenticate
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): 
>name 'x_james.harrison' matched without domain, user is x_james.harrison
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): command: 
>SSS_PAM_AUTHENTICATE
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: not 
>set
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): user: 
>x_james.harrison
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): service: sudo
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: 
>/dev/pts/1
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: 
>x_james.harrison
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: not 
>set
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok 
>type: 1
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok 
>type: 0
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 0
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 5470
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): logon name: 
>x_james.harrison
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [sss_ncache_check_str] (0x2000): 
>Checking negative cache for [NCE/USER/domain.com/x_james.harrison]
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_initgr_check_timeout] (0x4000): 
>User [x_james.harrison] not found in PAM cache.
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [sss_dp_issue_request] (0x0400): 
>Issuing 

Re: [Freeipa-users] FreeIPA sudo not working on ububtu xenial sssd version 1.13.4-1ubuntu1.1

[James Harrison]

Any ideas?
  From: James Harrison 
 To: "freeipa-users@redhat.com"  
 Sent: Thursday, 5 January 2017, 13:36
 Subject: FreeIPA sudo not working on ububtu xenial sssd version 
1.13.4-1ubuntu1.1
   
Hi all,I having problems with a FreeIPA client running Ububtu Xenial.
I can authenticate OK, I get a kerberos ticket, but cannot run sudo.
I get 1 rule returned, which I expect.
Many thanks,James Harrison


(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Destroying timer event 
0x1c11e30 "ltdb_timeout"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Ending timer event 
0x1c11d70 "ltdb_callback"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning 
info for user [x_james.harri...@domain.com]
(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_rules] (0x0400): 
Retrieving rules for [x_james.harrison] from [domain.com]
(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
"ltdb_callback": 0x1c11d70

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
"ltdb_timeout": 0x1c11e30

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Running timer event 
0x1c11d70 "ltdb_callback"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Destroying timer event 
0x1c11e30 "ltdb_timeout"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Ending timer event 
0x1c11d70 "ltdb_callback"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
"ltdb_callback": 0x1c0f550

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
"ltdb_timeout": 0x1c1da40

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Running timer event 
0x1c0f550 "ltdb_callback"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Destroying timer event 
0x1c1da40 "ltdb_timeout"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Ending timer event 
0x1c0f550 "ltdb_callback"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] 
(0x0200): Searching sysdb with 
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=x_james.harrison)(sudoUser=#1082600012)(sudoUser=%admins)(sudoUser=%ipausers)(sudoUser=%x_james.harrison)(sudoUser=+*))(&(dataExpireTimestamp<=1483618197)))]
(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
"ltdb_callback": 0x1c11d70

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
"ltdb_timeout": 0x1c11e30

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Running timer event 
0x1c11d70 "ltdb_callback"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Destroying timer event 
0x1c11e30 "ltdb_timeout"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Ending timer event 
0x1c11d70 "ltdb_callback"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About to 
get sudo rules from cache
(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
"ltdb_callback": 0x1c18790

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
"ltdb_timeout": 0x1c1b720

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Running timer event 
0x1c18790 "ltdb_callback"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Destroying timer event 
0x1c1b720 "ltdb_timeout"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Ending timer event 
0x1c18790 "ltdb_callback"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
"ltdb_callback": 0x1c12600

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
"ltdb_timeout": 0x1c0f550

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Running timer event 
0x1c12600 "ltdb_callback"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Destroying timer event 
0x1c0f550 "ltdb_timeout"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Ending timer event 
0x1c12600 "ltdb_callback"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] 
(0x0200): Searching sysdb with 
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=x_james.harrison)(sudoUser=#1082600012)(sudoUser=%admins)(sudoUser=%ipausers)(sudoUser=%x_james.harrison)(sudoUser=+*)))]
(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
"ltdb_callback": 0x1c0f550

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
"ltdb_timeout": 0x1c0dfd0

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Running timer event 
0x1c0f550 "ltdb_callback"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Destroying timer event 
0x1c0dfd0 "ltdb_timeout"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Ending timer event 
0x1c0f550 "ltdb_callback"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sort_sudo_rules] (0x0400): Sorting 
rules with higher-wins logic
(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] 
(0x0400): Returning 1 rules for [x_james.harri...@domain.com]

Re: [Freeipa-users] FreeIPA sudo not working on ububtu xenial sssd version 1.13.4-1ubuntu1.1

[Lukas Slebodnik]

On (05/01/17 15:38), Jakub Hrozek wrote:
>On Thu, Jan 05, 2017 at 01:36:56PM +, James Harrison wrote:
>> Hi all,I having problems with a FreeIPA client running Ububtu Xenial.
>> I can authenticate OK, I get a kerberos ticket, but cannot run sudo.
>> I get 1 rule returned, which I expect.
>> Many thanks,James Harrison
>
>I would check if (with the help of ldbsearch against the sssd cache or
>with the help of the sudo logs) if the rule is really the one you are
>expecting or if it's just the cn=defaults rule.
>
>If it's just cn=defaults, then I would check if the rules are downloaded
>(sssd always downloads all rules applicable for the host IIRC) or if
>they just don't match the filter that you can see in the debug message
>from sudosrv_get_sudorules_query_cache. Keep in mind that this is a
>filter that applies for the sssd cache, not LDAP.
>
>And lastly, if the rules are downloaded as expected, the sudo rules
>would tell you why the rule didn't match.
>
>All in all, this document:
>https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO
>describes how to troubleshoot the sudo integration.
>
Or you might check older thread
https://www.redhat.com/archives/freeipa-users/2016-August/msg00489.html

LS

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

Re: [Freeipa-users] FreeIPA sudo not working on ububtu xenial sssd version 1.13.4-1ubuntu1.1

[Jakub Hrozek]

On Thu, Jan 05, 2017 at 01:36:56PM +, James Harrison wrote:
> Hi all,I having problems with a FreeIPA client running Ububtu Xenial.
> I can authenticate OK, I get a kerberos ticket, but cannot run sudo.
> I get 1 rule returned, which I expect.
> Many thanks,James Harrison

I would check if (with the help of ldbsearch against the sssd cache or
with the help of the sudo logs) if the rule is really the one you are
expecting or if it's just the cn=defaults rule.

If it's just cn=defaults, then I would check if the rules are downloaded
(sssd always downloads all rules applicable for the host IIRC) or if
they just don't match the filter that you can see in the debug message
from sudosrv_get_sudorules_query_cache. Keep in mind that this is a
filter that applies for the sssd cache, not LDAP.

And lastly, if the rules are downloaded as expected, the sudo rules
would tell you why the rule didn't match.

All in all, this document:
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO
describes how to troubleshoot the sudo integration.

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

[Freeipa-users] FreeIPA sudo not working on ububtu xenial sssd version 1.13.4-1ubuntu1.1

[James Harrison]

Hi all,I having problems with a FreeIPA client running Ububtu Xenial.
I can authenticate OK, I get a kerberos ticket, but cannot run sudo.
I get 1 rule returned, which I expect.
Many thanks,James Harrison


(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Destroying timer event 
0x1c11e30 "ltdb_timeout"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Ending timer event 
0x1c11d70 "ltdb_callback"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning 
info for user [x_james.harri...@domain.com]
(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_rules] (0x0400): 
Retrieving rules for [x_james.harrison] from [domain.com]
(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
"ltdb_callback": 0x1c11d70

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
"ltdb_timeout": 0x1c11e30

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Running timer event 
0x1c11d70 "ltdb_callback"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Destroying timer event 
0x1c11e30 "ltdb_timeout"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Ending timer event 
0x1c11d70 "ltdb_callback"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
"ltdb_callback": 0x1c0f550

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
"ltdb_timeout": 0x1c1da40

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Running timer event 
0x1c0f550 "ltdb_callback"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Destroying timer event 
0x1c1da40 "ltdb_timeout"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Ending timer event 
0x1c0f550 "ltdb_callback"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] 
(0x0200): Searching sysdb with 
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=x_james.harrison)(sudoUser=#1082600012)(sudoUser=%admins)(sudoUser=%ipausers)(sudoUser=%x_james.harrison)(sudoUser=+*))(&(dataExpireTimestamp<=1483618197)))]
(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
"ltdb_callback": 0x1c11d70

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
"ltdb_timeout": 0x1c11e30

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Running timer event 
0x1c11d70 "ltdb_callback"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Destroying timer event 
0x1c11e30 "ltdb_timeout"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Ending timer event 
0x1c11d70 "ltdb_callback"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About to 
get sudo rules from cache
(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
"ltdb_callback": 0x1c18790

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
"ltdb_timeout": 0x1c1b720

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Running timer event 
0x1c18790 "ltdb_callback"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Destroying timer event 
0x1c1b720 "ltdb_timeout"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Ending timer event 
0x1c18790 "ltdb_callback"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
"ltdb_callback": 0x1c12600

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
"ltdb_timeout": 0x1c0f550

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Running timer event 
0x1c12600 "ltdb_callback"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Destroying timer event 
0x1c0f550 "ltdb_timeout"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Ending timer event 
0x1c12600 "ltdb_callback"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] 
(0x0200): Searching sysdb with 
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=x_james.harrison)(sudoUser=#1082600012)(sudoUser=%admins)(sudoUser=%ipausers)(sudoUser=%x_james.harrison)(sudoUser=+*)))]
(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
"ltdb_callback": 0x1c0f550

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
"ltdb_timeout": 0x1c0dfd0

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Running timer event 
0x1c0f550 "ltdb_callback"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Destroying timer event 
0x1c0dfd0 "ltdb_timeout"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Ending timer event 
0x1c0f550 "ltdb_callback"

(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sort_sudo_rules] (0x0400): Sorting 
rules with higher-wins logic
(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] 
(0x0400): Returning 1 rules for [x_james.harri...@domain.com]
(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [reset_idle_timer] (0x4000): Idle timer 
re-set for client [0x1c0e770][18]

==> sssd/sssd.log <==
(Thu Jan  5 12:10:00 2017) [sssd] [service_send_ping] (0x2000): Pinging 
domain.com
(Thu Jan  5 12:10:00 2017) [sssd] 

Re: [Freeipa-users] Freeipa Sudo / sudoers.d / nopasswd

[Alexander Bokovoy]

On Tue, 05 Apr 2016, Ash Alam wrote:

I wanted to follow up on this. Since sudo needs to be added to sssd.conf
and nsswitch.conf. Is it possible to add the options via
ipa-client-install? I can do the same with chef but this seems like
something that should be done with ipa?

$ ipa-client-install --help|grep sudo
   --no-sudo   do not configure SSSD as data source for sudo

By default IPA 4.x configures SSSD for sudo.

--
/ Alexander Bokovoy

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

Re: [Freeipa-users] Freeipa Sudo / sudoers.d / nopasswd

[Ash Alam]

I wanted to follow up on this. Since sudo needs to be added to sssd.conf
and nsswitch.conf. Is it possible to add the options via
ipa-client-install? I can do the same with chef but this seems like
something that should be done with ipa?

Thank You

On Thu, Mar 24, 2016 at 4:51 PM, Christophe TREFOIS <
christophe.tref...@uni.lu> wrote:

> Hi,
>
>
>
> Are you not missing “sudo” in [sssd] and did you restard the services on
> the machine? We found quite a significant cache, which sometimes lead to
> asking passwords.
>
>
>
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-ldap-sudo.html
>
>
>
> You might even have to delete /var/lib/sss/db/ contents and restart sssd.
>
>
>
> Best,
>
>
>
> *From:* freeipa-users-boun...@redhat.com [mailto:
> freeipa-users-boun...@redhat.com] *On Behalf Of *Ash Alam
> *Sent:* jeudi 24 mars 2016 19:50
> *To:* Jakub Hrozek <jhro...@redhat.com>
> *Cc:* freeipa-users@redhat.com
> *Subject:* Re: [Freeipa-users] Freeipa Sudo / sudoers.d / nopasswd
>
>
>
> Based on (How to troubleshoot Sudo)
>
>
>
> - Maybe i miss spoke when i said it fails completely. Rather it keeps
> asking for the users password which it does not accept.
>
> - I do not have sudo in sssd.conf
>
> - I do not have sudoers: sss defined in nsswitch.conf
>
> - Per Fedora/Freeipa doc (Defining Sudo), its not immediately clear if
> these needs to be defined
>
> - If this is the case then adding them might resolve my issues.
>
> - for the special sudo rule(s). is there any way to track it via the gui?
> I am trying to keep track of all the configs so its not a blackhole for the
> next person.
>
>
>
> - This is what it looks like on the web gui
>
> [image: Inline image 1]
>
>
>
>
>
> - This is what a clients sssd.conf looks like
>
> [domain/x]
>
>
>
> cache_credentials = True
>
> krb5_store_password_if_offline = True
>
> ipa_domain = pp
>
> id_provider = ipa
>
> auth_provider = ipa
>
> access_provider = ipa
>
> ipa_hostname = xx
>
> chpass_provider = ipa
>
> ipa_server = _srv_, x
>
> ldap_tls_cacert = /etc/ipa/ca.crt
>
> [sssd]
>
> services = nss, pam, ssh
>
> config_file_version = 2
>
>
>
> domains = X
>
> [nss]
>
> homedir_substring = /home
>
>
>
> [pam]
>
> [sudo]
>
> [autofs]
>
> [ssh]
>
> [pac]
>
> [ifp]
>
>
>
> On Thu, Mar 24, 2016 at 1:01 PM, Jakub Hrozek <jhro...@redhat.com> wrote:
>
>
> > On 24 Mar 2016, at 17:21, Ash Alam <aa...@paperlesspost.com> wrote:
> >
> > Hello
> >
> > I am looking for some guidance on how to properly do sudo with Freeipa.
> I have read up on what i need to do but i cant seem to get to work
> correctly. Now with sudoers.d i can accomplish this fairly quickly.
> >
> > Example:
> >
> > %dev ALL=(ALL) NOPASSWD:/usr/bin/chef-client
> >
> > What i have configured in Freeipa Sudo Rules:
> >
> > Sudo Option: !authenticate
> > Who: dev (group)
> > Access this host: testing (group)
> > Run Commands: set of commands that are defined.
> >
> > Now when i apply this, it still does not work as it asks for a password
> for the user and then fails. I am hoping to allow a group to only run
> certain commands without requiring password.
> >
>
> You should first find out why sudo fails completely. We have this guide
> that should help you:
> https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO
>
> About asking for passwords -- defining a special sudo rule called
> 'defaults' and then adding '!authenticate' should help:
>  Add a special Sudo rule for default Sudo server configuration:
>ipa sudorule-add defaults
>
>  Set a default Sudo option:
>ipa sudorule-add-option defaults --sudooption '!authenticate'
>
>
>
-- 
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

Re: [Freeipa-users] Freeipa Sudo / sudoers.d / nopasswd

[Christophe TREFOIS]

Hi,

Are you not missing “sudo” in [sssd] and did you restard the services on the 
machine? We found quite a significant cache, which sometimes lead to asking 
passwords.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-ldap-sudo.html


You might even have to delete /var/lib/sss/db/ contents and restart sssd.



Best,

From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Ash Alam
Sent: jeudi 24 mars 2016 19:50
To: Jakub Hrozek <jhro...@redhat.com>
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Freeipa Sudo / sudoers.d / nopasswd

Based on (How to troubleshoot Sudo)

- Maybe i miss spoke when i said it fails completely. Rather it keeps asking 
for the users password which it does not accept.
- I do not have sudo in sssd.conf
- I do not have sudoers: sss defined in nsswitch.conf
- Per Fedora/Freeipa doc (Defining Sudo), its not immediately clear if these 
needs to be defined
- If this is the case then adding them might resolve my issues.
- for the special sudo rule(s). is there any way to track it via the gui? I am 
trying to keep track of all the configs so its not a blackhole for the next 
person.

- This is what it looks like on the web gui
[Inline image 1]


- This is what a clients sssd.conf looks like
[domain/x]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = pp
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = xx
chpass_provider = ipa
ipa_server = _srv_, x
ldap_tls_cacert = /etc/ipa/ca.crt
[sssd]
services = nss, pam, ssh
config_file_version = 2

domains = X
[nss]
homedir_substring = /home

[pam]
[sudo]
[autofs]
[ssh]
[pac]
[ifp]

On Thu, Mar 24, 2016 at 1:01 PM, Jakub Hrozek 
<jhro...@redhat.com<mailto:jhro...@redhat.com>> wrote:

> On 24 Mar 2016, at 17:21, Ash Alam 
> <aa...@paperlesspost.com<mailto:aa...@paperlesspost.com>> wrote:
>
> Hello
>
> I am looking for some guidance on how to properly do sudo with Freeipa. I 
> have read up on what i need to do but i cant seem to get to work correctly. 
> Now with sudoers.d i can accomplish this fairly quickly.
>
> Example:
>
> %dev ALL=(ALL) NOPASSWD:/usr/bin/chef-client
>
> What i have configured in Freeipa Sudo Rules:
>
> Sudo Option: !authenticate
> Who: dev (group)
> Access this host: testing (group)
> Run Commands: set of commands that are defined.
>
> Now when i apply this, it still does not work as it asks for a password for 
> the user and then fails. I am hoping to allow a group to only run certain 
> commands without requiring password.
>

You should first find out why sudo fails completely. We have this guide that 
should help you:
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO

About asking for passwords -- defining a special sudo rule called 'defaults' 
and then adding '!authenticate' should help:
 Add a special Sudo rule for default Sudo server configuration:
   ipa sudorule-add defaults

 Set a default Sudo option:
   ipa sudorule-add-option defaults --sudooption '!authenticate'

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

Re: [Freeipa-users] Freeipa Sudo / sudoers.d / nopasswd

[Ash Alam]

I should clarify. I was just following the fedora/ipa docs. My Ipa servers
are Centos 7.2 and Ipa 4.2. Clients are Centos 6.6 and 3.0.0

$ rpm -q sssd ipa-client
sssd-1.11.6-30.el6_6.3.x86_64
ipa-client-3.0.0-42.el6.centos.x86_64

On Thu, Mar 24, 2016 at 3:04 PM, Rob Crittenden  wrote:

> Ash Alam wrote:
>
>> Based on (How to troubleshoot Sudo)
>>
>> - Maybe i miss spoke when i said it fails completely. Rather it keeps
>> asking for the users password which it does not accept.
>> - I do not have sudo in sssd.conf
>> - I do not have sudoers: sss defined in nsswitch.conf
>> - Per Fedora/Freeipa doc (Defining Sudo), its not immediately clear if
>> these needs to be defined
>> - If this is the case then adding them might resolve my issues.
>> - for the special sudo rule(s). is there any way to track it via the
>> gui? I am trying to keep track of all the configs so its not a blackhole
>> for the next person.
>>
>
> It would help to know the release of Fedora you're using, the rpm version
> of ipa-client and sssd.
>
> If you are using Fedora freeipa docs they are extremely old, at best F-18.
> Use the RHEL docs.
>
> rob
>
>
>> - This is what it looks like on the web gui
>> Inline image 1
>>
>>
>> - This is what a clients sssd.conf looks like
>> [domain/x]
>>
>> cache_credentials = True
>> krb5_store_password_if_offline = True
>> ipa_domain = pp
>> id_provider = ipa
>> auth_provider = ipa
>> access_provider = ipa
>> ipa_hostname = xx
>> chpass_provider = ipa
>> ipa_server = _srv_, x
>> ldap_tls_cacert = /etc/ipa/ca.crt
>> [sssd]
>> services = nss, pam, ssh
>> config_file_version = 2
>>
>> domains = X
>> [nss]
>> homedir_substring = /home
>>
>> [pam]
>> [sudo]
>> [autofs]
>> [ssh]
>> [pac]
>> [ifp]
>>
>> On Thu, Mar 24, 2016 at 1:01 PM, Jakub Hrozek > > wrote:
>>
>>
>> > On 24 Mar 2016, at 17:21, Ash Alam > > wrote:
>> >
>> > Hello
>> >
>> > I am looking for some guidance on how to properly do sudo with
>> Freeipa. I have read up on what i need to do but i cant seem to get to work
>> correctly. Now with sudoers.d i can accomplish this fairly quickly.
>> >
>> > Example:
>> >
>> > %dev ALL=(ALL) NOPASSWD:/usr/bin/chef-client
>> >
>> > What i have configured in Freeipa Sudo Rules:
>> >
>> > Sudo Option: !authenticate
>> > Who: dev (group)
>> > Access this host: testing (group)
>> > Run Commands: set of commands that are defined.
>> >
>> > Now when i apply this, it still does not work as it asks for a
>> password for the user and then fails. I am hoping to allow a group to only
>> run certain commands without requiring password.
>> >
>>
>> You should first find out why sudo fails completely. We have this
>> guide that should help you:
>> https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO
>>
>> About asking for passwords -- defining a special sudo rule called
>> 'defaults' and then adding '!authenticate' should help:
>>   Add a special Sudo rule for default Sudo server configuration:
>> ipa sudorule-add defaults
>>
>>   Set a default Sudo option:
>> ipa sudorule-add-option defaults --sudooption '!authenticate'
>>
>>
>>
>>
>>
>
-- 
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

Re: [Freeipa-users] Freeipa Sudo / sudoers.d / nopasswd

[Rob Crittenden]

Ash Alam wrote:

Based on (How to troubleshoot Sudo)

- Maybe i miss spoke when i said it fails completely. Rather it keeps
asking for the users password which it does not accept.
- I do not have sudo in sssd.conf
- I do not have sudoers: sss defined in nsswitch.conf
- Per Fedora/Freeipa doc (Defining Sudo), its not immediately clear if
these needs to be defined
- If this is the case then adding them might resolve my issues.
- for the special sudo rule(s). is there any way to track it via the
gui? I am trying to keep track of all the configs so its not a blackhole
for the next person.


It would help to know the release of Fedora you're using, the rpm 
version of ipa-client and sssd.


If you are using Fedora freeipa docs they are extremely old, at best 
F-18. Use the RHEL docs.


rob



- This is what it looks like on the web gui
Inline image 1


- This is what a clients sssd.conf looks like
[domain/x]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = pp
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = xx
chpass_provider = ipa
ipa_server = _srv_, x
ldap_tls_cacert = /etc/ipa/ca.crt
[sssd]
services = nss, pam, ssh
config_file_version = 2

domains = X
[nss]
homedir_substring = /home

[pam]
[sudo]
[autofs]
[ssh]
[pac]
[ifp]

On Thu, Mar 24, 2016 at 1:01 PM, Jakub Hrozek > wrote:


> On 24 Mar 2016, at 17:21, Ash Alam > wrote:
>
> Hello
>
> I am looking for some guidance on how to properly do sudo with Freeipa. I 
have read up on what i need to do but i cant seem to get to work correctly. Now 
with sudoers.d i can accomplish this fairly quickly.
>
> Example:
>
> %dev ALL=(ALL) NOPASSWD:/usr/bin/chef-client
>
> What i have configured in Freeipa Sudo Rules:
>
> Sudo Option: !authenticate
> Who: dev (group)
> Access this host: testing (group)
> Run Commands: set of commands that are defined.
>
> Now when i apply this, it still does not work as it asks for a password 
for the user and then fails. I am hoping to allow a group to only run certain 
commands without requiring password.
>

You should first find out why sudo fails completely. We have this
guide that should help you:
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO

About asking for passwords -- defining a special sudo rule called
'defaults' and then adding '!authenticate' should help:
  Add a special Sudo rule for default Sudo server configuration:
ipa sudorule-add defaults

  Set a default Sudo option:
ipa sudorule-add-option defaults --sudooption '!authenticate'






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

Re: [Freeipa-users] Freeipa Sudo / sudoers.d / nopasswd

[Ash Alam]

Based on (How to troubleshoot Sudo)

- Maybe i miss spoke when i said it fails completely. Rather it keeps
asking for the users password which it does not accept.
- I do not have sudo in sssd.conf
- I do not have sudoers: sss defined in nsswitch.conf
- Per Fedora/Freeipa doc (Defining Sudo), its not immediately clear if
these needs to be defined
- If this is the case then adding them might resolve my issues.
- for the special sudo rule(s). is there any way to track it via the gui? I
am trying to keep track of all the configs so its not a blackhole for the
next person.

- This is what it looks like on the web gui
[image: Inline image 1]


- This is what a clients sssd.conf looks like
[domain/x]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = pp
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = xx
chpass_provider = ipa
ipa_server = _srv_, x
ldap_tls_cacert = /etc/ipa/ca.crt
[sssd]
services = nss, pam, ssh
config_file_version = 2

domains = X
[nss]
homedir_substring = /home

[pam]
[sudo]
[autofs]
[ssh]
[pac]
[ifp]

On Thu, Mar 24, 2016 at 1:01 PM, Jakub Hrozek  wrote:

>
> > On 24 Mar 2016, at 17:21, Ash Alam  wrote:
> >
> > Hello
> >
> > I am looking for some guidance on how to properly do sudo with Freeipa.
> I have read up on what i need to do but i cant seem to get to work
> correctly. Now with sudoers.d i can accomplish this fairly quickly.
> >
> > Example:
> >
> > %dev ALL=(ALL) NOPASSWD:/usr/bin/chef-client
> >
> > What i have configured in Freeipa Sudo Rules:
> >
> > Sudo Option: !authenticate
> > Who: dev (group)
> > Access this host: testing (group)
> > Run Commands: set of commands that are defined.
> >
> > Now when i apply this, it still does not work as it asks for a password
> for the user and then fails. I am hoping to allow a group to only run
> certain commands without requiring password.
> >
>
> You should first find out why sudo fails completely. We have this guide
> that should help you:
> https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO
>
> About asking for passwords -- defining a special sudo rule called
> 'defaults' and then adding '!authenticate' should help:
>  Add a special Sudo rule for default Sudo server configuration:
>ipa sudorule-add defaults
>
>  Set a default Sudo option:
>ipa sudorule-add-option defaults --sudooption '!authenticate'
-- 
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

Re: [Freeipa-users] Freeipa Sudo / sudoers.d / nopasswd

[Brad Bendy]

What's your config look like in the GUI? Long as you assign the users
to the group and everything it should work. Your sssd.conf file shows
sudo in there as well?

On Thu, Mar 24, 2016 at 9:21 AM, Ash Alam  wrote:
> Hello
>
> I am looking for some guidance on how to properly do sudo with Freeipa. I
> have read up on what i need to do but i cant seem to get to work correctly.
> Now with sudoers.d i can accomplish this fairly quickly.
>
> Example:
>
> %dev ALL=(ALL) NOPASSWD:/usr/bin/chef-client
>
> What i have configured in Freeipa Sudo Rules:
>
> Sudo Option: !authenticate
> Who: dev (group)
> Access this host: testing (group)
> Run Commands: set of commands that are defined.
>
> Now when i apply this, it still does not work as it asks for a password for
> the user and then fails. I am hoping to allow a group to only run certain
> commands without requiring password.
>
> Thank You
>
> --
> 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

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

Re: [Freeipa-users] Freeipa Sudo / sudoers.d / nopasswd

[Jakub Hrozek]

> On 24 Mar 2016, at 17:21, Ash Alam  wrote:
> 
> Hello
> 
> I am looking for some guidance on how to properly do sudo with Freeipa. I 
> have read up on what i need to do but i cant seem to get to work correctly. 
> Now with sudoers.d i can accomplish this fairly quickly.
> 
> Example:
> 
> %dev ALL=(ALL) NOPASSWD:/usr/bin/chef-client
> 
> What i have configured in Freeipa Sudo Rules:
> 
> Sudo Option: !authenticate
> Who: dev (group)
> Access this host: testing (group)
> Run Commands: set of commands that are defined.
> 
> Now when i apply this, it still does not work as it asks for a password for 
> the user and then fails. I am hoping to allow a group to only run certain 
> commands without requiring password.
> 

You should first find out why sudo fails completely. We have this guide that 
should help you:
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO

About asking for passwords -- defining a special sudo rule called 'defaults' 
and then adding '!authenticate' should help:
 Add a special Sudo rule for default Sudo server configuration:
   ipa sudorule-add defaults

 Set a default Sudo option:
   ipa sudorule-add-option defaults --sudooption '!authenticate'

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

[Freeipa-users] Freeipa Sudo / sudoers.d / nopasswd

[Ash Alam]

Hello

I am looking for some guidance on how to properly do sudo with Freeipa. I
have read up on what i need to do but i cant seem to get to work correctly.
Now with sudoers.d i can accomplish this fairly quickly.

Example:

%dev ALL=(ALL) NOPASSWD:/usr/bin/chef-client

What i have configured in Freeipa Sudo Rules:

Sudo Option: !authenticate
Who: dev (group)
Access this host: testing (group)
Run Commands: set of commands that are defined.

Now when i apply this, it still does not work as it asks for a password for
the user and then fails. I am hoping to allow a group to only run certain
commands without requiring password.

Thank You
-- 
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

[Freeipa-users] [FreeIPA] SUDO fails with system error

[Markus.Moj]

Dear @all,

 

I´ve an issue with two, Oracle Linux based, clients and my freeipa server. I 
can authenticate on any on the enrolled machines but the two oracle server 
aren´t able to access sudo and I don´t know why.

Here are a few thing I´ve already figured out.

 

Both machines are enrolled from scratch and I see following entries in 
ldap_child.log

(Thu Oct  1 12:51:52 2015) [[sssd[ldap_child[3933 [ldap_child_get_tgt_sync] 
(0x0010): Failed to init credentials: Client 'host/@' not 
found in Kerberos database

(Thu Oct  1 12:51:52 2015) [[sssd[ldap_child[3934 [ldap_child_get_tgt_sync] 
(0x0010): Failed to init credentials: Client 'host/@' not 
found in Kerberos database

 

Furthermore I get following entries in secure log

pam_unix(sudo:auth): authentication failure; logname= uid=95741 
euid=0 tty=/dev/pts/1 ruser= rhost=  user=

pam_sss(sudo:auth): authentication failure; logname= uid=95741 
euid=0 tty=/dev/pts/1 ruser= rhost= user=

pam_sss(sudo:auth): received for user : 4 (System error)

 

Also I get following entries in sssd_pam.log

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_check_user_search] (0x0400): 
Returning info for user [@]

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_initgr_cache_set] (0x2000): 
[] added to PAM initgroup cache

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending 
request with the following data:

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): command: 
PAM_AUTHENTICATE

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: 


(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): user: 


(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sudo

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: 
/dev/pts/1

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: 


(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: not set

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 
1

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok 
type: 0

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 0

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 6457

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_print_data] (0x0100): logon name: 


(Thu Oct  1 14:06:14 2015) [sssd[pam]] [sbus_add_timeout] (0x2000): 
0x7f0d05f51ab0

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): 
pam_dp_send_req returned 0

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [sss_dp_req_destructor] (0x0400): 
Deleting request: [0x7f0d04221ed0:3:@]

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [sbus_remove_timeout] (0x2000): 
0x7f0d05f51ab0

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 
0x7f0d05f479e0

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching.

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100): 
received: [4][]

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply called 
with result [4].

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [pam_reply] (0x0200): blen: 26

(Thu Oct  1 14:06:14 2015) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
re-set for client [0x7f0d05f51110][20]

(Thu Oct  1 14:06:17 2015) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
re-set for client [0x7f0d05f51110][20]

(Thu Oct  1 14:06:17 2015) [sssd[pam]] [pam_cmd_authenticate] (0x0100): 
entering pam_cmd_authenticate

 

In krb5_child.log I get following entries

(Thu Oct  1 14:06:14 2015) [[sssd[krb5_child[6458 [main] (0x0400): 
krb5_child started.

(Thu Oct  1 14:06:14 2015) [[sssd[krb5_child[6458 [unpack_buffer] (0x1000): 
total buffer size: [129]

(Thu Oct  1 14:06:14 2015) [[sssd[krb5_child[6458 [unpack_buffer] (0x0100): 
cmd [241] uid [95741] gid [95741] validate [true] enterprise principal 
[false] offline [false] UPN [@]

(Thu Oct  1 14:06:14 2015) [[sssd[krb5_child[6458 [unpack_buffer] (0x2000): 
No old ccache

(Thu Oct  1 14:06:14 2015) [[sssd[krb5_child[6458 [unpack_buffer] (0x0100): 
ccname: [KEYRING:persistent:95741] old_ccname: [not set] keytab: 
[/etc/krb5.keytab]

(Thu Oct  1 14:06:14 2015) [[sssd[krb5_child[6458 [k5c_precreate_ccache] 
(0x4000): Recreating ccache

(Thu Oct  1 14:06:14 2015) [[sssd[krb5_child[6458 [k5c_setup_fast] 
(0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/@]

(Thu Oct  1 14:06:14 2015) [[sssd[krb5_child[6458 
[find_principal_in_keytab] (0x4000): Trying to find principal 
host/@ in keytab.

(Thu Oct  1 14:06:14 2015) [[sssd[krb5_child[6458 [match_principal] 
(0x1000): Principal matched to the sample (host/@).

(Thu Oct  1 14:06:14 2015) [[sssd[krb5_child[6458 [check_fast_ccache] 
(0x0200): FAST TGT is still valid.

(Thu Oct  1 14:06:14 2015) [[sssd[krb5_child[6458 [become_user] (0x0200): 
Trying to become user [95741][95741].

(Thu Oct  1 14:06:14 

Re: [Freeipa-users] [FreeIPA] SUDO fails with system error

[Jakub Hrozek]

On Thu, Oct 01, 2015 at 12:14:34PM +, markus@mc.ingenico.com wrote:
> Dear @all,
> 
>  
> 
> I´ve an issue with two, Oracle Linux based, clients and my freeipa server. I 
> can authenticate on any on the enrolled machines but the two oracle server 
> aren´t able to access sudo and I don´t know why.
  ~~~
What version of OEL and sssd?

> 
> Here are a few thing I´ve already figured out.
> 
>  
> 
> Both machines are enrolled from scratch and I see following entries in 
> ldap_child.log
> 
> (Thu Oct  1 12:51:52 2015) [[sssd[ldap_child[3933 
> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Client 
> 'host/@' not found in Kerberos database
> 
> (Thu Oct  1 12:51:52 2015) [[sssd[ldap_child[3934 
> [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Client 
> 'host/@' not found in Kerberos database

This looks like the enrollment is not correct, are you able to kinit -k
?

> 
>  
> 
> Furthermore I get following entries in secure log
> 
> pam_unix(sudo:auth): authentication failure; logname= uid=95741 
> euid=0 tty=/dev/pts/1 ruser= rhost=  user=
> 
> pam_sss(sudo:auth): authentication failure; logname= uid=95741 
> euid=0 tty=/dev/pts/1 ruser= rhost= user=
> 
> pam_sss(sudo:auth): received for user : 4 (System error)

You said you were able to authenticate, but here the authentication is
throwing system error. How did you authenticate, was it maye with ssh
keys?

Is that all you have in krb5_child.log? I don't see the child exiting in
the logs..

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

Re: [Freeipa-users] FreeIPA Sudo Error: Resource temporarily unavailable

[Lukas Slebodnik]

On (01/09/15 18:18), Yogesh Sharma wrote:
>Hi,
>
>This is fixed. On digging more found that my resolv.conf was updated and it
>was not able to find the domain. Fixing the resolv.conf with right
>nameserver, fixed the issue.
>
I know it was solved but you would not miss important debug
message with lover debug level.

>>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_issue_request] (0x0400):
>>> Issuing request for [0x40bc10:3:vg4...@klikpay.int]
>>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_get_account_msg]
>>> (0x0400): Creating request for [klikpay.int][3][1][name=vg4381]
>>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_internal_get_send]
>>> (0x0400): Entering request [0x40bc10:3:vg4...@klikpay.int]
>>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_check_user_dp_callback]
>>> (0x0020): Unable to get information from Data Provider
>>> Error: 1, 11, Offline
sssd was in offine mode because it was not able to connect to IPA server.

LS

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

Re: [Freeipa-users] FreeIPA Sudo Error: Resource temporarily unavailable

[Yogesh Sharma]

Even the users details are not coming:

[root@btservice-mysql-prd-ng2-01 sssd]# id vg4381
id: vg4381: No such user
[root@btservice-mysql-prd-ng2-01 sssd]# getent passwd vg4381
[root@btservice-mysql-prd-ng2-01 sssd]#


*Best Regards,*

*__*

*Yogesh Sharma*
*Email: yks0...@gmail.com  | Web: www.initd.in
 *

*RHCE, VCE-CIA, RACKSPACE CLOUD U Certified*

   



On Tue, Sep 1, 2015 at 5:05 PM, Yogesh Sharma  wrote:

> Hi,
>
> We are getting below error while user try to do sudo, while it work for
> old users.
>
>
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [client_recv] (0x0200): Client
> disconnected!
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [accept_fd_handler] (0x0400):
> Client connected!
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
> Received client version [1].
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
> Offered version [1].
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_parse_name_for_domains]
> (0x0200): name 'vg4381' matched without domain, user is vg4381
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_parse_name_for_domains]
> (0x0200): name 'vg4381' matched without domain, user is vg4381
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
> (0x0200): Requesting default options for [vg4381] from []
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):
> Requesting info about [vg4...@klikpay.int]
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_issue_request] (0x0400):
> Issuing request for [0x40bc10:3:vg4...@klikpay.int]
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_get_account_msg] (0x0400):
> Creating request for [klikpay.int][3][1][name=vg4381]
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_internal_get_send]
> (0x0400): Entering request [0x40bc10:3:vg4...@klikpay.int]
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_check_user_dp_callback]
> (0x0020): Unable to get information from Data Provider
> Error: 1, 11, Offline
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):
> Requesting info about [vg4...@klikpay.int]
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_get_user] (0x0400):
> Returning info for user [vg4...@klikpay.int]
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_get_rules] (0x0400):
> Retrieving default options for [vg4381] from [klikpay.int]
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]]
> [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=vg4381)(sudoUser=#465600011)(sudoUser=%dbausers)(sudoUser=%vg4381)(sudoUser=+*))(&(dataExpireTimestamp<=1441107001)))]
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_issue_request] (0x0400):
> Issuing request for [0x407380:0:1:vg4...@klikpay.int]
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_get_sudoers_msg] (0x0400):
> Creating SUDOers request for [klikpay.int][7][vg4381][1]
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_internal_get_send]
> (0x0400): Entering request [0x407380:0:1:vg4...@klikpay.int]
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_req_destructor] (0x0400):
> Deleting request: [0x40bc10:3:vg4...@klikpay.int]
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]]
> [sudosrv_get_sudorules_dp_callback] (0x0020): Unable to get information
> from Data Provider
> Error: 1, 11, Resource temporarily unavailable
> Will try to return what we have in cache
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]]
> [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
> [(&(objectClass=sudoRule)(|(name=defaults)))]
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_get_sudorules_from_cache]
> (0x0400): Returning 0 rules for [@klikpay.int]
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_req_destructor] (0x0400):
> Deleting request: [0x407380:0:1:vg4...@klikpay.int]
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_parse_name_for_domains]
> (0x0200): name 'vg4381' matched without domain, user is vg4381
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_parse_name_for_domains]
> (0x0200): name 'vg4381' matched without domain, user is vg4381
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
> (0x0200): Requesting rules for [vg4381] from []
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):
> Requesting info about [vg4...@klikpay.int]
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_issue_request] (0x0400):
> Issuing request for [0x40bc10:3:vg4...@klikpay.int]
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_get_account_msg] (0x0400):
> Creating request for [klikpay.int][3][1][name=vg4381]
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_internal_get_send]
> (0x0400): Entering request [0x40bc10:3:vg4...@klikpay.int]
> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] 

Re: [Freeipa-users] FreeIPA Sudo Error: Resource temporarily unavailable

[Yogesh Sharma]

Hi,

This is fixed. On digging more found that my resolv.conf was updated and it
was not able to find the domain. Fixing the resolv.conf with right
nameserver, fixed the issue.



*Best Regards,*

*__*

*Yogesh Sharma*
*Email: yks0...@gmail.com  | Web: www.initd.in
 *

*RHCE, VCE-CIA, RACKSPACE CLOUD U Certified*

   



On Tue, Sep 1, 2015 at 5:54 PM, Yogesh Sharma  wrote:

> Even the users details are not coming:
>
> [root@btservice-mysql-prd-ng2-01 sssd]# id vg4381
> id: vg4381: No such user
> [root@btservice-mysql-prd-ng2-01 sssd]# getent passwd vg4381
> [root@btservice-mysql-prd-ng2-01 sssd]#
>
>
> *Best Regards,*
>
> *__*
>
> *Yogesh Sharma*
> *Email: yks0...@gmail.com  | Web: www.initd.in
>  *
>
> *RHCE, VCE-CIA, RACKSPACE CLOUD U Certified*
>
>    
> 
> 
>
> On Tue, Sep 1, 2015 at 5:05 PM, Yogesh Sharma  wrote:
>
>> Hi,
>>
>> We are getting below error while user try to do sudo, while it work for
>> old users.
>>
>>
>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [client_recv] (0x0200): Client
>> disconnected!
>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [accept_fd_handler] (0x0400):
>> Client connected!
>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
>> Received client version [1].
>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
>> Offered version [1].
>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_parse_name_for_domains]
>> (0x0200): name 'vg4381' matched without domain, user is vg4381
>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_parse_name_for_domains]
>> (0x0200): name 'vg4381' matched without domain, user is vg4381
>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
>> (0x0200): Requesting default options for [vg4381] from []
>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):
>> Requesting info about [vg4...@klikpay.int]
>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_issue_request] (0x0400):
>> Issuing request for [0x40bc10:3:vg4...@klikpay.int]
>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_get_account_msg]
>> (0x0400): Creating request for [klikpay.int][3][1][name=vg4381]
>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_internal_get_send]
>> (0x0400): Entering request [0x40bc10:3:vg4...@klikpay.int]
>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_check_user_dp_callback]
>> (0x0020): Unable to get information from Data Provider
>> Error: 1, 11, Offline
>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):
>> Requesting info about [vg4...@klikpay.int]
>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_get_user] (0x0400):
>> Returning info for user [vg4...@klikpay.int]
>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_get_rules] (0x0400):
>> Retrieving default options for [vg4381] from [klikpay.int]
>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]]
>> [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
>> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=vg4381)(sudoUser=#465600011)(sudoUser=%dbausers)(sudoUser=%vg4381)(sudoUser=+*))(&(dataExpireTimestamp<=1441107001)))]
>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_issue_request] (0x0400):
>> Issuing request for [0x407380:0:1:vg4...@klikpay.int]
>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_get_sudoers_msg]
>> (0x0400): Creating SUDOers request for [klikpay.int][7][vg4381][1]
>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_internal_get_send]
>> (0x0400): Entering request [0x407380:0:1:vg4...@klikpay.int]
>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_req_destructor] (0x0400):
>> Deleting request: [0x40bc10:3:vg4...@klikpay.int]
>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]]
>> [sudosrv_get_sudorules_dp_callback] (0x0020): Unable to get information
>> from Data Provider
>> Error: 1, 11, Resource temporarily unavailable
>> Will try to return what we have in cache
>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]]
>> [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with
>> [(&(objectClass=sudoRule)(|(name=defaults)))]
>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]]
>> [sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for
>> [@klikpay.int]
>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_req_destructor] (0x0400):
>> Deleting request: [0x407380:0:1:vg4...@klikpay.int]
>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_parse_name_for_domains]
>> (0x0200): name 'vg4381' matched without domain, user is vg4381
>> (Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_parse_name_for_domains]
>> (0x0200): 

[Freeipa-users] FreeIPA Sudo Error: Resource temporarily unavailable

[Yogesh Sharma]

Hi,

We are getting below error while user try to do sudo, while it work for old
users.


(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [client_recv] (0x0200): Client
disconnected!
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [accept_fd_handler] (0x0400):
Client connected!
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
Received client version [1].
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
Offered version [1].
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'vg4381' matched without domain, user is vg4381
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'vg4381' matched without domain, user is vg4381
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
(0x0200): Requesting default options for [vg4381] from []
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):
Requesting info about [vg4...@klikpay.int]
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_issue_request] (0x0400):
Issuing request for [0x40bc10:3:vg4...@klikpay.int]
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_get_account_msg] (0x0400):
Creating request for [klikpay.int][3][1][name=vg4381]
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_internal_get_send]
(0x0400): Entering request [0x40bc10:3:vg4...@klikpay.int]
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_check_user_dp_callback]
(0x0020): Unable to get information from Data Provider
Error: 1, 11, Offline
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):
Requesting info about [vg4...@klikpay.int]
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_get_user] (0x0400):
Returning info for user [vg4...@klikpay.int]
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_get_rules] (0x0400):
Retrieving default options for [vg4381] from [klikpay.int]
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
(0x0200): Searching sysdb with
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=vg4381)(sudoUser=#465600011)(sudoUser=%dbausers)(sudoUser=%vg4381)(sudoUser=+*))(&(dataExpireTimestamp<=1441107001)))]
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_issue_request] (0x0400):
Issuing request for [0x407380:0:1:vg4...@klikpay.int]
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_get_sudoers_msg] (0x0400):
Creating SUDOers request for [klikpay.int][7][vg4381][1]
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_internal_get_send]
(0x0400): Entering request [0x407380:0:1:vg4...@klikpay.int]
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_req_destructor] (0x0400):
Deleting request: [0x40bc10:3:vg4...@klikpay.int]
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_get_sudorules_dp_callback]
(0x0020): Unable to get information from Data Provider
Error: 1, 11, Resource temporarily unavailable
Will try to return what we have in cache
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
(0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(name=defaults)))]
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_get_sudorules_from_cache]
(0x0400): Returning 0 rules for [@klikpay.int]
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_req_destructor] (0x0400):
Deleting request: [0x407380:0:1:vg4...@klikpay.int]
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'vg4381' matched without domain, user is vg4381
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'vg4381' matched without domain, user is vg4381
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
(0x0200): Requesting rules for [vg4381] from []
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):
Requesting info about [vg4...@klikpay.int]
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_issue_request] (0x0400):
Issuing request for [0x40bc10:3:vg4...@klikpay.int]
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_get_account_msg] (0x0400):
Creating request for [klikpay.int][3][1][name=vg4381]
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_internal_get_send]
(0x0400): Entering request [0x40bc10:3:vg4...@klikpay.int]
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_check_user_dp_callback]
(0x0020): Unable to get information from Data Provider
Error: 1, 11, Offline
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_get_user] (0x0200):
Requesting info about [vg4...@klikpay.int]
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_get_user] (0x0400):
Returning info for user [vg4...@klikpay.int]
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_get_rules] (0x0400):
Retrieving rules for [vg4381] from [klikpay.int]
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
(0x0200): Searching sysdb with
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=vg4381)(sudoUser=#465600011)(sudoUser=%dbausers)(sudoUser=%vg4381)(sudoUser=+*))(&(dataExpireTimestamp<=1441107001)))]
(Tue Sep  1 17:00:01 2015) [sssd[sudo]] [sss_dp_issue_request] 

[Freeipa-users] FreeIPA sudo configuration on FreeIPA, version: 4.1.0

[Chamambo Martin]

I have deployed FreeIPA on RedHat 7 and everything is working perfectly fine
except when I try to configure SUDO. All my clients are all centos 6 and
RedHat 6 clients and have the below config . I have followed every how-to
and I just can't seem to get it.I have configured the sudo commands and
rules mostly for reading files /usr/bin/vim and /usr/bin/less for reading
log files

 

/etc/nssswitch

 

sudoers: files sss

 

cat /etc/sssd/sssd.conf

 



[root@nemo ~]# cat /etc/sssd/sssd.conf 

[domain/default]

 

autofs_provider = ldap

cache_credentials = True

krb5_realm = XX.XX.XX

krb5_server = XX.XX.XX.XX:88

id_provider = ldap

auth_provider = ldap

chpass_provider = ldap

ldap_id_use_start_tls = False

ldap_tls_cacertdir = /etc/openldap/cacerts

[domain/ai.co.zw]

 

debug_level = 0x07F0

cache_credentials = True

krb5_store_password_if_offline = True

ipa_domain = ai.co.zw

id_provider = ipa

auth_provider = ipa

access_provider = ipa

ipa_hostname = XX.XX.XX.XX

chpass_provider = ipa

ipa_server = _srv_, XX.XX.XX.XX

ldap_tls_cacert = /etc/ipa/ca.crt

 

[sssd]

services = nss, sudo, pam, autofs, ssh

config_file_version = 2

 

domains = default, XX.XX.XX

[nss]

 

homedir_substring = /home

 

[pam]

 

[sudo]

 

[autofs]

 

[ssh]

 

[pac]

 

 

 

 

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

Re: [Freeipa-users] FreeIPA sudo configuration on FreeIPA, version: 4.1.0

[Jakub Hrozek]

On Tue, Apr 07, 2015 at 11:58:35AM +0200, Chamambo Martin wrote:
 I have deployed FreeIPA on RedHat 7 and everything is working perfectly fine
 except when I try to configure SUDO. All my clients are all centos 6 and
 RedHat 6 clients and have the below config . I have followed every how-to
 and I just can't seem to get it.I have configured the sudo commands and
 rules mostly for reading files /usr/bin/vim and /usr/bin/less for reading
 log files
 
  
 
 /etc/nssswitch
 
  
 
 sudoers: files sss
 
  
 
 cat /etc/sssd/sssd.conf
 
  
 
 
 
 [root@nemo ~]# cat /etc/sssd/sssd.conf 
 
 [domain/default]

it is really strange that you have a domain called default (that's the
name authconfig normally uses) set to ldap provider. Where does this
come from, did you add it manually? This really sounds wrong and I would
suggest to remove this domain, but I'd also like to know why did you add
it in the first place?

 
  
 
 autofs_provider = ldap
 
 cache_credentials = True
 
 krb5_realm = XX.XX.XX
 
 krb5_server = XX.XX.XX.XX:88
 
 id_provider = ldap
 
 auth_provider = ldap
 
 chpass_provider = ldap
 
 ldap_id_use_start_tls = False
 
 ldap_tls_cacertdir = /etc/openldap/cacerts
 
 [domain/ai.co.zw]
 
  
 
 debug_level = 0x07F0
 
 cache_credentials = True
 
 krb5_store_password_if_offline = True
 
 ipa_domain = ai.co.zw
 
 id_provider = ipa
 
 auth_provider = ipa
 
 access_provider = ipa
 
 ipa_hostname = XX.XX.XX.XX
 
 chpass_provider = ipa
 
 ipa_server = _srv_, XX.XX.XX.XX
 
 ldap_tls_cacert = /etc/ipa/ca.crt

What RHEL/CentOS version are you running in particular? Starting with
6.6, it should be enough to do:
sudo_provider = ipa

 
  
 
 [sssd]
 
 services = nss, sudo, pam, autofs, ssh
 
 config_file_version = 2
 
  
 
 domains = default, XX.XX.XX
 
 [nss]
 
  
 
 homedir_substring = /home
 
  
 
 [pam]
 
  
 
 [sudo]
 
  
 
 [autofs]
 
  
 
 [ssh]
 
  
 
 [pac]
 
  
 
  
 
  
 
  
 

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

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

Re: [Freeipa-users] FreeIPA sudo configuration on FreeIPA, version: 4.1.0

[Chamambo Martin]

Sorry for the confusion about that one ,that client I used to aunthenticate
to a pure 389 directory server and I have since changed it to free ipa and
below is the correct configuration.

I managed to add the line sudo_provider = ipa and im getting the below error
on my client

[admin@ironhide postfix]$ sudo vim access
[sudo] password for admin: 
Sorry, user admin is not allowed to execute '/usr/bin/vim access' as root on
ironhide.ai.co.zw.
[admin@ironhide postfix]$




[root@ironhide ~]# cat /etc/sssd/sssd.conf 
[domain/ai.co.zw]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = ai.co.zw
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = ironhide.ai.co.zw
chpass_provider = ipa
ipa_server = _srv_, cyclops.ai.co.zw
ldap_tls_cacert = /etc/ipa/ca.crt
[sssd]
services = nss, sudo, pam, ssh
config_file_version = 2


domains = ai.co.zw
[nss]
homedir_substring = /home

[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]

[root@ironhide ~]#







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

Re: [Freeipa-users] FreeIPA sudo configuration on FreeIPA, version: 4.1.0

[Jakub Hrozek]

On Tue, Apr 07, 2015 at 12:48:37PM +0200, Chamambo Martin wrote:
 Sorry for the confusion about that one ,that client I used to aunthenticate
 to a pure 389 directory server and I have since changed it to free ipa and
 below is the correct configuration.
 
 I managed to add the line sudo_provider = ipa and im getting the below error
 on my client

I don't see it added to the config.

If it's added, the next steps would be to add debug_level to the sudo
and domain sections. https://fedorahosted.org/sssd/wiki/Troubleshooting
has some notes on gathering the debug logs.

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

Re: [Freeipa-users] FreeIPA sudo configuration on FreeIPA, version: 4.1.0

[Chamambo Martin]

 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100):
cli_pid: 2377
(Tue Apr  7 13:53:59 2015) [sssd[be[ai.co.zw]]] [fo_resolve_service_send]
(0x0100): Trying to resolve service 'IPA'
(Tue Apr  7 13:54:00 2015) [sssd[be[ai.co.zw]]] [fo_set_port_status]
(0x0100): Marking port 0 of server 'cyclops.ai.co.zw' as 'working'
(Tue Apr  7 13:54:00 2015) [sssd[be[ai.co.zw]]] [set_server_common_status]
(0x0100): Marking server 'cyclops.ai.co.zw' as 'working'
(Tue Apr  7 13:54:00 2015) [sssd[be[ai.co.zw]]] [be_pam_handler_callback]
(0x0100): Backend returned: (0, 0, NULL) [Success]
(Tue Apr  7 13:54:00 2015) [sssd[be[ai.co.zw]]] [be_pam_handler_callback]
(0x0100): Sending result [0][ai.co.zw]
(Tue Apr  7 13:54:00 2015) [sssd[be[ai.co.zw]]] [be_pam_handler_callback]
(0x0100): Sent result [0][ai.co.zw]
(Tue Apr  7 13:54:00 2015) [sssd[be[ai.co.zw]]] [child_sig_handler]
(0x0100): child [2379] finished successfully.
(Tue Apr  7 13:54:00 2015) [sssd[be[ai.co.zw]]] [be_pam_handler] (0x0100):
Got request with the following data
(Tue Apr  7 13:54:00 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100):
command: PAM_ACCT_MGMT
(Tue Apr  7 13:54:00 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100):
domain: ai.co.zw
(Tue Apr  7 13:54:00 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100):
user: admin
(Tue Apr  7 13:54:00 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100):
service: sudo
(Tue Apr  7 13:54:00 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100):
tty: /dev/pts/1
(Tue Apr  7 13:54:00 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100):
ruser: admin
(Tue Apr  7 13:54:00 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100):
rhost: 
(Tue Apr  7 13:54:00 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100):
authtok type: 0
(Tue Apr  7 13:54:00 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100):
newauthtok type: 0
(Tue Apr  7 13:54:00 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100):
priv: 0
(Tue Apr  7 13:54:00 2015) [sssd[be[ai.co.zw]]] [pam_print_data] (0x0100):
cli_pid: 2377
(Tue Apr  7 13:54:01 2015) [sssd[be[ai.co.zw]]] [ipa_hbac_evaluate_rules]
(0x0080): Access granted by HBAC rule [allow_all]
(Tue Apr  7 13:54:01 2015) [sssd[be[ai.co.zw]]] [be_pam_handler_callback]
(0x0100): Backend returned: (0, 0, NULL) [Success]
(Tue Apr  7 13:54:01 2015) [sssd[be[ai.co.zw]]] [be_pam_handler_callback]
(0x0100): Backend returned: (0, 0, Success) [Success]
(Tue Apr  7 13:54:01 2015) [sssd[be[ai.co.zw]]] [be_pam_handler_callback]
(0x0100): Sending result [0][ai.co.zw]
(Tue Apr  7 13:54:01 2015) [sssd[be[ai.co.zw]]] [be_pam_handler_callback]
(0x0100): Sent result [0][ai.co.zw]
^C


-Original Message-
From: Jakub Hrozek [mailto:jhro...@redhat.com] 
Sent: Tuesday, April 07, 2015 12:58 PM
To: Chamambo Martin
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] FreeIPA sudo configuration on FreeIPA, version:
4.1.0

On Tue, Apr 07, 2015 at 12:48:37PM +0200, Chamambo Martin wrote:
 Sorry for the confusion about that one ,that client I used to 
 aunthenticate to a pure 389 directory server and I have since changed 
 it to free ipa and below is the correct configuration.
 
 I managed to add the line sudo_provider = ipa and im getting the below 
 error on my client

I don't see it added to the config.

If it's added, the next steps would be to add debug_level to the sudo and
domain sections. https://fedorahosted.org/sssd/wiki/Troubleshooting
has some notes on gathering the debug logs.

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

Re: [Freeipa-users] FreeIPA sudo configuration on FreeIPA, version: 4.1.0

[Jakub Hrozek]

On Tue, Apr 07, 2015 at 01:55:43PM +0200, Chamambo Martin wrote:
 Thanx Jakub for pointing me to the right direction .This is what I have now
 and I have increased the debug level during troubleshooting 
 
 [domain/ai.co.zw]
 
 debug_level=3
 cache_credentials = True
 krb5_store_password_if_offline = True
 ipa_domain = ai.co.zw
 id_provider = ipa
 sudo_provider = ipa
 auth_provider = ipa
 access_provider = ipa
 ipa_hostname = ironhide.ai.co.zw
 chpass_provider = ipa
 ipa_server = _srv_, cyclops.ai.co.zw
 ldap_tls_cacert = /etc/ipa/ca.crt
 [sssd]
 services = nss, sudo, pam, ssh
 config_file_version = 2
 
 
 domains = ai.co.zw
 [nss]
 homedir_substring = /home
 
 [pam]
 
 [sudo]
 
 [autofs]
 
 [ssh]
 
 Error messages from /var/log/sssd/sssd_ai.co.zw when debug level is set at 4

This snippet just shows successfull authentication, which I guess is
when sudo asked for the password. Anything interesting in the sudo log?
/var/log/sssd/sssd_sudo.log

You might need a higher debug_level, though (6?)

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

Re: [Freeipa-users] FreeIPA sudo configuration on FreeIPA, version: 4.1.0

[Chamambo Martin]

Thanx for the feedback ,let me read a bit and will share how I managed to 
resolve it

-Original Message-
From: Lukas Slebodnik [mailto:lsleb...@redhat.com] 
Sent: Tuesday, April 07, 2015 2:16 PM
To: Jakub Hrozek
Cc: Chamambo Martin; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] FreeIPA sudo configuration on FreeIPA, version: 
4.1.0

On (07/04/15 12:57), Jakub Hrozek wrote:
On Tue, Apr 07, 2015 at 12:48:37PM +0200, Chamambo Martin wrote:
 Sorry for the confusion about that one ,that client I used to 
 aunthenticate to a pure 389 directory server and I have since changed 
 it to free ipa and below is the correct configuration.
 
 I managed to add the line sudo_provider = ipa and im getting the 
 below error on my client

I don't see it added to the config.

It's not necessary to add sudo_provider = ipa into domain section.
because if sudo_provider is not specified then it is automatically inherited 
from id_provider.

It is described in documentation [1] (point 4) and also in the manual page 
sssd-sudo.

IIRC ipa-client-install should configure all necessary things on rhel 7.1

If it's added, the next steps would be to add debug_level to the sudo 
and domain sections. https://fedorahosted.org/sssd/wiki/Troubleshooting
has some notes on gathering the debug logs.

+1

LS

[1] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/Configuring_Services.html#configuring-sssd-sudo


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

Re: [Freeipa-users] freeipa / sudo

[Chris Card]

 What command did you use to get sudo options working please? 
 
 I noticed from below mail that you have‎ 
 Sudo Option: !authenticate
 
 I am having trouble getting that working
The first issue is what version of FreeIPA you are using. Before version 4 sudo 
rules don't work without some manual setup on the client:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/config-sudo-clients.html#example-configuring-sudo-sss
 .

If the client is setup correctly, then I found issues with sssd caching, and in 
particular the sss_cache command doesn't invalidate the cache of sudo rules 
yet. Once I reduced the default cache time for sssd I could see my sudo rule 
changes working on the client.
I also had a problem with using host groups as part of the sudo rule, and this 
was down to the netgroup seen by the client having fully-qualified host names, 
while the hostname command on the client was only returning the short hostname 
- but this was down to the way OpenStack creates instances by default, not an 
issue with FreeIPA per se.

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

Re: [Freeipa-users] freeipa / sudo

[Martin Kosek]

On 12/11/2014 04:38 PM, Dmitri Pal wrote:

On 12/11/2014 08:08 AM, Martin Kosek wrote:

On 12/11/2014 01:57 PM, Chris Card wrote:

On 12/11/2014 09:42 AM, Chris Card wrote:

On 12/10/2014 04:54 PM, Chris Card wrote:



On 12/10/2014 12:57 PM, Chris Card wrote:

thanks Martin,

I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a
freeipa server and a freeipa client machine.
I've set up a user with ssh keys, and can successfully ssh onto the
client machine.
I'm trying to setup sudo rules so that if the user is in a given user
group, then the user can run sudo su - on the client to become root.

snip

[root@fedora21-freeipa log]# ipa hostgroup-show
Host-group: cog
Host-group: cog
Member hosts: ipaclient21.testdomain21.com
Member of Sudo rule: All
[root@fedora21-freeipa log]# ipa sudorule-show All
Rule name: All
Enabled: TRUE
Command category: all
RunAs User category: all
RunAs Group category: all
User Groups: cog_rw
Host Groups: cog
Sudo Option: !authenticate

but this setup doesn't work, i.e. even though the user is in the user
group and the client machine is in the host group, sudo su - fails.
Is this a bug, or have I missed something?

Chris




With FreeIPA 4.1.1, client sudo integration should be automatically
configured,
so it should just work, including hostgroups. In your case, I would
start with
investigating

http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups


If that does not help, I bet SSSD devs will ask for logs.


I've done the troubleshooting steps:

[root@ipaclient21 log]# nisdomainname
testdomain21.com
[root@ipaclient21 log]# getent netgroup cog
cog (ipaclient21.testdomain21.com,-,testdomain21.com)

I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client
machine, but I'm not sure if that's the right file (it didn't exist
before).
I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some
stuff in /var/log/sssd/sssd_testdomain21.com.log but no obvious error
messages.

I worked out how to set up debug for sudo. sudoers_debug is deprecated
now, but I created /etc/sssd.conf with a line

Debug sudo /var/log/sudo_debug all@debug

and I saw this in the debug output:

Dec 10 15:42:57 sudo[10046] - sudo_sss_check_host @ ./sssd.c:557
Dec 10 15:42:57 sudo[10046] val[0]=+cog
Dec 10 15:42:57 sudo[10046] - addr_matches @ ./match_addr.c:189
Dec 10 15:42:57 sudo[10046] - addr_matches_if @ ./match_addr.c:61
Dec 10 15:42:57 sudo[10046] - addr_matches_if @ ./match_addr.c:99 := false
Dec 10 15:42:57 sudo[10046] - addr_matches @ ./match_addr.c:199 := false
Dec 10 15:42:57 sudo[10046] - netgr_matches @ ./match.c:899
Dec 10 15:42:57 sudo[10046] - netgr_matches @ ./match.c:918 := false
Dec 10 15:42:57 sudo[10046] - hostname_matches @ ./match.c:758
Dec 10 15:42:57 sudo[10046] - hostname_matches @ ./match.c:769 := false
Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not

The problem is that the hostname command on the client was returning a
short hostname, ipaclient21, instead of a FQDN,
ipaclient21.testdomain21.com and when I forced the hostname to be the
FQDN the sudo command worked.


The short hostname comes from the fact that the client machine is an
openstack instance, and that appears to be a feature of openstack
instances :(


So on the OpenStack instance, even hostname -f does not show the FQDN? If
this is the case, I am not sure what we could do, sudo somehow needs to
learn
the FQDN.


I can set up the instance so that hostname -f returns the FQDN, but the
only way I can get hostname to return the FQDN is if I explicitly run
hostname FQDN; unfortunately this doesn't survive a reboot.

You should be able to just set the hostname to /etc/hostname (for older
platforms, it may also be in /etc/sysconfig/network) and it should survive the
reboot. I do not think that OpenStack really cares that much what hostname did
you set up in the system after the VM is created.

At least my OpenStack VM with the FreeIPA demo works this way.


I found that simply editing /etc/hostname and rebooting didn't work, because
cloud-init resets the hostname. But if I create the instance with a
cloud-init script to set the hostname to the FQDN, and then reboot the
instance after creation, /etc/hostname contains the FQDN and hostname
returns the FQDN.

Chris

Ah, right. I just remembered I also need to set it up with cloud-init. This is
the config I use for the FreeIPA demo:

#cloud-config: FreeIPA cloud configuration
hostname: ipa.demo1.freeipa.org
fqdn: ipa.demo1.freeipa.org
manage_etc_hosts: false


Is it worth a howto? Seems like  a valuable piece of info...


It is, I added a task to my queue about generating howto with this and other 
updates I had to do to make FreeIPA demo run on OpenStack.


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

Re: [Freeipa-users] freeipa / sudo

[Chris Card]

 On 12/10/2014 04:54 PM, Chris Card wrote:



 On 12/10/2014 12:57 PM, Chris Card wrote:
 thanks Martin,
 I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a 
 freeipa server and a freeipa client machine.
 I've set up a user with ssh keys, and can successfully ssh onto the 
 client machine.
 I'm trying to setup sudo rules so that if the user is in a given user 
 group, then the user can run sudo su - on the client to become root.
 snip
 [root@fedora21-freeipa log]# ipa hostgroup-show
 Host-group: cog
 Host-group: cog
 Member hosts: ipaclient21.testdomain21.com
 Member of Sudo rule: All
 [root@fedora21-freeipa log]# ipa sudorule-show All
 Rule name: All
 Enabled: TRUE
 Command category: all
 RunAs User category: all
 RunAs Group category: all
 User Groups: cog_rw
 Host Groups: cog
 Sudo Option: !authenticate

 but this setup doesn't work, i.e. even though the user is in the user 
 group and the client machine is in the host group, sudo su - fails. Is 
 this a bug, or have I missed something?

 Chris




 With FreeIPA 4.1.1, client sudo integration should be automatically 
 configured,
 so it should just work, including hostgroups. In your case, I would start 
 with
 investigating

 http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups

 If that does not help, I bet SSSD devs will ask for logs.

 I've done the troubleshooting steps:

 [root@ipaclient21 log]# nisdomainname
 testdomain21.com
 [root@ipaclient21 log]# getent netgroup cog
 cog (ipaclient21.testdomain21.com,-,testdomain21.com)

 I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client 
 machine, but I'm not sure if that's the right file (it didn't exist before).
 I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some stuff 
 in /var/log/sssd/sssd_testdomain21.com.log but no obvious error messages.

 I worked out how to set up debug for sudo. sudoers_debug is deprecated now, 
 but I created /etc/sssd.conf with a line

 Debug sudo /var/log/sudo_debug all@debug

 and I saw this in the debug output:

 Dec 10 15:42:57 sudo[10046] - sudo_sss_check_host @ ./sssd.c:557
 Dec 10 15:42:57 sudo[10046] val[0]=+cog
 Dec 10 15:42:57 sudo[10046] - addr_matches @ ./match_addr.c:189
 Dec 10 15:42:57 sudo[10046] - addr_matches_if @ ./match_addr.c:61
 Dec 10 15:42:57 sudo[10046] - addr_matches_if @ ./match_addr.c:99 := false
 Dec 10 15:42:57 sudo[10046] - addr_matches @ ./match_addr.c:199 := false
 Dec 10 15:42:57 sudo[10046] - netgr_matches @ ./match.c:899
 Dec 10 15:42:57 sudo[10046] - netgr_matches @ ./match.c:918 := false
 Dec 10 15:42:57 sudo[10046] - hostname_matches @ ./match.c:758
 Dec 10 15:42:57 sudo[10046] - hostname_matches @ ./match.c:769 := false
 Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not

 The problem is that the hostname command on the client was returning a short 
 hostname, ipaclient21, instead of a FQDN, ipaclient21.testdomain21.com and 
 when I forced the hostname to be the FQDN the sudo command worked.


 The short hostname comes from the fact that the client machine is an 
 openstack instance, and that appears to be a feature of openstack instances 
 :(


 So on the OpenStack instance, even hostname -f does not show the FQDN? If
 this is the case, I am not sure what we could do, sudo somehow needs to learn
 the FQDN.

I can set up the instance so that hostname -f returns the FQDN, but the only 
way I can get hostname to return the FQDN is if I explicitly run hostname 
FQDN; unfortunately this doesn't survive a reboot.

Chris 

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

Re: [Freeipa-users] freeipa / sudo

[Martin Kosek]

On 12/11/2014 09:42 AM, Chris Card wrote:
 
 On 12/10/2014 04:54 PM, Chris Card wrote:



 On 12/10/2014 12:57 PM, Chris Card wrote:
 thanks Martin,
 I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a 
 freeipa server and a freeipa client machine.
 I've set up a user with ssh keys, and can successfully ssh onto the 
 client machine.
 I'm trying to setup sudo rules so that if the user is in a given user 
 group, then the user can run sudo su - on the client to become root.
 snip
 [root@fedora21-freeipa log]# ipa hostgroup-show
 Host-group: cog
 Host-group: cog
 Member hosts: ipaclient21.testdomain21.com
 Member of Sudo rule: All
 [root@fedora21-freeipa log]# ipa sudorule-show All
 Rule name: All
 Enabled: TRUE
 Command category: all
 RunAs User category: all
 RunAs Group category: all
 User Groups: cog_rw
 Host Groups: cog
 Sudo Option: !authenticate

 but this setup doesn't work, i.e. even though the user is in the user 
 group and the client machine is in the host group, sudo su - fails. Is 
 this a bug, or have I missed something?

 Chris




 With FreeIPA 4.1.1, client sudo integration should be automatically 
 configured,
 so it should just work, including hostgroups. In your case, I would start 
 with
 investigating

 http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups

 If that does not help, I bet SSSD devs will ask for logs.

 I've done the troubleshooting steps:

 [root@ipaclient21 log]# nisdomainname
 testdomain21.com
 [root@ipaclient21 log]# getent netgroup cog
 cog (ipaclient21.testdomain21.com,-,testdomain21.com)

 I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client 
 machine, but I'm not sure if that's the right file (it didn't exist 
 before).
 I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some 
 stuff in /var/log/sssd/sssd_testdomain21.com.log but no obvious error 
 messages.

 I worked out how to set up debug for sudo. sudoers_debug is deprecated now, 
 but I created /etc/sssd.conf with a line

 Debug sudo /var/log/sudo_debug all@debug

 and I saw this in the debug output:

 Dec 10 15:42:57 sudo[10046] - sudo_sss_check_host @ ./sssd.c:557
 Dec 10 15:42:57 sudo[10046] val[0]=+cog
 Dec 10 15:42:57 sudo[10046] - addr_matches @ ./match_addr.c:189
 Dec 10 15:42:57 sudo[10046] - addr_matches_if @ ./match_addr.c:61
 Dec 10 15:42:57 sudo[10046] - addr_matches_if @ ./match_addr.c:99 := false
 Dec 10 15:42:57 sudo[10046] - addr_matches @ ./match_addr.c:199 := false
 Dec 10 15:42:57 sudo[10046] - netgr_matches @ ./match.c:899
 Dec 10 15:42:57 sudo[10046] - netgr_matches @ ./match.c:918 := false
 Dec 10 15:42:57 sudo[10046] - hostname_matches @ ./match.c:758
 Dec 10 15:42:57 sudo[10046] - hostname_matches @ ./match.c:769 := false
 Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not

 The problem is that the hostname command on the client was returning a 
 short hostname, ipaclient21, instead of a FQDN, 
 ipaclient21.testdomain21.com and when I forced the hostname to be the FQDN 
 the sudo command worked.


 The short hostname comes from the fact that the client machine is an 
 openstack instance, and that appears to be a feature of openstack instances 
 :(


 So on the OpenStack instance, even hostname -f does not show the FQDN? If
 this is the case, I am not sure what we could do, sudo somehow needs to learn
 the FQDN.

 I can set up the instance so that hostname -f returns the FQDN, but the only 
 way I can get hostname to return the FQDN is if I explicitly run hostname 
 FQDN; unfortunately this doesn't survive a reboot.

You should be able to just set the hostname to /etc/hostname (for older
platforms, it may also be in /etc/sysconfig/network) and it should survive the
reboot. I do not think that OpenStack really cares that much what hostname did
you set up in the system after the VM is created.

At least my OpenStack VM with the FreeIPA demo works this way.

Martin

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

Re: [Freeipa-users] freeipa / sudo

[Chris Card]

 On 12/11/2014 09:42 AM, Chris Card wrote:

 On 12/10/2014 04:54 PM, Chris Card wrote:



 On 12/10/2014 12:57 PM, Chris Card wrote:
 thanks Martin,
 I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a 
 freeipa server and a freeipa client machine.
 I've set up a user with ssh keys, and can successfully ssh onto the 
 client machine.
 I'm trying to setup sudo rules so that if the user is in a given user 
 group, then the user can run sudo su - on the client to become root.
 snip
 [root@fedora21-freeipa log]# ipa hostgroup-show
 Host-group: cog
 Host-group: cog
 Member hosts: ipaclient21.testdomain21.com
 Member of Sudo rule: All
 [root@fedora21-freeipa log]# ipa sudorule-show All
 Rule name: All
 Enabled: TRUE
 Command category: all
 RunAs User category: all
 RunAs Group category: all
 User Groups: cog_rw
 Host Groups: cog
 Sudo Option: !authenticate

 but this setup doesn't work, i.e. even though the user is in the user 
 group and the client machine is in the host group, sudo su - fails. Is 
 this a bug, or have I missed something?

 Chris




 With FreeIPA 4.1.1, client sudo integration should be automatically 
 configured,
 so it should just work, including hostgroups. In your case, I would 
 start with
 investigating

 http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups

 If that does not help, I bet SSSD devs will ask for logs.

 I've done the troubleshooting steps:

 [root@ipaclient21 log]# nisdomainname
 testdomain21.com
 [root@ipaclient21 log]# getent netgroup cog
 cog (ipaclient21.testdomain21.com,-,testdomain21.com)

 I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client 
 machine, but I'm not sure if that's the right file (it didn't exist 
 before).
 I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some 
 stuff in /var/log/sssd/sssd_testdomain21.com.log but no obvious error 
 messages.

 I worked out how to set up debug for sudo. sudoers_debug is deprecated 
 now, but I created /etc/sssd.conf with a line

 Debug sudo /var/log/sudo_debug all@debug

 and I saw this in the debug output:

 Dec 10 15:42:57 sudo[10046] - sudo_sss_check_host @ ./sssd.c:557
 Dec 10 15:42:57 sudo[10046] val[0]=+cog
 Dec 10 15:42:57 sudo[10046] - addr_matches @ ./match_addr.c:189
 Dec 10 15:42:57 sudo[10046] - addr_matches_if @ ./match_addr.c:61
 Dec 10 15:42:57 sudo[10046] - addr_matches_if @ ./match_addr.c:99 := false
 Dec 10 15:42:57 sudo[10046] - addr_matches @ ./match_addr.c:199 := false
 Dec 10 15:42:57 sudo[10046] - netgr_matches @ ./match.c:899
 Dec 10 15:42:57 sudo[10046] - netgr_matches @ ./match.c:918 := false
 Dec 10 15:42:57 sudo[10046] - hostname_matches @ ./match.c:758
 Dec 10 15:42:57 sudo[10046] - hostname_matches @ ./match.c:769 := false
 Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not

 The problem is that the hostname command on the client was returning a 
 short hostname, ipaclient21, instead of a FQDN, 
 ipaclient21.testdomain21.com and when I forced the hostname to be the FQDN 
 the sudo command worked.


 The short hostname comes from the fact that the client machine is an 
 openstack instance, and that appears to be a feature of openstack 
 instances :(


 So on the OpenStack instance, even hostname -f does not show the FQDN? If
 this is the case, I am not sure what we could do, sudo somehow needs to 
 learn
 the FQDN.

 I can set up the instance so that hostname -f returns the FQDN, but the only 
 way I can get hostname to return the FQDN is if I explicitly run hostname 
 FQDN; unfortunately this doesn't survive a reboot.

 You should be able to just set the hostname to /etc/hostname (for older
 platforms, it may also be in /etc/sysconfig/network) and it should survive the
 reboot. I do not think that OpenStack really cares that much what hostname did
 you set up in the system after the VM is created.

 At least my OpenStack VM with the FreeIPA demo works this way.

I found that simply editing /etc/hostname and rebooting didn't work, because 
cloud-init resets the hostname. But if I create the instance with a cloud-init 
script to set the hostname to the FQDN, and then reboot the instance after 
creation, /etc/hostname contains the FQDN and hostname returns the FQDN.

Chris

  

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

Re: [Freeipa-users] freeipa / sudo

[Martin Kosek]

On 12/11/2014 01:57 PM, Chris Card wrote:
 On 12/11/2014 09:42 AM, Chris Card wrote:

 On 12/10/2014 04:54 PM, Chris Card wrote:



 On 12/10/2014 12:57 PM, Chris Card wrote:
 thanks Martin,
 I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a 
 freeipa server and a freeipa client machine.
 I've set up a user with ssh keys, and can successfully ssh onto the 
 client machine.
 I'm trying to setup sudo rules so that if the user is in a given user 
 group, then the user can run sudo su - on the client to become root.
 snip
 [root@fedora21-freeipa log]# ipa hostgroup-show
 Host-group: cog
 Host-group: cog
 Member hosts: ipaclient21.testdomain21.com
 Member of Sudo rule: All
 [root@fedora21-freeipa log]# ipa sudorule-show All
 Rule name: All
 Enabled: TRUE
 Command category: all
 RunAs User category: all
 RunAs Group category: all
 User Groups: cog_rw
 Host Groups: cog
 Sudo Option: !authenticate

 but this setup doesn't work, i.e. even though the user is in the user 
 group and the client machine is in the host group, sudo su - fails. Is 
 this a bug, or have I missed something?

 Chris




 With FreeIPA 4.1.1, client sudo integration should be automatically 
 configured,
 so it should just work, including hostgroups. In your case, I would 
 start with
 investigating

 http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups

 If that does not help, I bet SSSD devs will ask for logs.

 I've done the troubleshooting steps:

 [root@ipaclient21 log]# nisdomainname
 testdomain21.com
 [root@ipaclient21 log]# getent netgroup cog
 cog (ipaclient21.testdomain21.com,-,testdomain21.com)

 I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client 
 machine, but I'm not sure if that's the right file (it didn't exist 
 before).
 I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some 
 stuff in /var/log/sssd/sssd_testdomain21.com.log but no obvious error 
 messages.

 I worked out how to set up debug for sudo. sudoers_debug is deprecated 
 now, but I created /etc/sssd.conf with a line

 Debug sudo /var/log/sudo_debug all@debug

 and I saw this in the debug output:

 Dec 10 15:42:57 sudo[10046] - sudo_sss_check_host @ ./sssd.c:557
 Dec 10 15:42:57 sudo[10046] val[0]=+cog
 Dec 10 15:42:57 sudo[10046] - addr_matches @ ./match_addr.c:189
 Dec 10 15:42:57 sudo[10046] - addr_matches_if @ ./match_addr.c:61
 Dec 10 15:42:57 sudo[10046] - addr_matches_if @ ./match_addr.c:99 := 
 false
 Dec 10 15:42:57 sudo[10046] - addr_matches @ ./match_addr.c:199 := false
 Dec 10 15:42:57 sudo[10046] - netgr_matches @ ./match.c:899
 Dec 10 15:42:57 sudo[10046] - netgr_matches @ ./match.c:918 := false
 Dec 10 15:42:57 sudo[10046] - hostname_matches @ ./match.c:758
 Dec 10 15:42:57 sudo[10046] - hostname_matches @ ./match.c:769 := false
 Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not

 The problem is that the hostname command on the client was returning a 
 short hostname, ipaclient21, instead of a FQDN, 
 ipaclient21.testdomain21.com and when I forced the hostname to be the 
 FQDN the sudo command worked.


 The short hostname comes from the fact that the client machine is an 
 openstack instance, and that appears to be a feature of openstack 
 instances :(


 So on the OpenStack instance, even hostname -f does not show the FQDN? If
 this is the case, I am not sure what we could do, sudo somehow needs to 
 learn
 the FQDN.

 I can set up the instance so that hostname -f returns the FQDN, but the 
 only way I can get hostname to return the FQDN is if I explicitly run 
 hostname FQDN; unfortunately this doesn't survive a reboot.

 You should be able to just set the hostname to /etc/hostname (for older
 platforms, it may also be in /etc/sysconfig/network) and it should survive 
 the
 reboot. I do not think that OpenStack really cares that much what hostname 
 did
 you set up in the system after the VM is created.

 At least my OpenStack VM with the FreeIPA demo works this way.

 I found that simply editing /etc/hostname and rebooting didn't work, because 
 cloud-init resets the hostname. But if I create the instance with a 
 cloud-init script to set the hostname to the FQDN, and then reboot the 
 instance after creation, /etc/hostname contains the FQDN and hostname returns 
 the FQDN.
 
 Chris

Ah, right. I just remembered I also need to set it up with cloud-init. This is
the config I use for the FreeIPA demo:

#cloud-config: FreeIPA cloud configuration
hostname: ipa.demo1.freeipa.org
fqdn: ipa.demo1.freeipa.org
manage_etc_hosts: false

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

Re: [Freeipa-users] freeipa / sudo

[Dmitri Pal]

On 12/11/2014 08:08 AM, Martin Kosek wrote:

On 12/11/2014 01:57 PM, Chris Card wrote:

On 12/11/2014 09:42 AM, Chris Card wrote:

On 12/10/2014 04:54 PM, Chris Card wrote:



On 12/10/2014 12:57 PM, Chris Card wrote:

thanks Martin,

I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a freeipa 
server and a freeipa client machine.
I've set up a user with ssh keys, and can successfully ssh onto the client 
machine.
I'm trying to setup sudo rules so that if the user is in a given user group, then the 
user can run sudo su - on the client to become root.

snip

[root@fedora21-freeipa log]# ipa hostgroup-show
Host-group: cog
Host-group: cog
Member hosts: ipaclient21.testdomain21.com
Member of Sudo rule: All
[root@fedora21-freeipa log]# ipa sudorule-show All
Rule name: All
Enabled: TRUE
Command category: all
RunAs User category: all
RunAs Group category: all
User Groups: cog_rw
Host Groups: cog
Sudo Option: !authenticate

but this setup doesn't work, i.e. even though the user is in the user group and 
the client machine is in the host group, sudo su - fails. Is this a bug, or 
have I missed something?

Chris




With FreeIPA 4.1.1, client sudo integration should be automatically configured,
so it should just work, including hostgroups. In your case, I would start with
investigating

http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups

If that does not help, I bet SSSD devs will ask for logs.


I've done the troubleshooting steps:

[root@ipaclient21 log]# nisdomainname
testdomain21.com
[root@ipaclient21 log]# getent netgroup cog
cog (ipaclient21.testdomain21.com,-,testdomain21.com)

I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client machine, 
but I'm not sure if that's the right file (it didn't exist before).
I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some stuff in 
/var/log/sssd/sssd_testdomain21.com.log but no obvious error messages.

I worked out how to set up debug for sudo. sudoers_debug is deprecated now, but 
I created /etc/sssd.conf with a line

Debug sudo /var/log/sudo_debug all@debug

and I saw this in the debug output:

Dec 10 15:42:57 sudo[10046] - sudo_sss_check_host @ ./sssd.c:557
Dec 10 15:42:57 sudo[10046] val[0]=+cog
Dec 10 15:42:57 sudo[10046] - addr_matches @ ./match_addr.c:189
Dec 10 15:42:57 sudo[10046] - addr_matches_if @ ./match_addr.c:61
Dec 10 15:42:57 sudo[10046] - addr_matches_if @ ./match_addr.c:99 := false
Dec 10 15:42:57 sudo[10046] - addr_matches @ ./match_addr.c:199 := false
Dec 10 15:42:57 sudo[10046] - netgr_matches @ ./match.c:899
Dec 10 15:42:57 sudo[10046] - netgr_matches @ ./match.c:918 := false
Dec 10 15:42:57 sudo[10046] - hostname_matches @ ./match.c:758
Dec 10 15:42:57 sudo[10046] - hostname_matches @ ./match.c:769 := false
Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not

The problem is that the hostname command on the client was returning a short 
hostname, ipaclient21, instead of a FQDN, ipaclient21.testdomain21.com and when 
I forced the hostname to be the FQDN the sudo command worked.


The short hostname comes from the fact that the client machine is an openstack 
instance, and that appears to be a feature of openstack instances :(


So on the OpenStack instance, even hostname -f does not show the FQDN? If
this is the case, I am not sure what we could do, sudo somehow needs to learn
the FQDN.


I can set up the instance so that hostname -f returns the FQDN, but the only way I can get 
hostname to return the FQDN is if I explicitly run hostname FQDN; 
unfortunately this doesn't survive a reboot.

You should be able to just set the hostname to /etc/hostname (for older
platforms, it may also be in /etc/sysconfig/network) and it should survive the
reboot. I do not think that OpenStack really cares that much what hostname did
you set up in the system after the VM is created.

At least my OpenStack VM with the FreeIPA demo works this way.


I found that simply editing /etc/hostname and rebooting didn't work, because 
cloud-init resets the hostname. But if I create the instance with a cloud-init 
script to set the hostname to the FQDN, and then reboot the instance after 
creation, /etc/hostname contains the FQDN and hostname returns the FQDN.

Chris

Ah, right. I just remembered I also need to set it up with cloud-init. This is
the config I use for the FreeIPA demo:

#cloud-config: FreeIPA cloud configuration
hostname: ipa.demo1.freeipa.org
fqdn: ipa.demo1.freeipa.org
manage_etc_hosts: false


Is it worth a howto? Seems like  a valuable piece of info...


--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

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

[Freeipa-users] freeipa / sudo

[Chris Card]

Hi,
I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a freeipa 
server and a freeipa client machine.
I've set up a user with ssh keys, and can successfully ssh onto the client 
machine.
I'm trying to setup sudo rules so that if the user is in a given user group, 
then the user can run sudo su - on the client to become root.

Here is my setup:

[root@fedora21-freeipa log]# ipa user-show ccard
  User login: ccard
  First name: Chris
  Last name: Card
  Home directory: /home/ccard
  Login shell: /bin/sh
  Email address: cc...@testdomain21.com
  UID: 158101
  GID: 158101
  Account disabled: False
  Password: True
  Member of groups: ipausers, cog_rw
  Indirect Member of Sudo rule: All
  Kerberos keys available: True
  SSH public key fingerprint: 98:3D:15:93:A2:F7:79:A8:D6:F6:8B:5B:21:3F:E6:78 
ccard (ssh-rsa)
[root@fedora21-freeipa log]# ipa group-show cog_rw
  Group name: cog_rw
  GID: 158103
  Member users: ccard
  Member of Sudo rule: All
[root@fedora21-freeipa log]# ipa sudorule-show All
  Rule name: All
  Enabled: TRUE
  Host category: all
  Command category: all
  RunAs User category: all
  RunAs Group category: all
  User Groups: cog_rw
  Sudo Option: !authenticate

I've found that this setup works eventually, but I have to wait for several 
minutes after changing the settings (through the freeipa gui), before it works. 
I've found that changing entry_cache_sudo_timeout and stopping/starting sssd on 
the client machine helps, and that sss_cache doesn't support invalidating the 
sudo rules, which is annoying.

I've also tried making the sudo rule more restrictive by adding a host group 
e.g.

[root@fedora21-freeipa log]# ipa hostgroup-show
Host-group: cog
  Host-group: cog
  Member hosts: ipaclient21.testdomain21.com
  Member of Sudo rule: All
[root@fedora21-freeipa log]# ipa sudorule-show All
  Rule name: All
  Enabled: TRUE
  Command category: all
  RunAs User category: all
  RunAs Group category: all
  User Groups: cog_rw
  Host Groups: cog
  Sudo Option: !authenticate

but this setup doesn't work, i.e. even though the user is in the user group and 
the client machine is in the host group, sudo su - fails. Is this a bug, or 
have I missed something?

Chris

  

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

Re: [Freeipa-users] freeipa / sudo

[Martin Kosek]

On 12/10/2014 12:57 PM, Chris Card wrote:
 Hi,
 I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a freeipa 
 server and a freeipa client machine.
 I've set up a user with ssh keys, and can successfully ssh onto the client 
 machine.
 I'm trying to setup sudo rules so that if the user is in a given user group, 
 then the user can run sudo su - on the client to become root.
 
 Here is my setup:
 
 [root@fedora21-freeipa log]# ipa user-show ccard
   User login: ccard
   First name: Chris
   Last name: Card
   Home directory: /home/ccard
   Login shell: /bin/sh
   Email address: cc...@testdomain21.com
   UID: 158101
   GID: 158101
   Account disabled: False
   Password: True
   Member of groups: ipausers, cog_rw
   Indirect Member of Sudo rule: All
   Kerberos keys available: True
   SSH public key fingerprint: 98:3D:15:93:A2:F7:79:A8:D6:F6:8B:5B:21:3F:E6:78 
 ccard (ssh-rsa)
 [root@fedora21-freeipa log]# ipa group-show cog_rw
   Group name: cog_rw
   GID: 158103
   Member users: ccard
   Member of Sudo rule: All
 [root@fedora21-freeipa log]# ipa sudorule-show All
   Rule name: All
   Enabled: TRUE
   Host category: all
   Command category: all
   RunAs User category: all
   RunAs Group category: all
   User Groups: cog_rw
   Sudo Option: !authenticate
 
 I've found that this setup works eventually, but I have to wait for several 
 minutes after changing the settings (through the freeipa gui), before it 
 works. 
 I've found that changing entry_cache_sudo_timeout and stopping/starting sssd 
 on the client machine helps, and that sss_cache doesn't support invalidating 
 the sudo rules, which is annoying.
 
 I've also tried making the sudo rule more restrictive by adding a host group 
 e.g.
 
 [root@fedora21-freeipa log]# ipa hostgroup-show
 Host-group: cog
   Host-group: cog
   Member hosts: ipaclient21.testdomain21.com
   Member of Sudo rule: All
 [root@fedora21-freeipa log]# ipa sudorule-show All
   Rule name: All
   Enabled: TRUE
   Command category: all
   RunAs User category: all
   RunAs Group category: all
   User Groups: cog_rw
   Host Groups: cog
   Sudo Option: !authenticate
 
 but this setup doesn't work, i.e. even though the user is in the user group 
 and the client machine is in the host group, sudo su - fails. Is this a bug, 
 or have I missed something?
 
 Chris
 
 
 

With FreeIPA 4.1.1, client sudo integration should be automatically configured,
so it should just work, including hostgroups. In your case, I would start with
investigating

http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups

If that does not help, I bet SSSD devs will ask for logs.

Martin

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

Re: [Freeipa-users] freeipa / sudo

[Chris Card]

 On 12/10/2014 12:57 PM, Chris Card wrote:
 thanks Martin,
 I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a 
 freeipa server and a freeipa client machine.
 I've set up a user with ssh keys, and can successfully ssh onto the client 
 machine.
 I'm trying to setup sudo rules so that if the user is in a given user 
 group, then the user can run sudo su - on the client to become root.
 snip
 [root@fedora21-freeipa log]# ipa hostgroup-show
 Host-group: cog
 Host-group: cog
 Member hosts: ipaclient21.testdomain21.com
 Member of Sudo rule: All
 [root@fedora21-freeipa log]# ipa sudorule-show All
 Rule name: All
 Enabled: TRUE
 Command category: all
 RunAs User category: all
 RunAs Group category: all
 User Groups: cog_rw
 Host Groups: cog
 Sudo Option: !authenticate

 but this setup doesn't work, i.e. even though the user is in the user group 
 and the client machine is in the host group, sudo su - fails. Is this a 
 bug, or have I missed something?

 Chris




 With FreeIPA 4.1.1, client sudo integration should be automatically 
 configured,
 so it should just work, including hostgroups. In your case, I would start 
 with
 investigating

 http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups

 If that does not help, I bet SSSD devs will ask for logs.

 I've done the troubleshooting steps:

 [root@ipaclient21 log]# nisdomainname
 testdomain21.com
 [root@ipaclient21 log]# getent netgroup cog
 cog (ipaclient21.testdomain21.com,-,testdomain21.com)

 I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client machine, 
 but I'm not sure if that's the right file (it didn't exist before).
 I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some stuff 
 in /var/log/sssd/sssd_testdomain21.com.log but no obvious error messages.

I worked out how to set up debug for sudo. sudoers_debug is deprecated now, but 
I created /etc/sssd.conf with a line

Debug sudo /var/log/sudo_debug all@debug

and I saw this in the debug output:

Dec 10 15:42:57 sudo[10046] - sudo_sss_check_host @ ./sssd.c:557
Dec 10 15:42:57 sudo[10046] val[0]=+cog 
Dec 10 15:42:57 sudo[10046] - addr_matches @ ./match_addr.c:189
Dec 10 15:42:57 sudo[10046] - addr_matches_if @ ./match_addr.c:61
Dec 10 15:42:57 sudo[10046] - addr_matches_if @ ./match_addr.c:99 := false
Dec 10 15:42:57 sudo[10046] - addr_matches @ ./match_addr.c:199 := false
Dec 10 15:42:57 sudo[10046] - netgr_matches @ ./match.c:899
Dec 10 15:42:57 sudo[10046] - netgr_matches @ ./match.c:918 := false
Dec 10 15:42:57 sudo[10046] - hostname_matches @ ./match.c:758
Dec 10 15:42:57 sudo[10046] - hostname_matches @ ./match.c:769 := false
Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not

The problem is that the hostname command on the client was returning a short 
hostname, ipaclient21, instead of a FQDN, ipaclient21.testdomain21.com and when 
I forced the hostname to be the FQDN the sudo command worked.

The short hostname comes from the fact that the client machine is an openstack 
instance, and that appears to be a feature of openstack instances :(

Chris 

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

Re: [Freeipa-users] freeipa / sudo

[Simo Sorce]

On Wed, 10 Dec 2014 11:57:26 +
Chris Card ctc...@hotmail.com wrote:

 Hi,
 I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a
 freeipa server and a freeipa client machine. I've set up a user with
 ssh keys, and can successfully ssh onto the client machine. I'm
 trying to setup sudo rules so that if the user is in a given user
 group, then the user can run sudo su - on the client to become root.

FWIW you should probably use just sudo -i it will avoid authorization
issues to run the su service.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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

Re: [Freeipa-users] freeipa / sudo

[Martin Kosek]

On 12/10/2014 04:54 PM, Chris Card wrote:
 
 

 On 12/10/2014 12:57 PM, Chris Card wrote:
 thanks Martin,
 I've installed freeipa 4.1.1 on Fedora 21, and successfully set up a 
 freeipa server and a freeipa client machine.
 I've set up a user with ssh keys, and can successfully ssh onto the client 
 machine.
 I'm trying to setup sudo rules so that if the user is in a given user 
 group, then the user can run sudo su - on the client to become root.
 snip
 [root@fedora21-freeipa log]# ipa hostgroup-show
 Host-group: cog
 Host-group: cog
 Member hosts: ipaclient21.testdomain21.com
 Member of Sudo rule: All
 [root@fedora21-freeipa log]# ipa sudorule-show All
 Rule name: All
 Enabled: TRUE
 Command category: all
 RunAs User category: all
 RunAs Group category: all
 User Groups: cog_rw
 Host Groups: cog
 Sudo Option: !authenticate

 but this setup doesn't work, i.e. even though the user is in the user 
 group and the client machine is in the host group, sudo su - fails. Is 
 this a bug, or have I missed something?

 Chris




 With FreeIPA 4.1.1, client sudo integration should be automatically 
 configured,
 so it should just work, including hostgroups. In your case, I would start 
 with
 investigating

 http://www.freeipa.org/page/Troubleshooting#sudo_does_not_work_for_hostgroups

 If that does not help, I bet SSSD devs will ask for logs.

 I've done the troubleshooting steps:

 [root@ipaclient21 log]# nisdomainname
 testdomain21.com
 [root@ipaclient21 log]# getent netgroup cog
 cog (ipaclient21.testdomain21.com,-,testdomain21.com)

 I tried adding sudoers_debug 2 to /etc/sudo-ldap.conf on the client machine, 
 but I'm not sure if that's the right file (it didn't exist before).
 I have debug_level set to 9 in /etc/sssd/sssd.conf, so I can see some stuff 
 in /var/log/sssd/sssd_testdomain21.com.log but no obvious error messages.
 
 I worked out how to set up debug for sudo. sudoers_debug is deprecated now, 
 but I created /etc/sssd.conf with a line
 
 Debug sudo /var/log/sudo_debug all@debug
 
 and I saw this in the debug output:
 
 Dec 10 15:42:57 sudo[10046] - sudo_sss_check_host @ ./sssd.c:557
 Dec 10 15:42:57 sudo[10046] val[0]=+cog 
 Dec 10 15:42:57 sudo[10046] - addr_matches @ ./match_addr.c:189
 Dec 10 15:42:57 sudo[10046] - addr_matches_if @ ./match_addr.c:61
 Dec 10 15:42:57 sudo[10046] - addr_matches_if @ ./match_addr.c:99 := false
 Dec 10 15:42:57 sudo[10046] - addr_matches @ ./match_addr.c:199 := false
 Dec 10 15:42:57 sudo[10046] - netgr_matches @ ./match.c:899
 Dec 10 15:42:57 sudo[10046] - netgr_matches @ ./match.c:918 := false
 Dec 10 15:42:57 sudo[10046] - hostname_matches @ ./match.c:758
 Dec 10 15:42:57 sudo[10046] - hostname_matches @ ./match.c:769 := false
 Dec 10 15:42:57 sudo[10046] sssd/ldap sudoHost '+cog' ... not
 
 The problem is that the hostname command on the client was returning a short 
 hostname, ipaclient21, instead of a FQDN, ipaclient21.testdomain21.com and 
 when I forced the hostname to be the FQDN the sudo command worked.


 The short hostname comes from the fact that the client machine is an 
 openstack instance, and that appears to be a feature of openstack instances :(


So on the OpenStack instance, even hostname -f does not show the FQDN? If
this is the case, I am not sure what we could do, sudo somehow needs to learn
the FQDN.

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