Re: [Freeipa-users] ipa / sudoers on centos 6.3 client
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
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
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
[Freeipa-users] ipa / sudoers on centos 6.3 client
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 = Truekrb5_realm = REALMkrb5_server = ipa server:88id_provider = ldapauth_provider = ldapchpass_provider = ldapldap_tls_cacertdir = /etc/openldap/cacerts[domain/domain] cache_credentials = Truekrb5_store_password_if_offline = Trueipa_domain = domainid_provider = ipaauth_provider = ipaaccess_provider = ipachpass_provider = ipaipa_dyndns_update = Trueipa_server = ipa serverldap_tls_cacert = /etc/ipa/ca.crtsudo_provider = ldapldap_uri = ldap://ipa serverldap_sudo_search_base = ou=sudoers,domain base dnldap_sasl_mech = GSSAPIldap_sasl_authid = host/client fqdnldap_sasl_realm = REALMkrb5_server = ipa serverdebug_level = 9[sssd]services = nss, pam, ssh, sudoconfig_file_version = 2 domains = domain, defaultdebug_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-find2 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: -authenticateNumber 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 -- 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] trust non-IPA certificate client
Stephen Ingram wrote: On Mon, Dec 15, 2014 at 6:40 PM, Stephen Ingram sbing...@gmail.com mailto:sbing...@gmail.com wrote: I have one client using a certificate issued by a third party provider such that any secure (TLS) LDAP queries are refused since the certificates were not issued by IPA. Since there are only a few clients with foreign certificates, can the CA simply be added to the NSS database used by the 389 directory server so IPA will establish a secure connection with them? I should have added, or do I have to somehow add the certificate to the IPA directory? Need a little more context here. IPA doesn't use SSL client authentication so it shouldn't be an issue. Can you provide more details on what the client side is doing and what errors you are seeing? rob -- 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] Integration with Solaris 10
Watson, Dan wrote: Hi Rob, Thanks for the reply. Unfortunately /usr/bin/getent on my system doesn't seem to like the netgroup option: -bash-3.2# getent netgroup test1 Unknown database: netgroup usage: getent database [ key ... ] -bash-3.2# uname -a SunOS vdcudantest01 5.10 Generic_147440-27 sun4v sparc SUNW,SPARC-Enterprise-T5120 -bash-3.2# cat /etc/release Solaris 10 10/09 s10s_u8wos_08a SPARC Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 16 September 2009 -bash-3.2# Sorry, my Solaris is very rusty. You need to add a service descriptor to the DUA profile if you haven't already, something like: serviceSearchDescriptor: netgroup:cn=ng,cn=compat,dc=example,dc=com Then re-init the client. getent is still not going to work but ldaplist will: # ldaplist netgroup rob Thanks! Dan -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: January 02, 2015 10:15 AM To: Watson, Dan; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Integration with Solaris 10 Watson, Dan wrote: Hi All, I've lurked in the list history and cannot find anyone saying they have gotten login restrictions working with Solaris 10 u8. Has anyone on here successfully configured login restrictions on Solaris 10 u8 through u11? I'm looking for specific instructions from someone who has gotten this to work before. The two main routes to login restrictions I could find online are Netgroups or conditional ldap queries in ldapclient I initially tried netgroups but wasn't sure how to trouble shoot when it didn't work. There don't seem to be any user-land tools to query netgroups and further investigation turned up an issue with OpenLDAP. It seems the built-in Solaris 10 ldap client expects schema RFC2307bis and not the OpenLDAP standard RFC2307 (explanation here http://www.openldap.org/lists/openldap-software/200501/msg00309.html). does anyone know if this issue applies to IPA? Or how I check? The alternative of passing a restrictive query to ldapclient seems like a good route but doesn't seem to work. The common solution when using the old SunOne directory server was to pass the ldapclient (command line ldap configuration tool) an option like passwd:ou=people,o=myorg,c=de?one?(isMemberof=cn=unixadmins,ou=groups,o=myorg,c=de) (from here https://community.oracle.com/thread/2014224?start=0tstart=0) which is supposed to restrict account checking to only people in ou=people,p=myorg,c=de who are also members of cn=unixadmins,ou=groups,o=myorg,c=de. Unfortunately this doesn't seem to work in IPA, first of all because there is no isMemberof attribute to a user, but also doesn't work on other attributes like uid or uidNumber. One possible explanation I've found is that these attributes are not indexed, but I have no idea if this is correct or how to add them to be indexed. Has anyone else solved this? I just need to be able to allow only a specific user group to log in to the host, unfortunately the ssh directive AllowGroups is not good enough, this has to be system wide as we also have samba and some other services that rely on system authentication. Can anyone be of some help? Thanks! Dan You can use getent netgroup name to get a specific netgroup. Or ldapsearch -x -b cn=usertest,cn=ng,cn=compat,dc=example,dc=com rob -- 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] Integration with Solaris 10
Watson, Dan wrote: I finally got it working, the default setup of ldapclient init missed the special mapping for netgroups, so I had to do a manual setup that included the mapping. ldapclient manual \ -a credentialLevel=anonymous \ -a authenticationMethod=none \ -a defaultSearchBase=dn=domain,dn=name \ -a domainName=domain.name \ -a defaultServerList=server.domain.name \ -a objectClassMap=shadow:shadowAccount=posixaccount \ -a serviceSearchDescriptor='passwd:cn=users,cn=accounts,dc=bcferries,dc=corp' \ -a serviceSearchDescriptor=group:cn=groups,cn=accounts,dc=bcferries,dc=corp \ -a serviceSearchDescriptor=sudoers:cn=sysaccounts,cn=etc,dc=bcferries,dc=corp \ -a serviceSearchDescriptor=netgroup:cn=ng,cn=compat,dc=bcferries,dc=corp It's the last line that forces the OS level ldap client to look in the rich location for the netgroup information. I hope this helps the next person. Glad you got it working, and that'll teach me to catch up on all e-mail before responding :-) rob Thanks for all the help! Dan -Original Message- From: Watson, Dan Sent: January 02, 2015 11:41 AM To: 'Rob Crittenden'; freeipa-users@redhat.com Subject: RE: [Freeipa-users] Integration with Solaris 10 Hi Rob, Thanks for the reply. Unfortunately /usr/bin/getent on my system doesn't seem to like the netgroup option: -bash-3.2# getent netgroup test1 Unknown database: netgroup usage: getent database [ key ... ] -bash-3.2# uname -a SunOS vdcudantest01 5.10 Generic_147440-27 sun4v sparc SUNW,SPARC-Enterprise-T5120 -bash-3.2# cat /etc/release Solaris 10 10/09 s10s_u8wos_08a SPARC Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 16 September 2009 -bash-3.2# Thanks! Dan -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: January 02, 2015 10:15 AM To: Watson, Dan; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Integration with Solaris 10 Watson, Dan wrote: Hi All, I've lurked in the list history and cannot find anyone saying they have gotten login restrictions working with Solaris 10 u8. Has anyone on here successfully configured login restrictions on Solaris 10 u8 through u11? I'm looking for specific instructions from someone who has gotten this to work before. The two main routes to login restrictions I could find online are Netgroups or conditional ldap queries in ldapclient I initially tried netgroups but wasn't sure how to trouble shoot when it didn't work. There don't seem to be any user-land tools to query netgroups and further investigation turned up an issue with OpenLDAP. It seems the built-in Solaris 10 ldap client expects schema RFC2307bis and not the OpenLDAP standard RFC2307 (explanation here http://www.openldap.org/lists/openldap-software/200501/msg00309.html). does anyone know if this issue applies to IPA? Or how I check? The alternative of passing a restrictive query to ldapclient seems like a good route but doesn't seem to work. The common solution when using the old SunOne directory server was to pass the ldapclient (command line ldap configuration tool) an option like passwd:ou=people,o=myorg,c=de?one?(isMemberof=cn=unixadmins,ou=groups,o=myorg,c=de) (from here https://community.oracle.com/thread/2014224?start=0tstart=0) which is supposed to restrict account checking to only people in ou=people,p=myorg,c=de who are also members of cn=unixadmins,ou=groups,o=myorg,c=de. Unfortunately this doesn't seem to work in IPA, first of all because there is no isMemberof attribute to a user, but also doesn't work on other attributes like uid or uidNumber. One possible explanation I've found is that these attributes are not indexed, but I have no idea if this is correct or how to add them to be indexed. Has anyone else solved this? I just need to be able to allow only a specific user group to log in to the host, unfortunately the ssh directive AllowGroups is not good enough, this has to be system wide as we also have samba and some other services that rely on system authentication. Can anyone be of some help? Thanks! Dan You can use getent netgroup name to get a specific netgroup. Or ldapsearch -x -b cn=usertest,cn=ng,cn=compat,dc=example,dc=com rob -- 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] Integration with Solaris 10
On 01/02/2015 03:17 PM, Watson, Dan wrote: I finally got it working, the default setup of ldapclient init missed the special mapping for netgroups, so I had to do a manual setup that included the mapping. ldapclient manual \ -a credentialLevel=anonymous \ -a authenticationMethod=none \ -a defaultSearchBase=dn=domain,dn=name \ -a domainName=domain.name \ -a defaultServerList=server.domain.name \ -a objectClassMap=shadow:shadowAccount=posixaccount \ -a serviceSearchDescriptor='passwd:cn=users,cn=accounts,dc=bcferries,dc=corp' \ -a serviceSearchDescriptor=group:cn=groups,cn=accounts,dc=bcferries,dc=corp \ -a serviceSearchDescriptor=sudoers:cn=sysaccounts,cn=etc,dc=bcferries,dc=corp \ -a serviceSearchDescriptor=netgroup:cn=ng,cn=compat,dc=bcferries,dc=corp It's the last line that forces the OS level ldap client to look in the rich location for the netgroup information. I hope this helps the next person. Would you mind creating a wiki page with the solution on the wiki? Thanks for all the help! Dan -Original Message- From: Watson, Dan Sent: January 02, 2015 11:41 AM To: 'Rob Crittenden'; freeipa-users@redhat.com Subject: RE: [Freeipa-users] Integration with Solaris 10 Hi Rob, Thanks for the reply. Unfortunately /usr/bin/getent on my system doesn't seem to like the netgroup option: -bash-3.2# getent netgroup test1 Unknown database: netgroup usage: getent database [ key ... ] -bash-3.2# uname -a SunOS vdcudantest01 5.10 Generic_147440-27 sun4v sparc SUNW,SPARC-Enterprise-T5120 -bash-3.2# cat /etc/release Solaris 10 10/09 s10s_u8wos_08a SPARC Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 16 September 2009 -bash-3.2# Thanks! Dan -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: January 02, 2015 10:15 AM To: Watson, Dan; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Integration with Solaris 10 Watson, Dan wrote: Hi All, I've lurked in the list history and cannot find anyone saying they have gotten login restrictions working with Solaris 10 u8. Has anyone on here successfully configured login restrictions on Solaris 10 u8 through u11? I'm looking for specific instructions from someone who has gotten this to work before. The two main routes to login restrictions I could find online are Netgroups or conditional ldap queries in ldapclient I initially tried netgroups but wasn't sure how to trouble shoot when it didn't work. There don't seem to be any user-land tools to query netgroups and further investigation turned up an issue with OpenLDAP. It seems the built-in Solaris 10 ldap client expects schema RFC2307bis and not the OpenLDAP standard RFC2307 (explanation here http://www.openldap.org/lists/openldap-software/200501/msg00309.html). does anyone know if this issue applies to IPA? Or how I check? The alternative of passing a restrictive query to ldapclient seems like a good route but doesn't seem to work. The common solution when using the old SunOne directory server was to pass the ldapclient (command line ldap configuration tool) an option like passwd:ou=people,o=myorg,c=de?one?(isMemberof=cn=unixadmins,ou=groups,o=myorg,c=de) (from here https://community.oracle.com/thread/2014224?start=0tstart=0) which is supposed to restrict account checking to only people in ou=people,p=myorg,c=de who are also members of cn=unixadmins,ou=groups,o=myorg,c=de. Unfortunately this doesn't seem to work in IPA, first of all because there is no isMemberof attribute to a user, but also doesn't work on other attributes like uid or uidNumber. One possible explanation I've found is that these attributes are not indexed, but I have no idea if this is correct or how to add them to be indexed. Has anyone else solved this? I just need to be able to allow only a specific user group to log in to the host, unfortunately the ssh directive AllowGroups is not good enough, this has to be system wide as we also have samba and some other services that rely on system authentication. Can anyone be of some help? Thanks! Dan You can use getent netgroup name to get a specific netgroup. Or ldapsearch -x -b cn=usertest,cn=ng,cn=compat,dc=example,dc=com rob -- 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] Integration with Solaris 10
I finally got it working, the default setup of ldapclient init missed the special mapping for netgroups, so I had to do a manual setup that included the mapping. ldapclient manual \ -a credentialLevel=anonymous \ -a authenticationMethod=none \ -a defaultSearchBase=dn=domain,dn=name \ -a domainName=domain.name \ -a defaultServerList=server.domain.name \ -a objectClassMap=shadow:shadowAccount=posixaccount \ -a serviceSearchDescriptor='passwd:cn=users,cn=accounts,dc=bcferries,dc=corp' \ -a serviceSearchDescriptor=group:cn=groups,cn=accounts,dc=bcferries,dc=corp \ -a serviceSearchDescriptor=sudoers:cn=sysaccounts,cn=etc,dc=bcferries,dc=corp \ -a serviceSearchDescriptor=netgroup:cn=ng,cn=compat,dc=bcferries,dc=corp It's the last line that forces the OS level ldap client to look in the rich location for the netgroup information. I hope this helps the next person. Thanks for all the help! Dan -Original Message- From: Watson, Dan Sent: January 02, 2015 11:41 AM To: 'Rob Crittenden'; freeipa-users@redhat.com Subject: RE: [Freeipa-users] Integration with Solaris 10 Hi Rob, Thanks for the reply. Unfortunately /usr/bin/getent on my system doesn't seem to like the netgroup option: -bash-3.2# getent netgroup test1 Unknown database: netgroup usage: getent database [ key ... ] -bash-3.2# uname -a SunOS vdcudantest01 5.10 Generic_147440-27 sun4v sparc SUNW,SPARC-Enterprise-T5120 -bash-3.2# cat /etc/release Solaris 10 10/09 s10s_u8wos_08a SPARC Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 16 September 2009 -bash-3.2# Thanks! Dan -Original Message- From: Rob Crittenden [mailto:rcrit...@redhat.com] Sent: January 02, 2015 10:15 AM To: Watson, Dan; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Integration with Solaris 10 Watson, Dan wrote: Hi All, I've lurked in the list history and cannot find anyone saying they have gotten login restrictions working with Solaris 10 u8. Has anyone on here successfully configured login restrictions on Solaris 10 u8 through u11? I'm looking for specific instructions from someone who has gotten this to work before. The two main routes to login restrictions I could find online are Netgroups or conditional ldap queries in ldapclient I initially tried netgroups but wasn't sure how to trouble shoot when it didn't work. There don't seem to be any user-land tools to query netgroups and further investigation turned up an issue with OpenLDAP. It seems the built-in Solaris 10 ldap client expects schema RFC2307bis and not the OpenLDAP standard RFC2307 (explanation here http://www.openldap.org/lists/openldap-software/200501/msg00309.html). does anyone know if this issue applies to IPA? Or how I check? The alternative of passing a restrictive query to ldapclient seems like a good route but doesn't seem to work. The common solution when using the old SunOne directory server was to pass the ldapclient (command line ldap configuration tool) an option like passwd:ou=people,o=myorg,c=de?one?(isMemberof=cn=unixadmins,ou=groups,o=myorg,c=de) (from here https://community.oracle.com/thread/2014224?start=0tstart=0) which is supposed to restrict account checking to only people in ou=people,p=myorg,c=de who are also members of cn=unixadmins,ou=groups,o=myorg,c=de. Unfortunately this doesn't seem to work in IPA, first of all because there is no isMemberof attribute to a user, but also doesn't work on other attributes like uid or uidNumber. One possible explanation I've found is that these attributes are not indexed, but I have no idea if this is correct or how to add them to be indexed. Has anyone else solved this? I just need to be able to allow only a specific user group to log in to the host, unfortunately the ssh directive AllowGroups is not good enough, this has to be system wide as we also have samba and some other services that rely on system authentication. Can anyone be of some help? Thanks! Dan You can use getent netgroup name to get a specific netgroup. Or ldapsearch -x -b cn=usertest,cn=ng,cn=compat,dc=example,dc=com rob -- 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
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] Integration with Solaris 10
Watson, Dan wrote: Hi All, I've lurked in the list history and cannot find anyone saying they have gotten login restrictions working with Solaris 10 u8. Has anyone on here successfully configured login restrictions on Solaris 10 u8 through u11? I'm looking for specific instructions from someone who has gotten this to work before. The two main routes to login restrictions I could find online are Netgroups or conditional ldap queries in ldapclient I initially tried netgroups but wasn't sure how to trouble shoot when it didn't work. There don't seem to be any user-land tools to query netgroups and further investigation turned up an issue with OpenLDAP. It seems the built-in Solaris 10 ldap client expects schema RFC2307bis and not the OpenLDAP standard RFC2307 (explanation here http://www.openldap.org/lists/openldap-software/200501/msg00309.html). does anyone know if this issue applies to IPA? Or how I check? The alternative of passing a restrictive query to ldapclient seems like a good route but doesn't seem to work. The common solution when using the old SunOne directory server was to pass the ldapclient (command line ldap configuration tool) an option like passwd:ou=people,o=myorg,c=de?one?(isMemberof=cn=unixadmins,ou=groups,o=myorg,c=de) (from here https://community.oracle.com/thread/2014224?start=0tstart=0) which is supposed to restrict account checking to only people in ou=people,p=myorg,c=de who are also members of cn=unixadmins,ou=groups,o=myorg,c=de. Unfortunately this doesn't seem to work in IPA, first of all because there is no isMemberof attribute to a user, but also doesn't work on other attributes like uid or uidNumber. One possible explanation I've found is that these attributes are not indexed, but I have no idea if this is correct or how to add them to be indexed. Has anyone else solved this? I just need to be able to allow only a specific user group to log in to the host, unfortunately the ssh directive AllowGroups is not good enough, this has to be system wide as we also have samba and some other services that rely on system authentication. Can anyone be of some help? Thanks! Dan You can use getent netgroup name to get a specific netgroup. Or ldapsearch -x -b cn=usertest,cn=ng,cn=compat,dc=example,dc=com rob -- 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] KDC has no support for encryption type
On 12/30/2014 06:06 AM, Matt . wrote: Readin up on this the weak password setting should work, but it doesn't. What are my chances here as I need to do a ipa pwpolicy-mod --maxlife 200 This touches the expiration not the encryption types. Or can this be done from a ldap browser too ? Yes. It sets the global kerberos password expiration attribute. 2014-12-29 23:31 GMT+01:00 Matt . yamakasi@gmail.com: OK, thank for that. But should an IPA install not add them by default ? Maybe this is some 4.x dev which is still needed ? I need to look what I exactly need. -- 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] IPA trust integration in AD Forests that been upgraded to higher functional level
Hello all. I'm working on integrating AD trust feature in the forest of a large organization (Its network is not connected to the internet). First I tested the trust in clean environment (that i have deployed) to simulate production forest deployment , in the following configuration: The forest root domain : red.com Second Domain tree : blue.com IPA : linux.blue.com All the AD DCs are 2008 R2 server and 2008 R2 functional level. IPA server in installed on RHEL 7. ipa-server-3.3.3-28.el7_0.1.x86_64 ipa-server-trust-ad-3.3.3-28.el7_0.1.x86_64 ipa-python-3.3.3-28.el7_0.1.x86_64 With help of the mailing list, all works fine. Users from both red.com and blue.com are able to log into IPA domain. After the success, I proceeded to test the trust in organization's test environment. The installation of the trust itself has completed successfully. But although users from *red.com http://red.com* were able to log into IPA domain, users from *blue.com http://blue.com* couldn't. After checking the sssd logs it seemed as blue.com domain is unknown to IPA. Therefore I ran *ipa trustdomain-find red.com http://red.com *in both environments, to see if there are any differences. And indeed there were: While in the clean environment, the command returned both *red.com http://red.com* and *blue.com http://blue.com* domains, in organization's test environment it returned only *red.com http://red.com*. I tried to re fetch the domain with *ipa trust-fetch-domains red.com http://red.com *but it returned the message - No new trust domains were found. It made me think that maybe the AD is not returning all domains in the forest. I opened wireshark on both environments and ran *ipa trust-fetch-domains red.com http://red.com *to see what is been sent from AD to IPA. In both environments I seen the DsrEnumerateDomainTrusts request and response. Reading the content of response showed that in both environments, the response contained *red.com http://red.com* and *blue.com http://blue.com* domain. After inspecting the structures that contain domains information (DS_DOMAIN_TRUSTS) , I noticed that in both environments the *TrustAttribute *of red.com is set to 0x000. But *TrustAttribute *of blue.com is set to 0x0020 ( TRUST_ATTRIBUTE_WITHIN_FOREST) in the clean environment and to 0x0080 in the test environment. Reading MSDN for *TrustAttribute*, explains the following: http://msdn.microsoft.com/en-us/library/cc223779.aspx (TRUST_ATTRIBUTE_WITHIN_FOREST) 0x0020 If this bit is set, then the trusted domain is within the same forest. Only evaluated on Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2. While I couldn't find specific information about 0x0080, but this: 0x0040 - 0x0080 Previously used trust bits, and are obsolete. I did not find more information on 0x0080 or a reason why the attributes would be different in the two deployments. I asked for advice from Microsoft IT guy in the organization. He said that difference in the *TrustAttribute *is caused by the fact, that the clean environment was created as Windows Server 2008, while the test (and production) forest was created as windows 2000 servers (about 12 years ago) and the forest was gradually upgraded to 2003 and 2008 along the years. Couldn't find more information on the attribute for windows server 2000/2003 but the theory sounds quite logical. I decided to check if *TrustAttribute *influences IPA's domain fetch. fetch_domains function in /usr/lib/python2.7/site-packages/ipaserver/dcerpc.py contains the following lines of code: trust_attributes = dict( NETR_TRUST_ATTRIBUTE_NON_TRANSITIVE = 0x0001, NETR_TRUST_ATTRIBUTE_UPLEVEL_ONLY = 0x0002, NETR_TRUST_ATTRIBUTE_QUARANTINED_DOMAIN = 0x0004, NETR_TRUST_ATTRIBUTE_FOREST_TRANSITIVE = 0x0008, NETR_TRUST_ATTRIBUTE_CROSS_ORGANIZATION = 0x0010, NETR_TRUST_ATTRIBUTE_WITHIN_FOREST = 0x0020, NETR_TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL = 0x0040) . . . result = [] for t in domains.array: *if ((t.trust_attributes trust_attributes['NETR_TRUST_ATTRIBUTE_WITHIN_FOREST']) and* *(t.trust_flags trust_flags['NETR_TRUST_FLAG_IN_FOREST'])):* res = dict() res['cn'] = unicode(t.dns_name) res['ipantflatname'] = unicode(t.netbios_name) res['ipanttrusteddomainsid'] = unicode(t.sid) res['ipanttrustpartner'] = res['cn'] result.append(res) The bit-wise operation is preformed to check if the trust attribute is set to TRUST_ATTRIBUTE_WITHIN_FOREST (0x0020) and if so, the trust is added to result array. It seems the value of *TrustAttribute *set to 0x0080 is the reason the domain
Re: [Freeipa-users] ipa / sudoers on centos 6.3 client
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
