Re: [Freeipa-devel] [PATCH] 352 Fix certmonger configuration in installer code

[David Kupka]

On 10/10/2014 08:50 AM, Martin Kosek wrote:

On 10/09/2014 03:56 PM, David Kupka wrote:

On 10/08/2014 01:23 PM, Jan Cholasta wrote:

Dne 8.10.2014 v 12:27 Jan Cholasta napsal(a):

Hi,

the attached patch fixes
.

Honza


Forgot to delete a line in dogtaginstance.py (thanks to David for
noticing). Updated patch attached.



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel



Works for me, ACK.



Thanks, pushed to master.

Just to double check - no parts of the fixes should be applied to 4.1 or
4.0 branches, is that correct?

Martin


I've never seen or been able to reproduce this bug other than on master 
branch. AFAIK, the issue was caused by KRA patches that are only in master.

--
David Kupka

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 352 Fix certmonger configuration in installer code

[Martin Kosek]

On 10/09/2014 03:56 PM, David Kupka wrote:

On 10/08/2014 01:23 PM, Jan Cholasta wrote:

Dne 8.10.2014 v 12:27 Jan Cholasta napsal(a):

Hi,

the attached patch fixes .

Honza


Forgot to delete a line in dogtaginstance.py (thanks to David for
noticing). Updated patch attached.



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel



Works for me, ACK.



Thanks, pushed to master.

Just to double check - no parts of the fixes should be applied to 4.1 or 4.0 
branches, is that correct?


Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0131-0132] Add missing attributes to named.conf

[David Kupka]

On 10/03/2014 12:45 PM, Martin Basti wrote:

Hello!

Patch 131:
https://fedorahosted.org/freeipa/ticket/3801#comment:31

Patch 132:
I modified named.conf in 131, so I change the rest of paths to be
ipaplatform specified.

Patches attached



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel



Hi!
The upgrade processes looks fine to me. And I didn't find any surprise 
in the code. So it's A and C/2 from me. For the rest go to Petr^2.


--
David Kupka

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name

[Nathaniel McCallum]

On Thu, 2014-10-09 at 22:22 +0200, thierry bordaz wrote:
> On 10/09/2014 06:40 PM, Nathaniel McCallum wrote:
> 
> > On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote:
> > > On 10/09/2014 06:27 PM, Nathaniel McCallum wrote:
> > > > On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote:
> > > > > On 10/08/2014 11:46 PM, Nathaniel McCallum wrote:
> > > > > 
> > > > > > The background of this email is this bug:
> > > > > > https://fedorahosted.org/freeipa/ticket/4456
> > > > > > 
> > > > > > Attached are two patches which solve this issue for admin users (not
> > > > > > very helpful, I know). They depend on this fix in 389:
> > > > > > https://fedorahosted.org/389/ticket/47920
> > > > > > 
> > > > > > There are two outstanding issues:
> > > > > > 
> > > > > > 1. 389 does not send the post read control for normal users. The
> > > > > > operation itself succeeds, but no control is sent.
> > > > > > 
> > > > > > The relevant sections from the log are attached. 389 is denying 
> > > > > > access
> > > > > > to the following attributes (* = valid, ! = invalid):
> > > > > > ! objectClass
> > > > > > ! ipatokenOTPalgorithm
> > > > > > ! ipatokenOTPdigits
> > > > > > * ipatokenOTPkey
> > > > > > * ipatokenHOTPcounter
> > > > > > ! ipatokenOwner
> > > > > > ! managedBy
> > > > > > ! ipatokenUniqueID
> > > > > Hello Nathaniel,
> > > > > 
> > > > >  The post read control needs access to the modified entry to
> > > > >  return it.
> > > > >  This access is granted at the condition, the binddn can 
> > > > > access
> > > > >  attributes.
> > > > Agreed and understood.
> > > > 
> > > > >  My understanding is that the target entry is
> > > > >  
> > > > > ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com
> > > > >  and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com".
> > > > Correct.
> > > > 
> > > > >  The only ACI I found that match this target is:
> > > > >  aci: (targetfilter = "(objectClass=ipaToken)")
> > > > >  (targetattrs = "objectclass || description || managedBy || 
> > > > > ipatokenUniqueID || ipatokenDisabled
> > > > >   || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor 
> > > > > || ipatokenModel || ipatokenSerial || ipatokenOwner")
> > > > >  (version 3.0; acl "Users/managers can read basic token 
> > > > > info"; allow (read, search, compare) userattr = 
> > > > > "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";)
> > > > Correct.
> > > > 
> > > > >  Do you know if the target entry has 'ipatokenOwner' or
> > > > >  'managedBy' with the binddn value ?
> > > > Yes, both. So why is access to objectClass (et cetera) being denied?
> > > Good question... I will  try to reproduce
> > Thanks!
> 
> Hello,
> 
> I tried to reproduce and it seems to work on *master*.
> I am using the attached ldif file. 
> The test case is to bind as "cn=active
> guy,cn=accounts,dc=example,dc=com" and to do a modify on
> "cn=active otp,cn=otp,dc=example,dc=com".
> 
> The modify updates the 'description' attribute and do a
> postread (description, cn).
> 
> The write 'description' is allowed by :
> dn: cn=otp,dc=example,dc=com
> aci: (targetfilter =
> "(objectclass=organizationalPerson)")(target =
> "ldap:///c
>  n=*,cn=otp,dc=example,dc=com")(targetattr =
> "objectclass || description || se
>  eAlso")(version 3.0; acl "Active user modify otp
> entry"; allow (write) userdn
>   = "ldap:///cn=active
> guy,cn=accounts,dc=example,dc=com";)
> 
> [09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1.
> Evaluating ALLOW aci(19) " "Active user modify otp
> entry""
> [09/Oct/2014:22:07:56 +0200] NSACLPlugin - conn=2
> op=16 (main): Allow write on entry(cn=active
> otp,cn=otp,dc=example,dc=com).attr(description) to
> cn=active guy,cn=accounts,dc=example,dc=com: allowed
> by aci(19): aciname= "Active user modify otp entry",
> acidn="cn=otp,dc=example,dc=com"
> 
> 
> The postread is allowed by: 
> dn: cn=otp,dc=example,dc=com
> aci: (targetfilter =
> "(objectclass=organizationalPerson)") (targetattr =
> "obje
>  ctclass || description || seeAlso || cn")(version
> 3.0; acl "Active user can r
>  ead his entries"; allow (read, search, compare)
> userattr = "seeAlso#USERDN";)
> 
> [09/Oct/2014:22:07:58 +0200] NSACLPlugin - 1.
> Evaluating ALLOW aci(21) " "Active user can read his
> entries""

Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name

[thierry bordaz]

On 10/09/2014 06:40 PM, Nathaniel McCallum wrote:

On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote:

On 10/09/2014 06:27 PM, Nathaniel McCallum wrote:

On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote:

On 10/08/2014 11:46 PM, Nathaniel McCallum wrote:


The background of this email is this bug:
https://fedorahosted.org/freeipa/ticket/4456

Attached are two patches which solve this issue for admin users (not
very helpful, I know). They depend on this fix in 389:
https://fedorahosted.org/389/ticket/47920

There are two outstanding issues:

1. 389 does not send the post read control for normal users. The
operation itself succeeds, but no control is sent.

The relevant sections from the log are attached. 389 is denying access
to the following attributes (* = valid, ! = invalid):
! objectClass
! ipatokenOTPalgorithm
! ipatokenOTPdigits
* ipatokenOTPkey
* ipatokenHOTPcounter
! ipatokenOwner
! managedBy
! ipatokenUniqueID

Hello Nathaniel,

  The post read control needs access to the modified entry to
  return it.
  This access is granted at the condition, the binddn can access
  attributes.

Agreed and understood.


  My understanding is that the target entry is
  ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com 
and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com".

Correct.


  The only ACI I found that match this target is:
  aci: (targetfilter = "(objectClass=ipaToken)")
  (targetattrs = "objectclass || description || managedBy || 
ipatokenUniqueID || ipatokenDisabled
   || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || 
ipatokenModel || ipatokenSerial || ipatokenOwner")
  (version 3.0; acl "Users/managers can read basic token info"; allow (read, search, 
compare) userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";)

Correct.


  Do you know if the target entry has 'ipatokenOwner' or
  'managedBy' with the binddn value ?

Yes, both. So why is access to objectClass (et cetera) being denied?

Good question... I will  try to reproduce

Thanks!


Hello,

   I tried to reproduce and it seems to work on *master*.
   I am using the attached ldif file.
   The test case is to bind as "cn=active
   guy,cn=accounts,dc=example,dc=com" and to do a modify on "cn=active
   otp,cn=otp,dc=example,dc=com".

   The modify updates the 'description' attribute and do a postread
   (description, cn).

   The write 'description' is allowed by :

   dn: cn=otp,dc=example,dc=com
   aci: (targetfilter =
   "(objectclass=organizationalPerson)")(target = "ldap:///c
 n=*,cn=otp,dc=example,dc=com")(targetattr = "objectclass ||
   description || se
 eAlso")(version 3.0; acl "Active user modify otp entry"; allow
   (write) userdn
  = "ldap:///cn=active guy,cn=accounts,dc=example,dc=com";)

   [09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1. Evaluating ALLOW
   aci(19) " "Active user modify otp entry""
   [09/Oct/2014:22:07:56 +0200] NSACLPlugin - conn=2 op=16 (main):
   Allow write on entry(cn=active
   otp,cn=otp,dc=example,dc=com).attr(description) to cn=active
   guy,cn=accounts,dc=example,dc=com: allowed by aci(19): aciname=
   "Active user modify otp entry", acidn="cn=otp,dc=example,dc=com"



   The postread is allowed by:

   dn: cn=otp,dc=example,dc=com
   aci: (targetfilter = "(objectclass=organizationalPerson)")
   (targetattr = "obje
 ctclass || description || seeAlso || cn")(version 3.0; acl
   "Active user can r
 ead his entries"; allow (read, search, compare) userattr =
   "seeAlso#USERDN";)

   [09/Oct/2014:22:07:58 +0200] NSACLPlugin - 1. Evaluating ALLOW
   aci(21) " "Active user can read his entries""
   [09/Oct/2014:22:07:58 +0200] NSACLPlugin - Found READ ALLOW in cache
   [09/Oct/2014:22:07:58 +0200] NSACLPlugin - conn=2 op=16 (main):
   Allow read on entry(cn=active
   otp,cn=otp,dc=example,dc=com).attr(cn) to cn=active
   guy,cn=accounts,dc=example,dc=com: cached allow by aci(21)


   The postread works if I use USERDN or SELFDN.

   Please let me know the version of 389-ds that you are testing, I
   will try on that branch

   thanks
   thierry




The ACIs allowing access to most of these attributes are here:
https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90

Note that I am able to query the entry just fine (including all the
above invalidly restricted attributes). Hence, I know the ACIs are
working just fine.

Part of the strange thing is that in the post read control request, I
haven't indicated that I want *any* attributes returned (i.e. I want
just the DN). So I'm not sure why it is querying all the attributes. I
would suspect that the proper behavior would be to only check the ACIs
on attributes that will actually be returned.

  It may not querying a

Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name

[Ludwig Krispenz]

On 10/09/2014 06:53 PM, Nathaniel McCallum wrote:

On Thu, 2014-10-09 at 18:38 +0200, Ludwig Krispenz wrote:

On 10/09/2014 06:32 PM, thierry bordaz wrote:

On 10/09/2014 06:27 PM, Nathaniel McCallum wrote:

On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote:

On 10/08/2014 11:46 PM, Nathaniel McCallum wrote:


The background of this email is this bug:
https://fedorahosted.org/freeipa/ticket/4456

Attached are two patches which solve this issue for admin users (not
very helpful, I know). They depend on this fix in 389:
https://fedorahosted.org/389/ticket/47920

There are two outstanding issues:

1. 389 does not send the post read control for normal users. The
operation itself succeeds, but no control is sent.

The relevant sections from the log are attached. 389 is denying access
to the following attributes (* = valid, ! = invalid):
! objectClass
! ipatokenOTPalgorithm
! ipatokenOTPdigits
* ipatokenOTPkey
* ipatokenHOTPcounter
! ipatokenOwner
! managedBy
! ipatokenUniqueID

Hello Nathaniel,

  The post read control needs access to the modified entry to
  return it.
  This access is granted at the condition, the binddn can access
  attributes.

Agreed and understood.


  My understanding is that the target entry is
ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com
and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com".

Correct.


  The only ACI I found that match this target is:
  aci: (targetfilter = "(objectClass=ipaToken)")
  (targetattrs = "objectclass || description || managedBy ||
ipatokenUniqueID || ipatokenDisabled
   || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor
|| ipatokenModel || ipatokenSerial || ipatokenOwner")
  (version 3.0; acl "Users/managers can read basic token
info"; allow (read, search, compare) userattr =
"ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";)

Correct.


  Do you know if the target entry has 'ipatokenOwner' or
  'managedBy' with the binddn value ?

Yes, both. So why is access to objectClass (et cetera) being denied?

Good question...

+1
could you post the full aci logging not only the summary for the access
to the attributes ?

Attached.
this doesn't look like full acl logging, did you set errorlog-level to 
include 128 ?


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name

[Nathaniel McCallum]

On Thu, 2014-10-09 at 18:38 +0200, Ludwig Krispenz wrote:
> On 10/09/2014 06:32 PM, thierry bordaz wrote:
> > On 10/09/2014 06:27 PM, Nathaniel McCallum wrote:
> >> On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote:
> >>> On 10/08/2014 11:46 PM, Nathaniel McCallum wrote:
> >>>
>  The background of this email is this bug:
>  https://fedorahosted.org/freeipa/ticket/4456
> 
>  Attached are two patches which solve this issue for admin users (not
>  very helpful, I know). They depend on this fix in 389:
>  https://fedorahosted.org/389/ticket/47920
> 
>  There are two outstanding issues:
> 
>  1. 389 does not send the post read control for normal users. The
>  operation itself succeeds, but no control is sent.
> 
>  The relevant sections from the log are attached. 389 is denying access
>  to the following attributes (* = valid, ! = invalid):
>  ! objectClass
>  ! ipatokenOTPalgorithm
>  ! ipatokenOTPdigits
>  * ipatokenOTPkey
>  * ipatokenHOTPcounter
>  ! ipatokenOwner
>  ! managedBy
>  ! ipatokenUniqueID
> >>> Hello Nathaniel,
> >>>
> >>>  The post read control needs access to the modified entry to
> >>>  return it.
> >>>  This access is granted at the condition, the binddn can access
> >>>  attributes.
> >> Agreed and understood.
> >>
> >>>  My understanding is that the target entry is
> >>> ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com
> >>>  
> >>> and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com".
> >> Correct.
> >>
> >>>  The only ACI I found that match this target is:
> >>>  aci: (targetfilter = "(objectClass=ipaToken)")
> >>>  (targetattrs = "objectclass || description || managedBy || 
> >>> ipatokenUniqueID || ipatokenDisabled
> >>>   || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor 
> >>> || ipatokenModel || ipatokenSerial || ipatokenOwner")
> >>>  (version 3.0; acl "Users/managers can read basic token 
> >>> info"; allow (read, search, compare) userattr = 
> >>> "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";)
> >> Correct.
> >>
> >>>  Do you know if the target entry has 'ipatokenOwner' or
> >>>  'managedBy' with the binddn value ?
> >> Yes, both. So why is access to objectClass (et cetera) being denied?
> > Good question... 
> +1
> could you post the full aci logging not only the summary for the access 
> to the attributes ?

Attached.
[08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from 
"cn=anonymous-limits,cn=etc,dc=example,dc=com" for 
"(|(objectclass=*)(objectclass=ldapsubentry))" with scope 0 (base)
[08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from 
"uid=otp,cn=users,cn=accounts,dc=example,dc=com" for 
"(|(objectclass=*)(objectclass=ldapsubentry))" with scope 0 (base)
[08/Oct/2014:16:54:39 -0400] - cos_cache_vattr_get: failed to get class of 
service reference
[08/Oct/2014:16:54:39 -0400] - cos_cache_vattr_get: failed to get class of 
service reference
[08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from 
"cn=global_policy,cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com" for 
"(|(objectclass=*)(objectclass=ldapsubentry))" with scope 0 (base)
[08/Oct/2014:16:54:39 -0400] ipa-lockout-plugin - preop returning 0: success
 
[08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from 
"uid=otp,cn=users,cn=accounts,dc=example,dc=com" for 
"(|(objectclass=*)(objectclass=ldapsubentry))" with scope 0 (base)
[08/Oct/2014:16:54:39 -0400] ipa-pwd-extop - Attempting OTP authentication for 
'uid=otp,cn=users,cn=accounts,dc=example,dc=com'.
[08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from 
"dc=example,dc=com" for 
"(&(|(objectClass=ipaTokenTOTP)(objectClass=ipaTokenHOTP))(ipatokenOwner=uid=otp,cn=users,cn=accounts,dc=example,dc=com)(|(ipatokenNotBefore<=20141008205439Z)(!(ipatokenNotBefore=*)))(|(ipatokenNotAfter>=20141008205439Z)(!(ipatokenNotAfter=*)))(|(ipatokenDisabled=FALSE)(!(ipatokenDisabled=*"
 with scope 2 (sub)
[08/Oct/2014:16:54:39 -0400] ipa-pwd-extop - kerberos key already present in 
user entry: uid=otp,cn=users,cn=accounts,dc=example,dc=com
[08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from 
"uid=otp,cn=users,cn=accounts,dc=example,dc=com" for 
"(|(objectclass=*)(objectclass=ldapsubentry))" with scope 0 (base)
[08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from 
"uid=otp,cn=users,cn=accounts,dc=example,dc=com" for 
"(|(objectclass=*)(objectclass=ldapsubentry))" with scope 0 (base)
[08/Oct/2014:16:54:39 -0400] schema-compat-plugin - searching from 
"cn=anonymous-limits,cn=etc,dc=example,dc=com" for 
"(|(objectclass=*)(objectclass=ldapsubentry))" with scope 0 (base)
[08/Oct/2014:16:54:39 -0400] - cos_cache_vattr_get: failed to get class of 
service reference
[08/Oct/2014:16:54:39 -0400] - cos_cache_vattr_get: failed to get class of 
service refer

Re: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin

[thierry bordaz]

On 10/09/2014 05:51 PM, Nathaniel McCallum wrote:

On Thu, 2014-10-09 at 11:44 +0200, thierry bordaz wrote:

On 10/09/2014 12:15 AM, Nathaniel McCallum wrote:


On Wed, 2014-10-08 at 17:19 -0400, Simo Sorce wrote:

On Wed, 08 Oct 2014 15:53:39 -0400
Nathaniel McCallum  wrote:


As I understand my code, all servers will have csnD. Some servers will
have valueB and others will have valueD, but valueB == valueD.

We *never* discard a CSN. We only discard the counter/watermark mods
in the replication operation.

What Thierry is saying is that the individual attributes in the entry
have associate the last CSN that modified them. Because you remove the
mods when ValueD == ValueB the counter attribute will not have the
associated CSN changed. But it doesn't really matter because the plugin
will always keep things consistent.

Attached is a new version. It removes this optimization. If server X has
valueB/csnB and receives valueD/csnD and valueB == valueD, the
replication will be applied without any modification. However, if valueB

valueD and csnD > csnB, the counter mods will still be stripped.

It also collapses the error check from betxnpre to bepre now that we
have a fix for https://fedorahosted.org/389/ticket/47919 committed. The
betxnpre functions are completely removed. Also, a dependency on 389
1.3.3.4 (not yet released) is added.

Nathaniel

Hello Nathaniel,

 For me the code is fine. Ack.

New attached patch.


 I have two minor comments:
   * in preop_mod, when a direct update moves the counter
 backward you send UNWILLING to perform with a message.
 The message is allocated with slapi_ch_smprintf, you
 may free it with slapi_ch_free_string (rather than
 'free').

Fixed.


   * About this message, for example when you have these
 MODS (I admit they make no sens):
 
 changetype: modify

 ipatokenHOTPcounter: MOD_DELETE
 -
 ipatokenHOTPcounter: MOD_INCREMENT
 
 The returned message will be "Will not decrement

 ipatokenHOTPcounter", because 'simulate' will return
 'COUNTER_UNSET+1'.
 Is it the message you expected ?

I changed the logic in simulate(). Please review it.

Nathaniel


Hello Nathaniel,


   The patch is ok for me. Ack.

   Thank you
   thierry

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name

[Nathaniel McCallum]

On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote:
> On 10/09/2014 06:27 PM, Nathaniel McCallum wrote:
> > On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote:
> >> On 10/08/2014 11:46 PM, Nathaniel McCallum wrote:
> >>
> >>> The background of this email is this bug:
> >>> https://fedorahosted.org/freeipa/ticket/4456
> >>>
> >>> Attached are two patches which solve this issue for admin users (not
> >>> very helpful, I know). They depend on this fix in 389:
> >>> https://fedorahosted.org/389/ticket/47920
> >>>
> >>> There are two outstanding issues:
> >>>
> >>> 1. 389 does not send the post read control for normal users. The
> >>> operation itself succeeds, but no control is sent.
> >>>
> >>> The relevant sections from the log are attached. 389 is denying access
> >>> to the following attributes (* = valid, ! = invalid):
> >>> ! objectClass
> >>> ! ipatokenOTPalgorithm
> >>> ! ipatokenOTPdigits
> >>> * ipatokenOTPkey
> >>> * ipatokenHOTPcounter
> >>> ! ipatokenOwner
> >>> ! managedBy
> >>> ! ipatokenUniqueID
> >> Hello Nathaniel,
> >>
> >>  The post read control needs access to the modified entry to
> >>  return it.
> >>  This access is granted at the condition, the binddn can access
> >>  attributes.
> > Agreed and understood.
> >
> >>  My understanding is that the target entry is
> >>  
> >> ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com
> >>  and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com".
> > Correct.
> >
> >>  The only ACI I found that match this target is:
> >>  aci: (targetfilter = "(objectClass=ipaToken)")
> >>  (targetattrs = "objectclass || description || managedBy || 
> >> ipatokenUniqueID || ipatokenDisabled
> >>   || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || 
> >> ipatokenModel || ipatokenSerial || ipatokenOwner")
> >>  (version 3.0; acl "Users/managers can read basic token info"; 
> >> allow (read, search, compare) userattr = "ipatokenOwner#USERDN" or 
> >> userattr = "managedBy#USERDN";)
> > Correct.
> >
> >>  Do you know if the target entry has 'ipatokenOwner' or
> >>  'managedBy' with the binddn value ?
> > Yes, both. So why is access to objectClass (et cetera) being denied?
> Good question... I will  try to reproduce

Thanks!

> >>> The ACIs allowing access to most of these attributes are here:
> >>> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90
> >>>
> >>> Note that I am able to query the entry just fine (including all the
> >>> above invalidly restricted attributes). Hence, I know the ACIs are
> >>> working just fine.
> >>>
> >>> Part of the strange thing is that in the post read control request, I
> >>> haven't indicated that I want *any* attributes returned (i.e. I want
> >>> just the DN). So I'm not sure why it is querying all the attributes. I
> >>> would suspect that the proper behavior would be to only check the ACIs
> >>> on attributes that will actually be returned.
> >>  It may not querying all attributes, but just search the first
> >>  one it can read.
> >>  As it finds none of them you get the message for all
> >>  attributes.
> > Right, but why iterate through all possible attributes? It should only
> > iterate through the attributes requested. Whether the user can read a
> > non-requested attribute or not is irrelevant because the attribute was
> > not requested.
> I think it is iterating from the attributes in the entry. Searching the 
> first one that the authenticated subject is allowed to read.

I agree. The question is: why?

Nathaniel

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name

[Ludwig Krispenz]

On 10/09/2014 06:32 PM, thierry bordaz wrote:

On 10/09/2014 06:27 PM, Nathaniel McCallum wrote:

On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote:

On 10/08/2014 11:46 PM, Nathaniel McCallum wrote:


The background of this email is this bug:
https://fedorahosted.org/freeipa/ticket/4456

Attached are two patches which solve this issue for admin users (not
very helpful, I know). They depend on this fix in 389:
https://fedorahosted.org/389/ticket/47920

There are two outstanding issues:

1. 389 does not send the post read control for normal users. The
operation itself succeeds, but no control is sent.

The relevant sections from the log are attached. 389 is denying access
to the following attributes (* = valid, ! = invalid):
! objectClass
! ipatokenOTPalgorithm
! ipatokenOTPdigits
* ipatokenOTPkey
* ipatokenHOTPcounter
! ipatokenOwner
! managedBy
! ipatokenUniqueID

Hello Nathaniel,

 The post read control needs access to the modified entry to
 return it.
 This access is granted at the condition, the binddn can access
 attributes.

Agreed and understood.


 My understanding is that the target entry is
ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com 
and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com".

Correct.


 The only ACI I found that match this target is:
 aci: (targetfilter = "(objectClass=ipaToken)")
 (targetattrs = "objectclass || description || managedBy || 
ipatokenUniqueID || ipatokenDisabled
  || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor 
|| ipatokenModel || ipatokenSerial || ipatokenOwner")
 (version 3.0; acl "Users/managers can read basic token 
info"; allow (read, search, compare) userattr = 
"ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";)

Correct.


 Do you know if the target entry has 'ipatokenOwner' or
 'managedBy' with the binddn value ?

Yes, both. So why is access to objectClass (et cetera) being denied?
Good question... 

+1
could you post the full aci logging not only the summary for the access 
to the attributes ?

I will  try to reproduce



The ACIs allowing access to most of these attributes are here:
https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 



Note that I am able to query the entry just fine (including all the
above invalidly restricted attributes). Hence, I know the ACIs are
working just fine.

Part of the strange thing is that in the post read control request, I
haven't indicated that I want *any* attributes returned (i.e. I want
just the DN). So I'm not sure why it is querying all the attributes. I
would suspect that the proper behavior would be to only check the ACIs
on attributes that will actually be returned.

 It may not querying all attributes, but just search the first
 one it can read.
 As it finds none of them you get the message for all
 attributes.

Right, but why iterate through all possible attributes? It should only
iterate through the attributes requested. Whether the user can read a
non-requested attribute or not is irrelevant because the attribute was
not requested.
I think it is iterating from the attributes in the entry. Searching 
the first one that the authenticated subject is allowed to read.


thanks
thierry



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name

[thierry bordaz]

On 10/09/2014 06:27 PM, Nathaniel McCallum wrote:

On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote:

On 10/08/2014 11:46 PM, Nathaniel McCallum wrote:


The background of this email is this bug:
https://fedorahosted.org/freeipa/ticket/4456

Attached are two patches which solve this issue for admin users (not
very helpful, I know). They depend on this fix in 389:
https://fedorahosted.org/389/ticket/47920

There are two outstanding issues:

1. 389 does not send the post read control for normal users. The
operation itself succeeds, but no control is sent.

The relevant sections from the log are attached. 389 is denying access
to the following attributes (* = valid, ! = invalid):
! objectClass
! ipatokenOTPalgorithm
! ipatokenOTPdigits
* ipatokenOTPkey
* ipatokenHOTPcounter
! ipatokenOwner
! managedBy
! ipatokenUniqueID

Hello Nathaniel,

 The post read control needs access to the modified entry to
 return it.
 This access is granted at the condition, the binddn can access
 attributes.

Agreed and understood.


 My understanding is that the target entry is
 ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com 
and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com".

Correct.


 The only ACI I found that match this target is:
 aci: (targetfilter = "(objectClass=ipaToken)")
 (targetattrs = "objectclass || description || managedBy || 
ipatokenUniqueID || ipatokenDisabled
  || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || 
ipatokenModel || ipatokenSerial || ipatokenOwner")
 (version 3.0; acl "Users/managers can read basic token info"; allow (read, search, 
compare) userattr = "ipatokenOwner#USERDN" or userattr = "managedBy#USERDN";)

Correct.


 Do you know if the target entry has 'ipatokenOwner' or
 'managedBy' with the binddn value ?

Yes, both. So why is access to objectClass (et cetera) being denied?

Good question... I will  try to reproduce



The ACIs allowing access to most of these attributes are here:
https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90

Note that I am able to query the entry just fine (including all the
above invalidly restricted attributes). Hence, I know the ACIs are
working just fine.

Part of the strange thing is that in the post read control request, I
haven't indicated that I want *any* attributes returned (i.e. I want
just the DN). So I'm not sure why it is querying all the attributes. I
would suspect that the proper behavior would be to only check the ACIs
on attributes that will actually be returned.

 It may not querying all attributes, but just search the first
 one it can read.
 As it finds none of them you get the message for all
 attributes.

Right, but why iterate through all possible attributes? It should only
iterate through the attributes requested. Whether the user can read a
non-requested attribute or not is irrelevant because the attribute was
not requested.
I think it is iterating from the attributes in the entry. Searching the 
first one that the authenticated subject is allowed to read.


thanks
thierry

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name

[Nathaniel McCallum]

On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote:
> On 10/08/2014 11:46 PM, Nathaniel McCallum wrote:
> 
> > The background of this email is this bug:
> > https://fedorahosted.org/freeipa/ticket/4456
> > 
> > Attached are two patches which solve this issue for admin users (not
> > very helpful, I know). They depend on this fix in 389:
> > https://fedorahosted.org/389/ticket/47920
> > 
> > There are two outstanding issues:
> > 
> > 1. 389 does not send the post read control for normal users. The
> > operation itself succeeds, but no control is sent.
> > 
> > The relevant sections from the log are attached. 389 is denying access
> > to the following attributes (* = valid, ! = invalid):
> > ! objectClass
> > ! ipatokenOTPalgorithm
> > ! ipatokenOTPdigits
> > * ipatokenOTPkey
> > * ipatokenHOTPcounter
> > ! ipatokenOwner
> > ! managedBy
> > ! ipatokenUniqueID
> Hello Nathaniel,
> 
> The post read control needs access to the modified entry to
> return it.
> This access is granted at the condition, the binddn can access
> attributes.

Agreed and understood.

> My understanding is that the target entry is
> 
> ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com
>  and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com".

Correct.

> The only ACI I found that match this target is:
> aci: (targetfilter = "(objectClass=ipaToken)")
> (targetattrs = "objectclass || description || managedBy || 
> ipatokenUniqueID || ipatokenDisabled 
>  || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || 
> ipatokenModel || ipatokenSerial || ipatokenOwner")
> (version 3.0; acl "Users/managers can read basic token info"; allow 
> (read, search, compare) userattr = "ipatokenOwner#USERDN" or userattr = 
> "managedBy#USERDN";)

Correct.

> Do you know if the target entry has 'ipatokenOwner' or
> 'managedBy' with the binddn value ?

Yes, both. So why is access to objectClass (et cetera) being denied?

> > The ACIs allowing access to most of these attributes are here:
> > https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90
> > 
> > Note that I am able to query the entry just fine (including all the
> > above invalidly restricted attributes). Hence, I know the ACIs are
> > working just fine.
> > 
> > Part of the strange thing is that in the post read control request, I
> > haven't indicated that I want *any* attributes returned (i.e. I want
> > just the DN). So I'm not sure why it is querying all the attributes. I
> > would suspect that the proper behavior would be to only check the ACIs
> > on attributes that will actually be returned.
> It may not querying all attributes, but just search the first
> one it can read.
> As it finds none of them you get the message for all
> attributes.

Right, but why iterate through all possible attributes? It should only
iterate through the attributes requested. Whether the user can read a
non-requested attribute or not is irrelevant because the attribute was
not requested.

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name

[Nathaniel McCallum]

On Thu, 2014-10-09 at 18:01 +0200, Ludwig Krispenz wrote:
> On 10/09/2014 05:51 PM, Nathaniel McCallum wrote:
> > On Thu, 2014-10-09 at 16:33 +0200, Ludwig Krispenz wrote:
> >> On 10/09/2014 04:27 PM, Simo Sorce wrote:
> >>> On Thu, 09 Oct 2014 16:06:06 +0200
> >>> Ludwig Krispenz  wrote:
> >>>
>  On 10/09/2014 03:13 PM, Simo Sorce wrote:
> > On Wed, 08 Oct 2014 17:46:01 -0400
> > Nathaniel McCallum  wrote:
> >
> >> The background of this email is this bug:
> >> https://fedorahosted.org/freeipa/ticket/4456
> >>
> >> Attached are two patches which solve this issue for admin users
> >> (not very helpful, I know). They depend on this fix in 389:
> >> https://fedorahosted.org/389/ticket/47920
> >>
> >> There are two outstanding issues:
> >>
> >> 1. 389 does not send the post read control for normal users. The
> >> operation itself succeeds, but no control is sent.
> >>
> >> The relevant sections from the log are attached. 389 is denying
> >> access to the following attributes (* = valid, ! = invalid):
> >> ! objectClass
> >> ! ipatokenOTPalgorithm
> >> ! ipatokenOTPdigits
> >> * ipatokenOTPkey
> >> * ipatokenHOTPcounter
> >> ! ipatokenOwner
> >> ! managedBy
> >> ! ipatokenUniqueID
> >>
> >> The ACIs allowing access to most of these attributes are here:
> >> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90
> >>
> >> Note that I am able to query the entry just fine (including all the
> >> above invalidly restricted attributes). Hence, I know the ACIs are
> >> working just fine.
> >>
> >> Part of the strange thing is that in the post read control
> >> request, I haven't indicated that I want *any* attributes returned
> >> (i.e. I want just the DN). So I'm not sure why it is querying all
> >> the attributes. I would suspect that the proper behavior would be
> >> to only check the ACIs on attributes that will actually be
> >> returned.
> > Can you show an example ldif ?
> > I wonder if you are setting the owner ?
> > This is the ldif I used:
> > dn: ipatokenuniqueid=autogenerate,cn=otp,dc=example,dc=com
> > changetype: add
> > objectClass: top
> > objectClass: ipaToken
> > objectClass: ipaTokenHOTP
> > ipatokenUniqueID: autogenerate
> > ipatokenOTPalgorithm: sha1
> > ipatokenOTPdigits: 6
> > ipatokenOTPkey: 
> > ipatokenHOTPcounter: 0
> > ipatokenOwner: uid=otp,cn=users,cn=accounts,dc=example,dc=com
> > managedBy: uid=otp,cn=users,cn=accounts,dc=example,dc=com
> >
> >> 2. The second patch (0002) modifies the ACI for normal user token
> >> addition from this:
> >>
> >> aci: (target =
> >> "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX";)(targetfilter =
> >> "(objectClass=ipaToken)")(version 3.0; acl "Users can create
> >> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN"
> >> and userattr = "managedBy#SELFDN";)
> >>
> >> To this:
> >>
> >> aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp,
> >> $SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl
> >> "Users can create self-managed tokens"; allow (add) userattr =
> >> "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";)
> >>
> >> The idea is to allow users to create tokens which will be expanded
> >> by the UUID plugin. Unfortunately, after the UUID is expanded, the
> >> ACIs are checked. Since the expanded UUID no longer matches the
> >> ACI, the addition is denied. Is this truly the correct behavior? I
> >> would think that the ACIs would be checked before the UUID plugin,
> >> not after.
> > I would expect the same, can someone on the DS team comment ?
>  acis are always applied before the entry is sent to the client. the
>  control is added when the result is sent and for the postop control
>  it gets the POST_OP entry and checks read access to teh entry
> >>> So you think the whole add was denied because the post-read couldn't
> >>> read back the entry ?
> >> as far as I understood Nathaniel, the add succeeded, only the control
> >> was not returned
> >>> Then fixing the read-related issue is all we need ?
> >> you need an aci allowing to read the postop entry
> > No. Issue #2 is unrelated to issue #1. In issue #2, the add itself
> > fails.
> is this because of the change from tokenuiqieid=* to 
> tokenuniqueid=autogenerate in the aci?

Yes.

>  why not stick to*

Because all of this work is done precisely to change from * to
autogenerate. The goal is to make it so that ordinary users can only
create autogenerated token IDs while admins can specify their own custom
token IDs.

Nathaniel

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name

[Ludwig Krispenz]

On 10/09/2014 05:51 PM, Nathaniel McCallum wrote:

On Thu, 2014-10-09 at 16:33 +0200, Ludwig Krispenz wrote:

On 10/09/2014 04:27 PM, Simo Sorce wrote:

On Thu, 09 Oct 2014 16:06:06 +0200
Ludwig Krispenz  wrote:


On 10/09/2014 03:13 PM, Simo Sorce wrote:

On Wed, 08 Oct 2014 17:46:01 -0400
Nathaniel McCallum  wrote:


The background of this email is this bug:
https://fedorahosted.org/freeipa/ticket/4456

Attached are two patches which solve this issue for admin users
(not very helpful, I know). They depend on this fix in 389:
https://fedorahosted.org/389/ticket/47920

There are two outstanding issues:

1. 389 does not send the post read control for normal users. The
operation itself succeeds, but no control is sent.

The relevant sections from the log are attached. 389 is denying
access to the following attributes (* = valid, ! = invalid):
! objectClass
! ipatokenOTPalgorithm
! ipatokenOTPdigits
* ipatokenOTPkey
* ipatokenHOTPcounter
! ipatokenOwner
! managedBy
! ipatokenUniqueID

The ACIs allowing access to most of these attributes are here:
https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90

Note that I am able to query the entry just fine (including all the
above invalidly restricted attributes). Hence, I know the ACIs are
working just fine.

Part of the strange thing is that in the post read control
request, I haven't indicated that I want *any* attributes returned
(i.e. I want just the DN). So I'm not sure why it is querying all
the attributes. I would suspect that the proper behavior would be
to only check the ACIs on attributes that will actually be
returned.

Can you show an example ldif ?
I wonder if you are setting the owner ?

This is the ldif I used:
dn: ipatokenuniqueid=autogenerate,cn=otp,dc=example,dc=com
changetype: add
objectClass: top
objectClass: ipaToken
objectClass: ipaTokenHOTP
ipatokenUniqueID: autogenerate
ipatokenOTPalgorithm: sha1
ipatokenOTPdigits: 6
ipatokenOTPkey: 
ipatokenHOTPcounter: 0
ipatokenOwner: uid=otp,cn=users,cn=accounts,dc=example,dc=com
managedBy: uid=otp,cn=users,cn=accounts,dc=example,dc=com


2. The second patch (0002) modifies the ACI for normal user token
addition from this:

aci: (target =
"ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX";)(targetfilter =
"(objectClass=ipaToken)")(version 3.0; acl "Users can create
self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN"
and userattr = "managedBy#SELFDN";)

To this:

aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp,
$SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl
"Users can create self-managed tokens"; allow (add) userattr =
"ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";)

The idea is to allow users to create tokens which will be expanded
by the UUID plugin. Unfortunately, after the UUID is expanded, the
ACIs are checked. Since the expanded UUID no longer matches the
ACI, the addition is denied. Is this truly the correct behavior? I
would think that the ACIs would be checked before the UUID plugin,
not after.

I would expect the same, can someone on the DS team comment ?

acis are always applied before the entry is sent to the client. the
control is added when the result is sent and for the postop control
it gets the POST_OP entry and checks read access to teh entry

So you think the whole add was denied because the post-read couldn't
read back the entry ?

as far as I understood Nathaniel, the add succeeded, only the control
was not returned

Then fixing the read-related issue is all we need ?

you need an aci allowing to read the postop entry

No. Issue #2 is unrelated to issue #1. In issue #2, the add itself
fails.
is this because of the change from tokenuiqieid=* to 
tokenuniqueid=autogenerate in the aci, why not stick to*




___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin

[Nathaniel McCallum]

On Thu, 2014-10-09 at 11:44 +0200, thierry bordaz wrote:
> On 10/09/2014 12:15 AM, Nathaniel McCallum wrote:
> 
> > On Wed, 2014-10-08 at 17:19 -0400, Simo Sorce wrote:
> > > On Wed, 08 Oct 2014 15:53:39 -0400
> > > Nathaniel McCallum  wrote:
> > > 
> > > > As I understand my code, all servers will have csnD. Some servers will
> > > > have valueB and others will have valueD, but valueB == valueD.
> > > > 
> > > > We *never* discard a CSN. We only discard the counter/watermark mods
> > > > in the replication operation.
> > > What Thierry is saying is that the individual attributes in the entry
> > > have associate the last CSN that modified them. Because you remove the
> > > mods when ValueD == ValueB the counter attribute will not have the
> > > associated CSN changed. But it doesn't really matter because the plugin
> > > will always keep things consistent.
> > Attached is a new version. It removes this optimization. If server X has
> > valueB/csnB and receives valueD/csnD and valueB == valueD, the
> > replication will be applied without any modification. However, if valueB
> > > valueD and csnD > csnB, the counter mods will still be stripped.
> > It also collapses the error check from betxnpre to bepre now that we
> > have a fix for https://fedorahosted.org/389/ticket/47919 committed. The
> > betxnpre functions are completely removed. Also, a dependency on 389
> > 1.3.3.4 (not yet released) is added.
> > 
> > Nathaniel
> Hello Nathaniel,
> 
> For me the code is fine. Ack.

New attached patch.

> I have two minor comments:
>   * in preop_mod, when a direct update moves the counter
> backward you send UNWILLING to perform with a message.
> The message is allocated with slapi_ch_smprintf, you
> may free it with slapi_ch_free_string (rather than
> 'free').

Fixed.

>   * About this message, for example when you have these
> MODS (I admit they make no sens):
> 
> changetype: modify
> ipatokenHOTPcounter: MOD_DELETE
> -
> ipatokenHOTPcounter: MOD_INCREMENT
> 
> The returned message will be "Will not decrement
> ipatokenHOTPcounter", because 'simulate' will return
> 'COUNTER_UNSET+1'.
> Is it the message you expected ?

I changed the logic in simulate(). Please review it.

Nathaniel

From 2356ad22f009f8a99b1ce8801ee1506ce9433a1d Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum 
Date: Wed, 10 Sep 2014 17:31:37 -0400
Subject: [PATCH] Create ipa-otp-counter 389DS plugin

This plugin ensures that all counter/watermark operations are atomic
and never decrement. Also, deletion is not permitted.

Because this plugin also ensures internal operations behave properly,
this also gives ipa-pwd-extop the appropriate behavior for OTP
authentication.

https://fedorahosted.org/freeipa/ticket/4493
https://fedorahosted.org/freeipa/ticket/4494
---
 daemons/configure.ac   |   1 +
 daemons/ipa-slapi-plugins/Makefile.am  |   1 +
 .../ipa-slapi-plugins/ipa-otp-counter/Makefile.am  |  25 ++
 daemons/ipa-slapi-plugins/ipa-otp-counter/berval.c |  96 +
 daemons/ipa-slapi-plugins/ipa-otp-counter/berval.h |  66 +++
 .../ipa-otp-counter/ipa-otp-counter.sym|   1 +
 .../ipa-otp-counter/ipa_otp_counter.c  | 454 +
 .../ipa-slapi-plugins/ipa-otp-counter/ldapmod.c| 110 +
 .../ipa-slapi-plugins/ipa-otp-counter/ldapmod.h|  54 +++
 .../ipa-otp-counter/otp-counter-conf.ldif  |  15 +
 freeipa.spec.in|   8 +-
 ipaserver/install/dsinstance.py|   4 +
 12 files changed, 832 insertions(+), 3 deletions(-)
 create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-counter/Makefile.am
 create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-counter/berval.c
 create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-counter/berval.h
 create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-counter/ipa-otp-counter.sym
 create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-counter/ipa_otp_counter.c
 create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-counter/ldapmod.c
 create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-counter/ldapmod.h
 create mode 100644 daemons/ipa-slapi-plugins/ipa-otp-counter/otp-counter-conf.ldif

diff --git a/daemons/configure.ac b/daemons/configure.ac
index b4507a6d972f854331925e72869898576bdfd76f..bfcdeadcd1dc73762d8c773ee50210d9bdb91e92 100644
--- a/daemons/configure.ac
+++ b/daemons/configure.ac
@@ -314,6 +314,7 @@ AC_CONFIG_FILES([
 ipa-slapi-plugins/ipa-dns/Makefile
 ipa-slapi-plugins/ipa-enrollment/Makefile
 ipa-slapi-plugins/ipa-lockout/Makefile
+ipa-slapi-plugins/ipa-otp-counter/Makefile
 ipa-slapi-plugins/ipa-otp-lasttoken/Makefile
 ipa-slapi-plugins/ipa-pwd-extop/Makefile
 ipa-sl

Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name

[Nathaniel McCallum]

On Thu, 2014-10-09 at 16:33 +0200, Ludwig Krispenz wrote:
> On 10/09/2014 04:27 PM, Simo Sorce wrote:
> > On Thu, 09 Oct 2014 16:06:06 +0200
> > Ludwig Krispenz  wrote:
> >
> >> On 10/09/2014 03:13 PM, Simo Sorce wrote:
> >>> On Wed, 08 Oct 2014 17:46:01 -0400
> >>> Nathaniel McCallum  wrote:
> >>>
>  The background of this email is this bug:
>  https://fedorahosted.org/freeipa/ticket/4456
> 
>  Attached are two patches which solve this issue for admin users
>  (not very helpful, I know). They depend on this fix in 389:
>  https://fedorahosted.org/389/ticket/47920
> 
>  There are two outstanding issues:
> 
>  1. 389 does not send the post read control for normal users. The
>  operation itself succeeds, but no control is sent.
> 
>  The relevant sections from the log are attached. 389 is denying
>  access to the following attributes (* = valid, ! = invalid):
>  ! objectClass
>  ! ipatokenOTPalgorithm
>  ! ipatokenOTPdigits
>  * ipatokenOTPkey
>  * ipatokenHOTPcounter
>  ! ipatokenOwner
>  ! managedBy
>  ! ipatokenUniqueID
> 
>  The ACIs allowing access to most of these attributes are here:
>  https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90
> 
>  Note that I am able to query the entry just fine (including all the
>  above invalidly restricted attributes). Hence, I know the ACIs are
>  working just fine.
> 
>  Part of the strange thing is that in the post read control
>  request, I haven't indicated that I want *any* attributes returned
>  (i.e. I want just the DN). So I'm not sure why it is querying all
>  the attributes. I would suspect that the proper behavior would be
>  to only check the ACIs on attributes that will actually be
>  returned.
> >>> Can you show an example ldif ?
> >>> I wonder if you are setting the owner ?

This is the ldif I used:
dn: ipatokenuniqueid=autogenerate,cn=otp,dc=example,dc=com
changetype: add
objectClass: top
objectClass: ipaToken
objectClass: ipaTokenHOTP
ipatokenUniqueID: autogenerate
ipatokenOTPalgorithm: sha1
ipatokenOTPdigits: 6
ipatokenOTPkey: 
ipatokenHOTPcounter: 0
ipatokenOwner: uid=otp,cn=users,cn=accounts,dc=example,dc=com
managedBy: uid=otp,cn=users,cn=accounts,dc=example,dc=com

>  2. The second patch (0002) modifies the ACI for normal user token
>  addition from this:
> 
>  aci: (target =
>  "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX";)(targetfilter =
>  "(objectClass=ipaToken)")(version 3.0; acl "Users can create
>  self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN"
>  and userattr = "managedBy#SELFDN";)
> 
>  To this:
> 
>  aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp,
>  $SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl
>  "Users can create self-managed tokens"; allow (add) userattr =
>  "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";)
> 
>  The idea is to allow users to create tokens which will be expanded
>  by the UUID plugin. Unfortunately, after the UUID is expanded, the
>  ACIs are checked. Since the expanded UUID no longer matches the
>  ACI, the addition is denied. Is this truly the correct behavior? I
>  would think that the ACIs would be checked before the UUID plugin,
>  not after.
> >>> I would expect the same, can someone on the DS team comment ?
> >> acis are always applied before the entry is sent to the client. the
> >> control is added when the result is sent and for the postop control
> >> it gets the POST_OP entry and checks read access to teh entry
> > So you think the whole add was denied because the post-read couldn't
> > read back the entry ?
> as far as I understood Nathaniel, the add succeeded, only the control 
> was not returned
> > Then fixing the read-related issue is all we need ?
> you need an aci allowing to read the postop entry

No. Issue #2 is unrelated to issue #1. In issue #2, the add itself
fails.

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name

[Ludwig Krispenz]

On 10/09/2014 04:47 PM, Simo Sorce wrote:

On Thu, 09 Oct 2014 16:33:20 +0200
Ludwig Krispenz  wrote:


On 10/09/2014 04:27 PM, Simo Sorce wrote:

On Thu, 09 Oct 2014 16:06:06 +0200
Ludwig Krispenz  wrote:


On 10/09/2014 03:13 PM, Simo Sorce wrote:

On Wed, 08 Oct 2014 17:46:01 -0400
Nathaniel McCallum  wrote:


The background of this email is this bug:
https://fedorahosted.org/freeipa/ticket/4456

Attached are two patches which solve this issue for admin users
(not very helpful, I know). They depend on this fix in 389:
https://fedorahosted.org/389/ticket/47920

There are two outstanding issues:

1. 389 does not send the post read control for normal users. The
operation itself succeeds, but no control is sent.

The relevant sections from the log are attached. 389 is denying
access to the following attributes (* = valid, ! = invalid):
! objectClass
! ipatokenOTPalgorithm
! ipatokenOTPdigits
* ipatokenOTPkey
* ipatokenHOTPcounter
! ipatokenOwner
! managedBy
! ipatokenUniqueID

The ACIs allowing access to most of these attributes are here:
https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90

Note that I am able to query the entry just fine (including all
the above invalidly restricted attributes). Hence, I know the
ACIs are working just fine.

Part of the strange thing is that in the post read control
request, I haven't indicated that I want *any* attributes
returned (i.e. I want just the DN). So I'm not sure why it is
querying all the attributes. I would suspect that the proper
behavior would be to only check the ACIs on attributes that will
actually be returned.

Can you show an example ldif ?
I wonder if you are setting the owner ?


2. The second patch (0002) modifies the ACI for normal user token
addition from this:

aci: (target =
"ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX";)(targetfilter =
"(objectClass=ipaToken)")(version 3.0; acl "Users can create
self-managed tokens"; allow (add) userattr =
"ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";)

To this:

aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp,
$SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0;
acl "Users can create self-managed tokens"; allow (add) userattr
= "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";)

The idea is to allow users to create tokens which will be
expanded by the UUID plugin. Unfortunately, after the UUID is
expanded, the ACIs are checked. Since the expanded UUID no
longer matches the ACI, the addition is denied. Is this truly
the correct behavior? I would think that the ACIs would be
checked before the UUID plugin, not after.

I would expect the same, can someone on the DS team comment ?

acis are always applied before the entry is sent to the client. the
control is added when the result is sent and for the postop control
it gets the POST_OP entry and checks read access to teh entry

So you think the whole add was denied because the post-read couldn't
read back the entry ?

as far as I understood Nathaniel, the add succeeded, only the control
was not returned

Then fixing the read-related issue is all we need ?

you need an aci allowing to read the postop entry

Btw we could add userattr = creatorsName#SELFDN" to the read ACI so that
ipatokenOwner/managedby are not strictly needed for post-read ?
Does it make sense to do ?
I'm not sure, are there cases when tokenOwner is not set or different 
from selfdn ? Could anyone else create the token for another user (an 
admin )?
I don't see what the entry really looked like when trying to create the 
control, and who was "self" in that scenario. In Nathaniel's post access 
was denied to uid=otp, is this the tokenwoner ?




Simo.



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name

[Simo Sorce]

On Thu, 09 Oct 2014 16:33:20 +0200
Ludwig Krispenz  wrote:

> 
> On 10/09/2014 04:27 PM, Simo Sorce wrote:
> > On Thu, 09 Oct 2014 16:06:06 +0200
> > Ludwig Krispenz  wrote:
> >
> >> On 10/09/2014 03:13 PM, Simo Sorce wrote:
> >>> On Wed, 08 Oct 2014 17:46:01 -0400
> >>> Nathaniel McCallum  wrote:
> >>>
>  The background of this email is this bug:
>  https://fedorahosted.org/freeipa/ticket/4456
> 
>  Attached are two patches which solve this issue for admin users
>  (not very helpful, I know). They depend on this fix in 389:
>  https://fedorahosted.org/389/ticket/47920
> 
>  There are two outstanding issues:
> 
>  1. 389 does not send the post read control for normal users. The
>  operation itself succeeds, but no control is sent.
> 
>  The relevant sections from the log are attached. 389 is denying
>  access to the following attributes (* = valid, ! = invalid):
>  ! objectClass
>  ! ipatokenOTPalgorithm
>  ! ipatokenOTPdigits
>  * ipatokenOTPkey
>  * ipatokenHOTPcounter
>  ! ipatokenOwner
>  ! managedBy
>  ! ipatokenUniqueID
> 
>  The ACIs allowing access to most of these attributes are here:
>  https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90
> 
>  Note that I am able to query the entry just fine (including all
>  the above invalidly restricted attributes). Hence, I know the
>  ACIs are working just fine.
> 
>  Part of the strange thing is that in the post read control
>  request, I haven't indicated that I want *any* attributes
>  returned (i.e. I want just the DN). So I'm not sure why it is
>  querying all the attributes. I would suspect that the proper
>  behavior would be to only check the ACIs on attributes that will
>  actually be returned.
> >>> Can you show an example ldif ?
> >>> I wonder if you are setting the owner ?
> >>>
>  2. The second patch (0002) modifies the ACI for normal user token
>  addition from this:
> 
>  aci: (target =
>  "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX";)(targetfilter =
>  "(objectClass=ipaToken)")(version 3.0; acl "Users can create
>  self-managed tokens"; allow (add) userattr =
>  "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";)
> 
>  To this:
> 
>  aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp,
>  $SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0;
>  acl "Users can create self-managed tokens"; allow (add) userattr
>  = "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";)
> 
>  The idea is to allow users to create tokens which will be
>  expanded by the UUID plugin. Unfortunately, after the UUID is
>  expanded, the ACIs are checked. Since the expanded UUID no
>  longer matches the ACI, the addition is denied. Is this truly
>  the correct behavior? I would think that the ACIs would be
>  checked before the UUID plugin, not after.
> >>> I would expect the same, can someone on the DS team comment ?
> >> acis are always applied before the entry is sent to the client. the
> >> control is added when the result is sent and for the postop control
> >> it gets the POST_OP entry and checks read access to teh entry
> > So you think the whole add was denied because the post-read couldn't
> > read back the entry ?
> as far as I understood Nathaniel, the add succeeded, only the control 
> was not returned
> > Then fixing the read-related issue is all we need ?
> you need an aci allowing to read the postop entry

Btw we could add userattr = creatorsName#SELFDN" to the read ACI so that
ipatokenOwner/managedby are not strictly needed for post-read ?
Does it make sense to do ?

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] [HELP] Regular users should not be able to add OTP tokens with custom name

[Ludwig Krispenz]

On 10/09/2014 04:27 PM, Simo Sorce wrote:

On Thu, 09 Oct 2014 16:06:06 +0200
Ludwig Krispenz  wrote:


On 10/09/2014 03:13 PM, Simo Sorce wrote:

On Wed, 08 Oct 2014 17:46:01 -0400
Nathaniel McCallum  wrote:


The background of this email is this bug:
https://fedorahosted.org/freeipa/ticket/4456

Attached are two patches which solve this issue for admin users
(not very helpful, I know). They depend on this fix in 389:
https://fedorahosted.org/389/ticket/47920

There are two outstanding issues:

1. 389 does not send the post read control for normal users. The
operation itself succeeds, but no control is sent.

The relevant sections from the log are attached. 389 is denying
access to the following attributes (* = valid, ! = invalid):
! objectClass
! ipatokenOTPalgorithm
! ipatokenOTPdigits
* ipatokenOTPkey
* ipatokenHOTPcounter
! ipatokenOwner
! managedBy
! ipatokenUniqueID

The ACIs allowing access to most of these attributes are here:
https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90

Note that I am able to query the entry just fine (including all the
above invalidly restricted attributes). Hence, I know the ACIs are
working just fine.

Part of the strange thing is that in the post read control
request, I haven't indicated that I want *any* attributes returned
(i.e. I want just the DN). So I'm not sure why it is querying all
the attributes. I would suspect that the proper behavior would be
to only check the ACIs on attributes that will actually be
returned.

Can you show an example ldif ?
I wonder if you are setting the owner ?


2. The second patch (0002) modifies the ACI for normal user token
addition from this:

aci: (target =
"ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX";)(targetfilter =
"(objectClass=ipaToken)")(version 3.0; acl "Users can create
self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN"
and userattr = "managedBy#SELFDN";)

To this:

aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp,
$SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl
"Users can create self-managed tokens"; allow (add) userattr =
"ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";)

The idea is to allow users to create tokens which will be expanded
by the UUID plugin. Unfortunately, after the UUID is expanded, the
ACIs are checked. Since the expanded UUID no longer matches the
ACI, the addition is denied. Is this truly the correct behavior? I
would think that the ACIs would be checked before the UUID plugin,
not after.

I would expect the same, can someone on the DS team comment ?

acis are always applied before the entry is sent to the client. the
control is added when the result is sent and for the postop control
it gets the POST_OP entry and checks read access to teh entry

So you think the whole add was denied because the post-read couldn't
read back the entry ?
as far as I understood Nathaniel, the add succeeded, only the control 
was not returned

Then fixing the read-related issue is all we need ?

you need an aci allowing to read the postop entry


Simo.




___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name

[Simo Sorce]

On Thu, 09 Oct 2014 16:06:06 +0200
Ludwig Krispenz  wrote:

> 
> On 10/09/2014 03:13 PM, Simo Sorce wrote:
> > On Wed, 08 Oct 2014 17:46:01 -0400
> > Nathaniel McCallum  wrote:
> >
> >> The background of this email is this bug:
> >> https://fedorahosted.org/freeipa/ticket/4456
> >>
> >> Attached are two patches which solve this issue for admin users
> >> (not very helpful, I know). They depend on this fix in 389:
> >> https://fedorahosted.org/389/ticket/47920
> >>
> >> There are two outstanding issues:
> >>
> >> 1. 389 does not send the post read control for normal users. The
> >> operation itself succeeds, but no control is sent.
> >>
> >> The relevant sections from the log are attached. 389 is denying
> >> access to the following attributes (* = valid, ! = invalid):
> >> ! objectClass
> >> ! ipatokenOTPalgorithm
> >> ! ipatokenOTPdigits
> >> * ipatokenOTPkey
> >> * ipatokenHOTPcounter
> >> ! ipatokenOwner
> >> ! managedBy
> >> ! ipatokenUniqueID
> >>
> >> The ACIs allowing access to most of these attributes are here:
> >> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90
> >>
> >> Note that I am able to query the entry just fine (including all the
> >> above invalidly restricted attributes). Hence, I know the ACIs are
> >> working just fine.
> >>
> >> Part of the strange thing is that in the post read control
> >> request, I haven't indicated that I want *any* attributes returned
> >> (i.e. I want just the DN). So I'm not sure why it is querying all
> >> the attributes. I would suspect that the proper behavior would be
> >> to only check the ACIs on attributes that will actually be
> >> returned.
> > Can you show an example ldif ?
> > I wonder if you are setting the owner ?
> >
> >> 2. The second patch (0002) modifies the ACI for normal user token
> >> addition from this:
> >>
> >> aci: (target =
> >> "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX";)(targetfilter =
> >> "(objectClass=ipaToken)")(version 3.0; acl "Users can create
> >> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN"
> >> and userattr = "managedBy#SELFDN";)
> >>
> >> To this:
> >>
> >> aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp,
> >> $SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl
> >> "Users can create self-managed tokens"; allow (add) userattr =
> >> "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";)
> >>
> >> The idea is to allow users to create tokens which will be expanded
> >> by the UUID plugin. Unfortunately, after the UUID is expanded, the
> >> ACIs are checked. Since the expanded UUID no longer matches the
> >> ACI, the addition is denied. Is this truly the correct behavior? I
> >> would think that the ACIs would be checked before the UUID plugin,
> >> not after.
> > I would expect the same, can someone on the DS team comment ?
> acis are always applied before the entry is sent to the client. the 
> control is added when the result is sent and for the postop control
> it gets the POST_OP entry and checks read access to teh entry

So you think the whole add was denied because the post-read couldn't
read back the entry ?
Then fixing the read-related issue is all we need ?

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] [HELP] Regular users should not be able to add OTP tokens with custom name

[Ludwig Krispenz]

On 10/09/2014 03:13 PM, Simo Sorce wrote:

On Wed, 08 Oct 2014 17:46:01 -0400
Nathaniel McCallum  wrote:


The background of this email is this bug:
https://fedorahosted.org/freeipa/ticket/4456

Attached are two patches which solve this issue for admin users (not
very helpful, I know). They depend on this fix in 389:
https://fedorahosted.org/389/ticket/47920

There are two outstanding issues:

1. 389 does not send the post read control for normal users. The
operation itself succeeds, but no control is sent.

The relevant sections from the log are attached. 389 is denying access
to the following attributes (* = valid, ! = invalid):
! objectClass
! ipatokenOTPalgorithm
! ipatokenOTPdigits
* ipatokenOTPkey
* ipatokenHOTPcounter
! ipatokenOwner
! managedBy
! ipatokenUniqueID

The ACIs allowing access to most of these attributes are here:
https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90

Note that I am able to query the entry just fine (including all the
above invalidly restricted attributes). Hence, I know the ACIs are
working just fine.

Part of the strange thing is that in the post read control request, I
haven't indicated that I want *any* attributes returned (i.e. I want
just the DN). So I'm not sure why it is querying all the attributes. I
would suspect that the proper behavior would be to only check the ACIs
on attributes that will actually be returned.

Can you show an example ldif ?
I wonder if you are setting the owner ?


2. The second patch (0002) modifies the ACI for normal user token
addition from this:

aci: (target =
"ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX";)(targetfilter =
"(objectClass=ipaToken)")(version 3.0; acl "Users can create
self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN"
and userattr = "managedBy#SELFDN";)

To this:

aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp,
$SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl
"Users can create self-managed tokens"; allow (add) userattr =
"ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";)

The idea is to allow users to create tokens which will be expanded by
the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs
are checked. Since the expanded UUID no longer matches the ACI, the
addition is denied. Is this truly the correct behavior? I would think
that the ACIs would be checked before the UUID plugin, not after.

I would expect the same, can someone on the DS team comment ?
acis are always applied before the entry is sent to the client. the 
control is added when the result is sent and for the postop control it 
gets the POST_OP entry and checks read access to teh entry




Simo.



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [WIP] DNSSEC check for DNS forwarders

[Tomas Hozza]

On 10/09/2014 10:50 AM, Petr Spacek wrote:
> Hello,
> 
> bad things will happen (i.e. external DNS resolution will not work) if
> configured DNS forwarders are not standard compliant, i.e. EDNS or DNSSEC
> support is not enabled.
> 
> For this reason I'm proposing to add explicit check to IPA installer and
> possibly even to dnsconfig-mod/dnszone-mod commands so forwarders are be 
> tested
> before putting them in effect.
> 
> This check should detect failures soon and prevent surprises where IPA 
> installs
> itself but DNS resolution doesn't work for some domains etc.
> 
> 
> Instructions for attached patch/script:
> # ./dnssec_test.py 127.127.127.127
> -> Will (likely) time-out, print a warning and return None
> - This should be a reason to abort installation because forwarder doesn't work
> at all.
> 
> # ./dnssec_test.py 10.1.2.3
> - Result depends on your local resolver.
> - In RH's network it will print a scary warning message and return False 
> because
> internal forwarder doesn't support DNSSEC.
> - Should be a reason to abort installation. (This could be overridden by 
> --force
> switch but then "dnssec-validation" option in /etc/named.conf has to be set to
> "no" otherwise IPA DNS will not work properly.)
> (I would rather force people to flip the switch in named.conf on forwarder so
> this could be a hidden option.)
> 
> # ./dnssec_test.py 199.7.83.42
> -> Should return True - forwarder works and DNSSEC is supported
> - Installation should continue.
> 
> Please voice your concerns ASAP.
> 

I must confirm that if using DNSSEC, it is essential to probe the
forwarder for proper DNSSEC support before using it. If the forwarder
is not able to provide all the necessary information, the validation
will not work.

This is basically the same we are already doing on the client side
where dnssec-trigger tries to determine if network-provided DNS
forwarders are DNSSEC enabled before configuring unbound server.

Therefore I agree with the idea, however it is up to IPA developers
how they end up implementing the probing.

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

PGP: 1D9F3C2D
Red Hat Inc.   http://cz.redhat.com

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH] [WIP] DNSSEC support - preview

[Petr Spacek]

Hello,

it would be great if people could look at current state of DNSSEC patches for 
FreeIPA.


It consist of several relatively independent parts:
- python-pkcs#11 interface written by Martin Basti:
https://github.com/spacekpe/freeipa-pkcs11

- DNSSEC daemons written by me:
https://github.com/spacekpe/ipadnssecd

- FreeIPA integration written by Martin Basti:
https://github.com/bastiak/freeipa/tree/dnssec

For now brief visual inspection is good enough :-)

Current state
=
- It works only on single DNSSEC "master" server because we still do not have 
the key wrapping machinery.
- The "master" server has to be configured manually using ipa-dnssec-setmaster 
utility.

- DNSSEC keys are generated on the fly when DNSSEC is enabled for particular 
zone.
- Metadata for BIND are generated on the fly.
- BIND automatically signs the zone.

It depends on latest softhsm, opendnssec and bind-pkcs11-util & bind-pkcs11 
packages which are not in Fedora 21 yet.


Thank you for your time!

--
Petr^2 Spacek

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 352 Fix certmonger configuration in installer code

[David Kupka]

On 10/08/2014 01:23 PM, Jan Cholasta wrote:

Dne 8.10.2014 v 12:27 Jan Cholasta napsal(a):

Hi,

the attached patch fixes .

Honza


Forgot to delete a line in dogtaginstance.py (thanks to David for
noticing). Updated patch attached.



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel



Works for me, ACK.

--
David Kupka

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCHES] 344-346 Support building RPMs for RHEL/CentOS 7.0

[Martin Kosek]

On 10/09/2014 03:02 PM, Jan Cholasta wrote:
> Dne 9.10.2014 v 13:06 Martin Kosek napsal(a):
>> On 10/06/2014 12:31 PM, Jan Cholasta wrote:
>>> Hi,
>>>
>>> the attached patches fix .
>>>
>>> Honza
>>
>> 346 looks OK, but I still have couple points to previous 2 patches.
>>
>> 1) I do not like much the "Red Hat-like systems" classification. While it is
>> probably OK to use "redhat" as a folder/package name, the description should
>> say something better (as Red Hat by itself is a company name, not OS name).
>>
>> I did a little research what my colleagues think, Rich M. was suggesting
>> following what Puppet does with "osFamily" and go with "Red Hat OS family".
>>
>> Alexander's suggestion was to do something like "Fedora/RHEL 7.x/CentOS 
>> 7.x/...
>> distributions". Up to you, though I like the "family" approach more.
> 
> I like this more as well, fixed.
> 
>>
>> 2) You changed the hierarchy. Previously we had
>>
>> base -> fedora -> rhel
>>
>> Now we have
>>
>> base -> redhat -> fedora
>>\-> rhel
>>
>> I wonder if this will be flexible enough. Fedora goes before RHEL, so we will
>> soon need to add a support for something that works in Fedora but does not 
>> work
>> in RHEL.
> 
> Well, it's more flexible than what we had before.
> 
>>
>> Would we then add the new function only to fedora platform to not break rhel
>> platform?  Or would be add it to base redhat platform and update rhel 
>> platform
>> to workaround the function with what is available in rhel?
> 
> If you want to do a Fedora-only change, you do it in the fedora module, if you
> want to do a Fedora & RHEL change, you do it in the redhat module. To make a
> Fedora-only change a Fedora & RHEL change, you move it from the fedora module
> to the redhat module. Same for RHEL-only vs. Fedora & RHEL changes.
> 
> Think of the redhat module as a super-class and the fedora and rhel module as
> sub-classes.

Ok, works for me, ACK!

Pushed to master, ipa-4-1, ipa-4-0.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [HELP] Regular users should not be able to add OTP tokens with custom name

[Simo Sorce]

On Wed, 08 Oct 2014 17:46:01 -0400
Nathaniel McCallum  wrote:

> The background of this email is this bug:
> https://fedorahosted.org/freeipa/ticket/4456
> 
> Attached are two patches which solve this issue for admin users (not
> very helpful, I know). They depend on this fix in 389:
> https://fedorahosted.org/389/ticket/47920
> 
> There are two outstanding issues:
> 
> 1. 389 does not send the post read control for normal users. The
> operation itself succeeds, but no control is sent.
> 
> The relevant sections from the log are attached. 389 is denying access
> to the following attributes (* = valid, ! = invalid):
> ! objectClass
> ! ipatokenOTPalgorithm
> ! ipatokenOTPdigits
> * ipatokenOTPkey
> * ipatokenHOTPcounter
> ! ipatokenOwner
> ! managedBy
> ! ipatokenUniqueID
> 
> The ACIs allowing access to most of these attributes are here:
> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90
> 
> Note that I am able to query the entry just fine (including all the
> above invalidly restricted attributes). Hence, I know the ACIs are
> working just fine.
> 
> Part of the strange thing is that in the post read control request, I
> haven't indicated that I want *any* attributes returned (i.e. I want
> just the DN). So I'm not sure why it is querying all the attributes. I
> would suspect that the proper behavior would be to only check the ACIs
> on attributes that will actually be returned.

Can you show an example ldif ?
I wonder if you are setting the owner ?

> 2. The second patch (0002) modifies the ACI for normal user token
> addition from this:
> 
> aci: (target =
> "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX";)(targetfilter =
> "(objectClass=ipaToken)")(version 3.0; acl "Users can create
> self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN"
> and userattr = "managedBy#SELFDN";)
> 
> To this:
> 
> aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp,
> $SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl
> "Users can create self-managed tokens"; allow (add) userattr =
> "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";)
> 
> The idea is to allow users to create tokens which will be expanded by
> the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs
> are checked. Since the expanded UUID no longer matches the ACI, the
> addition is denied. Is this truly the correct behavior? I would think
> that the ACIs would be checked before the UUID plugin, not after.

I would expect the same, can someone on the DS team comment ?

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] Dogtag lightweight sub-CAs; updated design

[Simo Sorce]

On Tue, 07 Oct 2014 16:32:24 +0200
Petr Spacek  wrote:

> Naturally this forces applications to use PKCS#11 for all crypto so
> the raw key never leaves HSM. Luckily DNSSEC software is built around
> PKCS#11 so it was a natural choice for us.
> 
> Personally, I would say that this is the way to go.

I think this should be a goal indeed. However I'd be content if the
proxy process I described would use SoftHSM to retrieve the secrets to
hand them out (or proxy the calls by using them to authenticate) for
now. But yes the idea is that we store them encrypted in LDAP and the
only thing we do is to add ipa servers public keys to LDAP as a way to
distribute access to master keys.

The CA stuff is slightly different though.

We really have only 2 ways here:

1. keep using certificates and build a proxy service that uses GSSAPI
for authenticating received requests, then turn around and fetch a
corresponding cert only the proxy has access to and reply the same
command to the CA using this cert for auth.

2. Teach dogtag to use GSSAPI for authenticating these requests and
then just tell it which principals (or groups of principals) are
allowed to perform operations instead of using certs.

Of course 2 would be much simpler.

Fraser, how hard do you think it would be to add #2 ?

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] [HELP] Regular users should not be able to add OTP tokens with custom name

[thierry bordaz]

On 10/08/2014 11:46 PM, Nathaniel McCallum wrote:

The background of this email is this bug:
https://fedorahosted.org/freeipa/ticket/4456

Attached are two patches which solve this issue for admin users (not
very helpful, I know). They depend on this fix in 389:
https://fedorahosted.org/389/ticket/47920

There are two outstanding issues:

1. 389 does not send the post read control for normal users. The
operation itself succeeds, but no control is sent.

The relevant sections from the log are attached. 389 is denying access
to the following attributes (* = valid, ! = invalid):
! objectClass
! ipatokenOTPalgorithm
! ipatokenOTPdigits
* ipatokenOTPkey
* ipatokenHOTPcounter
! ipatokenOwner
! managedBy
! ipatokenUniqueID

Hello Nathaniel,

   The post read control needs access to the modified entry to return it.
   This access is granted at the condition, the binddn can access
   attributes.
   My understanding is that the target entry is
   
ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com
   and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com".

   The only ACI I found that match this target is:

   |aci: (targetfilter=  "(objectClass=ipaToken)")
   (targetattrs=  "objectclass || description || managedBy || ipatokenUniqueID 
|| ipatokenDisabled
 || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || 
ipatokenSerial || ipatokenOwner")
   (version3.0;  acl"Users/managers can read basic token info";  allow(read,  search,  compare)  
userattr=  "ipatokenOwner#USERDN"  or userattr=  "managedBy#USERDN";)|


   Do you know if the target entry has 'ipatokenOwner' or 'managedBy'
   with the binddn value ?



The ACIs allowing access to most of these attributes are here:
https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90

Note that I am able to query the entry just fine (including all the
above invalidly restricted attributes). Hence, I know the ACIs are
working just fine.

Part of the strange thing is that in the post read control request, I
haven't indicated that I want *any* attributes returned (i.e. I want
just the DN). So I'm not sure why it is querying all the attributes. I
would suspect that the proper behavior would be to only check the ACIs
on attributes that will actually be returned.


   It may not querying all attributes, but just search the first one it
   can read.
   As it finds none of them you get the message for all attributes.

   thanks
   thierry



2. The second patch (0002) modifies the ACI for normal user token
addition from this:

aci: (target = "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX";)(targetfilter
= "(objectClass=ipaToken)")(version 3.0; acl "Users can create
self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" and
userattr = "managedBy#SELFDN";)

To this:

aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp,
$SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl
"Users can create self-managed tokens"; allow (add) userattr =
"ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";)

The idea is to allow users to create tokens which will be expanded by
the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs are
checked. Since the expanded UUID no longer matches the ACI, the addition
is denied. Is this truly the correct behavior? I would think that the
ACIs would be checked before the UUID plugin, not after.


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree

[Alexander Bokovoy]

On Thu, 09 Oct 2014, Martin Kosek wrote:

On 10/09/2014 01:02 PM, Alexander Bokovoy wrote:

On Thu, 09 Oct 2014, Alexander Bokovoy wrote:

On Thu, 09 Oct 2014, Martin Kosek wrote:

On 10/09/2014 09:33 AM, Ludwig Krispenz wrote:

all the issues I found are fixed, for me it's ACK

On 10/08/2014 07:50 PM, Alexander Bokovoy wrote:

On Tue, 07 Oct 2014, Ludwig Krispenz wrote:

Hi Alex,

I have a question regarding cbdata.target. It is/was a reference to the
pblock used to generate a new dn, but now in
idview_replace_target_dn(&cbdata.target,...) it can be newly allocated and
should be freed, so I think there should be a return code indicating if it
was allocated or not.

Yes, good catch.

I've fixed this and other issues raised in the review.

I also fixed an issue with an initial lookup by an override. If someone
does a search by an override, we would replace uid|cn= by
uid= if it exists and by 
otherwise -- for groups we don't have ipaOriginalUid as they don't have
uids. Now, the filter would look like (ipaAnchorUUID=:SID:S-...) and if
there is no entry in the map cache, the search will return nothing, the
entry will be staged for lookup through SSSD.

In the original version lookup in SSSD didn't take ipaAnchorUUID into
account, so the entry would not be found at all. I did add a call to
do sid2name first and then use the name to perform actual SSSD lookup.

Works nicely now.

New patch for slapi-nis is attached.


Great! What is the next step? If Nalin (CCed) is OK with the slapi-nis changes
as well, it would be great to have that pushed there.

Alexander, do you plan to do any other changes in slapi-nis in scope of FreeIPA
4.1? When the changes are ready, it would be nice to get slapi-nis released so
that we can bump FreeIPA slapi-nis requires.

No more changes are planned right now. If Nalin would grant me write
access to slapi-nis.git on fedorahosted.org, I can handle release in Fedora
already.

Never say never. The moment I've sent this email, I've realized I need
to fix https://bugzilla.redhat.com/show_bug.cgi?id=1130131

The patch is sent in a separate email.


Seen that, thanks! BTW what about

#4435   Trusted AD users are not resovable in netgroups
#4403   [RFE] compat tree: show AD members of IPA groups

do you see this also as something that would fit in slapi-nis in 4.1?

I don't think I'll be able to fix them before 4.1. Netgroups support
requires to create additional configuration and in theory could be
simple but needs a lot of care (escaping of embedded string delimiters).
Additionally, netgroups will not yet work with views properly, this is
something that requires more time.

AD members of IPA groups needs more work too as we have no means yet to
pick up and resolve ipaExternalMember in slapi-nis.
--
/ Alexander Bokovoy

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree

[Martin Kosek]

On 10/09/2014 01:02 PM, Alexander Bokovoy wrote:
> On Thu, 09 Oct 2014, Alexander Bokovoy wrote:
>> On Thu, 09 Oct 2014, Martin Kosek wrote:
>>> On 10/09/2014 09:33 AM, Ludwig Krispenz wrote:
 all the issues I found are fixed, for me it's ACK

 On 10/08/2014 07:50 PM, Alexander Bokovoy wrote:
> On Tue, 07 Oct 2014, Ludwig Krispenz wrote:
>> Hi Alex,
>>
>> I have a question regarding cbdata.target. It is/was a reference to the
>> pblock used to generate a new dn, but now in
>> idview_replace_target_dn(&cbdata.target,...) it can be newly allocated 
>> and
>> should be freed, so I think there should be a return code indicating if 
>> it
>> was allocated or not.
> Yes, good catch.
>
> I've fixed this and other issues raised in the review.
>
> I also fixed an issue with an initial lookup by an override. If someone
> does a search by an override, we would replace uid|cn= by
> uid= if it exists and by 
> otherwise -- for groups we don't have ipaOriginalUid as they don't have
> uids. Now, the filter would look like (ipaAnchorUUID=:SID:S-...) and if
> there is no entry in the map cache, the search will return nothing, the
> entry will be staged for lookup through SSSD.
>
> In the original version lookup in SSSD didn't take ipaAnchorUUID into
> account, so the entry would not be found at all. I did add a call to
> do sid2name first and then use the name to perform actual SSSD lookup.
>
> Works nicely now.
>
> New patch for slapi-nis is attached.
>>>
>>> Great! What is the next step? If Nalin (CCed) is OK with the slapi-nis 
>>> changes
>>> as well, it would be great to have that pushed there.
>>>
>>> Alexander, do you plan to do any other changes in slapi-nis in scope of 
>>> FreeIPA
>>> 4.1? When the changes are ready, it would be nice to get slapi-nis released 
>>> so
>>> that we can bump FreeIPA slapi-nis requires.
>> No more changes are planned right now. If Nalin would grant me write
>> access to slapi-nis.git on fedorahosted.org, I can handle release in Fedora
>> already.
> Never say never. The moment I've sent this email, I've realized I need
> to fix https://bugzilla.redhat.com/show_bug.cgi?id=1130131
> 
> The patch is sent in a separate email.

Seen that, thanks! BTW what about

#4435   Trusted AD users are not resovable in netgroups
#4403   [RFE] compat tree: show AD members of IPA groups

do you see this also as something that would fit in slapi-nis in 4.1?

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH] 0656-0660 Make most tests runnable under py.test

[Petr Viktorin]

This makes all tests except
- integration
- xmlrpc
- doctest
to be runnable under py.test.
The last patch does touch Declarative, but keeps compatibility with Nose.

How to test:
- have a ticket
- do NOT have integration tests configured (using $MASTER or 
$IPATEST_*_CONFIG)

# yum install pytest
$ IPA_UNIT_TEST_MODE=cli_test py.test

(note: the command is `py.test`, for historical reasons in the pytest 
project)


--
Petr³
From 3ed569a74fb9006b0503e71ec7fbdb92745dcb1c Mon Sep 17 00:00:00 2001
From: Petr Viktorin 
Date: Tue, 7 Oct 2014 12:48:22 +0200
Subject: [PATCH] tests: Use PEP8-compliant setup/teardown method names

The setUp/dearDown names are used in the unittest module, but there is no reason
to use them in non-`unittest` test cases.
Nose supports both styles (but mixing them can cause trouble when
calling super()'s methods).
Pytest only supports the new ones.
---
 ipatests/test_cmdline/cmdline.py |  8 
 ipatests/test_integration/test_caless.py | 12 +---
 .../test_integration/test_forced_client_reenrollment.py  |  4 ++--
 ipatests/test_ipalib/test_rpc.py |  4 ++--
 ipatests/test_ipalib/test_text.py|  4 ++--
 ipatests/test_ipapython/test_ipavalidate.py  |  6 --
 ipatests/test_ipapython/test_keyring.py  |  2 +-
 ipatests/test_ipaserver/test_changepw.py |  8 
 ipatests/test_ipaserver/test_ldap.py |  8 
 ipatests/test_pkcs10/test_pkcs10.py  |  2 +-
 ipatests/test_webui/ui_driver.py |  6 +++---
 ipatests/test_xmlrpc/test_cert_plugin.py | 16 
 ipatests/test_xmlrpc/test_dns_plugin.py  |  8 
 ipatests/test_xmlrpc/test_external_members.py|  4 ++--
 ipatests/test_xmlrpc/test_host_plugin.py |  2 +-
 ipatests/test_xmlrpc/test_permission_plugin.py   |  4 ++--
 ipatests/test_xmlrpc/test_range_plugin.py|  8 
 ipatests/test_xmlrpc/test_trust_plugin.py|  4 ++--
 ipatests/test_xmlrpc/test_user_plugin.py |  4 ++--
 ipatests/test_xmlrpc/xmlrpc_test.py  |  6 +++---
 ipatests/util.py |  4 ++--
 21 files changed, 58 insertions(+), 66 deletions(-)

diff --git a/ipatests/test_cmdline/cmdline.py b/ipatests/test_cmdline/cmdline.py
index e790f022ebea8a29123cb41b5f215675fccaa647..bcb71328adce37e0e7bf748f018bb5773d5cc497 100644
--- a/ipatests/test_cmdline/cmdline.py
+++ b/ipatests/test_cmdline/cmdline.py
@@ -52,7 +52,7 @@ class cmdline_test(XMLRPC_test):
 # some reasonable default command
 command = paths.LS
 
-def setUp(self):
+def setup(self):
 # Find the executable in $PATH
 # This is neded because ipautil.run resets the PATH to
 # a system default.
@@ -65,14 +65,14 @@ def setUp(self):
 raise AssertionError(
 'Command %r not available' % original_command
 )
-super(cmdline_test, self).setUp()
+super(cmdline_test, self).setup()
 if not server_available:
 raise nose.SkipTest(
 'Server not available: %r' % api.env.xmlrpc_uri
 )
 
-def tearDown(self):
+def teardown(self):
 """
 nose tear-down fixture.
 """
-super(cmdline_test, self).tearDown()
+super(cmdline_test, self).teardown()
diff --git a/ipatests/test_integration/test_caless.py b/ipatests/test_integration/test_caless.py
index 1bd8202c8c375e67df0cbc401c4b4724465f2996..d2b74b33228d9e42246b306fe616613c9eecc4dd 100644
--- a/ipatests/test_integration/test_caless.py
+++ b/ipatests/test_integration/test_caless.py
@@ -340,7 +340,7 @@ def verify_installation(self):
 class TestServerInstall(CALessBase):
 num_replicas = 0
 
-def tearDown(self):
+def teardown(self):
 self.uninstall_server()
 
 # Remove CA cert in /etc/pki/nssdb, in case of failed (un)install
@@ -750,7 +748,7 @@ def test_no_ds_password(self):
 class TestReplicaInstall(CALessBase):
 num_replicas = 1
 
-def setUp(self):
+def setup(self):
 # Install the master for every test
 self.export_pkcs12('ca1/server')
 with open(self.pem_filename, 'w') as f:
@@ -759,7 +757,7 @@ def setUp(self):
 result = self.install_server()
 assert result.returncode == 0
 
-def tearDown(self):
+def teardown(self):
 # Uninstall both master and replica
 replica = self.replicas[0]
 tasks.kinit_admin(self.master)
diff --git a/ipatests/test_integration/test_forced_client_reenrollment.py b/ipatests/test_integration/test_forced_client_reenrollment.py
index b1165218714b994d835bb63f37dc6f921627b168..826e70d24b71d3fefc2cb305dd9eb7cb6ddb0c30 100644
--- a/ipatests/test_integration/test_forced_client_reenrollment.py
+++ b/ipatest

Re: [Freeipa-devel] [PATCHES] 344-346 Support building RPMs for RHEL/CentOS 7.0

[Martin Kosek]

On 10/06/2014 12:31 PM, Jan Cholasta wrote:
> Hi,
> 
> the attached patches fix .
> 
> Honza

346 looks OK, but I still have couple points to previous 2 patches.

1) I do not like much the "Red Hat-like systems" classification. While it is
probably OK to use "redhat" as a folder/package name, the description should
say something better (as Red Hat by itself is a company name, not OS name).

I did a little research what my colleagues think, Rich M. was suggesting
following what Puppet does with "osFamily" and go with "Red Hat OS family".

Alexander's suggestion was to do something like "Fedora/RHEL 7.x/CentOS 7.x/...
distributions". Up to you, though I like the "family" approach more.

2) You changed the hierarchy. Previously we had

base -> fedora -> rhel

Now we have

base -> redhat -> fedora
  \-> rhel

I wonder if this will be flexible enough. Fedora goes before RHEL, so we will
soon need to add a support for something that works in Fedora but does not work
in RHEL.

Would we then add the new function only to fedora platform to not break rhel
platform? Or would be add it to base redhat platform and update rhel platform
to workaround the function with what is available in rhel?

I just want to make sure we are clear on this one.

Thanks,
Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree

[Alexander Bokovoy]

On Thu, 09 Oct 2014, Alexander Bokovoy wrote:

On Thu, 09 Oct 2014, Martin Kosek wrote:

On 10/09/2014 09:33 AM, Ludwig Krispenz wrote:

all the issues I found are fixed, for me it's ACK

On 10/08/2014 07:50 PM, Alexander Bokovoy wrote:

On Tue, 07 Oct 2014, Ludwig Krispenz wrote:

Hi Alex,

I have a question regarding cbdata.target. It is/was a reference to the
pblock used to generate a new dn, but now in
idview_replace_target_dn(&cbdata.target,...) it can be newly allocated and
should be freed, so I think there should be a return code indicating if it
was allocated or not.

Yes, good catch.

I've fixed this and other issues raised in the review.

I also fixed an issue with an initial lookup by an override. If someone
does a search by an override, we would replace uid|cn= by
uid= if it exists and by 
otherwise -- for groups we don't have ipaOriginalUid as they don't have
uids. Now, the filter would look like (ipaAnchorUUID=:SID:S-...) and if
there is no entry in the map cache, the search will return nothing, the
entry will be staged for lookup through SSSD.

In the original version lookup in SSSD didn't take ipaAnchorUUID into
account, so the entry would not be found at all. I did add a call to
do sid2name first and then use the name to perform actual SSSD lookup.

Works nicely now.

New patch for slapi-nis is attached.


Great! What is the next step? If Nalin (CCed) is OK with the slapi-nis changes
as well, it would be great to have that pushed there.

Alexander, do you plan to do any other changes in slapi-nis in scope of FreeIPA
4.1? When the changes are ready, it would be nice to get slapi-nis released so
that we can bump FreeIPA slapi-nis requires.

No more changes are planned right now. If Nalin would grant me write
access to slapi-nis.git on fedorahosted.org, I can handle release in Fedora 
already.

Never say never. The moment I've sent this email, I've realized I need
to fix https://bugzilla.redhat.com/show_bug.cgi?id=1130131

The patch is sent in a separate email.
--
/ Alexander Bokovoy

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH] slapi-nis: normalize memberUid search filter term for AD users

[Alexander Bokovoy]

Hi,

memberUid attribute has case-sensitive comparison defined but when we
construct memberUid for AD users (coming through SSSD), they are
normalized to lower case. Interestingly enough, 'uid' attribute has
case-insensitive comparison.

Work around the issue by low-casing the memberUid search term value when
it is a fully-qualified name (user@domain), meaning we do ask for a SSSD
user.

This is the patch on top of my ID views support patch.

https://bugzilla.redhat.com/show_bug.cgi?id=1130131
--
/ Alexander Bokovoy
From e90135b7a477d15c4349e7d46e4cbf2730a66d71 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy 
Date: Thu, 9 Oct 2014 13:52:38 +0300
Subject: [PATCH 2/2] slapi-nis: normalize memberUid search filter when
 searching AD users

memberUid attribute uses IA5 String comparison which is case-sensitive.
At the same time, uid attribute uses case-insensitive comparison.

When memberUid is constructed for groups from AD, SSSD normalizes names
to a lower case. slapi-nis records these entries as they produced by SSSD.
However, the search filter is not modified, thus case-sensitive comparison
of memberUid attribute may fail match of the original term.

Workaround the issue by low-casing memberUid term in the search filter
if it includes '@' sign, meaning we are searching on fully-qualified user
name provided by SSSD.

https://bugzilla.redhat.com/show_bug.cgi?id=1130131
---
 src/back-sch-nss.c | 35 ---
 1 file changed, 32 insertions(+), 3 deletions(-)

diff --git a/src/back-sch-nss.c b/src/back-sch-nss.c
index 26d4b8c..12ae589 100644
--- a/src/back-sch-nss.c
+++ b/src/back-sch-nss.c
@@ -60,7 +60,7 @@ bvstrprefix(const struct berval *bval, const char *s)
 
len = strlen(s);
if (len < bval->bv_len) {
-   return strncasecmp(bval->bv_val, s, len) != 0;
+   return slapi_utf8ncasecmp((unsigned char *) bval->bv_val, 
(unsigned char *) s, len) != 0;
}
 
return 1;
@@ -75,9 +75,9 @@ bvstrcasecmp(const struct berval *bval, const char *s)
 
len = strlen(s);
if (len == bval->bv_len) {
-   return strncasecmp(bval->bv_val, s, len);
+   return slapi_utf8ncasecmp((unsigned char *) bval->bv_val, 
(unsigned char *) s, len);
}
-   c = strncasecmp(bval->bv_val, s, MIN(bval->bv_len, len));
+   c = slapi_utf8ncasecmp((unsigned char *) bval->bv_val, (unsigned char 
*) s, MIN(bval->bv_len, len));
if (c != 0) {
return c;
}
@@ -111,6 +111,35 @@ backend_search_filter_has_cn_uid(Slapi_Filter *filter, 
void *arg)
} else if (0 == strcasecmp(filter_type, "cn")) {
config->name_set = TRUE;
} else if (0 == strcasecmp(filter_type, "memberUid")) {
+   /* memberUid is case-sensitive in RFC 2307 but uid is 
case-insensitive
+* When memberUid is generated for SSSD-provided 
entries, it is low-cased,
+* we need to low case the filter value to actually 
match it.
+* However, we will do it only for fully qualified 
names as they are coming from SSSD. */
+   char *memberUid = NULL;
+   char *lwMemberUid = NULL;
+   unsigned int i = 0;
+
+   for (i=0; i < bval->bv_len ; i++) {
+   if (bval->bv_val[i] == '@')
+   break;
+   }
+
+   if (i < bval->bv_len) {
+   memberUid = slapi_ch_malloc(bval->bv_len + 1);
+   if (memberUid != NULL) {
+   memcpy(memberUid, bval->bv_val, 
bval->bv_len);
+   memberUid[bval->bv_len] = '\0';
+   lwMemberUid = (char *) 
slapi_utf8StrToLower((unsigned char*) memberUid);
+   if (lwMemberUid != NULL) {
+   struct berval bval_lw = {0, 
NULL};
+   bval_lw.bv_len = strlen((const 
char *) lwMemberUid);
+   bval_lw.bv_val = lwMemberUid;
+   slapi_ber_bvdone(bval);
+   slapi_ber_bvcpy(bval, &bval_lw);
+   }
+   slapi_ch_free_string(&memberUid);
+   }
+   }
config->name_set = TRUE;
config->search_members = TRUE;
} else if ((0 == strcasecmp(filter_type, "objectClass")) &&
-- 
2.1.0

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] Should mask/unmask be part of disabling/enabling services in systemd?

[Martin Basti]

On 22/09/14 09:52, Jan Cholasta wrote:

Dne 19.9.2014 v 17:23 Rob Crittenden napsal(a):

Martin Basti wrote:

Hello list,

I need to use systemd mask/unmask in ipa service.

But as Honza wrote:
"IMO masking/unmasking should be part of disabling/enabling a 
service in
systemd. AFAIK in most other init systems when you disable a 
service, it
has the same effect as masking the service in systemd - it will 
never be

started until it is enabled/unmasked again. "

So my questions is, should be masking part of disabling service in
systemd, to be platform independent?
Or should we add mask/unmask methods to
ipaplatform.base.services.PlatformService where mask is alias for 
disable?


Martin^2



After reading http://0pointer.de/blog/projects/three-levels-of-off I
disagree that disabling in SysV is the same as masking in systemd,
though I guess it depends on the meaning of disable. According to that
page chkconfig off  is equivalent to systemctl disable
.service, which is what we do now AFAIR.


I don't think that's entirely correct. They are equivalent 
mechanically (a symlink is added/removed when a service is 
enabled/disabled), but effectively they are different. AFAIK in SysV, 
services can be started either manually or automatically on boot and 
if you disable a service the only way it will start is when you do it 
manually. In systemd, there are more ways services can be started 
automatically (socket, D-Bus, etc.) and disabling a service will only 
disable automatic start *on boot*, but it can still be started 
automatically, which contrasts with what SysV does.




Why do you need to mask a service, e.g. render it completely 
unstartable?


rob





Let's continue with discussion,

1) should we add general method mask/unmask to ipaplatform, or
2) make mask/unmask part of enabling/disabling in systemd

Martin^2

--
Martin Basti

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0133] Fix ipactl service ordering

[Martin Kosek]

On 10/09/2014 12:51 PM, David Kupka wrote:
> On 10/09/2014 12:44 PM, Martin Basti wrote:
>> On 08/10/14 20:08, Martin Basti wrote:
>>> On 08/10/14 16:59, Martin Basti wrote:
 IPA sorts service order alphabetically, this patch modify ipactl to
 use integers.

 How to reproduce:
 set attribute ipaConfigString: startOrder 150
 DN:
 cn=HTTP,cn=ipa.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com

 then run
 #ipactl restart

 httpd service should start as last service, but it starts almost first.

 Patch attached.

>>>
>>> selfNACK
>>>
>> NACKing my SelfNACK, I accidentally installed wrong RPM  and I though I
>> haven't fixed it correctly.
>> Patch is OK.
>>
> Works for me, ACK.
> 

Pushed to:
master: 57c510dcc7a08d908fd55856a735b8dca6684571
ipa-4-1: f74213877a81553bc16c8e050956e742b0b9a5f4
ipa-4-0: 56a146a66627e71fcd927ede7608ed3358cd904c

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0133] Fix ipactl service ordering

[David Kupka]

On 10/09/2014 12:44 PM, Martin Basti wrote:

On 08/10/14 20:08, Martin Basti wrote:

On 08/10/14 16:59, Martin Basti wrote:

IPA sorts service order alphabetically, this patch modify ipactl to
use integers.

How to reproduce:
set attribute ipaConfigString: startOrder 150
DN:
cn=HTTP,cn=ipa.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com

then run
#ipactl restart

httpd service should start as last service, but it starts almost first.

Patch attached.



selfNACK


NACKing my SelfNACK, I accidentally installed wrong RPM  and I though I
haven't fixed it correctly.
Patch is OK.


Works for me, ACK.

--
David Kupka

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [WIP] DNSSEC check for DNS forwarders

[Petr Spacek]

I have accidentally sent the e-mail twice. Please reply to thread with 
additional [PATCH] keyword in subject and let this thread to die.


On 9.10.2014 10:50, Petr Spacek wrote:

Hello,

bad things will happen (i.e. external DNS resolution will not work) if
configured DNS forwarders are not standard compliant, i.e. EDNS or DNSSEC
support is not enabled.

For this reason I'm proposing to add explicit check to IPA installer and
possibly even to dnsconfig-mod/dnszone-mod commands so forwarders are be
tested before putting them in effect.

This check should detect failures soon and prevent surprises where IPA
installs itself but DNS resolution doesn't work for some domains etc.


Instructions for attached patch/script:
# ./dnssec_test.py 127.127.127.127
-> Will (likely) time-out, print a warning and return None
- This should be a reason to abort installation because forwarder doesn't work
at all.

# ./dnssec_test.py 10.1.2.3
- Result depends on your local resolver.
- In RH's network it will print a scary warning message and return False
because internal forwarder doesn't support DNSSEC.
- Should be a reason to abort installation. (This could be overridden by
--force switch but then "dnssec-validation" option in /etc/named.conf has to
be set to "no" otherwise IPA DNS will not work properly.)
(I would rather force people to flip the switch in named.conf on forwarder so
this could be a hidden option.)

# ./dnssec_test.py 199.7.83.42
-> Should return True - forwarder works and DNSSEC is supported
- Installation should continue.

Please voice your concerns ASAP.



--
Petr^2 Spacek

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0133] Fix ipactl service ordering

[Martin Basti]

On 08/10/14 20:08, Martin Basti wrote:

On 08/10/14 16:59, Martin Basti wrote:
IPA sorts service order alphabetically, this patch modify ipactl to 
use integers.


How to reproduce:
set attribute ipaConfigString: startOrder 150
DN: 
cn=HTTP,cn=ipa.example.com,cn=masters,cn=ipa,cn=etc,dc=example,dc=com


then run
#ipactl restart

httpd service should start as last service, but it starts almost first.

Patch attached.



selfNACK

NACKing my SelfNACK, I accidentally installed wrong RPM  and I though I 
haven't fixed it correctly.

Patch is OK.

--
Martin Basti

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] [WIP] DNSSEC check for DNS forwarders

[Petr Spacek]

On 9.10.2014 11:04, Martin Basti wrote:

On 09/10/14 10:42, Petr Spacek wrote:

Hello,

bad things will happen (i.e. external DNS resolution will not work) if
configured DNS forwarders are not standard compliant, i.e. EDNS or DNSSEC
support is not enabled.

For this reason I'm proposing to add explicit check to IPA installer and
possibly even to dnsconfig-mod/dnszone-mod commands so forwarders can be
tested before putting them in effect.

This check should detect failures soon and prevent surprises where IPA
installs itself but DNS resolution doesn't work for some domains etc.

Please voice your concerns ASAP.


We have discussed this in person once again, here is refined idea:


This is related to named option "dnssec-validate yes;" right?

Yes.


What is expected if this test failed:
1) during DNS installation

Fail installation with error and scream loudly.
User can use new option --no-dnssec-validation to change error to loud 
warning. This option will put "dnssec-validate no;" into /etc/named.conf.



2) during dnsconfig-mod --forwarders

Print a warning. This will not affect named.conf validation settings in any way.


3) during dnszone-mod --forwarders
This check doesn't make sense because zone-forwarder doesn't necessarily has 
access to DNS root zone and the forwarded zone doesn't need to be signed.



Will we force users to use standard compliant DNS forwarder or will we disable
DNSSEC validation?
We decided to enable validation by default but user can use the new option if 
he really insists on an insecure mode.



What if user doesn't want use DNSSEC?

There are three levels of 'use':

Highest level signing own DNS zones: IPA will not force users to sign any DNS 
zone. It always has to be explicitly enabled per-zone.


Mid level is DNSSEC validation on results from signed domains: I would like to 
enable it by default because it improves security.


Lowest level is the ability to get signatures (even if validation is not 
enabled at the moment): This is about EDNS & DNSSEC standard compliance and 
IMHO this should be required. That is why installer and dnsconfig-mod should 
scream.


--
Petr^2 Spacek

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0064] Create ipa-otp-decrement 389DS plugin

[thierry bordaz]

On 10/09/2014 12:15 AM, Nathaniel McCallum wrote:

On Wed, 2014-10-08 at 17:19 -0400, Simo Sorce wrote:

On Wed, 08 Oct 2014 15:53:39 -0400
Nathaniel McCallum  wrote:


As I understand my code, all servers will have csnD. Some servers will
have valueB and others will have valueD, but valueB == valueD.

We *never* discard a CSN. We only discard the counter/watermark mods
in the replication operation.

What Thierry is saying is that the individual attributes in the entry
have associate the last CSN that modified them. Because you remove the
mods when ValueD == ValueB the counter attribute will not have the
associated CSN changed. But it doesn't really matter because the plugin
will always keep things consistent.

Attached is a new version. It removes this optimization. If server X has
valueB/csnB and receives valueD/csnD and valueB == valueD, the
replication will be applied without any modification. However, if valueB

valueD and csnD > csnB, the counter mods will still be stripped.

It also collapses the error check from betxnpre to bepre now that we
have a fix for https://fedorahosted.org/389/ticket/47919 committed. The
betxnpre functions are completely removed. Also, a dependency on 389
1.3.3.4 (not yet released) is added.

Nathaniel

Hello Nathaniel,

   For me the code is fine. Ack.

   I have two minor comments:

 * in preop_mod, when a direct update moves the counter backward
   you send UNWILLING to perform with a message.
   The message is allocated with slapi_ch_smprintf, you may free it
   with slapi_ch_free_string (rather than 'free').
 * About this message, for example when you have these MODS (I
   admit they make no sens):

   changetype: modify
   ipatokenHOTPcounter: MOD_DELETE
   -
   ipatokenHOTPcounter: MOD_INCREMENT

   The returned message will be "Will not decrement
   ipatokenHOTPcounter", because 'simulate' will return
   'COUNTER_UNSET+1'.
   Is it the message you expected ?

thanks
thierry
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree

[Alexander Bokovoy]

On Thu, 09 Oct 2014, Martin Kosek wrote:

On 10/09/2014 09:33 AM, Ludwig Krispenz wrote:

all the issues I found are fixed, for me it's ACK

On 10/08/2014 07:50 PM, Alexander Bokovoy wrote:

On Tue, 07 Oct 2014, Ludwig Krispenz wrote:

Hi Alex,

I have a question regarding cbdata.target. It is/was a reference to the
pblock used to generate a new dn, but now in
idview_replace_target_dn(&cbdata.target,...) it can be newly allocated and
should be freed, so I think there should be a return code indicating if it
was allocated or not.

Yes, good catch.

I've fixed this and other issues raised in the review.

I also fixed an issue with an initial lookup by an override. If someone
does a search by an override, we would replace uid|cn= by
uid= if it exists and by 
otherwise -- for groups we don't have ipaOriginalUid as they don't have
uids. Now, the filter would look like (ipaAnchorUUID=:SID:S-...) and if
there is no entry in the map cache, the search will return nothing, the
entry will be staged for lookup through SSSD.

In the original version lookup in SSSD didn't take ipaAnchorUUID into
account, so the entry would not be found at all. I did add a call to
do sid2name first and then use the name to perform actual SSSD lookup.

Works nicely now.

New patch for slapi-nis is attached.


Great! What is the next step? If Nalin (CCed) is OK with the slapi-nis changes
as well, it would be great to have that pushed there.

Alexander, do you plan to do any other changes in slapi-nis in scope of FreeIPA
4.1? When the changes are ready, it would be nice to get slapi-nis released so
that we can bump FreeIPA slapi-nis requires.

No more changes are planned right now. If Nalin would grant me write
access to slapi-nis.git on fedorahosted.org, I can handle release in Fedora 
already.

--
/ Alexander Bokovoy

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] [WIP] DNSSEC check for DNS forwarders

[Martin Basti]

On 09/10/14 10:42, Petr Spacek wrote:

Hello,

bad things will happen (i.e. external DNS resolution will not work) if 
configured DNS forwarders are not standard compliant, i.e. EDNS or 
DNSSEC support is not enabled.


For this reason I'm proposing to add explicit check to IPA installer 
and possibly even to dnsconfig-mod/dnszone-mod commands so forwarders 
can be tested before putting them in effect.


This check should detect failures soon and prevent surprises where IPA 
installs itself but DNS resolution doesn't work for some domains etc.


Please voice your concerns ASAP.



This is related to named option "dnssec-validate yes;" right?
What is expected if this test failed:
1) during DNS installation
2) during dnsconfig-mod --forwarders
3) during dnszone-mod --forwarders

Will we force users to use standard compliant DNS forwarder or will we 
disable DNSSEC validation?


What if user doesn't want use DNSSEC?


Martin^2

--
Martin Basti

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [WIP] DNSSEC check for DNS forwarders

[Petr Spacek]

Hello,

bad things will happen (i.e. external DNS resolution will not work) if 
configured DNS forwarders are not standard compliant, i.e. EDNS or DNSSEC 
support is not enabled.


For this reason I'm proposing to add explicit check to IPA installer and 
possibly even to dnsconfig-mod/dnszone-mod commands so forwarders are be 
tested before putting them in effect.


This check should detect failures soon and prevent surprises where IPA 
installs itself but DNS resolution doesn't work for some domains etc.



Instructions for attached patch/script:
# ./dnssec_test.py 127.127.127.127
-> Will (likely) time-out, print a warning and return None
- This should be a reason to abort installation because forwarder doesn't work 
at all.


# ./dnssec_test.py 10.1.2.3
- Result depends on your local resolver.
- In RH's network it will print a scary warning message and return False 
because internal forwarder doesn't support DNSSEC.
- Should be a reason to abort installation. (This could be overridden by 
--force switch but then "dnssec-validation" option in /etc/named.conf has to 
be set to "no" otherwise IPA DNS will not work properly.)
(I would rather force people to flip the switch in named.conf on forwarder so 
this could be a hidden option.)


# ./dnssec_test.py 199.7.83.42
-> Should return True - forwarder works and DNSSEC is supported
- Installation should continue.

Please voice your concerns ASAP.

--
Petr^2 Spacek
import sys

import dns.resolver

def test_forwarder(ip_addr):
"""Test DNS forwarder properties.

:returns:
 True if forwarder works as expected and supports DNSSEC.
 False if forwarder does not support DNSSEC.
 None if forwarder does not respond.
"""
res = dns.resolver.Resolver()
res.nameservers = [ip_addr]

# enable Authenticated Data + Checking Disabled flags
res.set_flags(dns.flags.AD | dns.flags.CD)

# enable EDNS v0 + enable DNSSEC-Ok flag
res.use_edns(0, dns.flags.DO, 0)

# DNS root has to be signed
try:
ans = res.query('.', 'NS')
except dns.exception.DNSException as e:
print 'DNS forwarder %s does not work: %s: %s' % (ip_addr,
type(e).__name__, e)
return None

try:
ans.response.find_rrset(ans.response.answer, dns.name.root,
dns.rdataclass.IN, dns.rdatatype.RRSIG, dns.rdatatype.NS)
except KeyError:
print 'DNS forwarder %s does not return DNSSEC signatures in answers.' % ip_addr
print 'Please fix forwarder configuration to enable DNSSEC support.'
print '(For BIND 9 add directive "dnssec-enable yes;" to "options {}")'

print '(debug) Received DNS response:'
print ans.response
return False

return True

print test_forwarder(sys.argv[1])
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

[Freeipa-devel] [PATCH] [WIP] DNSSEC check for DNS forwarders

[Petr Spacek]

Hello,

bad things will happen (i.e. external DNS resolution will not work) if 
configured DNS forwarders are not standard compliant, i.e. EDNS or DNSSEC 
support is not enabled.


For this reason I'm proposing to add explicit check to IPA installer and 
possibly even to dnsconfig-mod/dnszone-mod commands so forwarders can be 
tested before putting them in effect.


This check should detect failures soon and prevent surprises where IPA 
installs itself but DNS resolution doesn't work for some domains etc.


Please voice your concerns ASAP.

--
Petr^2 Spacek
import sys

import dns.resolver

def test_forwarder(ip_addr):
"""Test DNS forwarder properties.

:returns:
 True if forwarder works as expected and supports DNSSEC.
 False if forwarder does not support DNSSEC.
 None if forwarder does not respond.
"""
res = dns.resolver.Resolver()
res.nameservers = [ip_addr]

# enable Authenticated Data + Checking Disabled flags
res.set_flags(dns.flags.AD | dns.flags.CD)

# enable EDNS v0 + enable DNSSEC-Ok flag
res.use_edns(0, dns.flags.DO, 0)

# DNS root has to be signed
try:
ans = res.query('.', 'NS')
except dns.exception.DNSException as e:
print 'DNS forwarder %s does not work: %s: %s' % (ip_addr,
type(e).__name__, e)
return None

try:
ans.response.find_rrset(ans.response.answer, dns.name.root,
dns.rdataclass.IN, dns.rdatatype.RRSIG, dns.rdatatype.NS)
except KeyError:
print 'DNS forwarder %s does not return DNSSEC signatures in answers.' % ip_addr
print 'Please fix forwarder configuration to enable DNSSEC support.'
print '(For BIND 9 add directive "dnssec-enable yes;" to "options {}")'

print '(debug) Received DNS response:'
print ans.response
return False

return True

print test_forwarder(sys.argv[1])
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 0034] Missing requires on python-dns

[Martin Kosek]

On 10/08/2014 10:56 AM, Martin Basti wrote:
> On 07/10/14 19:34, Gabe Alford wrote:
>> Done. Update patch to use python-dns >= 1.11.1
>>
>> On Tue, Oct 7, 2014 at 11:26 AM, Martin Basti > > wrote:
>>
>> On 07/10/14 15:58, Gabe Alford wrote:
>>> Forgot to add patch.
>>>
>>> On Tue, Oct 7, 2014 at 7:58 AM, Gabe Alford
>>> mailto:redhatri...@gmail.com>> wrote:
>>>
>>> Hello,
>>>
>>>Fix for https://fedorahosted.org/freeipa/ticket/4613
>>>
>>> Thanks,
>>>
>>> Gabe
>>>
>>>
>>>
>>>
>>> ___
>>> Freeipa-devel mailing list
>>> Freeipa-devel@redhat.com  
>>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>>
>> Thank you!
>>
>> I prefer to use python-dns >= 1.11.1, there are some DNSSEC fixes
>> which we may use in tests.
>>
>> Could you send updated patch please?
>>
>>
>> -- Martin Basti
>>
>>
> ACK
> Thank you!

Pushed to:
master: 7b7567aabfb4954ef6df30f375800e6e93fa5f6a
ipa-4-1: 19f5ec840ebcbea5ce270a2a9c8e8a1654c4195d
ipa-4-0: f336bcbd9be139ff825433c055465e26f98b4f18

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 130] Missing DNS tests

[Martin Kosek]

On 10/09/2014 09:00 AM, David Kupka wrote:
> On 10/01/2014 01:42 PM, Martin Basti wrote:
>> This patch adds 2 missing DNS tests:
>> * removing non-existent permission
>> * removing idnssoamname value using dnszone-mod --name-server=
>>
>> Patch attached, belongs to ipa-4-1 and master branches.
>>
>>
>>
>> ___
>> Freeipa-devel mailing list
>> Freeipa-devel@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>>
> Works for me, ACK.
> 

I see I replied to wrong part of the thread :-) So just to repeat:

Pushed to:
master: 41015e6c9c5232a741314ba77df082ba7db55620
ipa-4-1: 6d10f98c6b1adae1687738e8240ae78991f48ba3


Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree

[Martin Kosek]

On 10/09/2014 09:33 AM, Ludwig Krispenz wrote:
> all the issues I found are fixed, for me it's ACK
> 
> On 10/08/2014 07:50 PM, Alexander Bokovoy wrote:
>> On Tue, 07 Oct 2014, Ludwig Krispenz wrote:
>>> Hi Alex,
>>>
>>> I have a question regarding cbdata.target. It is/was a reference to the
>>> pblock used to generate a new dn, but now in
>>> idview_replace_target_dn(&cbdata.target,...) it can be newly allocated and
>>> should be freed, so I think there should be a return code indicating if it
>>> was allocated or not.
>> Yes, good catch.
>>
>> I've fixed this and other issues raised in the review.
>>
>> I also fixed an issue with an initial lookup by an override. If someone
>> does a search by an override, we would replace uid|cn= by
>> uid= if it exists and by 
>> otherwise -- for groups we don't have ipaOriginalUid as they don't have
>> uids. Now, the filter would look like (ipaAnchorUUID=:SID:S-...) and if
>> there is no entry in the map cache, the search will return nothing, the
>> entry will be staged for lookup through SSSD.
>>
>> In the original version lookup in SSSD didn't take ipaAnchorUUID into
>> account, so the entry would not be found at all. I did add a call to
>> do sid2name first and then use the name to perform actual SSSD lookup.
>>
>> Works nicely now.
>>
>> New patch for slapi-nis is attached.

Great! What is the next step? If Nalin (CCed) is OK with the slapi-nis changes
as well, it would be great to have that pushed there.

Alexander, do you plan to do any other changes in slapi-nis in scope of FreeIPA
4.1? When the changes are ready, it would be nice to get slapi-nis released so
that we can bump FreeIPA slapi-nis requires.

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 130] Missing DNS tests

[Martin Kosek]

On 10/01/2014 01:42 PM, Martin Basti wrote:
> This patch adds 2 missing DNS tests:
> * removing non-existent permission
> * removing idnssoamname value using dnszone-mod --name-server=
> 
> Patch attached, belongs to ipa-4-1 and master branches.

Pushed to:
master: 41015e6c9c5232a741314ba77df082ba7db55620
ipa-4-1: 6d10f98c6b1adae1687738e8240ae78991f48ba3

Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0159-0160 Support ID views in compat tree

[Ludwig Krispenz]

all the issues I found are fixed, for me it's ACK

On 10/08/2014 07:50 PM, Alexander Bokovoy wrote:

On Tue, 07 Oct 2014, Ludwig Krispenz wrote:

Hi Alex,

I have a question regarding cbdata.target. It is/was a reference to 
the pblock used to generate a new dn, but now in 
idview_replace_target_dn(&cbdata.target,...) it can be newly 
allocated and should be freed, so I think there should be a return 
code indicating if it was allocated or not.

Yes, good catch.

I've fixed this and other issues raised in the review.

I also fixed an issue with an initial lookup by an override. If someone
does a search by an override, we would replace uid|cn= by
uid= if it exists and by 
otherwise -- for groups we don't have ipaOriginalUid as they don't have
uids. Now, the filter would look like (ipaAnchorUUID=:SID:S-...) and if
there is no entry in the map cache, the search will return nothing, the
entry will be staged for lookup through SSSD.

In the original version lookup in SSSD didn't take ipaAnchorUUID into
account, so the entry would not be found at all. I did add a call to
do sid2name first and then use the name to perform actual SSSD lookup.

Works nicely now.

New patch for slapi-nis is attached.


___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH 130] Missing DNS tests

[David Kupka]

On 10/01/2014 01:42 PM, Martin Basti wrote:

This patch adds 2 missing DNS tests:
* removing non-existent permission
* removing idnssoamname value using dnszone-mod --name-server=

Patch attached, belongs to ipa-4-1 and master branches.



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Works for me, ACK.

--
David Kupka

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel