Re: [Freeipa-users] ipa / sudoers on centos 6.3 client

2015-01-02 Thread Craig White

From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Chris Card
Sent: Friday, January 02, 2015 8:45 AM
To: Brendan Kearney
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] ipa / sudoers on centos 6.3 client


 Subject: Re: [Freeipa-users] ipa / sudoers on centos 6.3 client
 From: bpk...@gmail.commailto:bpk...@gmail.com
 To: ctc...@hotmail.commailto:ctc...@hotmail.com
 CC: freeipa-users@redhat.commailto:freeipa-users@redhat.com
 Date: Fri, 2 Jan 2015 10:28:16 -0500

 On Fri, 2015-01-02 at 15:19 +, Chris Card wrote:
  I have existing machines running CentOS 6.3 which I want to include in
  a freeipa domain.
 
  The domain controller machine is running Fedora 21 and
  freeipa-server-4.1.1-2 while the latest version of ipa I can find that
  runs on CentOS 6.3 is ipa-client-3.0.0-37.el6.x86_64.
 
 
  I have successfully run ipa-client-install on the CentOS 6.3 client
  and set up users who can ssh to the client using ssh-keys.
 
 
  The problem is that I can't get sudo rules to work. I know that the
  ipa client software version 3.0.0 doesn't automatically set up all the
  configuration for sssd to control sudo access, but I have set up all
  the configuration necessary manually:
 
 
  On the client, /etc/nsswitch.conf has
 
 
  sudoers files sss
 
 
  /etc/sssd/sssd/conf has
 
 
  [domain/default]
 
 
  cache_credentials = True
  krb5_realm = REALM
  krb5_server = ipa server:88
  id_provider = ldap
  auth_provider = ldap
  chpass_provider = ldap
  ldap_tls_cacertdir = /etc/openldap/cacerts
  [domain/domain]
 
 
  cache_credentials = True
  krb5_store_password_if_offline = True
  ipa_domain = domain
  id_provider = ipa
  auth_provider = ipa
  access_provider = ipa
  chpass_provider = ipa
  ipa_dyndns_update = True
  ipa_server = ipa server
  ldap_tls_cacert = /etc/ipa/ca.crt
  sudo_provider = ldap
  ldap_uri = ldap://ipa server
  ldap_sudo_search_base = ou=sudoers,domain base dn
  ldap_sasl_mech = GSSAPI
  ldap_sasl_authid = host/client fqdn
  ldap_sasl_realm = REALM
  krb5_server = ipa server
  debug_level = 9
  [sssd]
  services = nss, pam, ssh, sudo
  config_file_version = 2
 
 
  domains = domain, default
  debug_level = 9
  [nss]
  debug_level = 9
 
 
  [pam]
  debug_level = 9
 
 
  [sudo]
  debug_level = 9
  [autofs]
 
 
  I have validated the ldap sasl configuration using ldapsearch, so I'm
  sure they are correct.
 
 
  The nisdomainname command returns the domain name.
 
 
  The sudo rules are:
  # ipa sudorule-find
  
  2 Sudo Rules matched
  
  Rule name: sudo-host1
  Enabled: TRUE
  Command category: all
  RunAs User category: all
  User Groups: host1-rw
  Host Groups: host1
  Sudo Option: -authenticate
 
 
  Rule name: sudo-host2
  Enabled: TRUE
  User Groups: host2-rw
  Host Groups: host2
  Sudo Option: -authenticate
  
  Number of entries returned 2
  
 
 
  When a user in user group host1-rw sshs to a client in host group
  host1 and runs sudo su - the user gets prompted for a password even
  though the sudo option -authenticate is set.
  I'm not convinced that sudo is even attempting to use sssd, but I'm
  not sure how to confirm this.
 
 
  I have seen some references to /etc/sudo-ldap.conf in online
  discussions of similar issues. This file exists on my client, but
  everything is commented out. Do I need to put the ldap client
  configuration in /etc/sudo-ldap.conf as well as /etc/sssd/sssd.conf
  for CentOS 6.3 clients?
 
 
  Any ideas about how to work out what is failing?
 
 
  Chris
 
 try !authenticate (without the quotes), not -authenticate (again,
 no quotes).
That made no difference (though I think you're correct that -authenticate is 
wrong).
Sudo didn't work correctly for me until I updated to RHEL 6.6 which had 
sssd-1.11
Just saying...
Craig
-- 
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] ipa / sudoers on centos 6.3 client

2015-01-02 Thread Chris Card


 Subject: Re: [Freeipa-users] ipa / sudoers on centos 6.3 client
 From: bpk...@gmail.com
 To: ctc...@hotmail.com
 CC: freeipa-users@redhat.com
 Date: Fri, 2 Jan 2015 10:28:16 -0500
 
 On Fri, 2015-01-02 at 15:19 +, Chris Card wrote:
  I have existing machines running CentOS 6.3 which I want to include in
  a freeipa domain.
  
  The domain controller machine is running Fedora 21 and
  freeipa-server-4.1.1-2 while the latest version of ipa I can find that
  runs on CentOS 6.3 is ipa-client-3.0.0-37.el6.x86_64.
  
  
  I have successfully run ipa-client-install on the CentOS 6.3 client
  and set up users who can ssh to the client using ssh-keys.
  
  
  The problem is that I can't get sudo rules to work. I know that the
  ipa client software version 3.0.0 doesn't automatically set up all the
  configuration for sssd to control sudo access, but I have set up all
  the configuration necessary manually:
  
  
  On the client, /etc/nsswitch.conf has 
  
  
sudoers files sss   
  
  
  /etc/sssd/sssd/conf has
  
  
  [domain/default]
  
  
  cache_credentials = True
  krb5_realm = REALM
  krb5_server = ipa server:88
  id_provider = ldap
  auth_provider = ldap
  chpass_provider = ldap
  ldap_tls_cacertdir = /etc/openldap/cacerts
  [domain/domain]
  
  
  cache_credentials = True
  krb5_store_password_if_offline = True
  ipa_domain = domain
  id_provider = ipa
  auth_provider = ipa
  access_provider = ipa
  chpass_provider = ipa
  ipa_dyndns_update = True
  ipa_server = ipa server
  ldap_tls_cacert = /etc/ipa/ca.crt
  sudo_provider = ldap
  ldap_uri = ldap://ipa server
  ldap_sudo_search_base = ou=sudoers,domain base dn
  ldap_sasl_mech = GSSAPI
  ldap_sasl_authid = host/client fqdn
  ldap_sasl_realm = REALM
  krb5_server = ipa server
  debug_level = 9
  [sssd]
  services = nss, pam, ssh, sudo
  config_file_version = 2
  
  
  domains = domain, default
  debug_level = 9
  [nss]
  debug_level = 9
  
  
  [pam]
  debug_level = 9
  
  
  [sudo]
  debug_level = 9
  [autofs]
  
  
  I have validated the ldap sasl configuration using ldapsearch, so I'm
  sure they are correct.
  
  
  The nisdomainname command returns the domain name.
  
  
  The sudo rules are:
  # ipa sudorule-find
  
  2 Sudo Rules matched
  
Rule name: sudo-host1
Enabled: TRUE
Command category: all
RunAs User category: all
User Groups: host1-rw
Host Groups: host1
Sudo Option: -authenticate
  
  
Rule name: sudo-host2
Enabled: TRUE
User Groups: host2-rw
Host Groups: host2
Sudo Option: -authenticate
  
  Number of entries returned 2
  
  
  
  When a user in user group host1-rw sshs to a client in host group
  host1 and runs sudo su - the user gets prompted for a password even
  though the sudo option -authenticate is set.
  I'm not convinced that sudo is even attempting to use sssd, but I'm
  not sure how to confirm this.
  
  
  I have seen some references to /etc/sudo-ldap.conf in online
  discussions of similar issues. This file exists on my client, but
  everything is commented out. Do I need to put the ldap client
  configuration in /etc/sudo-ldap.conf as well as /etc/sssd/sssd.conf
  for CentOS 6.3 clients?
  
  
  Any ideas about how to work out what is failing?
  
  
  Chris
  
 try !authenticate (without the quotes), not  -authenticate (again,
 no quotes).
That made no difference (though I think you're correct that -authenticate is 
wrong).
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] ipa / sudoers on centos 6.3 client

2015-01-02 Thread Brendan Kearney
On Fri, 2015-01-02 at 15:19 +, Chris Card wrote:
 I have existing machines running CentOS 6.3 which I want to include in
 a freeipa domain.
 
 The domain controller machine is running Fedora 21 and
 freeipa-server-4.1.1-2 while the latest version of ipa I can find that
 runs on CentOS 6.3 is ipa-client-3.0.0-37.el6.x86_64.
 
 
 I have successfully run ipa-client-install on the CentOS 6.3 client
 and set up users who can ssh to the client using ssh-keys.
 
 
 The problem is that I can't get sudo rules to work. I know that the
 ipa client software version 3.0.0 doesn't automatically set up all the
 configuration for sssd to control sudo access, but I have set up all
 the configuration necessary manually:
 
 
 On the client, /etc/nsswitch.conf has 
 
 
   sudoers files sss   
 
 
 /etc/sssd/sssd/conf has
 
 
 [domain/default]
 
 
 cache_credentials = True
 krb5_realm = REALM
 krb5_server = ipa server:88
 id_provider = ldap
 auth_provider = ldap
 chpass_provider = ldap
 ldap_tls_cacertdir = /etc/openldap/cacerts
 [domain/domain]
 
 
 cache_credentials = True
 krb5_store_password_if_offline = True
 ipa_domain = domain
 id_provider = ipa
 auth_provider = ipa
 access_provider = ipa
 chpass_provider = ipa
 ipa_dyndns_update = True
 ipa_server = ipa server
 ldap_tls_cacert = /etc/ipa/ca.crt
 sudo_provider = ldap
 ldap_uri = ldap://ipa server
 ldap_sudo_search_base = ou=sudoers,domain base dn
 ldap_sasl_mech = GSSAPI
 ldap_sasl_authid = host/client fqdn
 ldap_sasl_realm = REALM
 krb5_server = ipa server
 debug_level = 9
 [sssd]
 services = nss, pam, ssh, sudo
 config_file_version = 2
 
 
 domains = domain, default
 debug_level = 9
 [nss]
 debug_level = 9
 
 
 [pam]
 debug_level = 9
 
 
 [sudo]
 debug_level = 9
 [autofs]
 
 
 I have validated the ldap sasl configuration using ldapsearch, so I'm
 sure they are correct.
 
 
 The nisdomainname command returns the domain name.
 
 
 The sudo rules are:
 # ipa sudorule-find
 
 2 Sudo Rules matched
 
   Rule name: sudo-host1
   Enabled: TRUE
   Command category: all
   RunAs User category: all
   User Groups: host1-rw
   Host Groups: host1
   Sudo Option: -authenticate
 
 
   Rule name: sudo-host2
   Enabled: TRUE
   User Groups: host2-rw
   Host Groups: host2
   Sudo Option: -authenticate
 
 Number of entries returned 2
 
 
 
 When a user in user group host1-rw sshs to a client in host group
 host1 and runs sudo su - the user gets prompted for a password even
 though the sudo option -authenticate is set.
 I'm not convinced that sudo is even attempting to use sssd, but I'm
 not sure how to confirm this.
 
 
 I have seen some references to /etc/sudo-ldap.conf in online
 discussions of similar issues. This file exists on my client, but
 everything is commented out. Do I need to put the ldap client
 configuration in /etc/sudo-ldap.conf as well as /etc/sssd/sssd.conf
 for CentOS 6.3 clients?
 
 
 Any ideas about how to work out what is failing?
 
 
 Chris
 
try !authenticate (without the quotes), not  -authenticate (again,
no quotes).


-- 
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] ipa / sudoers on centos 6.3 client

2015-01-02 Thread Dmitri Pal

On 01/02/2015 12:12 PM, Craig White wrote:


*From:*freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] *On Behalf Of *Chris Card

*Sent:* Friday, January 02, 2015 8:45 AM
*To:* Brendan Kearney
*Cc:* freeipa-users@redhat.com
*Subject:* Re: [Freeipa-users] ipa / sudoers on centos 6.3 client

 Subject: Re: [Freeipa-users] ipa / sudoers on centos 6.3 client
 From: bpk...@gmail.com mailto:bpk...@gmail.com
 To: ctc...@hotmail.com mailto:ctc...@hotmail.com
 CC: freeipa-users@redhat.com mailto:freeipa-users@redhat.com
 Date: Fri, 2 Jan 2015 10:28:16 -0500

 On Fri, 2015-01-02 at 15:19 +, Chris Card wrote:
  I have existing machines running CentOS 6.3 which I want to include in
  a freeipa domain.
 
  The domain controller machine is running Fedora 21 and
  freeipa-server-4.1.1-2 while the latest version of ipa I can find that
  runs on CentOS 6.3 is ipa-client-3.0.0-37.el6.x86_64.
 
 
  I have successfully run ipa-client-install on the CentOS 6.3 client
  and set up users who can ssh to the client using ssh-keys.
 
 
  The problem is that I can't get sudo rules to work. I know that the
  ipa client software version 3.0.0 doesn't automatically set up all the
  configuration for sssd to control sudo access, but I have set up all
  the configuration necessary manually:
 
 
  On the client, /etc/nsswitch.conf has
 
 
  sudoers files sss
 
 
  /etc/sssd/sssd/conf has
 
 
  [domain/default]
 
 
  cache_credentials = True
  krb5_realm = REALM
  krb5_server = ipa server:88
  id_provider = ldap
  auth_provider = ldap
  chpass_provider = ldap
  ldap_tls_cacertdir = /etc/openldap/cacerts
  [domain/domain]
 
 
  cache_credentials = True
  krb5_store_password_if_offline = True
  ipa_domain = domain
  id_provider = ipa
  auth_provider = ipa
  access_provider = ipa
  chpass_provider = ipa
  ipa_dyndns_update = True
  ipa_server = ipa server
  ldap_tls_cacert = /etc/ipa/ca.crt
  sudo_provider = ldap
  ldap_uri = ldap://ipa server
  ldap_sudo_search_base = ou=sudoers,domain base dn
  ldap_sasl_mech = GSSAPI
  ldap_sasl_authid = host/client fqdn
  ldap_sasl_realm = REALM
  krb5_server = ipa server
  debug_level = 9
  [sssd]
  services = nss, pam, ssh, sudo
  config_file_version = 2
 
 
  domains = domain, default
  debug_level = 9
  [nss]
  debug_level = 9
 
 
  [pam]
  debug_level = 9
 
 
  [sudo]
  debug_level = 9
  [autofs]
 
 
  I have validated the ldap sasl configuration using ldapsearch, so I'm
  sure they are correct.
 
 
  The nisdomainname command returns the domain name.
 
 
  The sudo rules are:
  # ipa sudorule-find
  
  2 Sudo Rules matched
  
  Rule name: sudo-host1
  Enabled: TRUE
  Command category: all
  RunAs User category: all
  User Groups: host1-rw
  Host Groups: host1
  Sudo Option: -authenticate
 
 
  Rule name: sudo-host2
  Enabled: TRUE
  User Groups: host2-rw
  Host Groups: host2
  Sudo Option: -authenticate
  
  Number of entries returned 2
  
 
 
  When a user in user group host1-rw sshs to a client in host group
  host1 and runs sudo su - the user gets prompted for a password even
  though the sudo option -authenticate is set.
  I'm not convinced that sudo is even attempting to use sssd, but I'm
  not sure how to confirm this.
 
 
  I have seen some references to /etc/sudo-ldap.conf in online
  discussions of similar issues. This file exists on my client, but
  everything is commented out. Do I need to put the ldap client
  configuration in /etc/sudo-ldap.conf as well as /etc/sssd/sssd.conf
  for CentOS 6.3 clients?
 
 
  Any ideas about how to work out what is failing?
 
 
  Chris
 
 try !authenticate (without the quotes), not -authenticate (again,
 no quotes).
That made no difference (though I think you're correct that 
-authenticate is wrong).


Sudo didn't work correctly for me until I updated to RHEL 6.6 which 
had sssd-1.11


Just saying...

Craig





I think 6.3 is the last version where SUDO integration with SSSD does 
not work out of box.
You would need to configure SUDO independently from SSSD in the old way 
using direct LDAP connection.

AFAIR the configurtion is in the sudo-ldap.conf.

Find the RHEL 6.3 manual online. I think the doc is correct except that 
it mentions ldap.conf instead of sudo-ldap.
Sorry if the names above are not spelled right (may be it is sudo_ldap 
or something like), I was writing from the top of my head.



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

Re: [Freeipa-users] ipa / sudoers on centos 6.3 client

2015-01-02 Thread William Muriithi
‎Hi,

I also think you will have to update to rhel 6.6 if you want to use sssd for 
sudo. If updating to 6.6 is not a problem, this would be least painful. 

   The problem is that I can't get sudo rules to work. I know that the
   ipa client software version 3.0.0 doesn't automatically set up all the
   configuration for sssd to control sudo access, but I have set up all
   the configuration necessary manually:
  
  
   On the client, /etc/nsswitch.conf has
  
  
   sudoers files sss

This will work only for rhel 6.6. Add ldap between files and sss if you 
wouldn't be using 6.6

  
  
   /etc/sssd/sssd/conf has
  
  
   [domain/default]
  
  
   cache_credentials = True
   krb5_realm = REALM
   krb5_server = ipa server:88
   id_provider = ldap
   auth_provider = ldap
   chpass_provider = ldap
   ldap_tls_cacertdir = /etc/openldap/cacerts
   [domain/domain]
Remove the ldap related lines if on 6.6. If you are not going to use 6.6, keep 
them, but add a bind password on ipa-server as it can't bind anonymously
  
  
   cache_credentials = True
   krb5_store_password_if_offline = True
   ipa_domain = domain
   id_provider = ipa
   auth_provider = ipa
   access_provider = ipa
   chpass_provider = ipa
   ipa_dyndns_update = True
   ipa_server = ipa server
   ldap_tls_cacert = /etc/ipa/ca.crt
   sudo_provider = ldap
This is assuming you are not using 6.6, else replace ldap with sss
   ldap_uri = ldap://ipa server
   ldap_sudo_search_base = ou=sudoers,domain base dn
   ldap_sasl_mech = GSSAPI
   ldap_sasl_authid = host/client fqdn
   ldap_sasl_realm = REALM
   krb5_server = ipa server
   debug_level = 9
   [sssd]
   services = nss, pam, ssh, sudo
   config_file_version = 2
  
  
   domains = domain, default
   debug_level = 9
   [nss]
   debug_level = 9
  
  
   [pam]
   debug_level = 9
  
  
   [sudo]
   debug_level = 9
   [autofs]
  
  
   I have validated the ldap sasl configuration using ldapsearch, so I'm
   sure they are correct.
  
  
   The nisdomainname command returns the domain name.
  
  
   The sudo rules are:
   # ipa sudorule-find
   
   2 Sudo Rules matched
   
   Rule name: sudo-host1
   Enabled: TRUE
   Command category: all
   RunAs User category: all
   User Groups: host1-rw
   Host Groups: host1
   Sudo Option: -authenticate
  
  
   Rule name: sudo-host2
   Enabled: TRUE
   User Groups: host2-rw
   Host Groups: host2
   Sudo Option: -authenticate
   
   Number of entries returned 2
   
  
  
   When a user in user group host1-rw sshs to a client in host group
   host1 and runs sudo su - the user gets prompted for a password even
   though the sudo option -authenticate is set.
   I'm not convinced that sudo is even attempting to use sssd, but I'm
   not sure how to confirm this.

I think command group all or category all may be problematic. Enable debugging 
to see if category all is being considered. For me, I had to adjust that, but 
can't recall how I went around it from memory.
  
  
   I have seen some references to /etc/sudo-ldap.conf in online
   discussions of similar issues. This file exists on my client, but
   everything is commented out. Do I need to put the ldap client
   configuration in /etc/sudo-ldap.conf as well as /etc/sssd/sssd.conf
   for CentOS 6.3 clients?
Yes. Uncomment the lines that are commented with a single # and customize it 
with your realm details plus password you created on ipa-server. At the bottom, 
enable debugging in case it don't work on first attempt. 

If you are on 6.6, disregard this file
  
  
   Any ideas about how to work out what is failing?
William 

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