Re: [Freeipa-users] OTP vs VPN

2015-05-27 Thread Benjamen Keroack
We've found it easier to integrate a 2FA solution into OpenVPN and local
login separately. If you go with a solution that works with PAM, setting it
up with OpenVPN Access Server (the commercial product) and local login
(FreeIPA-backed) is pretty straightforward. The only thing it won't protect
is the FreeIPA web UI, but if you put that behind a VPN or IP whitelist it
should be less of an issue.

Ben

On Wed, May 27, 2015 at 10:53 AM, Bendl, Kurt kurt.be...@nrel.gov wrote:

 Hi,

 I want to know if I can configure FreeIPA's native OTP solution to require
 an account to use OTP when authenticating from a specific app (OpenVPN or
 StrongSwan) but not require 2FA when logging into a system/server or the
 IPA app.

 My (not completely baked) thought is to provision the VPN solution by
 setting up a role or group in IPA that I'd add accounts into. The VPN would
 allow users of that group to auth, using userid and password+OTP to
 successfully.

 I've been reading through docs on the freeipa and red hat sites, e.g.,
 https://www.freeipa.org/page/V4/OTP/Detail and
 http://www.freeipa.org/page/V4/OTP#Enabling_OTP_and_RADIUS, to determine
 if or how that might be doable.

 From what I read, an alternate approach from FreeIPA's built-in OTP might
 be to set up a stand-alone OTP solution and use radius and/or a PAM module
 to handle the VPN auth.

 I've DL'd the source, but there's so much there it'll take me some time to
 figure out what's happening.

 Any pointers on what approach I should take or where to find some notes
 and examples on how this might be accomplished would be greatly appreciated.

 Thanks,
   Kurt


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




-- 
Benjamen Keroack
*Infrastructure/DevOps Engineer*
benja...@dollarshaveclub.com
-- 
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] Common Name for the ipa-cacert-manage command

2015-04-30 Thread Benjamen Keroack
With respect, neither option is realistic in the common case. Unless I'm
mistaken, a CA-less installation will break in ~1 year when host
certificates expire and are not automatically renewed via certmonger.
Option 2 (sub-CA) is, as far as I can tell, also not feasible since no
public CA will sell subordinate CA certificates commercially. At least not
that I can find.

In our case, the only option is to resign ourselves to using self-signed
certificates for the UI. End users can import IPA CA root cert if they
choose.

On Thu, Apr 30, 2015 at 2:45 PM, Dmitri Pal d...@redhat.com wrote:

 On 04/30/2015 04:50 PM, William Graboyes wrote:

 Let me ask this a different way.

 What is the easiest method of using a trusted third party cert for the
 web UI?


 Make IPA CA-less with just certs from that 3rd party CA installed or make
 IPA trust that CA and be a sub CA.


 https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#install-ca-options



 Running IPA 4.1.0 on Centos 7.

 Thanks,
 Bill
 On 4/30/15 1:44 PM, Rob Crittenden wrote:

 William Graboyes wrote:

 Hi list,

 The end goal is to eliminate self signed certs from user interaction
 with FreeIPA, without having to roll out changes to each user in the
 house (and remote locations).  So basically changing the CA to a
 trusted CA that will not bring scare the users with Site security
 cannot be verified, return to safety.

 The problem with the CN is that when it is read from the CSR the
 CN=Certificate Authority.  Which is not an acceptable CN according
 to the tool we use for generating certs, The tool we use expects a CN
 of something along the lines of example.com.

 That sounds odd. The CN of a CA doesn't represent a machine or a
 specific domain, it represents itself. Granted Certificate Authority
 isn't all that unique a name either, but it's what we defaulted to, IIRC
 based on the dogtag defaults.

 Changing it might have other odd side-effects too as it's hardcoded in a
 few other places. I'm not exactly sure what would break, if anything.

 It sounds like your tool is issuing a server cert, not a CA cert. A
 server cert traditionally has used cn=FQDN,rest of subject. That
 doesn't really apply to a CA.

 So it's changeable if you hack some installer code, but there be dragons.

 rob

 Thanks,
 Bill

 On 4/21/15 2:55 PM, Rob Crittenden wrote:

 William Graboyes wrote:

 Hi List,

 I am having yet another issue, when I run the following command:
 ipa-cacert-manage renew --external-ca

 It does output the CSR, however the CN is not a valid name
 (Certificate Authority).  Is it possible to change the output of
 this command to use an external CA that requires a proper common
 name to be in the CSR?

 What I am trying to do is change from the internal self signed
 certs to an external CA signing system.

  What isn't valid about the name?
 This would make the IPA CA a subordinate of the external CA. Is
 that what you want?
 rob





 --
 Thank you,
 Dmitri Pal

 Director of Engineering for 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




-- 
Benjamen Keroack
*Infrastructure/DevOps Engineer*
benja...@dollarshaveclub.com
-- 
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 Web UI behind proxy

2015-04-27 Thread Benjamen Keroack
Hi Fraser,

I actually attempted that procedure (
https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP) but
it completely broke my IPA install. I could no longer log in with any users
including admin, enrollment/client auth broke, etc. Unfortunately I
couldn't find any way to roll back to the self-signed CA cert so I ended up
having to do a full re-provision and reinstall.

Needless to say, I'm a bit reticent to try that again.



On Sun, Apr 26, 2015 at 5:32 PM, Fraser Tweedale ftwee...@redhat.com
wrote:

 On Fri, Apr 24, 2015 at 11:45:23AM -0700, Benjamen Keroack wrote:
  Hi,
 
  Does anybody have any experience putting the IPA web UI behind a reverse
  proxy? In an attempt to allow our users to access the UI without browser
  warnings and without having to add the root CA certificate to their
 trusted
  store (there was some resistance to that idea), I set up an nginx server
 as
  a simple reverse proxy.
 
  Every request returns an Unable to verify your Kerberos credentials
 error
  page. The headers returned:
 
  $ http -h GET https://proxy/ipa
  HTTP/1.1 401 Unauthorized
  Accept-Ranges: bytes
  Connection: keep-alive
  Content-Length: 1474
  Content-Type: text/html; charset=UTF-8
  Date: Fri, 24 Apr 2015 18:43:06 GMT
  Last-Modified: Thu, 19 Mar 2015 18:38:36 GMT
  Server: nginx/1.4.6 (Ubuntu)
  WWW-Authenticate: Negotiate
 
  I saw this thread from 2013:
 
 https://www.redhat.com/archives/freeipa-users/2013-August/thread.html#00065
 
  I'm sending the proper Host and Referer headers by the proxy as
 specified,
  and I modified the Apache rewriting rules to not redirect to the hostname
  of the backend IPA server.
 
  Any ideas how this can be done?
 
 Hi Benjamen,

 You could use a 3rd-party certificate (signed by trusted, public CA)
 for the Web UI; see the guide:
 https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP

 If you decide to continue with the Web UI behind a reverse proxy,
 Simo recent blogged about Kerberos authentication issues with this
 sort of setup; you may find inspiration here:
 https://ssimo.org/blog/id_019.html

 Cheers,
 Fraser

  Thanks,
 
  --
  Benjamen Keroack
  *Infrastructure/DevOps Engineer*
  benja...@dollarshaveclub.com

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




-- 
Benjamen Keroack
*Infrastructure/DevOps Engineer*
benja...@dollarshaveclub.com
-- 
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] External group membership

2015-04-22 Thread Benjamen Keroack
Hi Dmitri,

I'd be happy to test sssd 1.13 alpha. Is there any easy was to install on
Ubuntu, or do I need to pull and compile from source?

Thanks,

On Fri, Apr 17, 2015 at 9:07 PM, Dmitri Pal d...@redhat.com wrote:

  On 04/17/2015 09:12 PM, Benjamen Keroack wrote:

 Hi,

  We have a number of local groups on our IPA-managed servers that we add
 LDAP/IPA users to. This works fine locally on the server on an ad hoc basis:

  $ usermod -a -G local-group test.user

  However I'm trying to do this as part of user provisioning in IPA via
 user groups. I've created external user groups in IPA, then added those
 external groups to the user groups that new users are added to via
 automember rules. For example:

  local-group [external] - [is a member of] - developers [IPA group]

  Then I SSH into one of the servers as a user who is a member of
 developers:

  test.user@qa$ groups
 test.user developers qa_users

  I do not see 'local-group' membership, even after restarting
 sssd/rebooting. Is it possible to achieve this kind of automatic local
 group membership? The only alternative I can see would be to write a SUID
 binary that .bash_profile runs on login to add them to the applicable
 groups, which seems like a bad hack.

  This is IPA 4.1.0 running on RHEL 7.1. Client servers are Ubuntu Trusty.

  Thanks for any help,

  --
   Benjamen Keroack
 *Infrastructure/DevOps Engineer*
 benja...@dollarshaveclub.com




 It looks like you are looking for this:
 https://fedorahosted.org/sssd/ticket/1591
 It is on the roadmap for 1.13 alpha which should be out in couple months.
 Would you be interested to test?

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




-- 
Benjamen Keroack
*Infrastructure/DevOps Engineer*
benja...@dollarshaveclub.com
-- 
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] External group membership

2015-04-17 Thread Benjamen Keroack
Hi,

We have a number of local groups on our IPA-managed servers that we add
LDAP/IPA users to. This works fine locally on the server on an ad hoc basis:

$ usermod -a -G local-group test.user

However I'm trying to do this as part of user provisioning in IPA via user
groups. I've created external user groups in IPA, then added those external
groups to the user groups that new users are added to via automember rules.
For example:

local-group [external] - [is a member of] - developers [IPA group]

Then I SSH into one of the servers as a user who is a member of developers:

test.user@qa$ groups
test.user developers qa_users

I do not see 'local-group' membership, even after restarting
sssd/rebooting. Is it possible to achieve this kind of automatic local
group membership? The only alternative I can see would be to write a SUID
binary that .bash_profile runs on login to add them to the applicable
groups, which seems like a bad hack.

This is IPA 4.1.0 running on RHEL 7.1. Client servers are Ubuntu Trusty.

Thanks for any help,

-- 
Benjamen Keroack
*Infrastructure/DevOps Engineer*
benja...@dollarshaveclub.com
-- 
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