Re: [Freeipa-devel] [PATCH] move replication topology to shared tree

2014-10-13 Thread Martin Kosek 
On 10/10/2014 06:44 PM, Simo Sorce wrote:
 On Fri, 10 Oct 2014 18:38:36 +0200
 Ludwig Krispenz lkris...@redhat.com wrote:
 

 On 10/10/2014 06:30 PM, James wrote:
 On 10 October 2014 12:21, Simo Sorce s...@redhat.com wrote:


 First thing, I do not think we want a new command here.
 If we need commands outside of the ipa framework they should be
 integrated in the ipa-replica-manage tool.
 But really one of the reasons to move data in the shared tree was
 that we could grow native framework command to handle the topology
 so we can manage the topology directly from the UI.
 So I am not happy with ipa-tology-manage
 I agree here... I think the current interface of ipa-replica-manage
 is fine, however the need to copy the credentials around and the
 need for a password are the problem. In fact, I particularly like
 the current interface, and puppet-ipa has already wrapped this
 successfully. In other words, the design checks out. Good job IPA
 team.

 All management should happen in the shared tree, moving to be able
 to avoid directly touching cn=config and avoid the need for DM
 password is one of the main reasons to do this work ...
 I'll comment later on Simmo's other comments, but I need access to 
 cn=config for two reasons,
 - I need to know if the plugin is deployed and enabled
 
 Let's expose something in rootDSE then, that's the standard way to
 do this (though it is unnecessary, if the shared tree is present you
 already know it is available).

+1, for the plugin enabled/disabled status. However, in case you really need to
let admin or other privileged person to look in specified part of cn=config,
this can be done with standard permissions. We already have for example
permission for reading replication agreements:

dn: cn=config
aci: (targetattr = cn || createtimestamp || description || entryusn ||
modifytimestamp || nsds50ruv ||  nsds5beginreplicarefresh ||
nsds5debugreplicatimeout || nsds5flags || nsds5replicaabortcleanruv ||   ...
winsyncsubtreepair || winsyncwindowsfilter)(targetfilter =
(|(objectclass=nsds5Replica)(objectclass=nsds5replicationagreement)(objectclass=nsDSWindowsReplicationAgreement)(objectClass=nsMappingTree)))(version
3.0;acl permission:System: Read Replication Agreements; allow
(compare,read,search) groupdn = ldap:///cn=System: Read Replication
Agreements,cn=permissions,cn=pbac,dc=ipa,dc=example;)

Martin

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

Re: [Freeipa-devel] Dogtag lightweight sub-CAs; updated design

2014-10-13 Thread Fraser Tweedale 
On Tue, Oct 07, 2014 at 09:40:12AM -0400, Simo Sorce wrote:
 On Tue, 07 Oct 2014 09:29:33 -0400
 Rob Crittenden rcrit...@redhat.com wrote:
 
  Simo Sorce wrote:
   On Tue, 07 Oct 2014 13:47:05 +0200
   Martin Kosek mko...@redhat.com wrote:
   
   On 10/07/2014 05:31 AM, Fraser Tweedale wrote:
   Hi all,
  
   The Dogtag lightweight sub-CAs design has undergone major revision
   and expansion ahead of beginning the implementation (I plan to
   begin later this week).  This feature will provide an API for
   admins to create sub-CAs for separate security domains and
   augment the existing API so that certificates requests can be
   directed to a particular sub-CA.
  
   This feature will be used in FreeIPA for issuing user or service
   certificates for particular purposes (that will be rejected when
   use for other purposes).
  
   Please review the document and provide feedback.
  
   http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs
  
   Feedback/suggestions for the REST API (that FreeIPA will use) and
   ACI considerations (e.g. is it appropriate to use the existing
   agent credential or should a separate credential or more
   fine-grained ACIs be used) are particularly encouraged.
  
   Cheers,
  
   Fraser
  
   Thanks for sharing the design! Couple initial comments:
  
   Creating sub-CAs
  
   Creation of sub-CAs at any time after the initial spawning of an
   CA instance is a requirement. Preferably, restart would not be
   needed, however, if needed, it must be able to be performed
   without manual intervention.
  
   I am all for having the operation in effect without requiring
   restart, especially given the change is in replicated tree. What
   do you mean by restart without manual operation? That Dogtag
   would restart itself when it detects that subCA would be added?
  
   Key generation and storage
  
   Are we referring to
   http://www.freeipa.org/page/V4/PKCS11_in_LDAP
   http://www.freeipa.org/page/V4/PKCS11_in_LDAP/Schema
   ? Contact people: Jan Cholasta, Petr Spacek
  
  
   ACI considerations
  
   Agent credential is used by FreeIPA web interface, all
   authorization is then done on python framework level. We can add
   more agents and then switch the used certificate, but I wonder how
   to use it in authorization decisions. Apache service will need to
   to have access to all these agents anyway.
   
   We really need to move to a separate service for agent access, the
   framework is supposed to not have any more power than the user that
   connects to it. By giving the framework direct access to
   credentials we fundamentally change the proposition and erode the
   security properties of the separation.
   
   We have discussed before a proxy process that pass in commands as
   they come from the framework but assumes agent identity only after
   checking how the framework authenticated to it (via GSSAPI).
   
   First we need to think how fine grained authorization we want to
   do.
   
   We need to associate a user to an agent credential via a group, so
   that we can assign the rights via roles.
   
   I think we will want to be able to for example say that user Foo
   can generate certificates in specified subCA. I am not sure it is
   a good way to go, it would also make such private key distribution
   on IPA replicas + renewal a challenge.
   
   I do not think we need to start with very fine grained permissions
   initially.
   
   Right now, we only have Virtual Operations concept to authorize
   different operations with Dogtag CA, but it does not distinguish
   between different CAs. We could add a new Virtual Operation for
   every subCA, but it looks clumsy. But the ACI-based mechanism and
   our permission system would still be the easiest way to go, IMHO,
   compared to utilizing PKI agents.
   
   We need to have a different agent certificate per role, and then in
   the proxy process associate the right agent certificate based on
   what the framework asks and internal checking that the user is
   indeed allowed to do so.
   
   The framework will select the 'role' to use based on the operation
   to be performed.
  
  I totally agree in principle but this will add significant complexity
  to replication and renewal.
 
 We already have this issue with DNSSEC, so I think we can solve it the
 same way (storing keys in LDAP encrypted with a master key).
 
  Each agent cert will need to be tracked by certmonger and renewed
  automatically. The basic framework for that is in place and IIRC
  fairly generalized so this should be relatively simple, but we've had
  a few bumps in the road to renewal.
 
 Alternatively I think we can avoid this by having the proxy process
 store the certs in LDAP (encrypted with the current main agent cert)
 and renew them by calling out to certmonger if the certs are close to
 expiration. We can make it simpler than it is now.
 
  What I think will be more challenging is dealing with distribution of
  additional agent

[Freeipa-devel] FreeIPA upstream guide - next steps

2014-10-13 Thread Martin Kosek 
Hello all,

Just FYI, based on the [Freeipa-users] What should we do with upstream guide?
thread I started doing actions on FreeIPA.org wiki side:

- Created http://www.freeipa.org/page/Upstream_User_Guide with the details
about the decisions that were made
- Updated http://www.freeipa.org/page/Documentation#User_Documentation with
links to downstream guides + direct links for reporting bugs
- Created https://git.fedorahosted.org/cgit/freeipa-docs.git/tree/DEPRECATION
- Given that I was in this work already, I created redirects for other
obsolete generated developer documentation:
  - http://www.freeipa.org/developer-docs/
  - http://www.freeipa.org/freeipa2-dev-doc/
  - http://www.freeipa.org/docs/master/

Updates or refinements welcome.

Thanks.

-- 
Martin Kosek mko...@redhat.com
Supervisor, Software Engineering - Identity Management Team
Red Hat Inc.

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

Re: [Freeipa-devel] [PATCH] 0159-0162 ID views in compat tree: ACIs, support for shell, gidNumber, and SSH keys

2014-10-13 Thread Petr Vobornik 

On 10.10.2014 17:56, Alexander Bokovoy wrote:

On Fri, 10 Oct 2014, Petr Vobornik wrote:

One more update for patch 0161, Petr noticed we need to call super
post_callback() too.



idoverrideuser_find callback causes internal error. I've attached new
version of the patch which fixes it. Basically it's this change:


If you are OK with it, then ACK for patches 160, 161-3, 162-1, 164 and
165.

I'm fine with your patch, copy/paste error, thanks for fixing it.




also ACK for 163.

patch 159 still needs review.

pushed to:

master:
* 63be2ee9f0296e1366c77258929c7ce2dad53154 Support overridding user 
shell in ID views
* ca42d3469a6f83376d33b08d7bb4b43c2e93d604 Allow user overrides to 
specify SSH public keys
* b50524b10c82ed7931a2e84dbb029e8909aa8f3f Allow user overrides to 
specify GID of the user
* 5ec23ccb5f1d21c6e6c56650c18d1b4296d59ac9 Allow override of gecos field 
in ID views
* 6637449ad2d8885f6df43b4098f09289c7405129 Update API version for ID 
views support
* 9fcc9a0163b7f485deae2fd000ae0ab554f9bb72 Require slapi-nis 0.54 or 
later for ID views support


ipa-4-1:
* 8a8d2e71f384bfa50477042cb8e82f14237caa7c Support overridding user 
shell in ID views
* ad6d019b4784853c59fb2a38c5de149b02640841 Allow user overrides to 
specify SSH public keys
* 240d93bd80a3fdc9f67640f74380eb74843c Allow user overrides to 
specify GID of the user
* aa0f5d35c5221e1d8ae270d354ff21d173b3194e Allow override of gecos field 
in ID views
* 79c0b31c72a8d8db676f3a621371983e5d9cdf53 Update API version for ID 
views support
* a4798c78372a66545d338b809afb45b5f9ada94d Require slapi-nis 0.54 or 
later for ID views support

--
Petr Vobornik

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

Re: [Freeipa-devel] [PATCH] 351 Support MS CA as the external CA in ipa-server-install and ipa-ca-install

2014-10-13 Thread Martin Kosek 
On 10/09/2014 08:44 AM, Martin Kosek wrote:
 On 10/08/2014 01:46 PM, Jan Cholasta wrote:
 Dne 8.10.2014 v 12:49 Martin Kosek napsal(a):
 On 10/08/2014 11:53 AM, Jan Cholasta wrote:
 Hi,

 the attached patch fixes https://fedorahosted.org/freeipa/ticket/4496.

 Note that this requires pki-core 10.2.0-3.

 Honza

 The approach looks OK, but I would like to be better in naming 
 documentation:

 +cert_group.add_option(--external-ca-type, dest=external_ca_type,
 +  type=choice, choices=(generic, ms),
 +  help=Type of the external CA)

 I would name the option either ad-cs or windows-server-ca, i.e. Active
 Directory Certificate Services or Windows Server CA. ms sounds too 
 generic
 to me in this context. When using trademarks we should be specific about 
 what
 do we mean.

 Microsoft docs refer to it as Microsoft Certificate Services or simply
 Certificate Services, so I went with ms-cs.
 
 Works for me. Just please update the man and refer to this type as Microsoft
 Certificate Services (MS CS) just in case MS CS alone does not ring a bell of
 a user.
 
 But that's just a minor issue, what is more concerning is that IPA 
 installation
 crashed with the signed CA certificate (this part worked smoothly btw):
 
 ...
   [17/27]: setting audit signing renewal to 2 years
   [18/27]: configuring certificate server to start on boot
   [19/27]: restarting certificate server
   [20/27]: requesting RA certificate from CA
   [error] IndexError: list index out of range
 Unexpected error - see /var/log/ipaserver-install.log for details:
 IndexError: list index out of range
 
 See
 https://mkosek.fedorapeople.org/ticket-4496.tgz
 
 for related logs.

Jan found the root cause for this failure, we have a bug logged:
https://bugzilla.redhat.com/show_bug.cgi?id=1151147

With related workaround specified in
https://bugzilla.redhat.com/show_bug.cgi?id=1129558#c11
I was able to install FreeIPA with MS Windows 2012 AD CA.

Thus, ACK, pushed to master, ipa-4-1.

Next steps with this ticket will be based on how Dogtag approach the reported 
bug.

Martin

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

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

2014-10-13 Thread Martin Kosek 
On 10/10/2014 05:43 PM, Nathaniel McCallum wrote:
 As a result of this ongoing conversation, I have opened two 389 bugs:
 
 1. Post Read - https://fedorahosted.org/389/ticket/47924
 2. UUID ACIs - https://fedorahosted.org/389/ticket/47925
 
 On Wed, 2014-10-08 at 17:46 -0400, Nathaniel McCallum wrote:
 The background of this email is this bug:
 https://fedorahosted.org/freeipa/ticket/4456

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

 There are two outstanding issues:

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

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

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

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

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

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

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

 To this:

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

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

Given the number of issues we have with this patch on the DS side, it is likely
we will need to go some simpler way for FreeIPA 4.1, in terms just of hiding
the option where appropriate.

Also, few comments to your current patch set (though the patches themselves
will probably not land in 4.1):

Patch 0001:
- while it may work (after DS fixes), it adds PostRead for all our commands,
not just otptoken-add. I would rather have some attribute like
read_dn_from_postread on LDAPObject which defaults to False to make sure
there is no regression or performance hit with other LDAP calls.
- Wider adoption of the PostRead call would be left for future, when we stop
doing post-execute LDAP read call and only rely on PostRead result.

Patch 0002:
- cn=IPA Token Unique IDs,cn=IPA UUID,cn=plugins,cn=config should be created
in LDAP update files only. Currently it will not be created on upgrades.

Martin

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

Re: [Freeipa-devel] [PATCH] 761 keytab manipulation permission management

2014-10-13 Thread Petr Vobornik 

On 8.10.2014 18:51, Petr Vobornik wrote:

On 1.10.2014 18:15, Petr Vobornik wrote:

Hello list,

Patch for: https://fedorahosted.org/freeipa/ticket/4419



New revisions of 761 and 763 with updated API and ACIs:

ipa host-allow-operation HOSTNAME retrieve-keytab --users=STR --groups STR
   ipa host-disallow-operation HOSTNAME retrieve-keytab --users=STR
--groups STR
   ipa host-allow-operation HOSTNAME create-keytab --users=STR --groups STR
   ipa host-disallow-operation HOSTNAME create-keytab --users=STR
--groups STR

   ipa service-allow-operation PRINCIPAL retrieve-keytab --users=STR
--groups STR
   ipa service-disallow-operation PRINCIPAL retrieve-keytab --users=STR
--groups STR
   ipa service-allow-operation PRINCIPAL create-keytab --users=STR
--groups STR
   ipa service-disallow-operation PRINCIPAL create-keytab --users=STR
--groups STR

ACIs are targeted to specific operations by including subtypes.



patch #761 rebased because of VERSION bump
--
Petr Vobornik
From 224f09d92b64d1658a13b760a85bc562729af8ed Mon Sep 17 00:00:00 2001
From: Petr Vobornik pvobo...@redhat.com
Date: Thu, 2 Oct 2014 16:57:08 +0200
Subject: [PATCH] keytab manipulation permission management

Adds new API:
  ipa host-allow-operation HOSTNAME retrieve-keytab --users=STR --groups STR
  ipa host-disallow-operation HOSTNAME retrieve-keytab --users=STR --groups STR
  ipa host-allow-operation HOSTNAME create-keytab --users=STR --groups STR
  ipa host-disallow-operation HOSTNAME create-keytab --users=STR --groups STR

  ipa service-allow-operation PRINCIPAL retrieve-keytab --users=STR --groups STR
  ipa service-disallow-operation PRINCIPAL retrieve-keytab --users=STR --groups STR
  ipa service-allow-operation PRINCIPAL create-keytab --users=STR --groups STR
  ipa service-disallow-operation PRINCIPAL create-keytab --users=STR --groups STR

these methods add or remove user or group DNs in `ipaallowedtoperform` attr with
`read_keys` and `write_keys` subtypes.

service|host-mod|show outputs these attrs as:

  Users allowed to retrieve keytab: user1
  Groups allowed to retrieve keytab: group1
  Users allowed to create keytab: user1
  Groups allowed to create keytab: group1

Adding of object class is implemented as a reusable method since this code is
used on many places and most likely will be also used in new features. Older
code may be refactored later.

https://fedorahosted.org/freeipa/ticket/4419
---
 ACI.txt|   4 ++
 API.txt|  52 +++
 VERSION|   4 +-
 ipalib/plugins/baseldap.py |  17 ++
 ipalib/plugins/host.py |  51 --
 ipalib/plugins/service.py  | 127 +++--
 6 files changed, 244 insertions(+), 11 deletions(-)

diff --git a/ACI.txt b/ACI.txt
index bc031ff1f24b9e9f08fe9ba78e5a262162f32cef..6fc88233e340d6eabe4ad819176e3cfa98d8c9ce 100644
--- a/ACI.txt
+++ b/ACI.txt
@@ -95,6 +95,8 @@ aci: (targetattr = userpassword)(targetfilter = (objectclass=ipahost))(versi
 dn: cn=computers,cn=accounts,dc=ipa,dc=example
 aci: (targetattr = krblastpwdchange || krbprincipalkey)(targetfilter = (objectclass=ipahost))(version 3.0;acl permission:System: Manage Host Keytab;allow (write) groupdn = ldap:///cn=System: Manage Host Keytab,cn=permissions,cn=pbac,dc=ipa,dc=example;)
 dn: cn=computers,cn=accounts,dc=ipa,dc=example
+aci: (targetattr = createtimestamp || entryusn || ipaallowedtoperform;read_keys || ipaallowedtoperform;write_keys || modifytimestamp || objectclass)(targetfilter = (objectclass=ipahost))(version 3.0;acl permission:System: Manage Host Keytab Permissions;allow (compare,read,search,write) groupdn = ldap:///cn=System: Manage Host Keytab Permissions,cn=permissions,cn=pbac,dc=ipa,dc=example;)
+dn: cn=computers,cn=accounts,dc=ipa,dc=example
 aci: (targetattr = ipasshpubkey)(targetfilter = (objectclass=ipahost))(version 3.0;acl permission:System: Manage Host SSH Public Keys;allow (write) groupdn = ldap:///cn=System: Manage Host SSH Public Keys,cn=permissions,cn=pbac,dc=ipa,dc=example;)
 dn: cn=computers,cn=accounts,dc=ipa,dc=example
 aci: (targetattr = description || ipaassignedidview || l || macaddress || nshardwareplatform || nshostlocation || nsosversion || userclass)(targetfilter = (objectclass=ipahost))(version 3.0;acl permission:System: Modify Hosts;allow (write) groupdn = ldap:///cn=System: Modify Hosts,cn=permissions,cn=pbac,dc=ipa,dc=example;)
@@ -193,6 +195,8 @@ aci: (targetfilter = (objectclass=ipaservice))(version 3.0;acl permission:Sys
 dn: cn=services,cn=accounts,dc=ipa,dc=example
 aci: (targetattr = krblastpwdchange || krbprincipalkey)(targetfilter = (objectclass=ipaservice))(version 3.0;acl permission:System: Manage Service Keytab;allow (write) groupdn = ldap:///cn=System: Manage Service Keytab,cn=permissions,cn=pbac,dc=ipa,dc=example;)
 dn: cn=services,cn=accounts,dc=ipa,dc=example
+aci: (targetattr = createtimestamp || entryusn || ipaallowedtoperform;read_keys ||

[Freeipa-devel] Thesis - Gnome Keyring Key Storage in Vault/KRA

2014-10-13 Thread Martin Kosek 
Hello all,

Last week me, Jakub and Stef discussed a design for a candidate for a
FreeIPAGnome keyring related thesis:

https://thesis-managementsystem.rhcloud.com/topic/show/219/gnome-keyring-storage-in-freeipa

Apparently, there was a misunderstanding when crafting the topic proposal, it
is not about storing Gnome Keyring *secrets* in FreeIPA tree, but only about
storing a *master key*/AUTHTOK in FreeIPA so that keyring can be unlocked by
SSSD on user log on even in non-password authentication case (like SSO).

With SSO, Gnome keyring cannot grab the long term secret to unlock the keyring,
the keyring also cannot re-encrypt itself when the long term password changes
on the server (this is no problem locally as Gnome keyring is hooked to PAM
password change module). Thus, there is the idea to store the master
key/AUTHTOK centrally on the server.

Given the sensitivity of the password, it would be best to store it in the
upcoming FreeIPA Password Vault/KRA:

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

However, here comes the problem with how to authorize the operation on SSSD
level. To make it working, SSSD, host/client.example@example.com would need
to be able to retrieve and decipher a key from (any) user's Vault, which is
probably not what we want to allow. We may add S4U2Proxy rules so that
host/client.example@example.com can get
vault/server.example@example.com for the client, but then SSSD could grab
any user's secret when he logs in.

Are there any ideas how to overcome this issue? Otherwise, it seems that the
Vault idea is not the right way. Maybe centralizing access to Gnome keyring is
not a good idea at all, we will see.

Thank you.

-- 
Martin Kosek mko...@redhat.com
Supervisor, Software Engineering - Identity Management Team
Red Hat Inc.

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

Re: [Freeipa-devel] Thesis - Gnome Keyring Key Storage in Vault/KRA

2014-10-13 Thread Sumit Bose 
On Mon, Oct 13, 2014 at 01:24:10PM +0200, Martin Kosek wrote:
 Hello all,
 
 Last week me, Jakub and Stef discussed a design for a candidate for a
 FreeIPAGnome keyring related thesis:
 
 https://thesis-managementsystem.rhcloud.com/topic/show/219/gnome-keyring-storage-in-freeipa
 
 Apparently, there was a misunderstanding when crafting the topic proposal, it
 is not about storing Gnome Keyring *secrets* in FreeIPA tree, but only about
 storing a *master key*/AUTHTOK in FreeIPA so that keyring can be unlocked by
 SSSD on user log on even in non-password authentication case (like SSO).
 
 With SSO, Gnome keyring cannot grab the long term secret to unlock the 
 keyring,
 the keyring also cannot re-encrypt itself when the long term password changes
 on the server (this is no problem locally as Gnome keyring is hooked to PAM
 password change module). Thus, there is the idea to store the master
 key/AUTHTOK centrally on the server.
 
 Given the sensitivity of the password, it would be best to store it in the
 upcoming FreeIPA Password Vault/KRA:
 
 http://www.freeipa.org/page/V4/Password_Vault
 
 However, here comes the problem with how to authorize the operation on SSSD
 level. To make it working, SSSD, host/client.example@example.com would 
 need
 to be able to retrieve and decipher a key from (any) user's Vault, which is
 probably not what we want to allow. We may add S4U2Proxy rules so that
 host/client.example@example.com can get
 vault/server.example@example.com for the client, but then SSSD could grab
 any user's secret when he logs in.
 
 Are there any ideas how to overcome this issue? Otherwise, it seems that the
 Vault idea is not the right way. Maybe centralizing access to Gnome keyring is
 not a good idea at all, we will see.

What about using a new authorization data type for the key. Then only
the KDCs on the IPA servers need access to the key. The authorization
data can be added to the service ticket of the host the user logs into.
Since SSSD does ticket validation by default this service ticket would
be available for password based logins as well.

bye,
Sumit

 
 Thank you.
 
 -- 
 Martin Kosek mko...@redhat.com
 Supervisor, Software Engineering - Identity Management Team
 Red Hat Inc.
 
 ___
 Freeipa-devel mailing list
 Freeipa-devel@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-devel

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

[Freeipa-devel] [PATCHES] 354-356 Check LDAP instead of local configuration to see if IPA CA is enabled

2014-10-13 Thread Jan Cholasta 

Hi,

the attached patches fix https://fedorahosted.org/freeipa/ticket/4621.

Honza

--
Jan Cholasta
From c4f65820ebf2936139c010d143a1f6a4017d6b58 Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Mon, 13 Oct 2014 14:10:13 +0200
Subject: [PATCH 1/3] Do not create ipa-pki-proxy.conf if CA is not configured
 in ipa-upgradeconfig

This fixes upgrade from CA-less to CA-full after IPA upgrade.

https://fedorahosted.org/freeipa/ticket/4621
---
 install/tools/ipa-upgradeconfig | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig
index ba4ac93..dd607f3 100644
--- a/install/tools/ipa-upgradeconfig
+++ b/install/tools/ipa-upgradeconfig
@@ -1161,7 +1161,11 @@ def main():
 
 upgrade(sub_dict, paths.HTTPD_IPA_CONF, ipautil.SHARE_DIR + ipa.conf)
 upgrade(sub_dict, paths.HTTPD_IPA_REWRITE_CONF, ipautil.SHARE_DIR + ipa-rewrite.conf)
-upgrade(sub_dict, paths.HTTPD_IPA_PKI_PROXY_CONF, ipautil.SHARE_DIR + ipa-pki-proxy.conf, add=True)
+if ca.is_configured():
+upgrade(sub_dict, paths.HTTPD_IPA_PKI_PROXY_CONF, ipautil.SHARE_DIR + ipa-pki-proxy.conf, add=True)
+else:
+if ipautil.file_exists(paths.HTTPD_IPA_PKI_PROXY_CONF):
+os.remove(paths.HTTPD_IPA_PKI_PROXY_CONF)
 if subject_base:
 upgrade(
 sub_dict,
-- 
1.9.3

From f9a64d83a00d1d2b15a1643bb4547893155a4d6f Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Mon, 13 Oct 2014 14:17:19 +0200
Subject: [PATCH 2/3] Do not fix trust flags in the DS NSS DB in
 ipa-upgradeconfig

It is necessary to fix trust flags only in the HTTP NSS DB, as it is used as
a source in the upload_cacrt update plugin.

https://fedorahosted.org/freeipa/ticket/4621
---
 install/tools/ipa-upgradeconfig | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig
index dd607f3..63af697 100644
--- a/install/tools/ipa-upgradeconfig
+++ b/install/tools/ipa-upgradeconfig
@@ -1069,8 +1069,8 @@ def remove_ds_ra_cert(subject_base):
 sysupgrade.set_upgrade_state('ds', 'remove_ra_cert', True)
 
 
-def fix_trust_flags(service, **kwargs):
-root_logger.info('[Fixing trust_flags in %s NSS database]' % service)
+def fix_trust_flags():
+root_logger.info('[Fixing trust flags in %s]' % paths.HTTPD_ALIAS_DIR)
 
 if not api.env.enable_ra:
 root_logger.info(CA is not enabled)
@@ -1080,13 +1080,13 @@ def fix_trust_flags(service, **kwargs):
 root_logger.info(Trust flags already fixed)
 return
 
-db = certs.CertDB(api.env.realm, **kwargs)
+db = certs.CertDB(api.env.realm)
 nickname = certdb.get_ca_nickname(api.env.realm)
 cert = db.get_cert_from_db(nickname)
 if cert:
 db.trust_root_cert(nickname, 'CT,C,C')
 
-sysupgrade.set_upgrade_state(service, 'fix_trust_flags', True)
+sysupgrade.set_upgrade_state('http', 'fix_trust_flags', True)
 
 
 def main():
@@ -1188,7 +1188,7 @@ def main():
 http.change_mod_nss_port_from_http()
 
 http.stop()
-fix_trust_flags('http')
+fix_trust_flags()
 http.start()
 
 ds = dsinstance.DsInstance()
@@ -1197,7 +1197,6 @@ def main():
 ds.stop(ds_serverid)
 fix_schema_file_syntax()
 remove_ds_ra_cert(subject_base)
-fix_trust_flags('ds', nssdir=ds_dirname)
 ds.start(ds_serverid)
 
 uninstall_selfsign(ds, http)
-- 
1.9.3

From bd6a94fa5efb7ff3635ffcfb3c7e9165bcf2cebb Mon Sep 17 00:00:00 2001
From: Jan Cholasta jchol...@redhat.com
Date: Mon, 13 Oct 2014 14:30:15 +0200
Subject: [PATCH 3/3] Check LDAP instead of local configuration to see if IPA
 CA is enabled

The check is done using a new hidden command ca_is_enabled.

https://fedorahosted.org/freeipa/ticket/4621
---
 API.txt |  6 +
 VERSION |  4 +--
 install/tools/ipa-ca-install|  6 ++---
 install/tools/ipa-replica-install   |  3 ++-
 install/tools/ipa-server-install|  6 +++--
 install/tools/ipa-upgradeconfig | 27 +---
 ipa-client/ipa-install/ipa-client-install   | 27 
 ipa-client/ipaclient/ipa_certupdate.py  | 20 +--
 ipalib/plugins/cert.py  | 38 ++---
 ipalib/plugins/host.py  |  6 ++---
 ipalib/plugins/service.py   |  4 +--
 ipalib/x509.py  |  2 +-
 ipaserver/install/httpinstance.py   | 12 ++---
 ipaserver/install/ipa_replica_prepare.py| 15 ++--
 ipaserver/install/ipa_server_certinstall.py | 20 ---
 ipaserver/install/plugins/upload_cacrt.py   |  7 +++---
 16 files changed, 141 insertions(+), 62 deletions(-)

diff --git a/API.txt b/API.txt
index 1af7850..df924c0 100644
--- a/API.txt
+++ b/API.txt
@@ -450,6 +450,12 @@ arg: Any('methods*')
 option:

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

2014-10-13 Thread Nathaniel McCallum 
On Mon, 2014-10-13 at 12:39 +0200, Martin Kosek wrote:
 On 10/10/2014 05:43 PM, Nathaniel McCallum wrote:
  As a result of this ongoing conversation, I have opened two 389 bugs:
  
  1. Post Read - https://fedorahosted.org/389/ticket/47924
  2. UUID ACIs - https://fedorahosted.org/389/ticket/47925
  
  On Wed, 2014-10-08 at 17:46 -0400, Nathaniel McCallum wrote:
  The background of this email is this bug:
  https://fedorahosted.org/freeipa/ticket/4456
 
  Attached are two patches which solve this issue for admin users (not
  very helpful, I know). They depend on this fix in 389:
  https://fedorahosted.org/389/ticket/47920
 
  There are two outstanding issues:
 
  1. 389 does not send the post read control for normal users. The
  operation itself succeeds, but no control is sent.
 
  The relevant sections from the log are attached. 389 is denying access
  to the following attributes (* = valid, ! = invalid):
  ! objectClass
  ! ipatokenOTPalgorithm
  ! ipatokenOTPdigits
  * ipatokenOTPkey
  * ipatokenHOTPcounter
  ! ipatokenOwner
  ! managedBy
  ! ipatokenUniqueID
 
  The ACIs allowing access to most of these attributes are here:
  https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90
 
  Note that I am able to query the entry just fine (including all the
  above invalidly restricted attributes). Hence, I know the ACIs are
  working just fine.
 
  Part of the strange thing is that in the post read control request, I
  haven't indicated that I want *any* attributes returned (i.e. I want
  just the DN). So I'm not sure why it is querying all the attributes. I
  would suspect that the proper behavior would be to only check the ACIs
  on attributes that will actually be returned.
 
  2. The second patch (0002) modifies the ACI for normal user token
  addition from this:
 
  aci: (target = ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX;)(targetfilter
  = (objectClass=ipaToken))(version 3.0; acl Users can create
  self-managed tokens; allow (add) userattr = ipatokenOwner#SELFDN and
  userattr = managedBy#SELFDN;)
 
  To this:
 
  aci: (target = ldap:///ipatokenuniqueid=autogenerate,cn=otp,
  $SUFFIX)(targetfilter = (objectClass=ipaToken))(version 3.0; acl
  Users can create self-managed tokens; allow (add) userattr =
  ipatokenOwner#SELFDN and userattr = managedBy#SELFDN;)
 
  The idea is to allow users to create tokens which will be expanded by
  the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs are
  checked. Since the expanded UUID no longer matches the ACI, the addition
  is denied. Is this truly the correct behavior? I would think that the
  ACIs would be checked before the UUID plugin, not after.
 
 Given the number of issues we have with this patch on the DS side, it is 
 likely
 we will need to go some simpler way for FreeIPA 4.1, in terms just of hiding
 the option where appropriate.

We have solved the first DS issue via a sensible workaround. Attached
are two new patches. These take into account your feedback below and
incorporate the aforementioned workaround.

The only thing these patches lack is the tightening of the ACI (problem
#2 in the first email). Merging these patches I believe provides
benefits over our current code, even though we don't get the final
benefit of forcing normal users to use autogeneration.

If we test/merge these now, then when the second DS problem is solved,
we can simply update the ACI independently via a trivial second patch
(s/\*/autogenerate/).

 Also, few comments to your current patch set (though the patches themselves
 will probably not land in 4.1):
 
 Patch 0001:
 - while it may work (after DS fixes), it adds PostRead for all our commands,
 not just otptoken-add. I would rather have some attribute like
 read_dn_from_postread on LDAPObject which defaults to False to make sure
 there is no regression or performance hit with other LDAP calls.

In the new code, we actually get a performance gain as the manual post
read is eliminated if the post read control is successful. Only one
issue can arise, which is when the post read control evaluates ACIs in a
different context than a normal manual read. This problem is well known
and is trivial to fix (s/USERDN/SELFDN/).

 - Wider adoption of the PostRead call would be left for future, when we stop
 doing post-execute LDAP read call and only rely on PostRead result.

This is already integrated.

 Patch 0002:
 - cn=IPA Token Unique IDs,cn=IPA UUID,cn=plugins,cn=config should be created
 in LDAP update files only. Currently it will not be created on upgrades.

Fixed.

I believe the following patches are ready for review. Should we review
on this thread? Or should I create separate threads for the patches?

Nathaniel
From ae10d13b3f5e3f9635463d38f72d8a0f06f6ffbe Mon Sep 17 00:00:00 2001
From: Nathaniel McCallum npmccal...@redhat.com
Date: Wed, 8 Oct 2014 14:39:18 -0400
Subject: [PATCH 1/2] Use post read control on add operations

By adding the post read control, we gain two

Re: [Freeipa-devel] Thesis - Gnome Keyring Key Storage in Vault/KRA

2014-10-13 Thread Simo Sorce 
On Mon, 13 Oct 2014 13:24:10 +0200
Martin Kosek mko...@redhat.com wrote:

 Hello all,
 
 Last week me, Jakub and Stef discussed a design for a candidate for a
 FreeIPAGnome keyring related thesis:
 
 https://thesis-managementsystem.rhcloud.com/topic/show/219/gnome-keyring-storage-in-freeipa
 
 Apparently, there was a misunderstanding when crafting the topic
 proposal, it is not about storing Gnome Keyring *secrets* in FreeIPA
 tree, but only about storing a *master key*/AUTHTOK in FreeIPA so
 that keyring can be unlocked by SSSD on user log on even in
 non-password authentication case (like SSO).
 
 With SSO, Gnome keyring cannot grab the long term secret to unlock
 the keyring, the keyring also cannot re-encrypt itself when the long
 term password changes on the server (this is no problem locally as
 Gnome keyring is hooked to PAM password change module). Thus, there
 is the idea to store the master key/AUTHTOK centrally on the server.
 
 Given the sensitivity of the password, it would be best to store it
 in the upcoming FreeIPA Password Vault/KRA:
 
 http://www.freeipa.org/page/V4/Password_Vault
 
 However, here comes the problem with how to authorize the operation
 on SSSD level. To make it working, SSSD,
 host/client.example@example.com would need to be able to retrieve
 and decipher a key from (any) user's Vault, which is probably not
 what we want to allow. We may add S4U2Proxy rules so that
 host/client.example@example.com can get
 vault/server.example@example.com for the client, but then SSSD
 could grab any user's secret when he logs in.
 
 Are there any ideas how to overcome this issue? Otherwise, it seems
 that the Vault idea is not the right way. Maybe centralizing access
 to Gnome keyring is not a good idea at all, we will see.

SSSD has access to the user credentials at authentication, that's what
it should use to retrieve the user's master key.

Neither using its host key nor s4u2proxy is necessary (nor advisable).

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] Thesis - Gnome Keyring Key Storage in Vault/KRA

2014-10-13 Thread Simo Sorce 
On Mon, 13 Oct 2014 14:15:10 +0200
Sumit Bose sb...@redhat.com wrote:

 What about using a new authorization data type for the key. Then only
 the KDCs on the IPA servers need access to the key. The authorization
 data can be added to the service ticket of the host the user logs
 into. Since SSSD does ticket validation by default this service
 ticket would be available for password based logins as well.

The KDC has no way to know what is the host the user is logging on, so
it would end up sending this data to any host the user logs into
(think SSH).

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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