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

2015-01-02 Thread Chris Card 
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 = krb5_server = :88id_provider = ldapauth_provider = ldapchpass_provider = 
ldapldap_tls_cacertdir = /etc/openldap/cacerts[domain/]
cache_credentials = Truekrb5_store_password_if_offline = Trueipa_domain = 
id_provider = ipaauth_provider = ipaaccess_provider = 
ipachpass_provider = ipaipa_dyndns_update = Trueipa_server = ldap_tls_cacert = /etc/ipa/ca.crtsudo_provider = ldapldap_uri = 
ldap://ldap_sudo_search_base = ou=sudoers,ldap_sasl_mech = GSSAPIldap_sasl_authid = host/ldap_sasl_realm 
= krb5_server = debug_level = 9[sssd]services = nss, pam, 
ssh, sudoconfig_file_version = 2
domains = , 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] 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 = 
> krb5_server = :88
> id_provider = ldap
> auth_provider = ldap
> chpass_provider = ldap
> ldap_tls_cacertdir = /etc/openldap/cacerts
> [domain/]
> 
> 
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = 
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> chpass_provider = ipa
> ipa_dyndns_update = True
> ipa_server = 
> ldap_tls_cacert = /etc/ipa/ca.crt
> sudo_provider = ldap
> ldap_uri = ldap://
> ldap_sudo_search_base = ou=sudoers,
> ldap_sasl_mech = GSSAPI
> ldap_sasl_authid = host/
> ldap_sasl_realm = 
> krb5_server = 
> debug_level = 9
> [sssd]
> services = nss, pam, ssh, sudo
> config_file_version = 2
> 
> 
> domains = , 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 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 = 
> > krb5_server = :88
> > id_provider = ldap
> > auth_provider = ldap
> > chpass_provider = ldap
> > ldap_tls_cacertdir = /etc/openldap/cacerts
> > [domain/]
> > 
> > 
> > cache_credentials = True
> > krb5_store_password_if_offline = True
> > ipa_domain = 
> > id_provider = ipa
> > auth_provider = ipa
> > access_provider = ipa
> > chpass_provider = ipa
> > ipa_dyndns_update = True
> > ipa_server = 
> > ldap_tls_cacert = /etc/ipa/ca.crt
> > sudo_provider = ldap
> > ldap_uri = ldap://
> > ldap_sudo_search_base = ou=sudoers,
> > ldap_sasl_mech = GSSAPI
> > ldap_sasl_authid = host/
> > ldap_sasl_realm = 
> > krb5_server = 
> > debug_level = 9
> > [sssd]
> > services = nss, pam, ssh, sudo
> > config_file_version = 2
> > 
> > 
> > domains = , 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 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.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 = 
> > krb5_server = :88
> > id_provider = ldap
> > auth_provider = ldap
> > chpass_provider = ldap
> > ldap_tls_cacertdir = /etc/openldap/cacerts
> > [domain/]
> >
> >
> > cache_credentials = True
> > krb5_store_password_if_offline = True
> > ipa_domain = 
> > id_provider = ipa
> > auth_provider = ipa
> > access_provider = ipa
> > chpass_provider = ipa
> > ipa_dyndns_update = True
> > ipa_server = 
> > ldap_tls_cacert = /etc/ipa/ca.crt
> > sudo_provider = ldap
> > ldap_uri = ldap://
> > ldap_sudo_search_base = ou=sudoers,
> > ldap_sasl_mech = GSSAPI
> > ldap_sasl_authid = host/
> > ldap_sasl_realm = 
> > krb5_server = 
> > debug_level = 9
> > [sssd]
> > services = nss, pam, ssh, sudo
> > config_file_version = 2
> >
> >
> > domains = , 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] trust non-IPA certificate client

2015-01-02 Thread Rob Crittenden 
Stephen Ingram wrote:
> On Mon, Dec 15, 2014 at 6:40 PM, Stephen Ingram  > 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

2015-01-02 Thread Rob Crittenden 
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=0&tstart=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  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

[Freeipa-users] sudo !requiretty !authenticate

2015-01-02 Thread Craig White 
Subject pretty much says it all.

Starting to play around with rundeck and was thinking it would be nice if I 
could create a user that had the ability to sudo, without password, a public 
key and the ability to run commands.

But the use of 'sudo' gets me an error that says it requires a tty to run sudo. 
So I tried by creating a sudo rule that has options '!requiretty !authenticate' 
but it still complains that I need a tty. Is there a FreeIPA method that I am 
lacking?

Craig White
System Administrator
O 623-201-8179   M 602-377-9752

[cid:image001.png@01CF86FE.42D51630]

SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032

-- 
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] firewalld management

2015-01-02 Thread Dmitri Pal 

On 01/01/2015 07:49 PM, Rob Crittenden wrote:

Andrew Holway wrote:

This would perhaps be a very interesting addition to the HBAC stuff.
We're considering deploying freeipa on EC2 and LDAP backed firewalld
would be a very powerful tool for a geographically distributed system.

There is an existing open ticket for this request,
https://fedorahosted.org/freeipa/ticket/2110

A user contributed an initial design was contributed a few months ago,
http://www.freeipa.org/page/V4/Firewall_Configuration

Definitely a desirable feature, just a matter of scheduling it.


It seems that the use cases a bit different.
The ticket talks about the IPA server firewall configuration.
The thread seems to talk about the clients. I do not think we have a 
ticket for that.
The question seems to be: is IPA the right place to store and manage 
firewall rules centrally?

How would they be enforced?
Is it a one time configuration at the client installation or real time 
enforcement of the specific configuration via SSSD or something else?

We start to bridge into SCAP area. Is this the right direction to go?
I have doubts...

Comments welcome!



rob



On 31 December 2014 at 16:56, Jorick Astrego mailto:j.astr...@netbulae.eu>> wrote:

 Hi,

 FreeIPA is great! One thing I'm missing though is management of
 firewalld services and ports.

 Is that something that would fit in FreeIPA?

 Currently we are using puppet scripts through katello/the foreman, but
 as this is very error prone we'd like to have it centrally managed a
 different way.

 The firewall rules are very essential IMHO and I thought the whole
 point
 of firewalld is to have make it more manageable...

 I already asked the katello guys but they don't appear very interested
 in implementing something there, then I started thinking it would maybe
 fit a lot better in freeIPA as it has more overlap with the other
 network/authentication stuff.

 It would be wasteful to have another project just for firewalld
 management.

 Happy new year everybody!

 Jorick







 **
 Met vriendelijke groet, With kind regards,

 Jorick Astrego*

 Netbulae Virtualization Experts *
 
 Tel: 053 20 30 270 i...@netbulae.eu 
 Staalsteden 4-3A   KvK 08198180
 Fax: 053 20 30 271 www.netbulae.eu   7547
 TA EnschedeBTW NL821234584B01


 


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







--
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 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 
> 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 = 
> > krb5_server = :88
> > id_provider = ldap
> > auth_provider = ldap
> > chpass_provider = ldap
> > ldap_tls_cacertdir = /etc/openldap/cacerts
> > [domain/]
> >
> >
> > cache_credentials = True
> > krb5_store_password_if_offline = True
> > ipa_domain = 
> > id_provider = ipa
> > auth_provider = ipa
> > access_provider = ipa
> > chpass_provider = ipa
> > ipa_dyndns_update = True
> > ipa_server = 
> > ldap_tls_cacert = /etc/ipa/ca.crt
> > sudo_provider = ldap
> > ldap_uri = ldap://
> > ldap_sudo_search_base = ou=sudoers,
> > ldap_sasl_mech = GSSAPI
> > ldap_sasl_authid = host/
> > ldap_sasl_realm = 
> > krb5_server = 
> > debug_level = 9
> > [sssd]
> > services = nss, pam, ssh, sudo
> > config_file_version = 2
> >
> >
> > domains = , 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] KDC has no support for encryption type

2015-01-02 Thread Dmitri Pal 

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

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

Re: [Freeipa-users] Integration with Solaris 10

2015-01-02 Thread Watson, Dan 
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=0&tstart=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  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

2015-01-02 Thread Watson, Dan 
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=0&tstart=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  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

2015-01-02 Thread Dmitri Pal 

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=0&tstart=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  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

2015-01-02 Thread Rob Crittenden 
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=0&tstart=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  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

2015-01-02 Thread Rob Crittenden 
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=0&tstart=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  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

[Freeipa-users] IPA trust integration in AD Forests that been upgraded to higher functional level

2015-01-02 Thread Genadi Postrilko 
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 * were able to log into IPA
domain, users from *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 " *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
* and *blue.com * domains, in
organization's test environment it returned only *red.com *.

I tried to re fetch the domain with "*ipa trust-fetch-domains 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 " *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 * and *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

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 = 
> > > krb5_server = :88
> > > id_provider = ldap
> > > auth_provider = ldap
> > > chpass_provider = ldap
> > > ldap_tls_cacertdir = /etc/openldap/cacerts
> > > [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 = 
> > > id_provider = ipa
> > > auth_provider = ipa
> > > access_provider = ipa
> > > chpass_provider = ipa
> > > ipa_dyndns_update = True
> > > 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://
> > > ldap_sudo_search_base = ou=sudoers,
> > > ldap_sasl_mech = GSSAPI
> > > ldap_sasl_authid = host/
> > > ldap_sasl_realm = 
> > > krb5_server = 
> > > debug_level = 9
> > > [sssd]
> > > services = nss, pam, ssh, sudo
> > > config_file_version = 2
> > >
> > >
> > > domains = , 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