Re: [Freeipa-devel] [PATCH][RFC] 7 automember rebuild nowait feature added
On 03/27/2014 03:37 PM, Misnyovszki Adam wrote: On Wed, 26 Mar 2014 13:15:55 +0100 Petr Viktorin pvikt...@redhat.com wrote: [...] Looks great! I'm just concerned about the error returned when the task takes too long: $ ipa automember-rebuild --type group ipa: ERROR: LDAP timeout I don't think it's sufficiently clear from this that waiting for the task timed out, but the task was actually started successfully. A custom error with a more descriptive message would be useful. Also I've noticed that the nstaskstatus of a successful task is: Automember rebuild task finished. Processed (1) entries. This looks helpful; we could return it as the summary. Hi, both fixed. Greets Adam Sorry for the delay! 'Automember' is a translatable string, so please wrap it in _() when raising TaskTimeout. Also please update the tests. Otherwise with a little rebase it's good to go. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Random Certificate Serial Numbers
Hi Rob, Ade and others, In the past, Rob was investigating enabling random certificate serial numbers for FreeIPA PKI [1]. We also have a ticket [2] planned to enable it for 4.0. Can we simply switch it on for PKI with pkispawn attribute: [CA] pki_random_serial_numbers_enable=True or is there any drawback or risk we should investigate. I am just thinking, does PKI handle collisions anyhow? When for example two PKI masters generate 2 certificates of the same serial (unlikely though it could happen)? Currently, we assign different slice of serial range to different PKI masters, do we want to do that also for random serial? Thanks for info [1] http://dogtagpki.org/wiki/Random_Certificate_Serial_Numbers [2] https://fedorahosted.org/freeipa/ticket/2016 -- Martin Kosek mko...@redhat.com Supervisor, Software Engineering - Identity Management Team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0113] ipa-client: Set NIS domain name in the installer
On 03/03/2014 08:16 PM, Tomas Babej wrote: The updated patch addresses all the mentioned issues. Also enables systemd's specific domainname service instead of relying ypbind being present on the system. Please note that nisdomainname is not configured on boot time at the moment. The following bug is the cause: https://bugzilla.redhat.com/show_bug.cgi?id=1071951 On 11/14/2013 12:54 PM, Ana Krivokapic wrote: On 09/26/2013 10:28 AM, Tomas Babej wrote: +if options.no_nisdomain and not options.nisdomain: This should be `if options.no_nisdomain and options.nisdomain:`. +parser.error(--no-nisdomain cannot be used together with --nisdomain) Shouldn't we also revert the nisdomain authconfig setting on client uninstall? This set the NIS domain correctly after the restart. However, it did not set it *before* the restart. Thus, after I installed IPA server/client, NIS domain was not set and thus SUDO would not work. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] global account lockout
Hi, please review the following feature design. It introduces a global account lockout, while trying to keep the replication traffic minimal. In my opinion for a real global account lockout the basic lockout attributes have to be replicated otherwise the benefit is minimal: an attacker could perform (maxFailedcount -1) login attempts on every server before the global lockout is set. But the design page describes how it could be done if it should be implemented - maybe the side effect that accounts could the be unlocked on any replica has its own benefit. http://www.freeipa.org/page/V4/Replicated_lockout ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0505 Default read ACIs for HBAC objects
On 04/03/2014 12:09 PM, Petr Viktorin wrote: Hello, This adds read permissions to read HBAC rules, services, and service groups. Read access is given to all authenticated users. So far looked OK in my tests. What about the ACIs like the following one? (targetattr = *)(version 3.0; acl No anonymous access to hbac; deny (read,search,compare) userdn != ldap:///all;;) Do we want to remove them together with this patch to have the change grouped together with allow ACIs or do you plan to remove all similar deny ACIs at once? (together with the master read ACI) Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0505 Default read ACIs for HBAC objects
On 04/07/2014 01:28 PM, Martin Kosek wrote: On 04/03/2014 12:09 PM, Petr Viktorin wrote: Hello, This adds read permissions to read HBAC rules, services, and service groups. Read access is given to all authenticated users. So far looked OK in my tests. What about the ACIs like the following one? (targetattr = *)(version 3.0; acl No anonymous access to hbac; deny (read,search,compare) userdn != ldap:///all;;) Do we want to remove them together with this patch to have the change grouped together with allow ACIs or do you plan to remove all similar deny ACIs at once? (together with the master read ACI) Martin I want to remove them after removing the global read ACI, so that in the mean time we're not allowing more access than we should. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0504 Default read ACIs for Sudo objects
On 04/03/2014 12:09 PM, Petr Viktorin wrote: Hello, This adds read permissions to read Sudo commands, command groups, rules. Read access is given to all authenticated users. Looks good. What about ou=sudoers? I think we should also allow it in this patch for authenticated users. This is the tree that clients use to read sudo. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Ipa-server-install Firewall Support
Simo Sorce wrote:
On Fri, 2014-04-04 at 09:59 +0200, Petr Spacek wrote:
On 4.4.2014 09:17, Martin Kosek wrote:
On 04/04/2014 09:04 AM, Justin Brown wrote:
I would actually do it the opposite way and open the ports after the FreeIPA
server is fully configured. After all, I do not think we want to open the ports
when the server is just half-configured and for example some ACIs are missing.
My thinking was that nothing would be listening on these ports if the
install doesn't succeed, but there's really necessity to modify the
firewall configuration early. (All of the internal install
communication will be over a local interface (to netfilter) and
unblock anyways. I don't have any problem in delaying firewall
configuration to the end of install.
If ipa-server-install does succeed without configuring the firewalld, then we
will indeed have no other option than to do it early.
I am thinking that we may want to put all the firewalld configuration in
ipaserver/install/firewalldinstance.py,
and then make the firewalld configuration the actual step of the installation.
Something like:
...
Configuring Firewall (firewalld)
[1/2]: looking up the right zone
[2/2]: allowing ports
Done configuring Firewall (firewalld).
...
The Service class derived object can be really simple, we would just reuse the
functionality it already has + let us properly hook into it in
ipa-{server,replica}-install and the uninstallation.
It would also make it easier to split this functionality to
freeipa-server-firewalld if we chose to in a future.
In general I agree with the idea, thank you Justin for working on that!
I would like to emphasis the necessity to work without NetworkManager and
FirewallD. New dependencies make Debian folks unhappy ...
On the other hand, it is perfectly fine to skip firewall configuration if
NM/FirewallD/DBus is not available.
Have a nice day!
Should be easy, probe for the dbus firewalld service and just skip (not
error out) if it is not there.
Set a variable in that case that will cause the installer to throw the
classic banner we have now which warns you about what ports need to be
opened at the end of the install.
Probably just need to spit out a large, preferably flashing warning that
the firewall has not been automatically configured. Perhaps even
multiple times: one in-line and one at the install summary at the end.
rob
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] questions regarding ldap schema for pkcs11
Simo Sorce wrote: On Fri, 2014-04-04 at 13:19 +0200, Petr Spacek wrote: On 4.4.2014 10:20, Ludwig Krispenz wrote: In the review discussion for the ldap schema for pkcs11 there was one topic, which we wanted to get the opinion from a broader audience before making a final decision. I'll add my opinion for the record: In pkcs11 there are many boolean attributes, like CKA_EXTRACTABLE, CKA_DERIVE, CKA_VERIFY and there are two suggestions how to represent them in ldap. 1] one ldap attribute for each pkcs11 attribute. This was my initial proposal to define a ldap attribute with boolean syntax. Most attributes have default values and need not to be present example: pkcs11extractable: true pkcs11derive: false pkcs11verify: true 2] one ldap attribute with pkcs11 attributes as values During the review Simo suggested to have a single attribute (or a few of them, key,cert,...) and for each pkcs11 attribute with value true add it as a value example: pkcs11keyFlags: CKA_EXTRACTABLE pkcs11keyFlags: CKA_VERIFY Pros Cons pro 1] : one ldap attribute for each pkcs11 attribute. * direct mapping of pkcs11attributes * required or allowed attributes are defined in an objectclass con 1]: * huge number of schema attributes, which will probably not be needed I don't think it is a problem. We have *huge* schema full of almost never-used attributes. Look at printerAbstract objectClass ... pro 2]: one ldap attribute with pkcs11 attributes as values * smaller schema definition IPA schema + all the RFCs created a huge pile of schema definitions already and 389 can cope with it. (We are speaking about adding tens of attributes, not hundreds or thousands!) * possible to add new attributes/flags without extending the schema Schema change is a little problem in comparison with updating clients (to get any value from the new flag). Note that we are talking about booleans defined by PKCS#11 standard so we can't add any boolean anyway. IMHO any IPA-specific booleans should go to a separate object class to separate them from pure PKCS#11 schema. con 2]: * no input validation, application could set undefined flags * since presence of a flag means TRUE, and absence FALSE all default true values need to be present To conclude it - I like approach [1]: One ldap attribute for each pkcs11 attribute. After much consideration I think one attribute per boolean is ok, I think the most convincing argument came from Honza when he said sometimes the default may depend on additional factors not explicit in the object, in that case setting or not setting a string would always be wrong and we would need to end up with additional definitions like: CKA_VERIFY_TRUE/CKA_VERIFY_FALSE as opposed to them missing which could indicate default (or we end up adding also CKA_VERIFY_DEFAULT ...). I prefer the one-per-boolean as well and for the same reason: it doesn't require magic values defined elsewhere. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0002] Use job prefix in install-built-rpms
Hi,
this patch fixes the issue with using freeipa specific rpms when
defining custom jobs.
Tomas
--
Tomas Babej
Associate Software Engineer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org
From fa75dd96908346d354c40fb6587fdf9b7b11870d Mon Sep 17 00:00:00 2001
From: Tomas Babej tomasba...@gmail.com
Date: Mon, 7 Apr 2014 15:56:10 +0200
Subject: [PATCH] Use job prefix in install-built-rpms
---
jenkins-job-builder/freeipa-jobs.yaml | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/jenkins-job-builder/freeipa-jobs.yaml b/jenkins-job-builder/freeipa-jobs.yaml
index 981c3f7cf8d5127bf7db2f3eef6e63299b5d0572..cb35aa7bee001637324da5fae4ad360a4a5c7b76 100644
--- a/jenkins-job-builder/freeipa-jobs.yaml
+++ b/jenkins-job-builder/freeipa-jobs.yaml
@@ -64,7 +64,7 @@
name: install-built-rpms
builders:
- copyartifact:
-project: freeipa-build-{os}
+project: {prefix}-build-{os}
which-build: upstream-build
fallback-to-last-successful: true
- shell: sudo yum remove -y 'freeipa-*' || :
@@ -196,6 +196,7 @@
- workspace-cleanup
builders:
- install-built-rpms:
+prefix: {prefix}
os: {os}
- shell: sudo yum check-update
- shell: rpm -qa | sort
@@ -237,6 +238,7 @@
builders:
- clean-up-environment
- install-built-rpms:
+prefix: {prefix}
os: {os}
- shell: |
# We're running in-tree tests, but we get compiled files from RPMs
@@ -276,6 +278,7 @@
builders:
- clean-up-environment
- install-built-rpms:
+prefix: {prefix}
os: {os}
- install:
options-dns-setup: {options-dns-setup}
@@ -303,6 +306,7 @@
builders:
- clean-up-environment
- install-built-rpms:
+prefix: {prefix}
os: {os}
- download-certificate
- install:
@@ -336,6 +340,7 @@
builders:
- clean-up-environment
- install-built-rpms:
+prefix: {prefix}
os: {os}
- shell: |
sudo yum install -y PyYAML python-requests python-paramiko
--
1.8.5.3
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0002] Use job prefix in install-built-rpms
On 04/07/2014 04:08 PM, Tomas Babej wrote: Hi, this patch fixes the issue with using freeipa specific rpms when defining custom jobs. Tomas Thanks! Pushed to https://github.com/encukou/freeipa-ci.git as 01778989306e19e53b98d4acc72772631a8bb9dd -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0507 Allow anonymous read access to containers
On 04/03/2014 01:34 PM, Petr Viktorin wrote: Hello, This adds anonymous read access to containers, as discussed in this thread: https://www.redhat.com/archives/freeipa-devel/2014-March/msg00442.html Additionally access is granted for $SUFFIX itself with targetfilter (objectclass=domain), and attributes objectclass, dc, info, nisDomain, associatedDomain. These are raw ACIs, not permission-based ones. Starting a new sub-thread to differential from the LDIF/update file fixes. I tested the new ACI and it worked ok for me (is a prerequisite for easy testing of the subsequent ACI patches). I assume you plan to handle cn=etc tree in other patch. ACK from me in that case (not pushing right now to let Simo raise any concerns he may have). Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0507 Allow anonymous read access to containers
On Mon, 2014-04-07 at 16:43 +0200, Martin Kosek wrote: On 04/03/2014 01:34 PM, Petr Viktorin wrote: Hello, This adds anonymous read access to containers, as discussed in this thread: https://www.redhat.com/archives/freeipa-devel/2014-March/msg00442.html Additionally access is granted for $SUFFIX itself with targetfilter (objectclass=domain), and attributes objectclass, dc, info, nisDomain, associatedDomain. These are raw ACIs, not permission-based ones. Starting a new sub-thread to differential from the LDIF/update file fixes. I tested the new ACI and it worked ok for me (is a prerequisite for easy testing of the subsequent ACI patches). I assume you plan to handle cn=etc tree in other patch. ACK from me in that case (not pushing right now to let Simo raise any concerns he may have). Martin I do not have any concern on the ACI itself, I only mused about ldif +update vs update only, sorry if I gave the worng impression. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] global account lockout
Ludwig Krispenz wrote: Hi, please review the following feature design. It introduces a global account lockout, while trying to keep the replication traffic minimal. In my opinion for a real global account lockout the basic lockout attributes have to be replicated otherwise the benefit is minimal: an attacker could perform (maxFailedcount -1) login attempts on every server before the global lockout is set. But the design page describes how it could be done if it should be implemented - maybe the side effect that accounts could the be unlocked on any replica has its own benefit. http://www.freeipa.org/page/V4/Replicated_lockout One weakness with this is there is still a window for extra password attempts if one is clever, (m * (f-1))+1 to be exact, where m is the number of masters and f is the # of allowed failed logins. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] global account lockout
On Mon, 2014-04-07 at 11:26 -0400, Rob Crittenden wrote: Ludwig Krispenz wrote: Hi, please review the following feature design. It introduces a global account lockout, while trying to keep the replication traffic minimal. In my opinion for a real global account lockout the basic lockout attributes have to be replicated otherwise the benefit is minimal: an attacker could perform (maxFailedcount -1) login attempts on every server before the global lockout is set. But the design page describes how it could be done if it should be implemented - maybe the side effect that accounts could the be unlocked on any replica has its own benefit. http://www.freeipa.org/page/V4/Replicated_lockout One weakness with this is there is still a window for extra password attempts if one is clever, (m * (f-1))+1 to be exact, where m is the number of masters and f is the # of allowed failed logins. Yes, but that is a problem that cannot be solved w/o full replication at every authentication attempt. What we tried to achieve is a middle ground to at least ease administration and still lock em up earlier. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] global account lockout
On Mon, 2014-04-07 at 12:01 -0400, Simo Sorce wrote: On Mon, 2014-04-07 at 11:26 -0400, Rob Crittenden wrote: Ludwig Krispenz wrote: Hi, please review the following feature design. It introduces a global account lockout, while trying to keep the replication traffic minimal. In my opinion for a real global account lockout the basic lockout attributes have to be replicated otherwise the benefit is minimal: an attacker could perform (maxFailedcount -1) login attempts on every server before the global lockout is set. But the design page describes how it could be done if it should be implemented - maybe the side effect that accounts could the be unlocked on any replica has its own benefit. http://www.freeipa.org/page/V4/Replicated_lockout One weakness with this is there is still a window for extra password attempts if one is clever, (m * (f-1))+1 to be exact, where m is the number of masters and f is the # of allowed failed logins. Yes, but that is a problem that cannot be solved w/o full replication at every authentication attempt. What we tried to achieve is a middle ground to at least ease administration and still lock em up earlier. Let me add that we could have yet another closer step by finding a way to replicate only failed attempts and not successful attempts in some case. Assuming a setup where most people do not fail to enter their password it would make for a decent compromise. That could be achieved by not storing lastsuccessful auth except when that is needed to clear failed logon attempts (ie when the failed logon counter is 0) If we did that then we would not need a new attribute actually, as failed logins would always be replicated. However it would mean that last Successful auth would never be accurate on any server. Or perhaps we could have a local last successful auth and a global one by adding one new attribute, and keeping masking only the successful auth. The main issue about all these possibilities is how do we present them ? And how do we make a good default ? I think a good default is defined by these 2 characteristics: 1. lockouts can be dealt with on any replica w/o having the admin hunt down where a user is locked. 2. at least successful authentications will not cause replication storms If we can afford to cause replications on failed authentication by default, then we could open up replication for failedauth and failedcount attributes but still bar the successful auth attribute. Unlock would simply consist in forcibly setting failed count to 0 (which is replicated so it would unlock all servers). This would work w/o introducing new attributes and only with minimal logic changes in the KDC/pwd-extop plugins I think. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] global account lockout
On Mon, 2014-04-07 at 12:10 -0400, Simo Sorce wrote: On Mon, 2014-04-07 at 12:01 -0400, Simo Sorce wrote: On Mon, 2014-04-07 at 11:26 -0400, Rob Crittenden wrote: Ludwig Krispenz wrote: Hi, please review the following feature design. It introduces a global account lockout, while trying to keep the replication traffic minimal. In my opinion for a real global account lockout the basic lockout attributes have to be replicated otherwise the benefit is minimal: an attacker could perform (maxFailedcount -1) login attempts on every server before the global lockout is set. But the design page describes how it could be done if it should be implemented - maybe the side effect that accounts could the be unlocked on any replica has its own benefit. http://www.freeipa.org/page/V4/Replicated_lockout One weakness with this is there is still a window for extra password attempts if one is clever, (m * (f-1))+1 to be exact, where m is the number of masters and f is the # of allowed failed logins. Yes, but that is a problem that cannot be solved w/o full replication at every authentication attempt. What we tried to achieve is a middle ground to at least ease administration and still lock em up earlier. Let me add that we could have yet another closer step by finding a way to replicate only failed attempts and not successful attempts in some case. Assuming a setup where most people do not fail to enter their password it would make for a decent compromise. That could be achieved by not storing lastsuccessful auth except when that is needed to clear failed logon attempts (ie when the failed logon counter is 0) If we did that then we would not need a new attribute actually, as failed logins would always be replicated. However it would mean that last Successful auth would never be accurate on any server. Or perhaps we could have a local last successful auth and a global one by adding one new attribute, and keeping masking only the successful auth. The main issue about all these possibilities is how do we present them ? And how do we make a good default ? I think a good default is defined by these 2 characteristics: 1. lockouts can be dealt with on any replica w/o having the admin hunt down where a user is locked. 2. at least successful authentications will not cause replication storms If we can afford to cause replications on failed authentication by default, then we could open up replication for failedauth and failedcount attributes but still bar the successful auth attribute. Unlock would simply consist in forcibly setting failed count to 0 (which is replicated so it would unlock all servers). This would work w/o introducing new attributes and only with minimal logic changes in the KDC/pwd-extop plugins I think. Sigh re[plying again to myself. note that the main issue with replicating failed accounts is that you can cause replication storms by simply probing all user accounts with failed binds or AS requests. In some environments that may cause DoSs (if you have slow/high latency links on which replication runs for example). So I think we should always give the option to turn off failed date/count attributes replication, which in turn would mean we still require a new attribute to replicate for when a user is finally locked out on one of the servers or we fail requirement 1. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] global account lockout
On 04/07/2014 10:13 AM, Simo Sorce wrote: On Mon, 2014-04-07 at 12:10 -0400, Simo Sorce wrote: On Mon, 2014-04-07 at 12:01 -0400, Simo Sorce wrote: On Mon, 2014-04-07 at 11:26 -0400, Rob Crittenden wrote: Ludwig Krispenz wrote: Hi, please review the following feature design. It introduces a global account lockout, while trying to keep the replication traffic minimal. In my opinion for a real global account lockout the basic lockout attributes have to be replicated otherwise the benefit is minimal: an attacker could perform (maxFailedcount -1) login attempts on every server before the global lockout is set. But the design page describes how it could be done if it should be implemented - maybe the side effect that accounts could the be unlocked on any replica has its own benefit. http://www.freeipa.org/page/V4/Replicated_lockout One weakness with this is there is still a window for extra password attempts if one is clever, (m * (f-1))+1 to be exact, where m is the number of masters and f is the # of allowed failed logins. Yes, but that is a problem that cannot be solved w/o full replication at every authentication attempt. What we tried to achieve is a middle ground to at least ease administration and still lock em up earlier. Let me add that we could have yet another closer step by finding a way to replicate only failed attempts and not successful attempts in some case. Assuming a setup where most people do not fail to enter their password it would make for a decent compromise. That could be achieved by not storing lastsuccessful auth except when that is needed to clear failed logon attempts (ie when the failed logon counter is 0) If we did that then we would not need a new attribute actually, as failed logins would always be replicated. However it would mean that last Successful auth would never be accurate on any server. Or perhaps we could have a local last successful auth and a global one by adding one new attribute, and keeping masking only the successful auth. The main issue about all these possibilities is how do we present them ? And how do we make a good default ? I think a good default is defined by these 2 characteristics: 1. lockouts can be dealt with on any replica w/o having the admin hunt down where a user is locked. 2. at least successful authentications will not cause replication storms If we can afford to cause replications on failed authentication by default, then we could open up replication for failedauth and failedcount attributes but still bar the successful auth attribute. Unlock would simply consist in forcibly setting failed count to 0 (which is replicated so it would unlock all servers). This would work w/o introducing new attributes and only with minimal logic changes in the KDC/pwd-extop plugins I think. Sigh re[plying again to myself. note that the main issue with replicating failed accounts is that you can cause replication storms by simply probing all user accounts with failed binds or AS requests. In some environments that may cause DoSs (if you have slow/high latency links on which replication runs for example). So I think we should always give the option to turn off failed date/count attributes replication, which in turn would mean we still require a new attribute to replicate for when a user is finally locked out on one of the servers or we fail requirement 1. Simo. Another problem with keeping track of bind attributes in a replicated environment is the sheer size of the replication metadata. Replicating 1 failed bind attempt might be 100kbytes or more data to all servers. We should have a way to perhaps say only keep last N CSNs or maybe even don't keep CSNs for these attributes. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 241-253 CA certificate renewal
Rob Crittenden wrote:
Jan Cholasta wrote:
Hi,
the attached patches implement automatic CA certificate renewal as well
as the initial version of the CA certificate management tool.
Requires my patches 172-196.
In order to test, you must install current git version of certmonger
(see https://fedorahosted.org/certmonger/ticket/26) and set SELinux to
permissive (see https://bugzilla.redhat.com/show_bug.cgi?id=1078783).
Make sure you install certmonger before running
ipa-server-install/ipa-replica-install. On F20 you can use RPMs located
at http://jcholast.fedorapeople.org/certmonger-git/.
To test automatic renewal, move system time forward (see
https://fedorahosted.org/freeipa/ticket/2803#comment:17 for more info
about certificate renewal testing, nickname of the CA certificate is
caSigningCert cert-pki-ca). In CA-full installs the renewal should be
fully automatic, in CA-less installs you should be alerted via syslog to
renew the certificate using ipa-cacert-manage.
To test manual renewal, run ipa-cacert-manage renew. You can run it on
any CA master. To make the renewed certificate available on other CA
masters, you must run getcert resubmit -d /etc/pki/pki-tomcat/alias -n
'caSigningCert cert-pki-ca' on each of them. Note that currently you
can't change the chaining of the CA certificate.
241
Not to be too anal, but would it be too outlandish to compare the
Authority Key Identifier (if there is one) with the Subject Key ID to
see if the cert is self-signed? Same subject then yeah, it is probably
self-signed. The keys match? Definitely.
242
I wonder if it would be clearer to use variables instead of a raw list
in the return value for these handlers: (result, message) = handler(...)
rather than examining result[0], etc. That may be beyond the scope of
this patch though.
x509.normalize_certificate() can raise an exception, there should be a
try/except around it.
For an invalid cookie, please include the values seen in the environment
in the error message.
243
You are going to end up with a lot of acis with the same comment value.
Perhaps add the host in there as well.
These are not removed when a master is deleted.
244
There are now several different places where the caCertificate value is
updated. I wonder if it's time for a function. I found it it in
dsinstance.py, upload_cacert and now renew_ca_cert.
246
caRenewalMaster should be checked when a replica is deleted and moved to
another master. This is a good idea. I wonder if a ticket should be
opened to do something similar for CRL generation.
247
We've been burned by hardcoded timeouts in the past. Should this be
configurable? This module doesn't currently do any logging but it might
be worth spitting out a waiting message, at least for debugging.
249
nss_init() is always scary to me since we can only have one. I didn't
see anything blow up, just wondering if this should be wrapped with an
is_initialized()-shutdown() at the top.
The find_cert_from_nickname() should be in a try/except in case the cert
is not found for some reason.
251
The tool should provide some feedback while it's running. For the
impatient (me) it takes a really long time and it's hard to know what is
going on, something in between nothing and full debug output.
The man page needs some more work too. I think some more explanation is
needed and an example would probably be really helpful as well. I think
particularly an example for external certs and a description of what you
mean by Self-signed CA (I assume you mean IPA-provided). I don't think
it really matters how many steps there are unless you are going to
provide progress output.
Got a backtrace when running as non-root:
$ ipa-cacert-manage -v renew
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: File
/usr/lib/python2.7/site-packages/ipapython/admintool.py, line 168, in
execute
self.validate_options()
File
/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py,
line 62, in validate_options
super(CACertManage, self).validate_options(needs_root=True)
File /usr/lib/python2.7/site-packages/ipapython/admintool.py, line
189, in validate_options
raise ScriptError('Must be root to run %s' % self.command_name, 1)
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The
ipa-cacert-manage command failed, exception: ScriptError: Must be root
to run ipa-cacert-manage
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: Must be
root to run ipa-cacert-manage
252
In what context would this be executing? My guess is that certmonger is
trying to do the renewal but a new cert hasn't been issued yet, so this
gets sysloged?
Still doing functional testing.
My current scenario:
1. Newly installed IPA master with these patches.
2. Replica using IPA 3.3.4 (yeah, I cheated)
While doing time travel I had a single cert fail on the initial master
with this:
ca-error: Server at https://lyra.example.com/ipa/xml failed
request, will retry: 4204
Re: [Freeipa-devel] global account lockout
On Mon, 2014-04-07 at 10:22 -0600, Rich Megginson wrote: On 04/07/2014 10:13 AM, Simo Sorce wrote: On Mon, 2014-04-07 at 12:10 -0400, Simo Sorce wrote: On Mon, 2014-04-07 at 12:01 -0400, Simo Sorce wrote: On Mon, 2014-04-07 at 11:26 -0400, Rob Crittenden wrote: Ludwig Krispenz wrote: Hi, please review the following feature design. It introduces a global account lockout, while trying to keep the replication traffic minimal. In my opinion for a real global account lockout the basic lockout attributes have to be replicated otherwise the benefit is minimal: an attacker could perform (maxFailedcount -1) login attempts on every server before the global lockout is set. But the design page describes how it could be done if it should be implemented - maybe the side effect that accounts could the be unlocked on any replica has its own benefit. http://www.freeipa.org/page/V4/Replicated_lockout One weakness with this is there is still a window for extra password attempts if one is clever, (m * (f-1))+1 to be exact, where m is the number of masters and f is the # of allowed failed logins. Yes, but that is a problem that cannot be solved w/o full replication at every authentication attempt. What we tried to achieve is a middle ground to at least ease administration and still lock em up earlier. Let me add that we could have yet another closer step by finding a way to replicate only failed attempts and not successful attempts in some case. Assuming a setup where most people do not fail to enter their password it would make for a decent compromise. That could be achieved by not storing lastsuccessful auth except when that is needed to clear failed logon attempts (ie when the failed logon counter is 0) If we did that then we would not need a new attribute actually, as failed logins would always be replicated. However it would mean that last Successful auth would never be accurate on any server. Or perhaps we could have a local last successful auth and a global one by adding one new attribute, and keeping masking only the successful auth. The main issue about all these possibilities is how do we present them ? And how do we make a good default ? I think a good default is defined by these 2 characteristics: 1. lockouts can be dealt with on any replica w/o having the admin hunt down where a user is locked. 2. at least successful authentications will not cause replication storms If we can afford to cause replications on failed authentication by default, then we could open up replication for failedauth and failedcount attributes but still bar the successful auth attribute. Unlock would simply consist in forcibly setting failed count to 0 (which is replicated so it would unlock all servers). This would work w/o introducing new attributes and only with minimal logic changes in the KDC/pwd-extop plugins I think. Sigh re[plying again to myself. note that the main issue with replicating failed accounts is that you can cause replication storms by simply probing all user accounts with failed binds or AS requests. In some environments that may cause DoSs (if you have slow/high latency links on which replication runs for example). So I think we should always give the option to turn off failed date/count attributes replication, which in turn would mean we still require a new attribute to replicate for when a user is finally locked out on one of the servers or we fail requirement 1. Simo. Another problem with keeping track of bind attributes in a replicated environment is the sheer size of the replication metadata. Replicating 1 failed bind attempt might be 100kbytes or more data to all servers. We should have a way to perhaps say only keep last N CSNs or maybe even don't keep CSNs for these attributes. Yes, but this look a lot like general replication improvement (would also be cool to have better conflict resolution), not lockout specific. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] global account lockout
On 04/07/2014 12:31 PM, Simo Sorce wrote: On Mon, 2014-04-07 at 10:22 -0600, Rich Megginson wrote: On 04/07/2014 10:13 AM, Simo Sorce wrote: On Mon, 2014-04-07 at 12:10 -0400, Simo Sorce wrote: On Mon, 2014-04-07 at 12:01 -0400, Simo Sorce wrote: On Mon, 2014-04-07 at 11:26 -0400, Rob Crittenden wrote: Ludwig Krispenz wrote: Hi, please review the following feature design. It introduces a global account lockout, while trying to keep the replication traffic minimal. In my opinion for a real global account lockout the basic lockout attributes have to be replicated otherwise the benefit is minimal: an attacker could perform (maxFailedcount -1) login attempts on every server before the global lockout is set. But the design page describes how it could be done if it should be implemented - maybe the side effect that accounts could the be unlocked on any replica has its own benefit. http://www.freeipa.org/page/V4/Replicated_lockout One weakness with this is there is still a window for extra password attempts if one is clever, (m * (f-1))+1 to be exact, where m is the number of masters and f is the # of allowed failed logins. Yes, but that is a problem that cannot be solved w/o full replication at every authentication attempt. What we tried to achieve is a middle ground to at least ease administration and still lock em up earlier. Let me add that we could have yet another closer step by finding a way to replicate only failed attempts and not successful attempts in some case. Assuming a setup where most people do not fail to enter their password it would make for a decent compromise. That could be achieved by not storing lastsuccessful auth except when that is needed to clear failed logon attempts (ie when the failed logon counter is 0) If we did that then we would not need a new attribute actually, as failed logins would always be replicated. However it would mean that last Successful auth would never be accurate on any server. Or perhaps we could have a local last successful auth and a global one by adding one new attribute, and keeping masking only the successful auth. The main issue about all these possibilities is how do we present them ? And how do we make a good default ? I think a good default is defined by these 2 characteristics: 1. lockouts can be dealt with on any replica w/o having the admin hunt down where a user is locked. 2. at least successful authentications will not cause replication storms If we can afford to cause replications on failed authentication by default, then we could open up replication for failedauth and failedcount attributes but still bar the successful auth attribute. Unlock would simply consist in forcibly setting failed count to 0 (which is replicated so it would unlock all servers). This would work w/o introducing new attributes and only with minimal logic changes in the KDC/pwd-extop plugins I think. Sigh re[plying again to myself. note that the main issue with replicating failed accounts is that you can cause replication storms by simply probing all user accounts with failed binds or AS requests. In some environments that may cause DoSs (if you have slow/high latency links on which replication runs for example). So I think we should always give the option to turn off failed date/count attributes replication, which in turn would mean we still require a new attribute to replicate for when a user is finally locked out on one of the servers or we fail requirement 1. Simo. Another problem with keeping track of bind attributes in a replicated environment is the sheer size of the replication metadata. Replicating 1 failed bind attempt might be 100kbytes or more data to all servers. We should have a way to perhaps say only keep last N CSNs or maybe even don't keep CSNs for these attributes. Yes, but this look a lot like general replication improvement (would also be cool to have better conflict resolution), Ludwig has made some improvements with how 389 stores replication metadata for conflict resolution, but in this case it's not nearly enough. not lockout specific. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] global account lockout
On 04/07/2014 02:31 PM, Simo Sorce wrote: On Mon, 2014-04-07 at 10:22 -0600, Rich Megginson wrote: On 04/07/2014 10:13 AM, Simo Sorce wrote: On Mon, 2014-04-07 at 12:10 -0400, Simo Sorce wrote: On Mon, 2014-04-07 at 12:01 -0400, Simo Sorce wrote: On Mon, 2014-04-07 at 11:26 -0400, Rob Crittenden wrote: Ludwig Krispenz wrote: Hi, please review the following feature design. It introduces a global account lockout, while trying to keep the replication traffic minimal. In my opinion for a real global account lockout the basic lockout attributes have to be replicated otherwise the benefit is minimal: an attacker could perform (maxFailedcount -1) login attempts on every server before the global lockout is set. But the design page describes how it could be done if it should be implemented - maybe the side effect that accounts could the be unlocked on any replica has its own benefit. http://www.freeipa.org/page/V4/Replicated_lockout One weakness with this is there is still a window for extra password attempts if one is clever, (m * (f-1))+1 to be exact, where m is the number of masters and f is the # of allowed failed logins. Yes, but that is a problem that cannot be solved w/o full replication at every authentication attempt. What we tried to achieve is a middle ground to at least ease administration and still lock em up earlier. Let me add that we could have yet another closer step by finding a way to replicate only failed attempts and not successful attempts in some case. Assuming a setup where most people do not fail to enter their password it would make for a decent compromise. That could be achieved by not storing lastsuccessful auth except when that is needed to clear failed logon attempts (ie when the failed logon counter is 0) If we did that then we would not need a new attribute actually, as failed logins would always be replicated. However it would mean that last Successful auth would never be accurate on any server. Or perhaps we could have a local last successful auth and a global one by adding one new attribute, and keeping masking only the successful auth. The main issue about all these possibilities is how do we present them ? And how do we make a good default ? I think a good default is defined by these 2 characteristics: 1. lockouts can be dealt with on any replica w/o having the admin hunt down where a user is locked. 2. at least successful authentications will not cause replication storms If we can afford to cause replications on failed authentication by default, then we could open up replication for failedauth and failedcount attributes but still bar the successful auth attribute. Unlock would simply consist in forcibly setting failed count to 0 (which is replicated so it would unlock all servers). This would work w/o introducing new attributes and only with minimal logic changes in the KDC/pwd-extop plugins I think. Sigh re[plying again to myself. note that the main issue with replicating failed accounts is that you can cause replication storms by simply probing all user accounts with failed binds or AS requests. In some environments that may cause DoSs (if you have slow/high latency links on which replication runs for example). So I think we should always give the option to turn off failed date/count attributes replication, which in turn would mean we still require a new attribute to replicate for when a user is finally locked out on one of the servers or we fail requirement 1. Simo. Another problem with keeping track of bind attributes in a replicated environment is the sheer size of the replication metadata. Replicating 1 failed bind attempt might be 100kbytes or more data to all servers. We should have a way to perhaps say only keep last N CSNs or maybe even don't keep CSNs for these attributes. Yes, but this look a lot like general replication improvement (would also be cool to have better conflict resolution), not lockout specific. Simo. My only comment is actually about conflict resolution. What would happen if I attack (flood) two replicas at the same time beating the replication. It would mean both servers would generate the global attributes and try to replicate to each other. If the replicas are on the edges of topology it might take some time and it might even happen that admin already unlocked the account while the old lock is still trying to propagate. IMO we need collisions resolution logic taken care of first. I suspect that any real attack would lead to collisions and if it would leave the deployment unstable even after the attack ended we lost. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Add DRM to IPA
On 04/04/2014 02:50 PM, Ade Lee wrote: This patch adds the capability of installing a Dogtag DRM to an IPA instance. With this patch, when ipa-server-install is run, a Dogtag CA and a Dogtag DRM are created. The DRM shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. It is also possible to clone the DRM. When the IPA instance is cloned, if --enable-ca and --enable-drm are specified, the DRM is cloned as well. Installing a DRM requires the user to have a Dogtag CA instance. We can look into possibly relaxing that requirement in a later patch. I am still working on patches for a ipa-drm-install script, which would be used to add a DRM to an existing master (that includes a dogtag CA), or an existing clone. Please review, Thanks, Ade Any takers? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Add DRM to IPA
Dmitri Pal wrote: On 04/04/2014 02:50 PM, Ade Lee wrote: This patch adds the capability of installing a Dogtag DRM to an IPA instance. With this patch, when ipa-server-install is run, a Dogtag CA and a Dogtag DRM are created. The DRM shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. It is also possible to clone the DRM. When the IPA instance is cloned, if --enable-ca and --enable-drm are specified, the DRM is cloned as well. Installing a DRM requires the user to have a Dogtag CA instance. We can look into possibly relaxing that requirement in a later patch. I am still working on patches for a ipa-drm-install script, which would be used to add a DRM to an existing master (that includes a dogtag CA), or an existing clone. Please review, Thanks, Ade Any takers? I'm going to look at it. Ade has provided a COPR build of the dogtag bits we'll need at http://copr.fedoraproject.org/coprs/vakwetu/dogtag/repo/fedora-20-x86_64/ rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] global account lockout
On Mon, 2014-04-07 at 14:47 -0400, Dmitri Pal wrote: On 04/07/2014 02:31 PM, Simo Sorce wrote: On Mon, 2014-04-07 at 10:22 -0600, Rich Megginson wrote: On 04/07/2014 10:13 AM, Simo Sorce wrote: On Mon, 2014-04-07 at 12:10 -0400, Simo Sorce wrote: On Mon, 2014-04-07 at 12:01 -0400, Simo Sorce wrote: On Mon, 2014-04-07 at 11:26 -0400, Rob Crittenden wrote: Ludwig Krispenz wrote: Hi, please review the following feature design. It introduces a global account lockout, while trying to keep the replication traffic minimal. In my opinion for a real global account lockout the basic lockout attributes have to be replicated otherwise the benefit is minimal: an attacker could perform (maxFailedcount -1) login attempts on every server before the global lockout is set. But the design page describes how it could be done if it should be implemented - maybe the side effect that accounts could the be unlocked on any replica has its own benefit. http://www.freeipa.org/page/V4/Replicated_lockout One weakness with this is there is still a window for extra password attempts if one is clever, (m * (f-1))+1 to be exact, where m is the number of masters and f is the # of allowed failed logins. Yes, but that is a problem that cannot be solved w/o full replication at every authentication attempt. What we tried to achieve is a middle ground to at least ease administration and still lock em up earlier. Let me add that we could have yet another closer step by finding a way to replicate only failed attempts and not successful attempts in some case. Assuming a setup where most people do not fail to enter their password it would make for a decent compromise. That could be achieved by not storing lastsuccessful auth except when that is needed to clear failed logon attempts (ie when the failed logon counter is 0) If we did that then we would not need a new attribute actually, as failed logins would always be replicated. However it would mean that last Successful auth would never be accurate on any server. Or perhaps we could have a local last successful auth and a global one by adding one new attribute, and keeping masking only the successful auth. The main issue about all these possibilities is how do we present them ? And how do we make a good default ? I think a good default is defined by these 2 characteristics: 1. lockouts can be dealt with on any replica w/o having the admin hunt down where a user is locked. 2. at least successful authentications will not cause replication storms If we can afford to cause replications on failed authentication by default, then we could open up replication for failedauth and failedcount attributes but still bar the successful auth attribute. Unlock would simply consist in forcibly setting failed count to 0 (which is replicated so it would unlock all servers). This would work w/o introducing new attributes and only with minimal logic changes in the KDC/pwd-extop plugins I think. Sigh re[plying again to myself. note that the main issue with replicating failed accounts is that you can cause replication storms by simply probing all user accounts with failed binds or AS requests. In some environments that may cause DoSs (if you have slow/high latency links on which replication runs for example). So I think we should always give the option to turn off failed date/count attributes replication, which in turn would mean we still require a new attribute to replicate for when a user is finally locked out on one of the servers or we fail requirement 1. Simo. Another problem with keeping track of bind attributes in a replicated environment is the sheer size of the replication metadata. Replicating 1 failed bind attempt might be 100kbytes or more data to all servers. We should have a way to perhaps say only keep last N CSNs or maybe even don't keep CSNs for these attributes. Yes, but this look a lot like general replication improvement (would also be cool to have better conflict resolution), not lockout specific. Simo. My only comment is actually about conflict resolution. What would happen if I attack (flood) two replicas at the same time beating the replication. It would mean both servers would generate the global attributes and try to replicate to each other. If the replicas are on the edges of topology it might take some time and it might even happen that admin already unlocked the account while the old lock is still trying to propagate. IMO we need collisions resolution logic taken care of first. I suspect that any real attack would lead to collisions and if it would leave the deployment unstable even after the attack ended we lost. Yes, this is a valid concern. We need a last-wins conflict resolution strategy for some cases. Simo. -- Simo Sorce * Red Hat, Inc * New York ___
Re: [Freeipa-devel] global account lockout
On 04/07/2014 01:00 PM, Simo Sorce wrote: On Mon, 2014-04-07 at 14:47 -0400, Dmitri Pal wrote: On 04/07/2014 02:31 PM, Simo Sorce wrote: On Mon, 2014-04-07 at 10:22 -0600, Rich Megginson wrote: On 04/07/2014 10:13 AM, Simo Sorce wrote: On Mon, 2014-04-07 at 12:10 -0400, Simo Sorce wrote: On Mon, 2014-04-07 at 12:01 -0400, Simo Sorce wrote: On Mon, 2014-04-07 at 11:26 -0400, Rob Crittenden wrote: Ludwig Krispenz wrote: Hi, please review the following feature design. It introduces a global account lockout, while trying to keep the replication traffic minimal. In my opinion for a real global account lockout the basic lockout attributes have to be replicated otherwise the benefit is minimal: an attacker could perform (maxFailedcount -1) login attempts on every server before the global lockout is set. But the design page describes how it could be done if it should be implemented - maybe the side effect that accounts could the be unlocked on any replica has its own benefit. http://www.freeipa.org/page/V4/Replicated_lockout One weakness with this is there is still a window for extra password attempts if one is clever, (m * (f-1))+1 to be exact, where m is the number of masters and f is the # of allowed failed logins. Yes, but that is a problem that cannot be solved w/o full replication at every authentication attempt. What we tried to achieve is a middle ground to at least ease administration and still lock em up earlier. Let me add that we could have yet another closer step by finding a way to replicate only failed attempts and not successful attempts in some case. Assuming a setup where most people do not fail to enter their password it would make for a decent compromise. That could be achieved by not storing lastsuccessful auth except when that is needed to clear failed logon attempts (ie when the failed logon counter is 0) If we did that then we would not need a new attribute actually, as failed logins would always be replicated. However it would mean that last Successful auth would never be accurate on any server. Or perhaps we could have a local last successful auth and a global one by adding one new attribute, and keeping masking only the successful auth. The main issue about all these possibilities is how do we present them ? And how do we make a good default ? I think a good default is defined by these 2 characteristics: 1. lockouts can be dealt with on any replica w/o having the admin hunt down where a user is locked. 2. at least successful authentications will not cause replication storms If we can afford to cause replications on failed authentication by default, then we could open up replication for failedauth and failedcount attributes but still bar the successful auth attribute. Unlock would simply consist in forcibly setting failed count to 0 (which is replicated so it would unlock all servers). This would work w/o introducing new attributes and only with minimal logic changes in the KDC/pwd-extop plugins I think. Sigh re[plying again to myself. note that the main issue with replicating failed accounts is that you can cause replication storms by simply probing all user accounts with failed binds or AS requests. In some environments that may cause DoSs (if you have slow/high latency links on which replication runs for example). So I think we should always give the option to turn off failed date/count attributes replication, which in turn would mean we still require a new attribute to replicate for when a user is finally locked out on one of the servers or we fail requirement 1. Simo. Another problem with keeping track of bind attributes in a replicated environment is the sheer size of the replication metadata. Replicating 1 failed bind attempt might be 100kbytes or more data to all servers. We should have a way to perhaps say only keep last N CSNs or maybe even don't keep CSNs for these attributes. Yes, but this look a lot like general replication improvement (would also be cool to have better conflict resolution), not lockout specific. Simo. My only comment is actually about conflict resolution. What would happen if I attack (flood) two replicas at the same time beating the replication. It would mean both servers would generate the global attributes and try to replicate to each other. If the replicas are on the edges of topology it might take some time and it might even happen that admin already unlocked the account while the old lock is still trying to propagate. IMO we need collisions resolution logic taken care of first. I suspect that any real attack would lead to collisions and if it would leave the deployment unstable even after the attack ended we lost. Yes, this is a valid concern. We need a last-wins conflict resolution strategy for some cases. I'm not sure what you mean. The 389 conflict resolution strategy is last-wins already. Or do you mean for some cases, but not all cases? Simo. ___
Re: [Freeipa-devel] [PATCH] Add DRM to IPA
Ade Lee wrote: This patch adds the capability of installing a Dogtag DRM to an IPA instance. With this patch, when ipa-server-install is run, a Dogtag CA and a Dogtag DRM are created. The DRM shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. It is also possible to clone the DRM. When the IPA instance is cloned, if --enable-ca and --enable-drm are specified, the DRM is cloned as well. Installing a DRM requires the user to have a Dogtag CA instance. We can look into possibly relaxing that requirement in a later patch. I am still working on patches for a ipa-drm-install script, which would be used to add a DRM to an existing master (that includes a dogtag CA), or an existing clone. Please review, Thanks, Ade Yikes, I wonder if the changes to ipaserver/install/cainstance.py should be pushed ASAP. freeipa-spec.in needs a dependency on pki-kra. Is it necessary to check for pkispawn/destroy in check_inst()? That should be handled by the CA install, right? You need to bump the version in ipa-pki-proxy.conf so that upgrades get the new configuration. Rather than this: +if setup_drm: +fd.write(enable_drm=True\n) +else: +fd.write(enable_drm=False\n) Why not: fd.write(enable_drm=%s\n % setup_drm) If o=ipadrm is a new root we'll need to backup/restore it right? You should import PKI_USER and HTTPD_CONFD from cainstance.py rather than redefining them. You should probably call the is_installed() from cainstance.py rather than redefining this. The function might be ok but I'd replace the contents with: ca = cainstance.CAInstance(api.env.realm, certs.NSS_DIR) return ca.is_installed() If the DRM is already installed we don't have a way to uninstall it so we shouldn't recommend that as an option. The value for pki_issuing_ca_uri doesn't create a valid URL (missing //). You should use this form instead: config.set(KRA, pki_issuing_ca_uri, https://%s; % ipautil.format_netloc(self.fqdn, 443)) I think that update_people_entry() should probably be moved into installutils.py and used for both the CA and DRM instances. It makes a certain amount of sense to use /etc/ipa/default.conf. It may be outside the scope here but it if we're including it, but would it be better to use that for everything rather than splitting between two files? The install failed for me. I've attached the KRA debug log. rob debug.gz Description: GNU Zip compressed data ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] global account lockout
Rich Megginson wrote: On 04/07/2014 01:00 PM, Simo Sorce wrote: On Mon, 2014-04-07 at 14:47 -0400, Dmitri Pal wrote: On 04/07/2014 02:31 PM, Simo Sorce wrote: On Mon, 2014-04-07 at 10:22 -0600, Rich Megginson wrote: On 04/07/2014 10:13 AM, Simo Sorce wrote: On Mon, 2014-04-07 at 12:10 -0400, Simo Sorce wrote: On Mon, 2014-04-07 at 12:01 -0400, Simo Sorce wrote: On Mon, 2014-04-07 at 11:26 -0400, Rob Crittenden wrote: Ludwig Krispenz wrote: Hi, please review the following feature design. It introduces a global account lockout, while trying to keep the replication traffic minimal. In my opinion for a real global account lockout the basic lockout attributes have to be replicated otherwise the benefit is minimal: an attacker could perform (maxFailedcount -1) login attempts on every server before the global lockout is set. But the design page describes how it could be done if it should be implemented - maybe the side effect that accounts could the be unlocked on any replica has its own benefit. http://www.freeipa.org/page/V4/Replicated_lockout One weakness with this is there is still a window for extra password attempts if one is clever, (m * (f-1))+1 to be exact, where m is the number of masters and f is the # of allowed failed logins. Yes, but that is a problem that cannot be solved w/o full replication at every authentication attempt. What we tried to achieve is a middle ground to at least ease administration and still lock em up earlier. Let me add that we could have yet another closer step by finding a way to replicate only failed attempts and not successful attempts in some case. Assuming a setup where most people do not fail to enter their password it would make for a decent compromise. That could be achieved by not storing lastsuccessful auth except when that is needed to clear failed logon attempts (ie when the failed logon counter is 0) If we did that then we would not need a new attribute actually, as failed logins would always be replicated. However it would mean that last Successful auth would never be accurate on any server. Or perhaps we could have a local last successful auth and a global one by adding one new attribute, and keeping masking only the successful auth. The main issue about all these possibilities is how do we present them ? And how do we make a good default ? I think a good default is defined by these 2 characteristics: 1. lockouts can be dealt with on any replica w/o having the admin hunt down where a user is locked. 2. at least successful authentications will not cause replication storms If we can afford to cause replications on failed authentication by default, then we could open up replication for failedauth and failedcount attributes but still bar the successful auth attribute. Unlock would simply consist in forcibly setting failed count to 0 (which is replicated so it would unlock all servers). This would work w/o introducing new attributes and only with minimal logic changes in the KDC/pwd-extop plugins I think. Sigh re[plying again to myself. note that the main issue with replicating failed accounts is that you can cause replication storms by simply probing all user accounts with failed binds or AS requests. In some environments that may cause DoSs (if you have slow/high latency links on which replication runs for example). So I think we should always give the option to turn off failed date/count attributes replication, which in turn would mean we still require a new attribute to replicate for when a user is finally locked out on one of the servers or we fail requirement 1. Simo. Another problem with keeping track of bind attributes in a replicated environment is the sheer size of the replication metadata. Replicating 1 failed bind attempt might be 100kbytes or more data to all servers. We should have a way to perhaps say only keep last N CSNs or maybe even don't keep CSNs for these attributes. Yes, but this look a lot like general replication improvement (would also be cool to have better conflict resolution), not lockout specific. Simo. My only comment is actually about conflict resolution. What would happen if I attack (flood) two replicas at the same time beating the replication. It would mean both servers would generate the global attributes and try to replicate to each other. If the replicas are on the edges of topology it might take some time and it might even happen that admin already unlocked the account while the old lock is still trying to propagate. IMO we need collisions resolution logic taken care of first. I suspect that any real attack would lead to collisions and if it would leave the deployment unstable even after the attack ended we lost. Yes, this is a valid concern. We need a last-wins conflict resolution strategy for some cases. I'm not sure what you mean. The 389 conflict resolution strategy is last-wins already. Or do you mean for some cases, but not all cases? He may be thinking entry vs attribute
Re: [Freeipa-devel] Ipa-server-install Firewall Support
On 04/07/2014 09:00 AM, Rob Crittenden wrote:
Simo Sorce wrote:
On Fri, 2014-04-04 at 09:59 +0200, Petr Spacek wrote:
On 4.4.2014 09:17, Martin Kosek wrote:
On 04/04/2014 09:04 AM, Justin Brown wrote:
I would actually do it the opposite way and open the ports after
the FreeIPA server is fully configured. After all, I do not think
we want to open the ports when the server is just half-configured
and for example some ACIs are missing.
My thinking was that nothing would be listening on these ports if the
install doesn't succeed, but there's really necessity to modify the
firewall configuration early. (All of the internal install
communication will be over a local interface (to netfilter) and
unblock anyways. I don't have any problem in delaying firewall
configuration to the end of install.
If ipa-server-install does succeed without configuring the
firewalld, then we
will indeed have no other option than to do it early.
I am thinking that we may want to put all the firewalld
configuration in
ipaserver/install/firewalldinstance.py,
and then make the firewalld configuration the actual step of the
installation.
Something like:
...
Configuring Firewall (firewalld)
[1/2]: looking up the right zone
[2/2]: allowing ports
Done configuring Firewall (firewalld).
...
The Service class derived object can be really simple, we would
just reuse the
functionality it already has + let us properly hook into it in
ipa-{server,replica}-install and the uninstallation.
It would also make it easier to split this functionality to
freeipa-server-firewalld if we chose to in a future.
In general I agree with the idea, thank you Justin for working on that!
I would like to emphasis the necessity to work without
NetworkManager and
FirewallD. New dependencies make Debian folks unhappy ...
On the other hand, it is perfectly fine to skip firewall
configuration if
NM/FirewallD/DBus is not available.
Have a nice day!
Should be easy, probe for the dbus firewalld service and just skip (not
error out) if it is not there.
Set a variable in that case that will cause the installer to throw the
classic banner we have now which warns you about what ports need to be
opened at the end of the install.
Probably just need to spit out a large, preferably flashing warning
that the firewall has not been automatically configured. Perhaps even
multiple times: one in-line and one at the install summary at the end.
rob
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Thanks for looking into this!
Would it be possible to summarize this thread in a design page on the wiki?
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Random Certificate Serial Numbers
On 04/07/2014 03:48 AM, Martin Kosek wrote: Hi Rob, Ade and others, In the past, Rob was investigating enabling random certificate serial numbers for FreeIPA PKI [1]. We also have a ticket [2] planned to enable it for 4.0. Can we simply switch it on for PKI with pkispawn attribute: [CA] pki_random_serial_numbers_enable=True or is there any drawback or risk we should investigate. I am just thinking, does PKI handle collisions anyhow? When for example two PKI masters generate 2 certificates of the same serial (unlikely though it could happen)? Currently, we assign different slice of serial range to different PKI masters, do we want to do that also for random serial? Thanks for info [1] http://dogtagpki.org/wiki/Random_Certificate_Serial_Numbers [2] https://fedorahosted.org/freeipa/ticket/2016 Any impact on upgrades? Any impact on certmonger? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
