[Freeipa-users] External group membership
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
Re: [Freeipa-users] External group membership
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 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] IPA Web UI behind proxy
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? 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
Re: [Freeipa-users] IPA Web UI behind proxy
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 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] Common Name for the ipa-cacert-manage command
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 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,. 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] OTP vs VPN
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 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
