Re: [Freeipa-devel] [Freeipa-interest] Announcing FreeIPA 4.1.2 - NEED HELP WITH 2FA/OTP!!!
Hello,
WE NEED HELP!
The biggest and the most interesting feature of FreeIPA 4.1.2 is support for
the two factor authentication using HOTP/TOTP compatible software tokens like
FreeOTP (open source compatible alternative to Google Authenticator) and
hardware tokens like Yubikeys. This feature allows Kerberos and LDAP clients of
a FreeIPA server to authenticate using the normal account password as the first
factor and an OTP token as a second factor. For those environments where a 2FA
solution is already in place, FreeIPA can act as a proxy via RADIUS. More about
this feature can be read here.
http://www.freeipa.org/page/V4/OTP
If you want to see this feature in downstream distros sooner rather than later
we need your help!
Please give it a try and provide feedback. We really, really need it!
Thank you,
FreeIPA development team
- Original Message -
From: Petr Vobornik pvobo...@redhat.com
To: freeipa-devel freeipa-devel@redhat.com, freeipa-users
freeipa-us...@redhat.com, freeipa-inter...@redhat.com
Sent: Thursday, November 27, 2014 11:59:35 AM
Subject: [Freeipa-interest] Announcing FreeIPA 4.1.2
The FreeIPA team would like to announce FreeIPA v4.1.2 security release!
It can be downloaded from http://www.freeipa.org/page/Downloads. The
builds will be available for Fedora 21. Builds for Fedora 20 are
available in the official COPR repository
[https://copr.fedoraproject.org/coprs/mkosek/freeipa/].
== Highlights in 4.1.2 ==
=== Bug fixes ===
* CVE-2014-7850: ensure that user input is properly escaped to prevent
XSS attacks [https://fedorahosted.org/freeipa/ticket/4742]
[http://www.freeipa.org/page/CVE-2014-7850]
* harden mod_nss config on update to use TLSv1.0, TLSv1.1, TLSv1.2
* fixed getkeytab operation
[https://fedorahosted.org/freeipa/ticket/4718]
[https://fedorahosted.org/freeipa/ticket/4728]
* backup and restore fixes related to certificates restore and SELinux
context
* static code analysis fixes
* various small fixes
== Upgrading ==
An IPA server can be upgraded simply by installing updated rpms. The
server does not need to be shut down in advance.
Please note that if you are doing the upgrade in special environment
(e.g. FedUp) which does not allow running the LDAP server during upgrade
process, upgrade scripts need to be run manually after the first boot:
# ipa-ldap-updater --upgrade
# ipa-upgradeconfig
Also note that the performance improvements require an extended set of
indexes to be configured. RPM update for an IPA server with a excessive
number of users may require several minutes to finish.
If you have multiple servers you may upgrade them one at a time. It is
expected that all servers will be upgraded in a relatively short period
(days or weeks, not months). They should be able to co-exist peacefully
but new features will not be available on old servers and enrolling a
new client against an old server will result in the SSH keys not being
uploaded.
Downgrading a server once upgraded is not supported.
Upgrading from 3.3.0 and later versions is supported. Upgrading from
previous versions is not supported and has not been tested.
An enrolled client does not need the new packages installed unless you
want to re-enroll it. SSH keys for already installed clients are not
uploaded, you will have to re-enroll the client or manually upload the keys.
== Feedback ==
Please provide comments, bugs and other feedback via the freeipa-users
mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or
#freeipa channel on Freenode.
== Detailed Changelog since 4.1.1 ==
=== Alexander Bokovoy (2) ===
* Update slapi-nis dependency to pull 0.54.1
* AD trust: improve trust validation
=== David Kupka (6) ===
* Remove unneeded internal methods. Move code to public methods.
* Remove service file even if it isn't link.
* Produce better error in group-add command.
* Fix --{user,group}-ignore-attribute in migration plugin.
* ipa-restore: Check if directory is provided + better errors.
* Fix error message for nonexistent members and add tests.
=== Gabe Alford (1) ===
* ipa-server-install Directory Manager help incorrect
=== Jan Cholasta (15) ===
* Fix CA certificate backup and restore
* Update Requires on pki-ca to 10.2.1-0.1
* Fix wrong expiration date on renewed IPA CA certificates
* Restore file extended attributes and SELinux context in ipa-restore
* Use correct service name in cainstance.backup_config
* Stop tracking certificates before restoring them in ipa-restore
* Remove redefinition of LOG from ipa-otp-lasttoken
* Unload P11_Helper object's library when it is finalized in ipap11helper
* Fix Kerberos error handling in ipa-sam
* Fix unchecked return value in ipa-kdb
* Fix unchecked return values in ipa-winsync
* Fix unchecked return value in ipa-join
* Fix unchecked return value in krb5 common utils
* Fix memory leak in GetKeytabControl asn1 code
* Add TLS 1.2 to the protocol list in mod_nss config
=== Martin Bašti (12) ===
* Fix: DNS
[Freeipa-devel] OpenLMI integration
Hello, As some might have heard there are plans to refactor our approach to how IPA server instances are installed and managed. Right now the procedures for server installation imply administrator presence and interaction. In the automated environments that does not work quite well. So we did some evaluation and decided that it would make sense to make IPA be capable of managing its on cluster as well as to be able to deploy IPA from an external system using tools of your preference without imposing too much knowledge of IPA internals on these tools. OpenLMI approach seems like the best available so we reached out to OpenLMI project to get some guidance. The following page is the summary of the architecture we managed to work out with OpenLMI guys. This is a high level architecture. The goal of the page is to define the parts of the solution and summarize the scope of effort. The plan is to handle it in FreeIPA 4.2 so whoever is going to be in charge of the implementation of different componants would probably create specific pages or sections for those components and fill the rest of the template per component. Comments and suggestions welcome but I would suggest we refrain from diving into design and implementation until somone actually picks up this feature in several months. Right now let us focus on making sure that: a) Approach makes sense b) Architecture is sound c) Components and interfaces are not missing d) All core elements of the feature outlined Link - http://www.freeipa.org/page/V4/IPA_Server_Management_via_OpenLMI -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] user certificates
On 06/11/2014 09:18 PM, Fraser Tweedale wrote: On Wed, Jun 11, 2014 at 08:55:20AM -0400, John Dennis wrote: On 06/11/2014 04:02 AM, Fraser Tweedale wrote: There are other use cases for user certificates, e.g. client authentication for HTTP or other network services. Perhaps you know of others - in which case let us know. 802.11 wireless authentication using EAP-TLS A common discussion on the RADIUS mailing lists is the desire to deploy using EAP-TLS but the difficulty of provisioning user certs is always the stumbling block. Thanks John, I've created http://www.freeipa.org/page/User_certificate_use_cases to collect and discuss these use cases. I think it is important to differ short term and long term certificates for users. The long term certificates are used for authentication and signing. They are put on devices like smart cards. They need to be associated with the user in the back end. They can be revoked. The short lived certificates do not need to be recorded on the server side. They are just issued and since they do not live long there is no need to record them in the back end or to try to revoke them. This IMO a crucial difference. For now we focus on the long living certificates for hosts, services, devices and short lived certificates for any identity. IMO long lived certs for users is a separate big use case that we currently should set aside and solve after we solve the other use cases. Fraser -- John ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Expired passwords cannot be changed via LDAP
On 06/09/2014 09:01 AM, Simo Sorce wrote: From: Martin Kosek mko...@redhat.com Given all sort of issues we get, I am thinking we should just revert it unless there is a quick fix available. Instead of reverting I am thinking we may want to make this optional by adding a configuration parameter that defaults to False for now. Once we can manage better the password change we can turn it on by deault, in the meanwhile admins can choose by themselves the lesser evil. Thoughts? Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I am also concerned about the OTP flows with this change. IMO we might not be ready for this change one way or another. Backing out or adding a default switch turning the feature off works for me. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Expired passwords cannot be changed via LDAP
On 06/09/2014 10:03 AM, Nathaniel McCallum wrote: On Mon, 2014-06-09 at 09:01 -0400, Simo Sorce wrote: From: Martin Kosek mko...@redhat.com Given all sort of issues we get, I am thinking we should just revert it unless there is a quick fix available. Instead of reverting I am thinking we may want to make this optional by adding a configuration parameter that defaults to False for now. Once we can manage better the password change we can turn it on by deault, in the meanwhile admins can choose by themselves the lesser evil. Thoughts? I'm not a fan of introducing a new configuration parameter for a temporary workaround. My preference is to revert it and have a small project for the next release which handles all the non-authenticated corner cases. This would include: * Expired passwords * Password changes * Token syncing * Unauthenticated RPCs (rpcserver.py rework) * others? I think there is some value to be gained by thinking about these problems as a whole and devising a set of consistent mechanisms for them. Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel +1 -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Move replication topology to the shared tree
On 06/06/2014 09:03 AM, Simo Sorce wrote: On Fri, 2014-06-06 at 06:58 -0400, James wrote: On Mon, Jun 2, 2014 at 4:46 AM, Ludwig Krispenz lkris...@redhat.com wrote: Ticket 4302 is a request for an enhancement: Move replication topology to the shared tree One comment to add: It would be particularly useful if the interface used to set the topology is something sane that a single host can use to set its peers. Eg: host1$ ipa-topology-set-peers host2 host2$ ipa-topology-set-peers host3 host3$ ipa-topology-set-peers host4 host4$ ipa-topology-set-peers host1 # redundant, but okay... This way config management could define topologies in terms of algorithms. Eg: Ring topology: Order hostnames alphabetically. Peer with host name index of self + 1 (Example shown above) Star topology: Peer with every other host in list Pick two topology: Peer with each subsequent hosts in ordered list... And so on... If running the command changes the topology again, then that's great because changing the algorithm would re-arrange the graph :) Hope this made sense. Oh it does! But I am dreaming even bigger, my aim is to end up (in the long run) with something like: ipa topology change --stellar host1 host2 host3 host4 host5 causes topology for those 5 servers only (ignores any other connection) to become: host2 | host3 - host1 - host5 | host4 So any agreement between host1 and 2,3,4,5 get wiped and replaced with the stellar topology. (agreements between 1,2,3,4,5 and 6,7,8,9 are not affected in any way and stay). And later on you'd be able to say ipa topology change --circular host1 host2 host3 host4 and you get: host1 - host2 | | host4 - host3 Note that if you previously did the stellar thing and you only have these 5 servers the actual complete topology ends up being like this: host5 | host1 - host2 | | host4 - host3 As the agreement between host1 and host5 is not touched by the second command. But this is in the far future IMO, we'll probably start by only implementing: ipa topology set-peering host1 host2 and ipa topology break-peering host3 host4 Ie creating and breaking segments in the topology tree only between pairs and storing/deleting the segment object in the shared tree. The reason is that the topology plugin will allow or disallow changes based on whether you are breaking the graph, and it is much simpler to do that if you change one object at a time. To do the nifty stuff above we'd need some staging area where we describe all the changes and then have a commit type change that would cause the topology plugin to do all the calculations and move stuff around inside at once (or refuse the commit if the change as a whole breaks the graph). HTH, Simo. I was thinking about the commit and staging too. I think this approach will be beneficial for the rebuild from existing non replicated agreements use case too. The logic for the use case that I described in other branch of this discussion will be: - Collect all info by contacting all the servers. - Save in staging - Analyze that topology makes sense and graph is not broken (error out if it is) - Start transaction - Put the data into the replicated tree - Stop transaction - Start replicating -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Reorganization of Web UI navigation items
On 06/04/2014 04:10 PM, Simo Sorce wrote: On Wed, 2014-06-04 at 20:52 +0200, Martin Kosek wrote: On 06/04/2014 05:35 PM, Simo Sorce wrote: On Wed, 2014-06-04 at 08:44 +0200, Martin Kosek wrote: On 06/04/2014 08:34 AM, Martin Kosek wrote: ... Users - Users - Groups - SUDO Hosts - Hosts - Host groups - Services - Netgroups - Automount Authentication - OTP Tokens - Password Policy - Kerberos Ticket Policy Policy - HBAC - SELinux User Maps - Automember Alternatively, we could rename Policy to Authorization as both HBAC and SELinux is about authorizing what an authenticated user can do. We would just need to move Automember to different place, though this one is difficult - it relates both to Users and Hosts, just like Netgroup. I do not see the need to do Policy - Authorization but Automember is in the wrong place imo. The first tab should be Users - Accounts and include automember in it as automember is about groupings ? Actually I would merge the current Users and Hosts tabs into 'Accounts' (or maybe 'Identities' ?) and add Automember. Simo. Automember is about grouping both users and hosts. I put it under Policy originally as it basically is a policy, when are certain users/hosts automember'ed. I would personally not merge Users and Hosts top level menus to one top level menu as that would spoil the whole reason why this effort is done, i.e. have at most 7 items in the second level bar to make things clearer. To me, it seemed a good idea to split Users and Hosts to achieve the target as it separates well the intent what one wants to do. Now we have it all under Identity (including DNS and Realm Domains) which is messy. Unfortunately some of your groupings make little sense to me: - why is SUDO under Users ?? It's a security policy and those policies are equally related to users, groups and hosts. - why policies are under authentication ? Both password policies and Kerberos Ticket policies have nothing to do with the authentication part, but with changing password and with which features are allowed on tickets. - why automember is in Policy ? It is just autoconfiguration it doesn't enforce any policy on its own But I am pretty open to counter-proposals which keeps the UX requirement of 7 second level items. Martin This is how it makes sense to me as a logical grouping: Accounts/Identity (7): - Users - Groups - Hosts - Host Groups - Netgroups - Services - Automember ^ These are all identity or identity-grouping related objects/actions +1 Policies (6): - Sudo - HBAC - SELinux User Maps - OTP Tokens (*) - Password Policies - Kerberos ticket Policies ^ These are all Security Policies an admin cares about +1, with the note, i.e. OTP does not belong there Directory (6): - Permissions - Privileges - Roles - Delegation NOTE: the 4 above can be merged into a single 'Authorization' entry perhaps May be it should be and Administration tab, I do not like the title. I understand where the directory comes from but this is IMo not intuitive for someone who does not know what is under the hood. - Replication Topology - Views (future) ^ Everything that deals with direct LDAP access/view I think views do not belong here. They belong in the same place where the trusts are. Network Services (4): - Automount - DNS - CA - Vault (future) ^ All the additional network services or configuration of network related services +1 Configuration (3): - Trusts - ID Ranges - Realm Domains - Global ^ Anything that does not fit the above categories. +1 Docs: - whatever :) (*) The only doubt I have is about OTP Tokens, it may be worth taking them off Policies and putting them into a new tab which in future may also sport a pointer to user certificates management: Yeah, may be for now we put OTP as a top level for now and have tokens and create a RADIUS page to manage radius proxies? In future when we add other credentials we can rename it and add smart card related options. Authentication: - OTP Tokens - User Certificates (future) HTH, Simo. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Move replication topology to the shared tree
On 06/05/2014 01:12 PM, Simo Sorce wrote: On Thu, 2014-06-05 at 16:46 +0200, Ludwig Krispenz wrote: On 06/05/2014 03:14 PM, Ludwig Krispenz wrote: On 06/05/2014 02:45 PM, Simo Sorce wrote: On Thu, 2014-06-05 at 11:27 +0200, Ludwig Krispenz wrote: On 06/04/2014 06:04 PM, thierry bordaz wrote: But this requires that the node database is already initialized (have the same replicageneration than the others nodes). If it is not initialized, it could be done by any masters. But if it is automatic, there is a risk that several masters will want to initialize it. I would not give the plugin the power to reinitialize a database on another server and I also would not put the responsibility to do it to the plugin. Initializing a server is an administrative task done at specific steps during deployment or in error conditions and most time has to be scheduled and often on-line initialization is not the preferred method. Agree. The plugin could still be used to trigger online initializations if the nsds5replicarefresh attribute is part of the information in the shared tree, it can be modified, the plugin on the targeted server will detect the change, update the replication agreement object and start the initialization (but this should probably still be allowed to be done directly). Nope, leave re-initialization to the plumbing. The topology plugin deals only with topology, it should not be involved with re-initializations, save for not going crazy and trying to remove agreements during a re-initialization. The question for me was more how the configuration information in the shared tree is initialized (not the full shared tree). We do agree that the info in the shared tree should be authoritative. Yep. To synchronize the info in the shared tree and cn=config I see two modes: passive mode: the sync is only from the shared tree to cn=config, it is the responsibility of an admin/tool to initialize the config in the shared tree This is my preferred, although leaves the problem open for migration, we need a way to properly prime the topology so that it doesn't wipe out current agreements before they are imported. supporting mode: if the plugin starts, it checks if the info in the shared tree exists, if not it initializes the topology info in the shared tree and then only reacts to changes in the shared tree. I would like some more details about what you have in mind here, depending on the fine points I might agree this is desirable to solve the migration problem. I will write it down for a few different scenarios. looks like this could get ugly, if the topology info initialization would happen on several masters at the same time, they would create the same entries (at least the config root container) and we could get replication conflicts :-( This is exactly why I said I do not want the plugin to create the topology tree itself :-) It should only import agreements that are not yet there. There is still potential conflict, the topology plugin will have to handle them, by intercepting replication writes to the topology tree and smartly merging/fencing IMO. we need to be careful on the process, I have an idea how it could work, but need to think a bit more about it I am all ears. Simo. We already have several situations (CRL, DNSSEC, cert rotation) where a single server has to do the job first and all the rest should rely on that. We can simply our life by making the initialization a special admin initialized operation for the situations when we upgrade from earlier versions. So general topology plugin does not initialize anything automatically. If we build a new deployment the ipa replica management tools will drive the modifications as servers are added. If it is an upgrade admin might go to IPA configuration and ray build/rebuild topology. This will drop all segment information if there is any and using master list from cn=masters connect to each replica, query its replication agreements and create data for the replicated tree. If some replica is not on line the operation will report that replica can be connected and that topology is not complete. I think this is acceptable for topology plugin to focus only on keeping data in sync when replica management tools are invoked and mot worry about initialization after migration. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Reorganization of Web UI navigation items
On 06/03/2014 04:29 AM, Petr Spacek wrote: On 3.6.2014 09:54, Martin Kosek wrote: On 06/02/2014 03:59 PM, Petr Vobornik wrote: Hi List, the purpose if this mail is to start a discussion about reorganization of navigation items. Users are not fond of such change so we should come up with a solution which would last for some time. Problem: UX recommendation is that one menu level should contain maximum of 7 items. We have 10 items in Identity, 7 in Policy and 7 in IPA Server. Basically we reached max. capacity of all 1st-level items. Solution: Introduce new 1st-level items and redistribute 2nd-level items. Initial Draft: Identity (6) - Users - Groups - Hosts - Hostgroups - Netgroups - Services ok, though I have different division in mind. Policy (5) some better name? - HBAC - SUDO - Automount - Automember - SELinux User Maps I am not sure about Automount, SUDO and Automember as they are not so about policy related to users but rather about central storage for native Linux services - similarly to DNS. Authentication (4) - Radius Server Proxy - OTP Tokens - Password Policy - Kerberos Ticket Policy Hm, Policy is indeed strange. Infrastructure (6) some better name? - DNS - Realm Domains - Trust - Views - ID Ranges - Certificates Permissions (3) - Role Based Access Control - Self Service Permissions - Delegation Configuration (1) - Global Let me twist your proposal a bit and come to it from different way, i.e. thinking about what admin wants to do. If he wants to set up a user, he should not need to go to 2 different top level items. Users - Users - Groups - OTP Tokens - Password Policy - Automember Hosts - Hosts - Host groups - Netgroups - HBAC - SELinux User Maps User maps are more about users than hosts. No? Services - Services - SUDO - Automount I do not like services on two levels but I can't come up with an alternative. Trusts - (future) Views - Trust configuration - Trusts Ad other trusts in future Infrastructure - Certificates - DNS - Realm Domains - Kerberos Ticket Policy - (future) Replication topology Configuration - Global - RBAC Is it IPA access control? - ID Ranges I suggest different slicing: Configuration - Global - Access control - Realm Domains - Kerberos Ticket Policy - ID ranges Infrastructure - (future) Replication topology - DNS - (future) Vault I am not sure about Certificates. Is it about root CA? Can you point me to a feature page that corresponds to this feature? Should we have also: (future) Support - Documentation - Project Wiki - File issue here ... Does that make sense? This seems reasolable. Couple nitpicks: 1) Certificates under Infrastructure: Now we don't support them for users, but this will change in (distant?) future. Also, hosts have own certificates. Services can have own certificates etc. Can we have e.g. Certificates button at two different places? (But still opening the same dialog.) 2) Kerberos Ticket Policy is also related to users ... 3) Configuration and Infrastructure seems so related to me that I would personally merge them. Anyway, this seems like a step in the right direction! -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ 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
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
Re: [Freeipa-devel] [RFC] Migrating existing environments to Trust
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? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ 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
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. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel
Re: [Freeipa-devel] User life cycle: plugins scope for staged users
On 05/29/2014 02:17 AM, Martin Kosek wrote: On 05/29/2014 04:09 AM, Dmitri Pal wrote: On 05/22/2014 10:33 AM, thierry bordaz wrote: Hello, In order to provision staged users (account inactivated) with there initial values: /usr/bin/ipa user-add tb20 --to-stage --first=tb20 --last=tb20 - Added user tb20 - User login: tb20 First name: tb20 Last name: tb20 Full name: tb20 tb20 Display name: tb20 tb20 Initials: tt Home directory: /home/tb20 GECOS: tb20 tb20 Login shell: /bin/sh Kerberos principal: t...@idm.lab.bos.redhat.com Email address: t...@idm.lab.bos.redhat.com UID: -1 GID: -1 Account disabled: true Password: False Kerberos keys available: False ldapsearch -LLL -h localhost -p 389 -D cn=directory manager -w Secret123 -b dc=idm,dc=lab,dc=bos,dc=redhat,dc=com uid=tb20 dn: uid=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com displayName: tb20 tb20 cn: tb20 tb20 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys loginShell: /bin/sh uidNumber: -1 ipaUniqueID: autogenerate gidNumber: -1 gecos: tb20 tb20 sn: tb20 homeDirectory: /home/tb20 uid: tb20 mail: t...@idm.lab.bos.redhat.com krbPrincipalName: t...@idm.lab.bos.redhat.com givenName: tb20 initials: tt I needed to resctrict the scope of the following plugins: dn: cn=ipaUniqueID uniqueness,cn=plugins,cn=config nsslapd-pluginarg1: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com dn: cn=IPA Unique IDs,cn=IPA UUID,cn=plugins,cn=confi ipauuidscope: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config dnaScope: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com dn: cn=MemberOf Plugin,cn=plugins,cn=config memberofentryscope: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com In fact I need them to not modify the added entry when it is added under cn=staged users,cn=accounts,cn=provisioning,$SUFFIX. Now is it possible to limit those plugins scope to the 'cn=accounts' part of the tree ? I guess not. If it is not possible, a solution is to make the scope multi-valued attributes or to introduce a new config attribute '*notInScope' also multi-valued. A problem is the 'cn=ipaUniqueID uniqueness' that rely on the 'attribute uniqueness' plugin with a argv[ ], not really convenient to pass 2 multivalued attributes. If anyone is having others solutions it would help me a lot :-) thanks thierry The easiest solution IMO is to not treat staging area as an account area, i.e instead of cn=staging, cn=accounts, dc=... I suggest saving users in cn=users, cn=staging, dc=... Actually, this almost exactly the DN I wrote in the RFE: http://www.freeipa.org/page/V4/User_Life-Cycle_Management#User_status Proposed containers are: cn=staged users,cn=accounts,cn=provisioning,$SUFFIX cn=deleted users,cn=accounts,cn=provisioning,$SUFFIX This way if in future we will have some staging for other objects (for whatever reason) we will create containers under common staging area. I would also argue that deleted should not be under accounts. Agreed. This will also make the plugin configuration (tree exclusion) easier. Martin I do not think so. My proposal is not to have staging under cn=accounts because most of the plugins enforce uniqueness and other consistency like DNA in the cn=account sub tree. Moving it out would move the staging out of the scope of the plugins and plugin configuration would not need to change. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ 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
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 ipa user-undel OR ipa user-undelete - Dmitri mentioned that he would like to see the move
Re: [Freeipa-devel] [RFC] Migrating existing environments to Trust - v2: reverse DNS lookup
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. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] User life cycle: plugins scope for staged users
On 05/22/2014 10:33 AM, thierry bordaz wrote: Hello, In order to provision staged users (account inactivated) with there initial values: /usr/bin/ipa user-add tb20 --to-stage --first=tb20 --last=tb20 - Added user tb20 - User login: tb20 First name: tb20 Last name: tb20 Full name: tb20 tb20 Display name: tb20 tb20 Initials: tt Home directory: /home/tb20 GECOS: tb20 tb20 Login shell: /bin/sh Kerberos principal: t...@idm.lab.bos.redhat.com Email address: t...@idm.lab.bos.redhat.com UID: -1 GID: -1 Account disabled: true Password: False Kerberos keys available: False ldapsearch -LLL -h localhost -p 389 -D cn=directory manager -w Secret123 -b dc=idm,dc=lab,dc=bos,dc=redhat,dc=com uid=tb20 dn: uid=tb20,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos, dc=redhat,dc=com displayName: tb20 tb20 cn: tb20 tb20 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys loginShell: /bin/sh uidNumber: -1 ipaUniqueID: autogenerate gidNumber: -1 gecos: tb20 tb20 sn: tb20 homeDirectory: /home/tb20 uid: tb20 mail: t...@idm.lab.bos.redhat.com krbPrincipalName: t...@idm.lab.bos.redhat.com givenName: tb20 initials: tt I needed to resctrict the scope of the following plugins: dn: cn=ipaUniqueID uniqueness,cn=plugins,cn=config nsslapd-pluginarg1: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com dn: cn=IPA Unique IDs,cn=IPA UUID,cn=plugins,cn=confi ipauuidscope: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config dnaScope: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com dn: cn=MemberOf Plugin,cn=plugins,cn=config memberofentryscope: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com In fact I need them to not modify the added entry when it is added under cn=staged users,cn=accounts,cn=provisioning,$SUFFIX. Now is it possible to limit those plugins scope to the 'cn=accounts' part of the tree ? I guess not. If it is not possible, a solution is to make the scope multi-valued attributes or to introduce a new config attribute '*notInScope' also multi-valued. A problem is the 'cn=ipaUniqueID uniqueness' that rely on the 'attribute uniqueness' plugin with a argv[ ], not really convenient to pass 2 multivalued attributes. If anyone is having others solutions it would help me a lot :-) thanks thierry The easiest solution IMO is to not treat staging area as an account area, i.e instead of cn=staging, cn=accounts, dc=... I suggest saving users in cn=users, cn=staging, dc=... This way if in future we will have some staging for other objects (for whatever reason) we will create containers under common staging area. I would also argue that deleted should not be under accounts. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Supported Staged entries
was also to limit the operator privilege to do MODRDN from 'pre-active' to 'active', instead ADD on 'active'. Just a note: The modrdn privilege is needed for moving users from normal to deleted and from deleted to normal or to staging. This was its primary intent of the RFE. It was not for staging to normal as that use case can in fact be addressed by adding a normal entry and then deleting the staged entry. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Supported Staged entries
better into the plugin model as well since the container, default objectclasses, etc will be different for these entries. rob +1 I was actually suggesting this too. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Supported Staged entries
On 05/28/2014 10:50 PM, Dmitri Pal wrote: On 05/28/2014 01:18 PM, Rob Crittenden wrote: Simo Sorce wrote: On Wed, 2014-05-28 at 15:56 +0200, Martin Kosek wrote: On 05/28/2014 02:48 PM, Simo Sorce wrote: On Wed, 2014-05-28 at 09:38 +0200, thierry bordaz wrote: On 05/28/2014 08:22 AM, Martin Kosek wrote: On 05/27/2014 08:18 PM, Simo Sorce wrote: On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote: On Tue, 27 May 2014, Simo Sorce wrote: On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote: On 05/27/2014 06:56 PM, Simo Sorce wrote: On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote: On 05/27/2014 06:06 PM, Simo Sorce wrote: We just need to care about the 'uid' attribute in the staged entry, and pick that to generate the RDN of the user in the active tree. If there are conflicts the 'unstage' will fail cleanly, as the 'add' operation will just fail (due to non unique RDN) and the admin will have to take care of the situation. In that case the provisioning system created a staging entry ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE It could be an issue for the provisioning system to retrieve the entry it created. Too bad for the provisioning system, we are not going to allow users to have a form that does not use uid in the RDN in IPA. Sounds like a lot of complexity for a problem we do not really have, all we need is to not enforce uniqueness in staging. This proposal was also to limit the operator privilege to do MODRDN from 'pre-active' to 'active', instead ADD on 'active'. It is not useful, the operator still needs to be able to create in pre-active ... so it can still create what it wants. yes that is correct. Does it address the security concern, if the operator that is allowed to add in 'staging'/'pre-active' is different from the one allowed to move the entry in 'active' ? Well it really depends on 'who' the operator is. We would like to be able to allow a 'junior admin/helpdesk person' to just press a button to activate a user, but that shouldn't drive our design if it makes other things clumsy or suboptimal. The less privileged operator problem can always be solved by a middle-man script that has higher privileges. So we nee to give priority to getting the workflow right in terms of the way it works. I think re-creating the user object gives us better chances at handling the overall workflow and fixing up entries accordingly to the management framework view of what a user needs to look like, so in the end I prefer that route. I agree. It also opens us a way to handle import of any foreign schema person if staged object uses extensibleObject object class where we are in control of what exactly will get into the actual tree. Right it allows us to do things like filter out objectclass or attributes the provisioning system adds but that the admin does not want in the final entry. This is not something we may want to build into the solution from day zero, but it gives us the option to build it more easily, as a framework filter on the 'unstage' operation. (We so need to be able to copy additional objectclasses and their attributes from day 0 though). Simo. Ok, thanks guys, I see an agreement. Thierry, we should now update all the information here: http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP (you can even link this thread in the archives) Martin Yes I will do that. Regarding workflow, it looks a priority that active entries are valid (regarding FreeIPA). Currently CLI offers: * ipa user-add (in active) * ipa user-add --stage (in stage). In order to prevent admin to add a corrupted entry in active and force any entry to go through the filter of objectclass/attribute, we could make 'ipa user-add' to create entry in staging and 'ipa user-add --active' to create entry in active. Even more, should we support to add entry directly in 'active' or rather only support 'user-add' to go only in staging ? I do not see why this would ever be necessary, ipa user-add cannot create a corrupt entry by definition. I am actually not very happy with the ipa user-add --stage idea, the staging area is necessary for when you do not create a full 'ipa' user entry, but rather for when a provisioning system creates an incomplete entry. Simo. /me wishes that the major concerns were spelled out during initial RFE review... Could this help a custom provisioning system that uses FreeIPA user-add JSON-RPC command instead of ldapadd? The record may still be incomplete in terms of company policy (e.g. missing manager) and about to be moved only when the user joins the company? Or is this nonsense and we should avoid doing user-add/user-mod/user-del in the staging area? Note that I did not say we should not have an IPA command for that, but I dislike the idea of putting it in the user plugin and using that specific command expression. I would see something
Re: [Freeipa-devel] User life cycle: question regarding the design
On 05/23/2014 01:01 PM, Simo Sorce wrote: On Fri, 2014-05-23 at 17:47 +0200, thierry bordaz wrote: About membership. I think it could be risky to keep membership in 'delete' or 'stage'. Those entries are not valid user and should not belong to any active group. Should we keep membership attributes in those state or let the plugin recompute the valid values when the entry is back to active ? Recompute. When a user is deleted it loses the memberships, when it is reactivated then new memberships need to be computed or explicitly added. Simo. Yes. This was a part of the initial design. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ 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
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. 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. 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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Understanding FreeIPA replica internals
On 05/23/2014 06:42 AM, Martin Kosek wrote: On 05/23/2014 07:01 AM, James wrote: I'm trying to understand some of the FreeIPA replication internals so that I can better know how to do this properly in Puppet without storing any secret information in Puppet, and so that automating FreeIPA is awesome. Please point me to any docs, if there is reading I could be doing :) Here are some open questions I have: 1) Is the GPG file created with ipa-replica-prepare using a symmetric password and is that password equal to the dm_password ? If not, where do the pub/priv key pairs come from and how do they get transferred to the replica. Yes. Grep for function expand_replica_info in FreeIPA git. 2) If I have root on the IPA server (actually all of them) how can I run ipa-replica-prepare without needing interactive prompting for entering the password. It's not possible with puppet. Is there another (possibly less user friendly even) method to prepare the replica? What is prepare actually doing? For, you can for example use --password for passing the DM password. I guess the question is more: If I am root is there any way to do the operation without providing the password but rather using something like LDAPI to drive the operation. The issue is that if you use puppet there is no way to get the password dynamically from some kind of source without baking it into the scripts. Baking passwords into scripts is bad so to avoid it there needs to be a way for root to install replica without it. I am not sure it is currently possible though. 3) With a multi master setup, what happens if I run the same action (eg: user-mod or user-add or user-del) on more than one server. I would not do that, you risk replication conflicts on entries or attributes. More here: https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html Can I run it on any server? Yes. What if I run different user-mod commands of the same user on different masters. Is there split brain? Then you get a replication conflict. I think in case of attributes, last modification wins. Are all the transactions and writes synchronous across the whole cluster? They are not synchronous, it takes some time for a change to replica to all masters. Please point me to a doc that explains this FAQ stuff if possible. Sorry for the noise You should be able to get a reasonable starting information here: https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Deployment_Guide/Designing_the_Replication_Process.html or here: https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication.html HTH, Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Status/Question about User life cycle
.) ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ 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
owned by him unless admin forces a flush of his IDs (new switch???) when he moves user from deleted to staged. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] OTP Sync Client Design
On 05/14/2014 05:23 PM, Nathaniel McCallum wrote: On Wed, 2014-05-14 at 16:34 -0400, Dmitri Pal wrote: On 05/14/2014 02:08 PM, Nathaniel McCallum wrote: Occasionally OTP tokens get out of sync with the server. When this happens, the user or an admin need to synchronize the token. To this end, we landed server-side synchronization support, which is a simple bind with a custom control. This all works with my sample test script. Client support is proving a bit more difficult. In the ideal world, the client would contact LDAP directly and perform the operation. This would make a man in the middle attack difficult and we can ensure encryption over the entire operation. However, browsers, without server-side assistance, cannot perform this operation from javascript. This means that, in this case, the first factor and two second factors must be transmitted to the FreeIPA server and then proxied to 389. Is this an acceptable compromise? Does Javascript have a way to encrypt things? May be we should do some encryption before sending the values over the wire? On the other hand we are OK with the form based login so I am not sure if there is any value. Yes, but I agree there is not a lot of value. We might have some logic related to permissions i.e. members of the admin group can only sync on server but I am not sure that is something we should consider out of box. In any way IMO it should be a separate page, other than login page that can be accessed by anyone. It should be visible outside firewall like other OTP vendors do. This would allow to use a mobile device to sync up a token (and potentially change the password). This would be nice. This command also needs to be accessible *without* an existing user login since, if a user's token is out of sync, the user can't login. Is it possible to expose such an API? If so, how? Both ipa env and ipa ping seem to require kinit, so I don't see any obvious examples. IMO SSSD should probably have a way to sync the token. From usability point of view it should be a part of the standard stock client software, not a part of the IPA client or ipa tools. It should probably have a good UI integration too if token is used to login into a laptop. SSSD has direct access to LDAP right? If so, it can just do a bind with the added control. That is actually the easiest way. Trying to access via a third API is probably actually more difficult. So for that to happen we should probably expose this interface over D-BUS. This is what we talked about with the desktop folks some time ago. The attached is the doc and there are diagrams at the end that show what we decided needs to be done. Similar to that one can provide a simple otp-sync application that will sync using command line (but on the other hand may be it should just warp curl?). How exactly we expose this in GDM is indeed a much more complicated question and needs to be part of the next phase of integration. I've CC'd jhrozek for this part. Some thoughts came up while writing this mail: a) We can go the complex path and provide password and sync capabilities in every client. This is a lot of work based on my past experience and can't be done quickly. See the complexity of the diagrams and flows in the attached doc. And may be it should not be. The synchronization needs to be added to whatever layer has access to the LDAP server. How it is exposed from there is specific to each application. b) May be IPA should provide a portal/proxy to do self service token sync and/or password change. This can be a URL. It should be possible to access it externally outside the firewall. It should be bullet proof. But then we need just one interface and one call and we can use it from mobile device or some other system on the internet to self service the token and then pass authentication. IMO that would save us a lot of time and effort. I know other OTP vendors went this path and were quite successful. +1. This solves the VPN bootstrapping problem. However: 1. It should be available by default in the FreeIPA installation with a link from the login page. This is just a matter of product polish. 2. In the case of a user logging into GDM, we have a bootstrapping problem that they can't login without a token, and they can't sync their token without logging into a browser. GDM/SSSD probably needs to support this natively. True but not from day one. This is why I mentioned a mobile device. Keeping in mind that FreeOTP is on the mobile device and there is a good chance that the person who will have a Linux laptop will have a mobile device. They can also call a helpdesk and ask the helpdesk engineer to sync the token for them. That means that there should be an admin interface that would not require the first factor just two codes. Nathaniel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel
Re: [Freeipa-devel] OTP Sync Client Design
On 05/14/2014 05:49 PM, Nathaniel McCallum wrote: On Wed, 2014-05-14 at 17:35 -0400, Dmitri Pal wrote: On 05/14/2014 05:23 PM, Nathaniel McCallum wrote: On Wed, 2014-05-14 at 16:34 -0400, Dmitri Pal wrote: On 05/14/2014 02:08 PM, Nathaniel McCallum wrote: Occasionally OTP tokens get out of sync with the server. When this happens, the user or an admin need to synchronize the token. To this end, we landed server-side synchronization support, which is a simple bind with a custom control. This all works with my sample test script. Client support is proving a bit more difficult. In the ideal world, the client would contact LDAP directly and perform the operation. This would make a man in the middle attack difficult and we can ensure encryption over the entire operation. However, browsers, without server-side assistance, cannot perform this operation from javascript. This means that, in this case, the first factor and two second factors must be transmitted to the FreeIPA server and then proxied to 389. Is this an acceptable compromise? Does Javascript have a way to encrypt things? May be we should do some encryption before sending the values over the wire? On the other hand we are OK with the form based login so I am not sure if there is any value. Yes, but I agree there is not a lot of value. We might have some logic related to permissions i.e. members of the admin group can only sync on server but I am not sure that is something we should consider out of box. In any way IMO it should be a separate page, other than login page that can be accessed by anyone. It should be visible outside firewall like other OTP vendors do. This would allow to use a mobile device to sync up a token (and potentially change the password). This would be nice. This command also needs to be accessible *without* an existing user login since, if a user's token is out of sync, the user can't login. Is it possible to expose such an API? If so, how? Both ipa env and ipa ping seem to require kinit, so I don't see any obvious examples. IMO SSSD should probably have a way to sync the token. From usability point of view it should be a part of the standard stock client software, not a part of the IPA client or ipa tools. It should probably have a good UI integration too if token is used to login into a laptop. SSSD has direct access to LDAP right? If so, it can just do a bind with the added control. That is actually the easiest way. Trying to access via a third API is probably actually more difficult. So for that to happen we should probably expose this interface over D-BUS. This is what we talked about with the desktop folks some time ago. The attached is the doc and there are diagrams at the end that show what we decided needs to be done. Similar to that one can provide a simple otp-sync application that will sync using command line (but on the other hand may be it should just warp curl?). How exactly we expose this in GDM is indeed a much more complicated question and needs to be part of the next phase of integration. I've CC'd jhrozek for this part. Some thoughts came up while writing this mail: a) We can go the complex path and provide password and sync capabilities in every client. This is a lot of work based on my past experience and can't be done quickly. See the complexity of the diagrams and flows in the attached doc. And may be it should not be. The synchronization needs to be added to whatever layer has access to the LDAP server. How it is exposed from there is specific to each application. b) May be IPA should provide a portal/proxy to do self service token sync and/or password change. This can be a URL. It should be possible to access it externally outside the firewall. It should be bullet proof. But then we need just one interface and one call and we can use it from mobile device or some other system on the internet to self service the token and then pass authentication. IMO that would save us a lot of time and effort. I know other OTP vendors went this path and were quite successful. +1. This solves the VPN bootstrapping problem. However: 1. It should be available by default in the FreeIPA installation with a link from the login page. This is just a matter of product polish. 2. In the case of a user logging into GDM, we have a bootstrapping problem that they can't login without a token, and they can't sync their token without logging into a browser. GDM/SSSD probably needs to support this natively. True but not from day one. This is why I mentioned a mobile device. Keeping in mind that FreeOTP is on the mobile device and there is a good chance that the person who will have a Linux laptop will have a mobile device. They can also call a helpdesk and ask the helpdesk engineer to sync the token for them. That means that there should be an admin interface that would not require the first factor just two codes. Yup. Agreed. Just thinking big picture. Nathaniel So it looks like that we agree
Re: [Freeipa-devel] Consistent password hashing and lookups
On 05/12/2014 10:37 PM, James wrote: On Mon, May 12, 2014 at 6:22 PM, Dmitri Pal d...@redhat.com wrote: On 05/12/2014 06:07 PM, James wrote: On Mon, 2014-05-12 at 17:56 -0400, Dmitri Pal wrote: Is there any other attribute to look at? For example the timestamp when it was last set and base the update on that rather than on matching password values? There are some other solutions, but they are less elegant or don't work consistently. (Eg: bad hacks) I would argue that comparing hashes is the worst hack ever. Can you create a file once you set a password to indicate that password is set? Not possible... Bottom line - I do not like the approach you are trying to implement and I do not want you to find a way to solve this problem by comparing hashes. It is not a good security hygiene. I would rather suggest patches to puppet to address the issue properly than aid you on this path. I think you are missing the point... It is a bit subtle. Puppet is weird :) Here's what I'll do. I'll finish my other password related work, and then I'll post back with my complete feature branch minus the missing commands that I'm hoping to learn from the ML. I think you'll realize what I'm doing makes a lot of sense. I think you'll also soon agree that I have the only puppet module out there that is managing passwords responsibly. The status quo is that people are storing cleartext passwords _in puppet! This is their problem. Why would we aid them to do wrong things and make it easier? I really miss the point. Why it is all needed? Why do you need to reset passwords in IPA through puppet? What is the use case? tsk tsk. In any case, since when did a project stop it's users from shooting themselves in the foot if they thought that was right? Cheers, James Sorry ;-) -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA on AWS EC2
On 05/09/2014 10:01 PM, daiEric wrote: hi Is there any solution to deploy FreeIpa on ubuntu linux？ OK, so after some investigation it seems that there is none. Some components can be used on Ubuntu but the whole IPA is not built on Ubuntu. We would welcome anyone to take the ownership of this task and make this possible. Thanks Dmitri thanks Eric dai 在 2014年5月10日，4:01，Martin Kosek mko...@redhat.com 写道： On 05/08/2014 06:55 PM, Dmitri Pal wrote: On 05/08/2014 11:59 AM, Hendri Morris wrote: Is there any plan to bring FreeIPA to Amazon AWS EC2? At this point the client doesn't even install on Amazon Linux (Redhat Clone Optimized for AWS). Goes straight to dependency hell. I deployed a multi-server FreeIPA in a enterprise environment and absolutely love the product. Please add AWS to the roadmap! https://owa.telit.com/owa/CookieAuth.dll?ae=Itema=Newt=IPM.Notecc=MTQuMy4xNTguMSxlbi1VUyw0Mjk0OTY3Mjk1LEhUTUwsMCwwpspid=_1399557927266_619631222# https://owa.telit.com/owa/CookieAuth.dll?ae=Itema=Newt=IPM.Notecc=MTQuMy4xNTguMSxlbi1VUyw0Mjk0OTY3Mjk1LEhUTUwsMCwwpspid=_1399557927266_619631222# *www.ilstechnology.com* http://www.ilstechnology.com ** *Hendri Morris* Senior Cloud Engineer deviceWISE Operations This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Have you tried this? http://cloud-mechanic.blogspot.com/2013/10/diversion-kerberos-freeipa-in-aws-ec2.html Great to hear you like FreeIPA! As you get in a dependency hell, I would assume it is not a problem of FreeIPA vs. AWS, but rather some packaging issue in your image of choice (i.e. the Red Hat clone). I personally tried deploying FreeIPA in Red Hat OpenStack instance for a public demo testing instance and did not hit much resistance. You just need to keep your hostname static (did with cloud-init) and make sure the DNS is sane and it should work ok. I plan to write some article about the OpenStack demo soon, stay tuned. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Consistent password hashing and lookups
On 05/12/2014 03:43 AM, Alexander Bokovoy wrote: On Mon, 12 May 2014, Martin Kosek wrote: On 05/12/2014 03:47 AM, James wrote: On Sun, May 11, 2014 at 9:02 PM, Dmitri Pal d...@redhat.com wrote: On 05/11/2014 06:31 PM, James wrote: On Sun, May 11, 2014 at 3:04 PM, Dmitri Pal d...@redhat.com wrote: This is scary. This means that you expecting to have a hash being stored somewhere else outside the DS. Haha, I agree! Actually, worse! I will have the plain text password stored somewhere outside the DS! Let me give you more background: I think this is an atrociously bad idea. However *everybody* stores password credentials poorly in puppet. So in order to do it properly, I've gone to great lengths to support something smarter for puppet-ipa. Most of the code is already done. Which module do you want me to look at? I am not going to review your whole project :-) I just posted it for fun. I wasn't looking for a review, though! The technique is rather complicated, so I'm going to save it for a longer blog post write up when it's finished. https://github.com/purpleidea/puppet-ipa/tree/feat/better-pw You'll be very pleased to know it doesn't do anything bad! BUT: I am still going to support the bad method of storing the actual password in puppet. Sad, but still used. So I do need to know how to do this bad thing, but if you look at my code, you'll see I'm doing something clever. Once it's all done and tested, I'll blog about it and announce the technique publicly. Can you describe the workflow? You want to be able to reset the admin password, right? How do you bind? Using same admin password? Or keytab? I don't bind. I'm running as root on the free-ipa server. But to do an LDAP operation you still need to connect to LDAP. You can use LDAPI in this case but then you do not need to authentocate at all, I think in this case you should be able to overwrite the password without knowing the old one. I do not think we should promote bad and insecure practices around the security product. That defeats the purpose. I strongle suggest avoiding saving any password and resetting the existing password using local root. I think it is possible. If not we need to think about the proper way of solving your use case. Agreed. Which is why I posted the feature branch early, to hopefully convince the ipa community that I'm going about the password stuff the right way. Anyways, back to the question: What commands can I use to look up the hash, and compute the hash? (Or simply test if a string password matches the stored password.) Same questions for the DM password. Thanks! I sense some very black magic happening in this thread... I do not see any reason for storing the password or hash of the password outside of FreeIPA. As you said, you have a local root access to IPA machine, you can then bind as Directory Manager and see or change any password. 1) Get fbar1;s b64 encoded password hash: # ldapsearch -Y EXTERNAL -H ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket -b 'uid=fbar1,cn=users,cn=accounts,dc=example,dc=com' userPassword 2) Forcefully change fbar1's password: # ldapsearch -Y EXTERNAL -H ldapi://%2fvar%2frun%2fslapd-EXAMPLE-COM.socket 'uid=fbar1,cn=users,cn=accounts,dc=example,dc=com' -s newpassword s/ldapsearch/ldappasswd/ Note that the user fbar1 will not be prompted for the new password as the password was changed by DM. As Dmitri wrote, a safer and a better approach would be to have the script run as a special/system user with appropriate privilege, authenticated with a keytab. Such user could then just call ipa passwd FreeIPA command. I think the point here is that puppet-ipa module is run by puppet under root account already, so ldappasswd using ldapi with external auth under root is enough. Introducing another user when you are already root seems to be a bit overbloat in puppet's case. Yes and this was my point too. If you have root you do not need to know the old password. You can just reset the current one to what you want. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Consistent password hashing and lookups
On 05/12/2014 04:28 PM, James wrote: On Mon, 2014-05-12 at 16:25 -0400, Dmitri Pal wrote: Yes and this was my point too. If you have root you do not need to know the old password. You can just reset the current one to what you want. I agree, with you. This isn't about functionality, it's about automating functionality. Puppet needs to know if the stored password matches the password it thinks is correct. Without this it would just try and run setpassword each run. I will test Martin's command shortly :) Cheers! Is there any other attribute to look at? For example the timestamp when it was last set and base the update on that rather than on matching password values? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Consistent password hashing and lookups
On 05/12/2014 06:07 PM, James wrote: On Mon, 2014-05-12 at 17:56 -0400, Dmitri Pal wrote: Is there any other attribute to look at? For example the timestamp when it was last set and base the update on that rather than on matching password values? There are some other solutions, but they are less elegant or don't work consistently. (Eg: bad hacks) I would argue that comparing hashes is the worst hack ever. Can you create a file once you set a password to indicate that password is set? Bottom line - I do not like the approach you are trying to implement and I do not want you to find a way to solve this problem by comparing hashes. It is not a good security hygiene. I would rather suggest patches to puppet to address the issue properly than aid you on this path. Sorry ;-) -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA on AWS EC2
On 05/09/2014 10:01 PM, daiEric wrote: hi Is there any solution to deploy FreeIpa on ubuntu linux？ I thought we did a lot to make this happen and it is now possible but to be fair I did not see any instructions and guidelines so I am not sure. thanks Eric dai 在 2014年5月10日，4:01，Martin Kosek mko...@redhat.com 写道： On 05/08/2014 06:55 PM, Dmitri Pal wrote: On 05/08/2014 11:59 AM, Hendri Morris wrote: Is there any plan to bring FreeIPA to Amazon AWS EC2? At this point the client doesn't even install on Amazon Linux (Redhat Clone Optimized for AWS). Goes straight to dependency hell. I deployed a multi-server FreeIPA in a enterprise environment and absolutely love the product. Please add AWS to the roadmap! https://owa.telit.com/owa/CookieAuth.dll?ae=Itema=Newt=IPM.Notecc=MTQuMy4xNTguMSxlbi1VUyw0Mjk0OTY3Mjk1LEhUTUwsMCwwpspid=_1399557927266_619631222# https://owa.telit.com/owa/CookieAuth.dll?ae=Itema=Newt=IPM.Notecc=MTQuMy4xNTguMSxlbi1VUyw0Mjk0OTY3Mjk1LEhUTUwsMCwwpspid=_1399557927266_619631222# *www.ilstechnology.com* http://www.ilstechnology.com ** *Hendri Morris* Senior Cloud Engineer deviceWISE Operations This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Have you tried this? http://cloud-mechanic.blogspot.com/2013/10/diversion-kerberos-freeipa-in-aws-ec2.html Great to hear you like FreeIPA! As you get in a dependency hell, I would assume it is not a problem of FreeIPA vs. AWS, but rather some packaging issue in your image of choice (i.e. the Red Hat clone). I personally tried deploying FreeIPA in Red Hat OpenStack instance for a public demo testing instance and did not hit much resistance. You just need to keep your hostname static (did with cloud-init) and make sure the DNS is sane and it should work ok. I plan to write some article about the OpenStack demo soon, stay tuned. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Consistent password hashing and lookups
On 05/11/2014 01:27 PM, James wrote:
Hi #freeipa,
I'm working on improving my puppet-ipa module...
One area I'm working on is better password management...
In any case, here's the problem:
I want to give the script the ability to change it. The easy way to do
this is to compare what it is currently, to what it is set to. As I'm
assuming it's hashed, you have to compare hashes, IOW:
/usr/bin/test `hashed(somepass)` = `function_lookup_hash()`
This is scary.
This means that you expecting to have a hash being stored somewhere else
outside the DS.
Can you describe the workflow?
You want to be able to reset the admin password, right?
How do you bind? Using same admin password? Or keytab?
Assuming the admin password is stored as a deterministic hash, I need
two things:
1) To know how to run the hashing function manually (say from python)
2) To know how to lookup the stored hash manually (say from python)
Thanks to ab (#freeipa), I know how to set the admin password:
# split by the periods!
$domain_split = split(${valid_domain}, '\.')
# add dc= to each array element
$prefix = prefix($domain_split, 'dc=')
$suffix = join($prefix, ',')# eg: dc=example,dc=com
$socket_realm = regsubst(${valid_realm}, '\.', '-', 'G')
$ldapuri = ldapi://%2fvar%2frun%2fslapd-${socket_realm}.socket
$admin_password_change = /usr/bin/ldappasswd -Y EXTERNAL -s `
${admin_password_exec}` -H ${ldapuri} uid=admin,cn=users,cn=accounts,
${suffix}
I also have the same question for the DM password, however I don't yet
know how to set it. If someone has a script for that, I'd love that too!
Thanks again!
James
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Consistent password hashing and lookups
On 05/11/2014 06:31 PM, James wrote: On Sun, May 11, 2014 at 3:04 PM, Dmitri Pal d...@redhat.com wrote: This is scary. This means that you expecting to have a hash being stored somewhere else outside the DS. Haha, I agree! Actually, worse! I will have the plain text password stored somewhere outside the DS! Let me give you more background: I think this is an atrociously bad idea. However *everybody* stores password credentials poorly in puppet. So in order to do it properly, I've gone to great lengths to support something smarter for puppet-ipa. Most of the code is already done. Which module do you want me to look at? I am not going to review your whole project :-) https://github.com/purpleidea/puppet-ipa/tree/feat/better-pw You'll be very pleased to know it doesn't do anything bad! BUT: I am still going to support the bad method of storing the actual password in puppet. Sad, but still used. So I do need to know how to do this bad thing, but if you look at my code, you'll see I'm doing something clever. Once it's all done and tested, I'll blog about it and announce the technique publicly. Can you describe the workflow? You want to be able to reset the admin password, right? How do you bind? Using same admin password? Or keytab? I don't bind. I'm running as root on the free-ipa server. But to do an LDAP operation you still need to connect to LDAP. You can use LDAPI in this case but then you do not need to authentocate at all, I think in this case you should be able to overwrite the password without knowing the old one. I do not think we should promote bad and insecure practices around the security product. That defeats the purpose. I strongle suggest avoiding saving any password and resetting the existing password using local root. I think it is possible. If not we need to think about the proper way of solving your use case. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA on AWS EC2
On 05/08/2014 11:59 AM, Hendri Morris wrote: Is there any plan to bring FreeIPA to Amazon AWS EC2? At this point the client doesn't even install on Amazon Linux (Redhat Clone Optimized for AWS). Goes straight to dependency hell. I deployed a multi-server FreeIPA in a enterprise environment and absolutely love the product. Please add AWS to the roadmap! https://owa.telit.com/owa/CookieAuth.dll?ae=Itema=Newt=IPM.Notecc=MTQuMy4xNTguMSxlbi1VUyw0Mjk0OTY3Mjk1LEhUTUwsMCwwpspid=_1399557927266_619631222# https://owa.telit.com/owa/CookieAuth.dll?ae=Itema=Newt=IPM.Notecc=MTQuMy4xNTguMSxlbi1VUyw0Mjk0OTY3Mjk1LEhUTUwsMCwwpspid=_1399557927266_619631222# *www.ilstechnology.com* http://www.ilstechnology.com ** *Hendri Morris* Senior Cloud Engineer deviceWISE Operations This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Have you tried this? http://cloud-mechanic.blogspot.com/2013/10/diversion-kerberos-freeipa-in-aws-ec2.html -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter
On 05/07/2014 04:06 AM, Jan Cholasta wrote: On 6.5.2014 19:55, Nathaniel McCallum wrote: I know it is a bit late on this, but for the OTP token import script, I have to have support for the full ISO 8601. My plan right now is to use python-dateutil for this. Using dateutil would simplify some of this code. Is there a reason we aren't using dateutil? IIRC it was rejected right at the beginning as an overkill. What are the alternatives? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0049] Add support for protected tokens
On 05/07/2014 09:05 AM, Nathaniel McCallum wrote: On Wed, 2014-05-07 at 11:42 +0200, Jan Cholasta wrote: Hi, On 6.5.2014 17:08, Nathaniel McCallum wrote: On Tue, 2014-05-06 at 09:49 -0400, Nathaniel McCallum wrote: On Mon, 2014-05-05 at 12:42 -0400, Nathaniel McCallum wrote: This also constitutes a rethinking of the token ACIs after the introduction of SELFDN support. Admins, as before, have full access to all token permissions. Normal users have read/search/compare access to all of the non-secret data for tokens assigned to them, whether protected or non-protected. Users can add or delete non-protected tokens and modify most of their metadata. However they cannot create, delete or modify protected tokens. Regardless of whether the token is protected or not, users cannot change a token's ownership or unique identity. In contrast, admins can create protected tokens. This protects the token from deletion or modification when assigned to users. Additionally, when a user account is deleted, the assigned non-protected tokens are deleted but the protected tokens are merely orphaned. This permits the token to be reassigned without having to recreate it. This last point is particularly useful in the case of hardware tokens. https://fedorahosted.org/freeipa/ticket/4228 NOTE: This patch depends on my patch 0048. This new version makes ipatokenDisabled visible for token owners. It is also writable if the token is non-protected. This additionally fixes: https://fedorahosted.org/freeipa/ticket/4259 This new version changes the way the default value of protected is setup in accordance with the changes made for the review of my patch 0048.2. Nathaniel Is using the ipatokenprotected attribute the final design? No. Alternate designs are welcome. The code is easy enough to modify. I did not dig too deep into this, but I think it might be better to instead use the managedby attribute on a token to limit who can delete (or administer in other way) the token. On otptoken-add, managedby would be set to the whoami user DN, unless run with --protected, in which case managedby would be left empty. Then, when deleting a user, the token would be deleted only if the user manages the token. It seems to me that the mechanics of this are roughly the same as protected, just with a different syntax. The cost of this is more complex ACIs. In particular, we'd have to use two userdn clauses (is this possible?) instead of a simple filter. If there is a clear benefit, we can justify the more obtuse syntax. We usually try not to create new attributes until it is fully justified. I would like Simo to chime in on this. Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0137] ipalib: Add DateTime parameter
On 05/07/2014 11:46 AM, Nathaniel McCallum wrote: On Wed, 2014-05-07 at 09:50 -0400, Dmitri Pal wrote: On 05/07/2014 04:06 AM, Jan Cholasta wrote: On 6.5.2014 19:55, Nathaniel McCallum wrote: I know it is a bit late on this, but for the OTP token import script, I have to have support for the full ISO 8601. My plan right now is to use python-dateutil for this. Using dateutil would simplify some of this code. Is there a reason we aren't using dateutil? IIRC it was rejected right at the beginning as an overkill. What are the alternatives? Hand-coded date parsing, AFAICS. That is what we are currently doing. In order to make this sane, we greatly restrict the date formats permitted as input to a small subset of ISO 8601. This is possible because we just tell the users to type the date in one of the supported formats. Unfortunately, I can't make that trade-off in the token import script since I have no control over the input. Since I have to support all of ISO 8601 (including timezone conversions), the dateutils module is pretty much the only option. If we adopt it for OTP import, we might as well throw away our hand-coded date parsing. Nathaniel I would leave this till next week for Martin and Petr3 to chime in. I do not have a problem but I am not sure I can assess all the implications. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0049] Add support for protected tokens
On 05/06/2014 11:08 AM, Nathaniel McCallum wrote: On Tue, 2014-05-06 at 09:49 -0400, Nathaniel McCallum wrote: On Mon, 2014-05-05 at 12:42 -0400, Nathaniel McCallum wrote: This also constitutes a rethinking of the token ACIs after the introduction of SELFDN support. Admins, as before, have full access to all token permissions. Normal users have read/search/compare access to all of the non-secret data for tokens assigned to them, whether protected or non-protected. Users can add or delete non-protected tokens and modify most of their metadata. However they cannot create, delete or modify protected tokens. Regardless of whether the token is protected or not, users cannot change a token's ownership or unique identity. In contrast, admins can create protected tokens. This protects the token from deletion or modification when assigned to users. Additionally, when a user account is deleted, the assigned non-protected tokens are deleted but the protected tokens are merely orphaned. This permits the token to be reassigned without having to recreate it. This last point is particularly useful in the case of hardware tokens. https://fedorahosted.org/freeipa/ticket/4228 NOTE: This patch depends on my patch 0048. This new version makes ipatokenDisabled visible for token owners. It is also writable if the token is non-protected. This additionally fixes: https://fedorahosted.org/freeipa/ticket/4259 This new version changes the way the default value of protected is setup in accordance with the changes made for the review of my patch 0048.2. Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Have we recorded any new OIDs added as a part of this OTP cleanup in our OID registry? If not we should collect all added attributes and make sure they are recorded. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0044] Periodically refresh global ipa-kdb configuration
On 05/02/2014 02:52 PM, Simo Sorce wrote: On Thu, 2014-05-01 at 16:22 -0400, Nathaniel McCallum wrote: On Tue, 2014-03-11 at 11:09 -0400, Simo Sorce wrote: On Tue, 2014-03-11 at 16:05 +0200, Alexander Bokovoy wrote: On Tue, 11 Mar 2014, Jan Pazdziora wrote: On Mon, Feb 24, 2014 at 02:26:27PM -0500, Nathaniel McCallum wrote: Before this patch, ipa-kdb would load global configuration on startup and never update it. This means that if global configuration is changed, the KDC never receives the new configuration until it is restarted. This patch enables caching of the global configuration with a timeout of 60 seconds. https://fedorahosted.org/freeipa/ticket/4153 From 7daeae56671d7b3049b0341aad66c96877431bbe Mon Sep 17 00:00:00 2001 From: Nathaniel McCallum npmccal...@redhat.com Date: Mon, 24 Feb 2014 14:19:13 -0500 Subject: [PATCH] Periodically refresh global ipa-kdb configuration Before this patch, ipa-kdb would load global configuration on startup and never update it. This means that if global configuration is changed, the KDC never receives the new configuration until it is restarted. This patch enables caching of the global configuration with a timeout of 60 seconds. https://fedorahosted.org/freeipa/ticket/4153 I have only read the code and it looks sane, so depending on how much you consider my word about code-reading worth, ack. However, my gut feeling is that my preferred way of handling the issue (without knowing much about the background of the ticket) would probably be a HUP signal handler or something similar, rather than polling for current values with the value timeout. This patch introduces small nondeterminism to the behaviour when the usage of the new values cannot really be enfoced by the admin (without the daemon restart). Thing is, we need the update to happen when other, non-root process makes the changes -- in our case when IPA server running under httpd privileges performs series of MS-RPC calls towards smbd which lead to creating certain LDAP objects. httpd couldn't send SIGHUP to a process not owned by httpd's effective user (non-root). Yes but this is not really the way to go. The proper fix is to use syncrepl/persistent search to get a notification of when we need to reload the configuration. On the patch itself I have a NACK due to this syntax used in various places: function()-attribute don't. do. that. ever. assign whatever come from the function to a local variable and *check* it is not null, *then* use it. Attached patch fixes the NACK issue, but does not address the question of the larger approach. Do we need to take a different approach? If so, what is it? LGTM I might prefer slightly more explicit names for those temp vars, but that's not a big deal. As for the approach, moving to something like syncrepl would be a good idea. As it would allow us to avoid useless polling and changes would be applaied as soon as they become available as the syncrepl agreement would push them to our client. It does mean we need a way to check that there aren't pending changes coming down the syncrepl pipe, but we can do that synchronously at every entry point in the KDB. After all we do not need to care about a change until the KDC needs something from the KDB. Simo. Do we need a ticket for that then? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] First beta release of ConnID FreeIPA connector
On 04/24/2014 09:58 AM, Massimiliano Perrone (tirasa.net) wrote: Hi guys, this mail only to share with you that ConnID FreeIPA connector (beta version) is released. You can find more informations here [1] Massimiliano [1] http://blog.tirasa.net/unlock-full-freeipa-features.html Cool! It might make sense to put something on the IPA wiki to have a cross reference. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ 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
On 04/18/2014 02:03 PM, Sumit Bose wrote: On Fri, Apr 18, 2014 at 06:52:30PM +0200, Sumit Bose wrote: On Fri, Apr 18, 2014 at 01:53:30AM -0400, Simo Sorce wrote: On Thu, 2014-04-17 at 23:58 -0400, Dmitri Pal wrote: yes, this can already be controlled by the idrange type. But you have to choose either algorithmic or manual mapping you cannot have both in a given domain. What you can do is to create a domain in the AD forest for the old users and one for the new users. Now you can use manual mapping for the old-users-domain and algorithmic mapping for the new-users-domain. If this requires moving users between domains on AD side then this is a non starter. The more I read it the more I think that decision is wrong and it is bug. What we can do is halfway, if an overlay view is activate for an AD domain then in IPA we have options to automatically generate IDs for any AD user (if the admin wants), these IDs get stored in the Ad overlaying view. From the SSSD pov no algoritmic mapping is occurring as SSSD always looks for the IDs in IPA. Note that we have to do this anyway if you want to allow also legacy clients to see the same ids, so it seem to me the best/only possible way. I agree, this sounds like safe and robust solution to the discussed issues. I wonder if we shouldn't do this always for all users and groups in the AD trusted AD forests? Since it looks like most real-world deployments would need it anyways it might be easier to stop thinking about the few cases where this is not needed. We will have lots of additional objects in the database but on the plus side: - the compat-tree does not have to talk to SSSD and keep the users and groups in memory but can just read of object from the tree, maybe do some modification and deliver the result. - the current extdom plugin won't be needed anymore because all it's operations can be done by SSSD with plain ldapsearch. Another benefit would be easier group management because since now AD users and group have an object in the IPA tree, they can be added to IPA groups directly without the need of an external group. A positive side-effect is that migrations from the win-sync solution would become much easier. Yes this seems like the right direction to go. bye, Sumit I'm not sure but it might also be the only way to resolve the user or group name for a given UID or GID in a more complex environment. The only caveat is that it requires some development on the IPA side to do this object creation, but it is not a lot of code as we can reuse DNA for the actual ID allocation, we just need to create the entry in the view. Or as an alternative SSSD running in ipa-server-mode can create the missing objects? Since SSSD in ipa-server-mode is currently doing the ID allocation it would be easily to keep compatibility with older versions. bye, Sumit 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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ 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
On 04/17/2014 05:15 AM, Sumit Bose wrote: On Wed, Apr 16, 2014 at 09:02:00PM -0400, Dmitri Pal wrote: On 04/15/2014 05:13 AM, 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 . I came across several questions which need answers so that more details can be added to the design. Besides that comments and suggestions are welcome as well. For your convenience I added the test below as well. bye, Sumit = Overview = This page illustrates how existing solutions which make AD users available to Linux hosts can be migrated to FreeIPA with Trusts. This includes migrations from the FreeIPA WinSync feature or environments where the AD users where correlated to NIS users. The common problem here is that some if not all attributes needed by a POSIX user or group must be overwritten or supplied by the IPA server. The link to the related AD object is preferably the SID but if it is not available on both sides the name of the object must be used. AD will keep the responsibility for authentication and provide the AD group-memberships of the object. = Use Cases = * Migration from the FreeIPA Sync solution to the FreeIPA Trust solution ** [https://fedorahosted.org/freeipa/ticket/3318 https://fedorahosted.org/freeipa/ticket/3318] * Migration/Consolidation of domains currently managed by other solutions, e.g. NIS ** [https://fedorahosted.org/freeipa/ticket/3979 https://fedorahosted.org/freeipa/ticket/3979] (contains some ideas about a solution) As I mentioned in the ticket not only that. Based on conversations with different potential consumers of the trust functionality the ability to use existing POSIX attributes and manage them in IPA while user accounts come from AD is a crucial next step. Thank you for your feedback, it was very helpful but I'm afraid it might also caused some new questions. = Design = In Ticket [https://fedorahosted.org/freeipa/ticket/3979 https://fedorahosted.org/freeipa/ticket/3979] two aspects of a design are already explained. # Instead of just offering a single override option the introduction of views are suggested. A suitable client can ask for a specific view with override options different from the default override view. Yes. Questions: #* Will the default view always be applied? I think it makes sense to always apply it to get a consistent default behavior. If there is a reason for a client to get the unmodified data a special view called e.g. NO_OVERRIDE can be used. This is e.g. needed for the extdom plugin to be able to send the raw data to the IPA client so that SSSD can use different views on the client which might be needed for docker/container use cases. Sounds reasonable to have the default view and apply it always. If the view does not contain posix attributes for the specific user we should use dynamic mapping based on SIDs. Quite some time ago we have decided to not mix algorithmic mapping and manually managed POSIX IDs. E.g. think about the case where a view with POSIX ID was added for an existing user which already has an algorithmic ID assigned on some clients. I think this is unfortunate but I can live with this though it is not best. If there is a workaround to have two trusts or two ranges associated with the forest with different mapping properties I am fine but we need to have that be clearly explain on a page because people were asking about this and I unfortunately gave them the wrong answer becuase I was not aware of the decision. IMO the decision seems contour intuitive to me. Here is the use cases that people explained to me: I had to put and manage my posix attributes in AD using third party solution. But as soon as I migrate to IPA I want the AD side of the company to stop managing posix attributes. I was under wrong assumption that though we do not have views now they can do what we ask by allowing the algorithmic mapping to kick in for new users. Frankly I do not see a reason why we can't assign posix attributes using algorithmic method if the posix attributes are not explicitly set. I can argue that this can be an optional fall back but it should be possible. I expect that there will be bugs filed about it as people try. We will see. I think the admin has to decide what he wants. He wants to use what he already has from AD but then use other mappings on top. Since we do not provide views yet the only expected option is to fall back to algorithmic mapping. Below you mentioned a migration use case where old users should keep their IDs but new users will get algorithmically generated ones. I think this is bad practice and technically is it next to impossible without additional admin effort to decide if a given AD user is an old or a new user. May
Re: [Freeipa-devel] Ipa-server-install Firewall Support
On 04/16/2014 08:39 AM, Martin Kosek wrote: On 04/16/2014 09:56 AM, Justin Brown wrote: ... L: This is interesting, and I have a couple of questions on how this should work. 1) Is there an actual use-case when a tool actually would want to check status of a port without correcting it? It seems to me that any sort of is_port_open() call that returned False would be immediately followed by open_port(). If that's the case, then why not just roll them into one operation? There won't be any firewall reload if no modifications take place, so there's no cost to combining them. We could also find a middle ground where there's only one method with a default parameter open_port(..., auto_add=True). I can imagine situations when we would want to see if a port is open in a firewall and then ask user if he wants to automatically open it. In such cases, 2 separate calls would be indeed helpful. 2) Will these tools be executed as root? To query NM and FirewallD, I have to connect to the system bus, which by default, won't allow access from other users without additional authorization. If non-privileged users need to query the firewall configuration, I'll need to look at the DBus policy more closely. In situations when we are about to manipulate ports, I think it is safe to assume we are operating under root account. I think you can have this assumption in your current code and do not deal with additional authorization at this point. We can think about this case when we need it. 3) Could you point me at a similar tool that has this check and modify behavior? There are many situations in FreeIPA interactive wizards where we have a pattern do_action = check_something() if do_action: do_something() For example, ipa-adtrust-install is checking if there are any users without SID assigned and if there are, it offers to run a task to add them. Martin +1 on all -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ 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
think overriding UIDs/GIDs should only be allowed for ipa-ad-trust-posix idranges, mixing override with algorithmic mapping does not make sense imo. I think it does at least for the migration time. But it might not be achievable. The idea is that you really should be required to manage UID/GID for the users manually via views if it is an old user. If it is a new user that never was on the Linux side before the algorithmic mapping might be preferred. But I also think that this should be controlled by a policy and admin would have to decide whether the IPA should generate UIDs or he would prefer to set the manually explicitly. # The views will be stored in containers below cn=views,cn=accounts,$SUFFIX with containers for users and groups. The objectclasses will look similar to posixAccount and posixGroup objectclasses but with only optional (MAY) attributes. Questions: #* Do we want to consider to allow to add arbitrary attributes to a view to cover requests like We have this beautiful application which can get all user data via the SSSD D-BUS responder but our AD admin will not extend the AD LDAP schema to add the required attributes. Can IPA add them for users from trusted domains? Yes but probably not as phase 1. So it is a separate enhancement. #* It was suggested to use a UUID to reference the original objects. For AD users and groups the SID would be a good choice because it is unique and already contains a reference to the original domain. I wonder if we should add a type prefix like 'SID:' to be able to add other types like 'IPAUUID:domref:ef2b7400-a3c4-11e3-82e7-525400de2951' where domref will be a reference to the other IPA domain. On the other hand a type can be added later and if the type is missing a SID is assumed. On the SSSD side the views can be stored below the corresponding user or group object in the cache and the SYSDB API has to be enhanced to return merged results. The merging only happens in the responders (NSS, D-BUS) before sending data to the clients. Why SSSD should know about different views? It should know raw and not raw but it always sees one merged view from the server. What am I missing? To manage the views a new set CLI tools/Web UI pages should be added. Depending if we would like to allow to override IPA users as well or only users from trusted domains the tools might get their own name space, ipa override-*, or can be added below the trust name space, ipa trust-override-*. It has to be noted that changes of a view will only be visible on the client after the related cached object is expired. OK. = Implementation = See comments above. I hope they give enough hints for implementation. At least for the first pass. =Feature Management = == UI == == CLI == = Major configuration options and enablement = Any configuration options? Any commands to enable/disable the feature or turn on/off its parts? = Replication = Any impact on replication? = Updates and Upgrades = Any impact on updates and upgrades? = Dependencies = Any new package and library dependencies. = External Impact = Impact on other development teams and components = Backup and Restore = Any files or configuration that needs to be taken care of in backup or restore procedure. = Test Plan = Test scenarios that will be transformed to test cases for FreeIPA Continuous Integration during implementation or review phase. = RFE Author = [[User:Sbose|Sumit Bose]] ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Random Certificate Serial Numbers
On 04/08/2014 09:55 AM, Ade Lee wrote: On Mon, 2014-04-07 at 09:48 +0200, Martin Kosek wrote: Hi Rob, Ade and others, In the past, Rob was investigating enabling random certificate serial numbers for FreeIPA PKI [1]. We also have a ticket [2] planned to enable it for 4.0. Can we simply switch it on for PKI with pkispawn attribute: [CA] pki_random_serial_numbers_enable=True Putting in this parameter in pkispawn means changing the method of assigning serial numbers for the CA that is being installed (ie. a new master) Thus this will affect new masters only. When the CA is cloned, it will inherit its method of assigning serial numbers from the master. I need to check the code to see what happens if you specify the above directive in pkispawn for a clone. Are you considering changing the serial number assignment for existing masters? No or is there any drawback or risk we should investigate. I am just thinking, does PKI handle collisions anyhow? When for example two PKI masters generate 2 certificates of the same serial (unlikely though it could happen)? Collisions are not supposed to happen. Range number assignment is automatically managed so that different masters are assigned different ranges so that collisions cannot happen. Collisions can occur if ranges overlap -- ie. if you are manually updating ranges and end up using overlapping ranges. Currently, we assign different slice of serial range to different PKI masters, do we want to do that also for random serial? Yes. Range management is done automatically. Different masters are assigned different ranges to prevent collisions. Random serial numbers will be generated within the assigned range. Thanks for info [1] http://dogtagpki.org/wiki/Random_Certificate_Serial_Numbers [2] https://fedorahosted.org/freeipa/ticket/2016 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Ipa-server-install Firewall Support
On 04/08/2014 02:42 PM, Rob Crittenden wrote:
Justin Brown wrote:
Dmitri,
I'd be more than happy to, but I'm having trouble figuring out where
it should go. Could you send me a link to a similar design page?
I'd put it under here: http://www.freeipa.org/page/V4_Proposals
There is a template at http://www.freeipa.org/page/Feature_template
So maybe something like http://www.freeipa.org/page/V4/Firewalld
Rob has beaten me to it, sorry.
I reviewed the page.
Pretty informative, thank you.
Couple comments:
a) No replication impact.
b) Example: freeipa-server-install --setup-dns --forwarder=192.168.0.2
--forwarder=192.168.0.3
I think you want to add the --firewall at the end
c) Please be consistent in one place you use freeipa-.. in other just
ipa-.. but this is minor
d) No commands or config options.
e) It would be really nice to have a bit more information about what
kind of methods and calls you plan to use to interact with
NetworkManager and FirewallD. If you can spell out something like:
Logic:
Call NM and get blah using method X
For each port in the list
call FirewallD method Y
f) What would be error handling if something goes wrong? Would it abort
or create a special message?
g) How should it behave if some ports are already open? Will it print a
message or do it silently?
h) There is actually impact on restore, restore might also now check
that ports are configured in the same way they have been.
i) We should probably also record in the rollback log the ports that
have been opened and close them back if we have to roll back
installation or uninstall server.
j) We should differentiate whether the CA is being installed and open CA
ports only if the CA component is there.
k) We are planning to add other components like DRM and TPS We need to
figure out if we would have to do something on the upgades when we add
those services to add additional ports.
l) I suspect that there be cases where different tools and scripts in
IPA would need to check and open ports. This means that we should
probably create a reusble library that would provide check and update
methods.
This is so far what came to mind.
Thanks for doing it!
Really appreciated.
Dmitri
rob
Thanks,
Justin
On Mon, Apr 7, 2014 at 6:51 PM, Dmitri Pal d...@redhat.com wrote:
On 04/07/2014 09:00 AM, Rob Crittenden wrote:
Simo Sorce wrote:
On Fri, 2014-04-04 at 09:59 +0200, Petr Spacek wrote:
On 4.4.2014 09:17, Martin Kosek wrote:
On 04/04/2014 09:04 AM, Justin Brown wrote:
I would actually do it the opposite way and open the ports
after the
FreeIPA server is fully configured. After all, I do not think
we want to
open the ports when the server is just half-configured and for
example some
ACIs are missing.
My thinking was that nothing would be listening on these ports
if the
install doesn't succeed, but there's really necessity to modify
the
firewall configuration early. (All of the internal install
communication will be over a local interface (to netfilter) and
unblock anyways. I don't have any problem in delaying firewall
configuration to the end of install.
If ipa-server-install does succeed without configuring the
firewalld,
then we
will indeed have no other option than to do it early.
I am thinking that we may want to put all the firewalld
configuration
in
ipaserver/install/firewalldinstance.py,
and then make the firewalld configuration the actual step of the
installation.
Something like:
...
Configuring Firewall (firewalld)
[1/2]: looking up the right zone
[2/2]: allowing ports
Done configuring Firewall (firewalld).
...
The Service class derived object can be really simple, we would
just
reuse the
functionality it already has + let us properly hook into it in
ipa-{server,replica}-install and the uninstallation.
It would also make it easier to split this functionality to
freeipa-server-firewalld if we chose to in a future.
In general I agree with the idea, thank you Justin for working on
that!
I would like to emphasis the necessity to work without
NetworkManager
and
FirewallD. New dependencies make Debian folks unhappy ...
On the other hand, it is perfectly fine to skip firewall
configuration
if
NM/FirewallD/DBus is not available.
Have a nice day!
Should be easy, probe for the dbus firewalld service and just skip
(not
error out) if it is not there.
Set a variable in that case that will cause the installer to throw
the
classic banner we have now which warns you about what ports need
to be
opened at the end of the install.
Probably just need to spit out a large, preferably flashing warning
that
the firewall has not been automatically configured. Perhaps even
multiple
times: one in-line and one at the install summary at the end.
rob
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Thanks for looking into this!
Would it be possible
Re: [Freeipa-devel] global account lockout
On 04/07/2014 02:31 PM, Simo Sorce wrote: On Mon, 2014-04-07 at 10:22 -0600, Rich Megginson wrote: On 04/07/2014 10:13 AM, Simo Sorce wrote: On Mon, 2014-04-07 at 12:10 -0400, Simo Sorce wrote: On Mon, 2014-04-07 at 12:01 -0400, Simo Sorce wrote: On Mon, 2014-04-07 at 11:26 -0400, Rob Crittenden wrote: Ludwig Krispenz wrote: Hi, please review the following feature design. It introduces a global account lockout, while trying to keep the replication traffic minimal. In my opinion for a real global account lockout the basic lockout attributes have to be replicated otherwise the benefit is minimal: an attacker could perform (maxFailedcount -1) login attempts on every server before the global lockout is set. But the design page describes how it could be done if it should be implemented - maybe the side effect that accounts could the be unlocked on any replica has its own benefit. http://www.freeipa.org/page/V4/Replicated_lockout One weakness with this is there is still a window for extra password attempts if one is clever, (m * (f-1))+1 to be exact, where m is the number of masters and f is the # of allowed failed logins. Yes, but that is a problem that cannot be solved w/o full replication at every authentication attempt. What we tried to achieve is a middle ground to at least ease administration and still lock em up earlier. Let me add that we could have yet another closer step by finding a way to replicate only failed attempts and not successful attempts in some case. Assuming a setup where most people do not fail to enter their password it would make for a decent compromise. That could be achieved by not storing lastsuccessful auth except when that is needed to clear failed logon attempts (ie when the failed logon counter is 0) If we did that then we would not need a new attribute actually, as failed logins would always be replicated. However it would mean that last Successful auth would never be accurate on any server. Or perhaps we could have a local last successful auth and a global one by adding one new attribute, and keeping masking only the successful auth. The main issue about all these possibilities is how do we present them ? And how do we make a good default ? I think a good default is defined by these 2 characteristics: 1. lockouts can be dealt with on any replica w/o having the admin hunt down where a user is locked. 2. at least successful authentications will not cause replication storms If we can afford to cause replications on failed authentication by default, then we could open up replication for failedauth and failedcount attributes but still bar the successful auth attribute. Unlock would simply consist in forcibly setting failed count to 0 (which is replicated so it would unlock all servers). This would work w/o introducing new attributes and only with minimal logic changes in the KDC/pwd-extop plugins I think. Sigh re[plying again to myself. note that the main issue with replicating failed accounts is that you can cause replication storms by simply probing all user accounts with failed binds or AS requests. In some environments that may cause DoSs (if you have slow/high latency links on which replication runs for example). So I think we should always give the option to turn off failed date/count attributes replication, which in turn would mean we still require a new attribute to replicate for when a user is finally locked out on one of the servers or we fail requirement 1. Simo. Another problem with keeping track of bind attributes in a replicated environment is the sheer size of the replication metadata. Replicating 1 failed bind attempt might be 100kbytes or more data to all servers. We should have a way to perhaps say only keep last N CSNs or maybe even don't keep CSNs for these attributes. Yes, but this look a lot like general replication improvement (would also be cool to have better conflict resolution), not lockout specific. Simo. My only comment is actually about conflict resolution. What would happen if I attack (flood) two replicas at the same time beating the replication. It would mean both servers would generate the global attributes and try to replicate to each other. If the replicas are on the edges of topology it might take some time and it might even happen that admin already unlocked the account while the old lock is still trying to propagate. IMO we need collisions resolution logic taken care of first. I suspect that any real attack would lead to collisions and if it would leave the deployment unstable even after the attack ended we lost. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Add DRM to IPA
On 04/04/2014 02:50 PM, Ade Lee wrote: This patch adds the capability of installing a Dogtag DRM to an IPA instance. With this patch, when ipa-server-install is run, a Dogtag CA and a Dogtag DRM are created. The DRM shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. It is also possible to clone the DRM. When the IPA instance is cloned, if --enable-ca and --enable-drm are specified, the DRM is cloned as well. Installing a DRM requires the user to have a Dogtag CA instance. We can look into possibly relaxing that requirement in a later patch. I am still working on patches for a ipa-drm-install script, which would be used to add a DRM to an existing master (that includes a dogtag CA), or an existing clone. Please review, Thanks, Ade Any takers? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Ipa-server-install Firewall Support
On 04/07/2014 09:00 AM, Rob Crittenden wrote:
Simo Sorce wrote:
On Fri, 2014-04-04 at 09:59 +0200, Petr Spacek wrote:
On 4.4.2014 09:17, Martin Kosek wrote:
On 04/04/2014 09:04 AM, Justin Brown wrote:
I would actually do it the opposite way and open the ports after
the FreeIPA server is fully configured. After all, I do not think
we want to open the ports when the server is just half-configured
and for example some ACIs are missing.
My thinking was that nothing would be listening on these ports if the
install doesn't succeed, but there's really necessity to modify the
firewall configuration early. (All of the internal install
communication will be over a local interface (to netfilter) and
unblock anyways. I don't have any problem in delaying firewall
configuration to the end of install.
If ipa-server-install does succeed without configuring the
firewalld, then we
will indeed have no other option than to do it early.
I am thinking that we may want to put all the firewalld
configuration in
ipaserver/install/firewalldinstance.py,
and then make the firewalld configuration the actual step of the
installation.
Something like:
...
Configuring Firewall (firewalld)
[1/2]: looking up the right zone
[2/2]: allowing ports
Done configuring Firewall (firewalld).
...
The Service class derived object can be really simple, we would
just reuse the
functionality it already has + let us properly hook into it in
ipa-{server,replica}-install and the uninstallation.
It would also make it easier to split this functionality to
freeipa-server-firewalld if we chose to in a future.
In general I agree with the idea, thank you Justin for working on that!
I would like to emphasis the necessity to work without
NetworkManager and
FirewallD. New dependencies make Debian folks unhappy ...
On the other hand, it is perfectly fine to skip firewall
configuration if
NM/FirewallD/DBus is not available.
Have a nice day!
Should be easy, probe for the dbus firewalld service and just skip (not
error out) if it is not there.
Set a variable in that case that will cause the installer to throw the
classic banner we have now which warns you about what ports need to be
opened at the end of the install.
Probably just need to spit out a large, preferably flashing warning
that the firewall has not been automatically configured. Perhaps even
multiple times: one in-line and one at the install summary at the end.
rob
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Thanks for looking into this!
Would it be possible to summarize this thread in a design page on the wiki?
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Random Certificate Serial Numbers
On 04/07/2014 03:48 AM, Martin Kosek wrote: Hi Rob, Ade and others, In the past, Rob was investigating enabling random certificate serial numbers for FreeIPA PKI [1]. We also have a ticket [2] planned to enable it for 4.0. Can we simply switch it on for PKI with pkispawn attribute: [CA] pki_random_serial_numbers_enable=True or is there any drawback or risk we should investigate. I am just thinking, does PKI handle collisions anyhow? When for example two PKI masters generate 2 certificates of the same serial (unlikely though it could happen)? Currently, we assign different slice of serial range to different PKI masters, do we want to do that also for random serial? Thanks for info [1] http://dogtagpki.org/wiki/Random_Certificate_Serial_Numbers [2] https://fedorahosted.org/freeipa/ticket/2016 Any impact on upgrades? Any impact on certmonger? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] emerging standard for hosts/passwords policy/automount/netgroups in LDAP
On 03/13/2014 04:40 AM, Petr Spacek wrote: Hello list, FYI I have come across following RFC drafts: (please start with the first one :-) http://www.ietf.org/id/draft-bannister-dbis-mapping-03.txt http://tools.ietf.org/html/draft-bannister-dbis-passwd-02 http://www.ietf.org/id/draft-bannister-dbis-policy-03.txt http://tools.ietf.org/html/draft-bannister-dbis-netgroup-02 http://tools.ietf.org/html/draft-bannister-dbis-automounter-02 http://tools.ietf.org/html/draft-bannister-dbis-hosts-04 This is a bad idea to have hosts in LDAP. We already discussed it couple years ago. I didn't study them in detail but it seems like an attempt to standardize Directory User Agent (DUA) profiles for various things like automounter etc. Maybe we can contact the author and coordinate/harmonize what possible. +1 At first glance automount spec seems incompatible with RFC2307bis schema, maybe that is one of things we can discuss and try to solve. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC: upgrade path to Vault
On 03/11/2014 07:53 AM, Petr Spacek wrote: On 11.3.2014 12:21, Martin Kosek wrote: On 03/11/2014 11:33 AM, Petr Spacek wrote: On 10.3.2014 12:08, Martin Kosek wrote: On 03/10/2014 11:49 AM, Petr Spacek wrote: On 7.3.2014 17:33, Dmitri Pal wrote: I do not think it is the right architectural approach to try to fix a specific use case with one off solution while we already know that we need a key storage. I would rather do things right and reusable than jam them into the currently proposed release boundaries. I want to make clear that I'm not opposed to Vault in general. I'm questioning the necessity of Vault from the beginning because it will delay DNSSEC significantly. +1, I also now see number of scenarios where Vault will be needed. One of the proposals in this thread is to use something simple for DNSSEC keys (with few lines of Python code) and migrate DNSSEC with Vault when Vault is available and stable enough (in some later release). I understand that Vault brings a lot of work to the table. But let us do it right and if it does not fit into 4.0 let us do it in 4.1. We will have one huge release with DNSSEC + Vault at once if we to postpone DNSSEC to the same release as Vault. As a result, it would be harder to debug it because we will have to find if something is broken because of: - DNSSEC-IPA integration - Vault-IPA integration - DNSSEC-Vault integration. I don't think it is a good idea to make such huge release. Release early, release often I must say I tend to agree with Petr. If the poor man's solution of DNSSEC without Vault does not cost us too much time and it would seem that the Vault is not going to squeeze in 4.0 deadlines, I would rather release the poor man's solution in 4.0 and switch to Vault when it's available in 4.1. This would let our users test the non-Vault parts of our DNSSEC solution instead of waiting to test a perfect solution. Yesterday we have agreed that DNSSEC support is not going to depend on Vault from the beginning and that we can migrate to Vault later. Here I'm proposing safe upgrade path from non-vault to Vault solution. After all, it seems relatively easy. TL;DR version = Use information in cn=masters to detect if there are old replicas and temporarily convert new keys from Vault to LDAP storage (until all old replicas are deleted). Full version IPA 4.0 is going to have OpenDNSSEC key generator on a single IPA server and separate key import/export daemon (i.e. script called from cron or something like that) on all IPA servers. In 4.0, we can add new LDAP objects for DNSSEC-related IPA services (please propose better names :-): - key generator: cn=OpenDNSSECv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example cn=DNSSEC,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example DNSSEC will be translated by FreeIPA to appropriate service name. This can vary between platforms. v1 can be an attribute of the entry, I would not add it's to name. - key imported/exporter: cn=DNSSECKeyImporterv1,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example I am thinking it may be sufficient to have just: cn=DNSSEC,cn=vm.example.com,cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example for all DNSSEC empowered masters and then just have: ipaConfigString: keygenerator ... in the master VM. I am just trying to be future agnostic and avoid hardcoding service names and implementations details in cn=masters. FreeIPA on master would know what services to run when it is a keygenerator or not. Initial state before upgrade: - N IPA 4.0 replicas - N DNSSECKeyImporterv1 service instances (i.e. key distribution for IPA 4.0) - 1 OpenDNSSECv1 service instance (key generator) Now we want to upgrade a first replica to IPA 4.1. For simplicity, let's add a *requirement* to upgrade the replica with OpenDNSSECv1 first. (We can generalize the procedure if this requirement is not acceptable.) Upgrade procedure: - stop OpenDNSSECv1 service - stop DNSSECKeyImporterv1 service - convert OpenDNSSECv1 database to OpenDNSSECv2 This step is not related to Vault. We need to covert local SQLite database from single-node OpenDNSSEC to LDAP-backed distributed OpenDNSSEC. - convert private keys from LDAP to Vault *but let them in LDAP for a while*. - walk through cn=masters,cn=ipa,cn=etc,dc=ipa,dc=example and check if there are any other replicas with DNSSECKeyImporterv1 service: In my proposal, one would just search for cn=DNSSEC,cn=*,cn=masters... with filter (ipaConfigString=version 1). Why not :-) I do not care as long as it is unambiguous. a) No such replica exists - delete old-fashioned keys from LDAP. b) Another replica with DNSSECKeyImporterv1 service exists: - *Temporarily* run DNSSECKeyImporterv2 which will do one-way key conversion from Vault to LDAP. - DNSSECKeyImporterv2 can check e.g. daily if all DNSSECKeyImporterv1 instances were deleted or not. Then it can delete old
Re: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope
On 03/11/2014 11:29 AM, Massimiliano Perrone wrote: Hi guys, I hope to explain in a few words what we are doing with ConnID and IPA. Comments in-line. On 03/10/2014 10:57 PM, Dmitri Pal wrote: On 03/10/2014 03:14 PM, Petr Viktorin wrote: On 03/10/2014 07:17 PM, Dmitri Pal wrote: On 03/10/2014 08:24 AM, Petr Viktorin wrote: On 03/07/2014 04:39 PM, Marco Di Sabatino Di Diodoro wrote: Hi all, Il giorno 03/feb/2014, alle ore 11:41, Francesco Chicchiriccò ilgro...@apache.org mailto:ilgro...@apache.org ha scritto: On 31/01/2014 18:57, Dmitri Pal wrote: On 01/31/2014 08:17 AM, Francesco Chicchiriccò wrote: [...] I am actually not sure if it is lightweight connector could actually be better than a loaded connector (e.g. without proxy), from a deployment point of view, unless you are saying either that (a) a smart proxy is already available that can be reused The idea can be reused as a starting point. IMO the easiest would be to look at the patches and use same machinery but implement different commands. or that (b) incorporating the smart proxy that we are going to develop into FreeIPA will easily happen. ^ quote left here deliberately [...] We start to implementing a FreeIPA ConnId connector for Apache Syncope. We have to implement all identity operations defined by the ConnId framework. I would like to know the implementation status of the Smart/Proxy and if we can use it to all the identity operations. I'm reviewing the Foreman Smart proxy patches now. They're not in the FreeIPA repository yet. However the remaining issues were with packaging, code organization, naming. The Smart Proxy is now specific to Foreman provisioning; it is not a full REST interface so it will probably not support all operations you need. For a full REST interface, patches are welcome but the core FreeIPA team has other priorities at the moment. The RFE ticket is here: https://fedorahosted.org/freeipa/ticket/4168. For user provisioning you do not need a full REST api. You need to have a similar proxy but just for user related operations. So the smart proxy can be used as a model to do what you need to implement for Syncope integration. You'd be building two bridges (IPA--REST REST--ConnID) when you could build just one. Unless you already have a suitable generic REST connector already, I don't think it's your best option. From this thread it seems to me that JSON-RPC--ConnID would not require significantly more work than just the REST--ConnID part. What are the operations you need to implement? Can you list them? They were listed earlier in the thread, and [5]. It is usually easy to take something that is already working like smart proxy and change the entry points to the ones that you need. I am not familiar with the architecture of the connectors. Are they separate processes? Are they daemons? Are they forked per request? Connection to IPA needs to be authenticated. If the connection to IPA happens from a single process like smart proxy you do not need to worry about machinery related to authentication and session managment. It is already implemented. This is why I was suggesting to use smart proxy. IMO REST vs. JSON is not that big deal. They are similar. Doing things right from the authentication POV and session management are much harder. But if we do not see a value in using smart proxy even like a reference point for ConnID I would not insist. Basically a ConnID bundle (ConnID is framework used by Apache Syncope to connect the external resources) is a Java library developed to invoke the following operations from Apache Syncope to the target resource: AUTHENTICATE CREATE UPDATE UPDATE_ATTRIBUTE_VALUES DELETE RESOLVE_USERNAME SCHEMA SEARCH SYNC TEST For example, ConnID already has an Active Directory bundle [9] and an LDAP bundle [10]. As you already know, our goal is to develop a new bundle to invoke the provisioning operations on IPA server installation. From ConnID development point of view, the first thing is to choose a right way (to read protocol/interfaces) to communicate with the server. Briefly the right way needs: *) a long term support interfaces; *) an interfaces that allows all user / group provisioning operations; *) a way which leaves ConnID developers totally independent from (in this case) the FreeIPA development. Starting from this introduction we think that the right way is to use JSON-RPC interfaces, with particular attention to authentication and session management, as suggested by you. Do we have to consider other critical factors before starting to work? This seems reasonable. Here are some other questions that you might want to ask yourself starting the work. http://www.freeipa.org/page/General_considerations (there is no intent to scare you :-) ) HTH Dmitri Massi Otherwise, we will instead specialize the CMD connector [12] to feature the FreeIPA command-line interface (as suggested at the beginning
Re: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope
On 03/10/2014 08:24 AM, Petr Viktorin wrote: On 03/07/2014 04:39 PM, Marco Di Sabatino Di Diodoro wrote: Hi all, Il giorno 03/feb/2014, alle ore 11:41, Francesco Chicchiriccò ilgro...@apache.org mailto:ilgro...@apache.org ha scritto: On 31/01/2014 18:57, Dmitri Pal wrote: On 01/31/2014 08:17 AM, Francesco Chicchiriccò wrote: Are you saying that we should split our development in two: (1) smart proxy, exposing the RESTful interface, developed on the basis of [8] (2) actual ConnId connector, dealing with the proxy above for implementing its own logic Correct If so, could you please point to the source code of [8]? Will then this eventually become part of FreeIPA? Quite soon. I would leave it to the team to suggest whether user and host provisioning smart proxies should be a same smart proxy or different so that they can be installed independently from each other but use the same approach. IMO haveing them separately but share the same code and approach will be more valuable to the project. But I am open to other ideas here. I am actually not sure if it is lightweight connector could actually be better than a loaded connector (e.g. without proxy), from a deployment point of view, unless you are saying either that (a) a smart proxy is already available that can be reused The idea can be reused as a starting point. IMO the easiest would be to look at the patches and use same machinery but implement different commands. or that (b) incorporating the smart proxy that we are going to develop into FreeIPA will easily happen. If done right: i.e. following process and style then yes. Please become familiar with the coding style [9] page on the wiki and other contributer guidelines [10]. Also having a design page created as a result of the preliminary investigation would go a long way towards acceptance and quality of the feature. We will gladly guide you on the way if you have specific questions [...] Ok then, we'll do it as follows. We are currently experimenting with FreeIPA, to get familiar with technology and options; once we will be confident enough to start the actual work on the connector, we will check the status of the smart proxy patches from [11]. If the implementation status will be close to be ready and about to be included in the official distribution, we will follow the suggestions above and develop a REST-based connector. We start to implementing a FreeIPA ConnId connector for Apache Syncope. We have to implement all identity operations defined by the ConnId framework. I would like to know the implementation status of the Smart/Proxy and if we can use it to all the identity operations. I'm reviewing the Foreman Smart proxy patches now. They're not in the FreeIPA repository yet. However the remaining issues were with packaging, code organization, naming. The Smart Proxy is now specific to Foreman provisioning; it is not a full REST interface so it will probably not support all operations you need. For a full REST interface, patches are welcome but the core FreeIPA team has other priorities at the moment. The RFE ticket is here: https://fedorahosted.org/freeipa/ticket/4168. For user provisioning you do not need a full REST api. You need to have a similar proxy but just for user related operations. So the smart proxy can be used as a model to do what you need to implement for Syncope integration. What are the operations you need to implement? Can you list them? Otherwise, we will instead specialize the CMD connector [12] to feature the FreeIPA command-line interface (as suggested at the beginning of this thread). There will be potentially need, in this case, to include the ConnId connector server into the Syncope deployment architecture, but this is a supported pattern. Have you looked at JSON-RPC interface mentioned earlier in this thread, and [6]? It might be cleaner to use that than the command-line interface. [1] http://syncope.apache.org/ [2] http://tirasa.github.io/ConnId/ [3] http://java.net/projects/identityconnectors/ [4] https://github.com/Tirasa/ConnIdFreeIPABundle [5] http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html [6] https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html [7] http://www.freeipa.org/page/Documentation [8] http://www.freeipa.org/page/V3/Smart_Proxy -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope
On 03/10/2014 03:14 PM, Petr Viktorin wrote: On 03/10/2014 07:17 PM, Dmitri Pal wrote: On 03/10/2014 08:24 AM, Petr Viktorin wrote: On 03/07/2014 04:39 PM, Marco Di Sabatino Di Diodoro wrote: Hi all, Il giorno 03/feb/2014, alle ore 11:41, Francesco Chicchiriccò ilgro...@apache.org mailto:ilgro...@apache.org ha scritto: On 31/01/2014 18:57, Dmitri Pal wrote: On 01/31/2014 08:17 AM, Francesco Chicchiriccò wrote: [...] I am actually not sure if it is lightweight connector could actually be better than a loaded connector (e.g. without proxy), from a deployment point of view, unless you are saying either that (a) a smart proxy is already available that can be reused The idea can be reused as a starting point. IMO the easiest would be to look at the patches and use same machinery but implement different commands. or that (b) incorporating the smart proxy that we are going to develop into FreeIPA will easily happen. ^ quote left here deliberately [...] We start to implementing a FreeIPA ConnId connector for Apache Syncope. We have to implement all identity operations defined by the ConnId framework. I would like to know the implementation status of the Smart/Proxy and if we can use it to all the identity operations. I'm reviewing the Foreman Smart proxy patches now. They're not in the FreeIPA repository yet. However the remaining issues were with packaging, code organization, naming. The Smart Proxy is now specific to Foreman provisioning; it is not a full REST interface so it will probably not support all operations you need. For a full REST interface, patches are welcome but the core FreeIPA team has other priorities at the moment. The RFE ticket is here: https://fedorahosted.org/freeipa/ticket/4168. For user provisioning you do not need a full REST api. You need to have a similar proxy but just for user related operations. So the smart proxy can be used as a model to do what you need to implement for Syncope integration. You'd be building two bridges (IPA--REST REST--ConnID) when you could build just one. Unless you already have a suitable generic REST connector already, I don't think it's your best option. From this thread it seems to me that JSON-RPC--ConnID would not require significantly more work than just the REST--ConnID part. What are the operations you need to implement? Can you list them? They were listed earlier in the thread, and [5]. It is usually easy to take something that is already working like smart proxy and change the entry points to the ones that you need. I am not familiar with the architecture of the connectors. Are they separate processes? Are they daemons? Are they forked per request? Connection to IPA needs to be authenticated. If the connection to IPA happens from a single process like smart proxy you do not need to worry about machinery related to authentication and session managment. It is already implemented. This is why I was suggesting to use smart proxy. IMO REST vs. JSON is not that big deal. They are similar. Doing things right from the authentication POV and session management are much harder. But if we do not see a value in using smart proxy even like a reference point for ConnID I would not insist. Otherwise, we will instead specialize the CMD connector [12] to feature the FreeIPA command-line interface (as suggested at the beginning of this thread). There will be potentially need, in this case, to include the ConnId connector server into the Syncope deployment architecture, but this is a supported pattern. Have you looked at JSON-RPC interface mentioned earlier in this thread, and [6]? It might be cleaner to use that than the command-line interface. [1] http://syncope.apache.org/ [2] http://tirasa.github.io/ConnId/ [3] http://java.net/projects/identityconnectors/ [4] https://github.com/Tirasa/ConnIdFreeIPABundle [5] http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html [6] https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html [7] http://www.freeipa.org/page/Documentation [8] http://www.freeipa.org/page/V3/Smart_Proxy -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 03/05/2014 11:06 AM, Simo Sorce wrote: On Wed, 2014-03-05 at 16:29 +0100, Martin Kosek wrote: On 03/05/2014 03:04 PM, Simo Sorce wrote: On Wed, 2014-03-05 at 13:05 +0100, Martin Kosek wrote: On 03/04/2014 11:14 PM, Petr Spacek wrote: On 4.3.2014 22:53, Simo Sorce wrote: On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote: On 4.3.2014 22:15, Simo Sorce wrote: On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: ... I guess my only reservation is about whether DRM storage is replicated or not. Although both the K/M and DNS cases do not require the Vault to be online at all times because the keys will be downloaded and stored locally and only needs to be accessed when they changed, there is the problem of having all keys in a SPOF, that should not happen. According to http://www.freeipa.org/page/V4/Password_Vault#Replication the replication is available for DRM, we just need to use it. IMHO a vault without replication is not useful anyway. Users are not happy when their passwords disappear ;-) The additional thing about the Vault is that we can use key escrow there as a mechanism to re-encrypt automatically system relevant keys when a new server is joined to the realm. So we agree that Vault offers what we want so we should use it, right? I think we should determine if we can use Vault for K/M. It would be another reason why we should use Vault instead of a custom solution. Do we really want to use the heavy machinery Vault for DNSSEC keys? I would personally like to avoid it and use something more lightweight. Vault seems to me as a too heavy requirement for FreeIPA server with DNS. It needs Tomcat and all the Java machinery, special installation, replication scheme, difficult debugging etc. In my mind, Vault is a specialized heavy component that solves specific problems that not every admin may want and thus may cause a lot of grief to such admins who just want CA-less FreeIPA and DNS(SEC). Well keep in mind that you do not need a vault instance on every DNS server, just like a CA a few servers would be sufficient. DNS key rotation happens relatively 'rarely' so the dependency is not a huge problem in terms of performance or management. There is the problem of the heavyweight java-based infrastructure, but we already have that dependency for the CA part, so it's not like we are adding anything new. Yeah, but the plan is not force people to have the heavy weight Java infrastructure on each server so that they are able to create more lightweight servers only with components they choose: https://fedorahosted.org/freeipa/ticket/4058 Yes, but the Vault does not need to be installed on each server, just on a couple of them like for the CA. In particular it doesn't need to be installed on the same servers that offer the DNS service. Simo. I agree with Simo. From the big picture perspective we have more and more use cases when Vault becomes a requirement: a) Storing passwords for users - initial case b) Storing volume keys for Cinder - OpenStack - Barbican use case c) Storing passwords for external cloud provider accounts - deltacloud/Manage IQ use case d) Storing DNSSEC keys - your use case e) Storing private keys for users - classical PKI escrow the DRM was built for f) Storing private SSH key - there is a ticket for that kind of escrow functionality too. For me it is apparent that vault will be a default component. It is not as heavy weight now as it used to be. All Dogtag components can share same tomcat instance so if you have a CA on the system your incremental impact is very small. So what we need is: a) Solve the problem of the DRM install. Single server work was done by Rob. Ade will be able to take it over and hel;p with the DRM install across several servers (with replication). b) There is REST API for Vault it requires certificate authentication for now. No Kerberos. We can probably live without Kerberos for now since SSSD has host cert. c) We need to hook some kind of access control that would allow specifying policies about who can fetch which keys (this is regardless where they are stored Vault or LDAP) I do not think it is the right architectural approach to try to fix a specific use case with one off solution while we already know that we need a key storage. I would rather do things right and reusable than jam them into the currently proposed release boundaries. I understand that Vault brings a lot of work to the table. But let us do it right and if it does not fit into 4.0 let us do it in 4.1. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC design page: key wrapping
that would allow masters to transfer keys to each other w/o exposing them as LDAP searches, do we want to try to go in that direction ? Simo. Should we consider vault as a storage for these keys too? It already supports recovery of the symmetric and asymmetric keys so may be these keys should be stored there? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] GSS-Proxy - TPM - PKCS#11 (silly idea)
On 03/04/2014 11:08 AM, Petr Spacek wrote: On 16.2.2014 13:22, Simo Sorce wrote: On Fri, 2014-02-14 at 14:51 +0100, Petr Spacek wrote: Hello, I have got an silly idea to use TPM (Trusted Platform Module) as backend for Keytab storage (via GSS-Proxy). GSS-Proxy prevents application from accessing key material, right? So GSS-Proxy could theoretically store keys in TPM and application wouldn't notice any difference, right? We have libraries for that in Fedora already: https://admin.fedoraproject.org/pkgdb/acls/name/trousers Even sillier idea is to use TPM as a PKCS#11 module: http://trousers.sourceforge.net/pkcs11.html I have no idea what the use case could be ... :-) May be as a cache for PKCS#11 module in SSSD? As I said, it is just a silly idea. Open a ticket in the GSS-Proxy trac :) Is it a good topic for bachelor/master thesis? We are going to send list of topics for next year so we have a chance to add it. We are not going to touch this any time soon so it sounds like a good idea to me. I am not sure. Sounds like a lot of work with questionable results... -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 03/04/2014 11:25 AM, Petr Spacek wrote: On 4.3.2014 17:00, Dmitri Pal wrote: On 03/04/2014 10:26 AM, Simo Sorce wrote: On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: On 26.2.2014 16:00, Simo Sorce wrote: need to be protected as carefully as the private key. This is something I meant to discuss too, how do we protect them ? Clearly we have ACIs but I am wondering if we want to encrypt them with keys not immediately or easily available via LDAP ? It's kind of catastrofic if they get inadvertently exposed like if someone does a ldapsearch as Directory Manager, which is one of the reasons why we encrypt kerberos key material before storing it into the db. PKCS#8 allows encryption, I guess we can use that. There needs to be some metadata on how to decrypt the blob though, so that the PKCS#11 module can actually decrypt it when necessary. Yep, and we also need to decide what master key is used and where it is placed, and who access it, and how:-) Let's move the discussion forward, we need to implement the schema for 4.0. Do I understand correctly that the whole purpose of krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example is just to encrypt keys with some other key which is located at some other place? I.e. the goal is to lower the probability that a random ldapsearch will return encrypted blob and master key at once, right? Yes, it would also be nice if we could finally offload this key from LDAP for added security, but we are not there yet. What algorithm/method should we use for key wrapping? As far as I remember from my studies key wrapping is very sensitive thing and we definitely need to use some existing standardtool for doing it. Can we just call some NSS function with default/system-wide parameters and let it do it's job? I think that would be what we want to do in some form. That would mean that, after all, we just need to provide some blob as key wrapping key :-) (Generated with care it deserves etc.) The key must be self describing somehow (for algorithm agility). We have had discussion with Honza and the first idea is to add attribute like 'wrappingKeyId' to each encrypted blob and use it for locating appropriate key when necessary. - During decryption: Do a LDAP search with filter like (keyId=wrappingKeyId) to find appropriate wrapping key. - The harder part is how to pick a wrapping key for encryption. It can be tricky if the wrapped key is shared among more users (DNS servers) etc. - It is possible to easily use multiple wrapping keys at once so key rollover is easy. You can re-encrypt keys one by one. This makes things complicated fast. One thing I was thinking was to use a keytab and krb functions to do the wrapping but that would be pretty IPA specific. The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 objects inside the same token will be encrypted with the same key. - Decryption is easy - the same as in previous case. - Encryption is basically the same as encryption. - Key rollover is hard. You would have to re-encrypt all keys and change wrappingKeyId associated with given token at once - but it is impossible because we don't have LDAP transactions. As a result, clients will be confused during rollover. (Consider problems with syncrepl when clients can see changes immediately.) Yeah this is a problem we need to address. The third approach is 'hybrid': A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is used for encrypting new objects stored into PKCS#11 token. Each key stored in the token has own wrappingKeyId attribute and it is used for decryption. - Decryption is easy - the same as in previous case. - Encryption always use wrappingKeyId associated with given token. - Key roll over can start from wrappingKeyId associated with the token and then re-encrypt keys in the token one by one. All keys can be decrypted in any step (assuming that changes in one LDAP object are atomic). Where is a hole in this design? :-) I do not like the idea of having to add a wrappingKeyId everywhere. My initial though was to have a central place where wrapping keys are stored, and during a rollover period you try all the keys until one works or decryption fails. At the end of rollover you delete the old key so you avoid the additional load. Where should we store wrapping keys for users/services and DNS servers? User object or cn=dns doesn't sound like a good idea because it would defeat the purpose. Indeed. And this is the biggest problem. It would be nice to have a mechanism to securely transfer the key to the DNS servers w/o having to store it permanently in LDAP. If we had this mechanism we'd be able to apply it to the Kerberos master key too. But it can't be confined to installation time only, which is easy, it needs to be possible to update it at a later time, which is where we have issues, as our replication mechanism is LDAP. If we solve
Re: [Freeipa-devel] GSS-Proxy - TPM - PKCS#11 (silly idea)
On 03/04/2014 11:40 AM, Petr Spacek wrote: On 4.3.2014 17:25, Dmitri Pal wrote: On 03/04/2014 11:08 AM, Petr Spacek wrote: On 16.2.2014 13:22, Simo Sorce wrote: On Fri, 2014-02-14 at 14:51 +0100, Petr Spacek wrote: Hello, I have got an silly idea to use TPM (Trusted Platform Module) as backend for Keytab storage (via GSS-Proxy). GSS-Proxy prevents application from accessing key material, right? So GSS-Proxy could theoretically store keys in TPM and application wouldn't notice any difference, right? We have libraries for that in Fedora already: https://admin.fedoraproject.org/pkgdb/acls/name/trousers Even sillier idea is to use TPM as a PKCS#11 module: http://trousers.sourceforge.net/pkcs11.html I have no idea what the use case could be ... :-) May be as a cache for PKCS#11 module in SSSD? As I said, it is just a silly idea. Open a ticket in the GSS-Proxy trac :) Is it a good topic for bachelor/master thesis? We are going to send list of topics for next year so we have a chance to add it. We are not going to touch this any time soon so it sounds like a good idea to me. I am not sure. Sounds like a lot of work with questionable results... I thought that it is purpose of thesis? :-) Now seriously: We are not doing research with questionable results because we don't have time for it - I perfectly understand that. That is the reason why I'm proposing such crazy ideas for theses. My hesitation is related to the satisfaction from the work being done by a student. We have many topics that we know we need for the project and taking them (and implementing right) would be beneficial for the project and rewarding for the student. With this idea I am concerned that since there is no clear drive for it to be needed there might not be enough motivation to make is usable for the project. But I might be wrong. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Client-side command in the IPA framework
On 03/04/2014 02:03 PM, Nathaniel McCallum wrote: On Mon, 2014-03-03 at 20:12 -0500, Dmitri Pal wrote: On 03/01/2014 10:07 PM, Adam Young wrote: On 02/28/2014 10:21 AM, Petr Viktorin wrote: On 02/28/2014 04:15 PM, Alexander Bokovoy wrote: On Fri, 28 Feb 2014, Nathaniel McCallum wrote: On Fri, 2014-02-28 at 16:43 +0200, Alexander Bokovoy wrote: On Fri, 28 Feb 2014, Nathaniel McCallum wrote: On Fri, 2014-02-28 at 10:47 +0100, Petr Vobornik wrote: On 28.2.2014 04:02, Rob Crittenden wrote: Alexander Bokovoy wrote: On Thu, 27 Feb 2014, Nathaniel McCallum wrote: So the recent discussion on importing tokens led me to write a script to parse RFC 6030 xml files into IPA token data. This all works well. But now I need to integrate it into the IPA framework. This command will parse one or more xml files, creating a set of tokens to be added. Given that we already have otptoken-add on the server-side, it seems to me that all work needs to be done on the client-side. How do I create a new client-side command that calls existing server-side API? subclass from frontend.Local, override run() or forward() method and perform batch operation of otptoken_add from there. See cli.help, for example. If you do an override, do forward() for cli-specific work. But you should do as little as possible for reasons you already stated: the UI. Anything you do in forward Petr will need to implement in the UI. Unfortunately we don't yet have a nice way to handle files. We have tickets open at https://fedorahosted.org/freeipa/ticket/1225 and https://fedorahosted.org/freeipa/ticket/2933 If this file is something that would be pasted into a big text field then you can probably handle it in a similarly clumsy way that we do CSRs in the cert plugin. rob +1 for parsing it on server. Otherwise every client, not just CLI or Web UI, would have to reimplement the same logic - having it on server will support better integration with third party products. Parsing on client would be understandable if there was some middle step which would require some action from user, i.e, pick only some tokens to import. If we parse on the server side, how do we handle the long-running operation? Think of the case of importing hundreds or thousands of tokens... Why then to do it as a IPA CLI command at all? This is an administrative task which can be done with a separate ipa-otp-import command, designated to run on IPA masters. Agreed. 1. Is there a framework for this? Or should it just be an independent script? We don't really have a framework for administrative tools. You may start with install/tools/ipa-adtrust-install, it is main part is relatively independent of the task (which is in ipaserver/install/adtrustinstance.py) The framework is there, new tools use it, and there's a ticket to convert old ones: https://fedorahosted.org/freeipa/ticket/2652 (it's low priority in Future Releases, so not much progress is there...) Also see http://www.freeipa.org/page/V3/Logging_and_output The RESTful approach would be: 1. Upload a file to a specific URL (not JSON RPC) 2. Receive back a 202 Accepted HTTP Request, to include an URL to poll for status Not certain the right response from the URL in step 2 would be, but I am assuming it would be 200 with the body of the message stating: processing or completed. It would be really nice if the Batch command could be handled this way as well. The response back could be the partial responses until processing is complete. It might also be nice to supply an email address for notification of completed processing instead of polling, if it is going to be a really long running task. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Yes I think that: 1) We should not limit it to server side operation only 2) Upload the whole file and then process it. 3) We should already have code to upload files, we did it for entitlements and were supposed to use for certs. 4) Make sure we have a generic upload mechanism that reads a chunk of a configurable size and asks for more (pagination by 65K might be a good default). Regarding token files specifically: they can be big but not super huge. 10-20K tokens makes sense but probably not more. More than that would be a real corner case becuase it is hard to deploy that amount of tokens at the same time. It can take months and you do not want token file to contain many tokens that would sit on the shelf. Tokens expire so it is inefficient to buy huge chunks and let them sit unused. UI you allow uploading file too and then would process it locally. The processing of the file should generate a log or report. It would be nice to get indication from the server that it is still working so may be upload protocol should be something like: client: Initialize the transfer server: ready client: here is the chunk of data server: ack
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 03/04/2014 04:53 PM, Simo Sorce wrote: On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote: On 4.3.2014 22:15, Simo Sorce wrote: On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: On 4.3.2014 20:48, Simo Sorce wrote: On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote: On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote: On 4.3.2014 17:43, Dmitri Pal wrote: On 03/04/2014 11:25 AM, Petr Spacek wrote: On 4.3.2014 17:00, Dmitri Pal wrote: On 03/04/2014 10:26 AM, Simo Sorce wrote: On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: On 26.2.2014 16:00, Simo Sorce wrote: need to be protected as carefully as the private key. This is something I meant to discuss too, how do we protect them ? Clearly we have ACIs but I am wondering if we want to encrypt them with keys not immediately or easily available via LDAP ? It's kind of catastrofic if they get inadvertently exposed like if someone does a ldapsearch as Directory Manager, which is one of the reasons why we encrypt kerberos key material before storing it into the db. PKCS#8 allows encryption, I guess we can use that. There needs to be some metadata on how to decrypt the blob though, so that the PKCS#11 module can actually decrypt it when necessary. Yep, and we also need to decide what master key is used and where it is placed, and who access it, and how:-) Let's move the discussion forward, we need to implement the schema for 4.0. Do I understand correctly that the whole purpose of krbPrincipalName=K/M@IPA.EXAMPLE,cn=IPA.EXAMPLE,cn=kerberos,dc=ipa,dc=example is just to encrypt keys with some other key which is located at some other place? I.e. the goal is to lower the probability that a random ldapsearch will return encrypted blob and master key at once, right? Yes, it would also be nice if we could finally offload this key from LDAP for added security, but we are not there yet. What algorithm/method should we use for key wrapping? As far as I remember from my studies key wrapping is very sensitive thing and we definitely need to use some existing standardtool for doing it. Can we just call some NSS function with default/system-wide parameters and let it do it's job? I think that would be what we want to do in some form. That would mean that, after all, we just need to provide some blob as key wrapping key :-) (Generated with care it deserves etc.) The key must be self describing somehow (for algorithm agility). We have had discussion with Honza and the first idea is to add attribute like 'wrappingKeyId' to each encrypted blob and use it for locating appropriate key when necessary. - During decryption: Do a LDAP search with filter like (keyId=wrappingKeyId) to find appropriate wrapping key. - The harder part is how to pick a wrapping key for encryption. It can be tricky if the wrapped key is shared among more users (DNS servers) etc. - It is possible to easily use multiple wrapping keys at once so key rollover is easy. You can re-encrypt keys one by one. This makes things complicated fast. One thing I was thinking was to use a keytab and krb functions to do the wrapping but that would be pretty IPA specific. The other idea is to add 'wrappingKeyId' to PKCS#11 token. So all PKCS#11 objects inside the same token will be encrypted with the same key. - Decryption is easy - the same as in previous case. - Encryption is basically the same as encryption. - Key rollover is hard. You would have to re-encrypt all keys and change wrappingKeyId associated with given token at once - but it is impossible because we don't have LDAP transactions. As a result, clients will be confused during rollover. (Consider problems with syncrepl when clients can see changes immediately.) Yeah this is a problem we need to address. The third approach is 'hybrid': A 'wrappingKeyId' associated with PKCS#11 token is 'the active one' and is used for encrypting new objects stored into PKCS#11 token. Each key stored in the token has own wrappingKeyId attribute and it is used for decryption. - Decryption is easy - the same as in previous case. - Encryption always use wrappingKeyId associated with given token. - Key roll over can start from wrappingKeyId associated with the token and then re-encrypt keys in the token one by one. All keys can be decrypted in any step (assuming that changes in one LDAP object are atomic). Where is a hole in this design? :-) I do not like the idea of having to add a wrappingKeyId everywhere. My initial though was to have a central place where wrapping keys are stored, and during a rollover period you try all the keys until one works or decryption fails. At the end of rollover you delete the old key so you avoid the additional load. Where should we store wrapping keys for users/services and DNS servers? User object or cn=dns doesn't sound like a good idea because it would defeat the purpose. Indeed. And this is the biggest problem. It would be nice to have a mechanism to securely transfer the key to the DNS servers
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 03/04/2014 05:14 PM, Petr Spacek wrote: On 4.3.2014 22:53, Simo Sorce wrote: On Tue, 2014-03-04 at 22:38 +0100, Petr Spacek wrote: On 4.3.2014 22:15, Simo Sorce wrote: On Tue, 2014-03-04 at 21:25 +0100, Petr Spacek wrote: On 4.3.2014 20:48, Simo Sorce wrote: On Tue, 2014-03-04 at 14:19 -0500, Simo Sorce wrote: On Tue, 2014-03-04 at 19:14 +0100, Petr Spacek wrote: On 4.3.2014 17:43, Dmitri Pal wrote: On 03/04/2014 11:25 AM, Petr Spacek wrote: On 4.3.2014 17:00, Dmitri Pal wrote: On 03/04/2014 10:26 AM, Simo Sorce wrote: On Tue, 2014-03-04 at 13:51 +0100, Petr Spacek wrote: Where should we store wrapping keys for users/services and DNS servers? User object or cn=dns doesn't sound like a good idea because it would defeat the purpose. Indeed. And this is the biggest problem. It would be nice to have a mechanism to securely transfer the key to the DNS servers w/o having to store it permanently in LDAP. If we had this mechanism we'd be able to apply it to the Kerberos master key too. But it can't be confined to installation time only, which is easy, it needs to be possible to update it at a later time, which is where we have issues, as our replication mechanism is LDAP. If we solve the DNA plugin issue with the ability to use groups for authentication I guess we could build a control/extend operation that would allow masters to transfer keys to each other w/o exposing them as LDAP searches, do we want to try to go in that direction ? Simo. Should we consider vault as a storage for these keys too? It already supports recovery of the symmetric and asymmetric keys so may be these keys should be stored there? Maybe. The question is if we want to support DNSSEC without Dogtag ... Without Dogtag? Vault would be an independent component from CA I assume, though CA might be needed anyways to issue transport keys for the internal components. But I think that even if we use Vault as an internal password and key storage I do not see a reason why we can't require it for DNSSEC. Why over-complicate things if we already have components that can be used? If we see a requests to support DNSSEC without Vault component we will adjust but I do not think we should limit ourselves in the first implementation. I'm personally fine with that. Are we going to re-prioritize Password Vault from Backlog to 4.0? https://fedorahosted.org/freeipa/ticket/3872 We need that in 4.0 timeframe for DNSSEC otherwise you need to convince Simo that key wrapping is not necessary :-) For 4.0 we could document that you have to copy the keys around manually. And add Vault support in 4.1 ? It could work ... Can we modify ipa-replica-prepare in 4.0 to add the wrapping key to replica file to make it easier? Can the vault approach work for Kerberos master key? If not, shouldn't we design something universal instead of deferring it again and again? We can use the same method for the M/K, now that the CA is installed before the rest we do not have a chicken-egg issue anymore. Another problem is that the PKCS#11 LDAP schema was designed as application-independent but now we are adding very specific key-wrapping mechanism (it is hard to believe that somebody else will implement it). It could be optional. Maybe we can add something like attribute 'pkcs11keyWrapMech': - key is not wrapped if it is not present - key is wrapped if it is present - value determines used mechanism (mandatory mechanism to implement is only 'none') What is 'none' ? I mean 'attribute is not present'. The only unknown here is who adds a new wrapper wen a new server is up and it publishes the public key in LDAP. For existing servers they can re-wrap themselves. It's a few layers but should not be too hard. I don't fully understand to your proposal but I'm afraid that it will not work for ordinary IPA users. Don't forget that we want to have universal PKCS#11 storage usable even for private SSH keys and other stuff. Well ... TBH I am not really that hot about storing private keys in IPA like that, however for people that want to do it they can simply store them not encrypted as you proposed above. Please correct me if I'm wrong. You are right, but I was caring for the DNS keys case, not the user's ssh key case, which is hairy IMHO. There is no difference between DNSSEC keys and any other keys except the fact that we need shared wrapping key for DNSSEC. Nothing else. Note that SSH private key is just an example. You can use PKCS#11 as storage for user certificates used for authentication in Firefox etc. I think the private ssh key case is a clear job for the Vault the fact sssd might use a pkcs#11 interface to present it to ssh, or the user simply pulls it to the local file system is, in my view, an implementation detail. I can see a huge difference. Properly implemented PKCS#11 provides you the same separation as GSS-Proxy for keytabs. I.e. non-root process will not be able to extract any
Re: [Freeipa-devel] Client-side command in the IPA framework
On 03/04/2014 02:27 PM, Nathaniel McCallum wrote: On Tue, 2014-03-04 at 14:11 -0500, Dmitri Pal wrote: On 03/04/2014 02:03 PM, Nathaniel McCallum wrote: On Mon, 2014-03-03 at 20:12 -0500, Dmitri Pal wrote: On 03/01/2014 10:07 PM, Adam Young wrote: On 02/28/2014 10:21 AM, Petr Viktorin wrote: On 02/28/2014 04:15 PM, Alexander Bokovoy wrote: On Fri, 28 Feb 2014, Nathaniel McCallum wrote: On Fri, 2014-02-28 at 16:43 +0200, Alexander Bokovoy wrote: On Fri, 28 Feb 2014, Nathaniel McCallum wrote: On Fri, 2014-02-28 at 10:47 +0100, Petr Vobornik wrote: On 28.2.2014 04:02, Rob Crittenden wrote: Alexander Bokovoy wrote: On Thu, 27 Feb 2014, Nathaniel McCallum wrote: So the recent discussion on importing tokens led me to write a script to parse RFC 6030 xml files into IPA token data. This all works well. But now I need to integrate it into the IPA framework. This command will parse one or more xml files, creating a set of tokens to be added. Given that we already have otptoken-add on the server-side, it seems to me that all work needs to be done on the client-side. How do I create a new client-side command that calls existing server-side API? subclass from frontend.Local, override run() or forward() method and perform batch operation of otptoken_add from there. See cli.help, for example. If you do an override, do forward() for cli-specific work. But you should do as little as possible for reasons you already stated: the UI. Anything you do in forward Petr will need to implement in the UI. Unfortunately we don't yet have a nice way to handle files. We have tickets open at https://fedorahosted.org/freeipa/ticket/1225 and https://fedorahosted.org/freeipa/ticket/2933 If this file is something that would be pasted into a big text field then you can probably handle it in a similarly clumsy way that we do CSRs in the cert plugin. rob +1 for parsing it on server. Otherwise every client, not just CLI or Web UI, would have to reimplement the same logic - having it on server will support better integration with third party products. Parsing on client would be understandable if there was some middle step which would require some action from user, i.e, pick only some tokens to import. If we parse on the server side, how do we handle the long-running operation? Think of the case of importing hundreds or thousands of tokens... Why then to do it as a IPA CLI command at all? This is an administrative task which can be done with a separate ipa-otp-import command, designated to run on IPA masters. Agreed. 1. Is there a framework for this? Or should it just be an independent script? We don't really have a framework for administrative tools. You may start with install/tools/ipa-adtrust-install, it is main part is relatively independent of the task (which is in ipaserver/install/adtrustinstance.py) The framework is there, new tools use it, and there's a ticket to convert old ones: https://fedorahosted.org/freeipa/ticket/2652 (it's low priority in Future Releases, so not much progress is there...) Also see http://www.freeipa.org/page/V3/Logging_and_output The RESTful approach would be: 1. Upload a file to a specific URL (not JSON RPC) 2. Receive back a 202 Accepted HTTP Request, to include an URL to poll for status Not certain the right response from the URL in step 2 would be, but I am assuming it would be 200 with the body of the message stating: processing or completed. It would be really nice if the Batch command could be handled this way as well. The response back could be the partial responses until processing is complete. It might also be nice to supply an email address for notification of completed processing instead of polling, if it is going to be a really long running task. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Yes I think that: 1) We should not limit it to server side operation only 2) Upload the whole file and then process it. 3) We should already have code to upload files, we did it for entitlements and were supposed to use for certs. 4) Make sure we have a generic upload mechanism that reads a chunk of a configurable size and asks for more (pagination by 65K might be a good default). Regarding token files specifically: they can be big but not super huge. 10-20K tokens makes sense but probably not more. More than that would be a real corner case becuase it is hard to deploy that amount of tokens at the same time. It can take months and you do not want token file to contain many tokens that would sit on the shelf. Tokens expire so it is inefficient to buy huge chunks and let them sit unused. UI you allow uploading file too and then would process it locally. The processing of the file should generate a log or report. It would be nice to get indication from the server that it is still working so may be upload protocol should
Re: [Freeipa-devel] DNSSEC design page: key wrapping
On 03/04/2014 05:30 PM, Petr Spacek wrote: On 4.3.2014 23:18, Dmitri Pal wrote: We need PKCS#11 for CA certificates, BIND and OpenDNSSEC anyway so we need to design schema for *public* data. All private data can be stored in Vault if we agree on that. Do we need it on the server and if so can it be exposed by the vault rather than via LDAP? We need standard PKCS#11 interface because applications like BIND and OpenDNSSEC do not care about IPA-specifics. However applications see only PKCS#11 interface and nothing else, there could be LDAP or some other protocol behind the API. Honza's plan is to integrate PKCS#11 module to SSSD somehow so it will be available on all client machines, it will use caching facilities, fail-over etc. Replying to the other thread to join both threads to one: Also about PKCS#11 interface. I am all for PKCS#11 interface for client exposed from SSSD that uses whatever means to fetch the central keys it being SSH keys, gnome keyring keys or something else. AFAIK that is exactly the plan. I do not see a reason for IPA to expose a remote PKCS#11 interface. If we need a remote PKCS#11 interface (please insert why here) then it should be a part of the vault API rather than anything else. I'm not sure that I understand... PKCS#11 is just a set of functions, for an application it is a library. An application just calls the PKCS#11 API and knows nothing about implementation details so there is nothing like 'remote PKCS#11'. As I said above, SSSD will be behind scenes. Everything is local except the data storage in LDAP or vault, it doesn't matter. Maybe I misunderstood you, sorry. Remote means that there is a PKCS#11 library that can be loaded into a process and would remotely connect to a central server via LDAP/REST/whatever. My point is that library should be light weight and always talk to a local service like SSSD rather than have a remote interface. In this case SSSD on the server can talk to the vault or IPA LDAP directly and all consumers would use PKCS#11 interface exposed by SSSD Something like this... -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Client-side command in the IPA framework
server: ack, (forks the file processing method that updates shared status data) come back in x seconds client: how are things? server: working, here is current status, come back in x seconds ... client: how are things? server: done, here is current status, have errors in a file client: start download server: here is the chunk ... I think we can short socket the command for now to fail if it is not local on the server and then build the upload mechanism but separate command as proposed in this thread would lock us in a local approach forever. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA 3.4 - 4.0
On 02/26/2014 09:46 AM, Petr Viktorin wrote: On 02/26/2014 12:24 PM, Martin Kosek wrote: Hello all, I would like to discuss a proposal that Simo had on FreeIPA devel meeting. Given permission/ACI refactoring that Petr3 is working on, people may have issues with access to their LDAP if they played too much with the default ACIs or if they expect that some information stays accessible in the new version. It may not stay accessible we are removing the SUFFIX level all allowing ACIs and creating custom read ACIs. Bottom line is we need to do our best in making our users aware that there are big changes in this version they need to be aware of. One way is to release a new major release with appropriate release notes. I support that move, I think we have enough big features planned to justify new major release: * Permissions/ACIs * OTP * DNSSEC (hopefully) * CA Certificate Management Tool * Big Web UI face lift and refactoring * ... If there is no push back against that idea, let's do it. I would then rename the 3.4 milestones to 4.0 and 3.5 milestones to 4.1. +1 I guess the http://www.freeipa.org/page/V3 tree will also need some renaming. I am concerned that it will do more harm than good but do not have valid arguments against. So +1 from me too. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Is there RPC documentation?
On 02/26/2014 05:48 PM, Simo Sorce wrote: On Wed, 2014-02-26 at 15:28 -0700, Rich Megginson wrote: On 02/26/2014 03:22 PM, Rob Crittenden wrote: Rich Megginson wrote: On 02/26/2014 02:19 PM, Rob Crittenden wrote: Rich Megginson wrote: On 02/26/2014 08:53 AM, Petr Viktorin wrote: On 02/26/2014 04:45 PM, Rich Megginson wrote: I'm working on adding support for freeipa DNS to openstack designate (DNSaaS). I am assuming I need to use RPC (XML? JSON? REST?) to communicate with freeipa. Is there documentation about how to construct and send RPC messages? The JSON-RPC and XML-RPC API is still not officially supported (read: documented), though it's extremely unlikely to change. If you need an example, run any ipa command with -vv, this will print out the request response. API.txt in the source tree lists all the commands and params. This blog post still applies (but be sure to read the update about --cacert): http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ Ok. Next question is - how does one do the equivalent of the curl command in python code? Here is a pretty stripped-down way to add a user. Other commands are similar, you just may care more about the output: from ipalib import api from ipalib import errors api.bootstrap(context='cli') api.finalize() api.Backend.xmlclient.connect() try: api.Command['user_add'](u'testuser', givenname=u'Test', sn=u'User', loginshell=u'/bin/sh') except errors.DuplicateEntry: print user already exists else: print User added How would one do this from outside of ipa? If ipalib is not available? You'd need to go to either /ipa/xml or /ipa/json (depending on what protocol you want to use) and issue one request there. This requires Kerberos authentication. The response will include a cookie which you should either ignore or store safely (like in the kernel keyring). Using the cookie will significantly improve performance. This is for the ipa dns backend for designate. I'm assuming I will either be using a keytab, or perhaps the new proxy? At any rate, I have to do everything in python - including the kinit with the keytab. Lok at rob's damon but you should *not* do a kinit, you should just use gssapi (see python-kerberos) and do a gss_init_sec_context there, if the environment is configured (KRB5_KTNAME set correctly) then gssapi will automatically kinit for you under the hood. Yes look at Rob's smart proxy and use a similar approach. I guess I'm really looking for specifics - I've seen recommendations to use the python libraries requests and json. I don't know if requests supports negotiate/kerberos. If not, is there a recommended library to use? As this particular project will be part of openstack, perhaps there is a more openstack-y library, or even something built-in to openstack (oslo?). I think amqp support kerberos, so perhaps there is some oslo.messaging thing that will do the http + kerberos stuff. Afaik there is nothing that does kerberos in openstack, you'll have to introduce all that stuff. HTH, Simo. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 531-541 OTP UI
On 02/26/2014 06:57 AM, Petr Vobornik wrote: On 26.2.2014 01:55, Dmitri Pal wrote: On 02/24/2014 10:21 AM, Nathaniel McCallum wrote: On Mon, 2014-02-24 at 15:48 +0100, Petr Vobornik wrote: On 24.2.2014 15:31, Nathaniel McCallum wrote: On Mon, 2014-02-24 at 11:04 +0100, Petr Vobornik wrote: On 21.2.2014 20:00, Nathaniel McCallum wrote: Is it possible to do something more intelligent for the key and date fields in the add-token UI? Date fields are currently just a text box. Is there any sort of calendar we could use here? If not, I'm still unsure of what the format should be for this field. It's the format you chose :), try to fill it in CLI, you will have the same proble. From API level it's just string, from LDAP it's generalized time. Is there a better option? I'm open to suggestions. As I mentioned below, it's being implemented. The datetime patches will be send separately. The core OTP UI patches should not be blocked by them. I've an UI patch prepared where you can write it in ISO format, with a validator attached to it, so user will be noticed about the format, but it's waiting for: https://www.redhat.com/archives/freeipa-devel/2014-January/msg00057.html https://www.redhat.com/archives/freeipa-devel/2014-January/msg00060.html The key field should probably have a note indicating that it is Base32 encoding. It would also be nice to restrict the input to Base32 characters. Maybe even automatic case correction... Actually I think it doesn't help much. Show me a person who can write base32 encoded string But I agree that a validator with some regex to limit the chars and a note that it should be base32 string is better. The question is what's the purpose of this field from user perspective. Is a human being suppose to fill it or is it meant to be only filled by some provisioning systems? In UI it's just as a backup? If there is a use case where user is suppose to choose the key, it would be better to fill the key and convert it to base32 string on a server. I can't think of any case where a user would use the key field. However, there are at least two important cases where an admin would do this: 1. Hardware tokens 2. Transferring OATH (TOTP/HOTP) tokens from another system Nathaniel What is the input format for these two cases? Is it base32 so admin can enter it into UI or is it plain text so he has to use different tool to encode it to base32 and then fill into UI? In both of the above cases, I suspect the predominant use will be scripts written to take a token store and import the tokens. This is mostly a non-UI case. RFC 6030 uses Base64 for unencrypted tokens. Base32 is also in wide use. This is largely because, with fewer characters and no case-sensitivity, Base32 is easier to type. I don't know of any other encodings in wide use. It would be nice to support both of them, but I'm not sure how this is possible. Suggestions are welcome. I do not think we should allow typing the key (and other attributes) manually. We should rather ask user to import a token or tokens from the XML file that uses RFC6030. There are vendors of the hardware tokens that actually using it to distribute the tokens. Here are the examples http://www.gooze.eu/howto/oath-otp-tokens-howto/seed-codes-sample-files Please click around the site for more info. This is one vendor. Do we have information that the other ones (or just the major ones) use the XML PSKC schema from RFC6030 as well? If that's the case, we have enough information for implementing otp-import (design page says that we don't have enough info). Back to UI. The UI might be useful if the admin has the values in different form than XML data, i.e., printed on a paper. Having the UI doesn't do any harm, right? If vendors mostly use base64 keys, adding only base32 support in our API doesn't make much sense. IMO it actually adds more work because you have to convert it first. Anyway: NACK for the patch because it shows totp/hotp switch in selfservice without possibility to define other hotp specifics. I'll remove it so there will be only totp in self-service (just token name+description). I think we need to take an inspiration in the LinOTP solution UI. See more details here: http://www.linotp.org/doc/2.6/part-management/managingtokens/import.html It loos like Alladin, SafeNet, Fetian have these tokens in XML. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC design page
On 02/25/2014 08:46 AM, Simo Sorce wrote: On Tue, 2014-02-25 at 11:08 +0100, Petr Spacek wrote: On 24.2.2014 20:20, Simo Sorce wrote: Also can you add some examples on how we would use these classes to store DNS keys ? We need to think about it a bit more. We plan to use PKCS#11 for key manipulation and data signing so the key itself will be unaware of any DNSSEC-specific attributes. DNSSEC-specifics could be in an auxiliary objectClass. I'm discussing this with CZ.NIC guys and they propose to add a 'layer of indirection' between DNS zones and keys so one key set can be used by more DNS zones. They claim that it is relatively common practice and I trust them. Note that I'm not saying that IPA should use one key for multiple DNS zones by default, but the schema should be future-proof and allow that if necessary. Makes sense. Let's start with this proposal: DNS zone: idnsname=dnssec.test, cn=dns, dc=example There will be multi-valued attribute idnsseckey pointing to DNs of keys stored somewhere else. Specifically for DNS, we could create sub-tree cn=dnsseckeys, cn=dns and store keys there. Ok, do we really want to have zones pointing at keys ? Or do we want keys have a list of zones they are supposed to apply to ? If we plan to store DNS keys in one place and other keys in other places in the tree (no common key store) then it really does not matter much. It should be derived from the LDAP searches that would need to be conducted by the software. We need keys for signing, right? Any other use case? If for signing we will start with a zone and would need to find keys that are relevant to this zone. It seems that having a generic key class + auxiliary class that would keep metadata about the key, its expiration and DN it applies to would be a way to go. So it seems that I agree with Simo that it would make sense to have the zone the key applies to specified in the key entry rather than in the zone entry. I expect that PKCS#11 module will handle keys scattered over the LDAP tree somehow. Sure as long as it can understand what the keys are for. Ideally the example would show the LDAP tree and some example data in detail, and also what operation we think would be common. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 531-541 OTP UI
On 02/24/2014 10:21 AM, Nathaniel McCallum wrote: On Mon, 2014-02-24 at 15:48 +0100, Petr Vobornik wrote: On 24.2.2014 15:31, Nathaniel McCallum wrote: On Mon, 2014-02-24 at 11:04 +0100, Petr Vobornik wrote: On 21.2.2014 20:00, Nathaniel McCallum wrote: Is it possible to do something more intelligent for the key and date fields in the add-token UI? Date fields are currently just a text box. Is there any sort of calendar we could use here? If not, I'm still unsure of what the format should be for this field. It's the format you chose :), try to fill it in CLI, you will have the same proble. From API level it's just string, from LDAP it's generalized time. Is there a better option? I'm open to suggestions. As I mentioned below, it's being implemented. The datetime patches will be send separately. The core OTP UI patches should not be blocked by them. I've an UI patch prepared where you can write it in ISO format, with a validator attached to it, so user will be noticed about the format, but it's waiting for: https://www.redhat.com/archives/freeipa-devel/2014-January/msg00057.html https://www.redhat.com/archives/freeipa-devel/2014-January/msg00060.html The key field should probably have a note indicating that it is Base32 encoding. It would also be nice to restrict the input to Base32 characters. Maybe even automatic case correction... Actually I think it doesn't help much. Show me a person who can write base32 encoded string But I agree that a validator with some regex to limit the chars and a note that it should be base32 string is better. The question is what's the purpose of this field from user perspective. Is a human being suppose to fill it or is it meant to be only filled by some provisioning systems? In UI it's just as a backup? If there is a use case where user is suppose to choose the key, it would be better to fill the key and convert it to base32 string on a server. I can't think of any case where a user would use the key field. However, there are at least two important cases where an admin would do this: 1. Hardware tokens 2. Transferring OATH (TOTP/HOTP) tokens from another system Nathaniel What is the input format for these two cases? Is it base32 so admin can enter it into UI or is it plain text so he has to use different tool to encode it to base32 and then fill into UI? In both of the above cases, I suspect the predominant use will be scripts written to take a token store and import the tokens. This is mostly a non-UI case. RFC 6030 uses Base64 for unencrypted tokens. Base32 is also in wide use. This is largely because, with fewer characters and no case-sensitivity, Base32 is easier to type. I don't know of any other encodings in wide use. It would be nice to support both of them, but I'm not sure how this is possible. Suggestions are welcome. I do not think we should allow typing the key (and other attributes) manually. We should rather ask user to import a token or tokens from the XML file that uses RFC6030. There are vendors of the hardware tokens that actually using it to distribute the tokens. Here are the examples http://www.gooze.eu/howto/oath-otp-tokens-howto/seed-codes-sample-files Please click around the site for more info. Nathaniel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy
On 02/21/2014 11:09 AM, Martin Kosek wrote: On 02/21/2014 04:37 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 02/17/2014 04:57 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 02/17/2014 04:13 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 02/17/2014 02:33 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 02/17/2014 01:21 PM, Rob Crittenden wrote: Martin Kosek wrote: On 02/14/2014 11:26 PM, Dmitri Pal wrote: +1, this was exactly my goal. It is easy to name and organize things now, difficult to do when it is live upstream and/or integrated with Foreman. I think the key for the right naming is a fact if this is really specific to Foreman or it is a truly general design usable also in other use cases. If Foreman-specific, I would go with freeipa-server-smartproxy-host or similar. If general, we can go with freeipa-server-proxy-host freeipa-server-proxy-user freeipa-server-proxy-dhcp The proxies may share the framework and only expose the requested part of the tree - which in advance gives you an option for an API separation, as compared to general freeipa-server-smartproxy. I still don't get the point of this. Are you proposing having 3 different servers, each providing a unique service? Or one service that one can turn on/off features, or something else? Do you envision this as 3 separate subpackages? There is no framework in my current patch, it is a cherrypy server that exposes parts of IPA on a given URI. It is the thinnest of layers. Then it seems to make sense to have 3 different packages that can be optionally coninstalled and would probably share the same principal, keytab and local REST API socket/port. Well, what you are designing is a central framework with plugins. What I designed is a quick-and-dirty get something up quickly. We need to pick one. The plugable method is going to require a fair bit of rework, though it will potentially pay dividends in the future. I think that we can start where you are but drive towards this architecture via refactoring. But we need to pick the right name now. Even if the architecture is not there yet we should name the package in such way that it does not preclude us from moving towards a clean architecture I described during the next iteration. Just having a hard time seeing the value. This would be like making each of the IPA plugins a separate package and somehow installing them individually. To do this you'd need at least 2 packages, a high level one with the framework and then a separate one for each data type. This could also be achieved, and likely more cleanly, without all these extra packages, as a simple configuration file. Once a package, always a package. Maybe I'm too close to the problem, but to me this is a Foreman-specific solution. The smartproxy is a Foreman creation, I don't know that anything else is using it. If you want a RESTful server, then we enable REST in IPA directly, but selectively enabling and disabling APIs is not something we've done before. It has been controlled by ACIs instead. rob We are trying to predict future here. Say we release it as you suggest. Tomorrow we point someone upstream who wants to add users to IPA from a similar proxy to this implementation and say use this as a model. And then Rich needs the same but for DNS for Designate. What would be the best? Rob if you knew that tomorrow two other developers will create similar proxies for users and DNS would you change anything? Would you provide some guidelines to them? If you are close to the problem you should be able to at least tell them: copy and paste vs. add more APIs to the same proxy. If your recommendation is copy and paste then I suspect there will be challenges of running these proxies on the same machine - they will collide on ports and sockets. If we say extend shouldn't we use a more generic name? I'd say use the existing IPA API. The only reason we have to write the smartproxy at all is to interoperate with another service that already has a well-defined remote server API which uses REST. rob OK, so you think that proxy is one off. OK I am fine with it. I was under assumption that it would be a beginning of a trend but I might be wrong as I do not have valid arguments to prove or disprove one way or another. I guess time would show. Any objections to Rob's approach? Ok, so try to summarize this long-running thread, I'll rename the subpackage to freeipa-server-foreman-smartproxy to make it clearer what it is/does. Right now it requires manual configuration so having the package installed should have no negative impacts (other than potentially pulling in additional dependencies). I'll leave it in smartproxy for now, it's just cleaner and better integrates with ipatests IMHO. Ok, sounds reasonable to me. Foreman supports SSL client auth which is great, by cherrypy does not yet. There is a pull request to add this, https://bitbucket.org/cherrypy/cherrypy/pull-request/15/added-support-for-client-certificate/activity
Re: [Freeipa-devel] [freeipa] #4185: Index plugin namespaces by classes
On 02/21/2014 06:31 AM, Petr Viktorin wrote: On 02/20/2014 08:00 PM, Dmitri Pal wrote: On 02/20/2014 12:57 PM, Petr Viktorin wrote: On 02/20/2014 06:47 PM, Dmitri Pal wrote: On 02/20/2014 12:39 PM, freeipa wrote: #4185: Index plugin namespaces by classes -+- Reporter: pviktori |Owner: pviktori Type: refactoring | Status: new Priority: major|Milestone: 0.0 Component: IPA | NEEDS_TRIAGE Resolution: | Version: Blocked By: | Keywords: Affects Documentation: 0| Blocking: Red Hat Bugzilla: | Patch posted for review: 0 Design link: | External tracker: Fedora test page: | Needs UI design: Source: | Feature: |Expertise: -+- Release Notes: -+- Comment (by pviktori): It's very easy to enable this so I'd like to do that now, and adapt the rest of the code whenever it's touched. Should it be captured in some guidelines somewhere on the wiki? I was planning to add some instructions to the [Refactorings] page, as I did with the new way to register plugins. I'm open to other suggestions. [Refactorings] http://www.freeipa.org/page/V3/Refactorings If we have some do and do not's it should be similar to Style guide but rather developer best practices guide. It should be a quick reference of: do not do X do Y instead like do not treat DN as string - use DN class ... use this notation instead of that notation etc. Then we can point people to it as part of the review process. Aye sir! http://www.freeipa.org/page/Coding_Best_Practices Linked from http://www.freeipa.org/page/Contribute/Code#Change_the_code Thank you, Sir! -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [freeipa] #4185: Index plugin namespaces by classes
On 02/20/2014 12:39 PM, freeipa wrote: #4185: Index plugin namespaces by classes -+- Reporter: pviktori |Owner: pviktori Type: refactoring | Status: new Priority: major|Milestone: 0.0 Component: IPA | NEEDS_TRIAGE Resolution: | Version: Blocked By: | Keywords: Affects Documentation: 0| Blocking: Red Hat Bugzilla: | Patch posted for review: 0 Design link: | External tracker: Fedora test page: | Needs UI design: Source: | Feature: |Expertise: -+- Release Notes: -+- Comment (by pviktori): It's very easy to enable this so I'd like to do that now, and adapt the rest of the code whenever it's touched. Should it be captured in some guidelines somewhere on the wiki? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Reviewer in Trac
On 02/20/2014 08:15 AM, Martin Kosek wrote: On 02/20/2014 02:02 PM, Petr Spacek wrote: On 20.2.2014 13:31, Sumit Bose wrote: On Thu, Feb 20, 2014 at 01:14:50PM +0100, Martin Kosek wrote: We had a discussion with other developers how better track who is reviewing which patch. Recently, we introduced the Reviewed-By tag in a commit message, but that is a post-review tag which is not useful for someone who wants to know which patches are already reviewed and which are not reviewed. We were testing Patch Work [1] in last months to contain this information, but I personally think that it is suboptimal - it introduces 2 tracking tools that needs to be maintained (Trac and Patch Work) and the Patch Work still requires lot of manual actions when maintaining it's state. I think it would be better to hold this information rather in a single tracking tool - Trac. There are 2 options: 1) Patch on review flag, similar to Patch posted for review flag which would hold 1 bit information if the patch is just lying there or has somebody assigned. 2) Reviewed by text field which would hold a login of a person who is reviewing it. It would be filled either by a person starting the review or by a supervisor like me to forcefully assign a reviewer ;-) +1 is it possible to instruct trac to send an email to the reviewer to let him know the he's the chosen one? I guess this would help to even better integrate with the workflow of many developers? It is definitely good idea! +1 As always - this is a good idea. However, the execution is an integral part of a successful idea :) And in this case I am not sure how to do it in Trac. I tried looking for different notification or workflow plugin but did not find something applicable to our Trac - ideas welcome. A workaround for me is to fill both reviewer + CC when assigning a reviewer or also by adding a My Active Patch Reviews by Milestone view. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel I am currently subscribed to all changes happening in trac. IMO what can be done is: a) You can subscribe to the notifications to or I can help with that b) Setup your mail filter to detect that the value of the field changed and has your name in it Then you will end up with the folder that has notifications that are relevant to only you being a reviewer. It is not going to be 100% clean but would work for 99% of the cases. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [freeipa] #4185: Index plugin namespaces by classes
On 02/20/2014 12:57 PM, Petr Viktorin wrote: On 02/20/2014 06:47 PM, Dmitri Pal wrote: On 02/20/2014 12:39 PM, freeipa wrote: #4185: Index plugin namespaces by classes -+- Reporter: pviktori |Owner: pviktori Type: refactoring | Status: new Priority: major|Milestone: 0.0 Component: IPA | NEEDS_TRIAGE Resolution: | Version: Blocked By: | Keywords: Affects Documentation: 0| Blocking: Red Hat Bugzilla: | Patch posted for review: 0 Design link: | External tracker: Fedora test page: | Needs UI design: Source: | Feature: |Expertise: -+- Release Notes: -+- Comment (by pviktori): It's very easy to enable this so I'd like to do that now, and adapt the rest of the code whenever it's touched. Should it be captured in some guidelines somewhere on the wiki? I was planning to add some instructions to the [Refactorings] page, as I did with the new way to register plugins. I'm open to other suggestions. [Refactorings] http://www.freeipa.org/page/V3/Refactorings If we have some do and do not's it should be similar to Style guide but rather developer best practices guide. It should be a quick reference of: do not do X do Y instead like do not treat DN as string - use DN class ... use this notation instead of that notation etc. Then we can point people to it as part of the review process. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] OpenSSH with PKCS#11 for key storage
On 02/19/2014 01:49 PM, Petr Spacek wrote: Hello list, I just came across this page: http://www.gooze.eu/howto/using-openssh-with-smartcards/using-ssh-authentication-agent-ssh-add-with-smartcards If I understand correctly, it allows you to store use your personal SSH keys via PKCS#11 interface. It sounds like a killer feature to me! Imagine that you can log-in to any machine in IPA realm and you will have all your SSH keys with you, without any extra work. This extends seamless SSO outside the enterprise (we have Kerberos for inside, this doesn't change that). Petr^2 Spacek P.S. It is natively supported in OpenSSH v5.4p1 - we have PKCS#11 support in Fedora 20 already. What are the implications for SSSD and IPA? What needs to be changed if anything? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH]Add -f option to ipactl
On 02/19/2014 11:58 AM, Adam Misnyovszki wrote: Hi, I reviewed this old patch: If an error occurs in the start up sequence in ipactl start/restart, all the services are stopped. Using the --force/-f option prevents stopping of services that have successfully started. https://fedorahosted.org/freeipa/ticket/3509 I have not read the code but looked at the patch and bug. I do not understand the -force option especially with help string being: If ipactl action fails, do not stop the services that are already running force usually means the reverse: if something did not happen force it to happen. I am not sure that --force option is the right name for the option with this help. Seems like fine to me. Thanks Adam ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH]Add -f option to ipactl
On 02/19/2014 03:13 PM, Petr Spacek wrote: On 19.2.2014 21:10, Dmitri Pal wrote: On 02/19/2014 11:58 AM, Adam Misnyovszki wrote: Hi, I reviewed this old patch: If an error occurs in the start up sequence in ipactl start/restart, all the services are stopped. Using the --force/-f option prevents stopping of services that have successfully started. https://fedorahosted.org/freeipa/ticket/3509 I have not read the code but looked at the patch and bug. I do not understand the -force option especially with help string being: If ipactl action fails, do not stop the services that are already running force usually means the reverse: if something did not happen force it to happen. I am not sure that --force option is the right name for the option with this help. I have proposed --no-rollback but it didn't fit to habits in IPA: https://fedorahosted.org/freeipa/ticket/3509#comment:2 then it should be -fs/--force-start or something of this kind. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] OpenSSH with PKCS#11 for key storage
On 02/19/2014 03:30 PM, Petr Spacek wrote: On 19.2.2014 21:13, Dmitri Pal wrote: On 02/19/2014 01:49 PM, Petr Spacek wrote: Hello list, I just came across this page: http://www.gooze.eu/howto/using-openssh-with-smartcards/using-ssh-authentication-agent-ssh-add-with-smartcards If I understand correctly, it allows you to store use your personal SSH keys via PKCS#11 interface. It sounds like a killer feature to me! Imagine that you can log-in to any machine in IPA realm and you will have all your SSH keys with you, without any extra work. This extends seamless SSO outside the enterprise (we have Kerberos for inside, this doesn't change that). Petr^2 Spacek P.S. It is natively supported in OpenSSH v5.4p1 - we have PKCS#11 support in Fedora 20 already. What are the implications for SSSD and IPA? What needs to be changed if anything? First of all, we need the PKCS#11 provider. We plan to write it for DNSSEC and CA rotation anyway, we just need to think about different use case during design phase. The rest should 'just work'. (As usual, nobody knows beforehand where the dead dog is buried :-)) Provider? You mean SSSD exposing data as a PKCS#11 provider? I understand it in the case when data comes from central server and needs to be passed to consumers via PKCS#11 interface but in this case data comes from a user and actually should not come from SSSD but rather a real smart card inserted by user. What am I missing? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy
On 02/17/2014 07:53 AM, Simo Sorce wrote: On Sun, 2014-02-16 at 21:54 -0500, Dmitri Pal wrote: On 02/16/2014 06:49 AM, Simo Sorce wrote: On Fri, 2014-02-14 at 16:52 -0500, Rob Crittenden wrote: - listens on port 8090, only on localhost - is unauthenticated Sorry to come late, but I am really at unease with this point. Can we do at least some form of simple authentication ? Even if it is a shared secret in a file accessible by both foreman and smartproxy ? Simo. Simo, it is such by design. The design is that foreman can connect to the local proxy in a simple way. We can do it w/o exposing completely open interfaces to the local host. The interface is local only and smart proxy explicitly checks that is it called locally byt a local process. If it were using a unix socket that can be protected by permissions I would have no qualms, but afaik this is listening on a network port on localhost. It means *any* process can connect, they are all local. The daemon by itself will then do a remote authenticate against IPA. We trust Foreman machine to make the host changes and allow it to make only these changes using access control rules on the server. I do not think we need or can change anything here. Any kind of authentication would significantly complicate integration with Foreman and I frankly do not see a value in another level of authentication. I.e. how certs or key in the file makes it more secure? By allowing only the Foreman process to successfully connect. I would rather suggest some SELInux policies that would open the REST api port to only specific labels. Sure SELinux should certainly be used, but not everybody runs SELinux. Right, but do we care? If you disable SELInux you open it to the whole host this is your choice. A shared file with a secret that only foreman and the proxy can access is very simple, it can even be generated on the fly at stratup, w/o requiring any special manual setup. Then you need to deal with permissions and labeling of this file and make sure that only these two can access again based on SELinux labels. And if you turn SELinux then other applications would be able to access if they can su to that user. IMO we should explore local socket path if possible first and make sure that only foreman can connect, then rely on SELInux and only if these options get exhausted start adding complexity to do the authentication of the API using shared secrets or certs. Keep in mind that the authentication was explicitly out of scope for the first round. I am generally no against it as next step. I am just against it being jammed in now. Simo. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy
On 02/17/2014 01:21 PM, Rob Crittenden wrote: Martin Kosek wrote: On 02/14/2014 11:26 PM, Dmitri Pal wrote: On 02/14/2014 05:07 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 02/14/2014 04:52 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 02/14/2014 03:09 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 02/14/2014 03:43 AM, Martin Kosek wrote: On 02/14/2014 12:07 AM, Rob Crittenden wrote: Martin Kosek wrote: On 01/28/2014 09:35 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 01/23/2014 02:17 PM, Petr Viktorin wrote: ... The URL endpoint /ipa/rest suggests that if we implement a complete REST API for IPA it would live here. Is the API supposed to be future-compatible? (The API itself seems to be a good subset of a complete REST API, but can we easily add an frontend with authentication, i18n, etc. here later, and keep the limitations for unauthenticated access?) Perhaps /ipa/smartproxy would be a better choice? It was future-proofing. I'm fine with changing the URI, it is probably a good thing to save that name. +1 for moving to /ipa/smartproxy/rest, we will want a complete REST interface in ipa/rest/ in the future. I rather opened a ticket to track that: https://fedorahosted.org/freeipa/ticket/4168 Martin I think I've addressed most of Petr's suggestions with the exception of the global ipa handle and I stuck with *args, **options as this is pretty much standard in IPA calls. The gssproxy.conf.snippet just makes it easier to copy/paste. I can drop it if you want, I suppose it is duplication. Note that I ran this past the Foreman design again and as a result added another interface, /realm. It was my understanding that this Foreman design wasn't set into stone but a patch is working its way through their system that followed the spec so I went ahead and added it. It isn't a big deal, the Host() class handles it out of the box. I also updated the design page a bit to reflect some of the changes made. Right now there are no plans to backport python-kerberos to F20. rob I will leave functional testing to others, I just read the code. I am still quite concerned about the positioning, naming and branding of this feature. 1) Package name Currently, it is a host/hostgroup smartproxy, primarily for Foreman integration use case. Packaging it as freeipa-server-smartproxy may be ok, but only if we plan to use this proxy for all other projects. I.e. if we one day implement user smartproxy, it would need to be part of this otherwise it would lead to strange organization, like having freeipa-server-smartproxy and freeipa-server-smartproxy-users packages. Maybe it should be named differently? freeipa-server-foreman-smartproxy freeipa-server-smartproxy-hosts 2) ipa-rest stuff We have ipa-rest script, ipa-rest.conf, ipa-rest.service, ipa-rest man. However, I have the same concerns as above. This is too general and it may conflict with future core server needs (like when we implement core IPA REST interface - #4168). Let us name it consistently with package name: ipa-smartproxy.service ipa-smartproxy-hosts.service ipa-foreman-smartproxy.service The same for binary, man, ... 3) Man pages The same point, you brand it as IPA REST server. This is too general. To sum it up - let us chose one name/brand of this feature and let's use it consistently in FreeIPA infrastructure - subpackage name, subdirectory in git, subdirectory in ipatests, man, conf, script, names in man pages. Martin +1 I think it should be host ipa-host-smartproxy then we will be able to add other smart proxies and then combine them into one ipa-smartproxy package later if needed. This would imply we actually run separate servers for the various commands. Given that right now we're focused on just the Foreman use cases I think ipa-smartproxy is sufficient. For our purposes the smartproxy is just a thin wrapper around the IPA API. It is extensible for our needs, we just don't need to yet. But if we did, we'd do so within the cherrypy server and everything would be self-contained. rob Are you saying that we will just extend this smart proxy for other use cases like users and others? It all depends on the use case. If we're talking Foreman then yes. If something else, then we'll discuss it at the time, but it still may be able to be included. The IPA Foreman smart proxy is distinguished by a couple of things: - listens on port 8090, only on localhost - is unauthenticated - uses the /realm URI namespace I'm exposing hosts and hostgroups as well, but per the spec that Dominic came up with only /realm/:domain is required and affects only hosts. We can stick this behind Apache to get authentication, even on a specific URI if we want/need to, but the basic REST stuff can still be handled by cherrypy. We'll need to balance complexity of mixing things vs the complexity of code duplication in multiple servers, unless we come up with some sort of REST
Re: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy
On 02/17/2014 04:13 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 02/17/2014 02:33 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 02/17/2014 01:21 PM, Rob Crittenden wrote: Martin Kosek wrote: On 02/14/2014 11:26 PM, Dmitri Pal wrote: +1, this was exactly my goal. It is easy to name and organize things now, difficult to do when it is live upstream and/or integrated with Foreman. I think the key for the right naming is a fact if this is really specific to Foreman or it is a truly general design usable also in other use cases. If Foreman-specific, I would go with freeipa-server-smartproxy-host or similar. If general, we can go with freeipa-server-proxy-host freeipa-server-proxy-user freeipa-server-proxy-dhcp The proxies may share the framework and only expose the requested part of the tree - which in advance gives you an option for an API separation, as compared to general freeipa-server-smartproxy. I still don't get the point of this. Are you proposing having 3 different servers, each providing a unique service? Or one service that one can turn on/off features, or something else? Do you envision this as 3 separate subpackages? There is no framework in my current patch, it is a cherrypy server that exposes parts of IPA on a given URI. It is the thinnest of layers. Then it seems to make sense to have 3 different packages that can be optionally coninstalled and would probably share the same principal, keytab and local REST API socket/port. Well, what you are designing is a central framework with plugins. What I designed is a quick-and-dirty get something up quickly. We need to pick one. The plugable method is going to require a fair bit of rework, though it will potentially pay dividends in the future. I think that we can start where you are but drive towards this architecture via refactoring. But we need to pick the right name now. Even if the architecture is not there yet we should name the package in such way that it does not preclude us from moving towards a clean architecture I described during the next iteration. Just having a hard time seeing the value. This would be like making each of the IPA plugins a separate package and somehow installing them individually. To do this you'd need at least 2 packages, a high level one with the framework and then a separate one for each data type. This could also be achieved, and likely more cleanly, without all these extra packages, as a simple configuration file. Once a package, always a package. Maybe I'm too close to the problem, but to me this is a Foreman-specific solution. The smartproxy is a Foreman creation, I don't know that anything else is using it. If you want a RESTful server, then we enable REST in IPA directly, but selectively enabling and disabling APIs is not something we've done before. It has been controlled by ACIs instead. rob We are trying to predict future here. Say we release it as you suggest. Tomorrow we point someone upstream who wants to add users to IPA from a similar proxy to this implementation and say use this as a model. And then Rich needs the same but for DNS for Designate. What would be the best? Rob if you knew that tomorrow two other developers will create similar proxies for users and DNS would you change anything? Would you provide some guidelines to them? If you are close to the problem you should be able to at least tell them: copy and paste vs. add more APIs to the same proxy. If your recommendation is copy and paste then I suspect there will be challenges of running these proxies on the same machine - they will collide on ports and sockets. If we say extend shouldn't we use a more generic name? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy
On 02/17/2014 04:57 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 02/17/2014 04:13 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 02/17/2014 02:33 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 02/17/2014 01:21 PM, Rob Crittenden wrote: Martin Kosek wrote: On 02/14/2014 11:26 PM, Dmitri Pal wrote: +1, this was exactly my goal. It is easy to name and organize things now, difficult to do when it is live upstream and/or integrated with Foreman. I think the key for the right naming is a fact if this is really specific to Foreman or it is a truly general design usable also in other use cases. If Foreman-specific, I would go with freeipa-server-smartproxy-host or similar. If general, we can go with freeipa-server-proxy-host freeipa-server-proxy-user freeipa-server-proxy-dhcp The proxies may share the framework and only expose the requested part of the tree - which in advance gives you an option for an API separation, as compared to general freeipa-server-smartproxy. I still don't get the point of this. Are you proposing having 3 different servers, each providing a unique service? Or one service that one can turn on/off features, or something else? Do you envision this as 3 separate subpackages? There is no framework in my current patch, it is a cherrypy server that exposes parts of IPA on a given URI. It is the thinnest of layers. Then it seems to make sense to have 3 different packages that can be optionally coninstalled and would probably share the same principal, keytab and local REST API socket/port. Well, what you are designing is a central framework with plugins. What I designed is a quick-and-dirty get something up quickly. We need to pick one. The plugable method is going to require a fair bit of rework, though it will potentially pay dividends in the future. I think that we can start where you are but drive towards this architecture via refactoring. But we need to pick the right name now. Even if the architecture is not there yet we should name the package in such way that it does not preclude us from moving towards a clean architecture I described during the next iteration. Just having a hard time seeing the value. This would be like making each of the IPA plugins a separate package and somehow installing them individually. To do this you'd need at least 2 packages, a high level one with the framework and then a separate one for each data type. This could also be achieved, and likely more cleanly, without all these extra packages, as a simple configuration file. Once a package, always a package. Maybe I'm too close to the problem, but to me this is a Foreman-specific solution. The smartproxy is a Foreman creation, I don't know that anything else is using it. If you want a RESTful server, then we enable REST in IPA directly, but selectively enabling and disabling APIs is not something we've done before. It has been controlled by ACIs instead. rob We are trying to predict future here. Say we release it as you suggest. Tomorrow we point someone upstream who wants to add users to IPA from a similar proxy to this implementation and say use this as a model. And then Rich needs the same but for DNS for Designate. What would be the best? Rob if you knew that tomorrow two other developers will create similar proxies for users and DNS would you change anything? Would you provide some guidelines to them? If you are close to the problem you should be able to at least tell them: copy and paste vs. add more APIs to the same proxy. If your recommendation is copy and paste then I suspect there will be challenges of running these proxies on the same machine - they will collide on ports and sockets. If we say extend shouldn't we use a more generic name? I'd say use the existing IPA API. The only reason we have to write the smartproxy at all is to interoperate with another service that already has a well-defined remote server API which uses REST. rob OK, so you think that proxy is one off. OK I am fine with it. I was under assumption that it would be a beginning of a trend but I might be wrong as I do not have valid arguments to prove or disprove one way or another. I guess time would show. Any objections to Rob's approach? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy
On 02/16/2014 06:49 AM, Simo Sorce wrote: On Fri, 2014-02-14 at 16:52 -0500, Rob Crittenden wrote: - listens on port 8090, only on localhost - is unauthenticated Sorry to come late, but I am really at unease with this point. Can we do at least some form of simple authentication ? Even if it is a shared secret in a file accessible by both foreman and smartproxy ? Simo. Simo, it is such by design. The interface is local only and smart proxy explicitly checks that is it called locally byt a local process. The daemon by itself will then do a remote authenticate against IPA. We trust Foreman machine to make the host changes and allow it to make only these changes using access control rules on the server. I do not think we need or can change anything here. Any kind of authentication would significantly complicate integration with Foreman and I frankly do not see a value in another level of authentication. I.e. how certs or key in the file makes it more secure? I would rather suggest some SELInux policies that would open the REST api port to only specific labels. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy
On 02/14/2014 03:43 AM, Martin Kosek wrote: On 02/14/2014 12:07 AM, Rob Crittenden wrote: Martin Kosek wrote: On 01/28/2014 09:35 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 01/23/2014 02:17 PM, Petr Viktorin wrote: ... The URL endpoint /ipa/rest suggests that if we implement a complete REST API for IPA it would live here. Is the API supposed to be future-compatible? (The API itself seems to be a good subset of a complete REST API, but can we easily add an frontend with authentication, i18n, etc. here later, and keep the limitations for unauthenticated access?) Perhaps /ipa/smartproxy would be a better choice? It was future-proofing. I'm fine with changing the URI, it is probably a good thing to save that name. +1 for moving to /ipa/smartproxy/rest, we will want a complete REST interface in ipa/rest/ in the future. I rather opened a ticket to track that: https://fedorahosted.org/freeipa/ticket/4168 Martin I think I've addressed most of Petr's suggestions with the exception of the global ipa handle and I stuck with *args, **options as this is pretty much standard in IPA calls. The gssproxy.conf.snippet just makes it easier to copy/paste. I can drop it if you want, I suppose it is duplication. Note that I ran this past the Foreman design again and as a result added another interface, /realm. It was my understanding that this Foreman design wasn't set into stone but a patch is working its way through their system that followed the spec so I went ahead and added it. It isn't a big deal, the Host() class handles it out of the box. I also updated the design page a bit to reflect some of the changes made. Right now there are no plans to backport python-kerberos to F20. rob I will leave functional testing to others, I just read the code. I am still quite concerned about the positioning, naming and branding of this feature. 1) Package name Currently, it is a host/hostgroup smartproxy, primarily for Foreman integration use case. Packaging it as freeipa-server-smartproxy may be ok, but only if we plan to use this proxy for all other projects. I.e. if we one day implement user smartproxy, it would need to be part of this otherwise it would lead to strange organization, like having freeipa-server-smartproxy and freeipa-server-smartproxy-users packages. Maybe it should be named differently? freeipa-server-foreman-smartproxy freeipa-server-smartproxy-hosts 2) ipa-rest stuff We have ipa-rest script, ipa-rest.conf, ipa-rest.service, ipa-rest man. However, I have the same concerns as above. This is too general and it may conflict with future core server needs (like when we implement core IPA REST interface - #4168). Let us name it consistently with package name: ipa-smartproxy.service ipa-smartproxy-hosts.service ipa-foreman-smartproxy.service The same for binary, man, ... 3) Man pages The same point, you brand it as IPA REST server. This is too general. To sum it up - let us chose one name/brand of this feature and let's use it consistently in FreeIPA infrastructure - subpackage name, subdirectory in git, subdirectory in ipatests, man, conf, script, names in man pages. Martin +1 I think it should be host ipa-host-smartproxy then we will be able to add other smart proxies and then combine them into one ipa-smartproxy package later if needed. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DNSSEC design page
On 02/14/2014 06:37 AM, Petr Spacek wrote: On 14.2.2014 12:27, Jan Cholasta wrote: On 14.2.2014 12:08, Petr Spacek wrote: On 14.2.2014 11:03, Jan Cholasta wrote: On 13.2.2014 18:36, Petr Spacek wrote: Hello list, I would like to point you to design pages for DNSSEC feature: Zone signing: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC Automatic key rotation: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Shortterm https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/DNSSEC/Keys/Longterm You can ignore bind-dyndb-ldap specifics and think about interactions with FreeIPA and SSSD. - We need to design LDAP schema for key storage (Ludwig is looking into it). Keep in mind the schema has to work with or be extensible enough for other uses as well, ATM at least IPA CA certificate storage. Feel free to extend the design page as necessary. May be that we should create separate design page specifically for this PKCS#11 module. +1 Will you create the design page? I have enjoyed it with DNSSEC and now I would like to spend some time with coding ... :-) http://www.freeipa.org/page/Feature_template In fact, it is not related to DNSSEC at all. We just need to add some DNSSEC-specific meta data to keys, nothing else. My point exactly. IMO the easiest (from the PKCS#11 module writing perspective) way to do it would be to map PKCS#11 object classes and attributes directly to LDAP object classes and attributes, but that might be too much low-level for us. - We need to write PKCS#11 module on top of LDAP database. SSSD. - We need to design key rotation on client side (SSSD? Certmonger?). Also SSSD. I thought we already agreed on that last week? Last idea I have heard was about certmonger - Dmitri thought that Certmonger already have all the necessary logic. It does not, for starters there is no LDAP or caching. If anything, it might be a combination of both, but I think that's more relevant to CA certificate rotation than DNSSEC. I do not insist on certmonger. In any case, nothing is set in stone. We have to discuss pros and cons and then decide. Obviously :-) Keep in mind that we have to support key rotation even if the key was compromised ... (Fallback from RFC 5011 to Kerberos+LDAP or something like that.) I don't see how this gives advantage to either SSSD or certmonger. Sure, I'm just pointing it out so we are all aware of this problem. - We need to design WebUI/CLI etc. Read sections 'External Impact' carefully :-) Have a nice day! -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy
On 02/14/2014 03:09 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 02/14/2014 03:43 AM, Martin Kosek wrote: On 02/14/2014 12:07 AM, Rob Crittenden wrote: Martin Kosek wrote: On 01/28/2014 09:35 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 01/23/2014 02:17 PM, Petr Viktorin wrote: ... The URL endpoint /ipa/rest suggests that if we implement a complete REST API for IPA it would live here. Is the API supposed to be future-compatible? (The API itself seems to be a good subset of a complete REST API, but can we easily add an frontend with authentication, i18n, etc. here later, and keep the limitations for unauthenticated access?) Perhaps /ipa/smartproxy would be a better choice? It was future-proofing. I'm fine with changing the URI, it is probably a good thing to save that name. +1 for moving to /ipa/smartproxy/rest, we will want a complete REST interface in ipa/rest/ in the future. I rather opened a ticket to track that: https://fedorahosted.org/freeipa/ticket/4168 Martin I think I've addressed most of Petr's suggestions with the exception of the global ipa handle and I stuck with *args, **options as this is pretty much standard in IPA calls. The gssproxy.conf.snippet just makes it easier to copy/paste. I can drop it if you want, I suppose it is duplication. Note that I ran this past the Foreman design again and as a result added another interface, /realm. It was my understanding that this Foreman design wasn't set into stone but a patch is working its way through their system that followed the spec so I went ahead and added it. It isn't a big deal, the Host() class handles it out of the box. I also updated the design page a bit to reflect some of the changes made. Right now there are no plans to backport python-kerberos to F20. rob I will leave functional testing to others, I just read the code. I am still quite concerned about the positioning, naming and branding of this feature. 1) Package name Currently, it is a host/hostgroup smartproxy, primarily for Foreman integration use case. Packaging it as freeipa-server-smartproxy may be ok, but only if we plan to use this proxy for all other projects. I.e. if we one day implement user smartproxy, it would need to be part of this otherwise it would lead to strange organization, like having freeipa-server-smartproxy and freeipa-server-smartproxy-users packages. Maybe it should be named differently? freeipa-server-foreman-smartproxy freeipa-server-smartproxy-hosts 2) ipa-rest stuff We have ipa-rest script, ipa-rest.conf, ipa-rest.service, ipa-rest man. However, I have the same concerns as above. This is too general and it may conflict with future core server needs (like when we implement core IPA REST interface - #4168). Let us name it consistently with package name: ipa-smartproxy.service ipa-smartproxy-hosts.service ipa-foreman-smartproxy.service The same for binary, man, ... 3) Man pages The same point, you brand it as IPA REST server. This is too general. To sum it up - let us chose one name/brand of this feature and let's use it consistently in FreeIPA infrastructure - subpackage name, subdirectory in git, subdirectory in ipatests, man, conf, script, names in man pages. Martin +1 I think it should be host ipa-host-smartproxy then we will be able to add other smart proxies and then combine them into one ipa-smartproxy package later if needed. This would imply we actually run separate servers for the various commands. Given that right now we're focused on just the Foreman use cases I think ipa-smartproxy is sufficient. For our purposes the smartproxy is just a thin wrapper around the IPA API. It is extensible for our needs, we just don't need to yet. But if we did, we'd do so within the cherrypy server and everything would be self-contained. rob Are you saying that we will just extend this smart proxy for other use cases like users and others? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy
On 02/14/2014 04:52 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 02/14/2014 03:09 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 02/14/2014 03:43 AM, Martin Kosek wrote: On 02/14/2014 12:07 AM, Rob Crittenden wrote: Martin Kosek wrote: On 01/28/2014 09:35 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 01/23/2014 02:17 PM, Petr Viktorin wrote: ... The URL endpoint /ipa/rest suggests that if we implement a complete REST API for IPA it would live here. Is the API supposed to be future-compatible? (The API itself seems to be a good subset of a complete REST API, but can we easily add an frontend with authentication, i18n, etc. here later, and keep the limitations for unauthenticated access?) Perhaps /ipa/smartproxy would be a better choice? It was future-proofing. I'm fine with changing the URI, it is probably a good thing to save that name. +1 for moving to /ipa/smartproxy/rest, we will want a complete REST interface in ipa/rest/ in the future. I rather opened a ticket to track that: https://fedorahosted.org/freeipa/ticket/4168 Martin I think I've addressed most of Petr's suggestions with the exception of the global ipa handle and I stuck with *args, **options as this is pretty much standard in IPA calls. The gssproxy.conf.snippet just makes it easier to copy/paste. I can drop it if you want, I suppose it is duplication. Note that I ran this past the Foreman design again and as a result added another interface, /realm. It was my understanding that this Foreman design wasn't set into stone but a patch is working its way through their system that followed the spec so I went ahead and added it. It isn't a big deal, the Host() class handles it out of the box. I also updated the design page a bit to reflect some of the changes made. Right now there are no plans to backport python-kerberos to F20. rob I will leave functional testing to others, I just read the code. I am still quite concerned about the positioning, naming and branding of this feature. 1) Package name Currently, it is a host/hostgroup smartproxy, primarily for Foreman integration use case. Packaging it as freeipa-server-smartproxy may be ok, but only if we plan to use this proxy for all other projects. I.e. if we one day implement user smartproxy, it would need to be part of this otherwise it would lead to strange organization, like having freeipa-server-smartproxy and freeipa-server-smartproxy-users packages. Maybe it should be named differently? freeipa-server-foreman-smartproxy freeipa-server-smartproxy-hosts 2) ipa-rest stuff We have ipa-rest script, ipa-rest.conf, ipa-rest.service, ipa-rest man. However, I have the same concerns as above. This is too general and it may conflict with future core server needs (like when we implement core IPA REST interface - #4168). Let us name it consistently with package name: ipa-smartproxy.service ipa-smartproxy-hosts.service ipa-foreman-smartproxy.service The same for binary, man, ... 3) Man pages The same point, you brand it as IPA REST server. This is too general. To sum it up - let us chose one name/brand of this feature and let's use it consistently in FreeIPA infrastructure - subpackage name, subdirectory in git, subdirectory in ipatests, man, conf, script, names in man pages. Martin +1 I think it should be host ipa-host-smartproxy then we will be able to add other smart proxies and then combine them into one ipa-smartproxy package later if needed. This would imply we actually run separate servers for the various commands. Given that right now we're focused on just the Foreman use cases I think ipa-smartproxy is sufficient. For our purposes the smartproxy is just a thin wrapper around the IPA API. It is extensible for our needs, we just don't need to yet. But if we did, we'd do so within the cherrypy server and everything would be self-contained. rob Are you saying that we will just extend this smart proxy for other use cases like users and others? It all depends on the use case. If we're talking Foreman then yes. If something else, then we'll discuss it at the time, but it still may be able to be included. The IPA Foreman smart proxy is distinguished by a couple of things: - listens on port 8090, only on localhost - is unauthenticated - uses the /realm URI namespace I'm exposing hosts and hostgroups as well, but per the spec that Dominic came up with only /realm/:domain is required and affects only hosts. We can stick this behind Apache to get authentication, even on a specific URI if we want/need to, but the basic REST stuff can still be handled by cherrypy. We'll need to balance complexity of mixing things vs the complexity of code duplication in multiple servers, unless we come up with some sort of REST server class where we just instantiate whatever we need. But that is for the future. rob But if it is specific for Foreman then it should have a generic name. I agree with Martin here. -- Thank you, Dmitri Pal
Re: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy
On 02/14/2014 05:07 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 02/14/2014 04:52 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 02/14/2014 03:09 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 02/14/2014 03:43 AM, Martin Kosek wrote: On 02/14/2014 12:07 AM, Rob Crittenden wrote: Martin Kosek wrote: On 01/28/2014 09:35 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 01/23/2014 02:17 PM, Petr Viktorin wrote: ... The URL endpoint /ipa/rest suggests that if we implement a complete REST API for IPA it would live here. Is the API supposed to be future-compatible? (The API itself seems to be a good subset of a complete REST API, but can we easily add an frontend with authentication, i18n, etc. here later, and keep the limitations for unauthenticated access?) Perhaps /ipa/smartproxy would be a better choice? It was future-proofing. I'm fine with changing the URI, it is probably a good thing to save that name. +1 for moving to /ipa/smartproxy/rest, we will want a complete REST interface in ipa/rest/ in the future. I rather opened a ticket to track that: https://fedorahosted.org/freeipa/ticket/4168 Martin I think I've addressed most of Petr's suggestions with the exception of the global ipa handle and I stuck with *args, **options as this is pretty much standard in IPA calls. The gssproxy.conf.snippet just makes it easier to copy/paste. I can drop it if you want, I suppose it is duplication. Note that I ran this past the Foreman design again and as a result added another interface, /realm. It was my understanding that this Foreman design wasn't set into stone but a patch is working its way through their system that followed the spec so I went ahead and added it. It isn't a big deal, the Host() class handles it out of the box. I also updated the design page a bit to reflect some of the changes made. Right now there are no plans to backport python-kerberos to F20. rob I will leave functional testing to others, I just read the code. I am still quite concerned about the positioning, naming and branding of this feature. 1) Package name Currently, it is a host/hostgroup smartproxy, primarily for Foreman integration use case. Packaging it as freeipa-server-smartproxy may be ok, but only if we plan to use this proxy for all other projects. I.e. if we one day implement user smartproxy, it would need to be part of this otherwise it would lead to strange organization, like having freeipa-server-smartproxy and freeipa-server-smartproxy-users packages. Maybe it should be named differently? freeipa-server-foreman-smartproxy freeipa-server-smartproxy-hosts 2) ipa-rest stuff We have ipa-rest script, ipa-rest.conf, ipa-rest.service, ipa-rest man. However, I have the same concerns as above. This is too general and it may conflict with future core server needs (like when we implement core IPA REST interface - #4168). Let us name it consistently with package name: ipa-smartproxy.service ipa-smartproxy-hosts.service ipa-foreman-smartproxy.service The same for binary, man, ... 3) Man pages The same point, you brand it as IPA REST server. This is too general. To sum it up - let us chose one name/brand of this feature and let's use it consistently in FreeIPA infrastructure - subpackage name, subdirectory in git, subdirectory in ipatests, man, conf, script, names in man pages. Martin +1 I think it should be host ipa-host-smartproxy then we will be able to add other smart proxies and then combine them into one ipa-smartproxy package later if needed. This would imply we actually run separate servers for the various commands. Given that right now we're focused on just the Foreman use cases I think ipa-smartproxy is sufficient. For our purposes the smartproxy is just a thin wrapper around the IPA API. It is extensible for our needs, we just don't need to yet. But if we did, we'd do so within the cherrypy server and everything would be self-contained. rob Are you saying that we will just extend this smart proxy for other use cases like users and others? It all depends on the use case. If we're talking Foreman then yes. If something else, then we'll discuss it at the time, but it still may be able to be included. The IPA Foreman smart proxy is distinguished by a couple of things: - listens on port 8090, only on localhost - is unauthenticated - uses the /realm URI namespace I'm exposing hosts and hostgroups as well, but per the spec that Dominic came up with only /realm/:domain is required and affects only hosts. We can stick this behind Apache to get authentication, even on a specific URI if we want/need to, but the basic REST stuff can still be handled by cherrypy. We'll need to balance complexity of mixing things vs the complexity of code duplication in multiple servers, unless we come up with some sort of REST server class where we just instantiate whatever we need. But that is for the future. rob But if it is specific for Foreman then it should have
Re: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy
On 02/13/2014 06:07 PM, Rob Crittenden wrote: Martin Kosek wrote: On 01/28/2014 09:35 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 01/23/2014 02:17 PM, Petr Viktorin wrote: ... The URL endpoint /ipa/rest suggests that if we implement a complete REST API for IPA it would live here. Is the API supposed to be future-compatible? (The API itself seems to be a good subset of a complete REST API, but can we easily add an frontend with authentication, i18n, etc. here later, and keep the limitations for unauthenticated access?) Perhaps /ipa/smartproxy would be a better choice? It was future-proofing. I'm fine with changing the URI, it is probably a good thing to save that name. +1 for moving to /ipa/smartproxy/rest, we will want a complete REST interface in ipa/rest/ in the future. I rather opened a ticket to track that: https://fedorahosted.org/freeipa/ticket/4168 Martin I think I've addressed most of Petr's suggestions with the exception of the global ipa handle and I stuck with *args, **options as this is pretty much standard in IPA calls. The gssproxy.conf.snippet just makes it easier to copy/paste. I can drop it if you want, I suppose it is duplication. Note that I ran this past the Foreman design again and as a result added another interface, /realm. It was my understanding that this Foreman design wasn't set into stone but a patch is working its way through their system that followed the spec so I went ahead and added it. It isn't a big deal, the Host() class handles it out of the box. I also updated the design page a bit to reflect some of the changes made. Right now there are no plans to backport python-kerberos to F20. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Recently we had a ticket in SSSD https://fedorahosted.org/sssd/ticket/2217 Should we have a similar one for IPA client and especially for the proxy? Proxy will be a long term running process so dealing with the stale tickets becomes important for it if replica is re-installed. Is it something that is solved in API level or on the proxy level? Should we have a separate ticket for that? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1106 IPA REST smart proxy
On 02/13/2014 09:02 PM, Rob Crittenden wrote: Dmitri Pal wrote: On 02/13/2014 06:07 PM, Rob Crittenden wrote: Martin Kosek wrote: On 01/28/2014 09:35 PM, Rob Crittenden wrote: Petr Viktorin wrote: On 01/23/2014 02:17 PM, Petr Viktorin wrote: ... The URL endpoint /ipa/rest suggests that if we implement a complete REST API for IPA it would live here. Is the API supposed to be future-compatible? (The API itself seems to be a good subset of a complete REST API, but can we easily add an frontend with authentication, i18n, etc. here later, and keep the limitations for unauthenticated access?) Perhaps /ipa/smartproxy would be a better choice? It was future-proofing. I'm fine with changing the URI, it is probably a good thing to save that name. +1 for moving to /ipa/smartproxy/rest, we will want a complete REST interface in ipa/rest/ in the future. I rather opened a ticket to track that: https://fedorahosted.org/freeipa/ticket/4168 Martin I think I've addressed most of Petr's suggestions with the exception of the global ipa handle and I stuck with *args, **options as this is pretty much standard in IPA calls. The gssproxy.conf.snippet just makes it easier to copy/paste. I can drop it if you want, I suppose it is duplication. Note that I ran this past the Foreman design again and as a result added another interface, /realm. It was my understanding that this Foreman design wasn't set into stone but a patch is working its way through their system that followed the spec so I went ahead and added it. It isn't a big deal, the Host() class handles it out of the box. I also updated the design page a bit to reflect some of the changes made. Right now there are no plans to backport python-kerberos to F20. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Recently we had a ticket in SSSD https://fedorahosted.org/sssd/ticket/2217 Should we have a similar one for IPA client and especially for the proxy? Proxy will be a long term running process so dealing with the stale tickets becomes important for it if replica is re-installed. Is it something that is solved in API level or on the proxy level? Should we have a separate ticket for that? Using gss-proxy so it's not our problem. We never touch tickets. rob Does gss proxy solve this problem? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Clarifying Pilsner/Beer Exchange/Deferred Trac milestones
On 02/10/2014 05:03 AM, Martin Kosek wrote: Hello, I would to follow up on a core devel team discussion we had last week. Part of it were changes to milestones as we currently use it. 1) Pilsner/Beer Exchange/Deferred Currently, we have 3 levels of deferring feature request and bug fix tickets to later releases: a) Pilsner barrel: when planning next release, most of the tickets will come from this release, based on priority or topic of the next release b) Beer Exchange: tickets we do not plan to complete any time soon as we do not consider it critical enough to devote our limited development resources to it. However, it does not mean we do not welcome our community to contact us and provide patches! More details in [1]. It may still happen though, that we will pick a ticket from this milestone to next release, but it is much less likely than with Pilsner c) Deferred: we surely do not plan to complete those and we do not recommend community to look at those either (unless strongly justified). More information about Roadmap in [2]. As discussed, this naming is not very transparent and obvious for people outside of core development team. Thus, to narrow the expectations, we would like to rename it to become more obvious. Here are my proposals: a) Pilsner - Future releases (with appropriate milestone description to set the expectations right) Next release backlog b) Beer Exchange - Backlog (with better description) General ticket pool c) Deferred - can stay as is. If there are any objections or better suggestions, please let me know. [1] http://www.freeipa.org/page/Contribute/Code [2] http://www.freeipa.org/page/Roadmap -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Organizing upstream development in Trac
On 02/10/2014 07:28 AM, Petr Viktorin wrote: On 02/10/2014 01:22 PM, Martin Kosek wrote: Hello, FreeIPA core devel team had a discussion about how to organize our development milestones better. Currently, all next release development tickets are put into monthly milestones and then worked in based on priorities. However, this does does not fly well with the non-critical tickets as when the development gets behind schedule, there is a lot of moving tickets around, moving them to $month+1 milestone, causing confusing churn in the ticket history. As agreed on the meeting, we need to improve the situation, this is the proposal: 1) Monthly release milestones will only contain a limited set of scheduled core critical feature that will be a priority for the developer to work on. 2) We will create a new next feature backlog which will contain the less important features and bug fixes, i.e. FreeIPA 3.4 Backlog. When developer has done all his this-month tickets, he can start with the backlog ones, according to priority. 3) Besides these 2 next-release milestone types, there will be a second train for bug fixing current release (we currently have 2014 Month 2 - February (3.3.x bug fixing)). I am thinking this does not need be divided to months as these tickets need to be done asap anyway. So I would name it simply FreeIPA 3.3.5. Note the change from 3.3.x to 3.3.5 - I found that 3.3.x is confusing that it is more difficult to see the exact version where the patch landed. Please name it e.g. FreeIPA 3.3.5 (bug fixing) or FreeIPA 3.3.5 (maintenance) for clarity. Numbers have a tendency to get mixed up. +1 This means that each month, a developer should watch following 3 milestones (in this order): * current release bug fixing milestone: FreeIPA 3.3.5 * next-release monthly milestone: FreeIPA 3.4 - 2014/2 * next-release backlog milestone: FreeIPA 3.4 Backlog If there are no strong objections, I will create new milestones, rename existing ones and sanitize current distribution of 3.4 tickets. IMO this would make the milestone clear, but I am open to other suggestions. +1 -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Samba FS ticket
Hi, We have a ticket [1] about Samba FS documentation. Alexander added a comment recently but I know Sumit is working on this effort now. Should we pull ticket in and/or merge it with some other ticket wit have? [1] https://fedorahosted.org/freeipa/ticket/3999 -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Web services in freeIPA
On 02/06/2014 10:12 AM, Martin Kosek wrote: As Petr said, we do not have a proper documentation for using RPC for controlling IPA. But I think you can start with looking at [1] to see the template and try running our commands with -vv which will show you how we call the API: $ ipa -vv user-show admin Are we still suggesting using XML interface? I though we were planning to prefer JSON rather than XML, something changed here? Martin [1] http://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ On 02/06/2014 04:04 PM, Alexandre Santos wrote: Is there any examples that can guide me. Thanks Alexandre Santos On 06 Feb 2014, at 14:33, Petr Vobornik pvobo...@redhat.com wrote: On 6.2.2014 15:22, Alexandre Santos wrote: Hi, I´m starting in freeIPA and I would like to know what web apps are available for use, like create user, delete user and so on. I´ve seen that when i use the command ipa -vv user-add” a url for the app if given. I would like to know if there is any information about that. Thanks Alexandre Santos The url you saw is most-likely for XML RPC API. You can check: https://hostname/ipa/xml - XML RPC API https://hostname/ipa/json - JSON RPC API https://hostname/ipa/session/xml XML RPC API with session support https://hostname/ipa/session/json JSON RPC API with session support https://hostname/ipa/ui - Web UI https://hostname/ipa/config/unauthorized.html - some config and error pages We don't have docs for the APIs yet. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope
On 01/31/2014 05:03 AM, Martin Kosek wrote: On 01/31/2014 10:45 AM, Francesco Chicchiriccò wrote: On 30/01/2014 19:25, Dmitri Pal wrote: On 01/30/2014 11:35 AM, Francesco Chicchiriccò wrote: ... To call into IPA you can use ipa ... command line or use out API from python client. Since you are using Java calling into ipa command is probably the best option. Actually, a RESTful interface (HTTP/JSON) would better suit our development model and deployment scenarios. FreeIPA does not have (currently) not RESTful interface (though it is being partially designed in [8]). However it has a Kerberos-protected JSON-RPC/XML-RPC interface used by clients or Web UI to communicate with the server. I suggest that you look at the implementation of [8] and create a user provisioning smart proxy similar to it. This proxy would expose the REST API that can be consumed by your connector or some other system and will be a part of IPA. Internally proxy will call JSON RPC against IPA and have all the busyness logic. So the recommendation is to make your connector lightwight and leverage a proxy that can be reused by other systems. We do not, however, have a good (read none) documentation of the interface, see related discussion in freeipa-users list [6]. And would appreciate if you start a wiki page to record it as you go so that we can start documenting it. In future we plan to allow insertion of the users via an ldap command https://fedorahosted.org/freeipa/ticket/3911 it is on the roadmap for this spring. What are other use cases and workflows you have? Do you have a password reset self service? If you do it might be nice external addition to FreeIPA if it integrates into the UI seamlessly. The idea is to deploy the latest FreeIPA version in our lab, start playing with it and come to this list for asking for more information we are not able to find in the wiki (just to avoid some graceful RTFMs...). Then, every time we get something working, we will also check here whether we are heading into the right direction, if we are missing some important points, etc. Does it sound? Sounds good to me, you should be able to find all documentation links in [7]. +1 Regards. [1] http://syncope.apache.org/ [2] http://tirasa.github.io/ConnId/ [3] http://java.net/projects/identityconnectors/ [4] https://github.com/Tirasa/ConnIdFreeIPABundle [5] http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html [6] https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html [7] http://www.freeipa.org/page/Documentation [8] http://www.freeipa.org/page/V3/Smart_Proxy Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope
On 01/31/2014 08:17 AM, Francesco Chicchiriccò wrote: Are you saying that we should split our development in two: (1) smart proxy, exposing the RESTful interface, developed on the basis of [8] (2) actual ConnId connector, dealing with the proxy above for implementing its own logic Correct If so, could you please point to the source code of [8]? Will then this eventually become part of FreeIPA? Quite soon. I would leave it to the team to suggest whether user and host provisioning smart proxies should be a same smart proxy or different so that they can be installed independently from each other but use the same approach. IMO haveing them separately but share the same code and approach will be more valuable to the project. But I am open to other ideas here. I am actually not sure if it is lightweight connector could actually be better than a loaded connector (e.g. without proxy), from a deployment point of view, unless you are saying either that (a) a smart proxy is already available that can be reused The idea can be reused as a starting point. IMO the easiest would be to look at the patches and use same machinery but implement different commands. or that (b) incorporating the smart proxy that we are going to develop into FreeIPA will easily happen. If done right: i.e. following process and style then yes. Please become familiar with the coding style [9] page on the wiki and other contributer guidelines [10]. Also having a design page created as a result of the preliminary investigation would go a long way towards acceptance and quality of the feature. We will gladly guide you on the way if you have specific questions [...] [2] http://tirasa.github.io/ConnId/ [3] http://java.net/projects/identityconnectors/ [4] https://github.com/Tirasa/ConnIdFreeIPABundle [5] http://tirasa.github.io/ConnId/apidocs/base/org/identityconnectors/framework/spi/operations/package-summary.html [6] https://www.redhat.com/archives/freeipa-users/2013-January/msg00109.html [7] http://www.freeipa.org/page/Documentation [8] http://www.freeipa.org/page/V3/Smart_Proxy [1] http://syncope.apache.org/ [9] http://www.freeipa.org/page/Coding_Style [10] http://www.freeipa.org/page/Contribute/Code -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA ConnId connector for usage with Apache Syncope
On 01/30/2014 11:35 AM, Francesco Chicchiriccò wrote: Hi all, I am PMC chair at Apache Syncope [1], an Open Source system for managing digital identities in enterprise environments, implemented in JEE technology and released under Apache 2.0 license. Apache Syncope can be classified as provisioning engine, and its duty can be summarized as keeping synchronized account data across different identity datastores (RDBMS, LDAP, Active Directory, ). For the actual communication with such external identity datastores, Apache Syncope relies upon ConnId [2], an Open Source fork of Sun Microsystem's Identity Connectors framework [3], left dead after Sun's acquisition by Oracle. I am also project owner at ConnId. My company Tirasa is about to start the development of a FreeIPA ConnId connector [4] that would allow the integration of FreeIPA into Apache Syncope-based IdM architectures. We are currently installing and testing FreeIPA in order to understand what is the better way to implement the communication with Syncope: do you have any suggestion about where to start from? Thanks. Can you please list provisioning use cases that you want to support? Add user? Edit user? Reset password? Keep in mind that after password is set for a user user needs to change it on the first login. This is done to make sure that no one can impersonate user and password is not know outside the system. So this is one of the first hurdles you need to deal with, i.e. fire and forget and not try to use password for anything else in IPA use case. To call into IPA you can use ipa ... command line or use out API from python client. Since you are using Java calling into ipa command is probably the best option. In future we plan to allow insertion of the users via an ldap command https://fedorahosted.org/freeipa/ticket/3911 it is on the roadmap for this spring. What are other use cases and workflows you have? Do you have a password reset self service? If you do it might be nice external addition to FreeIPA if it integrates into the UI seamlessly. Best regards. [1] http://syncope.apache.org/ [2] http://tirasa.github.io/ConnId/ [3] http://java.net/projects/identityconnectors/ [4] https://github.com/Tirasa/ConnIdFreeIPABundle -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
