Re: [Freeipa-devel] Is there RPC documentation?

[Rich Megginson]

On 02/26/2014 03:48 PM, Simo Sorce wrote:

On Wed, 2014-02-26 at 15:28 -0700, Rich Megginson wrote:

On 02/26/2014 03:22 PM, Rob Crittenden wrote:

Rich Megginson wrote:

On 02/26/2014 02:19 PM, Rob Crittenden wrote:

Rich Megginson wrote:

On 02/26/2014 08:53 AM, Petr Viktorin wrote:

On 02/26/2014 04:45 PM, Rich Megginson wrote:

I'm working on adding support for freeipa DNS to openstack designate
(DNSaaS).  I am assuming I need to use RPC (XML?  JSON? REST?) to
communicate with freeipa.  Is there documentation about how to
construct
and send RPC messages?

The JSON-RPC and XML-RPC API is still not "officially supported"
(read: documented), though it's extremely unlikely to change.
If you need an example, run any ipa command with -vv, this will print
out the request & response.
API.txt in the source tree lists all the commands and params.
This blog post still applies (but be sure to read the update about
--cacert):
http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/





Ok.  Next question is - how does one do the equivalent of the curl
command in python code?

Here is a pretty stripped-down way to add a user. Other commands are
similar, you just may care more about the output:

from ipalib import api
from ipalib import errors

api.bootstrap(context='cli')
api.finalize()
api.Backend.xmlclient.connect()

try:
 api.Command['user_add'](u'testuser',
 givenname=u'Test', sn=u'User',
 loginshell=u'/bin/sh')
except errors.DuplicateEntry:
 print "user already exists"
else:
 print "User added"


How would one do this from outside of ipa?  If ipalib is not available?

You'd need to go to either /ipa/xml or /ipa/json (depending on what
protocol you want to use) and issue one request there. This requires
Kerberos authentication. The response will include a cookie which you
should either ignore or store safely (like in the kernel keyring).
Using the cookie will significantly improve performance.

This is for the ipa dns backend for designate.  I'm assuming I will
either be using a keytab, or perhaps the new proxy?

At any rate, I have to do everything in python - including the kinit
with the keytab.

Lok at rob's damon but you should *not* do a kinit, you should just use
gssapi (see python-kerberos) and do a gss_init_sec_context there, if the
environment is configured (KRB5_KTNAME set correctly) then gssapi will
automatically kinit for you under the hood.


I guess I'm really looking for specifics - I've seen recommendations to
use the python libraries "requests" and "json".  I don't know if
requests supports negotiate/kerberos.  If not, is there a recommended
library to use?  As this particular project will be part of openstack,
perhaps there is a more "openstack"-y library, or even something
built-in to openstack (oslo?).  I think amqp support kerberos, so
perhaps there is some oslo.messaging thing that will do the http +
kerberos stuff.

Afaik there is nothing that does kerberos in openstack, you'll have to
introduce all that stuff.


Egads - implementing openstack-wide kerberos client libraries in order 
to add an ipa dns backend to designate.


Rob, need any help with your proxy?



HTH,
Simo.



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

Re: [Freeipa-devel] Is there RPC documentation?

[Rob Crittenden]

Dmitri Pal wrote:

On 02/26/2014 05:48 PM, Simo Sorce wrote:

On Wed, 2014-02-26 at 15:28 -0700, Rich Megginson wrote:

On 02/26/2014 03:22 PM, Rob Crittenden wrote:

Rich Megginson wrote:

On 02/26/2014 02:19 PM, Rob Crittenden wrote:

Rich Megginson wrote:

On 02/26/2014 08:53 AM, Petr Viktorin wrote:

On 02/26/2014 04:45 PM, Rich Megginson wrote:

I'm working on adding support for freeipa DNS to openstack
designate
(DNSaaS).  I am assuming I need to use RPC (XML?  JSON? REST?) to
communicate with freeipa.  Is there documentation about how to
construct
and send RPC messages?

The JSON-RPC and XML-RPC API is still not "officially supported"
(read: documented), though it's extremely unlikely to change.
If you need an example, run any ipa command with -vv, this will
print
out the request&  response.
API.txt in the source tree lists all the commands and params.
This blog post still applies (but be sure to read the update about
--cacert):
http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/






Ok.  Next question is - how does one do the equivalent of the curl
command in python code?

Here is a pretty stripped-down way to add a user. Other commands are
similar, you just may care more about the output:

from ipalib import api
from ipalib import errors

api.bootstrap(context='cli')
api.finalize()
api.Backend.xmlclient.connect()

try:
 api.Command['user_add'](u'testuser',
 givenname=u'Test', sn=u'User',
 loginshell=u'/bin/sh')
except errors.DuplicateEntry:
 print "user already exists"
else:
 print "User added"


How would one do this from outside of ipa?  If ipalib is not
available?

You'd need to go to either /ipa/xml or /ipa/json (depending on what
protocol you want to use) and issue one request there. This requires
Kerberos authentication. The response will include a cookie which you
should either ignore or store safely (like in the kernel keyring).
Using the cookie will significantly improve performance.

This is for the ipa dns backend for designate.  I'm assuming I will
either be using a keytab, or perhaps the new proxy?

At any rate, I have to do everything in python - including the kinit
with the keytab.

Lok at rob's damon but you should *not* do a kinit, you should just use
gssapi (see python-kerberos) and do a gss_init_sec_context there, if the
environment is configured (KRB5_KTNAME set correctly) then gssapi will
automatically kinit for you under the hood.


Yes look at Rob's smart proxy and use a similar approach.


This is a little different since the smart proxy is directly using ipalib.

You'll need to use python-kerberos to do the GSSAPI work. Basically you 
need to get a service ticket for the remote server using your TGT and 
pass that in the HTTP Authorization header.


There was a patch floating around for python-requests to do Kerberos but 
I'm not sure if it has been accepted upstream, or if it has if it is 
generally available. That patch may have been converted into a separate 
project, I found a repo at 
https://github.com/requests/requests-kerberos. At a glance it looks like 
this module does all the work for you.


To see how we do it, look in ipalib/rpc.py in the KerbTransport class, 
specifically in get_host_info(). That shows the calls IPA makes to get 
the information needed for the header, but this is for httplib.


rob

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

Re: [Freeipa-devel] [PATCH] 531-541 OTP UI

[Dmitri Pal]

On 02/26/2014 06:57 AM, Petr Vobornik wrote:

On 26.2.2014 01:55, Dmitri Pal wrote:

On 02/24/2014 10:21 AM, Nathaniel McCallum wrote:

On Mon, 2014-02-24 at 15:48 +0100, Petr Vobornik wrote:

On 24.2.2014 15:31, Nathaniel McCallum wrote:

On Mon, 2014-02-24 at 11:04 +0100, Petr Vobornik wrote:

On 21.2.2014 20:00, Nathaniel McCallum wrote:
Is it possible to do something more intelligent for the key and 
date

fields in the add-token UI?

Date fields are currently just a text box. Is there any sort of
calendar
we could use here? If not, I'm still unsure of what the format
should be
for this field.
It's the format you chose :), try to fill it in CLI, you will 
have the

same proble. From API level it's just string, from LDAP it's
generalized
time.

Is there a better option? I'm open to suggestions.
As I mentioned below, it's being implemented. The datetime patches 
will

be send separately. The core OTP UI patches should not be blocked by
them.

I've an UI patch prepared where you can write it in ISO format, 
with a

validator attached to it, so user will be noticed about the format,
but
it's waiting for:
https://www.redhat.com/archives/freeipa-devel/2014-January/msg00057.html 



https://www.redhat.com/archives/freeipa-devel/2014-January/msg00060.html 





The key field should probably have a note indicating that it is
Base32
encoding. It would also be nice to restrict the input to Base32
characters. Maybe even automatic case correction...
Actually I think it doesn't help much. Show me a person who can 
write
base32 encoded string But I agree that a validator with some 
regex

to limit the chars and a note that it should be base32 string is
better.
The question is what's the purpose of this field from user
perspective.
Is a human being suppose to fill it or is it meant to be only
filled by
some provisioning systems? In UI it's just as a backup?

If there is a use case where user is suppose to choose the key, it
would
be better to fill the key and convert it to base32 string on a 
server.

I can't think of any case where a user would use the key field.

However, there are at least two important cases where an admin 
would do

this:
1. Hardware tokens
2. Transferring OATH (TOTP/HOTP) tokens from another system

Nathaniel

What is the input format for these two cases? Is it base32 so admin 
can
enter it into UI or is it plain text so he has to use different 
tool to

encode it to base32 and then fill into UI?

In both of the above cases, I suspect the predominant use will be
scripts written to take a token store and import the tokens. This is
mostly a non-UI case.

RFC 6030 uses Base64 for unencrypted tokens. Base32 is also in wide 
use.

This is largely because, with fewer characters and no case-sensitivity,
Base32 is easier to type. I don't know of any other encodings in wide
use.

It would be nice to support both of them, but I'm not sure how this is
possible. Suggestions are welcome.


I do not think we should allow typing the key (and other attributes)
manually.
We should rather ask user to import a token or tokens from the XML file
that uses RFC6030.
There are vendors of the hardware tokens that actually using it to
distribute the tokens.

Here are the examples
http://www.gooze.eu/howto/oath-otp-tokens-howto/seed-codes-sample-files

Please click around the site for more info.



This is one vendor. Do we have information that the other ones (or 
just the major ones) use the XML PSKC schema from RFC6030 as well? If 
that's the case, we have enough information for implementing 
otp-import (design page says that we don't have enough info).


Back to UI. The UI might be useful if the admin has the values in 
different form than XML data, i.e., printed on a paper. Having the UI 
doesn't do any harm, right?


If vendors mostly use base64 keys, adding only base32 support in our 
API doesn't make much sense. IMO it actually adds more work because 
you have to convert it first.


Anyway: NACK for the patch because it shows totp/hotp switch in 
selfservice without possibility to define other hotp specifics. I'll 
remove it so there will be only totp in self-service (just token 
name+description).


I think we need to take an inspiration in the LinOTP solution UI.
See more details here: 
http://www.linotp.org/doc/2.6/part-management/managingtokens/import.html

It loos like Alladin, SafeNet, Fetian have these tokens in XML.

--
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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

Re: [Freeipa-devel] Is there RPC documentation?

[Dmitri Pal]

On 02/26/2014 05:48 PM, Simo Sorce wrote:

On Wed, 2014-02-26 at 15:28 -0700, Rich Megginson wrote:

On 02/26/2014 03:22 PM, Rob Crittenden wrote:

Rich Megginson wrote:

On 02/26/2014 02:19 PM, Rob Crittenden wrote:

Rich Megginson wrote:

On 02/26/2014 08:53 AM, Petr Viktorin wrote:

On 02/26/2014 04:45 PM, Rich Megginson wrote:

I'm working on adding support for freeipa DNS to openstack designate
(DNSaaS).  I am assuming I need to use RPC (XML?  JSON? REST?) to
communicate with freeipa.  Is there documentation about how to
construct
and send RPC messages?

The JSON-RPC and XML-RPC API is still not "officially supported"
(read: documented), though it's extremely unlikely to change.
If you need an example, run any ipa command with -vv, this will print
out the request&  response.
API.txt in the source tree lists all the commands and params.
This blog post still applies (but be sure to read the update about
--cacert):
http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/





Ok.  Next question is - how does one do the equivalent of the curl
command in python code?

Here is a pretty stripped-down way to add a user. Other commands are
similar, you just may care more about the output:

from ipalib import api
from ipalib import errors

api.bootstrap(context='cli')
api.finalize()
api.Backend.xmlclient.connect()

try:
 api.Command['user_add'](u'testuser',
 givenname=u'Test', sn=u'User',
 loginshell=u'/bin/sh')
except errors.DuplicateEntry:
 print "user already exists"
else:
 print "User added"


How would one do this from outside of ipa?  If ipalib is not available?

You'd need to go to either /ipa/xml or /ipa/json (depending on what
protocol you want to use) and issue one request there. This requires
Kerberos authentication. The response will include a cookie which you
should either ignore or store safely (like in the kernel keyring).
Using the cookie will significantly improve performance.

This is for the ipa dns backend for designate.  I'm assuming I will
either be using a keytab, or perhaps the new proxy?

At any rate, I have to do everything in python - including the kinit
with the keytab.

Lok at rob's damon but you should *not* do a kinit, you should just use
gssapi (see python-kerberos) and do a gss_init_sec_context there, if the
environment is configured (KRB5_KTNAME set correctly) then gssapi will
automatically kinit for you under the hood.


Yes look at Rob's smart proxy and use a similar approach.




I guess I'm really looking for specifics - I've seen recommendations to
use the python libraries "requests" and "json".  I don't know if
requests supports negotiate/kerberos.  If not, is there a recommended
library to use?  As this particular project will be part of openstack,
perhaps there is a more "openstack"-y library, or even something
built-in to openstack (oslo?).  I think amqp support kerberos, so
perhaps there is some oslo.messaging thing that will do the http +
kerberos stuff.

Afaik there is nothing that does kerberos in openstack, you'll have to
introduce all that stuff.

HTH,
Simo.




--
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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

Re: [Freeipa-devel] FreeIPA 3.4 -> 4.0

[Dmitri Pal]

On 02/26/2014 09:46 AM, Petr Viktorin wrote:

On 02/26/2014 12:24 PM, Martin Kosek wrote:

Hello all,

I would like to discuss a proposal that Simo had on FreeIPA devel 
meeting.
Given permission/ACI refactoring that Petr3 is working on, people may 
have
issues with access to their LDAP if they played too much with the 
default ACIs
or if they expect that some information stays accessible in the new 
version. It
may not stay accessible we are removing the SUFFIX level all allowing 
ACIs and

creating custom read ACIs.

Bottom line is we need to do our best in making our users aware that 
there are
big changes in this version they need to be aware of. One way is to 
release a

new major release with appropriate release notes.

I support that move, I think we have enough big features planned to 
justify new

major release:

* Permissions/ACIs
* OTP
* DNSSEC (hopefully)
* CA Certificate Management Tool
* Big Web UI face lift and refactoring
* ...

If there is no push back against that idea, let's do it. I would then 
rename

the 3.4 milestones to 4.0 and 3.5 milestones to 4.1.



+1

I guess the http://www.freeipa.org/page/V3 tree will also need some 
renaming.


I am concerned that it will do more harm than good but do not have valid 
arguments against.

So +1 from me too.

--
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


---
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/



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

Re: [Freeipa-devel] Is there RPC documentation?

[Simo Sorce]

On Wed, 2014-02-26 at 15:28 -0700, Rich Megginson wrote:
> On 02/26/2014 03:22 PM, Rob Crittenden wrote:
> > Rich Megginson wrote:
> >> On 02/26/2014 02:19 PM, Rob Crittenden wrote:
> >>> Rich Megginson wrote:
>  On 02/26/2014 08:53 AM, Petr Viktorin wrote:
> > On 02/26/2014 04:45 PM, Rich Megginson wrote:
> >> I'm working on adding support for freeipa DNS to openstack designate
> >> (DNSaaS).  I am assuming I need to use RPC (XML?  JSON? REST?) to
> >> communicate with freeipa.  Is there documentation about how to
> >> construct
> >> and send RPC messages?
> >
> > The JSON-RPC and XML-RPC API is still not "officially supported"
> > (read: documented), though it's extremely unlikely to change.
> > If you need an example, run any ipa command with -vv, this will print
> > out the request & response.
> > API.txt in the source tree lists all the commands and params.
> > This blog post still applies (but be sure to read the update about
> > --cacert):
> > http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/
> >  
> >
> >
> >
> >
> 
>  Ok.  Next question is - how does one do the equivalent of the curl
>  command in python code?
> >>>
> >>> Here is a pretty stripped-down way to add a user. Other commands are
> >>> similar, you just may care more about the output:
> >>>
> >>> from ipalib import api
> >>> from ipalib import errors
> >>>
> >>> api.bootstrap(context='cli')
> >>> api.finalize()
> >>> api.Backend.xmlclient.connect()
> >>>
> >>> try:
> >>> api.Command['user_add'](u'testuser',
> >>> givenname=u'Test', sn=u'User',
> >>> loginshell=u'/bin/sh')
> >>> except errors.DuplicateEntry:
> >>> print "user already exists"
> >>> else:
> >>> print "User added"
> >>>
> >>
> >> How would one do this from outside of ipa?  If ipalib is not available?
> >
> > You'd need to go to either /ipa/xml or /ipa/json (depending on what 
> > protocol you want to use) and issue one request there. This requires 
> > Kerberos authentication. The response will include a cookie which you 
> > should either ignore or store safely (like in the kernel keyring). 
> > Using the cookie will significantly improve performance.
> 
> This is for the ipa dns backend for designate.  I'm assuming I will 
> either be using a keytab, or perhaps the new proxy?
> 
> At any rate, I have to do everything in python - including the kinit 
> with the keytab.

Lok at rob's damon but you should *not* do a kinit, you should just use
gssapi (see python-kerberos) and do a gss_init_sec_context there, if the
environment is configured (KRB5_KTNAME set correctly) then gssapi will
automatically kinit for you under the hood.

> I guess I'm really looking for specifics - I've seen recommendations to 
> use the python libraries "requests" and "json".  I don't know if 
> requests supports negotiate/kerberos.  If not, is there a recommended 
> library to use?  As this particular project will be part of openstack, 
> perhaps there is a more "openstack"-y library, or even something 
> built-in to openstack (oslo?).  I think amqp support kerberos, so 
> perhaps there is some oslo.messaging thing that will do the http + 
> kerberos stuff.

Afaik there is nothing that does kerberos in openstack, you'll have to
introduce all that stuff.

HTH,
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] Is there RPC documentation?

[Rob Crittenden]

Rich Megginson wrote:

On 02/26/2014 02:19 PM, Rob Crittenden wrote:

Rich Megginson wrote:

On 02/26/2014 08:53 AM, Petr Viktorin wrote:

On 02/26/2014 04:45 PM, Rich Megginson wrote:

I'm working on adding support for freeipa DNS to openstack designate
(DNSaaS).  I am assuming I need to use RPC (XML?  JSON? REST?) to
communicate with freeipa.  Is there documentation about how to
construct
and send RPC messages?


The JSON-RPC and XML-RPC API is still not "officially supported"
(read: documented), though it's extremely unlikely to change.
If you need an example, run any ipa command with -vv, this will print
out the request & response.
API.txt in the source tree lists all the commands and params.
This blog post still applies (but be sure to read the update about
--cacert):
http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/





Ok.  Next question is - how does one do the equivalent of the curl
command in python code?


Here is a pretty stripped-down way to add a user. Other commands are
similar, you just may care more about the output:

from ipalib import api
from ipalib import errors

api.bootstrap(context='cli')
api.finalize()
api.Backend.xmlclient.connect()

try:
api.Command['user_add'](u'testuser',
givenname=u'Test', sn=u'User',
loginshell=u'/bin/sh')
except errors.DuplicateEntry:
print "user already exists"
else:
print "User added"



How would one do this from outside of ipa?  If ipalib is not available?


You'd need to go to either /ipa/xml or /ipa/json (depending on what 
protocol you want to use) and issue one request there. This requires 
Kerberos authentication. The response will include a cookie which you 
should either ignore or store safely (like in the kernel keyring). Using 
the cookie will significantly improve performance.


If you store the cookie then you can make future requests to 
/ipa/session/{xml|json} unless a Kerberos error is raised, in which case 
things start over again.


You'll need to include a Referer header in your request, see the -vv 
output of the ipa command for samples.


rob

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

Re: [Freeipa-devel] Is there RPC documentation?

[Rich Megginson]

On 02/26/2014 03:22 PM, Rob Crittenden wrote:

Rich Megginson wrote:

On 02/26/2014 02:19 PM, Rob Crittenden wrote:

Rich Megginson wrote:

On 02/26/2014 08:53 AM, Petr Viktorin wrote:

On 02/26/2014 04:45 PM, Rich Megginson wrote:

I'm working on adding support for freeipa DNS to openstack designate
(DNSaaS).  I am assuming I need to use RPC (XML?  JSON? REST?) to
communicate with freeipa.  Is there documentation about how to
construct
and send RPC messages?


The JSON-RPC and XML-RPC API is still not "officially supported"
(read: documented), though it's extremely unlikely to change.
If you need an example, run any ipa command with -vv, this will print
out the request & response.
API.txt in the source tree lists all the commands and params.
This blog post still applies (but be sure to read the update about
--cacert):
http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ 







Ok.  Next question is - how does one do the equivalent of the curl
command in python code?


Here is a pretty stripped-down way to add a user. Other commands are
similar, you just may care more about the output:

from ipalib import api
from ipalib import errors

api.bootstrap(context='cli')
api.finalize()
api.Backend.xmlclient.connect()

try:
api.Command['user_add'](u'testuser',
givenname=u'Test', sn=u'User',
loginshell=u'/bin/sh')
except errors.DuplicateEntry:
print "user already exists"
else:
print "User added"



How would one do this from outside of ipa?  If ipalib is not available?


You'd need to go to either /ipa/xml or /ipa/json (depending on what 
protocol you want to use) and issue one request there. This requires 
Kerberos authentication. The response will include a cookie which you 
should either ignore or store safely (like in the kernel keyring). 
Using the cookie will significantly improve performance.


This is for the ipa dns backend for designate.  I'm assuming I will 
either be using a keytab, or perhaps the new proxy?


At any rate, I have to do everything in python - including the kinit 
with the keytab.


I guess I'm really looking for specifics - I've seen recommendations to 
use the python libraries "requests" and "json".  I don't know if 
requests supports negotiate/kerberos.  If not, is there a recommended 
library to use?  As this particular project will be part of openstack, 
perhaps there is a more "openstack"-y library, or even something 
built-in to openstack (oslo?).  I think amqp support kerberos, so 
perhaps there is some oslo.messaging thing that will do the http + 
kerberos stuff.




If you store the cookie then you can make future requests to 
/ipa/session/{xml|json} unless a Kerberos error is raised, in which 
case things start over again.


You'll need to include a Referer header in your request, see the -vv 
output of the ipa command for samples.


rob


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

Re: [Freeipa-devel] Is there RPC documentation?

[Rich Megginson]

On 02/26/2014 02:19 PM, Rob Crittenden wrote:

Rich Megginson wrote:

On 02/26/2014 08:53 AM, Petr Viktorin wrote:

On 02/26/2014 04:45 PM, Rich Megginson wrote:

I'm working on adding support for freeipa DNS to openstack designate
(DNSaaS).  I am assuming I need to use RPC (XML?  JSON? REST?) to
communicate with freeipa.  Is there documentation about how to 
construct

and send RPC messages?


The JSON-RPC and XML-RPC API is still not "officially supported"
(read: documented), though it's extremely unlikely to change.
If you need an example, run any ipa command with -vv, this will print
out the request & response.
API.txt in the source tree lists all the commands and params.
This blog post still applies (but be sure to read the update about
--cacert):
http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ 






Ok.  Next question is - how does one do the equivalent of the curl
command in python code?


Here is a pretty stripped-down way to add a user. Other commands are 
similar, you just may care more about the output:


from ipalib import api
from ipalib import errors

api.bootstrap(context='cli')
api.finalize()
api.Backend.xmlclient.connect()

try:
api.Command['user_add'](u'testuser',
givenname=u'Test', sn=u'User',
loginshell=u'/bin/sh')
except errors.DuplicateEntry:
print "user already exists"
else:
print "User added"



How would one do this from outside of ipa?  If ipalib is not available?

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

Re: [Freeipa-devel] Is there RPC documentation?

[Rob Crittenden]

Rich Megginson wrote:

On 02/26/2014 08:53 AM, Petr Viktorin wrote:

On 02/26/2014 04:45 PM, Rich Megginson wrote:

I'm working on adding support for freeipa DNS to openstack designate
(DNSaaS).  I am assuming I need to use RPC (XML?  JSON?  REST?) to
communicate with freeipa.  Is there documentation about how to construct
and send RPC messages?


The JSON-RPC and XML-RPC API is still not "officially supported"
(read: documented), though it's extremely unlikely to change.
If you need an example, run any ipa command with -vv, this will print
out the request & response.
API.txt in the source tree lists all the commands and params.
This blog post still applies (but be sure to read the update about
--cacert):
http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/




Ok.  Next question is - how does one do the equivalent of the curl
command in python code?


Here is a pretty stripped-down way to add a user. Other commands are 
similar, you just may care more about the output:


from ipalib import api
from ipalib import errors

api.bootstrap(context='cli')
api.finalize()
api.Backend.xmlclient.connect()

try:
api.Command['user_add'](u'testuser',
givenname=u'Test', sn=u'User',
loginshell=u'/bin/sh')
except errors.DuplicateEntry:
print "user already exists"
else:
print "User added"

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

Re: [Freeipa-devel] Is there RPC documentation?

[Rich Megginson]

On 02/26/2014 08:53 AM, Petr Viktorin wrote:

On 02/26/2014 04:45 PM, Rich Megginson wrote:

I'm working on adding support for freeipa DNS to openstack designate
(DNSaaS).  I am assuming I need to use RPC (XML?  JSON?  REST?) to
communicate with freeipa.  Is there documentation about how to construct
and send RPC messages?


The JSON-RPC and XML-RPC API is still not "officially supported" 
(read: documented), though it's extremely unlikely to change.
If you need an example, run any ipa command with -vv, this will print 
out the request & response.

API.txt in the source tree lists all the commands and params.
This blog post still applies (but be sure to read the update about 
--cacert): 
http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/




Ok.  Next question is - how does one do the equivalent of the curl 
command in python code?


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

Re: [Freeipa-devel] [PATCH] 6 webui: Too big font in input fields

[Adam Misnyovszki]

- Original Message -
> From: "Petr Vobornik" 
> To: "Adam Misnyovszki" , freeipa-devel@redhat.com, 
> "Martin Kosek" 
> Sent: Wednesday, February 26, 2014 2:32:52 PM
> Subject: Re: [Freeipa-devel] [PATCH] Too big font in input fields
> 
> On 26.2.2014 13:00, Adam Misnyovszki wrote:
> > Hi,
> > too big font issue in ipa-3-3 and Firefox 27 fixed:
> >
> > In Firefox 27, default font size has bigger priority than body css,
> > text input font size is therefore explicitly set to 1em
> >
> > https://fedorahosted.org/freeipa/ticket/4180
> >
> > Thanks:
> > Adam
> >
> >
> 
> NACK
> 
> The issue is not present only in textboxes but also in comboboxes and
> selects. Btw, why the height: 12px?

It was because FF overwritten not only the font-size, but also the font-family. 
Fixed.

> 
> I suggest to use:
> 
> input, select, textarea {
>  font-size: 1em
> }
> 
> this should set the defaults for the whole UI.

Done.

> 
> In other topic Dmitri complained about ugliness of trust UI in 3.3
> because of jammed radios and labels. Martin, can we steal this CSS
> ticket and fix it with?
> 
> input[type=radio], input[type=checkbox],
> .ui-widget input[type=radio], .ui-widget input[type=checkbox]{
>  margin-right: 5px;
>  position: relative;
>  top: 2px;
> }
> --
> Petr Vobornik
> 

Done.

Thanks
Adam

From aefb2f2e868af963ad318a8fd512cf6a36ce72d7 Mon Sep 17 00:00:00 2001
From: Adam Misnyovszki 
Date: Wed, 26 Feb 2014 18:16:45 +0100
Subject: [PATCH] Too big font in input fields

In Firefox 27, default font size has bigger priority than body css,
text input font size is therefore explicitly set to 1em. Also
checkbox/radiobutton styling fixed.

https://fedorahosted.org/freeipa/ticket/4180
---
 install/ui/ipa.css | 12 
 1 file changed, 12 insertions(+)

diff --git a/install/ui/ipa.css b/install/ui/ipa.css
index ad3d1aa1f8f8898ad8dff8f8ecc175238fad1181..29dfe80aacfa1e508f59d3008b2aa57f9477a448 100644
--- a/install/ui/ipa.css
+++ b/install/ui/ipa.css
@@ -1243,6 +1243,18 @@ table.scrollable tbody {
 width: 250px;
 }
 
+input, select, textarea {
+font-size: 1em;
+font-family: "Liberation Sans",Arial,Sans;
+}
+
+input[type=radio], input[type=checkbox],
+.ui-widget input[type=radio], .ui-widget input[type=checkbox]{
+ margin-right: 5px;
+ position: relative;
+ top: 3px;
+}
+
 .multivalued-widget [name=value] {
 margin-bottom: 1em;
 }
-- 
1.8.5.3

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

Re: [Freeipa-devel] DNSSEC design page

[Petr Spacek]

On 26.2.2014 15:20, Ludwig Krispenz wrote:

I was talking about 'layer of indirection' previously. I'm digging into
details and it seems like a good idea to imitate what DNS registrars do
- use concept of key sets. It means that keys are not linked to a zone
one by one but rather a whole set of keys is linked to a zone.

It eases key rotation because you just need to drop a new key to a key
set and you don't have to add DNs of all zones to the new key (or the
other way around).

Another thing is that you could have different key rotation policies for
different key sets... we need to think about it carefully.

For example (without policies for now):
- two DNS zones example.com and example.net contain a pointer to keyset
called 'setA'
- zone objects: idnsname=example.net,cn=dns and idnsname=example.com,cn=dns

- key sets are stored under cn=keysets, cn=sec, cn=dns

- individual keys are stored under keyid=key1, keysetid=setA,
cn=keysets, cn=sec, cn=dns


How will the PKCS#11 module know into which keyset to store a key generated
by OpenDNSSEC? Are you suggesting having a separate slot/token for each
keyset? I would like to keep the number of tokens low, because there are
applications which go slot by slot, token by token when searching for
objects (e.g. BIND and OpenSSH) and that might generate a lot of unnecessary
traffic if the number of slots/tokens is high.
Okay, then we can store all DNSSEC keys in one slot and use "key sets" only 
for administrative purposes (i.e. pairing zone <=> keys in BIND) but it will 
be invisible for PKCS#11 interface.


Key set maintenance has to go over side channel for metadata and not over 
PKCS#11.


The pkcs11 data stored in ldap should represent pkcs11 objects. Other entries
could reference these objects, eg a zone referencing a key. I don't think we
should store references to other entries in an pkcs11 object. if you want this
we probably need another auxiliary objectclass for these pkcs11 entries.

Regarding objectclasses for the pkcs11 objects, what should be the structural
objectclass and what the naming attribute ?
So far I had defined the publicKey, privateKey, certificate objectclass all as
auxiliary, maybe we should have one structural like pkcs11Object containing
the required attrs like id, label, ...
and a naming attr if it is not one of them

This sounds like a good idea.

--
Petr^2 Spacek

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

Re: [Freeipa-devel] [PATCH] 0139 trustdomain_find: make sure we skip short entries when --pkey-only is specified

[Alexander Bokovoy]

On Wed, 26 Feb 2014, Martin Kosek wrote:

On 02/25/2014 06:56 PM, Alexander Bokovoy wrote:

Hi,

Simple patch to fix KeyError as --pkey-only causes no attributes to be
returned and trustdomain_find.post_callback checked them
unconditionally.


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


Can we simply skip the whole loop when options.get('pkey_only', False)? I.e.:

   def post_callback(self, ldap, entries, truncated, *args, **options):
   if not options.get('pkey_only', False):
   trust_dn = self.obj.get_dn(args[0], trust_type=u'ad')
   trust_entry = ldap.get_entry(trust_dn)
   ...

It seems to me that your way we still do one unnecessary LDAP search which is
never used. With pkey_only we should not be filling anything in post_callback
at all if it is not affecting the pkey.

Right, new patch attached.

--
/ Alexander Bokovoy
>From d6cc7f93bffcd6fd2be9f34c0aad0bb06b88c8d7 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy 
Date: Wed, 26 Feb 2014 17:59:05 +0200
Subject: [PATCH 7/7] trustdomain_find: make sure we skip short entries when 
 --pkey-only is specified

With --pkey-only only primary key is returned. It makes no sense to check and
replace boolean values then.

https://fedorahosted.org/freeipa/ticket/4196
---
 ipalib/plugins/trust.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py
index 0b6db27..353c6c7 100644
--- a/ipalib/plugins/trust.py
+++ b/ipalib/plugins/trust.py
@@ -1191,6 +1191,8 @@ class trustdomain_find(LDAPSearch):
 return (filters, base_dn, ldap.SCOPE_SUBTREE)
 
 def post_callback(self, ldap, entries, truncated, *args, **options):
+if options.get('pkey_only', False):
+return
 trust_dn = self.obj.get_dn(args[0], trust_type=u'ad')
 trust_entry = ldap.get_entry(trust_dn)
 for entry in entries:
-- 
1.8.3.1

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

Re: [Freeipa-devel] Is there RPC documentation?

[Rich Megginson]

On 02/26/2014 09:18 AM, Petr Vobornik wrote:

On 26.2.2014 16:53, Petr Viktorin wrote:

On 02/26/2014 04:45 PM, Rich Megginson wrote:

I'm working on adding support for freeipa DNS to openstack designate
(DNSaaS).  I am assuming I need to use RPC (XML?  JSON? REST?) to
communicate with freeipa.  Is there documentation about how to 
construct

and send RPC messages?


The JSON-RPC and XML-RPC API is still not "officially supported" (read:
documented), though it's extremely unlikely to change.
If you need an example, run any ipa command with -vv, this will print
out the request & response.
API.txt in the source tree lists all the commands and params.
This blog post still applies (but be sure to read the update about
--cacert):
http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ 






Web UI communicates with API through JSON-RPC so you can open browser 
developer tools (F12) and inspect requests/responses in network tab.


Thanks.  Would rather use cli, but that's good to know.

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

Re: [Freeipa-devel] Is there RPC documentation?

[Petr Vobornik]

On 26.2.2014 16:53, Petr Viktorin wrote:

On 02/26/2014 04:45 PM, Rich Megginson wrote:

I'm working on adding support for freeipa DNS to openstack designate
(DNSaaS).  I am assuming I need to use RPC (XML?  JSON?  REST?) to
communicate with freeipa.  Is there documentation about how to construct
and send RPC messages?


The JSON-RPC and XML-RPC API is still not "officially supported" (read:
documented), though it's extremely unlikely to change.
If you need an example, run any ipa command with -vv, this will print
out the request & response.
API.txt in the source tree lists all the commands and params.
This blog post still applies (but be sure to read the update about
--cacert):
http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/




Web UI communicates with API through JSON-RPC so you can open browser 
developer tools (F12) and inspect requests/responses in network tab.

--
Petr Vobornik

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

Re: [Freeipa-devel] [PATCH] 544 webui: Focus expand/collapse link in batch_error dialog

[Adam Misnyovszki]

- Original Message -
> From: "Petr Vobornik" 
> To: "freeipa-devel" 
> Sent: Tuesday, February 25, 2014 2:19:21 PM
> Subject: [Freeipa-devel] [PATCH] 544 webui: Focus expand/collapse link in 
> batch_error dialog
> 
> Dialog loses focus when the links are clicked making the dialog
> uncontrollable by keyboard. This patch focuses the link again after
> expanding/collapsing the error list. Thus keeping the focus in a dialog
> 
> https://fedorahosted.org/freeipa/ticket/4097
> --
> Petr Vobornik

ACK

works fine on FF26, 27, GC33

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

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

[Freeipa-devel] [PATCH] 0143: catch access denial when removing old trust object when using non-privileged AD user to create trust

[Alexander Bokovoy]

Hi,

this patch fixes a case when non-privileged AD user account is used to
re-establish trust. We need to catch one specific exception in deleting
the old trust and bail out earlier with proper error message.

https://fedorahosted.org/freeipa/ticket/4202
--
/ Alexander Bokovoy
>From 1ffd12988778fd9fcec3ad5436fd79753087ebfb Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy 
Date: Wed, 26 Feb 2014 17:43:34 +0200
Subject: [PATCH 6/6] ipaserver/dcerpc: catch the case of insuffient
 permissions when establishing trust

We attempt to delete the trust that might exist already. If there are not enough
privileges to do so, we wouldn't be able to create trust at the next step and 
it will fail.
However, failure to create trust will be due to the name collision as we 
already had
the trust with the same name before. Thus, raise access denied exception here
to properly indicate wrong access level instead of returning 
NT_STATUS_OBJECT_NAME_COLLISION.

https://fedorahosted.org/freeipa/ticket/4202
---
 ipaserver/dcerpc.py | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py
index d809c41..5972e62 100644
--- a/ipaserver/dcerpc.py
+++ b/ipaserver/dcerpc.py
@@ -892,8 +892,11 @@ class TrustDomainInstance(object):
 dname.string = another_domain.info['dns_domain']
 res = self._pipe.QueryTrustedDomainInfoByName(self._policy_handle, 
dname, lsa.LSA_TRUSTED_DOMAIN_INFO_FULL_INFO)
 self._pipe.DeleteTrustedDomain(self._policy_handle, 
res.info_ex.sid)
-except RuntimeError, e:
-pass
+except RuntimeError, (num, message):
+# Ignore anything but access denied (NT_STATUS_ACCESS_DENIED)
+if num == -1073741790:
+raise access_denied_error
+
 try:
 trustdom_handle = 
self._pipe.CreateTrustedDomainEx2(self._policy_handle, info, self.auth_info, 
security.SEC_STD_DELETE)
 except RuntimeError, (num, message):
-- 
1.8.3.1

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

Re: [Freeipa-devel] Is there RPC documentation?

[Petr Viktorin]

On 02/26/2014 04:45 PM, Rich Megginson wrote:

I'm working on adding support for freeipa DNS to openstack designate
(DNSaaS).  I am assuming I need to use RPC (XML?  JSON?  REST?) to
communicate with freeipa.  Is there documentation about how to construct
and send RPC messages?


The JSON-RPC and XML-RPC API is still not "officially supported" (read: 
documented), though it's extremely unlikely to change.
If you need an example, run any ipa command with -vv, this will print 
out the request & response.

API.txt in the source tree lists all the commands and params.
This blog post still applies (but be sure to read the update about 
--cacert): 
http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/


--
Petr³

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

Re: [Freeipa-devel] [PATCH] 0139 trustdomain_find: make sure we skip short entries when --pkey-only is specified

[Martin Kosek]

On 02/25/2014 06:56 PM, Alexander Bokovoy wrote:
> Hi,
> 
> Simple patch to fix KeyError as --pkey-only causes no attributes to be
> returned and trustdomain_find.post_callback checked them
> unconditionally.
> 
> 
> https://fedorahosted.org/freeipa/ticket/4196

Can we simply skip the whole loop when options.get('pkey_only', False)? I.e.:

def post_callback(self, ldap, entries, truncated, *args, **options):
if not options.get('pkey_only', False):
trust_dn = self.obj.get_dn(args[0], trust_type=u'ad')
trust_entry = ldap.get_entry(trust_dn)
...

It seems to me that your way we still do one unnecessary LDAP search which is
never used. With pkey_only we should not be filling anything in post_callback
at all if it is not affecting the pkey.

Martin

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

Re: [Freeipa-devel] [PATCH] Too big font in input fields

[Martin Kosek]

On 02/26/2014 02:45 PM, Adam Misnyovszki wrote:
> 
> 
> - Original Message -
>> From: "Petr Vobornik" 
>> To: "Adam Misnyovszki" , freeipa-devel@redhat.com, 
>> "Martin Kosek" 
>> Sent: Wednesday, February 26, 2014 2:32:52 PM
>> Subject: Re: [Freeipa-devel] [PATCH] Too big font in input fields
...
>> this should set the defaults for the whole UI.
>>
>> In other topic Dmitri complained about ugliness of trust UI in 3.3
>> because of jammed radios and labels. Martin, can we steal this CSS
>> ticket and fix it with?

Given it is this little change I think you can.

>>
>> input[type=radio], input[type=checkbox],
>> .ui-widget input[type=radio], .ui-widget input[type=checkbox]{
>>  margin-right: 5px;
>>  position: relative;
>>  top: 2px;
>> }
> 
> Will try this also

Martin

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

[Freeipa-devel] Is there RPC documentation?

[Rich Megginson]

I'm working on adding support for freeipa DNS to openstack designate 
(DNSaaS).  I am assuming I need to use RPC (XML?  JSON?  REST?) to 
communicate with freeipa.  Is there documentation about how to construct 
and send RPC messages?


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

[Freeipa-devel] [PATCH 0007][DOC] Tip on restoring admin account

[Gabe Alford]

Hi all,

I added a tip in the deleting users section on restoring admin account.
Please review.

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

Thanks,

Gabe


freeipa-rga-0007-DOC-Document-steps-to-restore-deleted-admin-account.patch
Description: Binary data
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] DNSSEC design page

[Simo Sorce]

On Wed, 2014-02-26 at 15:04 +0100, Jan Cholasta wrote:
> On 25.2.2014 20:22, Simo Sorce wrote:
> > On Tue, 2014-02-25 at 13:22 -0500, Rob Crittenden wrote:
> >> Jan Cholasta wrote:
> >>> On 25.2.2014 17:36, Ludwig Krispenz wrote:
> 
>  On 02/25/2014 05:12 PM, Simo Sorce wrote:
> > On Tue, 2014-02-25 at 16:18 +0100, Jan Cholasta wrote:
> >> On 25.2.2014 16:11, Simo Sorce wrote:
> >>> On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote:
>  On 25.2.2014 15:11, Simo Sorce wrote:
> > On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote:
> >>> Any reason why we should follow in detail what softshm does ?
> >> because I did't know what is really needed. If you want to have a
> >> pkcs11
> >> module, which stores data in ldap, I though it should have all the
> >> attributes potentially needed.
> >> Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP,
> >> CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE,
> >> CKA_EXTRACTABLE,
> >> so there is at least one requirement for fine grained attributes.
> > Does OpenDNSSEC store them as separate entities and need access
> > to them
> > independently ?
>  AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP
>  schema
>  doesn't matter as long as our PKCS#11 module can derive all values
>  defined by
>  standard.
> 
>  Honza, you did investigate OpenDNSSEC integration, please add some
>  details if
>  you can.
> 
> > Or is this internal use that can be satisfied by unpacking a blob in
> > OpenDNSSEC ?
> >
> > What does bind9 uses ? Petr, can you provide example key files ?
>  Private+public keys stored in files:
>  https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html
> 
> 
>  Private keys stored in HSM and public keys in files:
>  https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html
> 
>  (I.e. some values in .private file are replaced by PKCS#11 label.)
> >>> Ok it seem clear to me we do not need to spell out a lot of values
> >>> when
> >>> using pkcs#11 as bind doesn't need them in the key files. So I
> >>> assume it
> >>> can query the pkcs#11 module to find what it needs.
> >>>
> >>> I would use these key files as a sort of guide to understand what we
> >>> need in LDAP. I would try to put in a single blob as much as we can
> >>> that
> >>> we do not explicitly need by a client querying LDAP directly.
> >>>
> >>> I think in order to nail down exactly what we need, at this point, we
> >>> require some example use cases and queries the various clients would
> >>> perform with spelled out what they are looking for to identify or
> >>> manipulate keys.
> >>>
> >>> Simo.
> >>>
> >> See "How applications interact with PKCS#11" at
> >> . Tl;dr: applications
> >> don't search for keys by key data, but by metadata, so like I said in
> >> the other thread, key data can be in a single blob, but metadata should
> >> be in separate attributes.
> > Ah sorry, I hadn't looked at that one yet.
> > It helps quite a bit.
> >
> > So are the class, key_type, id, label, token, 'sign' the only values we
> > should really care to split off ?
> >>>
> >>> They are all metadata related to PKCS#11 operation. I don't think you
> >>> can easily encode them in PKCS#8 or certificate blob, so they actually
> >>> need to be split off. You can find the full list of them in the PKCS#11
> >>> spec (link below).
> >>>
> >
> > Can you describe what are these values ?
> > What is class ? Why is it important, and how does it differ from
> > key_type ?
> > What is the token ? What is 'sign' ?
> >
> > Feel free to give references to specific documents to read up about
> > these attributes.
>  I'm a newcomer to this area and am orienting myself at this doc:
>  ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf
>  and looking into opendnssec andsofthsm code.
> >>>
> >>> I use mainly
> >>> , as
> >>> 2.30 is a draft ATM.
> >>>
> 
>  It explains CKA_SIGN as:
>  "TheCKA_SIGN attribute of the signature key, whic h indicates whether
>  the key supports signatures with appendix, must be CK_TRUE."
>  I cannot tell if this will be needed, just can make up an attribute and
>  allow it in an objectclass :-)
> >>>
> >>> OpenDNSSEC puts it in public key objects it generates, so it's needed at
> >>> least for the sake of it.
> >>>
> >>> Actually, I think we should support all of the metadata attributes, so
> >>> that our PKCS#11 modu

Re: [Freeipa-devel] FreeIPA 3.4 -> 4.0

[Petr Viktorin]

On 02/26/2014 12:24 PM, Martin Kosek wrote:

Hello all,

I would like to discuss a proposal that Simo had on FreeIPA devel meeting.
Given permission/ACI refactoring that Petr3 is working on, people may have
issues with access to their LDAP if they played too much with the default ACIs
or if they expect that some information stays accessible in the new version. It
may not stay accessible we are removing the SUFFIX level all allowing ACIs and
creating custom read ACIs.

Bottom line is we need to do our best in making our users aware that there are
big changes in this version they need to be aware of. One way is to release a
new major release with appropriate release notes.

I support that move, I think we have enough big features planned to justify new
major release:

* Permissions/ACIs
* OTP
* DNSSEC (hopefully)
* CA Certificate Management Tool
* Big Web UI face lift and refactoring
* ...

If there is no push back against that idea, let's do it. I would then rename
the 3.4 milestones to 4.0 and 3.5 milestones to 4.1.



+1

I guess the http://www.freeipa.org/page/V3 tree will also need some 
renaming.


--
Petr³

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

Re: [Freeipa-devel] DNSSEC design page

[Rob Crittenden]

Jan Cholasta wrote:

On 25.2.2014 20:22, Simo Sorce wrote:

On Tue, 2014-02-25 at 13:22 -0500, Rob Crittenden wrote:

Jan Cholasta wrote:

On 25.2.2014 17:36, Ludwig Krispenz wrote:


On 02/25/2014 05:12 PM, Simo Sorce wrote:

On Tue, 2014-02-25 at 16:18 +0100, Jan Cholasta wrote:

On 25.2.2014 16:11, Simo Sorce wrote:

On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote:

On 25.2.2014 15:11, Simo Sorce wrote:

On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote:

Any reason why we should follow in detail what softshm does ?

because I did't know what is really needed. If you want to
have a
pkcs11
module, which stores data in ldap, I though it should have
all the
attributes potentially needed.
Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP,
CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE,
CKA_EXTRACTABLE,
so there is at least one requirement for fine grained
attributes.

Does OpenDNSSEC store them as separate entities and need access
to them
independently ?

AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP
schema
doesn't matter as long as our PKCS#11 module can derive all values
defined by
standard.

Honza, you did investigate OpenDNSSEC integration, please add some
details if
you can.


Or is this internal use that can be satisfied by unpacking a
blob in
OpenDNSSEC ?

What does bind9 uses ? Petr, can you provide example key files ?

Private+public keys stored in files:
https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html



Private keys stored in HSM and public keys in files:
https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html


(I.e. some values in .private file are replaced by PKCS#11 label.)

Ok it seem clear to me we do not need to spell out a lot of values
when
using pkcs#11 as bind doesn't need them in the key files. So I
assume it
can query the pkcs#11 module to find what it needs.

I would use these key files as a sort of guide to understand
what we
need in LDAP. I would try to put in a single blob as much as we can
that
we do not explicitly need by a client querying LDAP directly.

I think in order to nail down exactly what we need, at this
point, we
require some example use cases and queries the various clients
would
perform with spelled out what they are looking for to identify or
manipulate keys.

Simo.


See "How applications interact with PKCS#11" at
. Tl;dr: applications
don't search for keys by key data, but by metadata, so like I
said in
the other thread, key data can be in a single blob, but metadata
should
be in separate attributes.

Ah sorry, I hadn't looked at that one yet.
It helps quite a bit.

So are the class, key_type, id, label, token, 'sign' the only
values we
should really care to split off ?


They are all metadata related to PKCS#11 operation. I don't think you
can easily encode them in PKCS#8 or certificate blob, so they actually
need to be split off. You can find the full list of them in the PKCS#11
spec (link below).



Can you describe what are these values ?
What is class ? Why is it important, and how does it differ from
key_type ?
What is the token ? What is 'sign' ?

Feel free to give references to specific documents to read up about
these attributes.

I'm a newcomer to this area and am orienting myself at this doc:
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf
and looking into opendnssec andsofthsm code.


I use mainly
, as
2.30 is a draft ATM.



It explains CKA_SIGN as:
"TheCKA_SIGN attribute of the signature key, whic h indicates whether
the key supports signatures with appendix, must be CK_TRUE."
I cannot tell if this will be needed, just can make up an attribute
and
allow it in an objectclass :-)


OpenDNSSEC puts it in public key objects it generates, so it's
needed at
least for the sake of it.

Actually, I think we should support all of the metadata attributes, so
that our PKCS#11 module is reasonably generic and not tailored to needs
of a specific consumer.


We could hardcode some of these values but it will very likely cause
problems later. It seems simple enough to just define schema for all of
them and store them, except perhaps in the cases where they are easily
derived. If we, for example, store the prime numbers and exponents, they
need to be protected as carefully as the private key.


This is something I meant to discuss too, how do we protect them ?
Clearly we have ACIs but I am wondering if we want to encrypt them with
keys not immediately or easily available via LDAP ?

It's kind of catastrofic if they get inadvertently exposed like if
someone does a ldapsearch as "Directory Manager", which is one of the
reasons why we encrypt kerberos key material before storing it into the
db.


PKCS#8 allows encryption, I guess we can use that. There needs to be
some metadata on how to decrypt the blob though, so that the PKCS#1

Re: [Freeipa-devel] DNSSEC design page

[Ludwig Krispenz]

I was talking about 'layer of indirection' previously. I'm digging into
details and it seems like a good idea to imitate what DNS registrars do
- use concept of key sets. It means that keys are not linked to a zone
one by one but rather a whole set of keys is linked to a zone.

It eases key rotation because you just need to drop a new key to a key
set and you don't have to add DNs of all zones to the new key (or the
other way around).

Another thing is that you could have different key rotation policies for
different key sets... we need to think about it carefully.

For example (without policies for now):
- two DNS zones example.com and example.net contain a pointer to keyset
called 'setA'
- zone objects: idnsname=example.net,cn=dns and 
idnsname=example.com,cn=dns


- key sets are stored under cn=keysets, cn=sec, cn=dns

- individual keys are stored under keyid=key1, keysetid=setA,
cn=keysets, cn=sec, cn=dns


How will the PKCS#11 module know into which keyset to store a key 
generated by OpenDNSSEC? Are you suggesting having a separate 
slot/token for each keyset? I would like to keep the number of tokens 
low, because there are applications which go slot by slot, token by 
token when searching for objects (e.g. BIND and OpenSSH) and that 
might generate a lot of unnecessary traffic if the number of 
slots/tokens is high.
The pkcs11 data stored in ldap should represent pkcs11 objects. Other 
entries could reference these objects, eg a zone referencing a key. I 
don't think we should store references to other entries in an pkcs11 
object. if you want this we probably need another auxiliary objectclass 
for these pkcs11 entries.


Regarding objectclasses for the pkcs11 objects, what should be the 
structural objectclass and what the naming attribute ?
So far I had defined the publicKey, privateKey, certificate objectclass 
all as auxiliary, maybe we should have one structural like pkcs11Object 
containing the required attrs like id, label, ...

and a naming attr if it is not one of them

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

Re: [Freeipa-devel] DNSSEC design page

[Jan Cholasta]

On 25.2.2014 20:22, Simo Sorce wrote:

On Tue, 2014-02-25 at 13:22 -0500, Rob Crittenden wrote:

Jan Cholasta wrote:

On 25.2.2014 17:36, Ludwig Krispenz wrote:


On 02/25/2014 05:12 PM, Simo Sorce wrote:

On Tue, 2014-02-25 at 16:18 +0100, Jan Cholasta wrote:

On 25.2.2014 16:11, Simo Sorce wrote:

On Tue, 2014-02-25 at 15:59 +0100, Petr Spacek wrote:

On 25.2.2014 15:11, Simo Sorce wrote:

On Tue, 2014-02-25 at 14:54 +0100, Ludwig Krispenz wrote:

Any reason why we should follow in detail what softshm does ?

because I did't know what is really needed. If you want to have a
pkcs11
module, which stores data in ldap, I though it should have all the
attributes potentially needed.
Jan said taht OpenDNSSEC uses CKA_VERIFY, CKA_ENCRYPT, CKA_WRAP,
CKA_SIGN, CKA_DECRYPT, CKA_UNWRAP, CKA_SENSITIVE, CKA_PRIVATE,
CKA_EXTRACTABLE,
so there is at least one requirement for fine grained attributes.

Does OpenDNSSEC store them as separate entities and need access
to them
independently ?

AFAIK OpenDNSSEC uses purely PKCS#11 for key manipulation so LDAP
schema
doesn't matter as long as our PKCS#11 module can derive all values
defined by
standard.

Honza, you did investigate OpenDNSSEC integration, please add some
details if
you can.


Or is this internal use that can be satisfied by unpacking a blob in
OpenDNSSEC ?

What does bind9 uses ? Petr, can you provide example key files ?

Private+public keys stored in files:
https://www.redhat.com/archives/freeipa-devel/2014-February/msg00463.html


Private keys stored in HSM and public keys in files:
https://www.redhat.com/archives/freeipa-devel/2014-February/msg00333.html

(I.e. some values in .private file are replaced by PKCS#11 label.)

Ok it seem clear to me we do not need to spell out a lot of values
when
using pkcs#11 as bind doesn't need them in the key files. So I
assume it
can query the pkcs#11 module to find what it needs.

I would use these key files as a sort of guide to understand what we
need in LDAP. I would try to put in a single blob as much as we can
that
we do not explicitly need by a client querying LDAP directly.

I think in order to nail down exactly what we need, at this point, we
require some example use cases and queries the various clients would
perform with spelled out what they are looking for to identify or
manipulate keys.

Simo.


See "How applications interact with PKCS#11" at
. Tl;dr: applications
don't search for keys by key data, but by metadata, so like I said in
the other thread, key data can be in a single blob, but metadata should
be in separate attributes.

Ah sorry, I hadn't looked at that one yet.
It helps quite a bit.

So are the class, key_type, id, label, token, 'sign' the only values we
should really care to split off ?


They are all metadata related to PKCS#11 operation. I don't think you
can easily encode them in PKCS#8 or certificate blob, so they actually
need to be split off. You can find the full list of them in the PKCS#11
spec (link below).



Can you describe what are these values ?
What is class ? Why is it important, and how does it differ from
key_type ?
What is the token ? What is 'sign' ?

Feel free to give references to specific documents to read up about
these attributes.

I'm a newcomer to this area and am orienting myself at this doc:
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30b-d6.pdf
and looking into opendnssec andsofthsm code.


I use mainly
, as
2.30 is a draft ATM.



It explains CKA_SIGN as:
"TheCKA_SIGN attribute of the signature key, whic h indicates whether
the key supports signatures with appendix, must be CK_TRUE."
I cannot tell if this will be needed, just can make up an attribute and
allow it in an objectclass :-)


OpenDNSSEC puts it in public key objects it generates, so it's needed at
least for the sake of it.

Actually, I think we should support all of the metadata attributes, so
that our PKCS#11 module is reasonably generic and not tailored to needs
of a specific consumer.


We could hardcode some of these values but it will very likely cause
problems later. It seems simple enough to just define schema for all of
them and store them, except perhaps in the cases where they are easily
derived. If we, for example, store the prime numbers and exponents, they
need to be protected as carefully as the private key.


This is something I meant to discuss too, how do we protect them ?
Clearly we have ACIs but I am wondering if we want to encrypt them with
keys not immediately or easily available via LDAP ?

It's kind of catastrofic if they get inadvertently exposed like if
someone does a ldapsearch as "Directory Manager", which is one of the
reasons why we encrypt kerberos key material before storing it into the
db.


PKCS#8 allows encryption, I guess we can use that. There needs to be 
some metadata on how to decrypt the blob though, so that the PKCS#11 
module can actually

Re: [Freeipa-devel] DNSSEC design page

[Jan Cholasta]

On 25.2.2014 20:26, Petr Spacek wrote:

On 25.2.2014 19:13, Dmitri Pal wrote:

On 02/25/2014 08:46 AM, Simo Sorce wrote:

On Tue, 2014-02-25 at 11:08 +0100, Petr Spacek wrote:

On 24.2.2014 20:20, Simo Sorce wrote:

Also can you add some examples on how we would use these classes to
store DNS keys ?

We need to think about it a bit more. We plan to use PKCS#11 for key
manipulation and data signing so the key itself will be unaware of any
DNSSEC-specific attributes. DNSSEC-specifics could be in an auxiliary
objectClass.

I'm discussing this with CZ.NIC guys and they propose to add a
'layer of
indirection' between DNS zones and keys so one key set can be used
by more DNS
zones. They claim that it is relatively common practice and I trust
them.

Note that I'm not saying that IPA should use one key for multiple
DNS zones by
default, but the schema should be future-proof and allow that if
necessary.

Makes sense.


Let's start with this proposal:
DNS zone: idnsname=dnssec.test, cn=dns, dc=example
There will be multi-valued attribute idnsseckey pointing to DNs of
keys stored
somewhere else.

Specifically for DNS, we could create sub-tree cn=dnsseckeys, cn=dns
and store
keys there.

Ok, do we really want to have zones pointing at keys ?
Or do we want keys have a list of zones they are supposed to apply to ?



If we plan to store DNS keys in one place and other keys in other
places in
the tree (no common key store) then it really does not matter much.
It should be derived from the LDAP searches that would need to be
conducted by
the software.

We need keys for signing, right?
Any other use case?

In DNSSEC-context no, but the same principle will be re-used for CA
certificates and possibly user-keys (in future, like SSH private keys or
certificated used from Firefox).


If for signing we will start with a zone and would need to find keys
that are
relevant to this zone.
It seems that having a generic key class + auxiliary class that would
keep
metadata about the key, its expiration and DN it applies to would be a
way to go.

Yes, this is the plan.


So it seems that I agree with Simo that it would make sense to have
the zone
the key applies to specified in the key entry rather than in the zone
entry.

Practically it doesn't matter. You have to do either search to find
zones associated with given key or another search to find keys
associated with given zone.

Maybe the version with list of zones stored in key is better from ACI's
point of view. Access to list of zones will be controlled with ACI
attached to the key object.

... Would it be a problem to have bi-directional link between key and
zone (member-memberOf style)? It would ease processing on the client
side and I think that the price is not that high. We can use existing
member and memberOf attributes if we decide to do that.


I expect that PKCS#11 module will handle keys scattered over the
LDAP tree
somehow.

Sure as long as it can understand what the keys are for.


Ideally the example would show the LDAP tree and some example data in
detail, and also what operation we think would be common.


I was talking about 'layer of indirection' previously. I'm digging into
details and it seems like a good idea to imitate what DNS registrars do
- use concept of key sets. It means that keys are not linked to a zone
one by one but rather a whole set of keys is linked to a zone.

It eases key rotation because you just need to drop a new key to a key
set and you don't have to add DNs of all zones to the new key (or the
other way around).

Another thing is that you could have different key rotation policies for
different key sets... we need to think about it carefully.

For example (without policies for now):
- two DNS zones example.com and example.net contain a pointer to keyset
called 'setA'
- zone objects: idnsname=example.net,cn=dns and idnsname=example.com,cn=dns

- key sets are stored under cn=keysets, cn=sec, cn=dns

- individual keys are stored under keyid=key1, keysetid=setA,
cn=keysets, cn=sec, cn=dns


How will the PKCS#11 module know into which keyset to store a key 
generated by OpenDNSSEC? Are you suggesting having a separate slot/token 
for each keyset? I would like to keep the number of tokens low, because 
there are applications which go slot by slot, token by token when 
searching for objects (e.g. BIND and OpenSSH) and that might generate a 
lot of unnecessary traffic if the number of slots/tokens is high.




See the attached picture.

Are you okay with that? If so, we need to somehow add key rotation
policy to this mix :-)

This machinery has to allow algorithm-rollover, keysize-rollover etc.
We can get some inspiration from
https://wiki.opendnssec.org/display/DOCS/kasp.xml . Note that OpenDNSSEC
1.x can't do algorithm-rollover so we need to be creative with the design.


--
Jan Cholasta

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

Re: [Freeipa-devel] [PATCH] Too big font in input fields

[Adam Misnyovszki]

- Original Message -
> From: "Petr Vobornik" 
> To: "Adam Misnyovszki" , freeipa-devel@redhat.com, 
> "Martin Kosek" 
> Sent: Wednesday, February 26, 2014 2:32:52 PM
> Subject: Re: [Freeipa-devel] [PATCH] Too big font in input fields
> 
> On 26.2.2014 13:00, Adam Misnyovszki wrote:
> > Hi,
> > too big font issue in ipa-3-3 and Firefox 27 fixed:
> >
> > In Firefox 27, default font size has bigger priority than body css,
> > text input font size is therefore explicitly set to 1em
> >
> > https://fedorahosted.org/freeipa/ticket/4180
> >
> > Thanks:
> > Adam
> >
> >
> 
> NACK
> 
> The issue is not present only in textboxes but also in comboboxes and
> selects. Btw, why the height: 12px?

Because somehow the add new textboxes are 12px high, the other ones, where the 
issue is present, are 13px even with font-size: 1em

> 
> I suggest to use:
> 
> input, select, textarea {
>  font-size: 1em
> }

Will do it, ty

> 
> this should set the defaults for the whole UI.
> 
> In other topic Dmitri complained about ugliness of trust UI in 3.3
> because of jammed radios and labels. Martin, can we steal this CSS
> ticket and fix it with?
> 
> input[type=radio], input[type=checkbox],
> .ui-widget input[type=radio], .ui-widget input[type=checkbox]{
>  margin-right: 5px;
>  position: relative;
>  top: 2px;
> }

Will try this also

> --
> Petr Vobornik
> 

Thanks
Adam

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

Re: [Freeipa-devel] [PATCH] 0138, 0141: ipa-kdb fixes

[Simo Sorce]

On Wed, 2014-02-26 at 12:39 +0100, Martin Kosek wrote:
> On 02/26/2014 09:33 AM, Alexander Bokovoy wrote:
> > On Wed, 26 Feb 2014, Martin Kosek wrote:
> >> On 02/25/2014 07:59 PM, Simo Sorce wrote:
> >>> On Tue, 2014-02-25 at 20:58 +0200, Alexander Bokovoy wrote:
>  Resending patch 0138 together with another case Simo found out today:
>  when authdata flag is cleared by admin for the service principal, we'll
>  get NULL client database entry. In such case we have to bail out.
> >>>
> >>> The patches look correct code-flow-wise to me.
> >>>
> >>> So tentative ack pending testing.
> >>>
> >>> Simo.
> >>>
> >>
> >> Just checking - are we ok performance wise? If we for example add one
> >> additional LDAP search for every Kerberos authentication, it may increase 
> >> the
> >> load on our LDAP server.
> > One additional LDAP query per S4U2Proxy ticket issuing. It is not much
> > and it has to be done because current code does it wrongly for MS-PAC.
> > 
> > It is worth noting that issuing tickets should be relatively rare
> > operation -- with sessions in IPA server we don't hit HTTP/->ldap/
> > service ticket granting in S4U2Proxy case more than once.
> > 'ipa trust-add' case is a bit more specific but you rarely establish
> > trusts every second of the day, aren't you?
> > 
> > For normal operations it wouldn't affect anything beyond statistical
> > noise level.
> > 
> 
> If this only hits web management of FreeIPA (i.e. S4U2 proxy scenario) and the
> usual SSSD operations, then I have no concerns here.

Yes, this is a relatively rare event for now.
But even if it weren't there is no work around for now.

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] [PATCH] Too big font in input fields

[Petr Vobornik]

On 26.2.2014 13:00, Adam Misnyovszki wrote:

Hi,
too big font issue in ipa-3-3 and Firefox 27 fixed:

In Firefox 27, default font size has bigger priority than body css,
text input font size is therefore explicitly set to 1em

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

Thanks:
Adam




NACK

The issue is not present only in textboxes but also in comboboxes and 
selects. Btw, why the height: 12px?


I suggest to use:

input, select, textarea {
font-size: 1em
}

this should set the defaults for the whole UI.

In other topic Dmitri complained about ugliness of trust UI in 3.3 
because of jammed radios and labels. Martin, can we steal this CSS 
ticket and fix it with?


input[type=radio], input[type=checkbox],
.ui-widget input[type=radio], .ui-widget input[type=checkbox]{
margin-right: 5px;
position: relative;
top: 2px;
}
--
Petr Vobornik

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

Re: [Freeipa-devel] [PATCH] 0138, 0141: ipa-kdb fixes

[Petr Viktorin]

On 02/26/2014 02:17 PM, Tomas Babej wrote:


On 02/26/2014 02:16 PM, Tomas Babej wrote:

On 02/26/2014 12:39 PM, Martin Kosek wrote:

On 02/26/2014 09:33 AM, Alexander Bokovoy wrote:

On Wed, 26 Feb 2014, Martin Kosek wrote:

On 02/25/2014 07:59 PM, Simo Sorce wrote:

On Tue, 2014-02-25 at 20:58 +0200, Alexander Bokovoy wrote:

Resending patch 0138 together with another case Simo found out today:
when authdata flag is cleared by admin for the service principal, we'll
get NULL client database entry. In such case we have to bail out.

The patches look correct code-flow-wise to me.

So tentative ack pending testing.

Simo.


Just checking - are we ok performance wise? If we for example add one
additional LDAP search for every Kerberos authentication, it may increase the
load on our LDAP server.

One additional LDAP query per S4U2Proxy ticket issuing. It is not much
and it has to be done because current code does it wrongly for MS-PAC.

It is worth noting that issuing tickets should be relatively rare
operation -- with sessions in IPA server we don't hit HTTP/->ldap/
service ticket granting in S4U2Proxy case more than once.
'ipa trust-add' case is a bit more specific but you rarely establish
trusts every second of the day, aren't you?

For normal operations it wouldn't affect anything beyond statistical
noise level.


If this only hits web management of FreeIPA (i.e. S4U2 proxy scenario) and the
usual SSSD operations, then I have no concerns here.

Martin

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

After some thorough testing, ACK!

With this patch, not only we solve the referenced IPA ticket, but
adding a trust no longer requires retries in CI (and works on the first
attempt).


And by patch, I mean both 138 and 141, of course.



Pushed to:
master: f7955abdda854e58c60b74039bbd155f2dc66e75
ipa-3-3: c771ba23a88ef6869499f53d172f2282be19dd4d

--
Petr³

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

Re: [Freeipa-devel] [PATCH] 0138, 0141: ipa-kdb fixes

[Tomas Babej]

On 02/26/2014 02:16 PM, Tomas Babej wrote:
> On 02/26/2014 12:39 PM, Martin Kosek wrote:
>> On 02/26/2014 09:33 AM, Alexander Bokovoy wrote:
>>> On Wed, 26 Feb 2014, Martin Kosek wrote:
 On 02/25/2014 07:59 PM, Simo Sorce wrote:
> On Tue, 2014-02-25 at 20:58 +0200, Alexander Bokovoy wrote:
>> Resending patch 0138 together with another case Simo found out today:
>> when authdata flag is cleared by admin for the service principal, we'll
>> get NULL client database entry. In such case we have to bail out.
> The patches look correct code-flow-wise to me.
>
> So tentative ack pending testing.
>
> Simo.
>
 Just checking - are we ok performance wise? If we for example add one
 additional LDAP search for every Kerberos authentication, it may increase 
 the
 load on our LDAP server.
>>> One additional LDAP query per S4U2Proxy ticket issuing. It is not much
>>> and it has to be done because current code does it wrongly for MS-PAC.
>>>
>>> It is worth noting that issuing tickets should be relatively rare
>>> operation -- with sessions in IPA server we don't hit HTTP/->ldap/
>>> service ticket granting in S4U2Proxy case more than once.
>>> 'ipa trust-add' case is a bit more specific but you rarely establish
>>> trusts every second of the day, aren't you?
>>>
>>> For normal operations it wouldn't affect anything beyond statistical
>>> noise level.
>>>
>> If this only hits web management of FreeIPA (i.e. S4U2 proxy scenario) and 
>> the
>> usual SSSD operations, then I have no concerns here.
>>
>> Martin
>>
>> ___
>> Freeipa-devel mailing list
>> Freeipa-devel@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-devel
> After some thorough testing, ACK!
>
> With this patch, not only we solve the referenced IPA ticket, but
> adding a trust no longer requires retries in CI (and works on the first
> attempt).
>
And by patch, I mean both 138 and 141, of course.

-- 
Tomas Babej
Associate Software Engeneer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org 

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

Re: [Freeipa-devel] [PATCH] 0138, 0141: ipa-kdb fixes

[Tomas Babej]

On 02/26/2014 12:39 PM, Martin Kosek wrote:
> On 02/26/2014 09:33 AM, Alexander Bokovoy wrote:
>> On Wed, 26 Feb 2014, Martin Kosek wrote:
>>> On 02/25/2014 07:59 PM, Simo Sorce wrote:
 On Tue, 2014-02-25 at 20:58 +0200, Alexander Bokovoy wrote:
> Resending patch 0138 together with another case Simo found out today:
> when authdata flag is cleared by admin for the service principal, we'll
> get NULL client database entry. In such case we have to bail out.
 The patches look correct code-flow-wise to me.

 So tentative ack pending testing.

 Simo.

>>> Just checking - are we ok performance wise? If we for example add one
>>> additional LDAP search for every Kerberos authentication, it may increase 
>>> the
>>> load on our LDAP server.
>> One additional LDAP query per S4U2Proxy ticket issuing. It is not much
>> and it has to be done because current code does it wrongly for MS-PAC.
>>
>> It is worth noting that issuing tickets should be relatively rare
>> operation -- with sessions in IPA server we don't hit HTTP/->ldap/
>> service ticket granting in S4U2Proxy case more than once.
>> 'ipa trust-add' case is a bit more specific but you rarely establish
>> trusts every second of the day, aren't you?
>>
>> For normal operations it wouldn't affect anything beyond statistical
>> noise level.
>>
> If this only hits web management of FreeIPA (i.e. S4U2 proxy scenario) and the
> usual SSSD operations, then I have no concerns here.
>
> Martin
>
> ___
> Freeipa-devel mailing list
> Freeipa-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel

After some thorough testing, ACK!

With this patch, not only we solve the referenced IPA ticket, but
adding a trust no longer requires retries in CI (and works on the first
attempt).

-- 
Tomas Babej
Associate Software Engeneer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org 

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

[Freeipa-devel] [PATCH] Too big font in input fields

[Adam Misnyovszki]

Hi,
too big font issue in ipa-3-3 and Firefox 27 fixed:

In Firefox 27, default font size has bigger priority than body css, 
text input font size is therefore explicitly set to 1em 

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

Thanks:
AdamFrom 20f3ebe344abb90f930ce211bc99da95f1da7f11 Mon Sep 17 00:00:00 2001
From: Adam Misnyovszki 
Date: Wed, 26 Feb 2014 12:31:07 +0100
Subject: [PATCH] Too big font in input fields

In Firefox 27, default font size has bigger priority than body css,
text input font size is therefore explicitly set to 1em

https://fedorahosted.org/freeipa/ticket/4180
---
 install/ui/ipa.css | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/install/ui/ipa.css b/install/ui/ipa.css
index ad3d1aa1f8f8898ad8dff8f8ecc175238fad1181..468b0a8702d61716cf400bf124f84cfdc0e781b0 100644
--- a/install/ui/ipa.css
+++ b/install/ui/ipa.css
@@ -1241,6 +1241,8 @@ table.scrollable tbody {
 
 .text-widget input {
 width: 250px;
+font-size: 1em;
+height: 12px;
 }
 
 .multivalued-widget [name=value] {
-- 
1.8.5.3

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

Re: [Freeipa-devel] [PATCH] 531-541 OTP UI

[Petr Vobornik]

On 26.2.2014 01:55, Dmitri Pal wrote:

On 02/24/2014 10:21 AM, Nathaniel McCallum wrote:

On Mon, 2014-02-24 at 15:48 +0100, Petr Vobornik wrote:

On 24.2.2014 15:31, Nathaniel McCallum wrote:

On Mon, 2014-02-24 at 11:04 +0100, Petr Vobornik wrote:

On 21.2.2014 20:00, Nathaniel McCallum wrote:

Is it possible to do something more intelligent for the key and date
fields in the add-token UI?

Date fields are currently just a text box. Is there any sort of
calendar
we could use here? If not, I'm still unsure of what the format
should be
for this field.

It's the format you chose :), try to fill it in CLI, you will have the
same proble. From API level it's just string, from LDAP it's
generalized
time.

Is there a better option? I'm open to suggestions.

As I mentioned below, it's being implemented. The datetime patches will
be send separately. The core OTP UI patches should not be blocked by
them.


I've an UI patch prepared where you can write it in ISO format, with a
validator attached to it, so user will be noticed about the format,
but
it's waiting for:
https://www.redhat.com/archives/freeipa-devel/2014-January/msg00057.html

https://www.redhat.com/archives/freeipa-devel/2014-January/msg00060.html



The key field should probably have a note indicating that it is
Base32
encoding. It would also be nice to restrict the input to Base32
characters. Maybe even automatic case correction...

Actually I think it doesn't help much. Show me a person who can write
base32 encoded string But I agree that a validator with some regex
to limit the chars and a note that it should be base32 string is
better.
The question is what's the purpose of this field from user
perspective.
Is a human being suppose to fill it or is it meant to be only
filled by
some provisioning systems? In UI it's just as a backup?

If there is a use case where user is suppose to choose the key, it
would
be better to fill the key and convert it to base32 string on a server.

I can't think of any case where a user would use the key field.

However, there are at least two important cases where an admin would do
this:
1. Hardware tokens
2. Transferring OATH (TOTP/HOTP) tokens from another system

Nathaniel


What is the input format for these two cases? Is it base32 so admin can
enter it into UI or is it plain text so he has to use different tool to
encode it to base32 and then fill into UI?

In both of the above cases, I suspect the predominant use will be
scripts written to take a token store and import the tokens. This is
mostly a non-UI case.

RFC 6030 uses Base64 for unencrypted tokens. Base32 is also in wide use.
This is largely because, with fewer characters and no case-sensitivity,
Base32 is easier to type. I don't know of any other encodings in wide
use.

It would be nice to support both of them, but I'm not sure how this is
possible. Suggestions are welcome.


I do not think we should allow typing the key (and other attributes)
manually.
We should rather ask user to import a token or tokens from the XML file
that uses RFC6030.
There are vendors of the hardware tokens that actually using it to
distribute the tokens.

Here are the examples
http://www.gooze.eu/howto/oath-otp-tokens-howto/seed-codes-sample-files

Please click around the site for more info.



This is one vendor. Do we have information that the other ones (or just 
the major ones) use the XML PSKC schema from RFC6030 as well? If that's 
the case, we have enough information for implementing otp-import (design 
page says that we don't have enough info).


Back to UI. The UI might be useful if the admin has the values in 
different form than XML data, i.e., printed on a paper. Having the UI 
doesn't do any harm, right?


If vendors mostly use base64 keys, adding only base32 support in our API 
doesn't make much sense. IMO it actually adds more work because you have 
to convert it first.


Anyway: NACK for the patch because it shows totp/hotp switch in 
selfservice without possibility to define other hotp specifics. I'll 
remove it so there will be only totp in self-service (just token 
name+description).

--
Petr Vobornik

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

Re: [Freeipa-devel] [PATCH] 0142: initialize BindInstance.zonemgr for short-circuited instance use in replica setup

[Petr Viktorin]

On 02/26/2014 10:13 AM, Alexander Bokovoy wrote:

Hi,

BindInstance is used in two different ways, with replica setup not
calling BindInstance.setup() before adding master records. This causes
some properties to be uninitialized and an exception when installing
replica.

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


Thanks, ACK, pushed to:
master: 090a9669d8457a47880554bfbd1d99d0584e24ff
ipa-3-3: 61654ea6f3a00266732cf19d769f62262ed80935


--
Petr³

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

Re: [Freeipa-devel] FreeIPA 3.4 -> 4.0

[Alexander Bokovoy]

On Wed, 26 Feb 2014, Martin Kosek wrote:

On 02/26/2014 12:31 PM, Alexander Bokovoy wrote:

On Wed, 26 Feb 2014, Martin Kosek wrote:

Hello all,

I would like to discuss a proposal that Simo had on FreeIPA devel meeting.
Given permission/ACI refactoring that Petr3 is working on, people may have
issues with access to their LDAP if they played too much with the default ACIs
or if they expect that some information stays accessible in the new version. It
may not stay accessible we are removing the SUFFIX level all allowing ACIs and
creating custom read ACIs.

Bottom line is we need to do our best in making our users aware that there are
big changes in this version they need to be aware of. One way is to release a
new major release with appropriate release notes.

I support that move, I think we have enough big features planned to justify new
major release:

* Permissions/ACIs
* OTP
* DNSSEC (hopefully)
* CA Certificate Management Tool
* Big Web UI face lift and refactoring
* ...

I agree. If we succeed with global catalog work, it would too be big
enough feature.


Right. Though in this particular case it would also fit in the 3.x line as it
would be actually completing our 3.x theme which is AD trust. It would add the
IPA -> AD part.

Technically it would be considerable change -- with new (cached) DS
instance and a specialized schema, etc.

--
/ Alexander Bokovoy

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

Re: [Freeipa-devel] [PATCH 0155] ipatests: Kill winbindd process after uninstall

[Alexander Bokovoy]

On Wed, 26 Feb 2014, Martin Kosek wrote:

On 02/25/2014 07:15 PM, Alexander Bokovoy wrote:

On Tue, 25 Feb 2014, Tomas Babej wrote:

Hi,

As a part of a better cleanup procedure in the integration tests,
make sure that winbindd is not running after uninstalling the IPA
server.

Better patch 0140  attached. We simply need to stop and disable winbind in
adtrustinstance.uninstall()


Looks good to me (and a better approach than Tomas' 155 it seems). Since you
are touching this section anyway, can you please also replace bare except with
"except Exception:"?

It will allow admin to CTRL+C the stopping process when needed.

Sure, new patch is attached. There are two potentially long external
processes executed in the uninstall() so I changed to 'except
Exception:' in both.

--
/ Alexander Bokovoy
>From 74b7d5a3ffe77e6430d1b6c0cd175fea708c1855 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy 
Date: Tue, 25 Feb 2014 20:11:50 +0200
Subject: [PATCH 3/5] adtrustinstance: make sure to stop and disable winbind in
 uninstall()

This makes unnecessary Tomas' patch 0155.
---
 ipaserver/install/adtrustinstance.py | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/ipaserver/install/adtrustinstance.py 
b/ipaserver/install/adtrustinstance.py
index 621e3fd..118b2fe 100644
--- a/ipaserver/install/adtrustinstance.py
+++ b/ipaserver/install/adtrustinstance.py
@@ -889,12 +889,15 @@ class ADTRUSTInstance(service.Service):
 self.restore_state("running")
 self.restore_state("enabled")
 
+winbind = ipaservices.service("winbind")
 # Always try to stop and disable smb service, since we do not leave
 # working configuration after uninstall
 try:
 self.stop()
 self.disable()
-except:
+winbind.stop()
+winbind.disable()
+except Exception:
 pass
 
 # Since we do not guarantee restoring back to working samba state,
@@ -907,7 +910,7 @@ class ADTRUSTInstance(service.Service):
 try:
 ipautil.run(["/usr/sbin/setsebool",
  "-P", var, sebool_state])
-except:
+except Exception:
 self.print_msg(SELINUX_WARNING % dict(var=var))
 
 # Remove samba's credentials cache
-- 
1.8.3.1

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

Re: [Freeipa-devel] [PATCH] 0138, 0141: ipa-kdb fixes

[Martin Kosek]

On 02/26/2014 09:33 AM, Alexander Bokovoy wrote:
> On Wed, 26 Feb 2014, Martin Kosek wrote:
>> On 02/25/2014 07:59 PM, Simo Sorce wrote:
>>> On Tue, 2014-02-25 at 20:58 +0200, Alexander Bokovoy wrote:
 Resending patch 0138 together with another case Simo found out today:
 when authdata flag is cleared by admin for the service principal, we'll
 get NULL client database entry. In such case we have to bail out.
>>>
>>> The patches look correct code-flow-wise to me.
>>>
>>> So tentative ack pending testing.
>>>
>>> Simo.
>>>
>>
>> Just checking - are we ok performance wise? If we for example add one
>> additional LDAP search for every Kerberos authentication, it may increase the
>> load on our LDAP server.
> One additional LDAP query per S4U2Proxy ticket issuing. It is not much
> and it has to be done because current code does it wrongly for MS-PAC.
> 
> It is worth noting that issuing tickets should be relatively rare
> operation -- with sessions in IPA server we don't hit HTTP/->ldap/
> service ticket granting in S4U2Proxy case more than once.
> 'ipa trust-add' case is a bit more specific but you rarely establish
> trusts every second of the day, aren't you?
> 
> For normal operations it wouldn't affect anything beyond statistical
> noise level.
> 

If this only hits web management of FreeIPA (i.e. S4U2 proxy scenario) and the
usual SSSD operations, then I have no concerns here.

Martin

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

Re: [Freeipa-devel] FreeIPA 3.4 -> 4.0

[Martin Kosek]

On 02/26/2014 12:31 PM, Alexander Bokovoy wrote:
> On Wed, 26 Feb 2014, Martin Kosek wrote:
>> Hello all,
>>
>> I would like to discuss a proposal that Simo had on FreeIPA devel meeting.
>> Given permission/ACI refactoring that Petr3 is working on, people may have
>> issues with access to their LDAP if they played too much with the default 
>> ACIs
>> or if they expect that some information stays accessible in the new version. 
>> It
>> may not stay accessible we are removing the SUFFIX level all allowing ACIs 
>> and
>> creating custom read ACIs.
>>
>> Bottom line is we need to do our best in making our users aware that there 
>> are
>> big changes in this version they need to be aware of. One way is to release a
>> new major release with appropriate release notes.
>>
>> I support that move, I think we have enough big features planned to justify 
>> new
>> major release:
>>
>> * Permissions/ACIs
>> * OTP
>> * DNSSEC (hopefully)
>> * CA Certificate Management Tool
>> * Big Web UI face lift and refactoring
>> * ...
> I agree. If we succeed with global catalog work, it would too be big
> enough feature.

Right. Though in this particular case it would also fit in the 3.x line as it
would be actually completing our 3.x theme which is AD trust. It would add the
IPA -> AD part.

Martin

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

Re: [Freeipa-devel] FreeIPA 3.4 -> 4.0

[Alexander Bokovoy]

On Wed, 26 Feb 2014, Martin Kosek wrote:

Hello all,

I would like to discuss a proposal that Simo had on FreeIPA devel meeting.
Given permission/ACI refactoring that Petr3 is working on, people may have
issues with access to their LDAP if they played too much with the default ACIs
or if they expect that some information stays accessible in the new version. It
may not stay accessible we are removing the SUFFIX level all allowing ACIs and
creating custom read ACIs.

Bottom line is we need to do our best in making our users aware that there are
big changes in this version they need to be aware of. One way is to release a
new major release with appropriate release notes.

I support that move, I think we have enough big features planned to justify new
major release:

* Permissions/ACIs
* OTP
* DNSSEC (hopefully)
* CA Certificate Management Tool
* Big Web UI face lift and refactoring
* ...

I agree. If we succeed with global catalog work, it would too be big
enough feature.


If there is no push back against that idea, let's do it. I would then rename
the 3.4 milestones to 4.0 and 3.5 milestones to 4.1.

Yep.

--
/ Alexander Bokovoy

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

Re: [Freeipa-devel] [PATCH 0155] ipatests: Kill winbindd process after uninstall

[Martin Kosek]

On 02/25/2014 07:15 PM, Alexander Bokovoy wrote:
> On Tue, 25 Feb 2014, Tomas Babej wrote:
>> Hi,
>>
>> As a part of a better cleanup procedure in the integration tests,
>> make sure that winbindd is not running after uninstalling the IPA
>> server.
> Better patch 0140  attached. We simply need to stop and disable winbind in
> adtrustinstance.uninstall()

Looks good to me (and a better approach than Tomas' 155 it seems). Since you
are touching this section anyway, can you please also replace bare except with
"except Exception:"?

It will allow admin to CTRL+C the stopping process when needed.

Thanks,
Martin

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

[Freeipa-devel] FreeIPA 3.4 -> 4.0

[Martin Kosek]

Hello all,

I would like to discuss a proposal that Simo had on FreeIPA devel meeting.
Given permission/ACI refactoring that Petr3 is working on, people may have
issues with access to their LDAP if they played too much with the default ACIs
or if they expect that some information stays accessible in the new version. It
may not stay accessible we are removing the SUFFIX level all allowing ACIs and
creating custom read ACIs.

Bottom line is we need to do our best in making our users aware that there are
big changes in this version they need to be aware of. One way is to release a
new major release with appropriate release notes.

I support that move, I think we have enough big features planned to justify new
major release:

* Permissions/ACIs
* OTP
* DNSSEC (hopefully)
* CA Certificate Management Tool
* Big Web UI face lift and refactoring
* ...

If there is no push back against that idea, let's do it. I would then rename
the 3.4 milestones to 4.0 and 3.5 milestones to 4.1.

-- 
Martin Kosek 
Supervisor, Software Engineering - Identity Management Team
Red Hat Inc.

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

[Freeipa-devel] [PATCHES] 0473-0477 Managed permission updater, part 1

[Petr Viktorin]

Hello,
Here are a few fixes/improvements, and the first part of a managed 
permission updater.


The patches should go in this order but don't need to be ACKed/pushed 
all at once.



Design: 
http://www.freeipa.org/page/V3/Managed_Read_permissions#Default_Permission_Updater

Part of the work for: https://fedorahosted.org/freeipa/ticket/3566


This part is a "preview" of sorts, to get the basic mechanism and the 
metadata format reviewed before I add all of the default read permissions.
It implements the first section of "Default Permission Updater" in the 
design; "Replacing legacy default permissions" and "Removing the global 
anonymous read ACI" is left for later.
Metadata is added for the netgroup plugin* for starters, so installing 
this will give you two shiny new read permissions:


$ ipa permission-find ipa: --all
-
2 permissions matched
-
  dn: cn=ipa:Read Netgroup Membership,cn=permissions,cn=pbac,$SUFFIX
  Permission name: ipa:Read Netgroup Membership
  Permissions: read, compare, search
  Effective attributes: externalhost, member, memberof, memberuser
  Default attributes: member, memberof, memberuser, externalhost
  Bind rule type: all
  Subtree: cn=ng,cn=alt,$SUFFIX
  Target filter: (objectclass=ipanisnetgroup)
  Type: netgroup
  ipapermissiontype: V2, MANAGED, SYSTEM
  objectclass: ipapermission, groupofnames, top, ipapermissionv2

  dn: cn=ipa:Read Netgroups,cn=permissions,cn=pbac,$SUFFIX
  Permission name: ipa:Read Netgroups
  Permissions: read, compare, search
  Effective attributes: cn, description, hostcategory, ipaenabledflag, 
ipauniqueid, nisdomainname, usercategory
  Default attributes: cn, usercategory, hostcategory, ipauniqueid, 
ipaenabledflag, nisdomainname, description

  Bind rule type: all
  Subtree: cn=ng,cn=alt,$SUFFIX
  Target filter: (objectclass=ipanisnetgroup)
  Type: netgroup
  ipapermissiontype: V2, MANAGED, SYSTEM
  objectclass: ipapermission, groupofnames, top, ipapermissionv2

Number of entries returned 2


with corresponding ACIs at cn=ng,cn=alt,$SUFFIX:

(targetattr = "externalhost || member || memberof || 
memberuser")(targetfilter = "(objectclass=ipanisnetgroup)")(version 
3.0;acl "permission:ipa:Read Netgroup Membership";allow 
(read,compare,search) userdn = "ldap:///all";;)
(targetattr = "cn || description || hostcategory || ipaenabledflag || 
ipauniqueid || nisdomainname || usercategory")(targetfilter = 
"(objectclass=ipanisnetgroup)")(version 3.0;acl "permission:ipa:Read 
Netgroups";allow (read,compare,search) userdn = "ldap:///all";;)




Patches:

0473: Enables refactoring that will make it more clear (to humans and 
machines) what plugins code depends on.

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

0474: Fix handling of the search term for legacy permissions
My code that's in master now handles the search term incorrectly. This 
does a better job.


0475: Fix tests that relied on some assumptions I'll be breaking

0476: Allow modifying (but not creating) permissions with ":" in the name

0477: Permission updater & sample metadata


--
Petr³

(* picked by fair dice roll)

From acbca2183b52c3c3f2d3d733aa5a5086c2f24830 Mon Sep 17 00:00:00 2001
From: Petr Viktorin 
Date: Wed, 12 Feb 2014 16:17:39 +0100
Subject: [PATCH] Allow indexing API object types by class

This allows code like:
from ipalib.plugins.dns import dnszone_mod

api.Command[dnszone_mod]

This form should be preferred when getting specific objects
because it ensures that the appropriate plugin is imported.

https://fedorahosted.org/freeipa/ticket/4185
---
 ipalib/base.py| 15 +--
 ipatests/test_ipalib/test_base.py | 12 ++--
 2 files changed, 23 insertions(+), 4 deletions(-)

diff --git a/ipalib/base.py b/ipalib/base.py
index 83d778fe751e66414fe34d0d3243cdae34941ad6..91259c7f3b480ffc0e70061e1efa0135ff500478 100644
--- a/ipalib/base.py
+++ b/ipalib/base.py
@@ -287,7 +287,7 @@ class NameSpace(ReadOnly):
 >>> class Member(object):
 ... def __init__(self, i):
 ... self.i = i
-... self.name = 'member%d' % i
+... self.name = self.__name__ = 'member%d' % i
 ... def __repr__(self):
 ... return 'Member(%d)' % self.i
 ...
@@ -378,6 +378,14 @@ class NameSpace(ReadOnly):
 >>> unsorted_ns[0]
 Member(7)
 
+As a special extension, NameSpace objects can be indexed by objects that
+have a "__name__" attribute (e.g. classes). These lookups are converted
+to lookups on the name:
+
+>>> class_ns = NameSpace([Member(7), Member(3), Member(5)], sort=False)
+>>> unsorted_ns[Member(3)]
+Member(3)
+
 The `NameSpace` class is used in many places throughout freeIPA.  For a few
 examples, see the `plugable.API` and the `frontend.Command` classes.
 """
@@ -447,6 +455,7 @@ def __contains__(self, name):
 """
 Return ``True`` if namespace has a member na

[Freeipa-devel] [PATCH] 0142: initialize BindInstance.zonemgr for short-circuited instance use in replica setup

[Alexander Bokovoy]

Hi,

BindInstance is used in two different ways, with replica setup not
calling BindInstance.setup() before adding master records. This causes
some properties to be uninitialized and an exception when installing
replica.

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


--
/ Alexander Bokovoy
>From 644ac4508f9f357c75c1cf954386590828bbeb3e Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy 
Date: Wed, 26 Feb 2014 11:06:29 +0200
Subject: [PATCH 5/5] bindinstance: make sure zone manager is initialized in
 add_master_dns_records

Bind instance is configured using a short-circuited way when replica is set up.
Make sure required properties are in place for that.

https://fedorahosted.org/freeipa/ticket/4186
---
 ipaserver/install/bindinstance.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ipaserver/install/bindinstance.py 
b/ipaserver/install/bindinstance.py
index 6d5a1d4..4dc4103 100644
--- a/ipaserver/install/bindinstance.py
+++ b/ipaserver/install/bindinstance.py
@@ -828,6 +828,7 @@ class BindInstance(service.Service):
 self.reverse_zone = reverse_zone
 self.ca_configured = ca_configured
 self.first_instance = False
+self.zonemgr = 'hostmaster.%s' % self.domain
 
 self.__add_self()
 self.__add_ipa_ca_record()
-- 
1.8.3.1

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

[Freeipa-devel] [PATCH 0229] Require BIND >= 9.8.2 instead of >= 9.9.0

[Petr Spacek]

Hello,

Require BIND >= 9.8.2 instead of >= 9.9.0.

Pushed to v3 branch: 28cd600ddc0a9473b3adb31dd82ea99d7c92f983

--
Petr^2 Spacek

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

Re: [Freeipa-devel] [PATCH] 0138, 0141: ipa-kdb fixes

[Alexander Bokovoy]

On Wed, 26 Feb 2014, Martin Kosek wrote:

On 02/25/2014 07:59 PM, Simo Sorce wrote:

On Tue, 2014-02-25 at 20:58 +0200, Alexander Bokovoy wrote:

Resending patch 0138 together with another case Simo found out today:
when authdata flag is cleared by admin for the service principal, we'll
get NULL client database entry. In such case we have to bail out.


The patches look correct code-flow-wise to me.

So tentative ack pending testing.

Simo.



Just checking - are we ok performance wise? If we for example add one
additional LDAP search for every Kerberos authentication, it may increase the
load on our LDAP server.

One additional LDAP query per S4U2Proxy ticket issuing. It is not much
and it has to be done because current code does it wrongly for MS-PAC.

It is worth noting that issuing tickets should be relatively rare
operation -- with sessions in IPA server we don't hit HTTP/->ldap/
service ticket granting in S4U2Proxy case more than once. 


'ipa trust-add' case is a bit more specific but you rarely establish
trusts every second of the day, aren't you?

For normal operations it wouldn't affect anything beyond statistical
noise level.

--
/ Alexander Bokovoy

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