Re: [Freeipa-devel] #5881 / bz1327092 ; fixing broken caIPAserviceCert profile

[Martin Kosek]

On 05/12/2016 12:56 AM, Fraser Tweedale wrote:
> On Wed, May 11, 2016 at 04:36:34PM +0200, Jan Cholasta wrote:
>> On 11.5.2016 15:04, Fraser Tweedale wrote:
>>> On Wed, May 11, 2016 at 01:31:36PM +0200, Jan Cholasta wrote:
...
 3) I would rather avoid adding new commands just to work around bugs. IMO
 "certprofile-import caIPAserviceCert
 /usr/share/ipa/profiles/caIPAserviceCert.cfg" should be good enough in this
 case.

>>> As discussed above, I'm afraid it is not, unless users manually do
>>> the substitutions.  If we provide some code to do the substitutions,
>>> we have essentially reach what I have proposed.
>>>
>>> Other suggestions are welcome.
>>>
>>> BTW, there is another option I did not already mention: do nothing
>>> in code, and help users on a case-by-case basis / point them to a
>>> guide / KB article?
>>
>> This option is my favorite :-) (If automatic fix during upgrade is indeed
>> out of the picture.)
>>
> Martin, if the profile is incorrect, do we have to fix it
> automatically?  What are our obligations / customer expectations
> here?

I would love to hear customer expectations, but in that case you should ask the
users/customers, not me :-) But having documented procedure in a KB/wiki
article how to fix a broken profile seems as a good enough for me, we can build
the API command later if we see a pressing need.

Martin

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Provisioning throughput

[Ludwig Krispenz]

On 05/12/2016 03:45 PM, Ludwig Krispenz wrote:


On 05/12/2016 02:16 PM, Petr Vobornik wrote:

On 05/10/2016 05:50 PM, thierry bordaz wrote:


On 05/05/2016 03:44 PM, Petr Vobornik wrote:

On 05/04/2016 02:20 PM, thierry bordaz wrote:

Hello,

  I have been doing some tests/measures using
https://github.com/freeipa/freeipa-tools/blob/master/create-test-data.py.

  The tool creates a set of typical users/hosts/groups... to
import with a
  ldapadd.

  I wrote down some finding in
http://www.freeipa.org/page/V4/Performance_Improvements#Provisioning_throughput_and_DS_plugins.

  I still have to do some cleanup around the performance but the
basic of a
  possible improvement is to do provisioning in several steps
(disabling
  plugins, provisioning, enabling plugin, running fixup tasks).

  Before going further in the design I wanted to share those 
ideas

and know if
  it raise any concern.

  thanks
  thierry


Hi Thierry,

Thanks for the analysis. Very nice.

Knowing this will help us suggesting workarounds also for old 
releases.


Couple questions:

Have you tested retrCL disabled with memberOf enabled. It seems 
that it

would eliminate 550K adds and 0.8M searches. What would be the time
improvement?

Do you know what is the time when memberof is enabled but slapi-nis 
and

retroCL are disabled?

The culprit of the performance issue is very likely related to SRCH
(internal) triggered by memberof.

If retroCL is disabled and memberof enabled, #SRCH is 13.8M.
If retroCL is disabled, slapi-nis disabled and memberof enabled 
#SRCH is

14.8
When all of them are enabled the #SRCH is 15M.

You are right if retroCL is disabled the #ADD drops but it has no
significant effect on the duration.

ok, thanks for the analysis

Regarding the duration of the provisioning, values are not really 
stable

as performance of VM fluctuates. But as soon as memberof is enabled the
provisioning lasts > 4hours where the same provisioning lasts 6mins as
soon as memberof is disabled.

I need to confirm the average time for internal searches but assuming
1ms per SRCH it consumes >90% of the provisioning.



  From the text it was not clear to me, if you find or investigate
possible improvements in memberof plugin which would improve the
performance without stopping and starting DS.

As was discussed at mtg, have you tried if the DS restart is really
necessary?
memberof plugin can be enabled and disabled while the server is 
running, BUT
to achieve this the "enable-dynamic-plugins" feature has to be turned 
on. And then any enable/disable of a plugin would try to do it 
dynamically an dnot wait for the restart.
And I think not all plugins are able to handle this, TomasB was once 
working on it for IPA plugins, but it was not completed as far as I know
but enabling dynamic plugins can be done without restart, so what can be 
done is.

- enable dynamic plugins
- disable memberof
- do some work
- enable memberof
- disable dynamic plugins



And if it is required, what would be needed to not require restart.

The workaround should be easy to use.




--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael 
O'Neill

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling

[Martin Babinsky]

On 05/09/2016 08:26 AM, Alexander Bokovoy wrote:

On Fri, 06 May 2016, Martin Babinsky wrote:

On 05/05/2016 02:58 PM, Milan Kubík wrote:

On 04/08/2016 05:10 PM, Martin Babinsky wrote:

Hi list,

I have put together a draft [1] outlining the effort to reimplement
the handling of Kerberos principals in both backend and frontend
layers of FreeIPA so that we may have multiple aliases per user, host
or service and thus implement stuff like
https://fedorahosted.org/freeipa/ticket/3961 and
https://fedorahosted.org/freeipa/ticket/5413 .

Since much of the plumbing was already implemented,[2] the document
mainly describes what the patches do. Some parts required by other use
cases may be missing so please point these out.

I would also be happy if you could correct all factual inacurracies, I
did research on this issue a long time ago and my knowledge turned a
bit rusty.

[1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases
[2]
https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html




Hi!

I went through the design document and the related email thread here on
the list and I have few questions:

1. Is there any progress on what's to happen if MODRDN would colide with
an existing alias on a different entry?


Both krbPrincipalName and krbCanonicalName will be guarded by
uniqueness plugin so this should raise an error in the DS backend.

It will need some more investigation though and will probably warrant
a separate test case in the future test plan.


2. How does this RFE change the behavior of stage user plugin? Is the
principal (as in the canonical name) assigned at this stage of user
lifetime?


I didn't think about staged users when designing/doing patches. Thank
you for pointing this out. The principal name is assigned when
creating the staged user and it is also checked during activation and
again added if it is not present. We will need to handle both of these
cases. I will update the design to reflect this.


3. Will there be any constraints on what string can be used as an alias?
(The document mentions email address as one use case)


The e-mail case can be tricky, since having two '@' in the principal
name can break parsing/unparsing of principal name in KDB DAL. We will
likely have to implement some sort of escaping to handle this
correctly. This should be discussed in more detail with
Simo/Alexander/Sumit.

We should not allow anything after @ not belonging to the list of
realm domains. We also will need to extend realm domains to include
non-domain-based UPN suffixes. This actually flies close to what I need
to finish in my AD trust UPN patches, so I need to make sure we have the
same approach there.



Does this mean that we would not be able to implement e-mail as 
principal alias [1]?





4. Will this RFE have any impact on AD trust (possibility of cross realm
routing, RFC 6806 section 9)



IIRC there should be no impact on trusts.

We should never allow to specify alias from the realm we don't own. This
means the code needs to look into the namespaces associated with any of
the trusted domains and reject them.



So if I understand correctly we should reject tickets incoming from 
trusted domains if they do not contain canonical principal name (i.e. UPN)?


[1] https://fedorahosted.org/freeipa/ticket/5413

--
Martin^3 Babinsky

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0473-0476]DNS Locations: Prologue

[Martin Basti]

On 12.05.2016 11:01, Martin Basti wrote:



On 11.05.2016 09:41, Martin Basti wrote:



On 10.05.2016 18:56, Petr Spacek wrote:

On 10.5.2016 15:38, Petr Spacek wrote:

On 10.5.2016 15:26, Martin Basti wrote:


On 10.05.2016 15:23, Petr Spacek wrote:

On 10.5.2016 14:44, Martin Basti wrote:

On 10.05.2016 14:33, Petr Spacek wrote:

On 6.5.2016 10:20, Martin Basti wrote:

https://fedorahosted.org/freeipa/ticket/2008

Patches attached.


freeipa-mbasti-0473-DNS-Locations-Always-create-DNS-related-privileges.patch 




   From 9a936740da7cdacec150acc92a45041a98ce7cb3 Mon Sep 17 
00:00:00 2001

From: Martin Basti 
Date: Wed, 4 May 2016 17:33:52 +0200
Subject: [PATCH 1/4] DNS Locations: Always create DNS related 
privileges


DNS privileges are important for handling DNS locations which 
can be
created without DNS servers in IPA topology. We will also need 
this

privileges presented for future feature 'External DNS support'

Seems reasonable, ACK.


freeipa-mbasti-0474-DNS-Locations-add-new-attributes-and-objectclasses.patch 




   From a7766da5fd1a72884308d4206c9cde262f5c8d35 Mon Sep 17 
00:00:00 2001

From: Martin Basti 
Date: Thu, 5 May 2016 11:12:00 +0200
Subject: [PATCH 2/4] DNS Locations: add new attributes and 
objectclasses


http://www.freeipa.org/page/V4/DNS_Location_Mechanism

https://fedorahosted.org/freeipa/ticket/2008
---
install/share/60ipadns.ldif | 4 
1 file changed, 4 insertions(+)

diff --git a/install/share/60ipadns.ldif 
b/install/share/60ipadns.ldif

index
e0ed0ab869cea0478d9640bb509c6267abed1a01..31c2f71f8566d04a05709f1359b20e6fa51921ce 



100644
--- a/install/share/60ipadns.ldif
+++ b/install/share/60ipadns.ldif
@@ -70,9 +70,13 @@ attributeTypes: ( 
2.16.840.1.113730.3.8.5.25 NAME

'idnsSecKeyRevoke' DESC 'DNSKE
attributeTypes: ( 2.16.840.1.113730.3.8.5.26 NAME 
'idnsSecKeySep' DESC
'DNSKEY SEP flag (equivalent to bit 15): RFC 4035' EQUALITY 
booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA 
v4.1' )
attributeTypes: ( 2.16.840.1.113730.3.8.5.27 NAME 
'idnsSecAlgorithm' DESC
'DNSKEY algorithm: string used as mnemonic' EQUALITY 
caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 
1.3.6.1.4.1.1466.115.121.1.26

SINGLE-VALUE X-ORIGIN 'IPA v4.1' )
attributeTypes: ( 2.16.840.1.113730.3.8.5.28 NAME 
'idnsSecKeyRef' DESC
'PKCS#11 URI of the key' EQUALITY caseExactMatch SINGLE-VALUE 
SYNTAX

1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.1' )
+attributeTypes: ( 2.16.840.1.113730.3.8.5.32 NAME 
'ipaLocation' DESC
'Reference to IPA location' EQUALITY distinguishedNameMatch 
SYNTAX

1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE X-ORIGIN 'IPA v4.4' )
+attributeTypes: ( 2.16.840.1.113730.3.8.5.33 NAME 
'ipaLocationWeight' DESC
'Weight for the server in IPA location' EQUALITY integerMatch 
SYNTAX

1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'IPA v4.4' )
objectClasses: ( 2.16.840.1.113730.3.8.6.0 NAME 
'idnsRecord' DESC 'dns
Record, usually a host' SUP top STRUCTURAL MUST idnsName MAY ( 
cn $
idnsAllowDynUpdate $ dNSTTL $ dNSClass $ aRecord $ aAAARecord 
$ a6Record $
nSRecord $ cNAMERecord $ pTRRecord $ sRVRecord $ tXTRecord $ 
mXRecord $
mDRecord $ hInfoRecord $ mInfoRecord $ aFSDBRecord $ SigRecord 
$ KeyRecord
$ LocRecord $ nXTRecord $ nAPTRRecord $ kXRecord $ certRecord 
$ dNameRecord

$ dSRecord $ sSHFPRecord $ rRSIGRecord $ nSECRecord $ DLVRecord $
TLSARecord $ UnknownRecord $ RPRecord $ APLRecord $ 
IPSECKEYRecord $

DHCIDRecord $ HIPRecord $ SPFRecord ) )
objectClasses: ( 2.16.840.1.113730.3.8.6.1 NAME 'idnsZone' 
DESC 'Zone
class' SUP idnsRecord STRUCTURAL MUST ( idnsZoneActive $ 
idnsSOAmName $

idnsSOArName $ idnsSOAserial $ idnsSOArefresh $ idnsSOAretry $
idnsSOAexpire $ idnsSOAminimum ) MAY ( idnsUpdatePolicy $ 
idnsAllowQuery $
idnsAllowTransfer $ idnsAllowSyncPTR $ idnsForwardPolicy $ 
idnsForwarders $

idnsSecInlineSigning $ nSEC3PARAMRecord ) )
objectClasses: ( 2.16.840.1.113730.3.8.6.2 NAME 
'idnsConfigObject' DESC

'DNS global config options' STRUCTURAL MAY ( idnsForwardPolicy $
idnsForwarders $ idnsAllowSyncPTR $ idnsZoneRefresh $
idnsPersistentSearch ) )
objectClasses: ( 2.16.840.1.113730.3.8.12.18 NAME 
'ipaDNSZone' SUP top

AUXILIARY MUST idnsName MAY managedBy X-ORIGIN 'IPA v3' )
objectClasses: ( 2.16.840.1.113730.3.8.6.3 NAME 
'idnsForwardZone' DESC
'Forward Zone class' SUP top STRUCTURAL MUST ( idnsName $ 
idnsZoneActive )

MAY ( idnsForwarders $ idnsForwardPolicy ) )
objectClasses: ( 2.16.840.1.113730.3.8.6.4 NAME 
'idnsSecKey' DESC 'DNSSEC
key metadata' STRUCTURAL MUST ( idnsSecKeyRef $ 
idnsSecKeyCreated $

idnsSecAlgorithm ) MAY ( idnsSecKeyPublish $ idnsSecKeyActivate $
idnsSecKeyInactive $ idnsSecKeyDelete $ idnsSecKeyZone $ 
idnsSecKeyRevoke $

idnsSecKeySep $ cn ) X-ORIGIN 'IPA v4.1' )
+objectClasses: ( 2.16.840.1.113730.3.8.6.7 NAME 
'ipaLocationObject' DESC
'Object for storing IPA server location' AUXILIARY MUST ( 
idnsName ) MAY (

Re: [Freeipa-devel] [PATCH] 0011 webui: Offer OTP generation for host enrollment in the UI

[Pavel Vomacka]

On 05/11/2016 03:28 PM, Petr Vobornik wrote:

On 03/31/2016 04:59 PM, Pavel Vomacka wrote:

Hello,

This patch adds option to add host dialog which allows to show generated
OTP.
The patch also changes the way of informing user about success of adding
host
but only when the 'Generate OTP' option is checked.

https://fedorahosted.org/freeipa/ticket/4602


The patch copy behavior of entity adder dialog buttons when the
purpose is to do additional stuff on success. IMHO it copies to much logic.

Also the following method of redefining add handler is not very object
oriented:
   that.get_button('add_and_edit').click = function() {

Wouldn't it be better to move anonymous success handlers in
entity_adder_dialog to a class methods to achieve it. E.g:

"""
 click: function() {
 that.hide_message();
 that.add(
 function(data, text_status, xhr) {
 that.added.notify([data], that);
 that.close();
 var result = data.result.result;
 that.show_edit_page(that.entity, result);
 that.notify_success(data);
 },
 that.on_error);
 }
"""
to
"""
 click: function() {
 that.hide_message();
 that.add(that.on_add_success, that.on_error);
 }

that.on_add_success = function(data, text_status, xhr) {
 that.added.notify([data], that);
 that.close();
 var result = data.result.result;
 that.show_edit_page(that.entity, result);
 that.notify_success(data);
};

that.entity_adder_dialog_on_add_success = that.on_add_success;

"""

so in child class it would be overriden e.g. by:

that.on_add_success = function(data, text_status, xhr) {
 that.entity_adder_dialog_on_add_success(data, text_status, xhr);
 // .. my new code
};

It follows the pattern as in other code.

Other possible emthod is to implement in parent class
handle_notifications override point and then change calls of
that.notify_success(data); to that.handle_notifications(data, method);
Which could be overridden in child.

Or probably my favorite:
entity_adder_dialog has 'added' event which is raised prior closing the
dialog (in 'add' and 'add and edit'). We could either register new event
handler which would to the stuff. It will need a way to distinguish
buttons. The button name/method could be added as addional param in the
base class:
that.added.notify([data, 'add'], that);

Or a new event could be created if it is important to call it after
dialog is closed.
   that.post_added = IPA.observer();
   that.post_added.notify([data, 'add'], that);

dialog.post_added.attach(function(data, method) {
// do something;
});


Thank you for awesome explanation of how it should be done. I've chosen  
the last solution which you described. I added another parameter to the 
'added' event and I also added init method which allows to register 
listener to 'added' event only once. Edited patch is attached.


Pavel^3
From 6167b883e03a550af6833b94d0187e9a35d6372c Mon Sep 17 00:00:00 2001
From: Pavel Vomacka 
Date: Wed, 30 Mar 2016 10:19:39 +0200
Subject: [PATCH] Add option to show OTP when adding host

Add option to add host dialog which allows to show generated OTP.
This patch also changed the way of informing user about success of adding host
but only when the 'Generate OTP' option is checked. There is a new dialog with
generated OTP.

https://fedorahosted.org/freeipa/ticket/4602
---
 install/ui/src/freeipa/add.js  |  6 ++--
 install/ui/src/freeipa/host.js | 60 ++
 install/ui/test/data/ipa_init.json |  3 ++
 ipalib/plugins/internal.py |  3 ++
 4 files changed, 69 insertions(+), 3 deletions(-)

diff --git a/install/ui/src/freeipa/add.js b/install/ui/src/freeipa/add.js
index 8f24c7733d1614aaf05b544ecfb641ff57f292f2..6221085269b86d5bbc53c9deec182e10491452ca 100644
--- a/install/ui/src/freeipa/add.js
+++ b/install/ui/src/freeipa/add.js
@@ -84,7 +84,7 @@ IPA.entity_adder_dialog = function(spec) {
 that.hide_message();
 that.add(
 function(data, text_status, xhr) {
-that.added.notify([data], that);
+that.added.notify([data, 'add_and_add_another'], that);
 that.show_message(that.get_success_message(data), 'success');
 that.reset();
 that.focus_first_element();
@@ -100,7 +100,7 @@ IPA.entity_adder_dialog = function(spec) {
 that.hide_message();
 that.add(
 function(data, text_status, xhr) {
-that.added.notify([data], that);
+that.added.notify([data, 'add_and_edit'], that);
 that.close();
 var result = data.result.result;
 that.show_edit_page(that.entity, result);
@@ -129,7 +129,7 @@ 

Re: [Freeipa-devel] [PATCH 0099] ipa-nis-manage: add status option

[Petr Spacek]

On 28.4.2016 17:15, Petr Spacek wrote:
> On 28.4.2016 14:52, Abhijeet Kasurde wrote:
>> Hi Petr,
>>
>> On 04/25/2016 08:28 PM, Petr Spacek wrote:
>>> Hello,
>>>
>>> ipa-nis-manage: add status option
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1329275
>>>
>>>
>>>
>> Can you reword the error message here as well ?
>>
>>  if len(args) != 1:
>>  sys.exit("You must specify one action, either enable or disable")
>>
>> Thanks,
>> Abhijeet Kasurde
> 
> Good catch!

Please review this, thanks.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] URI in HBAC - code

[Lukáš Hellebrandt]

On 04/27/2016 03:34 PM, Lukáš Hellebrandt wrote:
> SSSD: https://github.com/lhellebr/sssd/commits/url_in_hbac
> Apache module: https://github.com/lhellebr/mod_hbacauthz_pam
> FreeIPA: http://pastebin.com/X6H9BTwk
> 
> On 04/26/2016 03:56 PM, Petr Spacek wrote:
>> On 26.4.2016 15:16, Jan Pazdziora wrote:
>>> On Tue, Apr 26, 2016 at 02:16:54PM +0200, Petr Spacek wrote:
>>
>> * For backwards compatibility, lack of URI in request means any URI is
>> matched (as described in the design document). Is it a good idea? Any
>> other solution?
>
> For other attributes in HBAC rules, the lack of a value means nothing is
> matched. To match anything, you have to set "${attribute}category" to 
> "all". I
> would prefer if URI matching was consistent with this, if it's possible.

 My understanding is that requests lacking URI parameter should not match 
 any
 HBAC rules with non-empty URI. This will be backwards compatible because 
 old
 clients will simply ignore new rules which cannot be evaluated properly 
 anyway
 (for lack of information in client's request).
>>>
>>> The problem is that old clients will not ack for the new attributes
>>> (they have no idea they should ask for them), so they will only see
>>> parts of the HBAC rules.
>>>
>>> So the question is -- what is the correct way to make sure that old
>>> clients (that would not ask for the new attributes) are not served
>>> any rules that have those new attributes set?
>>>
> BTW what is the reason to split URIs into separate fields? If it's just 
> case
> sensitivity, I would like to point out that you can switch case 
> sensitivity on
> and off in the middle of a Perl regex using "(?i)" and "(?-i)".

 Personally I would rather see host+scheme+port split into separate 
 attributes.
 That would allow reporting like 'give me all rules for FTP' etc. without
 substring magic.

 And yes, I agree with Honza that multiple values should be evaluated as
 logical OR.

 E.g.

 schemes: {http, https, ftp, ftps}
 URI: /home/pspacek
 host: any
 allow: pspacek
 should grant user pspacek access to directory /home/pspacek on any host as
 long as the scheme is http/https/ftp/ftps.
>>>
>>> So you propose cartesian product of the schemes and URI attributes
>>> to be used?
>>
>> Yes.
>>
>>
>> Before we can discuss this further we need to see current LDAP schema and
>> code. Lukas, please share the code with us.
>>
> 
> 

Added a patch for backwards compatibility using different objectClass
for rules containing some of the new attributes:

SSSD: https://github.com/lhellebr/sssd/commits/url_in_hbac
FreeIPA: attached patch file (works together with the previously
submitted patch)

-- 
Lukas Hellebrandt
Associate Quality Engineer
lhell...@redhat.com
From 5306556007a2448a8790f963abd52c6b89233605 Mon Sep 17 00:00:00 2001
From: Lukas Hellebrandt 
Date: Wed, 4 May 2016 18:33:27 +0200
Subject: [PATCH] Use new objectClass for backwards compatibility

---
 ACI.txt | 10 +-
 Makefile|  2 +-
 install/share/60basev2.ldif |  1 +
 ipalib/plugins/hbacrule.py  | 25 +
 4 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/ACI.txt b/ACI.txt
index 39f331264e3d724bae7d47a3bcbc9e42da93bbcd..419b90d2251086bf0b47f994041cc4ac79842214 100644
--- a/ACI.txt
+++ b/ACI.txt
@@ -85,15 +85,15 @@ aci: (targetattr = "businesscategory || cn || createtimestamp || description ||
 dn: cn=groups,cn=accounts,dc=ipa,dc=example
 aci: (targetfilter = "(|(objectclass=ipausergroup)(objectclass=posixgroup))")(version 3.0;acl "permission:System: Remove Groups";allow (delete) groupdn = "ldap:///cn=System: Remove Groups,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=hbac,dc=ipa,dc=example
-aci: (targetfilter = "(objectclass=ipahbacrule)")(version 3.0;acl "permission:System: Add HBAC Rule";allow (add) groupdn = "ldap:///cn=System: Add HBAC Rule,cn=permissions,cn=pbac,dc=ipa,dc=example";)
+aci: (targetfilter = "(|(objectclass=ipahbacrule)(objectclass=ipahbacruleuri))")(version 3.0;acl "permission:System: Add HBAC Rule";allow (add) groupdn = "ldap:///cn=System: Add HBAC Rule,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=hbac,dc=ipa,dc=example
-aci: (targetfilter = "(objectclass=ipahbacrule)")(version 3.0;acl "permission:System: Delete HBAC Rule";allow (delete) groupdn = "ldap:///cn=System: Delete HBAC Rule,cn=permissions,cn=pbac,dc=ipa,dc=example";)
+aci: (targetfilter = "(|(objectclass=ipahbacrule)(objectclass=ipahbacruleuri))")(version 3.0;acl "permission:System: Delete HBAC Rule";allow (delete) groupdn = "ldap:///cn=System: Delete HBAC Rule,cn=permissions,cn=pbac,dc=ipa,dc=example";)
 dn: cn=hbac,dc=ipa,dc=example
-aci: (targetattr = "externalhost || memberhost || memberservice || memberuser")(targetfilter = "(objectclass=ipahbacrule)")(version 3.0;acl 

[Freeipa-devel] [PATCH 0477] upgrade: always start CA

[Martin Basti]

Patch attached.

https://fedorahosted.org/freeipa/ticket/5868

From 9730518ea4b10806fb340008138a72be98b43748 Mon Sep 17 00:00:00 2001
From: Martin Basti 
Date: Thu, 12 May 2016 15:39:30 +0200
Subject: [PATCH] Upgrade: always start CA

Some CA upgrade steps in upgrader requires running CA. We have to always
start CA and wait for running status using http, because systemd may
return false positive result that CA is running even if CA is just
starting and unable to serve.

https://fedorahosted.org/freeipa/ticket/5868
---
 ipaserver/install/server/upgrade.py | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/ipaserver/install/server/upgrade.py b/ipaserver/install/server/upgrade.py
index 38fe2c3e89da55faa30c624983cb8f9c630357b3..6956f51b3ca38ae4daf5775c4d5fb2c8fb34c772 100644
--- a/ipaserver/install/server/upgrade.py
+++ b/ipaserver/install/server/upgrade.py
@@ -1448,6 +1448,7 @@ def upgrade_configuration():
 sub_dict['SUBJECT_BASE'] = subject_base
 
 ca = cainstance.CAInstance(api.env.realm, certs.NSS_DIR)
+ca_running = ca.is_running()
 
 with installutils.stopped_service('pki-tomcatd', 'pki-tomcat'):
 # Dogtag must be stopped to be able to backup CS.cfg config
@@ -1634,6 +1635,11 @@ def upgrade_configuration():
 except ipautil.CalledProcessError as e:
 root_logger.error("Failed to restart %s: %s", ca.service_name, e)
 
+# following upgrade steps require running CA
+# always run ca.start() because we need to wait until CA is really ready
+# by checking status using http
+ca.start('pki-tomcat')
+
 ca_enable_ldap_profile_subsystem(ca)
 
 # This step MUST be done after ca_enable_ldap_profile_subsystem and
@@ -1650,6 +1656,11 @@ def upgrade_configuration():
 elif not ds_running and ds.is_running():
 ds.stop(ds_serverid)
 
+if ca_running and not ca.is_running():
+ca.stop('pki-tomcat')
+elif not ca_running and ca.is_running():
+ca.start('pki-tomcat')
+
 
 def upgrade_check(options):
 try:
-- 
2.5.5

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Provisioning throughput

[Ludwig Krispenz]

On 05/12/2016 02:16 PM, Petr Vobornik wrote:

On 05/10/2016 05:50 PM, thierry bordaz wrote:


On 05/05/2016 03:44 PM, Petr Vobornik wrote:

On 05/04/2016 02:20 PM, thierry bordaz wrote:

Hello,

  I have been doing some tests/measures using
 
https://github.com/freeipa/freeipa-tools/blob/master/create-test-data.py.


  The tool creates a set of typical users/hosts/groups... to
import with a
  ldapadd.

  I wrote down some finding in
 
http://www.freeipa.org/page/V4/Performance_Improvements#Provisioning_throughput_and_DS_plugins.


  I still have to do some cleanup around the performance but the
basic of a
  possible improvement is to do provisioning in several steps
(disabling
  plugins, provisioning, enabling plugin, running fixup tasks).

  Before going further in the design I wanted to share those ideas
and know if
  it raise any concern.

  thanks
  thierry


Hi Thierry,

Thanks for the analysis. Very nice.

Knowing this will help us suggesting workarounds also for old releases.

Couple questions:

Have you tested retrCL disabled with memberOf enabled. It seems that it
would eliminate 550K adds and 0.8M searches. What would be the time
improvement?

Do you know what is the time when memberof is enabled but slapi-nis and
retroCL are disabled?

The culprit of the performance issue is very likely related to SRCH
(internal) triggered by memberof.

If retroCL is disabled and memberof enabled, #SRCH is 13.8M.
If retroCL is disabled, slapi-nis disabled and memberof enabled #SRCH is
14.8
When all of them are enabled the #SRCH is 15M.

You are right if retroCL is disabled the #ADD drops but it has no
significant effect on the duration.

ok, thanks for the analysis


Regarding the duration of the provisioning, values are not really stable
as performance of VM fluctuates. But as soon as memberof is enabled the
provisioning lasts > 4hours where the same provisioning lasts 6mins as
soon as memberof is disabled.

I need to confirm the average time for internal searches but assuming
1ms per SRCH it consumes >90% of the provisioning.



  From the text it was not clear to me, if you find or investigate
possible improvements in memberof plugin which would improve the
performance without stopping and starting DS.

As was discussed at mtg, have you tried if the DS restart is really
necessary?

memberof plugin can be enabled and disabled while the server is running, BUT
to achieve this the "enable-dynamic-plugins" feature has to be turned 
on. And then any enable/disable of a plugin would try to do it 
dynamically an dnot wait for the restart.
And I think not all plugins are able to handle this, TomasB was once 
working on it for IPA plugins, but it was not completed as far as I know


And if it is required, what would be needed to not require restart.

The workaround should be easy to use.


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael 
O'Neill

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0463] Performance: do not download password attributes in host/find-user command

[Rob Crittenden]

Martin Basti wrote:



On 22.04.2016 13:21, David Kupka wrote:

On 22/04/16 10:58, Martin Basti wrote:



On 21.04.2016 09:17, Martin Basti wrote:



On 20.04.2016 16:57, Martin Basti wrote:

https://fedorahosted.org/freeipa/ticket/5281

Patch attached.



selfNACK



Updated patch attached.




Works for me, ACK.


pushed to master:
* fe2ce02a6f7664e377c367e16e9c2e1ad960c9d7 Performace: don't download
password attributes in host/user-find



It occurs to me, won't this break the UI somewhat. Isn't Enrolled one of 
the attributes on the default host page. Won't this show all hosts as 
unenrolled?


rob

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0471] ipactl: advertise option --ignore-service-failure

[Stanislav Laznicka]

ACK

On 05/02/2016 05:27 PM, Martin Basti wrote:



On 02.05.2016 17:19, Petr Vobornik wrote:

On 05/02/2016 04:26 PM, Martin Basti wrote:

https://fedorahosted.org/freeipa/ticket/5820

Patch attached.



Copying the err message 3 times is not very nice. It should be in a
constant otherwise we risk that they will get out of sync in a future.

Updated patch attached.




-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0470] remove unused code in SchemaCache

[Stanislav Laznicka]

ACK, I see no reason for the code to be present there.

On 04/29/2016 04:33 PM, Martin Basti wrote:

Patch attached.




-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH] 0034: webui: Authentication indicators

[Nathaniel McCallum]

On Wed, 2016-05-11 at 13:08 +0200, Pavel Vomacka wrote:
> Hi,
> 
> the patch adds webui part for authentication indicators.
> 
> Ticket: https://fedorahosted.org/freeipa/ticket/5872

The otp option displays as: OTP.
The radius option displays as: Radius.

However, both are acronyms. The capitalization should be consistent.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0470] remove unused code in SchemaCache

[Martin Basti]

On 12.05.2016 09:17, Stanislav Laznicka wrote:

ACK, I see no reason for the code to be present there.

On 04/29/2016 04:33 PM, Martin Basti wrote:

Patch attached.





Pushed to master: 93332bcf4dd0189b7136db7fe4f900fc04171d20

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0471] ipactl: advertise option --ignore-service-failure

[Martin Basti]

On 12.05.2016 10:04, Stanislav Laznicka wrote:

ACK

On 05/02/2016 05:27 PM, Martin Basti wrote:



On 02.05.2016 17:19, Petr Vobornik wrote:

On 05/02/2016 04:26 PM, Martin Basti wrote:

https://fedorahosted.org/freeipa/ticket/5820

Patch attached.



Copying the err message 3 times is not very nice. It should be in a
constant otherwise we risk that they will get out of sync in a future.

Updated patch attached.





Pushed to master: ab2ebf489fa5afb57e5f49a8c025d555f583eb1a

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 0089-0093] Authentication Indicators

[Nathaniel McCallum]

On Fri, 2016-05-06 at 14:44 +0200, Sumit Bose wrote:
> On Wed, May 04, 2016 at 05:33:55PM -0400, Nathaniel McCallum wrote:
> > This series of patches implements authentication indicator
> > insertion,
> > evaluation and management in FreeIPA. Besides these patches, two
> > other
> > patches are needed to round out support.
> > 
> > First, we need a UI patch: https://fedorahosted.org/freeipa/ticket/
> > 5872
> > 
> > Second, we need a SSSD patch to handle the new case where multiple
> > responders are set (when either 1FA or 2FA can be used).
> 
> I've already some initial work done here and will continue with your
> patches.
> 
> > 
> > Please note that the last patch in this series (0093) is untested
> > and
> > simply represents my desire to get these patches off of my hard
> > disk
> > before I take a long weekend. This patch also requires mrogers'
> > patch
> > 0001 (already merged to master).
> > 
> > Also worthy of note is the need for an OID for the authentication
> > control. Hopefully Simo can assign this after we agree that this
> > control method is sufficient. One question I had was whether or not
> > it
> > would be possible to send the control only on UNIX sockets (0089;
> > report_auth_method()).
> > 
> > Please review the approaches taken here. I plan to hit this hard on
> > Monday.
> 
> I'm on a conference next week and currently busy preparing my
> presentation. I will give you feedback in the following week.

Thanks!

The attached patches offer the latest version of the work. The only
major outstanding item that I see is OID assignment (which we can do
just before committing).

I have tested the full stack both for appropriate approvals and denials
across all possible scenarios. In short it works.

The easiest way to test this is as following:

# After Clean Install of FreeIPA
$ kinit admin

# Add a service allowed by either 1FA or 2FA
$ ipa service-add ANY/ipa.example.com
$ ipa-getkeytab -p ANY/ipa.example.com -k /tmp/any.keytab

# Add a service allowed only by 2FA
$ ipa service-add OTP/ipa.example.com --auth-ind=otp
$ ipa-getkeytab -p OTP/ipa.example.com -k /tmp/otp.keytab

# Add the test user
$ ipa user-add test --user-auth-type=otp --user-auth-type=password
$ ipa passwd test
$ kinit test

# Try to get tickets for the services
$ kvno ANY/ipa.example.com # Expected success
$ kvno OTP/ipa.example.com # Expected failure

# Add a token and login with 2FA
$ ipa otptoken-add
$ kinit -T  test # Log in with 2FA

# Try to get tickets for the services
$ kvno ANY/ipa.example.com #
Expected success
$ kvno OTP/ipa.example.com # Expected success
From c9e2b50248493fb5a283cf8c88c8e20c312d6348 Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum 
Date: Wed, 4 May 2016 17:08:45 -0400
Subject: [PATCH 5/5] Enable service authentication indicator management

https://fedorahosted.org/freeipa/ticket/433
---
 API.txt   |  9 ++---
 VERSION   |  4 ++--
 ipalib/plugins/service.py | 10 +-
 3 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/API.txt b/API.txt
index b2aec7313b6b9496179beddb68e4a0f5a09608bf..7bf4cba0d29e89afbfd465f3f30d9c3de7701465 100644
--- a/API.txt
+++ b/API.txt
@@ -3888,7 +3888,7 @@ output: Entry('result', , Gettext('A dictionary representing an LDA
 output: Output('summary', (, ), None)
 output: PrimaryKey('value', None, None)
 command: service_add
-args: 1,11,3
+args: 1,12,3
 arg: Str('krbprincipalname', attribute=True, cli_name='principal', multivalue=False, primary_key=True, required=True)
 option: Str('addattr*', cli_name='addattr', exclude='webui')
 option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
@@ -3896,6 +3896,7 @@ option: Flag('force', autofill=True, default=False)
 option: StrEnum('ipakrbauthzdata', attribute=True, cli_name='pac_type', csv=True, multivalue=True, required=False, values=(u'MS-PAC', u'PAD', u'NONE'))
 option: Bool('ipakrbokasdelegate', attribute=False, cli_name='ok_as_delegate', multivalue=False, required=False)
 option: Bool('ipakrbrequirespreauth', attribute=False, cli_name='requires_pre_auth', multivalue=False, required=False)
+option: StrEnum('krbprincipalauthind', attribute=True, cli_name='auth_ind', multivalue=True, required=False, values=(u'otp', u'radius'))
 option: Flag('no_members', autofill=True, default=False, exclude='webui')
 option: Flag('raw', autofill=True, cli_name='raw', default=False, exclude='webui')
 option: Str('setattr*', cli_name='setattr', exclude='webui')
@@ -3998,10 +3999,11 @@ output: Output('completed', , None)
 output: Output('failed', , None)
 output: Entry('result', , Gettext('A dictionary representing an LDAP entry', domain='ipa', localedir=None))
 command: service_find
-args: 1,11,4
+args: 1,12,4
 arg: Str('criteria?', noextrawhitespace=False)
 option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
 option: StrEnum('ipakrbauthzdata', attribute=True, autofill=False, cli_name='pac_type', csv=True, 

Re: [Freeipa-devel] [PATCH 0096] Batch command: avoid accessing potentially undefined context.principa

[Jan Cholasta]

On 10.5.2016 12:34, Petr Spacek wrote:

On 4.5.2016 15:04, Jan Cholasta wrote:

Hi,

On 22.4.2016 13:28, Petr Spacek wrote:

Hello,

Batch command: avoid accessing potentially undefined context.principal

This might happen when the command is called directly in Python,
e.g. in installers and so on.

Pylint pylint-1.5.5-1.fc24.noarch caught this.

https://fedorahosted.org/freeipa/ticket/5838


LGTM, but please use 'UNKNOWN' as the default value, for consistency with
ipalib.rpcserver code.


Here you are.


Thanks, ACK.

Pushed to:
master: 89cdf6ee1e796e5ba4c302a19da4862e18b99c4a
ipa-4-2: da06be4ba891b1ad86af866fa4d9699bbaa5ab35
ipa-4-3: 2980e7851cba9bacefbc0adfab556634ec5fb6e6

--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0399-0402] Do not log warning about empty zones which are already disabled or unloaded & prepare 9.0 release

[Tomas Hozza]

On 05/09/2016 04:30 PM, Petr Spacek wrote:
> On 9.5.2016 16:25, Petr Spacek wrote:
> > Hello,
> >
> > following patch should cover most misleading warnings produced by new code
> > handling empty zones.
> >
> > If it is okay I will release version 9.0 with it.
> >
> > Please review it ASAP. Thank you very much!
>
> ... and here are patches :-)
>
ACK.

I tested the changes and warning is now logged only if the empty zone is still 
loaded. In case the configuration changes after the empty zone is already 
unloaded, no message is logged. Other than that, the changes look good to me.

Regards,
-- 
Tomas Hozza
Senior Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
UTC+1 (CET)
Red Hat Inc. http://cz.redhat.com

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0399-0402] Do not log warning about empty zones which are already disabled or unloaded & prepare 9.0 release

[Petr Spacek]

On 12.5.2016 13:27, Tomas Hozza wrote:
> On 05/09/2016 04:30 PM, Petr Spacek wrote:
>> On 9.5.2016 16:25, Petr Spacek wrote:
>>> Hello,
>>>
>>> following patch should cover most misleading warnings produced by new code
>>> handling empty zones.
>>>
>>> If it is okay I will release version 9.0 with it.
>>>
>>> Please review it ASAP. Thank you very much!
>>
>> ... and here are patches :-)
>>
> ACK.
> 
> I tested the changes and warning is now logged only if the empty zone is 
> still loaded. In case the configuration changes after the empty zone is 
> already unloaded, no message is logged. Other than that, the changes look 
> good to me.

Thanks, pushed to master:


210b6240d24a1e9dd778a5bd251ba2a3dc9fb5ab Bump NVR to 9.0.
3cd3da4d6de70a392d0ea64da674fbd1b8c39ae5 Update NEWS for upcoming 9.0 release.
64be537656310049ca4769ea05e728187370b415 Document new empty zone handling
mechanism.
4a2ef2eb491596870cf1b7bdc12c3eb2cc0015f5 Do not log warning about empty zones
which are already disabled or unloaded.
3232aa4f35850c5164e7ec0b9cc523e3cf7bdb5d Unload automatic empty zones only if
conflicting forward zone has policy 'only'.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Provisioning throughput

[Petr Vobornik]

On 05/10/2016 05:50 PM, thierry bordaz wrote:
> 
> 
> On 05/05/2016 03:44 PM, Petr Vobornik wrote:
>> On 05/04/2016 02:20 PM, thierry bordaz wrote:
>>> Hello,
>>>
>>>  I have been doing some tests/measures using
>>> 
>>> https://github.com/freeipa/freeipa-tools/blob/master/create-test-data.py.
>>>
>>>  The tool creates a set of typical users/hosts/groups... to
>>> import with a
>>>  ldapadd.
>>>
>>>  I wrote down some finding in
>>> 
>>> http://www.freeipa.org/page/V4/Performance_Improvements#Provisioning_throughput_and_DS_plugins.
>>>
>>>  I still have to do some cleanup around the performance but the
>>> basic of a
>>>  possible improvement is to do provisioning in several steps
>>> (disabling
>>>  plugins, provisioning, enabling plugin, running fixup tasks).
>>>
>>>  Before going further in the design I wanted to share those ideas
>>> and know if
>>>  it raise any concern.
>>>
>>>  thanks
>>>  thierry
>>>
>> Hi Thierry,
>>
>> Thanks for the analysis. Very nice.
>>
>> Knowing this will help us suggesting workarounds also for old releases.
>>
>> Couple questions:
>>
>> Have you tested retrCL disabled with memberOf enabled. It seems that it
>> would eliminate 550K adds and 0.8M searches. What would be the time
>> improvement?
>>
>> Do you know what is the time when memberof is enabled but slapi-nis and
>> retroCL are disabled?
> The culprit of the performance issue is very likely related to SRCH
> (internal) triggered by memberof.
> 
> If retroCL is disabled and memberof enabled, #SRCH is 13.8M.
> If retroCL is disabled, slapi-nis disabled and memberof enabled #SRCH is
> 14.8
> When all of them are enabled the #SRCH is 15M.
> 
> You are right if retroCL is disabled the #ADD drops but it has no
> significant effect on the duration.

ok, thanks for the analysis

> 
> Regarding the duration of the provisioning, values are not really stable
> as performance of VM fluctuates. But as soon as memberof is enabled the
> provisioning lasts > 4hours where the same provisioning lasts 6mins as
> soon as memberof is disabled.
> 
> I need to confirm the average time for internal searches but assuming
> 1ms per SRCH it consumes >90% of the provisioning.
> 
> 
>>
>>  From the text it was not clear to me, if you find or investigate
>> possible improvements in memberof plugin which would improve the
>> performance without stopping and starting DS.
> 

As was discussed at mtg, have you tried if the DS restart is really
necessary?

And if it is required, what would be needed to not require restart.

The workaround should be easy to use.
-- 
Petr Vobornik

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code