Re: [Freeipa-devel] ipa-server-install error

2014-05-30 Thread Martin Kosek 
On 05/30/2014 06:14 AM, Dmitri Pal wrote:
 On 05/29/2014 01:44 AM, James wrote:
 /usr/bin/runcon: invalid context: unconfined_u:system_r:pki_ca_script_t:s0:
 Invalid argument
 Looks like and AVC that lead to restart failure of the PKI instance that in
 turn led to failure to configure CA.

I asked Ade Lee and got this response:

On 05/29/2014 04:44 PM, Ade Lee wrote:
 The problem is here:

 /usr/bin/runcon: invalid context:
 unconfined_u:system_r:pki_ca_script_t:s0: Invalid argument

 We've seen this before.  Sometimes pki-selinux fails to load its policy
 for some reason.  The best thing to do is to force re-install
 pki-selinux (and check for any errors in the /var/log/messages file).

 Ade

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

Re: [Freeipa-devel] [PATCH 0020] ipa recursively adds old backups

2014-05-30 Thread Martin Kosek 
On 05/30/2014 01:11 AM, Gabe Alford wrote:
 Hello,
 
 This is a patch for https://fedorahosted.org/freeipa/ticket/4331
 It's a one liner that just adds an exclude to the tar command to ignore the
 /var/lib/ipa/backup folder.
 
 Thanks,
 
 Gabe

Thanks! Patches for backup and restore feature are very welcome.

ACK, works fine. Pushed to master: 9f2c4705d7e2fa83be95f005a78f83a399acfa72

Martin

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

Re: [Freeipa-devel] User life cycle: question regarding the design

2014-05-30 Thread Martin Kosek 
On 05/29/2014 08:14 PM, Dmitri Pal wrote:
 On 05/29/2014 08:39 AM, Simo Sorce wrote:
 On Thu, 2014-05-29 at 09:43 +0200, Martin Kosek wrote:
 On 05/29/2014 05:31 AM, Dmitri Pal wrote:
 On 05/26/2014 01:49 AM, Martin Kosek wrote:
 On 05/23/2014 04:55 PM, Simo Sorce wrote:
 On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote:
 This, I believe, has already been covered, but I'm concerned with the
 (over)use of active/inactive in this discussion.

 I think use of inactive and active to describe users might be
 confusing since there is already an account enable/disable command.
 This
 on top of unlock, are there now 3 possible boolean states a user can
 be
 in? locked/unlocked, enabled/disabled, active/inactive, plus
 deleted/active and staged/active?

 Agree, we should only have ipa user-unstage username and not call
 this operations with words like active/inactive.

 User's in the staging area are not inactive, they are *not* users yet in
 the first place.

 Simo.

 Ok. Let us consolidate the decisions, I think we are now running in 
 circles.
 Let me start from Petr3's API proposal which was a functionally complete
 proposal and start from there:

 On 05/22/2014 10:47 AM, Petr Viktorin wrote:
 ...
 My proposal would be that the move commands use the verb for the target
 and an
 option for the source, and add/mod use an option for the container:

 1) adding a new user
 (to active)   ipa user-add tuser ...
 (to stage)ipa user-add tuser --staged ...
 Ok.

 (to deleted)  ipa user-add tuser --deleted ...  (*)
 Not needed.

 2) moving to main
 (from stage)  ipa user-activate tuser  (**)
 (from del)ipa user-activate tuser --deleted
 We need both, alternative is Simo's proposal:

 ipa user-unstage
 ipa user-undelete

 I personally like unstage and undelete commands, I would go with those.
 Sorry for coming late to the party.
 I strongly do not like unstage
 This suggests that the user will be removed from staged but does not 
 indicate
 that the full user will be created.
 As I suggested elsewhere provision-user or user-provision (or may be even
 user-add --from-stage) would be better.
 As Petr3 already noted on 05/19/2014 03:19 PM, integrating unstaging 
 operation
 could get messy and would not create the right API. Using a separate call 
 would
 be cleaner. As we see, choosing the right action term has proven very 
 difficult
 - everyone has strong opinion on the command name :-)

 I already saw user-activate and user-unstage to be trashed so I am thinking
 what we are left with. I am still fan of user-unstage, user-provision is not
 telling me much more than user-unstage.

 3) moving to deleted
 (from active) ipa user-del tuser
 Ok.

 (from stage)  ipa user-del tuser --staged
 IMO staged deleted users should not be moved to deleted container, but 
 simply
 permanently deleted. As Simo noted, staged user are not real users, just
 incomplete users.

 4) moving to stage
 (from active) ipa user-stage tuser

 This was suggested for completeness.
 I think we are cutting corners but I would not insist here.

 (from del)ipa user-stage tuser --deleted
 None of the commands are needed for the basic workflow.
 But this is a valid use case. I created a user, deleted it and want to 
 rebuild
 it becuase something got corrupted in the original entry. I agree it is 
 not a
 primary use case but then we should have a ticket to track this RFE for
 future.
 This was not about cutting corners, this was about what operation makes 
 sense
 and what we should support. Stage was defined as a tree with incomplete 
 user,
 thus this proposal - Simo was not very OK with this workflow.

 5) modifying
 (in active)   ipa user-mod tuser ...
 Ok.

 (in stage)ipa user-mod tuser --staged ...
 Simo did not like this command, I would personally add it. As long as we 
 have
 ipa user-add --staged, we should also have an option to delete and 
 modify
 user in staged area.

 (in del)  ipa user-mod tuser --deleted ...
 Not needed.

 Is this acceptable for everyone? If yes, the next step would be for 
 Thierry
 to update the design page with new proposals.

 Martin
 Let me try to consolidate again the proposals and changes for the 
 workflowAPI
 we have so far:

 1) Manipulating staged users
 - staged users must have UID RDN
 - UID uniqueness plugin should not be enforcing in staging area
 - we do not want it in user plugin as it requires different parameters and
 objectclasses
 - API:
 ipa stage-user-add
 ipa stage-user-mod
 ipa stage-user-find
 ipa stage-user-del

 2) Activating staged user
 - activation will not do MODRDN, it will create a new user in active 
 container
 and then delete the old one (to create right structural objectclass set)
 - for now, we need to allow operator delete any user in staged and add any 
 user
 in active tree
 - API
 ipa stage-user-activate
 - other options mentioned in the past were user-unstage and user-activate

 3) Manipulating deleted users
 - deletion and undeletion will do MODRDN and

Re: [Freeipa-devel] [RFC] Migrating existing environments to Trust - v2: reverse DNS lookup

2014-05-30 Thread Sumit Bose 
On Thu, May 29, 2014 at 01:31:04PM -0400, Simo Sorce wrote:
 On Thu, 2014-05-29 at 18:50 +0200, Petr Spacek wrote:
  On 29.5.2014 13:48, Sumit Bose wrote:
   == slapi-nis plugin/compat tree ==
   The compat tree offers a simplified LDAP tree with user and group data
   for legacy clients. No data for this tree is stored on disk but it is
   always created on the fly. It has to be noted that legacy clients might
   be one of the major users of the user-views because chances are that
   they were attached to the legacy systems with legacy ID management which
   should be replaced by IPA.
  
   In contrast to the extdom plugin it is not possible to determine the
   client based on the DN because connection might be anonymous. The
   Slapi_PBlock contains the IP address of the client in
   SLAPI_CONN_CLIENTNETADDR. Finding the matching client object in the IPA
   tree requires a reverse-DNS lookup which might be unreliable. If the
   reverse-DNS lookup was successful the slapi-nos plugin can follow the
   same steps as the extdom plugin to lookup up and apply the view.
  
  Do we really want to base security decisions on reverse DNS resolution?
 
 No we do not want to play these games.
 
  That 
  will be insecure. Attacker could tamper with reverse DNS to change UID/GID 
  mapping ... Maybe we can store IP-view mapping in the LDAP database. That 
  should be reliable if we assume that only TCP is used for connection to 
  LDAP 
  database.
 
 It is not just about it being insecure, it is about it being wrong.
 As soon as you have a bunch of clients behind a NAT this pans goes belly
 up.

I do not like this one either. I just wanted to list to options I could
think of because I think supporting user-views on legacy clients is one
of the major use-cases for this feature.

bye,
Sumit

 
   As a alternative slapi-nis can provide one tree for each view.
 
 This is the only alternative, if we decide to pursue it.
 
 Simo.
 
 -- 
 Simo Sorce * Red Hat, Inc * New York
 
 ___
 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

Re: [Freeipa-devel] CA certificate renewal, shared store trust settings

2014-05-30 Thread Jan Cholasta 

Hi,

On 29.5.2014 19:44, Nalin Dahyabhai wrote:

I'm working on adding to certmonger the ability to read the IPA root
certificate from the server and store it locally, and I'm looking at the
V4 shared certificate store feature [1] with an eye toward also pulling
down and processing those certificates.  Before I head down that path,
I've got a few questions about the schema that the page describes for
storing trust information.


So, you want to fetch the certificates directly from LDAP? Shouldn't 
they rather be fetched using IPA API (in ipa-submit) or Dogtag API (in 
dogtag-ipa-renew-agent-submit)?


In the past few months that I worked on the CA certificate renewal 
feature the shared certificate store design has evolved into something 
more about certificate trust policy rather than simple storage of CA 
certificates. My plan is to integrate it with p11-kit in the forthcoming 
months to provide the policy to IPA clients. SSSD is going to be used as 
the component between IPA and p11-kit. A PKCS#11 module will be provided 
for (not only) that. (This is what 
http://www.freeipa.org/page/V4/CA_certificate_renewal_(2) is going to 
be about.)


I can imagine you might as well talk to the module to fetch the CA 
certificates. Are there any plans to support PKCS#11 as a storage 
backend in certmonger?




Is the ipaKeyTrust attribute meant to be a part of the ipaKeyPolicy
object class?


Yes.



Looking at the ipaKeyTrust attribute, the description suggests that it's
a directoryString that should contain one of 'unknown', 'trusted', or
'distrusted' as its value.  The syntax doesn't guarantee that, and that
ambiguity makes me a little nervous.  Any chance of tweaking the schema
to remove that possibility?


This does not make me nervous at all. Take a look at other similar 
attributes in IPA, they all use directory string syntax. I'm open to 
suggestions, though.




The ipaKeyExtUsage attribute, along with ipaKeyTrust values of 'trusted'
and 'distrusted', appears to map pretty directly to the sort of
information that OpenSSL stores in trusted certificates [2], but going
through the man pages for x509(1) and verify(1), I don't see anything
that obviously corresponds to an ipaKeyTrust value of 'unknown'.   What's
that value intended to signify, and how would consumers of the
certificates be expected to treat certificates from entries with that
ipaKeyTrust value?


Actually it is designed to map to p11-kit-style trust policy 
(http://p11-glue.freedesktop.org/doc/storing-trust-policy/index.html), 
which is a superset of OpenSSL's.


The unknown value means the trust is not explicitly given and that if 
there is other source of trust information for the key/certificate, it 
should be used. In p11-kit terms, it is for certificates which are 
neither in the anchors nor the blacklist set. In NSS terms, it's for 
certificates without any of the C, T, P or p trust flags.




Are there examples of what the ipaKeyUsage attribute should contain?


It's the purpose bit names from the key usage certificate extension 
(http://tools.ietf.org/html/rfc5280#section-4.2.1.3) or none.




Is there a recommended method for mapping from this representation to
the form that we'd pass to certutil(1)'s '-t' option when storing the
certificates in NSS databases, or is the intent that it be translated
into NSS-specific PKCS#11 attributes set on those certificates?


Well, it can be both. But as I said above, I'm not sure if reading from 
LDAP directly is the best thing to do in this case.




Thanks,

Nalin

[1] 
http://www.freeipa.org/page/V4/CA_certificate_renewal#Shared_certificate_store
[2] 
http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html#openssl-trusted



(Yes, I will update the design page.)

Honza

--
Jan Cholasta

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

Re: [Freeipa-devel] ipa-server-install error

2014-05-30 Thread Martin Kosek 
On 05/30/2014 09:44 AM, James wrote:
 On Fri, May 30, 2014 at 2:00 AM, Martin Kosek mko...@redhat.com wrote:
 On 05/30/2014 06:14 AM, Dmitri Pal wrote:
 On 05/29/2014 01:44 AM, James wrote:
 /usr/bin/runcon: invalid context: unconfined_u:system_r:pki_ca_script_t:s0:
 Invalid argument
 Looks like and AVC that lead to restart failure of the PKI instance that in
 turn led to failure to configure CA.

 I asked Ade Lee and got this response:

 On 05/29/2014 04:44 PM, Ade Lee wrote:
 The problem is here:

 /usr/bin/runcon: invalid context:
 unconfined_u:system_r:pki_ca_script_t:s0: Invalid argument

 We've seen this before.  Sometimes pki-selinux fails to load its policy
 for some reason.  The best thing to do is to force re-install
 pki-selinux (and check for any errors in the /var/log/messages file).

 Ade

 
 Thanks for looking into this... I'm able to reproduce this currently
 100% of the time. Unfortunately this breaks automated installs. Is it
 a bug that needs filling somewhere, or is it something wrong with my
 machines? I'm seeing it with the most recent incarnation of the
 vagrant-libvirt base images I'm building.
 
 It's particularly pernicious because when this occurs (100% of the
 time), the machine seems to be in a partially installed state.
 
 Thanks,
 James

Good question - CCing PKI developers.

Martin

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

Re: [Freeipa-devel] [RFC] Migrating existing environments to Trust - v2: reverse DNS lookup

2014-05-30 Thread Alexander Bokovoy 

On Fri, 30 May 2014, Sumit Bose wrote:

On Fri, May 30, 2014 at 12:23:53AM -0400, Dmitri Pal wrote:

On 05/29/2014 01:31 PM, Simo Sorce wrote:
On Thu, 2014-05-29 at 18:50 +0200, Petr Spacek wrote:
On 29.5.2014 13:48, Sumit Bose wrote:
== slapi-nis plugin/compat tree ==
The compat tree offers a simplified LDAP tree with user and group data
for legacy clients. No data for this tree is stored on disk but it is
always created on the fly. It has to be noted that legacy clients might
be one of the major users of the user-views because chances are that
they were attached to the legacy systems with legacy ID management which
should be replaced by IPA.

In contrast to the extdom plugin it is not possible to determine the
client based on the DN because connection might be anonymous. The
Slapi_PBlock contains the IP address of the client in
SLAPI_CONN_CLIENTNETADDR. Finding the matching client object in the IPA
tree requires a reverse-DNS lookup which might be unreliable. If the
reverse-DNS lookup was successful the slapi-nos plugin can follow the
same steps as the extdom plugin to lookup up and apply the view.
Do we really want to base security decisions on reverse DNS resolution?
No we do not want to play these games.

That
will be insecure. Attacker could tamper with reverse DNS to change UID/GID
mapping ... Maybe we can store IP-view mapping in the LDAP database. That
should be reliable if we assume that only TCP is used for connection to LDAP
database.
It is not just about it being insecure, it is about it being wrong.
As soon as you have a bunch of clients behind a NAT this pans goes belly
up.

As a alternative slapi-nis can provide one tree for each view.
This is the only alternative, if we decide to pursue it.

Simo.

Can we at least do something like CoS and use the base compat tree and
overwrite just uid/gid on the fly instead of using the whole another view?
That would reduce the size of the additional views significantly and would
save cycles used for keeping each view in sync with underlying DB. In this
case there will be still one view and dynamic overwrite in the search
results.


If we do not want to support all configured views what about making it
configurable which view are delivered in separate trees by slapi-nis?
-
I do not know much about the slap-nis internal, but I could image that
the memory requirement for a two layer cache (one global for the data
from SSSD (default view) and one for each view with the override data)
might be an issue. It would be nice if Alexander or Nalin can explain
some of the current bottlenecks in slap-nis to see were it will get
worse when supporting user-views in multiple trees?

Pretty bad.

slapi-nis only serves the entries that were not found with the normal
search path. This implies there is always cost of a search over the main
tree. If a base DN is too generic, slapi-nis will happily return
everything what is cached and fits the filter.

Now, we cannot rely on a client connection properties to segregate
the connections to different cached sub-trees. Reverse DNS is bad, IP
address handling is unreliable. The only way to differentiate would be
to have different base DN supplied by each client, maybe in the form of
multi-valued RDN (cn=compat+view=viewname,$SUFFIX). However, that would
add complication to slapi-nis map cache as data is evaluated once and
then inserted into the map cache while in this case a different view
would mean need to re-evaluate part of the entry or partially modify
returned object on the fly.

Technically the latter is possible. Suppose on the first hit to
slapi-nis for a uid=foo we would insert its entry into the map cache
where each uidNumber/gidNumber has view name appended:

uidNumber: 12344556
gidNumber: 12344556
uidNumber_legacy_client1: 11
gidNumber_legacy_client1: 110001
uidNumber_legacy_client2: 21
gidNumber_legacy_client2: 210001
uidNumber_legacy_client3: 31
gidNumber_legacy_client3: 310001

And then have a filter for the resulting object fetched from the
map cache prior to pushing it out to the client.

The main trouble here is that we have to post process the data in map
cache and also the fact that we'll have more triggers to invalidate
cached objects, including the ones coming from nss requests which
officially have no DN in the main tree to get a trigger for them.



Maybe running a separate 389ds instance for the user-views might be an
alternative here as well? Alexanders work for the Global Catalog might
come handy here because it sets up and configures a separate instance
which reads data from the main one.

I don't think it makes problem any easier as we really have to solve the
issue of addressing client connection differences first. Whether the
data is served by a separate instance or not is irrelevant here.
--
/ Alexander Bokovoy

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

Re: [Freeipa-devel] [RFC] Migrating existing environments to Trust

2014-05-30 Thread Alexander Bokovoy 

On Fri, 30 May 2014, Dmitri Pal wrote:

On 05/29/2014 02:13 PM, Simo Sorce wrote:

On Thu, 2014-05-29 at 12:35 -0400, Dmitri Pal wrote:

On 05/29/2014 11:41 AM, Simo Sorce wrote:

On Thu, 2014-05-29 at 11:39 -0400, Dmitri Pal wrote:

On 05/28/2014 11:20 PM, Simo Sorce wrote:

On Wed, 2014-05-28 at 23:15 -0400, Dmitri Pal wrote:

On 05/27/2014 03:52 PM, Simo Sorce wrote:

On Tue, 2014-05-27 at 16:01 +0200, Sumit Bose wrote:

On Tue, Apr 15, 2014 at 11:13:38AM +0200, Sumit Bose wrote:

Hi,

I have started to write a design page for 'Migrating existing
environments to Trust'
http://www.freeipa.org/page/V3/Migrating_existing_environments_to_Trust
It shall cover https://fedorahosted.org/freeipa/ticket/3318 and
https://fedorahosted.org/freeipa/ticket/3979 .


while working on a new version of the page with more details on design
and implementation I came across the following problem. On the IPA
server there should be a way for SSSD to deliver unmodified data (no
view applied) or views other than the one for the IPA server to
processes which delivers user and group data to other clients. This are
mainly the extdom and the compat plugin of dirsrv.

The two currently use standard glibc calls like getpwnam_r() to get the
needed data from SSSD. While they can read the view objects form the
LDAP tree there is no way to read the original data for users from
trusted domains because it is only in the cache of SSSD.

I'm looking for a way to allow SSSD to deliver the data without changing
the protocol used by the NSS responder.

One way I can think of is to use a new socket like
/var/lib/sss/pipes/nss_noview and create a small library for the extdom
and compat plugin to use the new socket. With this the plugin have to
apply the views on their own if needed.

Another way would be a new command for the NSS responder with two
arguments, the view name (or empty for unmodified data) and a blob which
contains the data for the corresponding request like e.g. getpwnam_r() or
getgrgid_r(). Here the plugins have to use some new calls but all view
processing can happen in sssd and the plugins can deliver the data
directly.

A drawback in both cases is that the memcache cannot be used.

If someone has suggestions for SSSD or other ways how to deliver user
and group data to client with other views than the IPA server I'm all
ears.

Ok this one is hard to deal with in a way that will satisfy every
possible user.

I think what we need to aim is simplicity and predictability at the
expense of flexibility.

What I mean is that freeipa servers should be allowed to only stick to
one view, the default view for external users.

I do not understand what you mean by one view?

The one view is the view exposed via the (default) compat tree.


Server should be able to have all views.
View is an equivalent of the zones.

SSSD has to get raw data from the external domain and give it to IPA.
IPA would have to merge the data coming from SSSD in server mode with
some set of data associated with a subset of clients.
I am not sure how it will be done (compat, cos or some other mechanism)
but this is the requirement.

This would require multiple compat trees, one per view, it would be very
expensive.


So for clarity let me restate the use cases:

a) I had my users in a NIS or LDAP with POSIX attributes there. I used
to sync users from AD. I migrate from that to IPA but want to use trust
for my users because AD is authoritative source and I do not want/can
put POSIX into AD.
b) I have several NIS domains that I need to consolidate. For whatever
reasons I can't migrate to the unified POSIX namespace. I want an
equivalent of the Centrify Zones when different clients get different
uid/gid assignments for the same users.
c) I used sync so my POSIX attributes are in IPA but now I want to
switch to trust.
d) I had a third party solution that had posix zoning and I want to
replace it with the similar solution based on IPA.

Views (plural) are a way to merge data and present it to a subset of
clients. In this context it is not really clear what you mean by one
view.

In order to see views you'll need a modern SSSD client that knows how to
apply them. Ie viewS are applied on the client side. The server shows
only one view via LDAP.

Simo.


OK, I agree with multiple views being expensive and merging things on
the client but how you define which one is the default on the server?

We'll have one called default ?

Simo.



I do not care about the name i care about the content. Imagine that
there can be several different views. Which one is the default one? How
it is picked? Id there a way to change from one view to another? Also
this means that all legacy clients would have just one view because
there will be a single compat all of them can be pointed to. May be if
we can switch views on different replicas we would be able to create
zones such that different replicas are used to serve different groups of
legacy clients.

No we can't switch the default view for

Re: [Freeipa-devel] [PATCHES] 0562-0563 ix internal error when global policy is not readable

2014-05-30 Thread Petr Viktorin 

On 05/29/2014 07:13 PM, Rob Crittenden wrote:

Petr Viktorin wrote:

When investigating this issue I became very annoyed by the star import
hiding where names come from, so I did some cleanup first.


In krbtpolicy, an ACIError is now raised if:
- the user doesn't have permission to read any one of the ticket policy
   attributes on the requested entry
   (checked using attribute-level rights)
- any ticket policy attribute from the default policy is not available
   (either not readable, or not there at all)
   (only checked if these are accessed, i.e. when the user entry doesn't
override all of the defaults, or when requesting the global policy)

That means if the user is not available at all, you get a NotFound, but
if global policy is not found it's assumed that it's just unreadable.


That seems reasonable to me.

I also noticed a typo, ddoesn't


Fixed, thanks.


In the lower-level code, ldap2.py, we have some help
can_[read|write|etc] for managing rights. Would doing something similar
in baseldap be better than embedding the logic into each plugins?

So instead of this:

 if rights is None:
 rights = baseldap.get_effective_rights(
 ldap, dn, self.obj.default_attributes)
 if 'r' not in rights.get(attrname.lower(), ''):
 raise errors.ACIError(
 info=_('Ticket policy for %s could not be
read') %
 keys[-1])

You'd have this:

 if not baseldap.can_read(ldap, dn, attrname):
 raise errors.ACIError(
 info=_('Ticket policy for %s could not be
read') %
 keys[-1])


The second is definitely better.


This may end up fetching the rights multiple times depending on how many
things need to be read, so perhaps passing that in if you have it already.


This however means doing the get_effective_rights call anyway to get all 
the needed attrs, at which point most of the readability benefits are gone.


Actually I'd like to add some good attrlevelrights handling right into 
ipaldap. Let's do this correctly rather than add a quick fix to the 
helpers just so we can use them.

Issue here: https://fedorahosted.org/freeipa/ticket/4362

--
Petr³

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

Re: [Freeipa-devel] [PATCHES] 0562-0563 Fix internal error when global policy is not readable

2014-05-30 Thread Petr Viktorin 

On 05/30/2014 11:02 AM, Petr Viktorin wrote:

On 05/29/2014 07:13 PM, Rob Crittenden wrote:

Petr Viktorin wrote:

When investigating this issue I became very annoyed by the star import
hiding where names come from, so I did some cleanup first.


In krbtpolicy, an ACIError is now raised if:
- the user doesn't have permission to read any one of the ticket policy
   attributes on the requested entry
   (checked using attribute-level rights)
- any ticket policy attribute from the default policy is not available
   (either not readable, or not there at all)
   (only checked if these are accessed, i.e. when the user entry doesn't
override all of the defaults, or when requesting the global policy)

That means if the user is not available at all, you get a NotFound, but
if global policy is not found it's assumed that it's just unreadable.


That seems reasonable to me.

I also noticed a typo, ddoesn't


Fixed, thanks.


In the lower-level code, ldap2.py, we have some help
can_[read|write|etc] for managing rights. Would doing something similar
in baseldap be better than embedding the logic into each plugins?

So instead of this:

 if rights is None:
 rights = baseldap.get_effective_rights(
 ldap, dn, self.obj.default_attributes)
 if 'r' not in rights.get(attrname.lower(), ''):
 raise errors.ACIError(
 info=_('Ticket policy for %s could not be
read') %
 keys[-1])

You'd have this:

 if not baseldap.can_read(ldap, dn, attrname):
 raise errors.ACIError(
 info=_('Ticket policy for %s could not be
read') %
 keys[-1])


The second is definitely better.


This may end up fetching the rights multiple times depending on how many
things need to be read, so perhaps passing that in if you have it
already.


This however means doing the get_effective_rights call anyway to get all
the needed attrs, at which point most of the readability benefits are gone.

Actually I'd like to add some good attrlevelrights handling right into
ipaldap. Let's do this correctly rather than add a quick fix to the
helpers just so we can use them.
Issue here: https://fedorahosted.org/freeipa/ticket/4362


Once more, with patches

--
Petr³

From 4760edee0db8dd7f1d24daeee0b2501c485dc828 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Thu, 29 May 2014 15:39:26 +0200
Subject: [PATCH] krbtpolicy plugin: Code cleanup

- Use the new plugin registration API
  See: http://www.freeipa.org/page/Coding_Best_Practices#Decorator-based_plugin_registration

- Remove the star import from baseldap
  Part of the work for: https://fedorahosted.org/freeipa/ticket/2653
---
 ipalib/plugins/krbtpolicy.py | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/ipalib/plugins/krbtpolicy.py b/ipalib/plugins/krbtpolicy.py
index 22a961a4ab6005b138d0fb261d2a90527b373c48..a3b971e14697470790f8cd01fb45b194223a8226 100644
--- a/ipalib/plugins/krbtpolicy.py
+++ b/ipalib/plugins/krbtpolicy.py
@@ -17,10 +17,12 @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see http://www.gnu.org/licenses/.
 
-from ipalib import api
+from ipalib import api, errors, output, _
 from ipalib import Int, Str
-from ipalib.plugins.baseldap import *
-from ipalib import _
+from ipalib.plugins import baseldap
+from ipalib.plugins.baseldap import entry_to_dict, pkey_to_value
+from ipalib.plugable import Registry
+from ipapython.dn import DN
 
 __doc__ = _(
 Kerberos ticket policy
@@ -60,6 +62,8 @@
   ipa krbtpolicy-mod admin --maxlife=3600
 )
 
+register = Registry()
+
 # FIXME: load this from a config file?
 _default_values = {
 'krbmaxticketlife': 86400,
@@ -67,7 +71,8 @@
 }
 
 
-class krbtpolicy(LDAPObject):
+@register()
+class krbtpolicy(baseldap.LDAPObject):
 
 Kerberos Ticket Policy object
 
@@ -141,10 +146,9 @@ def get_dn(self, *keys, **kwargs):
 return self.api.Object.user.get_dn(*keys, **kwargs)
 return DN(self.container_dn, api.env.basedn)
 
-api.register(krbtpolicy)
 
-
-class krbtpolicy_mod(LDAPUpdate):
+@register()
+class krbtpolicy_mod(baseldap.LDAPUpdate):
 __doc__ = _('Modify Kerberos ticket policy.')
 
 def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options):
@@ -155,10 +159,9 @@ def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options):
 options['all'] = False
 return dn
 
-api.register(krbtpolicy_mod)
 
-
-class krbtpolicy_show(LDAPRetrieve):
+@register()
+class krbtpolicy_show(baseldap.LDAPRetrieve):
 __doc__ = _('Display the current Kerberos ticket policy.')
 
 def pre_callback(self, ldap, dn, attrs_list, *keys, **options):
@@ -180,10 +183,9 @@ def post_callback(self, ldap, dn,

Re: [Freeipa-devel] ipa-server-install error

2014-05-30 Thread Jan Pazdziora 
On Fri, May 30, 2014 at 08:00:10AM +0200, Martin Kosek wrote:
 On 05/30/2014 06:14 AM, Dmitri Pal wrote:
  On 05/29/2014 01:44 AM, James wrote:
  /usr/bin/runcon: invalid context: unconfined_u:system_r:pki_ca_script_t:s0:
  Invalid argument
  Looks like and AVC that lead to restart failure of the PKI instance that in
  turn led to failure to configure CA.
 
 I asked Ade Lee and got this response:
 
 On 05/29/2014 04:44 PM, Ade Lee wrote:
  The problem is here:
 
  /usr/bin/runcon: invalid context:
  unconfined_u:system_r:pki_ca_script_t:s0: Invalid argument
 
  We've seen this before.  Sometimes pki-selinux fails to load its policy
  for some reason.  The best thing to do is to force re-install

Did you try to use %posttrans instead of %post?

https://bugzilla.redhat.com/show_bug.cgi?id=505066

-- 
Jan Pazdziora
Principal Software Engineer, Identity Management Engineering, Red Hat

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

[Freeipa-devel] [PATCH] 0057 Fix indentation

2014-05-30 Thread Martin Basti 
Patch fixes indentation in one function in ipalib/util.py
-- 
Martin^2 Basti
From dda5b130fc6546a53e85301a4e93c6f6130e0074 Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Fri, 30 May 2014 13:49:02 +0200
Subject: [PATCH] Fix indentation

There was 5 spaces instead of 4, my bad.
---
 ipalib/util.py | 42 +-
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/ipalib/util.py b/ipalib/util.py
index 3fc8544810d0e45eb1dca9bed357ffd51c401560..a2c2a90e47181dbf45b1954c1edc8d6bd0184962 100644
--- a/ipalib/util.py
+++ b/ipalib/util.py
@@ -221,33 +221,33 @@ def normalize_zone(zone):
 
 
 def validate_dns_label(dns_label, allow_underscore=False, allow_slash=False):
- base_chars = 'a-z0-9'
- extra_chars = ''
- middle_chars = ''
+base_chars = 'a-z0-9'
+extra_chars = ''
+middle_chars = ''
 
- if allow_underscore:
- extra_chars += '_'
- if allow_slash:
- middle_chars += '/'
+if allow_underscore:
+extra_chars += '_'
+if allow_slash:
+middle_chars += '/'
 
- middle_chars = middle_chars + '-' #has to be always the last in the regex [-]
+middle_chars = middle_chars + '-' #has to be always the last in the regex [-]
 
- label_regex = r'^[%(base)s%(extra)s]([%(base)s%(extra)s%(middle)s]?[%(base)s%(extra)s])*$' \
- % dict(base=base_chars, extra=extra_chars, middle=middle_chars)
- regex = re.compile(label_regex, re.IGNORECASE)
+label_regex = r'^[%(base)s%(extra)s]([%(base)s%(extra)s%(middle)s]?[%(base)s%(extra)s])*$' \
+% dict(base=base_chars, extra=extra_chars, middle=middle_chars)
+regex = re.compile(label_regex, re.IGNORECASE)
 
- if not dns_label:
- raise ValueError(_('empty DNS label'))
+if not dns_label:
+raise ValueError(_('empty DNS label'))
 
- if len(dns_label)  63:
- raise ValueError(_('DNS label cannot be longer that 63 characters'))
+if len(dns_label)  63:
+raise ValueError(_('DNS label cannot be longer that 63 characters'))
 
- if not regex.match(dns_label):
- chars = ', '.join('%s' % c for c in extra_chars + middle_chars)
- chars2 = ', '.join('%s' % c for c in middle_chars)
- raise ValueError(_(only letters, numbers, %(chars)s are allowed.  \
-DNS label may not start or end with %(chars2)s) \
-% dict(chars=chars, chars2=chars2))
+if not regex.match(dns_label):
+chars = ', '.join('%s' % c for c in extra_chars + middle_chars)
+chars2 = ', '.join('%s' % c for c in middle_chars)
+raise ValueError(_(only letters, numbers, %(chars)s are allowed.  \
+   DNS label may not start or end with %(chars2)s) \
+   % dict(chars=chars, chars2=chars2))
 
 
 def validate_domain_name(domain_name, allow_underscore=False, allow_slash=False):
-- 
1.8.3.1

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

[Freeipa-devel] [PATCH] 0058 Test DNS: dnsrecord-* zone.test. zone.test. should work

2014-05-30 Thread Martin Basti 
Test only, issue was fixed in
https://fedorahosted.org/freeipa/ticket/3169

Required patches: mbasti 0029-0032, 0034-0040, 0047,
0041-0042, 0045-0046

Patch attached.
Ticket: https://fedorahosted.org/freeipa/ticket/4232
-- 
Martin^2 Basti
From 9cb372f5ebf6d5771eccbd27f2c1136d29cd0293 Mon Sep 17 00:00:00 2001
From: Martin Basti mba...@redhat.com
Date: Fri, 30 May 2014 13:58:21 +0200
Subject: [PATCH] Test DNS: dnsrecord-* zone.test. zone.test. should work

Old ipa versions allows only dnsrecord-* zone.test. @

This issue was fixed in ticket:
https://fedorahosted.org/freeipa/ticket/3169

Ticket: https://fedorahosted.org/freeipa/ticket/4232
---
 ipatests/test_xmlrpc/test_dns_plugin.py | 34 +
 1 file changed, 34 insertions(+)

diff --git a/ipatests/test_xmlrpc/test_dns_plugin.py b/ipatests/test_xmlrpc/test_dns_plugin.py
index 346182e9ba6ff1e756141dfd4c7d05248705708c..f36027b1a29b4a62727bd8f71c211c56bb9ac164 100644
--- a/ipatests/test_xmlrpc/test_dns_plugin.py
+++ b/ipatests/test_xmlrpc/test_dns_plugin.py
@@ -2193,6 +2193,40 @@ class test_dns(Declarative):
 },
 ),
 
+
+#https://fedorahosted.org/freeipa/ticket/4232
+dict(
+desc='Add MX record (2) to zone %r using dnsrecord_add' % (idnzone1),
+command=('dnsrecord_add', [idnzone1, idnzone1], {'mxrecord': u10 %s % idnzone1_mname }),
+expected={
+'value': idnzone1_dnsname,
+'summary': None,
+'result': {
+'objectclass': objectclasses.dnszone,
+'dn': idnzone1_dn,
+'idnsname': [_dns_zone_record],
+'mxrecord': [u0 %s % idnzone1_mname, u10 %s % idnzone1_mname],
+'nsrecord': [idnzone1_mname],
+},
+},
+),
+
+
+dict(
+desc='Remove MX record (2) from zone %r using dnsrecord_add' % (idnzone1),
+command=('dnsrecord_del', [idnzone1, idnzone1], {'mxrecord': u10 %s % idnzone1_mname }),
+expected={
+'value': [idnzone1_dnsname],
+'summary': None,
+'result': {
+'idnsname': [_dns_zone_record],
+'mxrecord': [u0 %s % idnzone1_mname],
+'nsrecord': [idnzone1_mname],
+},
+},
+),
+
+
 dict(
 desc='Add KX record to zone %r using dnsrecord_add' % (idnzone1),
 command=('dnsrecord_add', [idnzone1, u'@'], {'kxrecord': u0 %s % idnzone1_mname }),
-- 
1.8.3.1

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

Re: [Freeipa-devel] User life cycle: question regarding the design

2014-05-30 Thread Petr Viktorin 

On 05/30/2014 08:37 AM, Martin Kosek wrote:

On 05/29/2014 08:14 PM, Dmitri Pal wrote:

On 05/29/2014 08:39 AM, Simo Sorce wrote:

On Thu, 2014-05-29 at 09:43 +0200, Martin Kosek wrote:

On 05/29/2014 05:31 AM, Dmitri Pal wrote:

On 05/26/2014 01:49 AM, Martin Kosek wrote:

On 05/23/2014 04:55 PM, Simo Sorce wrote:

On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote:

This, I believe, has already been covered, but I'm concerned with the
(over)use of active/inactive in this discussion.

I think use of inactive and active to describe users might be
confusing since there is already an account enable/disable command.
This
on top of unlock, are there now 3 possible boolean states a user can
be
in? locked/unlocked, enabled/disabled, active/inactive, plus
deleted/active and staged/active?


Agree, we should only have ipa user-unstage username and not call
this operations with words like active/inactive.

User's in the staging area are not inactive, they are *not* users yet in
the first place.

Simo.


Ok. Let us consolidate the decisions, I think we are now running in circles.
Let me start from Petr3's API proposal which was a functionally complete
proposal and start from there:

On 05/22/2014 10:47 AM, Petr Viktorin wrote:

...
My proposal would be that the move commands use the verb for the target
and an
option for the source, and add/mod use an option for the container:

1) adding a new user
(to active)   ipa user-add tuser ...
(to stage)ipa user-add tuser --staged ...

Ok.


(to deleted)  ipa user-add tuser --deleted ...  (*)

Not needed.


2) moving to main
(from stage)  ipa user-activate tuser  (**)
(from del)ipa user-activate tuser --deleted

We need both, alternative is Simo's proposal:

ipa user-unstage
ipa user-undelete

I personally like unstage and undelete commands, I would go with those.

Sorry for coming late to the party.
I strongly do not like unstage
This suggests that the user will be removed from staged but does not indicate
that the full user will be created.
As I suggested elsewhere provision-user or user-provision (or may be even
user-add --from-stage) would be better.

As Petr3 already noted on 05/19/2014 03:19 PM, integrating unstaging operation
could get messy and would not create the right API. Using a separate call would
be cleaner. As we see, choosing the right action term has proven very difficult
- everyone has strong opinion on the command name :-)

I already saw user-activate and user-unstage to be trashed so I am thinking
what we are left with. I am still fan of user-unstage, user-provision is not
telling me much more than user-unstage.


3) moving to deleted
(from active) ipa user-del tuser

Ok.


(from stage)  ipa user-del tuser --staged

IMO staged deleted users should not be moved to deleted container, but simply
permanently deleted. As Simo noted, staged user are not real users, just
incomplete users.


4) moving to stage
(from active) ipa user-stage tuser


This was suggested for completeness.
I think we are cutting corners but I would not insist here.


(from del)ipa user-stage tuser --deleted

None of the commands are needed for the basic workflow.

But this is a valid use case. I created a user, deleted it and want to rebuild
it becuase something got corrupted in the original entry. I agree it is not a
primary use case but then we should have a ticket to track this RFE for
future.

This was not about cutting corners, this was about what operation makes sense
and what we should support. Stage was defined as a tree with incomplete user,
thus this proposal - Simo was not very OK with this workflow.


5) modifying
(in active)   ipa user-mod tuser ...

Ok.


(in stage)ipa user-mod tuser --staged ...

Simo did not like this command, I would personally add it. As long as we have
ipa user-add --staged, we should also have an option to delete and modify
user in staged area.


(in del)  ipa user-mod tuser --deleted ...

Not needed.

Is this acceptable for everyone? If yes, the next step would be for Thierry
to update the design page with new proposals.

Martin

Let me try to consolidate again the proposals and changes for the workflowAPI
we have so far:

1) Manipulating staged users
- staged users must have UID RDN
- UID uniqueness plugin should not be enforcing in staging area
- we do not want it in user plugin as it requires different parameters and
objectclasses
- API:
ipa stage-user-add
ipa stage-user-mod
ipa stage-user-find
ipa stage-user-del

2) Activating staged user
- activation will not do MODRDN, it will create a new user in active container
and then delete the old one (to create right structural objectclass set)
- for now, we need to allow operator delete any user in staged and add any user
in active tree
- API
ipa stage-user-activate
- other options mentioned in the past were user-unstage and user-activate

3) Manipulating deleted users
- deletion and undeletion will do MODRDN and will use the ACI that Thierry
implemented
- API
ipa user-del

Re: [Freeipa-devel] User life cycle: question regarding the design

2014-05-30 Thread Dmitri Pal 

On 05/30/2014 09:24 AM, Petr Viktorin wrote:

On 05/30/2014 08:37 AM, Martin Kosek wrote:

On 05/29/2014 08:14 PM, Dmitri Pal wrote:

On 05/29/2014 08:39 AM, Simo Sorce wrote:

On Thu, 2014-05-29 at 09:43 +0200, Martin Kosek wrote:

On 05/29/2014 05:31 AM, Dmitri Pal wrote:

On 05/26/2014 01:49 AM, Martin Kosek wrote:

On 05/23/2014 04:55 PM, Simo Sorce wrote:

On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote:
This, I believe, has already been covered, but I'm concerned 
with the

(over)use of active/inactive in this discussion.

I think use of inactive and active to describe users might be
confusing since there is already an account enable/disable 
command.

This
on top of unlock, are there now 3 possible boolean states a 
user can

be
in? locked/unlocked, enabled/disabled, active/inactive, plus
deleted/active and staged/active?

Agree, we should only have ipa user-unstage username and 
not call

this operations with words like active/inactive.

User's in the staging area are not inactive, they are *not* 
users yet in

the first place.

Simo.

Ok. Let us consolidate the decisions, I think we are now running 
in circles.
Let me start from Petr3's API proposal which was a functionally 
complete

proposal and start from there:

On 05/22/2014 10:47 AM, Petr Viktorin wrote:

...
My proposal would be that the move commands use the verb for 
the target

and an
option for the source, and add/mod use an option for the 
container:


1) adding a new user
(to active)   ipa user-add tuser ...
(to stage)ipa user-add tuser --staged ...

Ok.


(to deleted)  ipa user-add tuser --deleted ...  (*)

Not needed.


2) moving to main
(from stage)  ipa user-activate tuser  (**)
(from del)ipa user-activate tuser --deleted

We need both, alternative is Simo's proposal:

ipa user-unstage
ipa user-undelete

I personally like unstage and undelete commands, I would go with 
those.

Sorry for coming late to the party.
I strongly do not like unstage
This suggests that the user will be removed from staged but does 
not indicate

that the full user will be created.
As I suggested elsewhere provision-user or user-provision (or may 
be even

user-add --from-stage) would be better.
As Petr3 already noted on 05/19/2014 03:19 PM, integrating 
unstaging operation
could get messy and would not create the right API. Using a 
separate call would
be cleaner. As we see, choosing the right action term has proven 
very difficult

- everyone has strong opinion on the command name :-)

I already saw user-activate and user-unstage to be trashed so I am 
thinking
what we are left with. I am still fan of user-unstage, 
user-provision is not

telling me much more than user-unstage.


3) moving to deleted
(from active) ipa user-del tuser

Ok.


(from stage)  ipa user-del tuser --staged
IMO staged deleted users should not be moved to deleted 
container, but simply
permanently deleted. As Simo noted, staged user are not real 
users, just

incomplete users.


4) moving to stage
(from active) ipa user-stage tuser


This was suggested for completeness.
I think we are cutting corners but I would not insist here.


(from del)ipa user-stage tuser --deleted

None of the commands are needed for the basic workflow.
But this is a valid use case. I created a user, deleted it and 
want to rebuild
it becuase something got corrupted in the original entry. I agree 
it is not a
primary use case but then we should have a ticket to track this 
RFE for

future.
This was not about cutting corners, this was about what operation 
makes sense
and what we should support. Stage was defined as a tree with 
incomplete user,

thus this proposal - Simo was not very OK with this workflow.


5) modifying
(in active)   ipa user-mod tuser ...

Ok.


(in stage)ipa user-mod tuser --staged ...
Simo did not like this command, I would personally add it. As 
long as we have
ipa user-add --staged, we should also have an option to delete 
and modify

user in staged area.


(in del)  ipa user-mod tuser --deleted ...

Not needed.

Is this acceptable for everyone? If yes, the next step would be 
for Thierry

to update the design page with new proposals.

Martin
Let me try to consolidate again the proposals and changes for the 
workflowAPI

we have so far:

1) Manipulating staged users
- staged users must have UID RDN
- UID uniqueness plugin should not be enforcing in staging area
- we do not want it in user plugin as it requires different 
parameters and

objectclasses
- API:
ipa stage-user-add
ipa stage-user-mod
ipa stage-user-find
ipa stage-user-del

2) Activating staged user
- activation will not do MODRDN, it will create a new user in 
active container
and then delete the old one (to create right structural 
objectclass set)
- for now, we need to allow operator delete any user in staged and 
add any user

in active tree
- API
ipa stage-user-activate
- other options mentioned in the past were user-unstage and 
user-activate


3) Manipulating deleted users
- deletion and

Re: [Freeipa-devel] User life cycle: question regarding the design

2014-05-30 Thread Jan Cholasta 

On 30.5.2014 15:24, Petr Viktorin wrote:

On 05/30/2014 08:37 AM, Martin Kosek wrote:

On 05/29/2014 08:14 PM, Dmitri Pal wrote:

On 05/29/2014 08:39 AM, Simo Sorce wrote:

On Thu, 2014-05-29 at 09:43 +0200, Martin Kosek wrote:

On 05/29/2014 05:31 AM, Dmitri Pal wrote:

On 05/26/2014 01:49 AM, Martin Kosek wrote:

On 05/23/2014 04:55 PM, Simo Sorce wrote:

On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote:

This, I believe, has already been covered, but I'm concerned
with the
(over)use of active/inactive in this discussion.

I think use of inactive and active to describe users might be
confusing since there is already an account enable/disable
command.
This
on top of unlock, are there now 3 possible boolean states a
user can
be
in? locked/unlocked, enabled/disabled, active/inactive, plus
deleted/active and staged/active?


Agree, we should only have ipa user-unstage username and not
call
this operations with words like active/inactive.

User's in the staging area are not inactive, they are *not*
users yet in
the first place.

Simo.


Ok. Let us consolidate the decisions, I think we are now running
in circles.
Let me start from Petr3's API proposal which was a functionally
complete
proposal and start from there:

On 05/22/2014 10:47 AM, Petr Viktorin wrote:

...
My proposal would be that the move commands use the verb for the
target
and an
option for the source, and add/mod use an option for the container:

1) adding a new user
(to active)   ipa user-add tuser ...
(to stage)ipa user-add tuser --staged ...

Ok.


(to deleted)  ipa user-add tuser --deleted ...  (*)

Not needed.


2) moving to main
(from stage)  ipa user-activate tuser  (**)
(from del)ipa user-activate tuser --deleted

We need both, alternative is Simo's proposal:

ipa user-unstage
ipa user-undelete

I personally like unstage and undelete commands, I would go with
those.

Sorry for coming late to the party.
I strongly do not like unstage
This suggests that the user will be removed from staged but does
not indicate
that the full user will be created.
As I suggested elsewhere provision-user or user-provision (or may
be even
user-add --from-stage) would be better.

As Petr3 already noted on 05/19/2014 03:19 PM, integrating
unstaging operation
could get messy and would not create the right API. Using a
separate call would
be cleaner. As we see, choosing the right action term has proven
very difficult
- everyone has strong opinion on the command name :-)

I already saw user-activate and user-unstage to be trashed so I am
thinking
what we are left with. I am still fan of user-unstage,
user-provision is not
telling me much more than user-unstage.


3) moving to deleted
(from active) ipa user-del tuser

Ok.


(from stage)  ipa user-del tuser --staged

IMO staged deleted users should not be moved to deleted
container, but simply
permanently deleted. As Simo noted, staged user are not real
users, just
incomplete users.


4) moving to stage
(from active) ipa user-stage tuser


This was suggested for completeness.
I think we are cutting corners but I would not insist here.


(from del)ipa user-stage tuser --deleted

None of the commands are needed for the basic workflow.

But this is a valid use case. I created a user, deleted it and
want to rebuild
it becuase something got corrupted in the original entry. I agree
it is not a
primary use case but then we should have a ticket to track this
RFE for
future.

This was not about cutting corners, this was about what operation
makes sense
and what we should support. Stage was defined as a tree with
incomplete user,
thus this proposal - Simo was not very OK with this workflow.


5) modifying
(in active)   ipa user-mod tuser ...

Ok.


(in stage)ipa user-mod tuser --staged ...

Simo did not like this command, I would personally add it. As
long as we have
ipa user-add --staged, we should also have an option to delete
and modify
user in staged area.


(in del)  ipa user-mod tuser --deleted ...

Not needed.

Is this acceptable for everyone? If yes, the next step would be
for Thierry
to update the design page with new proposals.

Martin

Let me try to consolidate again the proposals and changes for the
workflowAPI
we have so far:

1) Manipulating staged users
- staged users must have UID RDN
- UID uniqueness plugin should not be enforcing in staging area
- we do not want it in user plugin as it requires different
parameters and
objectclasses
- API:
ipa stage-user-add
ipa stage-user-mod
ipa stage-user-find
ipa stage-user-del

2) Activating staged user
- activation will not do MODRDN, it will create a new user in
active container
and then delete the old one (to create right structural objectclass
set)
- for now, we need to allow operator delete any user in staged and
add any user
in active tree
- API
ipa stage-user-activate
- other options mentioned in the past were user-unstage and
user-activate

3) Manipulating deleted users
- deletion and undeletion will do MODRDN and will use the ACI

Re: [Freeipa-devel] User life cycle: question regarding the design

2014-05-30 Thread Rob Crittenden 
Petr Viktorin wrote:
 On 05/30/2014 08:37 AM, Martin Kosek wrote:
 On 05/29/2014 08:14 PM, Dmitri Pal wrote:
 On 05/29/2014 08:39 AM, Simo Sorce wrote:
 On Thu, 2014-05-29 at 09:43 +0200, Martin Kosek wrote:
 On 05/29/2014 05:31 AM, Dmitri Pal wrote:
 On 05/26/2014 01:49 AM, Martin Kosek wrote:
 On 05/23/2014 04:55 PM, Simo Sorce wrote:
 On Fri, 2014-05-23 at 10:13 -0400, Rob Crittenden wrote:
 This, I believe, has already been covered, but I'm concerned
 with the
 (over)use of active/inactive in this discussion.

 I think use of inactive and active to describe users might be
 confusing since there is already an account enable/disable
 command.
 This
 on top of unlock, are there now 3 possible boolean states a
 user can
 be
 in? locked/unlocked, enabled/disabled, active/inactive, plus
 deleted/active and staged/active?

 Agree, we should only have ipa user-unstage username and not
 call
 this operations with words like active/inactive.

 User's in the staging area are not inactive, they are *not*
 users yet in
 the first place.

 Simo.

 Ok. Let us consolidate the decisions, I think we are now running
 in circles.
 Let me start from Petr3's API proposal which was a functionally
 complete
 proposal and start from there:

 On 05/22/2014 10:47 AM, Petr Viktorin wrote:
 ...
 My proposal would be that the move commands use the verb for the
 target
 and an
 option for the source, and add/mod use an option for the container:

 1) adding a new user
 (to active)   ipa user-add tuser ...
 (to stage)ipa user-add tuser --staged ...
 Ok.

 (to deleted)  ipa user-add tuser --deleted ...  (*)
 Not needed.

 2) moving to main
 (from stage)  ipa user-activate tuser  (**)
 (from del)ipa user-activate tuser --deleted
 We need both, alternative is Simo's proposal:

 ipa user-unstage
 ipa user-undelete

 I personally like unstage and undelete commands, I would go with
 those.
 Sorry for coming late to the party.
 I strongly do not like unstage
 This suggests that the user will be removed from staged but does
 not indicate
 that the full user will be created.
 As I suggested elsewhere provision-user or user-provision (or may
 be even
 user-add --from-stage) would be better.
 As Petr3 already noted on 05/19/2014 03:19 PM, integrating
 unstaging operation
 could get messy and would not create the right API. Using a
 separate call would
 be cleaner. As we see, choosing the right action term has proven
 very difficult
 - everyone has strong opinion on the command name :-)

 I already saw user-activate and user-unstage to be trashed so I am
 thinking
 what we are left with. I am still fan of user-unstage,
 user-provision is not
 telling me much more than user-unstage.

 3) moving to deleted
 (from active) ipa user-del tuser
 Ok.

 (from stage)  ipa user-del tuser --staged
 IMO staged deleted users should not be moved to deleted
 container, but simply
 permanently deleted. As Simo noted, staged user are not real
 users, just
 incomplete users.

 4) moving to stage
 (from active) ipa user-stage tuser

 This was suggested for completeness.
 I think we are cutting corners but I would not insist here.

 (from del)ipa user-stage tuser --deleted
 None of the commands are needed for the basic workflow.
 But this is a valid use case. I created a user, deleted it and
 want to rebuild
 it becuase something got corrupted in the original entry. I agree
 it is not a
 primary use case but then we should have a ticket to track this
 RFE for
 future.
 This was not about cutting corners, this was about what operation
 makes sense
 and what we should support. Stage was defined as a tree with
 incomplete user,
 thus this proposal - Simo was not very OK with this workflow.

 5) modifying
 (in active)   ipa user-mod tuser ...
 Ok.

 (in stage)ipa user-mod tuser --staged ...
 Simo did not like this command, I would personally add it. As
 long as we have
 ipa user-add --staged, we should also have an option to delete
 and modify
 user in staged area.

 (in del)  ipa user-mod tuser --deleted ...
 Not needed.

 Is this acceptable for everyone? If yes, the next step would be
 for Thierry
 to update the design page with new proposals.

 Martin
 Let me try to consolidate again the proposals and changes for the
 workflowAPI
 we have so far:

 1) Manipulating staged users
 - staged users must have UID RDN
 - UID uniqueness plugin should not be enforcing in staging area
 - we do not want it in user plugin as it requires different
 parameters and
 objectclasses
 - API:
 ipa stage-user-add
 ipa stage-user-mod
 ipa stage-user-find
 ipa stage-user-del

 2) Activating staged user
 - activation will not do MODRDN, it will create a new user in
 active container
 and then delete the old one (to create right structural objectclass
 set)
 - for now, we need to allow operator delete any user in staged and
 add any user
 in active tree
 - API
 ipa stage-user-activate
 - other options mentioned in the past were user-unstage and
 user-activate

 3)

Re: [Freeipa-devel] CA certificate renewal, shared store trust settings

2014-05-30 Thread Nalin Dahyabhai 
On Fri, May 30, 2014 at 09:09:46AM +0200, Jan Cholasta wrote:
 On 29.5.2014 19:44, Nalin Dahyabhai wrote:
 I'm working on adding to certmonger the ability to read the IPA root
 certificate from the server and store it locally, and I'm looking at the
 V4 shared certificate store feature [1] with an eye toward also pulling
 down and processing those certificates.  Before I head down that path,
 I've got a few questions about the schema that the page describes for
 storing trust information.
 
 So, you want to fetch the certificates directly from LDAP? Shouldn't
 they rather be fetched using IPA API (in ipa-submit) or Dogtag API
 (in dogtag-ipa-renew-agent-submit)?

Yes, that's something the daemon is farming out to the enrollment
helpers.  As a start, though, I'm only looking at teaching ipa-submit to
fetch this information.

The IPA interfaces run over HTTPS, so I thought that having ipa-submit
search LDAP using GSSAPI would avoid complications that could arise if
the CA certificate had become invalid before we went to fetch things.

The request for the read the root certificate functionality is to have
something that works against servers running IPA on EL6, so the ability
to fetch the v3 root information is dictated by needing to work against
what we're already storing and offering there.

Accessing the additional information that's coming in v4 could be done
differently, but I'd also lean toward looking at the directory directly.
The design page mentions asking SSSD for it, which I guess would work.

 In the past few months that I worked on the CA certificate renewal
 feature the shared certificate store design has evolved into
 something more about certificate trust policy rather than simple
 storage of CA certificates. My plan is to integrate it with p11-kit
 in the forthcoming months to provide the policy to IPA clients. SSSD
 is going to be used as the component between IPA and p11-kit. A
 PKCS#11 module will be provided for (not only) that. (This is what
 http://www.freeipa.org/page/V4/CA_certificate_renewal_(2) is going
 to be about.)
 
 I can imagine you might as well talk to the module to fetch the CA
 certificates. Are there any plans to support PKCS#11 as a storage
 backend in certmonger?

Only notionally, as it it's only ever been one of those would be cool,
but we don't need it in the short-term things.  I also wasn't looking
forward to dealing with cases where a removable token isn't inserted
right when we intend to access it, but if we need to make that work,
then okay.

 This does not make me nervous at all. Take a look at other similar
 attributes in IPA, they all use directory string syntax. I'm open to
 suggestions, though.

The first thing that comes to mind is an enumerated syntax like the one
for booleans, but I understand that enforcing that would require help
from the server itself.  The docs tell me that syntax plugins are a
thing we can supply, but that might be more than we want to bite off.

 The ipaKeyExtUsage attribute, along with ipaKeyTrust values of 'trusted'
 and 'distrusted', appears to map pretty directly to the sort of
 information that OpenSSL stores in trusted certificates [2], but going
 through the man pages for x509(1) and verify(1), I don't see anything
 that obviously corresponds to an ipaKeyTrust value of 'unknown'.   What's
 that value intended to signify, and how would consumers of the
 certificates be expected to treat certificates from entries with that
 ipaKeyTrust value?
 
 Actually it is designed to map to p11-kit-style trust policy 
 (http://p11-glue.freedesktop.org/doc/storing-trust-policy/index.html),
 which is a superset of OpenSSL's.

What's the planned schedule for teaching NSS and OpenSSL to consume
trust information supplied in this format?

 The unknown value means the trust is not explicitly given and that
 if there is other source of trust information for the
 key/certificate, it should be used. In p11-kit terms, it is for
 certificates which are neither in the anchors nor the blacklist set.
 In NSS terms, it's for certificates without any of the C, T, P or p
 trust flags.

Okay, that makes sense -- they're around for building chains, but not
much else.

 Are there examples of what the ipaKeyUsage attribute should contain?
 
 It's the purpose bit names from the key usage certificate extension
 (http://tools.ietf.org/html/rfc5280#section-4.2.1.3) or none.

So, enumerated values represented as directory strings?

 Is there a recommended method for mapping from this representation to
 the form that we'd pass to certutil(1)'s '-t' option when storing the
 certificates in NSS databases, or is the intent that it be translated
 into NSS-specific PKCS#11 attributes set on those certificates?
 
 Well, it can be both. But as I said above, I'm not sure if reading
 from LDAP directly is the best thing to do in this case.

[shrug]  If that's where it's being stored, something's going to have to
fetch it from there.  Until the SSSD and IPA interfaces are

[Freeipa-devel] Patch for #1539

2014-05-30 Thread Simo Sorce 
I have rebased theold patch attached to the ticket, unfortunately I
haven't had time to test it yet, but didn't want to lose it in some
branch.

Simo.
-- 
Simo Sorce * Red Hat, Inc * New York
From df31e12b2e86f4ef8b840637ae898844c043fa63 Mon Sep 17 00:00:00 2001
From: Simo Sorce s...@redhat.com
Date: Thu, 9 May 2013 14:25:14 -0400
Subject: [PATCH] Check for password expiration in pre-bind

If the password is expired fail a password bind.

Resolves: https://fedorahosted.org/freeipa/ticket/1539
---
 daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c | 33 ---
 1 file changed, 29 insertions(+), 4 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c
index 23c7cb18c9a1cb5256254f20080c5d9aaec25579..6786c6ddb4de4158ec680e271cae29318bc150ce 100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c
@@ -1217,13 +1217,35 @@ static bool ipapwd_pre_bind_otp(const char *bind_dn, Slapi_Entry *entry,
 }
 
 static int ipapwd_authenticate(const char *dn, Slapi_Entry *entry,
-   const struct berval *credentials)
+   const struct berval *credentials,
+   const char **errmsg)
 {
 Slapi_Value **pwd_values = NULL; /* values of userPassword attribute */
 Slapi_Value *value = NULL;
 Slapi_Attr *attr = NULL;
+struct tm expire_tm;
+char *expire;
+char *p;
 int ret;
 
+/* check the if the krbPrincipalKey attribute is present */
+ret = slapi_entry_attr_find(entry, krbprincipalkey, attr);
+if (!ret) {
+/* check that the password is not expired */
+expire = slapi_entry_attr_get_charptr(entry, krbpasswordexpiration);
+if (expire) {
+memset(expire_tm, 0, sizeof (expire_tm));
+p = strptime(expire, %Y%m%d%H%M%SZ, expire_tm);
+if (*p) {
+LOG(Invalid expiration date string format);
+return 1;
+} else if (time(NULL)  mktime(expire_tm)) {
+*errmsg = The user password is expired;
+return 1;
+}
+}
+}
+
 /* retrieve userPassword attribute */
 ret = slapi_entry_attr_find(entry, SLAPI_USERPWD_ATTR, attr);
 if (ret) {
@@ -1381,7 +1403,7 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb)
 static const char *attrs_list[] = {
 SLAPI_USERPWD_ATTR, ipaUserAuthType, krbprincipalkey, uid,
 krbprincipalname, objectclass, passwordexpirationtime,
-passwordhistory, krbprincipalexpiration,
+passwordhistory, krbprincipalexpiration, krbpasswordexpiration,
 NULL
 };
 struct berval *credentials = NULL;
@@ -1394,6 +1416,7 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb)
 time_t expire_time;
 char *principal_expire = NULL;
 struct tm expire_tm;
+const char *errmsg = NULL;
 
 /* get BIND parameters */
 ret |= slapi_pblock_get(pb, SLAPI_BIND_TARGET, dn);
@@ -1454,10 +1477,12 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb)
 }
 
 /* Authenticate the user. */
-ret = ipapwd_authenticate(dn, entry, credentials);
+ret = ipapwd_authenticate(dn, entry, credentials, errmsg);
 if (ret) {
 slapi_entry_free(entry);
-return 0;
+slapi_send_ldap_result(pb, LDAP_INVALID_CREDENTIALS,
+   NULL, errmsg, 0, NULL);
+return 1;
 }
 
 /* Attempt to handle a token synchronization request. */
-- 
1.9.0

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