Re: [Freeipa-users] FreeIPA + Foreman 1.5
On 04/24/2014 10:46 PM, Dmitri Pal wrote: On 04/23/2014 07:23 PM, Stephen Benjamin wrote: ... I am not sure it is doing the right thing. In the blog you specify bindpw for SUDO, this means you are configuring SUDO without SSSD integration. If you use IPA it is a command switch on the ipa-client-install command to enable sudo, ssh or automount integration (at least in the latest versions of IPA). I think we should focus on that. I'm very interested in this... I wrote the ipaclient module a year ago to suit a specific need for me. I have some consulting customers who use it, but I haven't had much feedback about it from anyone. Suggestions for changes to how I do things would be much appreciated. The way ipaclient is doing things works on *everything*, from a 2-year old release of RH IdM, to the 3.4 nightly I tested not too long ago. Right. So this is where instead of relying on the command switches it might make sense to run commands (if they are available). I do not recall what the commands and switches are. This is where I need help from Martin and Honza. I know there is ipa-client-automount but I do not remember the names of the similar commands for SSH, SUDO and SELinux integration. I updated FreeIPA.org Client article to hold the integration information: http://www.freeipa.org/page/Client#Integration It's used in the wild, so I can't just break the compatability there -- but, can I use SSSD setup even on the older versions of IPA? Do you have some info about how to get that working? If so, I'll gladly go to that. I need help here. Martin? I am not sure I understand the question. FreeIPA client compatibility is described on the wiki: http://www.freeipa.org/page/Client#Compatibility Are we talking about ipa-client-install options compatibility, or sssd.conf compatibility or even FreeIPA API compatibility? https://fedorahosted.org/freeipa/ticket/3740 This is just a convenient command to ipa-client-install. Separate ipa-client-automount is there since FreeIPA 3.0. https://fedorahosted.org/freeipa/ticket/3358 - but one can run command after install to enable integration with SUDO Honza, martin can you please add the details about SSH and SELinux integration Sorry I did not spot the question earlier, please see the referred article I just wrote. If there are question, ask. I haven't investigated automount, maybe it's something I can consider adding to the ipaclient puppet module. I see it more as apart of the initial client setup and check boxes: do you want SUDO integration y/n; do you want automount y/n; do you want SELinux user mapping y/n; Do you want SSH integration y/n. Once you deploy you usually do not change these things because they are dictated by general policy rather than something that you turn on and off. Right, for this we'd need to extend the freeipa_snippet, and use Foreman parameters for these options. I think it's a great idea, and something I'd gladly implement. For Foreman 1.5, we've really fixed the templates now for the release, but this is something that could probably go into 1.5.1 if the details are hammered out. Martin Honza please suggest how this can be accomplished using our commands. I would assume we can assume we are dealing with 6.4 and later, right? If talking about IPA in 6.4 and older: automount - run ipa-client-automount after ipa-client-install SUDO - configure manually (details in https://fedorahosted.org/freeipa/ticket/3358). Though I am afraid that sssd in 6.4 does not have ipa sudo provider. SSH - ready after ipa-client-install SELinux - this comes with ipa-client-install automatically, though I think it was very limited before 6.5 (https://bugzilla.redhat.com/show_bug.cgi?id=914433) I'd really appreciate an issue opened about this. Where? How do older versions of IPA respond to unknown options (say, if they don't support sudoers)? I guess I need some kind of matrix of what's supported for each version, so that I can do the appropriate things. ipa-client-install will fail if unknown option is passed. # ipa-client-install --foo Usage: ipa-client-install [options] ipa-client-install: error: no such option: --foo Yes we should pass right options to the right clients but may be we can do some kind of introspaction based on the package version. Something like: if ipa-client package version is greater than X: add options k, l, m otherwise log that options k, l, m are not supported on the version if ipa-client package version is greater than Y: add options n, o, q, p otherwise log that options n, o, q, p are not supported on the version That might be a script that is run on the system rather than a part of the template and it would check the package version available and use only applicable options. Again here I would like to hear the opinion of the list. It seems to me that all integration options are available in 6.4 (see above). The only
Re: [Freeipa-users] FreeIPA + Foreman 1.5
On 25.4.2014 09:07, Martin Kosek wrote: On 04/24/2014 10:46 PM, Dmitri Pal wrote: On 04/23/2014 07:23 PM, Stephen Benjamin wrote: ... I am not sure it is doing the right thing. In the blog you specify bindpw for SUDO, this means you are configuring SUDO without SSSD integration. If you use IPA it is a command switch on the ipa-client-install command to enable sudo, ssh or automount integration (at least in the latest versions of IPA). I think we should focus on that. I'm very interested in this... I wrote the ipaclient module a year ago to suit a specific need for me. I have some consulting customers who use it, but I haven't had much feedback about it from anyone. Suggestions for changes to how I do things would be much appreciated. The way ipaclient is doing things works on *everything*, from a 2-year old release of RH IdM, to the 3.4 nightly I tested not too long ago. Right. So this is where instead of relying on the command switches it might make sense to run commands (if they are available). I do not recall what the commands and switches are. This is where I need help from Martin and Honza. I know there is ipa-client-automount but I do not remember the names of the similar commands for SSH, SUDO and SELinux integration. I updated FreeIPA.org Client article to hold the integration information: http://www.freeipa.org/page/Client#Integration Updated the bit about SSHFP and added markup to prevent line wrapping in the middle of command and option names. It's used in the wild, so I can't just break the compatability there -- but, can I use SSSD setup even on the older versions of IPA? Do you have some info about how to get that working? If so, I'll gladly go to that. I need help here. Martin? I am not sure I understand the question. FreeIPA client compatibility is described on the wiki: http://www.freeipa.org/page/Client#Compatibility Are we talking about ipa-client-install options compatibility, or sssd.conf compatibility or even FreeIPA API compatibility? https://fedorahosted.org/freeipa/ticket/3740 This is just a convenient command to ipa-client-install. Separate ipa-client-automount is there since FreeIPA 3.0. https://fedorahosted.org/freeipa/ticket/3358 - but one can run command after install to enable integration with SUDO Honza, martin can you please add the details about SSH and SELinux integration Sorry I did not spot the question earlier, please see the referred article I just wrote. If there are question, ask. What Martin said. I haven't investigated automount, maybe it's something I can consider adding to the ipaclient puppet module. I see it more as apart of the initial client setup and check boxes: do you want SUDO integration y/n; do you want automount y/n; do you want SELinux user mapping y/n; Do you want SSH integration y/n. Once you deploy you usually do not change these things because they are dictated by general policy rather than something that you turn on and off. Right, for this we'd need to extend the freeipa_snippet, and use Foreman parameters for these options. I think it's a great idea, and something I'd gladly implement. For Foreman 1.5, we've really fixed the templates now for the release, but this is something that could probably go into 1.5.1 if the details are hammered out. Martin Honza please suggest how this can be accomplished using our commands. I would assume we can assume we are dealing with 6.4 and later, right? If talking about IPA in 6.4 and older: automount - run ipa-client-automount after ipa-client-install SUDO - configure manually (details in https://fedorahosted.org/freeipa/ticket/3358). Though I am afraid that sssd in 6.4 does not have ipa sudo provider. AFAIK you can use ldap sudo provider with IPA, see e.g. http://fedoraproject.org/wiki/QA:Testcase_freeipav3_sudo_sssd#Configure_SSSD SSH - ready after ipa-client-install SELinux - this comes with ipa-client-install automatically, though I think it was very limited before 6.5 (https://bugzilla.redhat.com/show_bug.cgi?id=914433) I'd really appreciate an issue opened about this. Where? How do older versions of IPA respond to unknown options (say, if they don't support sudoers)? I guess I need some kind of matrix of what's supported for each version, so that I can do the appropriate things. ipa-client-install will fail if unknown option is passed. # ipa-client-install --foo Usage: ipa-client-install [options] ipa-client-install: error: no such option: --foo Yes we should pass right options to the right clients but may be we can do some kind of introspaction based on the package version. Something like: if ipa-client package version is greater than X: add options k, l, m otherwise log that options k, l, m are not supported on the version if ipa-client package version is greater than Y: add options n, o, q, p otherwise log that options n, o, q, p are not supported on the version That might be a script that is run on the
Re: [Freeipa-users] services and openSSL and stuff
What are the certs for? At the moment for a third party application however we would like to issue our own certs for everything SSL such as LDAPs or OpenVPN. It is quite a powerful feature to be able to install an organisations root key on a clients machine and then be able to bosh out certs at will however I am still on an interesting journey understanding the specific implications of this for the various client, operating systems and browsers. Thanks for the certmonger keyword :) If they are for systems and services you might make you life simpler by using certmonger on the system where your service will be running. Assuming it is fedora, RHEL, CentOS and such (not sure about Debian and Ubuntu, they might have certmonger too) you install ipa-client and it will configure certmonger to use IPA. See certmonger man pages to get the certs for the services. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Free IPA and Google Apps
On 04/25/2014 01:59 AM, Chris Whittle wrote: I am wanting to use Free IPA as the authentication source for Google Apps. I can't seem to find any documentation on how to accomplish this. Anyone have any experience they would be willing to share? Or install is on CentOS 6.5 fyi. I did a brief googling and it seems to me that Google Apps should be capable of LDAP based auth/synchronization: http://www.google.com/support/enterprise/static/gapps/docs/admin/en/gads/admin/config_ldap_auth.html Even better solution would be probably to use SAML: https://developers.google.com/google-apps/sso/saml_reference_implementation by utilizing a project Ipsilon that Simo (CCed) is working on. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Hardening freeipa on the internet
On 04/25/2014 09:50 AM, Andrew Holway wrote:
Hello,
I am having a think about running freeipa on the open seas for more
distributed organisations and would like to understand where the
weaknesses might be. I would almost certainly only make the ui
unavailable however I am unsure about the other services.
Would this be a workable?
Thanks,
Andrew
That's actually a very good question. I am currently working on a public
FreeIPA demo on Red Hat OpenStack platform which I will make available in
upcoming weeks and have few pointers for you:
1) If you have DNS configured, make sure that your FreeIPA DNS does not pose as
open DNS resolver to avoid DNS amplification attacks.
Following extension to named.conf options should be a good start:
allow-transfer {none;};
allow-recursion {none;};
recursion no;
version [Secured];
rate-limit {
responses-per-second 15;
};
2) Prevention for NTP amplification attack
More info here:
https://support.steadfast.net/Knowledgebase/Article/View/106/0/preventing-ntp-amplification-attacks
Does anybody know about other precautions that should be made besides standard
hardening (SELinux, firewall, log audits)?
Thanks,
Martin
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA + Foreman 1.5
- Original Message - From: Jan Cholasta jchol...@redhat.com To: Martin Kosek mko...@redhat.com, d...@redhat.com, Stephen Benjamin stben...@redhat.com Cc: freeipa-users@redhat.com Sent: Friday, April 25, 2014 9:44:37 AM Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 AFAIK you can use ldap sudo provider with IPA, see e.g. http://fedoraproject.org/wiki/QA:Testcase_freeipav3_sudo_sssd#Configure_SSSD I got this working, and seems to work across recent Fedora releases too. This at least removes the requirement on using the old bind password method. Thanks! Is there a way for sssd to use _srv_ for the krb5_server line? Here's an updated Kickstart snippet: https://github.com/stbenjam/community-templates/blob/freeipa-fixes/snippets/freeipa_register.erb If we know what the Syntax will be for sudo (or will it be default in 4.0?), then I can include the logic already not to do it manually. - Stephen ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA + Foreman 1.5
On 04/25/2014 10:16 AM, Stephen Benjamin wrote: - Original Message - From: Jan Cholasta jchol...@redhat.com To: Martin Kosek mko...@redhat.com, d...@redhat.com, Stephen Benjamin stben...@redhat.com Cc: freeipa-users@redhat.com Sent: Friday, April 25, 2014 9:44:37 AM Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 AFAIK you can use ldap sudo provider with IPA, see e.g. http://fedoraproject.org/wiki/QA:Testcase_freeipav3_sudo_sssd#Configure_SSSD I got this working, and seems to work across recent Fedora releases too. This at least removes the requirement on using the old bind password method. Thanks! Is there a way for sssd to use _srv_ for the krb5_server line? Here's an updated Kickstart snippet: https://github.com/stbenjam/community-templates/blob/freeipa-fixes/snippets/freeipa_register.erb If we know what the Syntax will be for sudo (or will it be default in 4.0?), then I can include the logic already not to do it manually. - Stephen Good! Few comments I saw when reading the snippet: For automount, you also want to use --server option and --unattended option (your version would freeze): # ipa-client-automount --server vm-086.example.com --unattended IPA server: vm-086.example.com Location: default Configured /etc/nsswitch.conf Configured /etc/sysconfig/nfs Configured /etc/idmapd.conf Started rpcidmapd Started rpcgssd Restarting sssd, waiting for it to become available. Started autofs This is example from RHEL-6.5. As for SUDO, did you test the setup? It seems to me you missed adding sss source to sudoers database in nsswitch.conf. You would also need to set NIS domain name, otherwise SUDO will not correctly recognize SUDO rules targeted on host groups, instead of hosts: authconfig --nisdomain example.com --update nisdomainname example.com On Fedora or RHEL 7.0, you would also need to enable systemd service to make the NIS domain name setup persistent: # service rhel-domainname.service start or # service fedora-domainname.service start and # service rhel-domainname.service enable or # service fedora-domainname.service enable All these sudo client changes will come from free with FreeIPA 4.0. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Are replica gpg files reusable?
On 25.4.2014 00:15, Dave Jones wrote: Hi Rob, I was considering installing replicas using puppet. Having pre-prepared replica files available would be easier than having to run an ipa-replica-prepare and scp copy. I had guessed the ldap/kerberos replication would handle the user/password/DNS updates, and that changing CA certificates would be the most likely cause of gpg file invalidation. I'm working on DNSSEC support in FreeIPA right now. It is possible that replica-file validity will lowered by this work. (We will need to distribute one new key as part of the replica file so the replica file will become invalid if the key was changed in meantime. Maybe we will find some other solution for it, I don't know ...) Petr^2 Spacek On 24 Apr 2014, at 23:40, Rob Crittenden rcrit...@redhat.com wrote: Dave Jones wrote: Hi, Should the replica gpg created by ipa-replica-prepare be re-created when there have been trivial changes such as adding/modifying a user/group/password on the IPA server? What change of condition(s) in the ‘master’ IPA host would prevent reuse of a previously prepared replica gpg file, or otherwise render it invalid? I'm assuming there is some specific scenario you have in mind. Typically a replica file is not needed after a master is installed. The only exception is if you install without a CA and then decide to use ipa-ca-install to add it later. We generally recommend that a replica be installed fairly soon after preparation of the file, days, not months, but even then it may still be viable. As for data modification (users, groups, etc) it should have no impact whatsoever. Once a replica is installed it is a full IPA master and the 389-ds replication protocol will keep it in sync. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA + Foreman 1.5
- Original Message - From: Martin Kosek mko...@redhat.com To: Stephen Benjamin stben...@redhat.com, Jan Cholasta jchol...@redhat.com Cc: d...@redhat.com, freeipa-users@redhat.com, Tomas Babej tba...@redhat.com Sent: Friday, April 25, 2014 10:54:13 AM Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 On 04/25/2014 10:16 AM, Stephen Benjamin wrote: - Original Message - From: Jan Cholasta jchol...@redhat.com To: Martin Kosek mko...@redhat.com, d...@redhat.com, Stephen Benjamin stben...@redhat.com Cc: freeipa-users@redhat.com Sent: Friday, April 25, 2014 9:44:37 AM Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 AFAIK you can use ldap sudo provider with IPA, see e.g. http://fedoraproject.org/wiki/QA:Testcase_freeipav3_sudo_sssd#Configure_SSSD I got this working, and seems to work across recent Fedora releases too. This at least removes the requirement on using the old bind password method. Thanks! Is there a way for sssd to use _srv_ for the krb5_server line? Here's an updated Kickstart snippet: https://github.com/stbenjam/community-templates/blob/freeipa-fixes/snippets/freeipa_register.erb If we know what the Syntax will be for sudo (or will it be default in 4.0?), then I can include the logic already not to do it manually. - Stephen Good! Few comments I saw when reading the snippet: For automount, you also want to use --server option and --unattended option (your version would freeze): # ipa-client-automount --server vm-086.example.com --unattended IPA server: vm-086.example.com Location: default Configured /etc/nsswitch.conf Configured /etc/sysconfig/nfs Configured /etc/idmapd.conf Started rpcidmapd Started rpcgssd Restarting sssd, waiting for it to become available. Started autofs This is example from RHEL-6.5. As for SUDO, did you test the setup? It seems to me you missed adding sss source to sudoers database in nsswitch.conf. You would also need to set NIS domain name, otherwise SUDO will not correctly recognize SUDO rules targeted on host groups, instead of hosts: Ah right, the system I tested was already registered. Good catch, thanks. authconfig --nisdomain example.com --update nisdomainname example.com On Fedora or RHEL 7.0, you would also need to enable systemd service to make the NIS domain name setup persistent: # service rhel-domainname.service start or # service fedora-domainname.service start Wow. Why was it done that way? It makes it difficult to write cross-distro things... How will we call that on EL clones? and # service rhel-domainname.service enable or # service fedora-domainname.service enable All these sudo client changes will come from free with FreeIPA 4.0. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Free IPA and Google Apps
Thanks Martin, I found a few notes on FreeIPA and GADS but most were people saying not to do it on principal but nothing saying if it's possible or not. I like the SAML option, including the mysterious ipsilon (Is there anything more than the git repo yet?), but wonder how much control it has. Does it just allow them to SSO using their LDAP credentials? If I disable a user in LDAP does it only recognize that only during login or is it smart enough to kill their Google Apps sessions and make them login again? On Fri, Apr 25, 2014 at 3:03 AM, Martin Kosek mko...@redhat.com wrote: On 04/25/2014 01:59 AM, Chris Whittle wrote: I am wanting to use Free IPA as the authentication source for Google Apps. I can't seem to find any documentation on how to accomplish this. Anyone have any experience they would be willing to share? Or install is on CentOS 6.5 fyi. I did a brief googling and it seems to me that Google Apps should be capable of LDAP based auth/synchronization: http://www.google.com/support/enterprise/static/gapps/docs/admin/en/gads/admin/config_ldap_auth.html Even better solution would be probably to use SAML: https://developers.google.com/google-apps/sso/saml_reference_implementation by utilizing a project Ipsilon that Simo (CCed) is working on. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Free IPA and Google Apps
On Fri, 2014-04-25 at 07:27 -0500, Chris Whittle wrote: Thanks Martin, I found a few notes on FreeIPA and GADS but most were people saying not to do it on principal but nothing saying if it's possible or not. I like the SAML option, including the mysterious ipsilon (Is there anything more than the git repo yet?), but wonder how much control it has. At the moment no control at all. Does it just allow them to SSO using their LDAP credentials? Yes. If I disable a user in LDAP does it only recognize that only during login or is it smart enough to kill their Google Apps sessions and make them login again? At the moment no, in future, perhaps we can develop a plugin that will call a SSO logout to the remote applications the user logged into, but this will require the server to be more stateful. This feature is not available in the current code. Simo. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Free IPA and Google Apps
Thank you Simo! Does anyone have any more info/experience on using GADS and FreeIPA that they would be willing to share? On Fri, Apr 25, 2014 at 7:39 AM, Simo Sorce sso...@redhat.com wrote: On Fri, 2014-04-25 at 07:27 -0500, Chris Whittle wrote: Thanks Martin, I found a few notes on FreeIPA and GADS but most were people saying not to do it on principal but nothing saying if it's possible or not. I like the SAML option, including the mysterious ipsilon (Is there anything more than the git repo yet?), but wonder how much control it has. At the moment no control at all. Does it just allow them to SSO using their LDAP credentials? Yes. If I disable a user in LDAP does it only recognize that only during login or is it smart enough to kill their Google Apps sessions and make them login again? At the moment no, in future, perhaps we can develop a plugin that will call a SSO logout to the remote applications the user logged into, but this will require the server to be more stateful. This feature is not available in the current code. Simo. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA + Foreman 1.5
On 04/25/2014 07:44 AM, Martin Kosek wrote: On 04/25/2014 01:23 PM, Stephen Benjamin wrote: ... authconfig --nisdomain example.com --update nisdomainname example.com On Fedora or RHEL 7.0, you would also need to enable systemd service to make the NIS domain name setup persistent: # service rhel-domainname.service start or # service fedora-domainname.service start Wow. Why was it done that way? It makes it difficult to write cross-distro things... /me sighs. Well, I had exactly same question but I never hear an answer. How will we call that on EL clones? Umh... Maybe: systemctl start `ls /usr/lib/systemd/system/*-domainname.service | rev | cut -d'/' -f 1 | rev` ? ;-) Martin Are you planning to have a toggle for SSH integration? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Are replica gpg files reusable?
On 04/25/2014 05:06 AM, Petr Spacek wrote: On 25.4.2014 00:15, Dave Jones wrote: Hi Rob, I was considering installing replicas using puppet. Having pre-prepared replica files available would be easier than having to run an ipa-replica-prepare and scp copy. I had guessed the ldap/kerberos replication would handle the user/password/DNS updates, and that changing CA certificates would be the most likely cause of gpg file invalidation. I'm working on DNSSEC support in FreeIPA right now. It is possible that replica-file validity will lowered by this work. (We will need to distribute one new key as part of the replica file so the replica file will become invalid if the key was changed in meantime. Maybe we will find some other solution for it, I don't know ...) May be the solution is to run a cron job on the server that would prepare a replica file and refresh it under source control every so often? Petr^2 Spacek On 24 Apr 2014, at 23:40, Rob Crittenden rcrit...@redhat.com wrote: Dave Jones wrote: Hi, Should the replica gpg created by ipa-replica-prepare be re-created when there have been trivial changes such as adding/modifying a user/group/password on the IPA server? What change of condition(s) in the ‘master’ IPA host would prevent reuse of a previously prepared replica gpg file, or otherwise render it invalid? I'm assuming there is some specific scenario you have in mind. Typically a replica file is not needed after a master is installed. The only exception is if you install without a CA and then decide to use ipa-ca-install to add it later. We generally recommend that a replica be installed fairly soon after preparation of the file, days, not months, but even then it may still be viable. As for data modification (users, groups, etc) it should have no impact whatsoever. Once a replica is installed it is a full IPA master and the 389-ds replication protocol will keep it in sync. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] services and openSSL and stuff
On 04/25/2014 03:57 AM, Andrew Holway wrote: What are the certs for? At the moment for a third party application however we would like to issue our own certs for everything SSL such as LDAPs or OpenVPN. It is quite a powerful feature to be able to install an organisations root key on a clients machine and then be able to bosh out certs at will however I am still on an interesting journey understanding the specific implications of this for the various client, operating systems and browsers. Thanks for the certmonger keyword :) There are also some good docs and examples in the certmonger git repo in docs folder and here. http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/certmongerX.html Keep in mind that there are some limitations with what you want to accomplish. We are aware of it and want to address it. We just did not have a chance to get our hands on it. http://www.freeipa.org/page/V3/IPA_as_external_Puppet_CA If they are for systems and services you might make you life simpler by using certmonger on the system where your service will be running. Assuming it is fedora, RHEL, CentOS and such (not sure about Debian and Ubuntu, they might have certmonger too) you install ipa-client and it will configure certmonger to use IPA. See certmonger man pages to get the certs for the services. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA + Foreman 1.5
On 04/25/2014 09:52 AM, Stephen Benjamin wrote: - Original Message - From: Dmitri Pal d...@redhat.com To: Martin Kosek mko...@redhat.com, Stephen Benjamin stben...@redhat.com Cc: Jan Cholasta jchol...@redhat.com, freeipa-users@redhat.com, Tomas Babej tba...@redhat.com Sent: Friday, April 25, 2014 3:42:39 PM Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 Are you planning to have a toggle for SSH integration? There's freeipa_opts to pass options directly to the installer, so a user can directly pass anything they want. I can add the SSH flag if it's needed and a relatively common one... Is there anything else that should be added? I still have to give the snippet a workout to ensure it works on everything, but seems OK so far, even if it's not going to win any beauty contests. https://github.com/stbenjam/community-templates/blob/freeipa-fixes/snippets/freeipa_register.erb Yeah I was not thrilled by sed but if we can't do better for now so be it. Can Foreman have defaults? So that SSH SUDO are turned on by default but automount is not. I am not sure there is anything else for now. We might start getting into more advanced features like provisioning certs for other software components deployed on the same machine later. That however rises a question: is there a way to record in Foreman that the client system has been IPA enrolled, because if it was the software deployed on top might be able to leverage this fact and the configuration of this software would be different if the system is enrolled or not. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Free IPA and Google Apps
On 04/25/2014 09:51 AM, Simo Sorce wrote: On Fri, 2014-04-25 at 09:29 -0400, Dmitri Pal wrote: On 04/25/2014 08:39 AM, Simo Sorce wrote: On Fri, 2014-04-25 at 07:27 -0500, Chris Whittle wrote: Thanks Martin, I found a few notes on FreeIPA and GADS but most were people saying not to do it on principal but nothing saying if it's possible or not. I like the SAML option, including the mysterious ipsilon (Is there anything more than the git repo yet?), but wonder how much control it has. At the moment no control at all. Does it just allow them to SSO using their LDAP credentials? Yes. If I disable a user in LDAP does it only recognize that only during login or is it smart enough to kill their Google Apps sessions and make them login again? At the moment no, in future, perhaps we can develop a plugin that will call a SSO logout to the remote applications the user logged into, but this will require the server to be more stateful. This feature is not available in the current code. Simo. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users Simo, how much Ipsilon is ready for a POC like this? I understand it is probably somewhere between alpha and beta quality but it might be a good exercise to try to set it up for a real use case. What do you think? It can be tried, but I need to write some documentation on how to set it up first :-) Simo. Hint-hint, nudge-nudge :-) -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Free IPA and Google Apps
On Fri, 2014-04-25 at 10:00 -0400, Dmitri Pal wrote: On 04/25/2014 09:51 AM, Simo Sorce wrote: On Fri, 2014-04-25 at 09:29 -0400, Dmitri Pal wrote: On 04/25/2014 08:39 AM, Simo Sorce wrote: On Fri, 2014-04-25 at 07:27 -0500, Chris Whittle wrote: Thanks Martin, I found a few notes on FreeIPA and GADS but most were people saying not to do it on principal but nothing saying if it's possible or not. I like the SAML option, including the mysterious ipsilon (Is there anything more than the git repo yet?), but wonder how much control it has. At the moment no control at all. Does it just allow them to SSO using their LDAP credentials? Yes. If I disable a user in LDAP does it only recognize that only during login or is it smart enough to kill their Google Apps sessions and make them login again? At the moment no, in future, perhaps we can develop a plugin that will call a SSO logout to the remote applications the user logged into, but this will require the server to be more stateful. This feature is not available in the current code. Simo. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users Simo, how much Ipsilon is ready for a POC like this? I understand it is probably somewhere between alpha and beta quality but it might be a good exercise to try to set it up for a real use case. What do you think? It can be tried, but I need to write some documentation on how to set it up first :-) Simo. Hint-hint, nudge-nudge :-) I know, I know. I got done with lasso and mod_auth_mellon patches, now I can go back to Ipsilon. If Jan gives me the go, I will cut a first release and start writing instruction, file for Fedora packages and all that Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Are replica gpg files reusable?
Dmitri Pal wrote: On 04/25/2014 05:06 AM, Petr Spacek wrote: On 25.4.2014 00:15, Dave Jones wrote: Hi Rob, I was considering installing replicas using puppet. Having pre-prepared replica files available would be easier than having to run an ipa-replica-prepare and scp copy. I had guessed the ldap/kerberos replication would handle the user/password/DNS updates, and that changing CA certificates would be the most likely cause of gpg file invalidation. I'm working on DNSSEC support in FreeIPA right now. It is possible that replica-file validity will lowered by this work. (We will need to distribute one new key as part of the replica file so the replica file will become invalid if the key was changed in meantime. Maybe we will find some other solution for it, I don't know ...) May be the solution is to run a cron job on the server that would prepare a replica file and refresh it under source control every so often? The downside is you could end up issuing a whole ton of certificates for the same service, the majority of which aren't being used, and are unrevoked. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA + Foreman 1.5
- Original Message - From: Dmitri Pal d...@redhat.com To: Stephen Benjamin stben...@redhat.com Cc: Martin Kosek mko...@redhat.com, Jan Cholasta jchol...@redhat.com, freeipa-users@redhat.com, Tomas Babej tba...@redhat.com Sent: Friday, April 25, 2014 3:59:31 PM Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 On 04/25/2014 09:52 AM, Stephen Benjamin wrote: - Original Message - From: Dmitri Pal d...@redhat.com To: Martin Kosek mko...@redhat.com, Stephen Benjamin stben...@redhat.com Cc: Jan Cholasta jchol...@redhat.com, freeipa-users@redhat.com, Tomas Babej tba...@redhat.com Sent: Friday, April 25, 2014 3:42:39 PM Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 Are you planning to have a toggle for SSH integration? There's freeipa_opts to pass options directly to the installer, so a user can directly pass anything they want. I can add the SSH flag if it's needed and a relatively common one... Is there anything else that should be added? I still have to give the snippet a workout to ensure it works on everything, but seems OK so far, even if it's not going to win any beauty contests. https://github.com/stbenjam/community-templates/blob/freeipa-fixes/snippets/freeipa_register.erb Yeah I was not thrilled by sed but if we can't do better for now so be it. Can Foreman have defaults? So that SSH SUDO are turned on by default but automount is not. I am not sure there is anything else for now. Yup, defaults are as you described. SSH integration can't currently be turned off but I'll add the flag. We might start getting into more advanced features like provisioning certs for other software components deployed on the same machine later. That however rises a question: is there a way to record in Foreman that the client system has been IPA enrolled, because if it was the software deployed on top might be able to leverage this fact and the configuration of this software would be different if the system is enrolled or not. Foreman keeps track of which hosts are registered, so this information is available for use. Certificates could even be managed in Foreman via a puppet module (there's one out there for Certmonger, IIRC). -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA + Foreman 1.5
On 04/25/2014 10:29 AM, Stephen Benjamin wrote: - Original Message - From: Dmitri Pal d...@redhat.com To: Stephen Benjamin stben...@redhat.com Cc: Martin Kosek mko...@redhat.com, Jan Cholasta jchol...@redhat.com, freeipa-users@redhat.com, Tomas Babej tba...@redhat.com Sent: Friday, April 25, 2014 3:59:31 PM Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 On 04/25/2014 09:52 AM, Stephen Benjamin wrote: - Original Message - From: Dmitri Pal d...@redhat.com To: Martin Kosek mko...@redhat.com, Stephen Benjamin stben...@redhat.com Cc: Jan Cholasta jchol...@redhat.com, freeipa-users@redhat.com, Tomas Babej tba...@redhat.com Sent: Friday, April 25, 2014 3:42:39 PM Subject: Re: [Freeipa-users] FreeIPA + Foreman 1.5 Are you planning to have a toggle for SSH integration? There's freeipa_opts to pass options directly to the installer, so a user can directly pass anything they want. I can add the SSH flag if it's needed and a relatively common one... Is there anything else that should be added? I still have to give the snippet a workout to ensure it works on everything, but seems OK so far, even if it's not going to win any beauty contests. https://github.com/stbenjam/community-templates/blob/freeipa-fixes/snippets/freeipa_register.erb Yeah I was not thrilled by sed but if we can't do better for now so be it. Can Foreman have defaults? So that SSH SUDO are turned on by default but automount is not. I am not sure there is anything else for now. Yup, defaults are as you described. SSH integration can't currently be turned off but I'll add the flag. We might start getting into more advanced features like provisioning certs for other software components deployed on the same machine later. That however rises a question: is there a way to record in Foreman that the client system has been IPA enrolled, because if it was the software deployed on top might be able to leverage this fact and the configuration of this software would be different if the system is enrolled or not. Foreman keeps track of which hosts are registered, so this information is available for use. Certificates could even be managed in Foreman via a puppet module (there's one out there for Certmonger, IIRC). Yes. This is the direction of the further expansion. Let us get back to it in couple months. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Are replica gpg files reusable?
This type of behavior is generally beyond what Puppet should do because it involves two systems retrieving information directly from one another and the puppet master can't reasonably serve as the repository of that information. Using a separate tool will likely work better. There's at least two ways that you could go with this. 1) Script and SSH The IPA master has a simple script that will just invoke ipa-replica-setup with the proper options and passwords. The new replica will get a Puppet exec resource that will SSH into the master, run the script, scp the resulting replica file, and invoke the replica install with that info. The problem with this solution is that credentials are sprinkled all over the place, and security is not good. Your Puppet manifest will need SSH credentials/keys, the master script needs IPA credentials, and the Puppet logs for the exec resource may contain passwords depending on how you implement it. 2) MCollective You'll need to write a MCollective agent that resides on the replica and master. The new replica will get a Puppet exec resource that will run the MCollective agent. The agent will connect to the master and invoke its half of the agent, which will create the replica file and read it back to the replica. Then, there's a second Puppet exec resource that will run ipa-replica-install. Security is better for a couple of reasons. First, ACLs can be used with MCollective to limit who can run this agent. Second, there's no SSH keys/passwords to exchange. Third, we can store the IPA DM and admin passwords in puppet facts (this works for the previous solution, too.). Both solutions are pretty simple and will get the job done, but I think the second one is better but does require MCollective installed and Ruby knowledge. On Fri, Apr 25, 2014 at 9:18 AM, Rob Crittenden rcrit...@redhat.com wrote: Dmitri Pal wrote: On 04/25/2014 05:06 AM, Petr Spacek wrote: On 25.4.2014 00:15, Dave Jones wrote: Hi Rob, I was considering installing replicas using puppet. Having pre-prepared replica files available would be easier than having to run an ipa-replica-prepare and scp copy. I had guessed the ldap/kerberos replication would handle the user/password/DNS updates, and that changing CA certificates would be the most likely cause of gpg file invalidation. I'm working on DNSSEC support in FreeIPA right now. It is possible that replica-file validity will lowered by this work. (We will need to distribute one new key as part of the replica file so the replica file will become invalid if the key was changed in meantime. Maybe we will find some other solution for it, I don't know ...) May be the solution is to run a cron job on the server that would prepare a replica file and refresh it under source control every so often? The downside is you could end up issuing a whole ton of certificates for the same service, the majority of which aren't being used, and are unrevoked. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Are replica gpg files reusable?
On 04/25/2014 12:48 PM, Justin Brown wrote: This type of behavior is generally beyond what Puppet should do because it involves two systems retrieving information directly from one another and the puppet master can't reasonably serve as the repository of that information. Using a separate tool will likely work better. There's at least two ways that you could go with this. 1) Script and SSH The IPA master has a simple script that will just invoke ipa-replica-setup with the proper options and passwords. The new replica will get a Puppet exec resource that will SSH into the master, run the script, scp the resulting replica file, and invoke the replica install with that info. The problem with this solution is that credentials are sprinkled all over the place, and security is not good. Your Puppet manifest will need SSH credentials/keys, the master script needs IPA credentials, and the Puppet logs for the exec resource may contain passwords depending on how you implement it. 2) MCollective You'll need to write a MCollective agent that resides on the replica and master. The new replica will get a Puppet exec resource that will run the MCollective agent. The agent will connect to the master and invoke its half of the agent, which will create the replica file and read it back to the replica. Then, there's a second Puppet exec resource that will run ipa-replica-install. Security is better for a couple of reasons. First, ACLs can be used with MCollective to limit who can run this agent. Second, there's no SSH keys/passwords to exchange. Third, we can store the IPA DM and admin passwords in puppet facts (this works for the previous solution, too.). Both solutions are pretty simple and will get the job done, but I think the second one is better but does require MCollective installed and Ruby knowledge. Or we use Cockpit for that matter: http://sgallagh.wordpress.com/2013/12/09/proposal-freeipa-role-for-fedora-servers/ On Fri, Apr 25, 2014 at 9:18 AM, Rob Crittenden rcrit...@redhat.com wrote: Dmitri Pal wrote: On 04/25/2014 05:06 AM, Petr Spacek wrote: On 25.4.2014 00:15, Dave Jones wrote: Hi Rob, I was considering installing replicas using puppet. Having pre-prepared replica files available would be easier than having to run an ipa-replica-prepare and scp copy. I had guessed the ldap/kerberos replication would handle the user/password/DNS updates, and that changing CA certificates would be the most likely cause of gpg file invalidation. I'm working on DNSSEC support in FreeIPA right now. It is possible that replica-file validity will lowered by this work. (We will need to distribute one new key as part of the replica file so the replica file will become invalid if the key was changed in meantime. Maybe we will find some other solution for it, I don't know ...) May be the solution is to run a cron job on the server that would prepare a replica file and refresh it under source control every so often? The downside is you could end up issuing a whole ton of certificates for the same service, the majority of which aren't being used, and are unrevoked. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Are replica gpg files reusable?
Justin Brown wrote: This type of behavior is generally beyond what Puppet should do because it involves two systems retrieving information directly from one another and the puppet master can't reasonably serve as the repository of that information. Using a separate tool will likely work better. There's at least two ways that you could go with this. 1) Script and SSH The IPA master has a simple script that will just invoke ipa-replica-setup with the proper options and passwords. The new replica will get a Puppet exec resource that will SSH into the master, run the script, scp the resulting replica file, and invoke the replica install with that info. The problem with this solution is that credentials are sprinkled all over the place, and security is not good. Your Puppet manifest will need SSH credentials/keys, the master script needs IPA credentials, and the Puppet logs for the exec resource may contain passwords depending on how you implement it. 2) MCollective You'll need to write a MCollective agent that resides on the replica and master. The new replica will get a Puppet exec resource that will run the MCollective agent. The agent will connect to the master and invoke its half of the agent, which will create the replica file and read it back to the replica. Then, there's a second Puppet exec resource that will run ipa-replica-install. Security is better for a couple of reasons. First, ACLs can be used with MCollective to limit who can run this agent. Second, there's no SSH keys/passwords to exchange. Third, we can store the IPA DM and admin passwords in puppet facts (this works for the previous solution, too.). Both solutions are pretty simple and will get the job done, but I think the second one is better but does require MCollective installed and Ruby knowledge. Would that mean that anyone with shell access to the box could run facter and get the passwords? I guess one would need a well-defined HBAC rule to limit access. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
