Re: [Freeipa-devel] Domain level for topology plugin = 2
Dne 26.5.2015 v 16:32 Petr Spacek napsal(a): On 26.5.2015 16:16, Martin Kosek wrote: On 05/26/2015 04:13 PM, thierry bordaz wrote: On 05/26/2015 02:12 PM, Petr Spacek wrote: Hello, it came to my mind that domain level for topology plugin should actually be number 2, not 1. We already used number 1 for incompatible changes in DNS tree and I believe that it is not a good idea to have two places which say 'version 1' but and actually mean two different things. (DNS tree version 1 + domain level 1) Patch is attached. Hello, The fix looks good but that seems strange to have to set the initial version of the topology plugin to 2.0. (IIUC That is the version that will be written in dse.ldif) I would rather expects that topology plugin 1.0, would activate itself if the DomainLevel is 2.0 or more. If topology plugin 1.0 sets an internal DomainLevel_trigger=2.0 then activate itself if DomainLevel >= DomainLevel_trigger. Let's wait for Ludwig feedback. thanks thierry My personal opinion on this is to start with Domain Level 1 regardless. We already "solved" the DNS forwarders otherwise, with docs, async updates etc. I do not think we will be returning to implementing proper Domain Level support for that anyway. So I rather think that all the "Domain Level starts with 0, 1 is unused, 2 is the top one" will cause unforeseen issues I would rather like to avoid. I'm more worried about confusion in future. To to me it simply seems easier to bump one integer now than to document and explain (to users & new developers) why we have two "ones" which mean something else. Code-wise it is just an integer. Also, it can simplify logic in future when we decide to do another incompatible change in DNS tree because we will have only one integer to test (instead of checking two separate version attribute in DNS tree & domain level). +1, but I think the minimum supported domain level should be 1, not 0, because 0 means the server uses the old DNS schema, which we do not support anymore, right? If you really want to avoid unforeseen issues rather go and get rid of "major.minor" logic we have in the topology plugin right now :-) -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Domain level for topology plugin = 2
On 05/27/2015 01:04 PM, Martin Kosek wrote: On 05/26/2015 04:32 PM, Petr Spacek wrote: On 26.5.2015 16:16, Martin Kosek wrote: ... If you really want to avoid unforeseen issues rather go and get rid of "major.minor" logic we have in the topology plugin right now :-) Ludwig, I thought we agreed to avoid using major.minor format in the topology plugin Domain Level implementation, to both avoid confusion of users and to not ship unused code - right? The user does not see major/minor, so no confusion. All the plugin versions have the format 1.0 or alike and I converted the single integer domain level internally to compare to the plugin version Thanks, Martin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin
Dne 27.5.2015 v 19:38 Rob Crittenden napsal(a):
Petr Vobornik wrote:
On 05/27/2015 05:46 PM, Alexander Bokovoy wrote:
On Wed, 27 May 2015, Rob Crittenden wrote:
Petr Vobornik wrote:
On 05/20/2015 06:02 PM, Rob Crittenden wrote:
Rob Crittenden wrote:
Rob Crittenden wrote:
Add a plugin to manage service delegations, like the one allowing
the
HTTP service to obtain an ldap service ticket on behalf of the
user.
This does not include impersonation targets, so one cannot yet
limit by
user what tickets can be obtained.
There is also no referential integrity for the memberPrincipal
attribute
since it is a string and not a DN. I don't see a way around this
that
isn't either clunky or requires a 389-ds plugin, both of which are
overkill in this case IMHO.
If you wonder why all the overrides it's because all of this is
stored
in the same container, and membership-like functions are used for a
non-DN attribute (memberPrincipal).
I used Alexander's patch in the ticket as a jumping off point.
Removed a couple of hardcoded domain/realm elements in the tests.
I must be getting rustly. Forgot to include ACIs. Added now.
rob
Thanks for the design[1] and patches.
First some high level questions before any unnecessary changes are
made.
From API point of view wouldn't it be better to distinguish rules and
targets by object name so we could avoid usage of the --type option.
I.e., why expose internal schema limitations in the API?
Type could be implied by the object name and commands can do what they
do now. They could even have a common base class if needed.
E.g.:
servicedelegationrule-add MYRULE
servicedelegationrule-find
servicedelegationrule-del MYRULE
servicedelegationrule-add_member MYRULE --targets={MYTARGET,MYTARGET2}
--principals={..,..}
servicedelegationrule-remove_member MYRULE
--targets={MYTARGET,MYTARGET2} --principals={..,..}
servicedelegationtarget-add MYTARGET
servicedelegationtarget-find
servicedelegationtarget-del MYTARGET
servicedelegationtarget-add_member MYTARGET --principals={..,..}
servicedelegationtarget-remove_member MYTARGET --principals={..,..}
+1, but I would split servicedelegationrule-{add,remove}-member into
separate commands:
servicedelegationrule-add-member --principals=
servicedelegationrule-remove-member --principals=
servicedelegationrule-add-target --targets=
servicedelegationrule-remove-target --targets=
because one means "services which can delegate" and the other "services
to which can be delegated".
Yes, I used delegation instead of constraint. What is the rationale
behind 'constraint'? To me 'constraint' specifies what kind of
delegation we want to set but a goal of S4U2 proxy is to allow
something
which is not allowed by default not to create a new constraint.
[1] http://www.freeipa.org/page/V4/Service_Constraint_Delegation
I considered that but we already have this precedent in automember so
I went with it. This is complex enough with the fake memberPrincipal
stuff, I don't want to explode it with a baseclass and two subclasses
as well, plus doubling the number of new API commands.
It could tolerated in automember given that hostgroup and group rules
have exactly the same schema and purpose. The only difference is a
different target.
On the other hand, here, the purpose of both types is different. One is
a rule, second a target. Separation of the names would tell it to the
users.
+1
Number of API commands is a topic for different discussion. In short, it
could be handled better in CLI and future doc.
I don't want to discuss implementation details(complexity) yet. Issue
with API is that we are stuck with it and can't change it(much).
I very much agree.
Technically this is called constrained delegation. I was trying to
keep the name short and still descriptive. There is already aci
delegation which is a completely separate thing.
I understand that. The existing delegation might be misleading and
should be distinguished from s4u2. But imagine that somebody told you
that he created a new "service constraint rule of service A to service
B". Since there is no mention of word delegation nor S4U I wouldn't know
that it's related to ticket delegation. I would think the *opposite*.
That he constrained service A to do something with service B. But a
"service delegation rule", "constrained delegation rule" or "ticket
delegation rule" says what it is actually about.
Rather than avoiding descriptive commands we should improve a speed bash
completion.
Perhaps, but it still possible to be excessive.
A feeble attempt to remove service from the object name:
A question: Even thought the kerberos feature is called S4U (service for
user), is it limited to service principals? Services are of course the
primary target but in theory they don't have to be, right?
What is the user case for non-services? Sure, you could probably use
this to allow paul to get an ldap ticket for dave, but why would you? It
would be nice for delegating calendar entr
Re: [Freeipa-devel] [PATCH] Password vault
Dne 28.5.2015 v 07:43 Jan Cholasta napsal(a):
Dne 27.5.2015 v 07:39 Jan Cholasta napsal(a):
Dne 27.5.2015 v 02:38 Endi Sukma Dewata napsal(a):
Please take a look at the attached patch to add vault-archive/retrieve
commands.
On 4/20/2015 1:12 AM, Jan Cholasta wrote:
16) You do way too much stuff in vault_add.forward(). Only code
that
must be done on the client needs to be there, i.e. handling of the
"data", "text" and "in" options.
The vault_archive call must be in vault_add.execute(), otherwise
a) we
will be making 2 RPC calls from the client and b) it won't be
called at
all when api.env.in_server is True.
This is done by design. The vault_add.forward() generates the salt
and
the keys. The vault_archive.forward() will encrypt the data. These
operations have to be done on the client side to secure the
transport of
the data from the client through the server and finally to KRA. This
mechanism prevents the server from looking at the unencrypted data.
OK, but that does not justify that it's broken in server-side API. It
can and should be done so that it works the same way on both client
and
server.
I think the best solution would be to split the command into two
commands, server-side vault_archive_raw to archive already encrypted
data, and client-side vault_archive to encrypt data and archive them
with vault_archive_raw in its .execute(). Same thing for
vault_retrieve.
Actually I think it's better to just merge the add and archive,
reducing
the number of RPC calls. The vault_archive now will support two
types of
operations:
(a) Archive data into a new vault (it will create the vault just
before
archiving the data):
$ ipa vault-archive testvault --create --in data ...
(b) Archive data into an existing vault:
$ ipa vault-archive testvault --in data ...
The vault_add is now just a wrapper for the vault_archive(a).
If that's just an implementation detail, OK.
If it's possible to modify existing vault objects using vault-add or
create new objects using vault-archive, then NACK.
The vault-archive is now completely separate from vault-add. You can no
longer archive data while creating a vault:
$ ipa vault-add test
$ ipa vault-archive test --in secret.bin
OK.
BTW, I also think it would be better if there were 2 separate sets of
commands for binary and textual data
(vault_{archive,retrieve}_{data,text}) rather than trying to handle
everything in vault_{archive,retrieve}.
I don't think we want to provide a separate command of every possible
data type & operation combination. Users would get confused. The
archive
& retrieve commands should be able to handle all current & future data
types with options.
A command with two sets of mutually exclusive options is really two
commands in disguise, which is a good sign it should be divided into
two
actual commands.
Who are you to say users would get confused? I say they would be more
confused by a command with a plethora of mutually exclusive "options".
What other possible data types are there?
The patch has been simplified to support only binary data. The data can
be specified using either of these options:
$ ipa vault-archive test --data
$ ipa vault-archive test --in
I don't think we want to provide two separate commands for these options
although they are mutually exclusive, do we?
No, these are not really 2 different options, but rather 2 forms of the
same option, which for the lack of better support for files in the
framework have to be done as 2 options.
The add & archive combination was added for convenience, not for
optimization. This way you would be able to archive data into a new
vault using a single command. Without this, you'd have to execute
two
separate commands: add & archive, which will result in 2 RPC calls
anyway.
I think I would prefer if it was separate, as that would be
consistent
with other plugins (e.g. for objects with members, we don't allow
adding
members directly in -add, you have to use -add-member after -add).
The vault data is similar to group description, not group members.
When
creating a group we can supply the description. If not specified it
will
be blank. Archiving vault data is similar to updating the group
description.
It's similar to group members because there are separate commands to
manipulate them.
Just because there are separate commands doesn't mean vault data
(single-valued) is similar to group members (multi-valued). It uses
separate commands because of the encryption steps involved while
archiving/retrieving data.
That was not the point, but whatever.
You have to choose one of:
a) vault data is settable using vault-add and vault-mod and gettable
using vault-mod, vault-show and vault-find
b) vault data is settable using vault-archive and gettable using
vault-retrieve
Anything in between is not permitted.
As mentioned above, the add and archive commands are now separate.
21) vault_archive is not a retrieve operation, it should be
based on
L
Re: [Freeipa-devel] [PATCH] Password vault
Dne 27.5.2015 v 07:39 Jan Cholasta napsal(a):
Dne 27.5.2015 v 02:38 Endi Sukma Dewata napsal(a):
Please take a look at the attached patch to add vault-archive/retrieve
commands.
On 4/20/2015 1:12 AM, Jan Cholasta wrote:
16) You do way too much stuff in vault_add.forward(). Only code that
must be done on the client needs to be there, i.e. handling of the
"data", "text" and "in" options.
The vault_archive call must be in vault_add.execute(), otherwise
a) we
will be making 2 RPC calls from the client and b) it won't be
called at
all when api.env.in_server is True.
This is done by design. The vault_add.forward() generates the salt
and
the keys. The vault_archive.forward() will encrypt the data. These
operations have to be done on the client side to secure the
transport of
the data from the client through the server and finally to KRA. This
mechanism prevents the server from looking at the unencrypted data.
OK, but that does not justify that it's broken in server-side API. It
can and should be done so that it works the same way on both client
and
server.
I think the best solution would be to split the command into two
commands, server-side vault_archive_raw to archive already encrypted
data, and client-side vault_archive to encrypt data and archive them
with vault_archive_raw in its .execute(). Same thing for
vault_retrieve.
Actually I think it's better to just merge the add and archive,
reducing
the number of RPC calls. The vault_archive now will support two
types of
operations:
(a) Archive data into a new vault (it will create the vault just before
archiving the data):
$ ipa vault-archive testvault --create --in data ...
(b) Archive data into an existing vault:
$ ipa vault-archive testvault --in data ...
The vault_add is now just a wrapper for the vault_archive(a).
If that's just an implementation detail, OK.
If it's possible to modify existing vault objects using vault-add or
create new objects using vault-archive, then NACK.
The vault-archive is now completely separate from vault-add. You can no
longer archive data while creating a vault:
$ ipa vault-add test
$ ipa vault-archive test --in secret.bin
OK.
BTW, I also think it would be better if there were 2 separate sets of
commands for binary and textual data
(vault_{archive,retrieve}_{data,text}) rather than trying to handle
everything in vault_{archive,retrieve}.
I don't think we want to provide a separate command of every possible
data type & operation combination. Users would get confused. The
archive
& retrieve commands should be able to handle all current & future data
types with options.
A command with two sets of mutually exclusive options is really two
commands in disguise, which is a good sign it should be divided into two
actual commands.
Who are you to say users would get confused? I say they would be more
confused by a command with a plethora of mutually exclusive "options".
What other possible data types are there?
The patch has been simplified to support only binary data. The data can
be specified using either of these options:
$ ipa vault-archive test --data
$ ipa vault-archive test --in
I don't think we want to provide two separate commands for these options
although they are mutually exclusive, do we?
No, these are not really 2 different options, but rather 2 forms of the
same option, which for the lack of better support for files in the
framework have to be done as 2 options.
The add & archive combination was added for convenience, not for
optimization. This way you would be able to archive data into a new
vault using a single command. Without this, you'd have to execute two
separate commands: add & archive, which will result in 2 RPC calls
anyway.
I think I would prefer if it was separate, as that would be consistent
with other plugins (e.g. for objects with members, we don't allow
adding
members directly in -add, you have to use -add-member after -add).
The vault data is similar to group description, not group members. When
creating a group we can supply the description. If not specified it
will
be blank. Archiving vault data is similar to updating the group
description.
It's similar to group members because there are separate commands to
manipulate them.
Just because there are separate commands doesn't mean vault data
(single-valued) is similar to group members (multi-valued). It uses
separate commands because of the encryption steps involved while
archiving/retrieving data.
That was not the point, but whatever.
You have to choose one of:
a) vault data is settable using vault-add and vault-mod and gettable
using vault-mod, vault-show and vault-find
b) vault data is settable using vault-archive and gettable using
vault-retrieve
Anything in between is not permitted.
As mentioned above, the add and archive commands are now separate.
21) vault_archive is not a retrieve operation, it should be based on
LDAPUpdate instead of LDAPRetrieve. Or Command a
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
Dne 27.5.2015 v 15:54 Simo Sorce napsal(a): On Wed, 2015-05-27 at 15:47 +0200, Jan Cholasta wrote: Dne 27.5.2015 v 15:43 Simo Sorce napsal(a): On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: ipa config-mod --enable-kdcproxy=TRUE ipa config-mod --enable-kdcproxy=FALSE I don't like this approach, as it is completely inconsistent with every other optional component. There should be *one* way to handle them and there already is one, no need to reinvent the wheel. Sorry Jan, but this is really the correct approach. I don't think so. We want a boolean in LDAP to control whether the IPA Domain allows proxying or not, the code is embedded in the overall framework and has no need for explicit install/uninstall unlike the CA or DNS components. There is a boolean for every other component/service as well. If you want to add new API to manipulate the boolean, fine, but it should be done in a generic way that works for other components as well. This is the same as: ipa config-mod --enable-migration=TRUE Why is it a problem ? This is a switch to enable the migrate-ds plugin. I think it's hardly fair to compare it to a whole new component which provides a new service to the outside world. This is not a separate service. How is it not a separate service? If it's installed, MS-KKDCP is provided to the outside world, and if it's not installed MS-KKDCP is not provided to the outside world. How is this different from, say, DNS? (Besides implementation details, such as what protocols or how many daemons it uses - think about IPA as a black box for a moment.) Simo. -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
Dne 27.5.2015 v 16:01 Christian Heimes napsal(a): On 2015-05-27 15:51, Nathaniel McCallum wrote: As I understand the problem, there is an assumption that an optional component has a distinct service to start and stop. That is not the case here. This is just new config for apache. More details: The KDC Proxy uses the same Apache instance as FreeIPAs Web GUI and Tomcat. There is no extra service involved. The switch just decides if https://ipa.example.org/KdcProxy acts as a MS-KKDCP end point or returns a 404 error. FYI Tomcat does not use the same Apache instance, the Apache instance is configured to proxy requests to Tomcat. If the IPA KDC proxy package is not installed on a replica, then going to /KdcProxy will return 404, right? Why is an additional switch necessary then? My patch "0001 Provide Kerberos over HTTP (MS-KKDCP)" has more details. Christian -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
Dne 27.5.2015 v 15:51 Nathaniel McCallum napsal(a): On Wed, 2015-05-27 at 15:47 +0200, Jan Cholasta wrote: Dne 27.5.2015 v 15:43 Simo Sorce napsal(a): On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: ipa config-mod --enable-kdcproxy=TRUE ipa config-mod --enable-kdcproxy=FALSE I don't like this approach, as it is completely inconsistent with every other optional component. There should be *one* way to handle them and there already is one, no need to reinvent the wheel. Sorry Jan, but this is really the correct approach. I don't think so. We want a boolean in LDAP to control whether the IPA Domain allows proxying or not, the code is embedded in the overall framework and has no need for explicit install/uninstall unlike the CA or DNS components. There is a boolean for every other component/service as well. If you want to add new API to manipulate the boolean, fine, but it should be done in a generic way that works for other components as well. As I understand the problem, there is an assumption that an optional component has a distinct service to start and stop. That is not the case here. This is just new config for apache. Nathaniel I say that's a wrong assumption. It should not matter whether the service is provided by an actual daemon, or a set of daemons or no daemon, as that is an implementation detail. By installing KDC proxy on IPA server an actual new service is provided to the outside world, which is conceptually the same as adding DNS or CA, so I don't see why it should be handled differently. -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] Sudorules user validation help
Hey, Freeipa-devel, I'm working on ticket #3226 (https://fedorahosted.org/freeipa/ticket/3226) I've identified the problem. The sudorules add user command adds the user validations at the end of it's pre-callback using add_external_pre_callback. However, the "user" plugin pattern-matches a string for the "uid" param, because it only allows certain characters. I've been picking through the codebase and I think I have enough understanding to ask this: What if we changed the user "uid" validation to a standalone "rule" function (you can do that, right? pass in a function as a validation rule?) that would normally just assert that the pattern matches, but could have that pattern matching validation overridden in some cases. I think that's the easiest, cleanest way to change user so that sudorules and other plugins can ignore this validation if necessary (I'm trying to figure out exactly how to implement this without changing any APIs). Am I understanding the plugin params API correctly, and can I do this? Is this the best way to do this? The only other solution I see is to write sudorules-specific code in some plugin-related (either user.py or baseldap.py module, which would create unwanted coupling. Most specifically, this would be a change to the object instantiated at ipalib/plugins/user.py line 467 Thoughts and suggestions? Thanks, Drew Erny de...@redhat.com -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin
On 27/05/15 19:27, Rob Crittenden wrote:
Martin Basti wrote:
On 20/05/15 18:02, Rob Crittenden wrote:
Rob Crittenden wrote:
Rob Crittenden wrote:
Add a plugin to manage service delegations, like the one allowing the
HTTP service to obtain an ldap service ticket on behalf of the user.
This does not include impersonation targets, so one cannot yet
limit by
user what tickets can be obtained.
There is also no referential integrity for the memberPrincipal
attribute
since it is a string and not a DN. I don't see a way around this that
isn't either clunky or requires a 389-ds plugin, both of which are
overkill in this case IMHO.
If you wonder why all the overrides it's because all of this is
stored
in the same container, and membership-like functions are used for a
non-DN attribute (memberPrincipal).
I used Alexander's patch in the ticket as a jumping off point.
Removed a couple of hardcoded domain/realm elements in the tests.
I must be getting rustly. Forgot to include ACIs. Added now.
rob
Thank you.
I haven't finished review yet, but I have few notes in case you will
modify the patch.
Please fix following issues:
1) Patch needs rebase, VERSION conflict
2)
+pattern='^[a-zA-Z0-9_.][
a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.-]?$',
+pattern_errmsg='may only include letters, numbers, _, -, .,
and a space inside',
+maxlength=255,
If I count correctly, regexp allows only 254 characters, not 255, and
this regexp also allows the space at the end of the string.
IMHO '^[a-zA-Z0-9_.]([ a-zA-Z0-9_.-]*[a-zA-Z0-9_.-])?$' would work.
This is a direct copy from many places. I'd file a bug to fix all of
them I guess.
I cannot find the same regexp in current code, there are only patterns
without space, so the space issue is only in this patch.
Otherwise I agree to file a ticket to fix the length issue.
3)
There are many PEP8 errors, can you fix some of them,?
Is PEP8 a concern? What kinds of errors do we fix? For example, the
current model for defining options generates a slew of indention errors.
We try to keep PEP8 in new code, mainly indentation, blank lines, too
long lines.
Yes in test definitions and option definitions, is better to keep the
same style, but other parts of code should be PEP8.
For example these should be fixed
./ipatests/test_xmlrpc/test_serviceconstraint_plugin.py:37:13: E225
missing whitespace around operator
./ipatests/test_xmlrpc/test_serviceconstraint_plugin.py:39:1: E302
expected 2 blank lines, found 1
./ipatests/test_xmlrpc/test_serviceconstraint_plugin.py:42:1: E302
expected 2 blank lines, found 1
4)
Please use
except Exception as e: to be compatible with python 3
ok
5)
For new files we stared using shorter license header.
#
# Copyright (C) 2015 FreeIPA Contributors see COPYING for license
#
ok
I'll wait and see what falls out of the API review before making any
real changes.
rob
Martin^2
--
Martin Basti
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin
Petr Vobornik wrote:
On 05/27/2015 05:46 PM, Alexander Bokovoy wrote:
On Wed, 27 May 2015, Rob Crittenden wrote:
Petr Vobornik wrote:
On 05/20/2015 06:02 PM, Rob Crittenden wrote:
Rob Crittenden wrote:
Rob Crittenden wrote:
Add a plugin to manage service delegations, like the one allowing
the
HTTP service to obtain an ldap service ticket on behalf of the user.
This does not include impersonation targets, so one cannot yet
limit by
user what tickets can be obtained.
There is also no referential integrity for the memberPrincipal
attribute
since it is a string and not a DN. I don't see a way around this
that
isn't either clunky or requires a 389-ds plugin, both of which are
overkill in this case IMHO.
If you wonder why all the overrides it's because all of this is
stored
in the same container, and membership-like functions are used for a
non-DN attribute (memberPrincipal).
I used Alexander's patch in the ticket as a jumping off point.
Removed a couple of hardcoded domain/realm elements in the tests.
I must be getting rustly. Forgot to include ACIs. Added now.
rob
Thanks for the design[1] and patches.
First some high level questions before any unnecessary changes are
made.
From API point of view wouldn't it be better to distinguish rules and
targets by object name so we could avoid usage of the --type option.
I.e., why expose internal schema limitations in the API?
Type could be implied by the object name and commands can do what they
do now. They could even have a common base class if needed.
E.g.:
servicedelegationrule-add MYRULE
servicedelegationrule-find
servicedelegationrule-del MYRULE
servicedelegationrule-add_member MYRULE --targets={MYTARGET,MYTARGET2}
--principals={..,..}
servicedelegationrule-remove_member MYRULE
--targets={MYTARGET,MYTARGET2} --principals={..,..}
servicedelegationtarget-add MYTARGET
servicedelegationtarget-find
servicedelegationtarget-del MYTARGET
servicedelegationtarget-add_member MYTARGET --principals={..,..}
servicedelegationtarget-remove_member MYTARGET --principals={..,..}
Yes, I used delegation instead of constraint. What is the rationale
behind 'constraint'? To me 'constraint' specifies what kind of
delegation we want to set but a goal of S4U2 proxy is to allow
something
which is not allowed by default not to create a new constraint.
[1] http://www.freeipa.org/page/V4/Service_Constraint_Delegation
I considered that but we already have this precedent in automember so
I went with it. This is complex enough with the fake memberPrincipal
stuff, I don't want to explode it with a baseclass and two subclasses
as well, plus doubling the number of new API commands.
It could tolerated in automember given that hostgroup and group rules
have exactly the same schema and purpose. The only difference is a
different target.
On the other hand, here, the purpose of both types is different. One is
a rule, second a target. Separation of the names would tell it to the
users.
Number of API commands is a topic for different discussion. In short, it
could be handled better in CLI and future doc.
I don't want to discuss implementation details(complexity) yet. Issue
with API is that we are stuck with it and can't change it(much).
Technically this is called constrained delegation. I was trying to
keep the name short and still descriptive. There is already aci
delegation which is a completely separate thing.
I understand that. The existing delegation might be misleading and
should be distinguished from s4u2. But imagine that somebody told you
that he created a new "service constraint rule of service A to service
B". Since there is no mention of word delegation nor S4U I wouldn't know
that it's related to ticket delegation. I would think the *opposite*.
That he constrained service A to do something with service B. But a
"service delegation rule", "constrained delegation rule" or "ticket
delegation rule" says what it is actually about.
Rather than avoiding descriptive commands we should improve a speed bash
completion.
Perhaps, but it still possible to be excessive.
A feeble attempt to remove service from the object name:
A question: Even thought the kerberos feature is called S4U (service for
user), is it limited to service principals? Services are of course the
primary target but in theory they don't have to be, right?
What is the user case for non-services? Sure, you could probably use
this to allow paul to get an ldap ticket for dave, but why would you? It
would be nice for delegating calendar entries for a personal assistant,
for example, but would be an audit nightmare.
I agree with Rob. There is also a need to address principals which
aren't directly accessible as IPA objects in the framework (think about
trusts, for example).
I don't think this part is affected at all. The API's have the same
capabilities.
I'm not going to argue too much about this. I imagine that a vast
majority of users will never use this at all, and even then probab
Re: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin
Martin Basti wrote:
On 20/05/15 18:02, Rob Crittenden wrote:
Rob Crittenden wrote:
Rob Crittenden wrote:
Add a plugin to manage service delegations, like the one allowing the
HTTP service to obtain an ldap service ticket on behalf of the user.
This does not include impersonation targets, so one cannot yet limit by
user what tickets can be obtained.
There is also no referential integrity for the memberPrincipal
attribute
since it is a string and not a DN. I don't see a way around this that
isn't either clunky or requires a 389-ds plugin, both of which are
overkill in this case IMHO.
If you wonder why all the overrides it's because all of this is stored
in the same container, and membership-like functions are used for a
non-DN attribute (memberPrincipal).
I used Alexander's patch in the ticket as a jumping off point.
Removed a couple of hardcoded domain/realm elements in the tests.
I must be getting rustly. Forgot to include ACIs. Added now.
rob
Thank you.
I haven't finished review yet, but I have few notes in case you will
modify the patch.
Please fix following issues:
1) Patch needs rebase, VERSION conflict
2)
+pattern='^[a-zA-Z0-9_.][ a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.-]?$',
+pattern_errmsg='may only include letters, numbers, _, -, .,
and a space inside',
+maxlength=255,
If I count correctly, regexp allows only 254 characters, not 255, and
this regexp also allows the space at the end of the string.
IMHO '^[a-zA-Z0-9_.]([ a-zA-Z0-9_.-]*[a-zA-Z0-9_.-])?$' would work.
This is a direct copy from many places. I'd file a bug to fix all of
them I guess.
3)
There are many PEP8 errors, can you fix some of them,?
Is PEP8 a concern? What kinds of errors do we fix? For example, the
current model for defining options generates a slew of indention errors.
4)
Please use
except Exception as e: to be compatible with python 3
ok
5)
For new files we stared using shorter license header.
#
# Copyright (C) 2015 FreeIPA Contributors see COPYING for license
#
ok
I'll wait and see what falls out of the API review before making any
real changes.
rob
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin
On 05/27/2015 05:46 PM, Alexander Bokovoy wrote:
On Wed, 27 May 2015, Rob Crittenden wrote:
Petr Vobornik wrote:
On 05/20/2015 06:02 PM, Rob Crittenden wrote:
Rob Crittenden wrote:
Rob Crittenden wrote:
Add a plugin to manage service delegations, like the one allowing the
HTTP service to obtain an ldap service ticket on behalf of the user.
This does not include impersonation targets, so one cannot yet
limit by
user what tickets can be obtained.
There is also no referential integrity for the memberPrincipal
attribute
since it is a string and not a DN. I don't see a way around this that
isn't either clunky or requires a 389-ds plugin, both of which are
overkill in this case IMHO.
If you wonder why all the overrides it's because all of this is
stored
in the same container, and membership-like functions are used for a
non-DN attribute (memberPrincipal).
I used Alexander's patch in the ticket as a jumping off point.
Removed a couple of hardcoded domain/realm elements in the tests.
I must be getting rustly. Forgot to include ACIs. Added now.
rob
Thanks for the design[1] and patches.
First some high level questions before any unnecessary changes are made.
From API point of view wouldn't it be better to distinguish rules and
targets by object name so we could avoid usage of the --type option.
I.e., why expose internal schema limitations in the API?
Type could be implied by the object name and commands can do what they
do now. They could even have a common base class if needed.
E.g.:
servicedelegationrule-add MYRULE
servicedelegationrule-find
servicedelegationrule-del MYRULE
servicedelegationrule-add_member MYRULE --targets={MYTARGET,MYTARGET2}
--principals={..,..}
servicedelegationrule-remove_member MYRULE
--targets={MYTARGET,MYTARGET2} --principals={..,..}
servicedelegationtarget-add MYTARGET
servicedelegationtarget-find
servicedelegationtarget-del MYTARGET
servicedelegationtarget-add_member MYTARGET --principals={..,..}
servicedelegationtarget-remove_member MYTARGET --principals={..,..}
Yes, I used delegation instead of constraint. What is the rationale
behind 'constraint'? To me 'constraint' specifies what kind of
delegation we want to set but a goal of S4U2 proxy is to allow something
which is not allowed by default not to create a new constraint.
[1] http://www.freeipa.org/page/V4/Service_Constraint_Delegation
I considered that but we already have this precedent in automember so
I went with it. This is complex enough with the fake memberPrincipal
stuff, I don't want to explode it with a baseclass and two subclasses
as well, plus doubling the number of new API commands.
It could tolerated in automember given that hostgroup and group rules
have exactly the same schema and purpose. The only difference is a
different target.
On the other hand, here, the purpose of both types is different. One is
a rule, second a target. Separation of the names would tell it to the users.
Number of API commands is a topic for different discussion. In short, it
could be handled better in CLI and future doc.
I don't want to discuss implementation details(complexity) yet. Issue
with API is that we are stuck with it and can't change it(much).
Technically this is called constrained delegation. I was trying to
keep the name short and still descriptive. There is already aci
delegation which is a completely separate thing.
I understand that. The existing delegation might be misleading and
should be distinguished from s4u2. But imagine that somebody told you
that he created a new "service constraint rule of service A to service
B". Since there is no mention of word delegation nor S4U I wouldn't know
that it's related to ticket delegation. I would think the *opposite*.
That he constrained service A to do something with service B. But a
"service delegation rule", "constrained delegation rule" or "ticket
delegation rule" says what it is actually about.
Rather than avoiding descriptive commands we should improve a speed bash
completion.
A feeble attempt to remove service from the object name:
A question: Even thought the kerberos feature is called S4U (service for
user), is it limited to service principals? Services are of course the
primary target but in theory they don't have to be, right?
I agree with Rob. There is also a need to address principals which
aren't directly accessible as IPA objects in the framework (think about
trusts, for example).
I don't think this part is affected at all. The API's have the same
capabilities.
--
Petr Vobornik
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin
On 20/05/15 18:02, Rob Crittenden wrote:
Rob Crittenden wrote:
Rob Crittenden wrote:
Add a plugin to manage service delegations, like the one allowing the
HTTP service to obtain an ldap service ticket on behalf of the user.
This does not include impersonation targets, so one cannot yet limit by
user what tickets can be obtained.
There is also no referential integrity for the memberPrincipal
attribute
since it is a string and not a DN. I don't see a way around this that
isn't either clunky or requires a 389-ds plugin, both of which are
overkill in this case IMHO.
If you wonder why all the overrides it's because all of this is stored
in the same container, and membership-like functions are used for a
non-DN attribute (memberPrincipal).
I used Alexander's patch in the ticket as a jumping off point.
Removed a couple of hardcoded domain/realm elements in the tests.
I must be getting rustly. Forgot to include ACIs. Added now.
rob
Thank you.
I haven't finished review yet, but I have few notes in case you will
modify the patch.
Please fix following issues:
1) Patch needs rebase, VERSION conflict
2)
+pattern='^[a-zA-Z0-9_.][ a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.-]?$',
+pattern_errmsg='may only include letters, numbers, _, -, .,
and a space inside',
+maxlength=255,
If I count correctly, regexp allows only 254 characters, not 255, and
this regexp also allows the space at the end of the string.
IMHO '^[a-zA-Z0-9_.]([ a-zA-Z0-9_.-]*[a-zA-Z0-9_.-])?$' would work.
3)
There are many PEP8 errors, can you fix some of them,?
4)
Please use
except Exception as e: to be compatible with python 3
5)
For new files we stared using shorter license header.
#
# Copyright (C) 2015 FreeIPA Contributors see COPYING for license
#
--
Martin Basti
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin
On Wed, 2015-05-27 at 18:46 +0300, Alexander Bokovoy wrote:
> On Wed, 27 May 2015, Rob Crittenden wrote:
> >Petr Vobornik wrote:
> >>On 05/20/2015 06:02 PM, Rob Crittenden wrote:
> >>>Rob Crittenden wrote:
> Rob Crittenden wrote:
> >Add a plugin to manage service delegations, like the one allowing the
> >HTTP service to obtain an ldap service ticket on behalf of the user.
> >
> >This does not include impersonation targets, so one cannot yet limit by
> >user what tickets can be obtained.
> >
> >There is also no referential integrity for the memberPrincipal
> >attribute
> >since it is a string and not a DN. I don't see a way around this that
> >isn't either clunky or requires a 389-ds plugin, both of which are
> >overkill in this case IMHO.
> >
> >If you wonder why all the overrides it's because all of this is stored
> >in the same container, and membership-like functions are used for a
> >non-DN attribute (memberPrincipal).
> >
> >I used Alexander's patch in the ticket as a jumping off point.
>
> Removed a couple of hardcoded domain/realm elements in the tests.
> >>>
> >>>I must be getting rustly. Forgot to include ACIs. Added now.
> >>>
> >>>rob
> >>>
> >>
> >>Thanks for the design[1] and patches.
> >>
> >>First some high level questions before any unnecessary changes are made.
> >>
> >> From API point of view wouldn't it be better to distinguish rules and
> >>targets by object name so we could avoid usage of the --type option.
> >>I.e., why expose internal schema limitations in the API?
> >>
> >>Type could be implied by the object name and commands can do what they
> >>do now. They could even have a common base class if needed.
> >>
> >>E.g.:
> >>
> >>servicedelegationrule-add MYRULE
> >>servicedelegationrule-find
> >>servicedelegationrule-del MYRULE
> >>servicedelegationrule-add_member MYRULE --targets={MYTARGET,MYTARGET2}
> >>--principals={..,..}
> >>servicedelegationrule-remove_member MYRULE
> >>--targets={MYTARGET,MYTARGET2} --principals={..,..}
> >>
> >>servicedelegationtarget-add MYTARGET
> >>servicedelegationtarget-find
> >>servicedelegationtarget-del MYTARGET
> >>servicedelegationtarget-add_member MYTARGET --principals={..,..}
> >>servicedelegationtarget-remove_member MYTARGET --principals={..,..}
> >>
> >>Yes, I used delegation instead of constraint. What is the rationale
> >>behind 'constraint'? To me 'constraint' specifies what kind of
> >>delegation we want to set but a goal of S4U2 proxy is to allow something
> >>which is not allowed by default not to create a new constraint.
> >>
> >>[1] http://www.freeipa.org/page/V4/Service_Constraint_Delegation
> >
> >I considered that but we already have this precedent in automember so
> >I went with it. This is complex enough with the fake memberPrincipal
> >stuff, I don't want to explode it with a baseclass and two subclasses
> >as well, plus doubling the number of new API commands.
> >
> >Technically this is called constrained delegation. I was trying to
> >keep the name short and still descriptive. There is already aci
> >delegation which is a completely separate thing.
> I agree with Rob. There is also a need to address principals which
> aren't directly accessible as IPA objects in the framework (think about
> trusts, for example).
Shouldn't the commands then be: constraineddelegation-add etc...
serviceconstraint doesn't really help understanding what this is all
about. If service is in the name I agree with Petr that
servicedelegation makes much more sense.
On the API I also do not like to split rules into 2 apis, but I see no
other option really.
Something like the following makes it clear what you are operating on:
ipa servicedelegationtarget-add [principals]
ipa servicedelegation-add --members [principals] --targets [targets]
Example:
ipa servicedelegationtarget-add ipa-ldap ldap/ipa1.example.com
ldap/ipa2.example.com
This would add ldap/ipa1.example@example.com and
ldap/ipa2.example@example.com to cn=ipa-ldap-delegation-targets
(note that rule name is shorter than DN and principals are automatically
augmented with the REALM part if not provided on the command line)
ipa servicedelegation-add ipa-http --targets ipa-ldap
This would create the cn=ipa-http-delegation rule and add
cn=ipa-ldap-delegation-targets,... to it (note again that the rule name
and target name are shortcuts wrt the actual DNs used)
ipa servicedelegation-mod ipa-http --add-members HTTP/ipa1.example.com
HTTP/ipa2.example.com
This would add member principals to cn=ipa-http-delegation
The full list of APIs would be:
ipa servicedelegation-add [--members principals] [--targets targets]
ipa servicedelegation-del
ipa servicedelegation-mod [--add-members Ps] [--del-members Ps]
[--add-targets Ts] [--del-targets Ts]
ipa servicedelegation-show
ipa servicedelegation-find [rule]
ipa servicedelegtarget-add [--members principals]
ipa servicedelegtarget-del
ipa servicedelegtarget-m
Re: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates
On Wed, May 27, 2015 at 06:12:50PM +0200, Martin Basti wrote:
> On 27/05/15 15:53, Fraser Tweedale wrote:
> >This patch adds supports for multiple user / host certificates. No
> >schema change is needed ('usercertificate' attribute is already
> >multi-value). The revoke-previous-cert behaviour of host-mod and
> >user-mod has been removed but revocation behaviour of -del and
> >-disable is preserved.
> >
> >The latest profiles/caacl patchset (0001..0013 v5) depends on this
> >patch for correct cert-request behaviour.
> >
> >There is one design question (or maybe more, let me know): the
> >`--out=FILENAME' option to {host,service} show saves ONE certificate
> >to the named file. I propose to either:
> >
> >a) write all certs, suffixing suggested filename with either a
> >sequential numerical index, e.g. "cert.pem" becomes
> >"cert.pem.1", "cert.pem.2", and so on; or
> >
> >b) as above, but suffix with serial number and, if there are
> >different issues, some issuer-identifying information.
> >
> >Let me know your thoughts.
> >
> >Thanks,
> >Fraser
> >
> >
> Is there a possible way how to store certificates into one file?
> I read about possibilities to have multiple certs in one .pem file, but I'm
> not cert guru :)
It is possible, check e.g. /etc/pki/tls/cert.pem.
bye,
Sumit
>
> I personally vote for serial number in case there are multiple certificates,
> if ^ is no possible.
>
>
> 1)
> +if len(certs) > 0:
>
> please use only,
> if certs:
>
> 2)
> You need to re-generate API/ACI.txt in this patch
>
> 3)
> syntax error:
> +for dercert in certs_der
>
>
> 4)
> command
> ipa user-mod ca_user --certificate=
>
> removes the current certificate from the LDAP, by design.
> Should be the old certificate(s) revoked? You removed that part in the code.
>
> only the --addattr='usercertificate=' appends new value there
>
> --
> Martin Basti
>
> --
> Manage your subscription for the Freeipa-devel mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-devel
> Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates
On 27/05/15 15:53, Fraser Tweedale wrote:
This patch adds supports for multiple user / host certificates. No
schema change is needed ('usercertificate' attribute is already
multi-value). The revoke-previous-cert behaviour of host-mod and
user-mod has been removed but revocation behaviour of -del and
-disable is preserved.
The latest profiles/caacl patchset (0001..0013 v5) depends on this
patch for correct cert-request behaviour.
There is one design question (or maybe more, let me know): the
`--out=FILENAME' option to {host,service} show saves ONE certificate
to the named file. I propose to either:
a) write all certs, suffixing suggested filename with either a
sequential numerical index, e.g. "cert.pem" becomes
"cert.pem.1", "cert.pem.2", and so on; or
b) as above, but suffix with serial number and, if there are
different issues, some issuer-identifying information.
Let me know your thoughts.
Thanks,
Fraser
Is there a possible way how to store certificates into one file?
I read about possibilities to have multiple certs in one .pem file, but
I'm not cert guru :)
I personally vote for serial number in case there are multiple
certificates, if ^ is no possible.
1)
+if len(certs) > 0:
please use only,
if certs:
2)
You need to re-generate API/ACI.txt in this patch
3)
syntax error:
+for dercert in certs_der
4)
command
ipa user-mod ca_user --certificate=
removes the current certificate from the LDAP, by design.
Should be the old certificate(s) revoked? You removed that part in the code.
only the --addattr='usercertificate=' appends new value there
--
Martin Basti
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin
On Wed, 27 May 2015, Rob Crittenden wrote:
Petr Vobornik wrote:
On 05/20/2015 06:02 PM, Rob Crittenden wrote:
Rob Crittenden wrote:
Rob Crittenden wrote:
Add a plugin to manage service delegations, like the one allowing the
HTTP service to obtain an ldap service ticket on behalf of the user.
This does not include impersonation targets, so one cannot yet limit by
user what tickets can be obtained.
There is also no referential integrity for the memberPrincipal
attribute
since it is a string and not a DN. I don't see a way around this that
isn't either clunky or requires a 389-ds plugin, both of which are
overkill in this case IMHO.
If you wonder why all the overrides it's because all of this is stored
in the same container, and membership-like functions are used for a
non-DN attribute (memberPrincipal).
I used Alexander's patch in the ticket as a jumping off point.
Removed a couple of hardcoded domain/realm elements in the tests.
I must be getting rustly. Forgot to include ACIs. Added now.
rob
Thanks for the design[1] and patches.
First some high level questions before any unnecessary changes are made.
From API point of view wouldn't it be better to distinguish rules and
targets by object name so we could avoid usage of the --type option.
I.e., why expose internal schema limitations in the API?
Type could be implied by the object name and commands can do what they
do now. They could even have a common base class if needed.
E.g.:
servicedelegationrule-add MYRULE
servicedelegationrule-find
servicedelegationrule-del MYRULE
servicedelegationrule-add_member MYRULE --targets={MYTARGET,MYTARGET2}
--principals={..,..}
servicedelegationrule-remove_member MYRULE
--targets={MYTARGET,MYTARGET2} --principals={..,..}
servicedelegationtarget-add MYTARGET
servicedelegationtarget-find
servicedelegationtarget-del MYTARGET
servicedelegationtarget-add_member MYTARGET --principals={..,..}
servicedelegationtarget-remove_member MYTARGET --principals={..,..}
Yes, I used delegation instead of constraint. What is the rationale
behind 'constraint'? To me 'constraint' specifies what kind of
delegation we want to set but a goal of S4U2 proxy is to allow something
which is not allowed by default not to create a new constraint.
[1] http://www.freeipa.org/page/V4/Service_Constraint_Delegation
I considered that but we already have this precedent in automember so
I went with it. This is complex enough with the fake memberPrincipal
stuff, I don't want to explode it with a baseclass and two subclasses
as well, plus doubling the number of new API commands.
Technically this is called constrained delegation. I was trying to
keep the name short and still descriptive. There is already aci
delegation which is a completely separate thing.
I agree with Rob. There is also a need to address principals which
aren't directly accessible as IPA objects in the framework (think about
trusts, for example).
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin
Petr Vobornik wrote:
On 05/20/2015 06:02 PM, Rob Crittenden wrote:
Rob Crittenden wrote:
Rob Crittenden wrote:
Add a plugin to manage service delegations, like the one allowing the
HTTP service to obtain an ldap service ticket on behalf of the user.
This does not include impersonation targets, so one cannot yet limit by
user what tickets can be obtained.
There is also no referential integrity for the memberPrincipal
attribute
since it is a string and not a DN. I don't see a way around this that
isn't either clunky or requires a 389-ds plugin, both of which are
overkill in this case IMHO.
If you wonder why all the overrides it's because all of this is stored
in the same container, and membership-like functions are used for a
non-DN attribute (memberPrincipal).
I used Alexander's patch in the ticket as a jumping off point.
Removed a couple of hardcoded domain/realm elements in the tests.
I must be getting rustly. Forgot to include ACIs. Added now.
rob
Thanks for the design[1] and patches.
First some high level questions before any unnecessary changes are made.
From API point of view wouldn't it be better to distinguish rules and
targets by object name so we could avoid usage of the --type option.
I.e., why expose internal schema limitations in the API?
Type could be implied by the object name and commands can do what they
do now. They could even have a common base class if needed.
E.g.:
servicedelegationrule-add MYRULE
servicedelegationrule-find
servicedelegationrule-del MYRULE
servicedelegationrule-add_member MYRULE --targets={MYTARGET,MYTARGET2}
--principals={..,..}
servicedelegationrule-remove_member MYRULE
--targets={MYTARGET,MYTARGET2} --principals={..,..}
servicedelegationtarget-add MYTARGET
servicedelegationtarget-find
servicedelegationtarget-del MYTARGET
servicedelegationtarget-add_member MYTARGET --principals={..,..}
servicedelegationtarget-remove_member MYTARGET --principals={..,..}
Yes, I used delegation instead of constraint. What is the rationale
behind 'constraint'? To me 'constraint' specifies what kind of
delegation we want to set but a goal of S4U2 proxy is to allow something
which is not allowed by default not to create a new constraint.
[1] http://www.freeipa.org/page/V4/Service_Constraint_Delegation
I considered that but we already have this precedent in automember so I
went with it. This is complex enough with the fake memberPrincipal
stuff, I don't want to explode it with a baseclass and two subclasses as
well, plus doubling the number of new API commands.
Technically this is called constrained delegation. I was trying to keep
the name short and still descriptive. There is already aci delegation
which is a completely separate thing.
rob
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 1112 Add service constraint delegation plugin
On 05/20/2015 06:02 PM, Rob Crittenden wrote:
Rob Crittenden wrote:
Rob Crittenden wrote:
Add a plugin to manage service delegations, like the one allowing the
HTTP service to obtain an ldap service ticket on behalf of the user.
This does not include impersonation targets, so one cannot yet limit by
user what tickets can be obtained.
There is also no referential integrity for the memberPrincipal attribute
since it is a string and not a DN. I don't see a way around this that
isn't either clunky or requires a 389-ds plugin, both of which are
overkill in this case IMHO.
If you wonder why all the overrides it's because all of this is stored
in the same container, and membership-like functions are used for a
non-DN attribute (memberPrincipal).
I used Alexander's patch in the ticket as a jumping off point.
Removed a couple of hardcoded domain/realm elements in the tests.
I must be getting rustly. Forgot to include ACIs. Added now.
rob
Thanks for the design[1] and patches.
First some high level questions before any unnecessary changes are made.
From API point of view wouldn't it be better to distinguish rules and
targets by object name so we could avoid usage of the --type option.
I.e., why expose internal schema limitations in the API?
Type could be implied by the object name and commands can do what they
do now. They could even have a common base class if needed.
E.g.:
servicedelegationrule-add MYRULE
servicedelegationrule-find
servicedelegationrule-del MYRULE
servicedelegationrule-add_member MYRULE --targets={MYTARGET,MYTARGET2}
--principals={..,..}
servicedelegationrule-remove_member MYRULE
--targets={MYTARGET,MYTARGET2} --principals={..,..}
servicedelegationtarget-add MYTARGET
servicedelegationtarget-find
servicedelegationtarget-del MYTARGET
servicedelegationtarget-add_member MYTARGET --principals={..,..}
servicedelegationtarget-remove_member MYTARGET --principals={..,..}
Yes, I used delegation instead of constraint. What is the rationale
behind 'constraint'? To me 'constraint' specifies what kind of
delegation we want to set but a goal of S4U2 proxy is to allow something
which is not allowed by default not to create a new constraint.
[1] http://www.freeipa.org/page/V4/Service_Constraint_Delegation
--
Petr Vobornik
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] New replica installation and topology - we need stable base
On Wed, 2015-05-27 at 16:59 +0200, Martin Kosek wrote: > Hello all, > > As FreeIPA 4.2 deadlines are approaching us slowly, there is a concern that > not > all of the new replica install way (replication-package-less) based on > Custodia > would be done and finished in time. > > There will be certainly a lot of integration hurdles, in making sure that the > installed replica can ask for all needed secrets and that the server can > provide them and ensure proper encryption. The encryption part is not a concern, but proper integration of all these interconnected and inter-dependent components is. > My question is - if we postpone new replica promotion way&Custodia, what is > needed to make FreeIPA 4.2 replica installation and topology management > GA-ready and finished? > > This is the status of related functions, as I see it: > > Domain Levels > - Done, committed > - Defaults to Level 1, i.e. Topology plugin powered infra enabled This default is only for a *new* domain right ? If you join a replica it should not automatically enable topology. > Topology plugin > - We have the base plugin and it's installation pushed > - There is a critical bug that needs to be solved - #5035 > - API&UI is in works (Petr Vobornik). We already committed the new server-* > commands used there. Overall, AFAIU the API should be mostly functionally > complete > - Plugin is enabled during installation, but we still use the simple auth with > DM password during replica creation process. I think we planned to use GSSAPI, > no? Is anything else needed in the replica creation process, except fixing > #5035? > > Given this summary, if we forget about the Custodia parts for a moment, it > seems to me that the new Topology is almost functionally complete and we only > miss the management API. Is that correct or we miss some bigger piece? > > I am for example not sure if the "IPA masters" hostgroup is needed for > Topology > work without Custodia, I think Ludwig used some other group for authorization > purposes in Topology. The hostgroup is needed regardless of Custodia, IIRC. Simo. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] New replica installation and topology - we need stable base
On 05/27/2015 04:59 PM, Martin Kosek wrote: > Hello all, > > As FreeIPA 4.2 deadlines are approaching us slowly, there is a concern that > not > all of the new replica install way (replication-package-less) based on > Custodia > would be done and finished in time. > > There will be certainly a lot of integration hurdles, in making sure that the > installed replica can ask for all needed secrets and that the server can > provide them and ensure proper encryption. > > My question is - if we postpone new replica promotion way&Custodia, what is > needed to make FreeIPA 4.2 replica installation and topology management > GA-ready and finished? > > This is the status of related functions, as I see it: > > Domain Levels > - Done, committed > - Defaults to Level 1, i.e. Topology plugin powered infra enabled > > Topology plugin > - We have the base plugin and it's installation pushed > - There is a critical bug that needs to be solved - #5035 Which actually blocks the testing of the feature. Once it is resolved, we need several days to properly test the plugin. I anticipate at least a week, if there will be no other blockers. This does not include WebUI part of the plugin. > - API&UI is in works (Petr Vobornik). We already committed the new server-* > commands used there. Overall, AFAIU the API should be mostly functionally > complete > - Plugin is enabled during installation, but we still use the simple auth with > DM password during replica creation process. I think we planned to use GSSAPI, > no? Is anything else needed in the replica creation process, except fixing > #5035? > > Given this summary, if we forget about the Custodia parts for a moment, it > seems to me that the new Topology is almost functionally complete and we only > miss the management API. Is that correct or we miss some bigger piece? > > I am for example not sure if the "IPA masters" hostgroup is needed for > Topology > work without Custodia, I think Ludwig used some other group for authorization > purposes in Topology. > > Thanks. > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] New replica installation and topology - we need stable base
Hello all, As FreeIPA 4.2 deadlines are approaching us slowly, there is a concern that not all of the new replica install way (replication-package-less) based on Custodia would be done and finished in time. There will be certainly a lot of integration hurdles, in making sure that the installed replica can ask for all needed secrets and that the server can provide them and ensure proper encryption. My question is - if we postpone new replica promotion way&Custodia, what is needed to make FreeIPA 4.2 replica installation and topology management GA-ready and finished? This is the status of related functions, as I see it: Domain Levels - Done, committed - Defaults to Level 1, i.e. Topology plugin powered infra enabled Topology plugin - We have the base plugin and it's installation pushed - There is a critical bug that needs to be solved - #5035 - API&UI is in works (Petr Vobornik). We already committed the new server-* commands used there. Overall, AFAIU the API should be mostly functionally complete - Plugin is enabled during installation, but we still use the simple auth with DM password during replica creation process. I think we planned to use GSSAPI, no? Is anything else needed in the replica creation process, except fixing #5035? Given this summary, if we forget about the Custodia parts for a moment, it seems to me that the new Topology is almost functionally complete and we only miss the management API. Is that correct or we miss some bigger piece? I am for example not sure if the "IPA masters" hostgroup is needed for Topology work without Custodia, I think Ludwig used some other group for authorization purposes in Topology. Thanks. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Fix password changes via kadmin
On 05/27/2015 04:33 PM, Martin Kosek wrote: On 05/27/2015 03:55 PM, Alexander Bokovoy wrote: On Wed, 27 May 2015, Simo Sorce wrote: On Wed, 2015-05-27 at 15:25 +0200, Martin Babinsky wrote: On 05/25/2015 10:48 AM, Martin Babinsky wrote: On 04/06/2015 12:53 AM, Simo Sorce wrote: Fix for bug 4914. I've tested it locally and seem to do exactly what is needed. I couldn't detect any side effects, except that if you use kadmin to get a randomized password for a service then you'll get a key for all supported types (currently aes256, aes128, des3, rc4, camellia128, camellia256) instead of just the default ones (aes256, aes128, des3, rc4) if you do not specify enctypes. I think that is fine, we use ipa-getkeytab anyway in the normal course of business and that one uses a different code path. Simo. Hi Simo, the patch works as expected. My only gripe is with the duplicate code in 'daemons/ipa-kdb/ipa_kdb.c' between lines 389 and 455. It could be made into a single function to get key encoding/salt types from LDAP (see my feeble and untested attempt which I attached). ACK. I will then send the patch fixing duplicate code separately once I consult it with somebody more skilled in C than myself. Thanks, added your reviewed-by and pushed to master. Martin, should we push this to other branches too ? I think we also need this in 4.1 so that it can go to Fedora, Debian, and RHEL releases. 4.2 will be released soon, but if you are confident about the patch so that it does not break stuff, we may add it to 4.1.x too, given the positive impact. I actually tested it also with 4.1 branch with no problem. -- Martin^3 Babinsky -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Fix password changes via kadmin
On Wed, 2015-05-27 at 16:33 +0200, Martin Kosek wrote: > On 05/27/2015 03:55 PM, Alexander Bokovoy wrote: > > On Wed, 27 May 2015, Simo Sorce wrote: > >> On Wed, 2015-05-27 at 15:25 +0200, Martin Babinsky wrote: > >>> On 05/25/2015 10:48 AM, Martin Babinsky wrote: > >>> > On 04/06/2015 12:53 AM, Simo Sorce wrote: > >>> >> Fix for bug 4914. > >>> >> > >>> >> I've tested it locally and seem to do exactly what is needed. I > >>> >> couldn't > >>> >> detect any side effects, except that if you use kadmin to get a > >>> >> randomized password for a service then you'll get a key for all > >>> >> supported types (currently aes256, aes128, des3, rc4, camellia128, > >>> >> camellia256) instead of just the default ones (aes256, aes128, des3, > >>> >> rc4) if you do not specify enctypes. I think that is fine, we use > >>> >> ipa-getkeytab anyway in the normal course of business and that one uses > >>> >> a different code path. > >>> >> > >>> >> Simo. > >>> >> > >>> >> > >>> >> > >>> > > >>> > Hi Simo, > >>> > > >>> > the patch works as expected. > >>> > > >>> > My only gripe is with the duplicate code in 'daemons/ipa-kdb/ipa_kdb.c' > >>> > between lines 389 and 455. It could be made into a single function to > >>> > get key encoding/salt types from LDAP (see my feeble and untested > >>> > attempt which I attached). > >>> > > >>> > > >>> > > >>> ACK. > >>> > >>> I will then send the patch fixing duplicate code separately once I > >>> consult it with somebody more skilled in C than myself. > >>> > >> > >> Thanks, added your reviewed-by and pushed to master. > >> > >> Martin, should we push this to other branches too ? > > I think we also need this in 4.1 so that it can go to Fedora, Debian, > > and RHEL releases. > > 4.2 will be released soon, but if you are confident about the patch so that it > does not break stuff, we may add it to 4.1.x too, given the positive impact. Please backport to 4.1 then, it really is only a net positive afaik. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Fix password changes via kadmin
On 05/27/2015 03:55 PM, Alexander Bokovoy wrote: > On Wed, 27 May 2015, Simo Sorce wrote: >> On Wed, 2015-05-27 at 15:25 +0200, Martin Babinsky wrote: >>> On 05/25/2015 10:48 AM, Martin Babinsky wrote: >>> > On 04/06/2015 12:53 AM, Simo Sorce wrote: >>> >> Fix for bug 4914. >>> >> >>> >> I've tested it locally and seem to do exactly what is needed. I couldn't >>> >> detect any side effects, except that if you use kadmin to get a >>> >> randomized password for a service then you'll get a key for all >>> >> supported types (currently aes256, aes128, des3, rc4, camellia128, >>> >> camellia256) instead of just the default ones (aes256, aes128, des3, >>> >> rc4) if you do not specify enctypes. I think that is fine, we use >>> >> ipa-getkeytab anyway in the normal course of business and that one uses >>> >> a different code path. >>> >> >>> >> Simo. >>> >> >>> >> >>> >> >>> > >>> > Hi Simo, >>> > >>> > the patch works as expected. >>> > >>> > My only gripe is with the duplicate code in 'daemons/ipa-kdb/ipa_kdb.c' >>> > between lines 389 and 455. It could be made into a single function to >>> > get key encoding/salt types from LDAP (see my feeble and untested >>> > attempt which I attached). >>> > >>> > >>> > >>> ACK. >>> >>> I will then send the patch fixing duplicate code separately once I >>> consult it with somebody more skilled in C than myself. >>> >> >> Thanks, added your reviewed-by and pushed to master. >> >> Martin, should we push this to other branches too ? > I think we also need this in 4.1 so that it can go to Fedora, Debian, > and RHEL releases. 4.2 will be released soon, but if you are confident about the patch so that it does not break stuff, we may add it to 4.1.x too, given the positive impact. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0367] Support unknown record types (RFC 3597)
On 26.5.2015 17:10, Matus Honek wrote: > Works with correct privileges checking, as in your patch attached. > > ACK Thank you very much! Pushed to master: 79cc0254aca589d6d352d96de1827c84d0fe6cfb Petr^2 Spacek > - Original Message - > From: "Petr Spacek" > To: tho...@redhat.com > Cc: freeipa-devel@redhat.com, "Matus Honek" > Sent: Friday, May 22, 2015 10:03:49 AM > Subject: Re: [Freeipa-devel] [PATCH 0367] Support unknown record types (RFC > 3597) > > On 18.5.2015 17:31, Petr Spacek wrote: >> Hello, >> >> This patch is unrelated to metaDB but it should be merged before alpha, too. >> >> Thank you for review! >> >> Support unknown record types (RFC 3597). >> >> Fallback to generic LDAP attribute "UnknownRecord;TYP256" if attempt to >> add specific attribute like "URIRecord" failed with >> LDAP_OBJECT_CLASS_VIOLATION >> and always delete both attributes like "URIRecord" and >> "UnknownRecord;TYPE256". >> >> https://fedorahosted.org/bind-dyndb-ldap/ticket/157 > > Fixed version is attached. Version 1 could dereference NULL pointers in second > iteration of while loops. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0376] Add schema for unknown record types
On 26.5.2015 12:16, Tomas Hozza wrote: > On 05/21/2015 12:42 PM, Petr Spacek wrote: >> Hello, >> >> Add schema for unknown record types. >> >> This patch complements my previous patch 367. >> >> The change was pushed to >> https://github.com/pspacek/bind-dyndb-ldap/tree/unknown_record_types , too. >> > > ACK Pushed to master: d64744725d5607a0b928c59fb233e794b3dc6d48 Thanks! -- Petr^2 Spacek -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On 2015-05-27 15:41, Petr Vobornik wrote: > It would be great to have a privileged daemon which could observed > replicated configuration and perform such tasks on all servers so we > would eliminate manual tasks(and errors and misconceptions which are > caused by forgotten manual tasks) as much as possible. We don't need a separate daemon, we already have an HTTP interface. A reload interface can be implemented with an additional route, e.g. GET /KdcProxy/refresh. It needs a bit of extra work in kdcproxy, kdcproxyshim.py and an ACL for the route. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 822 webui: topology plugin
On 05/26/2015 12:22 PM, Petr Vobornik wrote:
On 05/15/2015 01:50 PM, Petr Vobornik wrote:
On 04/21/2015 04:09 PM, Petr Vobornik wrote:
First iteration of Topology plugin Web UI.
It reflects current state of topology plugin python part which is
implemented in "[PATCH] manage replication topology in the shared tree"
and my wip patch.
I expect that the server API part will change a bit therefore this will
as well.
Graphical visualization/management (ticket 4286) will be implemented in
separate patch.
https://fedorahosted.org/freeipa/ticket/4997
http://www.freeipa.org/page/V4/Manage_replication_topology
New version attached. It requires stage user web ui patches in order to
apply (I expect that user life cycle backend will be pushed sooner than
topology)
Changes:
- Left host and Right host fields are now host comboboxes
- Connectivity are radio buttons with "both, left-right, right-left,
none" options
- segment name is not a required field in its adder dialog
IMHO "Attributes to strip", "Attributes to replicate", "Attributes for
total update", "Initialize replica", "Session timeout", "Replication
agreement enabled" fields should not be just free-form textboxes, but
they should be more specific, e.g. a checkbox for "Replication agreement
enabled" or integer for "Session timeout", but that should be modified
first in the backend python plugin.
New patchset which replaces the old patch.
Contains Web UI for:
- topologysuffix, topologysegment, domain level, server
Backend is implemented in patches:
- tbabej 325-9
- pvoborni 855, 857
New update which reflects the API change in domain level patches.
(domainlevel-show changed to domainlevel-get).
Now it depends only on pvoborni 857-2, the rest was pushed.
--
Petr Vobornik
From b2d17a135c83c04cb1e3fba7efa20a1d545aaa35 Mon Sep 17 00:00:00 2001
From: Petr Vobornik
Date: Tue, 21 Apr 2015 15:50:54 +0200
Subject: [PATCH] webui: topology plugin
https://fedorahosted.org/freeipa/ticket/4997
---
install/ui/doc/categories.json | 1 +
install/ui/src/freeipa/app.js | 1 +
install/ui/src/freeipa/field.js| 2 +-
install/ui/src/freeipa/navigation/menu_spec.js | 22 ++
install/ui/src/freeipa/topology.js | 393 +
install/ui/test/data/ipa_init.json | 11 +
ipalib/plugins/internal.py | 11 +
7 files changed, 440 insertions(+), 1 deletion(-)
create mode 100644 install/ui/src/freeipa/topology.js
diff --git a/install/ui/doc/categories.json b/install/ui/doc/categories.json
index 555367a77f966812d3073edfb9e3289248ff63d2..83c24c5efa7f8e52188a30452a9b3119d831592b 100644
--- a/install/ui/doc/categories.json
+++ b/install/ui/doc/categories.json
@@ -252,6 +252,7 @@
"otptoken",
"radiusproxy",
"stageuser",
+"topology",
"user",
"plugins.load",
"plugins.login",
diff --git a/install/ui/src/freeipa/app.js b/install/ui/src/freeipa/app.js
index 140fe938f68975310175fb9fadf0ec36db048b72..9b290ab0eee216f8b8adb3181a1b3e7ac22fb351 100644
--- a/install/ui/src/freeipa/app.js
+++ b/install/ui/src/freeipa/app.js
@@ -47,6 +47,7 @@ define([
'./service',
'./sudo',
'./trust',
+'./topology',
'./user',
'./stageuser',
'dojo/domReady!'
diff --git a/install/ui/src/freeipa/field.js b/install/ui/src/freeipa/field.js
index f26033ce25a15cface945eeecc69ca503179d30c..fdf925e3d7adc62622e0c9e5e1440eefbdac807b 100644
--- a/install/ui/src/freeipa/field.js
+++ b/install/ui/src/freeipa/field.js
@@ -821,7 +821,7 @@ field.Adapter = declare(null, {
var dr = data.result;
var record = null;
if (dr) {
-if (dr.result) record = dr.result;
+if (IPA.defined(dr.result)) record = dr.result;
else if (dr.results) {
var result = dr.results[this.result_index];
if (result) record = result.result;
diff --git a/install/ui/src/freeipa/navigation/menu_spec.js b/install/ui/src/freeipa/navigation/menu_spec.js
index 13f533d1a6fbb21c73e1f0e5fe1df2836c99f832..c35445f12e36c5dc49033723d8efdcaed7331002 100644
--- a/install/ui/src/freeipa/navigation/menu_spec.js
+++ b/install/ui/src/freeipa/navigation/menu_spec.js
@@ -184,6 +184,28 @@ var nav = {};
{ entity: 'trustconfig' }
]
},
+{
+entity: 'topologysuffix',
+label: '@i18n:tabs.topology',
+facet: 'search',
+children: [
+{
+entity: 'topologysuffix',
+facet: 'search',
+hidden: true
+},
+{
+entity: 'server',
+facet: 'search'
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On 2015-05-27 15:51, Nathaniel McCallum wrote: > As I understand the problem, there is an assumption that an optional > component has a distinct service to start and stop. That is not the > case here. This is just new config for apache. More details: The KDC Proxy uses the same Apache instance as FreeIPAs Web GUI and Tomcat. There is no extra service involved. The switch just decides if https://ipa.example.org/KdcProxy acts as a MS-KKDCP end point or returns a 404 error. My patch "0001 Provide Kerberos over HTTP (MS-KKDCP)" has more details. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On Wed, 2015-05-27 at 15:41 +0200, Petr Vobornik wrote: > On 05/27/2015 03:34 PM, Christian Heimes wrote: > > On 2015-05-27 14:47, Petr Vobornik wrote: > >> Install/uninstall is not the same thing as enable/disable. Installation > >> is a set of steps which first configures and then (optionally) enables > >> the component. > >> > >> E.g: > >> 1. modify configuration file(s), ldap entries > >> 2. run something which starts the component. E.g. `systemctl start xxx`, > >> an ldap change which is being observed (like topology plugin). > >> > >> The only rationale for external tool is to do stuff which can't be done > >> trough API. E.g. restart of httpd.service or a need of Directory > >> Manager. But in that case the tool should be: > >> > >> ipa-kdcproxy-manage enable|disable > > > > Right, the restart of httpd.service isn't handled by ipa config-mod. A > > tool like ipa-kdcproxy-manage could handle the restart on a local > > machine. As far as I know it won't be able to restart httpd on all > > replicas, too. > > > > My current implementation needs a restart of all Apache servers on all > > machines, that run a kdc proxy instance. > > > > Christian > > > > It would be great to have a privileged daemon which could observed > replicated configuration and perform such tasks on all servers so we > would eliminate manual tasks(and errors and misconceptions which are > caused by forgotten manual tasks) as much as possible. Yes this is something we had a need for, for a while, we could, perhaps, turn custodia in such a service, or embed custodia in there, as they are both very privileged service that interact with LDAP to find information. Simo. > -- > Petr Vobornik > -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Fix password changes via kadmin
On Wed, 27 May 2015, Simo Sorce wrote: On Wed, 2015-05-27 at 15:25 +0200, Martin Babinsky wrote: On 05/25/2015 10:48 AM, Martin Babinsky wrote: > On 04/06/2015 12:53 AM, Simo Sorce wrote: >> Fix for bug 4914. >> >> I've tested it locally and seem to do exactly what is needed. I couldn't >> detect any side effects, except that if you use kadmin to get a >> randomized password for a service then you'll get a key for all >> supported types (currently aes256, aes128, des3, rc4, camellia128, >> camellia256) instead of just the default ones (aes256, aes128, des3, >> rc4) if you do not specify enctypes. I think that is fine, we use >> ipa-getkeytab anyway in the normal course of business and that one uses >> a different code path. >> >> Simo. >> >> >> > > Hi Simo, > > the patch works as expected. > > My only gripe is with the duplicate code in 'daemons/ipa-kdb/ipa_kdb.c' > between lines 389 and 455. It could be made into a single function to > get key encoding/salt types from LDAP (see my feeble and untested > attempt which I attached). > > > ACK. I will then send the patch fixing duplicate code separately once I consult it with somebody more skilled in C than myself. Thanks, added your reviewed-by and pushed to master. Martin, should we push this to other branches too ? I think we also need this in 4.1 so that it can go to Fedora, Debian, and RHEL releases. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On Wed, 2015-05-27 at 15:41 +0200, Petr Vobornik wrote: > On 05/27/2015 03:34 PM, Christian Heimes wrote: > > On 2015-05-27 14:47, Petr Vobornik wrote: > > > Install/uninstall is not the same thing as enable/disable. > > > Installation > > > is a set of steps which first configures and then (optionally) > > > enables > > > the component. > > > > > > E.g: > > > 1. modify configuration file(s), ldap entries > > > 2. run something which starts the component. E.g. `systemctl > > > start xxx`, > > > an ldap change which is being observed (like topology plugin). > > > > > > The only rationale for external tool is to do stuff which can't > > > be done > > > trough API. E.g. restart of httpd.service or a need of Directory > > > Manager. But in that case the tool should be: > > > > > > ipa-kdcproxy-manage enable|disable > > > > Right, the restart of httpd.service isn't handled by ipa config > > -mod. A > > tool like ipa-kdcproxy-manage could handle the restart on a local > > machine. As far as I know it won't be able to restart httpd on all > > replicas, too. > > > > My current implementation needs a restart of all Apache servers on > > all > > machines, that run a kdc proxy instance. > > > > Christian > > > > It would be great to have a privileged daemon which could observed > replicated configuration and perform such tasks on all servers so we > would eliminate manual tasks(and errors and misconceptions which are > caused by forgotten manual tasks) as much as possible. *security shiver* -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On Wed, 2015-05-27 at 15:47 +0200, Jan Cholasta wrote: > Dne 27.5.2015 v 15:43 Simo Sorce napsal(a): > > On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: > > ipa config-mod --enable-kdcproxy=TRUE > ipa config-mod --enable-kdcproxy=FALSE > >> > >> I don't like this approach, as it is completely inconsistent with > >> every > >> other optional component. There should be *one* way to handle them > >> and > >> there already is one, no need to reinvent the wheel. > > > > Sorry Jan, but this is really the correct approach. > > I don't think so. > > > > > We want a boolean in LDAP to control whether the IPA Domain allows > > proxying or not, the code is embedded in the overall framework and has > > no need for explicit install/uninstall unlike the CA or DNS components. > > There is a boolean for every other component/service as well. If you > want to add new API to manipulate the boolean, fine, but it should be > done in a generic way that works for other components as well. This is the same as: ipa config-mod --enable-migration=TRUE Why is it a problem ? This is not a separate service. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
Dne 27.5.2015 v 15:43 Simo Sorce napsal(a): On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: ipa config-mod --enable-kdcproxy=TRUE ipa config-mod --enable-kdcproxy=FALSE I don't like this approach, as it is completely inconsistent with every other optional component. There should be *one* way to handle them and there already is one, no need to reinvent the wheel. Sorry Jan, but this is really the correct approach. I don't think so. We want a boolean in LDAP to control whether the IPA Domain allows proxying or not, the code is embedded in the overall framework and has no need for explicit install/uninstall unlike the CA or DNS components. There is a boolean for every other component/service as well. If you want to add new API to manipulate the boolean, fine, but it should be done in a generic way that works for other components as well. Simo. -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 0014] Support multiple user and host certificates
This patch adds supports for multiple user / host certificates. No
schema change is needed ('usercertificate' attribute is already
multi-value). The revoke-previous-cert behaviour of host-mod and
user-mod has been removed but revocation behaviour of -del and
-disable is preserved.
The latest profiles/caacl patchset (0001..0013 v5) depends on this
patch for correct cert-request behaviour.
There is one design question (or maybe more, let me know): the
`--out=FILENAME' option to {host,service} show saves ONE certificate
to the named file. I propose to either:
a) write all certs, suffixing suggested filename with either a
sequential numerical index, e.g. "cert.pem" becomes
"cert.pem.1", "cert.pem.2", and so on; or
b) as above, but suffix with serial number and, if there are
different issues, some issuer-identifying information.
Let me know your thoughts.
Thanks,
Fraser
>From 333654797908ab6a71a84b51723bd1d5e59637d0 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale
Date: Wed, 27 May 2015 08:02:08 -0400
Subject: [PATCH] Support multiple host and service certificates
Update the framework to support multiple host and service
certificates.
host-mod now sets 'usercertificate' values without revoking existing
certificate. Similarly, service-mod does nothing with preexisting
'usercertificate' values where previously it raised an error.
The existing behaviour of host-disable, host-del, service-disable
and service-del (revoke existing certificate) is preserved but now
applies to all certificates in the host or service entry.
Part of: http://www.freeipa.org/page/V4/User_Certificates
---
ipalib/plugins/host.py| 64 +--
ipalib/plugins/service.py | 55
2 files changed, 38 insertions(+), 81 deletions(-)
diff --git a/ipalib/plugins/host.py b/ipalib/plugins/host.py
index
c47439743da45b8629d1b2afbd210d87591784ce..880a3b5d3c2de79a9752ec3fa64ed729ffd42641
100644
--- a/ipalib/plugins/host.py
+++ b/ipalib/plugins/host.py
@@ -493,7 +493,7 @@ class host(LDAPObject):
label=_('Random password'),
flags=('no_create', 'no_update', 'no_search', 'virtual_attribute'),
),
-Bytes('usercertificate?', validate_certificate,
+Bytes('usercertificate*', validate_certificate,
cli_name='certificate',
label=_('Certificate'),
doc=_('Base-64 encoded server certificate'),
@@ -640,11 +640,11 @@ class host_add(LDAPCreate):
entry_attrs['userpassword'] =
ipa_generate_password(characters=host_pwd_chars)
# save the password so it can be displayed in post_callback
setattr(context, 'randompassword', entry_attrs['userpassword'])
-cert = options.get('usercertificate')
-if cert:
-cert = x509.normalize_certificate(cert)
+certs = options.get('usercertificate', [])
+certs_der = map(x509.normalize_certificate, certs)
+for cert in certs_der:
x509.verify_cert_subject(ldap, keys[-1], cert)
-entry_attrs['usercertificate'] = cert
+entry_attrs['usercertificate'] = certs_der
entry_attrs['managedby'] = dn
entry_attrs['objectclass'].append('ieee802device')
entry_attrs['objectclass'].append('ipasshhost')
@@ -786,8 +786,7 @@ class host_del(LDAPDelete):
entry_attrs = ldap.get_entry(dn, ['usercertificate'])
except errors.NotFound:
self.obj.handle_not_found(*keys)
-cert = entry_attrs.single_value.get('usercertificate')
-if cert:
+for cert in entry_attrs.get('usercertificate', []):
cert = x509.normalize_certificate(cert)
try:
serial = unicode(x509.get_serial_number(cert, x509.DER))
@@ -864,39 +863,10 @@ class host_mod(LDAPUpdate):
if 'krbprincipalaux' not in obj_classes:
obj_classes.append('krbprincipalaux')
entry_attrs['objectclass'] = obj_classes
-cert = x509.normalize_certificate(entry_attrs.get('usercertificate'))
-if cert:
-if self.api.Command.ca_is_enabled()['result']:
-x509.verify_cert_subject(ldap, keys[-1], cert)
-entry_attrs_old = ldap.get_entry(dn, ['usercertificate'])
-oldcert = entry_attrs_old.single_value.get('usercertificate')
-if oldcert:
-oldcert = x509.normalize_certificate(oldcert)
-try:
-serial = x509.get_serial_number(oldcert, x509.DER)
-serial = unicode(serial)
-try:
-result = api.Command['cert_show'](serial)['result']
-if 'revocation_reason' not in result:
-try:
-api.Command['cert_revoke'](
-
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On Wed, 2015-05-27 at 15:47 +0200, Jan Cholasta wrote: > Dne 27.5.2015 v 15:43 Simo Sorce napsal(a): > > On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: > > > > > > > > > > ipa config-mod --enable-kdcproxy=TRUE > > > > > ipa config-mod --enable-kdcproxy=FALSE > > > > > > I don't like this approach, as it is completely inconsistent with > > > every > > > other optional component. There should be *one* way to handle > > > them > > > and > > > there already is one, no need to reinvent the wheel. > > > > Sorry Jan, but this is really the correct approach. > > I don't think so. > > > > > We want a boolean in LDAP to control whether the IPA Domain allows > > proxying or not, the code is embedded in the overall framework and > > has > > no need for explicit install/uninstall unlike the CA or DNS > > components. > > There is a boolean for every other component/service as well. If you > want to add new API to manipulate the boolean, fine, but it should be > > done in a generic way that works for other components as well. As I understand the problem, there is an assumption that an optional component has a distinct service to start and stop. That is not the case here. This is just new config for apache. Nathaniel -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On Wed, 2015-05-27 at 13:57 +0200, Jan Cholasta wrote: > >> > >>ipa config-mod --enable-kdcproxy=TRUE > >>ipa config-mod --enable-kdcproxy=FALSE > > I don't like this approach, as it is completely inconsistent with > every > other optional component. There should be *one* way to handle them > and > there already is one, no need to reinvent the wheel. Sorry Jan, but this is really the correct approach. We want a boolean in LDAP to control whether the IPA Domain allows proxying or not, the code is embedded in the overall framework and has no need for explicit install/uninstall unlike the CA or DNS components. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Fix password changes via kadmin
On Wed, 2015-05-27 at 15:25 +0200, Martin Babinsky wrote: > On 05/25/2015 10:48 AM, Martin Babinsky wrote: > > On 04/06/2015 12:53 AM, Simo Sorce wrote: > >> Fix for bug 4914. > >> > >> I've tested it locally and seem to do exactly what is needed. I couldn't > >> detect any side effects, except that if you use kadmin to get a > >> randomized password for a service then you'll get a key for all > >> supported types (currently aes256, aes128, des3, rc4, camellia128, > >> camellia256) instead of just the default ones (aes256, aes128, des3, > >> rc4) if you do not specify enctypes. I think that is fine, we use > >> ipa-getkeytab anyway in the normal course of business and that one uses > >> a different code path. > >> > >> Simo. > >> > >> > >> > > > > Hi Simo, > > > > the patch works as expected. > > > > My only gripe is with the duplicate code in 'daemons/ipa-kdb/ipa_kdb.c' > > between lines 389 and 455. It could be made into a single function to > > get key encoding/salt types from LDAP (see my feeble and untested > > attempt which I attached). > > > > > > > ACK. > > I will then send the patch fixing duplicate code separately once I > consult it with somebody more skilled in C than myself. > Thanks, added your reviewed-by and pushed to master. Martin, should we push this to other branches too ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On 05/27/2015 03:34 PM, Christian Heimes wrote: On 2015-05-27 14:47, Petr Vobornik wrote: Install/uninstall is not the same thing as enable/disable. Installation is a set of steps which first configures and then (optionally) enables the component. E.g: 1. modify configuration file(s), ldap entries 2. run something which starts the component. E.g. `systemctl start xxx`, an ldap change which is being observed (like topology plugin). The only rationale for external tool is to do stuff which can't be done trough API. E.g. restart of httpd.service or a need of Directory Manager. But in that case the tool should be: ipa-kdcproxy-manage enable|disable Right, the restart of httpd.service isn't handled by ipa config-mod. A tool like ipa-kdcproxy-manage could handle the restart on a local machine. As far as I know it won't be able to restart httpd on all replicas, too. My current implementation needs a restart of all Apache servers on all machines, that run a kdc proxy instance. Christian It would be great to have a privileged daemon which could observed replicated configuration and perform such tasks on all servers so we would eliminate manual tasks(and errors and misconceptions which are caused by forgotten manual tasks) as much as possible. -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
Dne 27.5.2015 v 14:47 Petr Vobornik napsal(a): On 05/27/2015 01:57 PM, Jan Cholasta wrote: Dne 27.5.2015 v 13:34 Martin Kosek napsal(a): On 05/27/2015 01:33 PM, Christian Heimes wrote: On 2015-05-27 11:59, Martin Kosek wrote: On 05/27/2015 11:53 AM, Alexander Bokovoy wrote: On Wed, 27 May 2015, Martin Kosek wrote: On 05/26/2015 05:40 PM, Jan Cholasta wrote: Dne 22.5.2015 v 12:24 Christian Heimes napsal(a): ... Finally I haven't figured out the best way to configure the instance. An admin should be able to enable / disable KDC proxy. Should I write a script or a ipa plugin for the job? A script, ipa-kdcproxy-install, if you want to be consistent with what's already there. I thought we wanted to install it by default and only switch it on/off via configuration in LDAP. In that case, no ipa-*-install should be needed. As with any other feature which requires configuration of other components, if it wasn't installed before, you need to make sure you are able to configure it over upgraded instance. Not providing ipa-kdcproxy-install would mean you are not supporting an upgrade case. I do not disagree with the approach for optional components. But as I wrote above, this was supposed to be configured everywhere by default - both on new and upgraded installations. It doesn't matter whether it's installed by default or not. This is to support disabling and enabling the component - "ipa-kdcproxy-install" to enable, "ipa-kdcproxy-install --uninstall" to disable. Install/uninstall is not the same thing as enable/disable. Installation is a set of steps which first configures and then (optionally) enables the component. The configuration steps exist for the sole purpose of making it possible to enable the component after they are done. The result of install is that the component is enabled, and the result of uninstall is that the component is disabled. So, in a way, they are the same thing. E.g: 1. modify configuration file(s), ldap entries 2. run something which starts the component. E.g. `systemctl start xxx`, an ldap change which is being observed (like topology plugin). Yes, and this boils down to: 1. enable KDC proxy in LDAP for KDC proxy. The only rationale for external tool is to do stuff which can't be done trough API. E.g. restart of httpd.service or a need of Directory Manager. But in that case the tool should be: There is no API for enabling/disabling components, so it can't be done through API. ipa-kdcproxy-manage enable|disable There is no ipa-ca-manage, ipa-dns-manage or ipa-kra-manage. AFAIK, it is mostly just one config for Apache and wsgi script. Yes, it is really just one boolean switch (service enabled/disabled). The state of the switch is read when Apache is started or reloaded. In the default state KDC Proxy is enabled. When the service is disabled, the WSGI script replies with 404 instead. All remaining settings like kdc, kadmin and kpasswd server(s) are read from /etc/krb5.conf. This is just an implementation detail. I had both the per-replica and the global switch implemented. After I discussion with Nathaniel and Martin, it's now a global switch only. Nathaniel argued, that a global switch is easier to implement as well as sufficient for now. The state of the switch is controlled with ipa config-mod: ipa config-mod --enable-kdcproxy=TRUE ipa config-mod --enable-kdcproxy=FALSE I don't like this approach, as it is completely inconsistent with every other optional component. There should be *one* way to handle them and there already is one, no need to reinvent the wheel. Could you be more specific? Is there really *one* way? The only optional components/functions of IPA server which can be turned on and off while still being installed are probably Managed Entry plugin(controlled by ipa-managed-entries) and a Migration mode(controlled in the same fashion as current proposal). These are not components, but rather DS "switches". Other optional components(CA, DNS, KRA) could be just installed later if they are not installed during server installation. They cannot be disabled nor uninstalled (KRA is exception, there is also uninstallation). So they are not the same case. They can be uninstalled, it's just not implemented yet :-) The schema changes for the new attribute are handled by ipa-server-upgrade. The Apache config file is created ipa-server-install, ipa-replica-install and ipa-server-upgrade. Thanks. This is all we need for 4.2, IMO. Martin -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On 2015-05-27 14:47, Petr Vobornik wrote: > Install/uninstall is not the same thing as enable/disable. Installation > is a set of steps which first configures and then (optionally) enables > the component. > > E.g: > 1. modify configuration file(s), ldap entries > 2. run something which starts the component. E.g. `systemctl start xxx`, > an ldap change which is being observed (like topology plugin). > > The only rationale for external tool is to do stuff which can't be done > trough API. E.g. restart of httpd.service or a need of Directory > Manager. But in that case the tool should be: > > ipa-kdcproxy-manage enable|disable Right, the restart of httpd.service isn't handled by ipa config-mod. A tool like ipa-kdcproxy-manage could handle the restart on a local machine. As far as I know it won't be able to restart httpd on all replicas, too. My current implementation needs a restart of all Apache servers on all machines, that run a kdc proxy instance. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Yet another user certificates/Smart Card thread
Fraser Tweedale wrote: On Tue, May 26, 2015 at 07:49:10AM +0200, Martin Kosek wrote: I think a global option is sensible starting point. We should also consider an option to use revocation reason "certificateHold" for obj-disable and revive the certificates if the object is re-enabled via obj-enable. (I'm not sure whether Dogtag makes this easy but I am pretty sure it's currently possible; and it's a bit more work for IPA to do this, of course). It is already supported. If you revoke with a reason of 6 then you can remove the hold using the cert-remove-hold command. rob -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Fix password changes via kadmin
On 05/25/2015 10:48 AM, Martin Babinsky wrote: On 04/06/2015 12:53 AM, Simo Sorce wrote: Fix for bug 4914. I've tested it locally and seem to do exactly what is needed. I couldn't detect any side effects, except that if you use kadmin to get a randomized password for a service then you'll get a key for all supported types (currently aes256, aes128, des3, rc4, camellia128, camellia256) instead of just the default ones (aes256, aes128, des3, rc4) if you do not specify enctypes. I think that is fine, we use ipa-getkeytab anyway in the normal course of business and that one uses a different code path. Simo. Hi Simo, the patch works as expected. My only gripe is with the duplicate code in 'daemons/ipa-kdb/ipa_kdb.c' between lines 389 and 455. It could be made into a single function to get key encoding/salt types from LDAP (see my feeble and untested attempt which I attached). ACK. I will then send the patch fixing duplicate code separately once I consult it with somebody more skilled in C than myself. -- Martin^3 Babinsky -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH] 0001 Provide Kerberos over HTTP (MS-KKDCP)
Hello, here is my first patch for FreeIPA. The patch integrates python-kdcproxy for MS-KKDCP support (aka Kerberos over HTTPS). https://www.freeipa.org/page/V4/KDC_Proxy Ticket: https://fedorahosted.org/freeipa/ticket/4801 Christian From 49ad74834ef9036d0678dceb4020784fef389446 Mon Sep 17 00:00:00 2001 From: Christian Heimes Date: Thu, 21 May 2015 12:42:27 +0200 Subject: [PATCH] Provide Kerberos over HTTP (MS-KKDCP) Add integration of python-kdcproxy into FreeIPA to support the MS Kerberos KDC proxy protocol (MS-KKDCP), to allow KDC and KPASSWD client requests over HTTP and HTTPS. - freeipa-server now depends on python-kdcproxy >= 0.2.1. All kdcproxy dependencies are already satisfied. - The service can be globally toggled with the boolean attribute ipaKDCproxyEnabled in cn=ipaConfig,cn=etc. The switch is supported by ipa config-mod --enable-kdcproxy. - The installers and update create a new Apache config file ipa-kdc-proxy.conf that mounts a WSGI app at /KdcProxy. The app is run inside its own WSGI daemon group. - The WSGI app at /KdcProxy is a WSGI wrapper, that checks the state of the switch. When ipaKDCproxyEnabled is FALSE, a HTTP 404 error is returned. For performance reasons the flag is only checked at start of the WSGI app. Apache must be reloaded or restarted to read the switch state again. - The WSGI app uses the Apache principal to acquire a Kerberos ticket to perform GSSAPI bindings for the LDAP query of ipaKDCproxyEnabled. - The WSGI wrapper script sets KDCPROXY_CONFIG=/etc/ipa/kdcproxy.conf, so that an existing config is not used. - python-kdcproxy is configured to *not* use DNS SRV lookups. The location of KDC and KPASSWD servers are read from /etc/krb5.conf https://www.freeipa.org/page/V4/KDC_Proxy https://fedorahosted.org/freeipa/ticket/4801 --- ACI.txt| 2 +- API.txt| 3 +- freeipa.spec.in| 11 ++ install/conf/Makefile.am | 1 + install/conf/ipa-kdc-proxy.conf| 14 +++ install/conf/ipa.conf | 6 +- install/share/60ipaconfig.ldif | 4 +- install/share/Makefile.am | 2 + install/share/kdcproxy.conf| 4 + install/share/kdcproxyshim.py | 189 + install/tools/ipa-replica-install | 6 ++ install/tools/ipa-server-install | 7 ++ install/ui/src/freeipa/serverconfig.js | 4 + install/updates/50-ipaconfig.update| 4 + ipalib/plugins/config.py | 8 +- ipaplatform/base/paths.py | 1 + ipaserver/install/ipa_backup.py| 1 + ipaserver/install/kdcproxyinstance.py | 105 ++ ipaserver/install/server.py| 8 ++ 19 files changed, 373 insertions(+), 7 deletions(-) create mode 100644 install/conf/ipa-kdc-proxy.conf create mode 100644 install/share/kdcproxy.conf create mode 100644 install/share/kdcproxyshim.py create mode 100644 ipaserver/install/kdcproxyinstance.py diff --git a/ACI.txt b/ACI.txt index 3c4ebde5b3ac2eb0b8e9465c5f2bd74f5bdbfb01..8576f56c3c89311dec92bcd7fe2932e42be3d510 100644 --- a/ACI.txt +++ b/ACI.txt @@ -23,7 +23,7 @@ aci: (targetattr = "automountmapname || description")(targetfilter = "(objectcla dn: cn=automount,dc=ipa,dc=example aci: (targetfilter = "(objectclass=automountmap)")(version 3.0;acl "permission:System: Remove Automount Maps";allow (delete) groupdn = "ldap:///cn=System: Remove Automount Maps,cn=permissions,cn=pbac,dc=ipa,dc=example";) dn: cn=ipaconfig,cn=etc,dc=ipa,dc=example -aci: (targetattr = "cn || createtimestamp || entryusn || ipacertificatesubjectbase || ipaconfigstring || ipacustomfields || ipadefaultemaildomain || ipadefaultloginshell || ipadefaultprimarygroup || ipagroupobjectclasses || ipagroupsearchfields || ipahomesrootdir || ipakrbauthzdata || ipamaxusernamelength || ipamigrationenabled || ipapwdexpadvnotify || ipasearchrecordslimit || ipasearchtimelimit || ipaselinuxusermapdefault || ipaselinuxusermaporder || ipauserauthtype || ipauserobjectclasses || ipausersearchfields || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipaguiconfig)")(version 3.0;acl "permission:System: Read Global Configuration";allow (compare,read,search) userdn = "ldap:///all";;) +aci: (targetattr = "cn || createtimestamp || entryusn || ipacertificatesubjectbase || ipaconfigstring || ipacustomfields || ipadefaultemaildomain || ipadefaultloginshell || ipadefaultprimarygroup || ipagroupobjectclasses || ipagroupsearchfields || ipahomesrootdir || ipakdcproxyenabled || ipakrbauthzdata || ipamaxusernamelength || ipamigrationenabled || ipapwdexpadvnotify || ipasearchrecordslimit || ipasearchtimelimit || ipaselinuxusermapdefault || ipaselinuxusermaporder || ipauserauthtype || ipauserobjectclasses || ipausersearchfields || modifytimestamp || objectclass")(targetfilter = "(objectclass=ipaguiconfig)")(version 3.0;acl "permission:System: Read Gl
[Freeipa-devel] [PATCH 0377-0382] Synchronize changes from LDAP after reconnect
Hello,
https://fedorahosted.org/bind-dyndb-ldap/ticket/128
Previously records deleted when connection to LDAP server was down were not
synchronized properly. It should work now.
I use this command to simulate broken connections and connection
re-establishment:
$ socat tcp-listen:3899,reuseaddr,fork tcp-connect:localhost:389
It should be enough to add "ldap://$(hostname):3899" as LDAP URI to
/etc/named.conf and then simulate changes by killing and restarting socat.
Let me know if you need any assistance!
--
Petr^2 Spacek
From 57e87e325bbfe60709a53c8d5422339bb5f2b664 Mon Sep 17 00:00:00 2001
From: Petr Spacek
Date: Tue, 26 May 2015 09:32:59 +0200
Subject: [PATCH] Add functions for MetaLDAP generation number manipulation.
https://fedorahosted.org/bind-dyndb-ldap/ticket/128
---
src/mldap.c | 38 --
src/mldap.h | 6 ++
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/src/mldap.c b/src/mldap.c
index 28fd2296b7ba6b97d1688ccf0be8ae63bbf6c2e8..d207df52ed92975c5d678add6dadfbcedfa052b8 100644
--- a/src/mldap.c
+++ b/src/mldap.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "ldap_entry.h"
#include "metadb.h"
@@ -60,7 +61,7 @@ mldap_new(isc_mem_t *mctx, mldapdb_t **mldapp) {
isc_mem_attach(mctx, &mldap->mctx);
CHECK(metadb_new(mctx, &mldap->mdb));
- mldap->generation = 0;
+ mldap->generation = 1;
*mldapp = mldap;
return result;
@@ -99,6 +100,34 @@ mldap_closeversion(mldapdb_t *mldap, isc_boolean_t commit) {
}
/**
+ * Atomically increment MetaLDAP generation number.
+ */
+void mldap_cur_generation_bump(mldapdb_t *mldap) {
+ isc_uint32_t oldgen;
+ isc_uint32_t curgen;
+ isc_uint32_t newgen;
+
+ REQUIRE(mldap != NULL);
+
+ curgen = isc_atomic_cmpxchg((isc_int32_t *)&mldap->generation, 0, 0);
+ do {
+ oldgen = curgen;
+ newgen = dns_update_soaserial(oldgen, dns_updatemethod_increment);
+ curgen = isc_atomic_cmpxchg((isc_int32_t *)&mldap->generation, oldgen, newgen);
+ } while (curgen != oldgen);
+}
+
+/**
+ * Get current MetaLDAP generation number.
+ *
+ * Generation numbers have to be compared using isc_serial_* functions.
+ */
+isc_uint32_t
+mldap_cur_generation_get(mldapdb_t *mldap) {
+ return isc_atomic_cmpxchg((isc_int32_t *)&mldap->generation, 0, 0);
+}
+
+/**
* Convert UUID to "01234567-89ab-cdef-0123-456789abcdef.uuid.ldap." DNS name.
*
* @param[in] beruuid
@@ -191,12 +220,17 @@ mldap_generation_store(mldapdb_t *mldap, metadb_node_t *node) {
unsigned char buff[sizeof(mldap->generation)];
isc_region_t region = { .base = buff, .length = sizeof(buff) };
dns_rdata_t rdata;
+ isc_uint32_t generation;
+
+ STATIC_ASSERT((sizeof(((mldapdb_t *)0)->generation) == sizeof(generation)), \
+ "mldapdb_t->generation and local generation size does not match");
dns_rdata_init(&rdata);
/* Bytes should be in network-order but we do not care because:
* 1) It is used only internally and always compared on this machine. */
- memcpy(buff, &mldap->generation, sizeof(mldap->generation));
+ generation = mldap_cur_generation_get(mldap);
+ memcpy(buff, &generation, sizeof(generation));
dns_rdata_fromregion(&rdata, dns_rdataclass_in, dns_rdatatype_a, ®ion);
CHECK(metadb_rdata_store(&rdata, node));
diff --git a/src/mldap.h b/src/mldap.h
index 752ab28b2da956817ad27c9c928863bc9e601c0c..c7eb725d2c1743da6037a2dc95d6bc000ccb0928 100644
--- a/src/mldap.h
+++ b/src/mldap.h
@@ -42,4 +42,10 @@ mldap_dnsname_get(metadb_node_t *node, dns_name_t *fqdn, dns_name_t *zone);
isc_result_t ATTR_CHECKRESULT ATTR_NONNULLS
mldap_dnsname_store(dns_name_t *fqdn, dns_name_t *zone, metadb_node_t *node);
+void ATTR_NONNULLS
+mldap_cur_generation_bump(mldapdb_t *mldap);
+
+isc_uint32_t ATTR_CHECKRESULT ATTR_NONNULLS
+mldap_cur_generation_get(mldapdb_t *mldap);
+
#endif /* SRC_MLDAP_H_ */
--
2.1.0
From b476041bd6a88b88cd1739e61960a666868e1b23 Mon Sep 17 00:00:00 2001
From: Petr Spacek
Date: Tue, 26 May 2015 09:34:58 +0200
Subject: [PATCH] Increment MetaLDAP generation number on reconnect.
https://fedorahosted.org/bind-dyndb-ldap/ticket/128
---
src/ldap_helper.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/ldap_helper.c b/src/ldap_helper.c
index abda9f54e84f097214ac0ba69a5cd657a39b5862..e9d2229d5369fc9ac9d692f426a2bdab99958184 100644
--- a/src/ldap_helper.c
+++ b/src/ldap_helper.c
@@ -4588,6 +4588,7 @@ ldap_syncrepl_watcher(isc_threadarg_t arg)
sane_sleep(inst, 1);
continue;
}
+ mldap_cur_generation_bump(inst->mldapdb);
log_info("LDAP instance '%s' is being synchronized, "
"please ignore message 'all zones loaded'",
--
2.1.0
From 77ecee87f551567b94bd26290c734c7feb5ed93f Mon Sep 17 00:00:00 2001
From: Petr Spacek
Date: Wed, 27 May 2015 08:02:57 +0200
Subject: [PATCH] Add iterators for dead nodes in metaLDAP.
https://fedorahosted.org/bind-dyndb-ldap/ticket/128
---
src/metadb.c | 55
src/metadb.h | 20
src/mldap.c | 165 +++
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On 05/27/2015 01:57 PM, Jan Cholasta wrote: Dne 27.5.2015 v 13:34 Martin Kosek napsal(a): On 05/27/2015 01:33 PM, Christian Heimes wrote: On 2015-05-27 11:59, Martin Kosek wrote: On 05/27/2015 11:53 AM, Alexander Bokovoy wrote: On Wed, 27 May 2015, Martin Kosek wrote: On 05/26/2015 05:40 PM, Jan Cholasta wrote: Dne 22.5.2015 v 12:24 Christian Heimes napsal(a): ... Finally I haven't figured out the best way to configure the instance. An admin should be able to enable / disable KDC proxy. Should I write a script or a ipa plugin for the job? A script, ipa-kdcproxy-install, if you want to be consistent with what's already there. I thought we wanted to install it by default and only switch it on/off via configuration in LDAP. In that case, no ipa-*-install should be needed. As with any other feature which requires configuration of other components, if it wasn't installed before, you need to make sure you are able to configure it over upgraded instance. Not providing ipa-kdcproxy-install would mean you are not supporting an upgrade case. I do not disagree with the approach for optional components. But as I wrote above, this was supposed to be configured everywhere by default - both on new and upgraded installations. It doesn't matter whether it's installed by default or not. This is to support disabling and enabling the component - "ipa-kdcproxy-install" to enable, "ipa-kdcproxy-install --uninstall" to disable. Install/uninstall is not the same thing as enable/disable. Installation is a set of steps which first configures and then (optionally) enables the component. E.g: 1. modify configuration file(s), ldap entries 2. run something which starts the component. E.g. `systemctl start xxx`, an ldap change which is being observed (like topology plugin). The only rationale for external tool is to do stuff which can't be done trough API. E.g. restart of httpd.service or a need of Directory Manager. But in that case the tool should be: ipa-kdcproxy-manage enable|disable AFAIK, it is mostly just one config for Apache and wsgi script. Yes, it is really just one boolean switch (service enabled/disabled). The state of the switch is read when Apache is started or reloaded. In the default state KDC Proxy is enabled. When the service is disabled, the WSGI script replies with 404 instead. All remaining settings like kdc, kadmin and kpasswd server(s) are read from /etc/krb5.conf. This is just an implementation detail. I had both the per-replica and the global switch implemented. After I discussion with Nathaniel and Martin, it's now a global switch only. Nathaniel argued, that a global switch is easier to implement as well as sufficient for now. The state of the switch is controlled with ipa config-mod: ipa config-mod --enable-kdcproxy=TRUE ipa config-mod --enable-kdcproxy=FALSE I don't like this approach, as it is completely inconsistent with every other optional component. There should be *one* way to handle them and there already is one, no need to reinvent the wheel. Could you be more specific? Is there really *one* way? The only optional components/functions of IPA server which can be turned on and off while still being installed are probably Managed Entry plugin(controlled by ipa-managed-entries) and a Migration mode(controlled in the same fashion as current proposal). Other optional components(CA, DNS, KRA) could be just installed later if they are not installed during server installation. They cannot be disabled nor uninstalled (KRA is exception, there is also uninstallation). So they are not the same case. The schema changes for the new attribute are handled by ipa-server-upgrade. The Apache config file is created ipa-server-install, ipa-replica-install and ipa-server-upgrade. Thanks. This is all we need for 4.2, IMO. Martin -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
Dne 27.5.2015 v 13:34 Martin Kosek napsal(a): On 05/27/2015 01:33 PM, Christian Heimes wrote: On 2015-05-27 11:59, Martin Kosek wrote: On 05/27/2015 11:53 AM, Alexander Bokovoy wrote: On Wed, 27 May 2015, Martin Kosek wrote: On 05/26/2015 05:40 PM, Jan Cholasta wrote: Dne 22.5.2015 v 12:24 Christian Heimes napsal(a): ... Finally I haven't figured out the best way to configure the instance. An admin should be able to enable / disable KDC proxy. Should I write a script or a ipa plugin for the job? A script, ipa-kdcproxy-install, if you want to be consistent with what's already there. I thought we wanted to install it by default and only switch it on/off via configuration in LDAP. In that case, no ipa-*-install should be needed. As with any other feature which requires configuration of other components, if it wasn't installed before, you need to make sure you are able to configure it over upgraded instance. Not providing ipa-kdcproxy-install would mean you are not supporting an upgrade case. I do not disagree with the approach for optional components. But as I wrote above, this was supposed to be configured everywhere by default - both on new and upgraded installations. It doesn't matter whether it's installed by default or not. This is to support disabling and enabling the component - "ipa-kdcproxy-install" to enable, "ipa-kdcproxy-install --uninstall" to disable. AFAIK, it is mostly just one config for Apache and wsgi script. Yes, it is really just one boolean switch (service enabled/disabled). The state of the switch is read when Apache is started or reloaded. In the default state KDC Proxy is enabled. When the service is disabled, the WSGI script replies with 404 instead. All remaining settings like kdc, kadmin and kpasswd server(s) are read from /etc/krb5.conf. This is just an implementation detail. I had both the per-replica and the global switch implemented. After I discussion with Nathaniel and Martin, it's now a global switch only. Nathaniel argued, that a global switch is easier to implement as well as sufficient for now. The state of the switch is controlled with ipa config-mod: ipa config-mod --enable-kdcproxy=TRUE ipa config-mod --enable-kdcproxy=FALSE I don't like this approach, as it is completely inconsistent with every other optional component. There should be *one* way to handle them and there already is one, no need to reinvent the wheel. The schema changes for the new attribute are handled by ipa-server-upgrade. The Apache config file is created ipa-server-install, ipa-replica-install and ipa-server-upgrade. Thanks. This is all we need for 4.2, IMO. Martin -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0038] increase NSS memcache timeout for IPA server
On 05/27/2015 01:33 PM, Lukas Slebodnik wrote:
On (27/05/15 13:25), Martin Babinsky wrote:
https://fedorahosted.org/freeipa/ticket/4964
--
Martin^3 Babinsky
From ef8481ee0267a720551832baae9398b435b3c6c5 Mon Sep 17 00:00:00 2001
From: Martin Babinsky
Date: Tue, 26 May 2015 18:11:08 +0200
Subject: [PATCH] increase NSS memcache timeout for IPA server
Increasing memcache timeout to 600 seconds when configuring sssd on IPA server
should improve performance when dealing with large groups in trusts.
https://fedorahosted.org/freeipa/ticket/4964
---
ipa-client/ipa-install/ipa-client-install | 9 +
1 file changed, 9 insertions(+)
diff --git a/ipa-client/ipa-install/ipa-client-install
b/ipa-client/ipa-install/ipa-client-install
index
63e3c9800791f3d29c977d63815c4291f5a235b9..ab3bc8a652dad01b9db5a26b877f38b850cb07f1
100755
--- a/ipa-client/ipa-install/ipa-client-install
+++ b/ipa-client/ipa-install/ipa-client-install
@@ -1274,6 +1274,15 @@ def configure_sssd_conf(fstore, cli_realm, cli_domain,
cli_server, options, clie
# the master should only use itself for Kerberos
domain.set_option('ipa_server', cli_server[0])
+# increase memcache timeout to 10 minutes when in server mode
+try:
+nss_service = sssdconfig.get_service('nss')
+except SSSDConfig.NoServiceError:
+nss_service = sssdconfig.new_service('nss')
+
+nss_service.set_option('memcache_timeout', 600)
+sssdconfig.save_service(nss_service)
+
NACK
It should not be set to such high value for each client.
It should be configured if and only if sssd is in the ipa-server mode
(trust with AD)
LS
Lukas,
it actually is set only when '--on-master' option is used, as can be
(hopefully) seen from the following code:
"""
if not options.on_master:
if options.primary:
domain.set_option('ipa_server', ', '.join(cli_server))
else:
domain.set_option('ipa_server', '_srv_, %s' % ',
'.join(cli_server))
else:
domain.set_option('ipa_server_mode', 'True')
# the master should only use itself for Kerberos
domain.set_option('ipa_server', cli_server[0])
# increase memcache timeout to 10 minutes when in server mode
try:
nss_service = sssdconfig.get_service('nss')
except SSSDConfig.NoServiceError:
nss_service = sssdconfig.new_service('nss')
nss_service.set_option('memcache_timeout', 600)
sssdconfig.save_service(nss_service)
"""
--
Martin^3 Babinsky
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On 05/27/2015 01:33 PM, Christian Heimes wrote: > On 2015-05-27 11:59, Martin Kosek wrote: >> On 05/27/2015 11:53 AM, Alexander Bokovoy wrote: >>> On Wed, 27 May 2015, Martin Kosek wrote: On 05/26/2015 05:40 PM, Jan Cholasta wrote: > Dne 22.5.2015 v 12:24 Christian Heimes napsal(a): ... >> Finally I haven't figured out the best way to configure the instance. An >> admin should be able to enable / disable KDC proxy. Should I write a >> script or a ipa plugin for the job? > > A script, ipa-kdcproxy-install, if you want to be consistent with what's > already there. I thought we wanted to install it by default and only switch it on/off via configuration in LDAP. In that case, no ipa-*-install should be needed. >>> As with any other feature which requires configuration of other >>> components, if it wasn't installed before, you need to make sure you are >>> able to configure it over upgraded instance. Not providing >>> ipa-kdcproxy-install would mean you are not supporting an upgrade case. >> >> I do not disagree with the approach for optional components. But as I wrote >> above, this was supposed to be configured everywhere by default - both on new >> and upgraded installations. >> >> AFAIK, it is mostly just one config for Apache and wsgi script. > > Yes, it is really just one boolean switch (service enabled/disabled). > The state of the switch is read when Apache is started or reloaded. In > the default state KDC Proxy is enabled. When the service is disabled, > the WSGI script replies with 404 instead. All remaining settings like > kdc, kadmin and kpasswd server(s) are read from /etc/krb5.conf. > > I had both the per-replica and the global switch implemented. After I > discussion with Nathaniel and Martin, it's now a global switch only. > Nathaniel argued, that a global switch is easier to implement as well as > sufficient for now. > > The state of the switch is controlled with ipa config-mod: > > ipa config-mod --enable-kdcproxy=TRUE > ipa config-mod --enable-kdcproxy=FALSE > > The schema changes for the new attribute are handled by > ipa-server-upgrade. The Apache config file is created > ipa-server-install, ipa-replica-install and ipa-server-upgrade. Thanks. This is all we need for 4.2, IMO. Martin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0038] increase NSS memcache timeout for IPA server
On (27/05/15 13:25), Martin Babinsky wrote:
>https://fedorahosted.org/freeipa/ticket/4964
>
>--
>Martin^3 Babinsky
>From ef8481ee0267a720551832baae9398b435b3c6c5 Mon Sep 17 00:00:00 2001
>From: Martin Babinsky
>Date: Tue, 26 May 2015 18:11:08 +0200
>Subject: [PATCH] increase NSS memcache timeout for IPA server
>
>Increasing memcache timeout to 600 seconds when configuring sssd on IPA server
>should improve performance when dealing with large groups in trusts.
>
>https://fedorahosted.org/freeipa/ticket/4964
>---
> ipa-client/ipa-install/ipa-client-install | 9 +
> 1 file changed, 9 insertions(+)
>
>diff --git a/ipa-client/ipa-install/ipa-client-install
>b/ipa-client/ipa-install/ipa-client-install
>index
>63e3c9800791f3d29c977d63815c4291f5a235b9..ab3bc8a652dad01b9db5a26b877f38b850cb07f1
> 100755
>--- a/ipa-client/ipa-install/ipa-client-install
>+++ b/ipa-client/ipa-install/ipa-client-install
>@@ -1274,6 +1274,15 @@ def configure_sssd_conf(fstore, cli_realm, cli_domain,
>cli_server, options, clie
> # the master should only use itself for Kerberos
> domain.set_option('ipa_server', cli_server[0])
>
>+# increase memcache timeout to 10 minutes when in server mode
>+try:
>+nss_service = sssdconfig.get_service('nss')
>+except SSSDConfig.NoServiceError:
>+nss_service = sssdconfig.new_service('nss')
>+
>+nss_service.set_option('memcache_timeout', 600)
>+sssdconfig.save_service(nss_service)
>+
NACK
It should not be set to such high value for each client.
It should be configured if and only if sssd is in the ipa-server mode
(trust with AD)
LS
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On 2015-05-27 11:59, Martin Kosek wrote: > On 05/27/2015 11:53 AM, Alexander Bokovoy wrote: >> On Wed, 27 May 2015, Martin Kosek wrote: >>> On 05/26/2015 05:40 PM, Jan Cholasta wrote: Dne 22.5.2015 v 12:24 Christian Heimes napsal(a): >>> ... > Finally I haven't figured out the best way to configure the instance. An > admin should be able to enable / disable KDC proxy. Should I write a > script or a ipa plugin for the job? A script, ipa-kdcproxy-install, if you want to be consistent with what's already there. >>> >>> I thought we wanted to install it by default and only switch it on/off via >>> configuration in LDAP. In that case, no ipa-*-install should be needed. >> As with any other feature which requires configuration of other >> components, if it wasn't installed before, you need to make sure you are >> able to configure it over upgraded instance. Not providing >> ipa-kdcproxy-install would mean you are not supporting an upgrade case. > > I do not disagree with the approach for optional components. But as I wrote > above, this was supposed to be configured everywhere by default - both on new > and upgraded installations. > > AFAIK, it is mostly just one config for Apache and wsgi script. Yes, it is really just one boolean switch (service enabled/disabled). The state of the switch is read when Apache is started or reloaded. In the default state KDC Proxy is enabled. When the service is disabled, the WSGI script replies with 404 instead. All remaining settings like kdc, kadmin and kpasswd server(s) are read from /etc/krb5.conf. I had both the per-replica and the global switch implemented. After I discussion with Nathaniel and Martin, it's now a global switch only. Nathaniel argued, that a global switch is easier to implement as well as sufficient for now. The state of the switch is controlled with ipa config-mod: ipa config-mod --enable-kdcproxy=TRUE ipa config-mod --enable-kdcproxy=FALSE The schema changes for the new attribute are handled by ipa-server-upgrade. The Apache config file is created ipa-server-install, ipa-replica-install and ipa-server-upgrade. Christian signature.asc Description: OpenPGP digital signature -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 0038] increase NSS memcache timeout for IPA server
https://fedorahosted.org/freeipa/ticket/4964
--
Martin^3 Babinsky
From ef8481ee0267a720551832baae9398b435b3c6c5 Mon Sep 17 00:00:00 2001
From: Martin Babinsky
Date: Tue, 26 May 2015 18:11:08 +0200
Subject: [PATCH] increase NSS memcache timeout for IPA server
Increasing memcache timeout to 600 seconds when configuring sssd on IPA server
should improve performance when dealing with large groups in trusts.
https://fedorahosted.org/freeipa/ticket/4964
---
ipa-client/ipa-install/ipa-client-install | 9 +
1 file changed, 9 insertions(+)
diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install
index 63e3c9800791f3d29c977d63815c4291f5a235b9..ab3bc8a652dad01b9db5a26b877f38b850cb07f1 100755
--- a/ipa-client/ipa-install/ipa-client-install
+++ b/ipa-client/ipa-install/ipa-client-install
@@ -1274,6 +1274,15 @@ def configure_sssd_conf(fstore, cli_realm, cli_domain, cli_server, options, clie
# the master should only use itself for Kerberos
domain.set_option('ipa_server', cli_server[0])
+# increase memcache timeout to 10 minutes when in server mode
+try:
+nss_service = sssdconfig.get_service('nss')
+except SSSDConfig.NoServiceError:
+nss_service = sssdconfig.new_service('nss')
+
+nss_service.set_option('memcache_timeout', 600)
+sssdconfig.save_service(nss_service)
+
domain.set_option('ipa_domain', cli_domain)
domain.set_option('ipa_hostname', client_hostname)
if cli_domain.lower() != cli_realm.lower():
--
2.1.0
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Domain level for topology plugin = 2
On 05/26/2015 04:32 PM, Petr Spacek wrote: > On 26.5.2015 16:16, Martin Kosek wrote: ... > If you really want to avoid unforeseen issues rather go and get rid of > "major.minor" logic we have in the topology plugin right now :-) Ludwig, I thought we agreed to avoid using major.minor format in the topology plugin Domain Level implementation, to both avoid confusion of users and to not ship unused code - right? Thanks, Martin -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 857 topology: ipa management commands
On 05/27/2015 11:36 AM, Oleg Fayans wrote: The current version of the patch can not be applied: git apply freeipa-pvoborni-0857-1-topology-ipa-management-commands.patch error: patch failed: VERSION:90 error: VERSION: patch does not apply This patch should apply on current master. All its dependencies were pushed. Worked for me. Also, is freeipa-pvoborni-0855-server-find-and-server-show-commands.patch already merged? Yes, this was pushed. Generally what is the current list of patches that need to be applied in order to test this feature? I currently have the following set: freeipa-pvoborni-0822-1-webui-topology-plugin.patch could be disregarded, was replaced with patches 858-861 freeipa-pvoborni-0857-1-topology-ipa-management-commands.patch needed for testing CLI and is a prerequisite for Web UI freeipa-pvoborni-0858-webui-IPA.command_dialog-a-new-dialog-base-class.patch freeipa-pvoborni-0859-webui-use-command_dialog-as-a-base-class-for-passwor.patch freeipa-pvoborni-0860-webui-make-usage-of-all-in-details-facet-optional.patch freeipa-pvoborni-0861-webui-topology-plugin.patch 858-861 are Web UI, I'll sent new versions today because the domains level API was changed after these patches had been created and therefore the patches uses an incorrect call. Is there anything else that I've missed? No, but we don't have a patch for ticket #5035 which effectively blocks us with testing the core of the topology effort. It's something Ludwig should look at. On 05/26/2015 03:31 PM, Petr Vobornik wrote: On 05/26/2015 12:19 PM, Petr Vobornik wrote: this patch is based on top of my patch #856 and tbabej' s 325-9. Obsoletes Ludwig's 0006. ipalib part of topology management Design: - http://www.freeipa.org/page/V4/Manage_replication_topology https://fedorahosted.org/freeipa/ticket/4302 New version attached: - domainlevel_show usage changed to domainlevel_get - updated VERSION - added more attrs to default_attributes -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 857 topology: ipa management commands
On 05/26/2015 03:56 PM, Oleg Fayans wrote: Hi Petr, team After playing around with the previous version of your patch applied on top of the current master branch today in the morning, I still observe the problem with replica installation, described here: https://fedorahosted.org/freeipa/ticket/5035 This issue is not fixed with this patch. There is no patch for #5035 yet. This patch only adds ipalib API and CLI related to topology suffix and topology segment management. Over 857, patch 857-1 fixes only the 'internal error' which was in previous version(invalid domainslevel-show call). the session transcript together with ipareplica-install.log and the errors log of the dirsrv on master are attached. The following lines in the error log might be of interest: [26/May/2015:08:46:09 -0400] NSMMReplicationPlugin - Finished total update of replica "agmt="cn=meToreplica1.pesen.net" (replica1:389)". Sent 382 entries. [26/May/2015:08:46:11 -0400] ipa-topology-plugin - ipa_topo_util_modify: failed to modify entry (cn=meToreplica1.pesen.net,cn=replica,cn=dc\3Dpesen\2Cdc\3Dnet,cn=mapping tree,cn=config): error 53 [26/May/2015:08:46:17 -0400] repl_version_plugin_recv_acquire_cb - [file ipa_repl_version.c, line 119]: Incompatible IPA versions, pausing replication. This server: "2010061412" remote server: "(null)". [26/May/2015:08:46:38 -0400] NSMMReplicationPlugin - agmt="cn=meToreplica1.pesen.net" (replica1:389): Unable to receive the response for a startReplication extended operation to consumer (Can't contact LDAP server). Will retry later. [26/May/2015:08:46:41 -0400] NSMMReplicationPlugin - agmt="cn=meToreplica1.pesen.net" (replica1:389): Replication bind with SIMPLE auth resumed [26/May/2015:08:47:42 -0400] NSMMReplicationPlugin - Beginning total update of replica "agmt="cn=masterAgreement1-replica1.pesen.net-pki-tomcat" (replica1:389)". [26/May/2015:08:47:46 -0400] NSMMReplicationPlugin - Finished total update of replica "agmt="cn=masterAgreement1-replica1.pesen.net-pki-tomcat" (replica1:389)". Sent 70 entries. [26/May/2015:08:48:28 -0400] repl_version_plugin_recv_acquire_cb - [file ipa_repl_version.c, line 119]: Incompatible IPA versions, pausing replication. This server: "2010061412" remote server: "(null)". [26/May/2015:08:48:28 -0400] repl_version_plugin_recv_acquire_cb - [file ipa_repl_version.c, line 119]: Incompatible IPA versions, pausing replication. This server: "2010061412" remote server: "(null)". Should I rebuild the packages with the latest version of your patch on top of the current master with Tomas' latest Domain Level-related changes and try again? On 05/26/2015 03:31 PM, Petr Vobornik wrote: On 05/26/2015 12:19 PM, Petr Vobornik wrote: this patch is based on top of my patch #856 and tbabej' s 325-9. Obsoletes Ludwig's 0006. ipalib part of topology management Design: - http://www.freeipa.org/page/V4/Manage_replication_topology https://fedorahosted.org/freeipa/ticket/4302 New version attached: - domainlevel_show usage changed to domainlevel_get - updated VERSION - added more attrs to default_attributes -- Petr Vobornik -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Yet another user certificates/Smart Card thread
On Tue, May 26, 2015 at 07:49:10AM +0200, Martin Kosek wrote:
> On 05/25/2015 04:40 PM, Jan Cholasta wrote:
> >Dne 25.5.2015 v 16:26 Fraser Tweedale napsal(a):
> >>On Mon, May 25, 2015 at 03:56:46PM +0200, Martin Kosek wrote:
> >>>On 05/25/2015 03:13 PM, Jan Cholasta wrote:
> Hi,
>
> Dne 25.5.2015 v 14:55 Martin Babinsky napsal(a):
> >Hello all, long post ahead!
> >
> >I became a proud owner of https://fedorahosted.org/freeipa/ticket/4238,
> >and while Martin's design page
> >(http://www.freeipa.org/page/V4/User_Certificates) brings a
> >comprehensive overview of what should be done, there are still some gray
> >areas we should address both in the design page and the actual
> >implementation.
> >
> >These are the things that were agreed upon in previous thread(s):
> >
> >1.) If the whole user certificates are available, the should be stored
> >directly in the user entry as an attribute of the following format:
> >
> > "userCertificate;binary;$id",
> >
> >where "id" should be an unique identifier. IIRC we agreed that the
> >first/last 4 bytes of cert's SHA512 hash should fill the 'id' role
> >nicely. During user authentication the whole binary blob would be
> >matched (pspacek pointed out that the cost of this operation is
> >acceptable).
> >
> >2.) In addition, or when the user certs are stored externally, we should
> >store the certificate metadata in the user entry. These metadata should
> >be represented by "userCertAttrs;$id;$attr" attributes, where $attr
> >subtype corresponds to the type of metadata (issuer, serial no., profile
> >id, certificate hash etc.). The authentication/lookup would require some
> >custom matching rule to fetch the correct cert.
> >
> >Point 1. seems clear to me, we need to implement an index for
> >userCertificate attribute in DS and modify 'user-add/mod' commands to
> >allow for direct enrollment through API ("--usercertificate" option).
> >
> >Point 2. requires more work: we need to add a new attribute
> >"userCertAttrs" to the schema and create DS index/custom matching rule
> >for searching. I'm also not quite sure how to approach the task of
> >getting these metadata from external storage and putting them to the
> >user entry.
>
> Both points are obsolete. See the design page you linked for the current
> plan.
> >>>
> >>>Huh, where that came from Martin? Did you have some cached old version of
> >>>the
> >>>design page? I am just wondering what went wrong, as this is something I
> >>>deleted from that page month ago.
> >>>
> >>+1 ; we will just store the certificate(s) in the userCertificate
> >>attribute.
> >>
>
> >
> >These are the questions that should be addressed in a broader discussion:
> >
> >What is the relation to Fraser's work (cert profiles/sub-CAs)? I have
> >seen that the recent iteration of Fraser's patches (0010-3 and 0011-3)
> >add some ACIs and attributes/requests related to user certificates. I
> >suppose that the only way the user certs are related to cert profile
> >will be that there will be a profile ID stored either in cert itself, or
> >as a separate userCertAttr;$id;profileId attribute in user entry.
> >
> >>For the avoidance of doubt, there well be no way to query which
> >>profile was used to issue a certificate in the near term. Dogtag
> >>does store this information, but at the moment we are not planning
> >>to use it or expose it in IPA.
> >>
> >What to do with user certs when the entry is deleted? Should we revoke
> >them or let them expire?
>
> See
> .
>
> >>
> >>There was not really any conclusion to that discussion. I am in
> >>favour of a ``{user,host,service}-{del,mod} --[no-]revoke[=$REASON]``
> >>argument that says what to do when we delete a certificate, and
> >>allows specifying the revocation reason.
> >
> >I don't think we should add such option, for the same reasons why we did not
> >add the option to override the "store certificate in entry" policy in
> >cert-request.
> >
> >>
> >>I don't have a strong opinion on whether the default should be to
> >>revoke or not revoke, but I do think that the default revocation
> >>reason should be unspecified(0). superseded(4) is no longer
> >>appropriate.
> >
> >I would rather wait for Dogtag to implement the profile querying interface
> >before doing anything and just not revoke certificates for now.
>
> Well, whatever we do, it should not be a regression. So, we can change the
> global default (or make it different for upgraded/new installations as with
> some ACIs for PermissionsV2) but we should still have some possibility for a
> user to configure the behavior. FreeIPA should be still able to revoke certs
> stored in user/service/host entry during object-del/obj
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On 05/27/2015 11:53 AM, Alexander Bokovoy wrote: > On Wed, 27 May 2015, Martin Kosek wrote: >> On 05/26/2015 05:40 PM, Jan Cholasta wrote: >>> Dne 22.5.2015 v 12:24 Christian Heimes napsal(a): >> ... Finally I haven't figured out the best way to configure the instance. An admin should be able to enable / disable KDC proxy. Should I write a script or a ipa plugin for the job? >>> >>> A script, ipa-kdcproxy-install, if you want to be consistent with what's >>> already there. >> >> I thought we wanted to install it by default and only switch it on/off via >> configuration in LDAP. In that case, no ipa-*-install should be needed. > As with any other feature which requires configuration of other > components, if it wasn't installed before, you need to make sure you are > able to configure it over upgraded instance. Not providing > ipa-kdcproxy-install would mean you are not supporting an upgrade case. I do not disagree with the approach for optional components. But as I wrote above, this was supposed to be configured everywhere by default - both on new and upgraded installations. AFAIK, it is mostly just one config for Apache and wsgi script. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On 26.5.2015 17:56, Christian Heimes wrote: > On 2015-05-26 17:11, Nathaniel McCallum wrote: >> I don't want to add code that: 1. is half-baked 2. we aren't committed >> to supporting. >> >> I'd rather land per-replica switches as a separate commit with >> everything polished and supportable. > > Well then ... I'm going to remove the code for per-replica config and go > back to the global switch. Since I'm now familiar with the code, it's > easy for me to add it back, in case we need it again. :) I do not see a *need* for the user interface to the per-replica switch. We do not have such switch for any other optional component, like DNS. IMHO it is perfectly fine to have only per-replica switch as we do for all other components - and do not have user interface to the switch as we do not have it for any other component. It would be consistent, easy, and future proof. -- Petr^2 Spacek -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On Wed, 27 May 2015, Martin Kosek wrote: On 05/26/2015 05:40 PM, Jan Cholasta wrote: Dne 22.5.2015 v 12:24 Christian Heimes napsal(a): ... Finally I haven't figured out the best way to configure the instance. An admin should be able to enable / disable KDC proxy. Should I write a script or a ipa plugin for the job? A script, ipa-kdcproxy-install, if you want to be consistent with what's already there. I thought we wanted to install it by default and only switch it on/off via configuration in LDAP. In that case, no ipa-*-install should be needed. As with any other feature which requires configuration of other components, if it wasn't installed before, you need to make sure you are able to configure it over upgraded instance. Not providing ipa-kdcproxy-install would mean you are not supporting an upgrade case. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)
On 05/26/2015 05:40 PM, Jan Cholasta wrote: > Dne 22.5.2015 v 12:24 Christian Heimes napsal(a): ... >> Finally I haven't figured out the best way to configure the instance. An >> admin should be able to enable / disable KDC proxy. Should I write a >> script or a ipa plugin for the job? > > A script, ipa-kdcproxy-install, if you want to be consistent with what's > already there. I thought we wanted to install it by default and only switch it on/off via configuration in LDAP. In that case, no ipa-*-install should be needed. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 857 topology: ipa management commands
The current version of the patch can not be applied: git apply freeipa-pvoborni-0857-1-topology-ipa-management-commands.patch error: patch failed: VERSION:90 error: VERSION: patch does not apply Also, is freeipa-pvoborni-0855-server-find-and-server-show-commands.patch already merged? Generally what is the current list of patches that need to be applied in order to test this feature? I currently have the following set: freeipa-pvoborni-0822-1-webui-topology-plugin.patch freeipa-pvoborni-0857-1-topology-ipa-management-commands.patch freeipa-pvoborni-0858-webui-IPA.command_dialog-a-new-dialog-base-class.patch freeipa-pvoborni-0859-webui-use-command_dialog-as-a-base-class-for-passwor.patch freeipa-pvoborni-0860-webui-make-usage-of-all-in-details-facet-optional.patch freeipa-pvoborni-0861-webui-topology-plugin.patch Is there anything else that I've missed? On 05/26/2015 03:31 PM, Petr Vobornik wrote: > On 05/26/2015 12:19 PM, Petr Vobornik wrote: >> this patch is based on top of my patch #856 and tbabej' >> s 325-9. >> >> Obsoletes Ludwig's 0006. >> >> ipalib part of topology management >> >> Design: >> - http://www.freeipa.org/page/V4/Manage_replication_topology >> >> https://fedorahosted.org/freeipa/ticket/4302 >> >> > > New version attached: > - domainlevel_show usage changed to domainlevel_get > - updated VERSION > - added more attrs to default_attributes > > -- Oleg Fayans Quality Engineer FreeIPA team RedHat. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
