Re: [Freeipa-devel] Domain level for topology plugin = 2

[Petr Spacek]

On 28.5.2015 08:55, Jan Cholasta wrote:
> 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?

Good point!

-- 
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)

[Christian Heimes]

On 2015-05-28 07:32, Jan Cholasta wrote:
> 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?

The python-kdcproxy package is a new dependency for the freeipa-server
package. It will always get installed with the server.




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)

[Jan Cholasta]

Dne 28.5.2015 v 09:45 Christian Heimes napsal(a):

On 2015-05-28 07:32, Jan Cholasta wrote:

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?


The python-kdcproxy package is a new dependency for the freeipa-server
package. It will always get installed with the server.


Why? None of the IPA core functionality depends on it, so it should be 
optional. Also the overall trend in IPA is to have everything in 
subpackages.


--
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)

[Christian Heimes]

On 2015-05-28 10:02, Jan Cholasta wrote:
>> The python-kdcproxy package is a new dependency for the freeipa-server
>> package. It will always get installed with the server.
> 
> Why? None of the IPA core functionality depends on it, so it should be
> optional. Also the overall trend in IPA is to have everything in
> subpackages.

We discussed the idea on the internal IPA and Samba team list (KDC proxy
for FreeIPA 4.2 on 2015-05-15). My initial design suggested a separate
freeipa-server-kdcproxy package. Nathaniel, Nathan and Dmitri were in
favor of a new dependency instead of a new subpackage.

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 0014] Support multiple user and host certificates

[Fraser Tweedale]

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 :)
> 
> I personally vote for serial number in case there are multiple certificates,
> if ^ is no possible.
> 
Actually, yeah, we can just write the PEMs to a single file,
sequentially.  I don't know why I didn't think of that... ¯\_(ツ)_/¯

> 
> 1)
> +if len(certs) > 0:
> 
> please use only,
> if certs:
> 
I have strong feels about this.  ``if len(certs) > 0:`` admits fewer
bugs than ``if certs:`` , e.g. if 'certs' were bound to a
non-length-able object by mistake.  Even though we have already
iterated ``certs`` at this point in the function, this failure mode
is still possible, e.g. if ``certs`` is a generator.  Using ``if
certs:`` will not fail for a generator, but it will be a silent bug!

PEP-8 is wrong on this one.  It is better to use the construction
that admits fewer errors.  Unless it causes lint failure (on f21 it
does not) I prefer not to change it.

> 2)
> You need to re-generate API/ACI.txt in this patch
> 
Good pickup, thanks.

> 3)
> syntax error:
> +for dercert in certs_der
> 
Geez... dunno how I let that one past -_-  My bad.

> 
> 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
> 

Yeah... I was a bit confused about how --addattr=... interacts with
options.  I understand it now, and yes I think we should revoke
certificates that get removed this way.

cert-request will use addattr= so no existing certificates will get
removed (or revoked).  New patch addressing this and other points
will arrive on list today.

Thanks for reviewing!
Fraser

> -- 
> 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] Kerberos over HTTPS (KDC proxy)

[Petr Spacek]

On 28.5.2015 07:42, Jan Cholasta wrote:
> 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.)

I very much agree with Honza - we have per-replica boolean for every service
so there is no reason not to have one for kdc proxy, especially when we
consider future containerization of services.

-- 
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)

[Martin Kosek]

On 05/28/2015 10:02 AM, Jan Cholasta wrote:
> Dne 28.5.2015 v 09:45 Christian Heimes napsal(a):
>> On 2015-05-28 07:32, Jan Cholasta wrote:
>>> 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?
>>
>> The python-kdcproxy package is a new dependency for the freeipa-server
>> package. It will always get installed with the server.
> 
> Why? None of the IPA core functionality depends on it, so it should be
> optional. Also the overall trend in IPA is to have everything in subpackages.

Do not look at it as a separate component. It is mostly just a new transport
for Kerberos. FreeIPA already provides Kerberos via TCP and UDP. This is a
third transport - HTTP.

-- 
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)

[Martin Kosek]

On 05/28/2015 07:29 AM, Jan Cholasta wrote:
> 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.

It is not another new service, like DNS or CA. It is another transport for
Kerberos, on top of TCP/UDP. Can we please stop bikeshedding here?

-- 
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

[Martin Kosek]

On 05/27/2015 05:05 PM, Oleg Fayans wrote:
> 
> 
> 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.

Right. I would suggest this bug to be now the top priority for Ludwig.

>> - 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.
>>
> 

-- 
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]

On 05/27/2015 08:17 PM, Martin Basti wrote:

On 27/05/15 19:27, Rob Crittenden wrote:

Martin Basti wrote:



Thank you.

I haven't finished review yet, but I have few notes in case you will
modify the patch.

Please fix following issues:




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.


In old modules it's preferred to keep the old indentation style for 
options(not to mix 2 styles). New modules should use following pep8 
compliant style:

Str(
'cn',
cli_name='name',
primary_key=True,
label=_('Server name'),
doc=_('IPA server hostname'),
),


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




I'll wait and see what falls out of the API review before making any
real changes.

rob



Martin^2




--
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 0014] Support multiple user and host certificates

[Martin Basti]

On 28/05/15 10:13, Fraser Tweedale wrote:

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 :)

I personally vote for serial number in case there are multiple certificates,
if ^ is no possible.


Actually, yeah, we can just write the PEMs to a single file,
sequentially.  I don't know why I didn't think of that... ¯\_(ツ)_/¯


1)
+if len(certs) > 0:

please use only,
if certs:


I have strong feels about this.  ``if len(certs) > 0:`` admits fewer
bugs than ``if certs:`` , e.g. if 'certs' were bound to a
non-length-able object by mistake.  Even though we have already
iterated ``certs`` at this point in the function, this failure mode
is still possible, e.g. if ``certs`` is a generator.  Using ``if
certs:`` will not fail for a generator, but it will be a silent bug!

PEP-8 is wrong on this one.  It is better to use the construction
that admits fewer errors.  Unless it causes lint failure (on f21 it
does not) I prefer not to change it.

I still think it should be in PEP8 style.

We should avoid these mistakes, not create the code which will detect it.

And, I forgot to write, please use
except Exception as e:  instead except Exception, e
to be compatible with python3

2)
You need to re-generate API/ACI.txt in this patch


Good pickup, thanks.


3)
syntax error:
+for dercert in certs_der


Geez... dunno how I let that one past -_-  My bad.


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


Yeah... I was a bit confused about how --addattr=... interacts with
options.  I understand it now, and yes I think we should revoke
certificates that get removed this way.

cert-request will use addattr= so no existing certificates will get
removed (or revoked).  New patch addressing this and other points
will arrive on list today.

Thanks for reviewing!
Fraser


--
Martin Basti




--
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] Sudorules user validation help

[Martin Kosek]

On 05/27/2015 08:41 PM, Drew Erny wrote:
> 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?

I think it would make sense to follow the example with validate_hostname and
prepare a function validate_username(username, upn=False, netbios_name=False) 
[1].

where upn would allow using "@." on top of current validator (i.e.
u...@domain.test) and netbios_name would allow the "DOMAIN\user" style. I would
just suggest making sure the standard user validation error message is still
the same to avoid unnecessary QE fail positives.

In add_external_pre_callback you could then just simply call

validate_username(user, True, True)

just like it is already done with hostname.

My 2 cents.

Martin

[1] 
https://msdn.microsoft.com/en-us/library/windows/desktop/aa380525(v=vs.85).aspx

-- 
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

[Martin Kosek]

On 05/27/2015 06:12 PM, 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 :)
> 
> 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.

Good question. I think the suggestion was to have a global switch in IPA global
config that would configure the policy - whether the certificates removed by
this command or by host-del or host-disable are revoked or if they are just
removed (my motivation is to avoid behavior regression in case somebody
depended on this behavior).

> 
> only the --addattr='usercertificate=' appends new value there
> 
> 
> 

-- 
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

[Martin Kosek]

On 05/28/2015 09:05 AM, Petr Spacek wrote:
> On 28.5.2015 08:55, Jan Cholasta wrote:
>> 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?
> 
> Good point!
> 

It may be a good point, but it does not make the situation easier. You still
have RHEL/CentOS 6.x IPA out there, where some of them already support the new
DNS forwarders and some don't - and neither of them support Domain Levels -
i.e. have Domain Level 0.

As I said, I still see more complications with this proposals than benefits...

-- 
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)

[Alexander Bokovoy]

On Thu, 28 May 2015, Petr Spacek wrote:

On 28.5.2015 07:42, Jan Cholasta wrote:

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.)


I very much agree with Honza - we have per-replica boolean for every service
so there is no reason not to have one for kdc proxy, especially when we
consider future containerization of services.

A mere 'me too' here. Note that once updates to RFC 4120 as outlined in
https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-00
would be accepted, clients will not be assuming all of replicas serve
MS-KKDCP proxies so there will not be need to run them everywhere.
Rather, only the servers on a network boundary will need to be
advertised. This means we'll eventually get per-replica need as well.

It is fine to assume right now that all of them are going to run
MS-KKDCP proxy but configuration isn't really going to be global.

Additionally, ipa-kdcproxy-manage would need to manipulate
_kerberos.$DOMAIN URI DNS records too, so there is more than just
switching the boolean here.
--
/ 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)

[Alexander Bokovoy]

On Thu, 28 May 2015, Martin Kosek wrote:

On 05/28/2015 10:02 AM, Jan Cholasta wrote:

Dne 28.5.2015 v 09:45 Christian Heimes napsal(a):

On 2015-05-28 07:32, Jan Cholasta wrote:

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?


The python-kdcproxy package is a new dependency for the freeipa-server
package. It will always get installed with the server.


Why? None of the IPA core functionality depends on it, so it should be
optional. Also the overall trend in IPA is to have everything in subpackages.


Do not look at it as a separate component. It is mostly just a new transport
for Kerberos. FreeIPA already provides Kerberos via TCP and UDP. This is a
third transport - HTTP.

See my other response. With changes in 
https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-00
we'll need to manage _kerberos.$DOMAIN URI DNS record (not just TXT one
like now) to explicitly report where the proxies are located. This goes
beyond just global switch in LDAP and requires ipa-kdcproxy-manage tool.
--
/ 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 0014] Support multiple user and host certificates

[Martin Basti]

On 28/05/15 10:46, Martin Kosek wrote:

On 05/27/2015 06:12 PM, 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 :)

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.

Good question. I think the suggestion was to have a global switch in IPA global
config that would configure the policy - whether the certificates removed by
this command or by host-del or host-disable are revoked or if they are just
removed (my motivation is to avoid behavior regression in case somebody
depended on this behavior).
I would prefer to keep the current behavior: revoke the certificate if 
it was replaced or removed, instead of adding an extra configuration option.

This behavior is not regression.

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 0014] Support multiple user and host certificates

[Fraser Tweedale]

On Thu, May 28, 2015 at 10:40:22AM +0200, Martin Basti wrote:
> On 28/05/15 10:13, Fraser Tweedale wrote:
> >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 :)
> >>
> >>I personally vote for serial number in case there are multiple certificates,
> >>if ^ is no possible.
> >>
> >Actually, yeah, we can just write the PEMs to a single file,
> >sequentially.  I don't know why I didn't think of that... ¯\_(ツ)_/¯
> >
> >>1)
> >>+if len(certs) > 0:
> >>
> >>please use only,
> >>if certs:
> >>
> >I have strong feels about this.  ``if len(certs) > 0:`` admits fewer
> >bugs than ``if certs:`` , e.g. if 'certs' were bound to a
> >non-length-able object by mistake.  Even though we have already
> >iterated ``certs`` at this point in the function, this failure mode
> >is still possible, e.g. if ``certs`` is a generator.  Using ``if
> >certs:`` will not fail for a generator, but it will be a silent bug!
> >
> >PEP-8 is wrong on this one.  It is better to use the construction
> >that admits fewer errors.  Unless it causes lint failure (on f21 it
> >does not) I prefer not to change it.
> I still think it should be in PEP8 style.
> 
> We should avoid these mistakes, not create the code which will detect it.
> 
How do you know if you made a mistake?  This is not just about me
making this change now.  If someone in the future comes along and
for whatever reasons changes the list to a generator, the diff in
isolation may look like a good change, and the reviewer might not
notice that the change leads to undesired behaviour elsewhere
(outside the diff context).

If you have good test coverage, tests might catch the bug.  If not,
hopefully QE notices the incorrect behaviour before a customer does.
The best tool is a type system so you don't get a program if you
make a mistake like this.  Well, Python doesn't give us that tool
but let us not ignore what it *can* do to help us for the sake of
adhereing to PEP-8 or saving a few characters.

> And, I forgot to write, please use
> except Exception as e:  instead except Exception, e
> to be compatible with python3
>
Sure, no problem.

> >>2)
> >>You need to re-generate API/ACI.txt in this patch
> >>
> >Good pickup, thanks.
> >
> >>3)
> >>syntax error:
> >>+for dercert in certs_der
> >>
> >Geez... dunno how I let that one past -_-  My bad.
> >
> >>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
> >>
> >Yeah... I was a bit confused about how --addattr=... interacts with
> >options.  I understand it now, and yes I think we should revoke
> >certificates that get removed this way.
> >
> >cert-request will use addattr= so no existing certificates will get
> >removed (or revoked).  New patch addressing this and other points
> >will arrive on list today.
> >
> >Thanks for reviewing!
> >Fraser
> >
> >>-- 
> >>Martin Basti
> >>
> 
> 
> -- 
> 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] [PATCHES 0001-0013 v5] Profiles and CA ACLs

[Martin Basti]

On 27/05/15 16:04, Fraser Tweedale wrote:

Hello all,

Fresh certificate management patchset; Changelog:

- Now depends on patch freeipa-ftweedal-0014 for correct
   cert-request behaviour with host and service principals.

- Updated Dogtag dependency to 10.2.4-1.  Should should be in f22
   soon, but for f22 right now or for f21, please grab from my copr:
   https://copr.fedoraproject.org/coprs/ftweedal/freeipa/

   Martin^1 could you please add to the quasi-official freeipa copr?
   SRPM lives at https://frase.id.au/pki-core-10.2.4-1.fc21.src.rpm.

- cert-request now verifies that for user principals, CSR CN matches
   uid and, DN emailAddress and SAN rfc822Name match user's email
   address, if either of those is present.

- Fixed one or two other sneaky little bugs.

On Wed, May 27, 2015 at 01:59:30AM +1000, Fraser Tweedale wrote:

Hi all,

Please find attached the latest certificate management patchset,
which introduces the `caacl' plugin and various fixes and
improvement to earlier patches.

One important change to earlier patches is reverting the name of the
default profile to 'caIPAserviceCert' and using the existing
instance of this profile on upgrade (but not install) in case it has
been modified.

Other notes:

- Still have changes in ipa-server-install (fewer lines now, though)

- Still have the ugly import hack.  It is not a high priority for
   me, i.e. I think it should wait until after alpha

- Still need to update 'service' and 'host' plugins to support
   multiple certificates.  (The userCertificate attribute schema
   itself is multi-valued, so there are no schema issues here)

- The TODOs in [1]; mostly certprofile CLI conveniences and
   supporting multiple profiles for hosts and services (which
   requires changes to framework only, not schema).
   [1]: http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress

Happy reviewing!  I am pleased with the initial cut of the caacl
plugin but I'm sure you will find some things to be fixed :)

Cheers,
Fraser


[root@vm-093 ~]#  ipa-replica-prepare vm-094.example.com --ip-address 
10.34.78.94

Directory Manager (existing master) password:

Preparing replica for vm-094.example.com from vm-093.example.com
Creating SSL certificate for the Directory Server
not well-formed (invalid token): line 2, column 14

I cannot create replica file.
It work on the upgraded server, but it doesn't work on the newly 
installed server.
I'm not sure if this causes your patches which modifies the 
ca-installer, or the newer version of dogtag.


Or if there was any other changes in master, I will continue to 
investigate with new RPM from master branch.


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 0014] Support multiple user and host certificates

[Martin Kosek]

On 05/28/2015 11:17 AM, Martin Basti wrote:
> On 28/05/15 10:46, Martin Kosek wrote:
>> On 05/27/2015 06:12 PM, 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 :)
>>>
>>> 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.
>> Good question. I think the suggestion was to have a global switch in IPA 
>> global
>> config that would configure the policy - whether the certificates removed by
>> this command or by host-del or host-disable are revoked or if they are just
>> removed (my motivation is to avoid behavior regression in case somebody
>> depended on this behavior).
> I would prefer to keep the current behavior: revoke the certificate if it was
> replaced or removed, instead of adding an extra configuration option.
> This behavior is not regression.

It is not. However, it is not an ideal behavior also. In FreeIPA 4.2, we are
now adding support of certificate profiles, multiple certificates and even
certificates for user.

With that change, there may be much more certificates in play than now. If we
keep revoking all such certificates, it may cause rapid growth of CRLs. This is
something I am trying to avoid with this proposal and default to not revoking
certificates automatically (which mostly only makes sense if there is a risk
that the key is compromised), but have some option to keep the old behavior.

Does this make sense?

-- 
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

[Martin Basti]

On 28/05/15 11:17, Fraser Tweedale wrote:

On Thu, May 28, 2015 at 10:40:22AM +0200, Martin Basti wrote:

On 28/05/15 10:13, Fraser Tweedale wrote:

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 :)

I personally vote for serial number in case there are multiple certificates,
if ^ is no possible.


Actually, yeah, we can just write the PEMs to a single file,
sequentially.  I don't know why I didn't think of that... ¯\_(ツ)_/¯


1)
+if len(certs) > 0:

please use only,
if certs:


I have strong feels about this.  ``if len(certs) > 0:`` admits fewer
bugs than ``if certs:`` , e.g. if 'certs' were bound to a
non-length-able object by mistake.  Even though we have already
iterated ``certs`` at this point in the function, this failure mode
is still possible, e.g. if ``certs`` is a generator.  Using ``if
certs:`` will not fail for a generator, but it will be a silent bug!

PEP-8 is wrong on this one.  It is better to use the construction
that admits fewer errors.  Unless it causes lint failure (on f21 it
does not) I prefer not to change it.

I still think it should be in PEP8 style.

We should avoid these mistakes, not create the code which will detect it.


How do you know if you made a mistake?  This is not just about me
making this change now.  If someone in the future comes along and
for whatever reasons changes the list to a generator, the diff in
isolation may look like a good change, and the reviewer might not
notice that the change leads to undesired behaviour elsewhere
(outside the diff context).

If you have good test coverage, tests might catch the bug.  If not,
hopefully QE notices the incorrect behaviour before a customer does.
The best tool is a type system so you don't get a program if you
make a mistake like this.  Well, Python doesn't give us that tool
but let us not ignore what it *can* do to help us for the sake of
adhereing to PEP-8 or saving a few characters.


Ok then, leave there len() > 0

but to catch these kind of mistakes, we should have asserts everywhere 
to verify type.



And, I forgot to write, please use
except Exception as e:  instead except Exception, e
to be compatible with python3


Sure, no problem.


2)
You need to re-generate API/ACI.txt in this patch


Good pickup, thanks.


3)
syntax error:
+for dercert in certs_der


Geez... dunno how I let that one past -_-  My bad.


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


Yeah... I was a bit confused about how --addattr=... interacts with
options.  I understand it now, and yes I think we should revoke
certificates that get removed this way.

cert-request will use addattr= so no existing certificates will get
removed (or revoked).  New patch addressing this and other points
will arrive on list today.

Thanks for reviewing!
Fraser


--
Martin Basti



--
Martin Basti




--
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] Kerberos over HTTPS (KDC proxy)

[Martin Kosek]

On 05/28/2015 11:12 AM, Alexander Bokovoy wrote:
> On Thu, 28 May 2015, Petr Spacek wrote:
>> On 28.5.2015 07:42, Jan Cholasta wrote:
>>> 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.)
>>
>> I very much agree with Honza - we have per-replica boolean for every service
>> so there is no reason not to have one for kdc proxy, especially when we
>> consider future containerization of services.
> A mere 'me too' here. Note that once updates to RFC 4120 as outlined in
> https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-00
> would be accepted, clients will not be assuming all of replicas serve
> MS-KKDCP proxies so there will not be need to run them everywhere.
> Rather, only the servers on a network boundary will need to be
> advertised. This means we'll eventually get per-replica need as well.
> 
> It is fine to assume right now that all of them are going to run
> MS-KKDCP proxy but configuration isn't really going to be global.
> 
> Additionally, ipa-kdcproxy-manage would need to manipulate
> _kerberos.$DOMAIN URI DNS records too, so there is more than just
> switching the boolean here.

I see. My question is - if we go this way, what is then the reasonable subset
configuration functionality realistic for FreeIPA 4.2 GA? (As we want this
feature in for 4.2). Is ipa-kdcproxy-manage doable?

What is the proposed API here?

ipa-kdcproxy-manage list
ipa-kdcproxy-manage enable 
ipa-kdcproxy-manage disable 

?

-- 
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

[Fraser Tweedale]

On Thu, May 28, 2015 at 11:52:25AM +0200, Martin Kosek wrote:
> On 05/28/2015 11:17 AM, Martin Basti wrote:
> > On 28/05/15 10:46, Martin Kosek wrote:
> >> On 05/27/2015 06:12 PM, 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 :)
> >>>
> >>> 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.
> >> Good question. I think the suggestion was to have a global switch in IPA 
> >> global
> >> config that would configure the policy - whether the certificates removed 
> >> by
> >> this command or by host-del or host-disable are revoked or if they are just
> >> removed (my motivation is to avoid behavior regression in case somebody
> >> depended on this behavior).
> > I would prefer to keep the current behavior: revoke the certificate if it 
> > was
> > replaced or removed, instead of adding an extra configuration option.
> > This behavior is not regression.
> 
> It is not. However, it is not an ideal behavior also. In FreeIPA 4.2, we are
> now adding support of certificate profiles, multiple certificates and even
> certificates for user.
> 
> With that change, there may be much more certificates in play than now. If we
> keep revoking all such certificates, it may cause rapid growth of CRLs. This 
> is
> something I am trying to avoid with this proposal and default to not revoking
> certificates automatically (which mostly only makes sense if there is a risk
> that the key is compromised), but have some option to keep the old behavior.
> 
> Does this make sense?
>
It does make senes.

In regards to *this* patch, I will make -mod behave the same as -del
and -disable; i.e. the current behaviour i.e. revoke whenever we
"forget" a certificate.

Any config knobs, command options, etc to govern whether to revoke
shall be added in a subsequent patch.

Cheers,
Fraser

-- 
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)

[Petr Spacek]

On 28.5.2015 11:59, Martin Kosek wrote:
> On 05/28/2015 11:12 AM, Alexander Bokovoy wrote:
>> On Thu, 28 May 2015, Petr Spacek wrote:
>>> On 28.5.2015 07:42, Jan Cholasta wrote:
 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.)
>>>
>>> I very much agree with Honza - we have per-replica boolean for every service
>>> so there is no reason not to have one for kdc proxy, especially when we
>>> consider future containerization of services.
>> A mere 'me too' here. Note that once updates to RFC 4120 as outlined in
>> https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-00
>> would be accepted, clients will not be assuming all of replicas serve
>> MS-KKDCP proxies so there will not be need to run them everywhere.
>> Rather, only the servers on a network boundary will need to be
>> advertised. This means we'll eventually get per-replica need as well.
>>
>> It is fine to assume right now that all of them are going to run
>> MS-KKDCP proxy but configuration isn't really going to be global.
>>
>> Additionally, ipa-kdcproxy-manage would need to manipulate
>> _kerberos.$DOMAIN URI DNS records too, so there is more than just
>> switching the boolean here.
> 
> I see. My question is - if we go this way, what is then the reasonable subset
> configuration functionality realistic for FreeIPA 4.2 GA? (As we want this
> feature in for 4.2). Is ipa-kdcproxy-manage doable?
> 
> What is the proposed API here?
> 
> ipa-kdcproxy-manage list
> ipa-kdcproxy-manage enable 
> ipa-kdcproxy-manage disable 

I believe that for 4.2 it is perfectly enough to have per-replica switch in
LDAP (enabled by default) and to provide ldapmodify command in docs. User
interface can be polished later if we get the design right.

-- 
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)

[Christian Heimes]

On 2015-05-28 12:10, Petr Spacek wrote:
>> I see. My question is - if we go this way, what is then the reasonable subset
>> configuration functionality realistic for FreeIPA 4.2 GA? (As we want this
>> feature in for 4.2). Is ipa-kdcproxy-manage doable?
>>
>> What is the proposed API here?
>>
>> ipa-kdcproxy-manage list
>> ipa-kdcproxy-manage enable 
>> ipa-kdcproxy-manage disable 
> 
> I believe that for 4.2 it is perfectly enough to have per-replica switch in
> LDAP (enabled by default) and to provide ldapmodify command in docs. User
> interface can be polished later if we get the design right.

For Petr proposal to work we only need an additional ACI and maybe an
additional permission. I'm using Apache's keytab for LDAP bin. The
principal has no permission to read or search ipaConfigString attributes
in the cn=masters tree.

A ipa-kdcproxy-manage is more work. I'd have to write the script and
implement a HTTP interface to reload all settings.

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)

[Alexander Bokovoy]

On Thu, 28 May 2015, Christian Heimes wrote:

On 2015-05-28 12:10, Petr Spacek wrote:

I see. My question is - if we go this way, what is then the reasonable subset
configuration functionality realistic for FreeIPA 4.2 GA? (As we want this
feature in for 4.2). Is ipa-kdcproxy-manage doable?

What is the proposed API here?

ipa-kdcproxy-manage list
ipa-kdcproxy-manage enable 
ipa-kdcproxy-manage disable 


I believe that for 4.2 it is perfectly enough to have per-replica switch in
LDAP (enabled by default) and to provide ldapmodify command in docs. User
interface can be polished later if we get the design right.


For Petr proposal to work we only need an additional ACI and maybe an
additional permission. I'm using Apache's keytab for LDAP bin. The
principal has no permission to read or search ipaConfigString attributes
in the cn=masters tree.

A ipa-kdcproxy-manage is more work. I'd have to write the script and
implement a HTTP interface to reload all settings.

I'm fine with that for 4.2. We can always add an example of
enable/disable via ipa-ldap-updater tool which should be simplest one
for admins as it includes template values for domain and IPA master
hosts. See https://vda.li/en/posts/2015/01/02/playing-with-freeipa-ipa-ldap-updater/ 
for examples, this one would be similar to how weak enctypes are enabled:


# 20-kdcproxy-enable-on-this-master.update
dn: cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX
add:ipaConfigString:enabledService

# 20-kdcproxy-disable-on-this-master.update
dn: cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX
remove:ipaConfigString:enabledService


--
/ 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] [PATCHES 0001-0013 v5] Profiles and CA ACLs

[Petr Vobornik]

On 05/28/2015 11:48 AM, Martin Basti wrote:

On 27/05/15 16:04, Fraser Tweedale wrote:

Hello all,

Fresh certificate management patchset; Changelog:

- Now depends on patch freeipa-ftweedal-0014 for correct
   cert-request behaviour with host and service principals.

- Updated Dogtag dependency to 10.2.4-1.  Should should be in f22
   soon, but for f22 right now or for f21, please grab from my copr:
   https://copr.fedoraproject.org/coprs/ftweedal/freeipa/

   Martin^1 could you please add to the quasi-official freeipa copr?
   SRPM lives at https://frase.id.au/pki-core-10.2.4-1.fc21.src.rpm.



I've added it to mkosek/freeipa-master

The build was successful on f22 but failed on f21. Should it be 
successful on f21?


https://copr.fedoraproject.org/coprs/mkosek/freeipa-master/build/94540/
--
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)

[Martin Kosek]

On 05/28/2015 12:27 PM, Alexander Bokovoy wrote:
> On Thu, 28 May 2015, Christian Heimes wrote:
>> On 2015-05-28 12:10, Petr Spacek wrote:
 I see. My question is - if we go this way, what is then the reasonable 
 subset
 configuration functionality realistic for FreeIPA 4.2 GA? (As we want this
 feature in for 4.2). Is ipa-kdcproxy-manage doable?

 What is the proposed API here?

 ipa-kdcproxy-manage list
 ipa-kdcproxy-manage enable 
 ipa-kdcproxy-manage disable 
>>>
>>> I believe that for 4.2 it is perfectly enough to have per-replica switch in
>>> LDAP (enabled by default) and to provide ldapmodify command in docs. User
>>> interface can be polished later if we get the design right.
>>
>> For Petr proposal to work we only need an additional ACI and maybe an
>> additional permission. I'm using Apache's keytab for LDAP bin. The
>> principal has no permission to read or search ipaConfigString attributes
>> in the cn=masters tree.
>>
>> A ipa-kdcproxy-manage is more work. I'd have to write the script and
>> implement a HTTP interface to reload all settings.
> I'm fine with that for 4.2. We can always add an example of
> enable/disable via ipa-ldap-updater tool which should be simplest one
> for admins as it includes template values for domain and IPA master
> hosts. See
> https://vda.li/en/posts/2015/01/02/playing-with-freeipa-ipa-ldap-updater/ for
> examples, this one would be similar to how weak enctypes are enabled:
> 
> # 20-kdcproxy-enable-on-this-master.update
> dn: cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX
> add:ipaConfigString:enabledService
> 
> # 20-kdcproxy-disable-on-this-master.update
> dn: cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX
> remove:ipaConfigString:enabledService

I am fine with this too. So if there is not another major disagreement, let us
start with enabling KDCPROXY by default during upgrade/install, the new ACI and
the per-replica standard configuration.

API CLI/UI can come later (4.2.x or 4.3).

-- 
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)

[Christian Heimes]

On 2015-05-28 12:46, Martin Kosek wrote:
> I am fine with this too. So if there is not another major disagreement, let us
> start with enabling KDCPROXY by default during upgrade/install, the new ACI 
> and
> the per-replica standard configuration.
> 
> API CLI/UI can come later (4.2.x or 4.3).

LGTM, too.

How should the new ACI work? I see two possible ways:

1) Allow compare/search for ipaConfigString=enabledService for everybody:

(targetfilter="(ipaConfigString=enabledService)")(targetattr="ipaConfigString")(version
3.0; acl "Compare enabledService access to masters"; allow(search,
compare) userdn = "ldap:///all";;)

2) Create a new permission, assign it to all HTTP principals and allow
read, compare and search for all ipaConfigString attributes.

For the second way I need somebody to walk me through the permission and
role system of FreeIPA.

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] [PATCHES 326-328] ID Views improvements

[Tomas Babej]

Hi,

this couple of patches improves ID Views and ID overrides handling. See
commit messages for details.

Tomas
>From 8acc50c10d9886668a0147b46f311f9aa83294bb Mon Sep 17 00:00:00 2001
From: Tomas Babej 
Date: Wed, 27 May 2015 14:31:13 +0200
Subject: [PATCH] idviews: Set dcerpc detection flag properly

The availability of dcerpc bindings is being checked on the client
side as well, hence we need to define it properly.

https://fedorahosted.org/freeipa/ticket/5025
---
 ipalib/plugins/idviews.py | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/ipalib/plugins/idviews.py b/ipalib/plugins/idviews.py
index 57f0cce1549edb4e582df225f7831916d96c216b..a7b1e0a78e57fcd2864d258c7968393c359499f2 100644
--- a/ipalib/plugins/idviews.py
+++ b/ipalib/plugins/idviews.py
@@ -30,12 +30,14 @@ from ipalib.util import (normalize_sshpubkey, validate_sshpubkey,
 
 from ipapython.dn import DN
 
+_dcerpc_bindings_installed = False
+
 if api.env.in_server and api.env.context in ['lite', 'server']:
 try:
 import ipaserver.dcerpc
 _dcerpc_bindings_installed = True
 except ImportError:
-_dcerpc_bindings_installed = False
+pass
 
 __doc__ = _("""
 ID Views
-- 
2.1.0

>From 41f158cd2b18ee7007e5b1d9ee2e1e02e37512c5 Mon Sep 17 00:00:00 2001
From: Tomas Babej 
Date: Wed, 27 May 2015 15:06:15 +0200
Subject: [PATCH] idviews: Allow users specify the raw anchor directly as
 identifier

For various reasons, it can happen that the users or groups that
have overrides defined in a given ID view are no longer resolvable.

Since user and group names are used to specify the ID override objects
too by leveraging the respective user's or group's ipaUniqueID,
we need to provide a fallback in case these user or group entries
no longer exist.

https://fedorahosted.org/freeipa/ticket/5026
---
 ipalib/plugins/idviews.py | 42 +++---
 1 file changed, 31 insertions(+), 11 deletions(-)

diff --git a/ipalib/plugins/idviews.py b/ipalib/plugins/idviews.py
index a7b1e0a78e57fcd2864d258c7968393c359499f2..2c843462a859ae397ab1ef8e183f21dc1ac796a6 100644
--- a/ipalib/plugins/idviews.py
+++ b/ipalib/plugins/idviews.py
@@ -17,6 +17,7 @@
 #
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see .
+import re
 
 from ipalib.plugins.baseldap import (LDAPQuery, LDAPObject, LDAPCreate,
  LDAPDelete, LDAPUpdate, LDAPSearch,
@@ -57,6 +58,12 @@ protected_default_trust_view_error = errors.ProtectedEntryError(
 
 DEFAULT_TRUST_VIEW_NAME = "default trust view"
 
+ANCHOR_REGEX = re.compile(
+r':IPA:.*:[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}'
+r'|'
+r':SID:S-[0-9\-]+'
+)
+
 @register()
 class idview(LDAPObject):
 """
@@ -559,11 +566,19 @@ class baseidoverride(LDAPObject):
 override_object = None
 
 def get_dn(self, *keys, **options):
-anchor = resolve_object_to_anchor(
-self.backend,
-self.override_object,
-keys[-1]
-)
+# If user passed raw anchor, do not try
+# to translate it.
+if ANCHOR_REGEX.match(keys[-1]):
+anchor = keys[-1]
+
+# Otherwise, translate object into a
+# legitimate object anchor.
+else:
+anchor = resolve_object_to_anchor(
+self.backend,
+self.override_object,
+keys[-1]
+)
 
 keys = keys[:-1] + (anchor, )
 return super(baseidoverride, self).get_dn(*keys, **options)
@@ -578,12 +593,17 @@ class baseidoverride(LDAPObject):
 anchor = entry_attrs.single_value['ipaanchoruuid']
 
 if anchor:
-object_name = resolve_anchor_to_object_name(
-self.backend,
-self.override_object,
-anchor
-)
-entry_attrs.single_value['ipaanchoruuid'] = object_name
+try:
+object_name = resolve_anchor_to_object_name(
+self.backend,
+self.override_object,
+anchor
+)
+entry_attrs.single_value['ipaanchoruuid'] = object_name
+except errors.NotFound:
+# If we were unable to resolve the anchor,
+# keep it in the raw form
+pass
 
 def prohibit_ipa_users_in_default_view(self, dn, entry_attrs):
 # Check if parent object is Default Trust View, if so, prohibit
-- 
2.1.0

>From c4ad3ba829ab2816c6ddb64da8d5c6ceb8789340 Mon Sep 17 00:00:00 2001
From: Tomas Babej 
Date: Wed, 27 May 2015 16:30:48 +0200
Subject: [PATCH] idviews: Remove ID overrides for permanently removed users
 and groups

For IPA users and groups we are able to trigger a removal of
any relevant ID overrides in user-del and group-del c

Re: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates

[Fraser Tweedale]

Updated patch attached.  Notably restores/adds revocation behaviour
to host-mod and service-mod.

Thanks,
Fraser

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 :)
> 
> 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
> 
From 58d301e1c8e6efba68bf6459d51c24c640b67edd 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 and service-mod revoke existing certificates that are not
included in the modified entry.  Using addattr=certificate=... will
result in no certificates being revoked.

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
---
 API.txt   | 10 ++---
 ipalib/plugins/host.py| 96 ---
 ipalib/plugins/service.py | 83 
 3 files changed, 104 insertions(+), 85 deletions(-)

diff --git a/API.txt b/API.txt
index 
da69f32de5c12c0d85a7d61d9027385aa3c0ee05..3cfcf34939a58d6888de8f0a7a6ef0c7779c993e
 100644
--- a/API.txt
+++ b/API.txt
@@ -1812,7 +1812,7 @@ option: Str('nsosversion', attribute=True, cli_name='os', 
multivalue=False, requ
 option: Flag('random', attribute=False, autofill=True, cli_name='random', 
default=False, multivalue=False, required=False)
 option: Flag('raw', autofill=True, cli_name='raw', default=False, 
exclude='webui')
 option: Str('setattr*', cli_name='setattr', exclude='webui')
-option: Bytes('usercertificate', attribute=True, cli_name='certificate', 
multivalue=False, required=False)
+option: Bytes('usercertificate', attribute=True, cli_name='certificate', 
multivalue=True, required=False)
 option: Str('userclass', attribute=True, cli_name='class', multivalue=True, 
required=False)
 option: Str('userpassword', attribute=True, cli_name='password', 
multivalue=False, required=False)
 option: Str('version?', exclude='webui')
@@ -1935,7 +1935,7 @@ option: Flag('pkey_only?', autofill=True, default=False)
 option: Flag('raw', autofill=True, cli_name='raw', default=False, 
exclude='webui')
 option: Int('sizelimit?', autofill=False, minvalue=0)
 option: Int('timelimit?', autofill=False, minvalue=0)
-option: Bytes('usercertificate', attribute=True, autofill=False, 
cli_name='certificate', multivalue=False, query=True, required=False)
+option: Bytes('usercertificate', attribute=True, autofill=False, 
cli_name='certificate', multivalue=True, query=True, required=False)
 option: Str('userclass', attribute=True, autofill=False, cli_name='class', 
multivalue=True, query=True, required=False)
 option: Str('userpassword', attribute=True, autofill=False, 
cli_name='password', multivalue=False, query=True, required=False)
 option: Str('version?', exclude='webui')
@@ -1966,7 +1966,7 @@ option: Flag('raw', autofill=True, cli_name='raw', 
default=False, exclude='webui
 option: Flag('rights', autofill=True, default=False)
 option: Str('setattr*', cli_name='setattr', exclude='webui')
 option: Flag('updatedns?', autofill=True, d

Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)

[Martin Basti]

On 28/05/15 12:53, Christian Heimes wrote:

On 2015-05-28 12:46, Martin Kosek wrote:

I am fine with this too. So if there is not another major disagreement, let us
start with enabling KDCPROXY by default during upgrade/install, the new ACI and
the per-replica standard configuration.

API CLI/UI can come later (4.2.x or 4.3).

LGTM, too.

How should the new ACI work? I see two possible ways:

1) Allow compare/search for ipaConfigString=enabledService for everybody:

(targetfilter="(ipaConfigString=enabledService)")(targetattr="ipaConfigString")(version
3.0; acl "Compare enabledService access to masters"; allow(search,
compare) userdn = "ldap:///all";;)

2) Create a new permission, assign it to all HTTP principals and allow
read, compare and search for all ipaConfigString attributes.

For the second way I need somebody to walk me through the permission and
role system of FreeIPA.
3) Or we can create a new keytab for KDC proxy, and add permission only 
for this service




Christian






--
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] Kerberos over HTTPS (KDC proxy)

[Jan Cholasta]

Dne 28.5.2015 v 12:53 Christian Heimes napsal(a):

On 2015-05-28 12:46, Martin Kosek wrote:

I am fine with this too. So if there is not another major disagreement, let us
start with enabling KDCPROXY by default during upgrade/install, the new ACI and
the per-replica standard configuration.

API CLI/UI can come later (4.2.x or 4.3).


LGTM, too.

How should the new ACI work? I see two possible ways:

1) Allow compare/search for ipaConfigString=enabledService for everybody:

(targetfilter="(ipaConfigString=enabledService)")(targetattr="ipaConfigString")(version
3.0; acl "Compare enabledService access to masters"; allow(search,
compare) userdn = "ldap:///all";;)

2) Create a new permission, assign it to all HTTP principals and allow
read, compare and search for all ipaConfigString attributes.

For the second way I need somebody to walk me through the permission and
role system of FreeIPA.

Christian


So, will it be a separate component with its own freeipa-server-kdcproxy 
subpackage and installer or will it be a sub-component of KDC (as Martin 
suggested) and part of the core freeipa-server package?


--
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)

[Petr Spacek]

On 28.5.2015 12:53, Christian Heimes wrote:
> On 2015-05-28 12:46, Martin Kosek wrote:
>> I am fine with this too. So if there is not another major disagreement,
>> let us start with enabling KDCPROXY by default during upgrade/install,
>> the new ACI and the per-replica standard configuration.
>> 
>> API CLI/UI can come later (4.2.x or 4.3).
> 
> LGTM, too.
> 
> How should the new ACI work? I see two possible ways:
> 
> 1) Allow compare/search for ipaConfigString=enabledService for
> everybody:
> 
> (targetfilter="(ipaConfigString=enabledService)")(targetattr="ipaConfigString")(version
>
> 
3.0; acl "Compare enabledService access to masters"; allow(search,
> compare) userdn = "ldap:///all";;)
> 
> 2) Create a new permission, assign it to all HTTP principals and allow 
> read, compare and search for all ipaConfigString attributes.

I like option 2 - a new permission like "Read configuration of IPA services".

> For the second way I need somebody to walk me through the permission and 
> role system of FreeIPA.

Unfortunately I did not use the new system myself so I do not have
particular steps to share. Please see design pages here:
http://www.freeipa.org/page/V3/Permissions_V2
http://www.freeipa.org/page/V3/Permissions_V2/tests

... and contact Petr Viktorin . The new permission
system is his child :-)

I hope this helps.

-- 
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)

[Jan Cholasta]

Dne 28.5.2015 v 13:56 Christian Heimes napsal(a):

On 2015-05-28 13:30, Jan Cholasta wrote:

Dne 28.5.2015 v 12:53 Christian Heimes napsal(a):

On 2015-05-28 12:46, Martin Kosek wrote:

I am fine with this too. So if there is not another major
disagreement, let us
start with enabling KDCPROXY by default during upgrade/install, the
new ACI and
the per-replica standard configuration.

API CLI/UI can come later (4.2.x or 4.3).


LGTM, too.

How should the new ACI work? I see two possible ways:

1) Allow compare/search for ipaConfigString=enabledService for everybody:

(targetfilter="(ipaConfigString=enabledService)")(targetattr="ipaConfigString")(version

3.0; acl "Compare enabledService access to masters"; allow(search,
compare) userdn = "ldap:///all";;)

2) Create a new permission, assign it to all HTTP principals and allow
read, compare and search for all ipaConfigString attributes.

For the second way I need somebody to walk me through the permission and
role system of FreeIPA.

Christian


So, will it be a separate component with its own freeipa-server-kdcproxy
subpackage and installer or will it be a sub-component of KDC (as Martin
suggested) and part of the core freeipa-server package?


For now I'm in favor of a sub-component as part of the freeipa-server
package.


OK, then I'm fine with ipa-kdcproxy-manage, but instead of adding a new 
service entry for KDC proxy, you can just add a flag to the KDC service 
entry, like ipaConfigString=kdcProxyEnabled.


--
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)

[Christian Heimes]

On 2015-05-28 13:30, Jan Cholasta wrote:
> Dne 28.5.2015 v 12:53 Christian Heimes napsal(a):
>> On 2015-05-28 12:46, Martin Kosek wrote:
>>> I am fine with this too. So if there is not another major
>>> disagreement, let us
>>> start with enabling KDCPROXY by default during upgrade/install, the
>>> new ACI and
>>> the per-replica standard configuration.
>>>
>>> API CLI/UI can come later (4.2.x or 4.3).
>>
>> LGTM, too.
>>
>> How should the new ACI work? I see two possible ways:
>>
>> 1) Allow compare/search for ipaConfigString=enabledService for everybody:
>>
>> (targetfilter="(ipaConfigString=enabledService)")(targetattr="ipaConfigString")(version
>>
>> 3.0; acl "Compare enabledService access to masters"; allow(search,
>> compare) userdn = "ldap:///all";;)
>>
>> 2) Create a new permission, assign it to all HTTP principals and allow
>> read, compare and search for all ipaConfigString attributes.
>>
>> For the second way I need somebody to walk me through the permission and
>> role system of FreeIPA.
>>
>> Christian
> 
> So, will it be a separate component with its own freeipa-server-kdcproxy
> subpackage and installer or will it be a sub-component of KDC (as Martin
> suggested) and part of the core freeipa-server package?

For now I'm in favor of a sub-component as part of the freeipa-server
package.

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)

[Christian Heimes]

On 2015-05-28 13:29, Martin Basti wrote:
> On 28/05/15 12:53, Christian Heimes wrote:
>> On 2015-05-28 12:46, Martin Kosek wrote:
>>> I am fine with this too. So if there is not another major disagreement, let 
>>> us
>>> start with enabling KDCPROXY by default during upgrade/install, the new ACI 
>>> and
>>> the per-replica standard configuration.
>>>
>>> API CLI/UI can come later (4.2.x or 4.3).
>> LGTM, too.
>>
>> How should the new ACI work? I see two possible ways:
>>
>> 1) Allow compare/search for ipaConfigString=enabledService for everybody:
>>
>> (targetfilter="(ipaConfigString=enabledService)")(targetattr="ipaConfigString")(version
>> 3.0; acl "Compare enabledService access to masters"; allow(search,
>> compare) userdn = "ldap:///all";;)
>>
>> 2) Create a new permission, assign it to all HTTP principals and allow
>> read, compare and search for all ipaConfigString attributes.
>>
>> For the second way I need somebody to walk me through the permission and
>> role system of FreeIPA.
>
> 3) Or we can create a new keytab for KDC proxy, and add permission only
> for this service

The new keytab must be readable by the Apache process.Therefore a new
keytab doesn't give us extra security. It separates the kdcproxy service
from the IPA webgui. Is that your goal?

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)

[Martin Basti]

On 28/05/15 14:06, Christian Heimes wrote:

On 2015-05-28 13:29, Martin Basti wrote:

On 28/05/15 12:53, Christian Heimes wrote:

On 2015-05-28 12:46, Martin Kosek wrote:

I am fine with this too. So if there is not another major disagreement, let us
start with enabling KDCPROXY by default during upgrade/install, the new ACI and
the per-replica standard configuration.

API CLI/UI can come later (4.2.x or 4.3).

LGTM, too.

How should the new ACI work? I see two possible ways:

1) Allow compare/search for ipaConfigString=enabledService for everybody:

(targetfilter="(ipaConfigString=enabledService)")(targetattr="ipaConfigString")(version
3.0; acl "Compare enabledService access to masters"; allow(search,
compare) userdn = "ldap:///all";;)

2) Create a new permission, assign it to all HTTP principals and allow
read, compare and search for all ipaConfigString attributes.

For the second way I need somebody to walk me through the permission and
role system of FreeIPA.

3) Or we can create a new keytab for KDC proxy, and add permission only
for this service

The new keytab must be readable by the Apache process.Therefore a new
keytab doesn't give us extra security. It separates the kdcproxy service
from the IPA webgui. Is that your goal?

Christian


OK, then nevermind :-)

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] Domain level for topology plugin = 2

[Petr Spacek]

On 28.5.2015 10:49, Martin Kosek wrote:
> On 05/28/2015 09:05 AM, Petr Spacek wrote:
>> On 28.5.2015 08:55, Jan Cholasta wrote:
>>> 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?
>>
>> Good point!
>>
> 
> It may be a good point, but it does not make the situation easier. You still
> have RHEL/CentOS 6.x IPA out there, where some of them already support the new
> DNS forwarders and some don't - and neither of them support Domain Levels -
> i.e. have Domain Level 0.
> 
> As I said, I still see more complications with this proposals than benefits...

I would argue that it actually helps.

If domain level = 1 then we can be *sure* that all replicas support the new
DNS semantics.

If domain level = 0 then we know nothing (because of patched RHEL 6) and it is
a warning sign for diagnostic tools and also us when it comes to debugging.

-- 
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] [PATCH 0014] Support multiple user and host certificates

[Petr Spacek]

On 28.5.2015 12:06, Fraser Tweedale wrote:
> On Thu, May 28, 2015 at 11:52:25AM +0200, Martin Kosek wrote:
>> On 05/28/2015 11:17 AM, Martin Basti wrote:
>>> On 28/05/15 10:46, Martin Kosek wrote:
 On 05/27/2015 06:12 PM, 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 :)
>
> 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.
 Good question. I think the suggestion was to have a global switch in IPA 
 global
 config that would configure the policy - whether the certificates removed 
 by
 this command or by host-del or host-disable are revoked or if they are just
 removed (my motivation is to avoid behavior regression in case somebody
 depended on this behavior).
>>> I would prefer to keep the current behavior: revoke the certificate if it 
>>> was
>>> replaced or removed, instead of adding an extra configuration option.
>>> This behavior is not regression.
>>
>> It is not. However, it is not an ideal behavior also. In FreeIPA 4.2, we are
>> now adding support of certificate profiles, multiple certificates and even
>> certificates for user.
>>
>> With that change, there may be much more certificates in play than now. If we
>> keep revoking all such certificates, it may cause rapid growth of CRLs. This 
>> is
>> something I am trying to avoid with this proposal and default to not revoking
>> certificates automatically (which mostly only makes sense if there is a risk
>> that the key is compromised), but have some option to keep the old behavior.
>>
>> Does this make sense?

I would like to see some data to support the decision not to revoke certs by
default. Are there some facts to base the decision on? Or just hand-wavy
reasoning?

Sure, huge CRL may be bad, but not revoking certs may be even worse. E.g. when
older backup files are stolen (in the information sense, i.e. copied without
anyone noticing it) - attacker might get valid certs despite the fact that the
old cert is never used (because it was rotated right after the backup).

IMHO this behavior should be configurable and default to 'revoke'. We should
ship FreeIPA with secure defaults and let users to lower the standards if they
wish/need.

Petr^2 Spacek

> It does make senes.
> 
> In regards to *this* patch, I will make -mod behave the same as -del
> and -disable; i.e. the current behaviour i.e. revoke whenever we
> "forget" a certificate.
> 
> Any config knobs, command options, etc to govern whether to revoke
> shall be added in a subsequent patch.

-- 
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] [PATCHES 0001-0013 v5] Profiles and CA ACLs

[Martin Basti]

On 28/05/15 11:48, Martin Basti wrote:

On 27/05/15 16:04, Fraser Tweedale wrote:

Hello all,

Fresh certificate management patchset; Changelog:

- Now depends on patch freeipa-ftweedal-0014 for correct
   cert-request behaviour with host and service principals.

- Updated Dogtag dependency to 10.2.4-1.  Should should be in f22
   soon, but for f22 right now or for f21, please grab from my copr:
   https://copr.fedoraproject.org/coprs/ftweedal/freeipa/

   Martin^1 could you please add to the quasi-official freeipa copr?
   SRPM lives at https://frase.id.au/pki-core-10.2.4-1.fc21.src.rpm.

- cert-request now verifies that for user principals, CSR CN matches
   uid and, DN emailAddress and SAN rfc822Name match user's email
   address, if either of those is present.

- Fixed one or two other sneaky little bugs.

On Wed, May 27, 2015 at 01:59:30AM +1000, Fraser Tweedale wrote:

Hi all,

Please find attached the latest certificate management patchset,
which introduces the `caacl' plugin and various fixes and
improvement to earlier patches.

One important change to earlier patches is reverting the name of the
default profile to 'caIPAserviceCert' and using the existing
instance of this profile on upgrade (but not install) in case it has
been modified.

Other notes:

- Still have changes in ipa-server-install (fewer lines now, though)

- Still have the ugly import hack.  It is not a high priority for
   me, i.e. I think it should wait until after alpha

- Still need to update 'service' and 'host' plugins to support
   multiple certificates.  (The userCertificate attribute schema
   itself is multi-valued, so there are no schema issues here)

- The TODOs in [1]; mostly certprofile CLI conveniences and
   supporting multiple profiles for hosts and services (which
   requires changes to framework only, not schema).
   [1]: http://idm.etherpad.corp.redhat.com/rhel72-cert-mgmt-progress

Happy reviewing!  I am pleased with the initial cut of the caacl
plugin but I'm sure you will find some things to be fixed :)

Cheers,
Fraser


[root@vm-093 ~]#  ipa-replica-prepare vm-094.example.com --ip-address 
10.34.78.94

Directory Manager (existing master) password:

Preparing replica for vm-094.example.com from vm-093.example.com
Creating SSL certificate for the Directory Server
not well-formed (invalid token): line 2, column 14

I cannot create replica file.
It work on the upgraded server, but it doesn't work on the newly 
installed server.
I'm not sure if this causes your patches which modifies the 
ca-installer, or the newer version of dogtag.


Or if there was any other changes in master, I will continue to 
investigate with new RPM from master branch.


Martin^2


ipa-replica-prepare works for:
* master branch
* master branch + pki-ca 10.2.4-1

So something in your patches is breaking it

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

[Freeipa-devel] [PATCH 0039] ipa-kdb: common function to get key encodings/salt types

[Martin Babinsky]

A small improvement upon simo's fix for 
https://fedorahosted.org/freeipa/ticket/4914


--
Martin^3 Babinsky
From 51f8bcd716fbddf5913cd79ba574a396e0956f0d Mon Sep 17 00:00:00 2001
From: Martin Babinsky 
Date: Fri, 22 May 2015 17:23:00 +0200
Subject: [PATCH] ipa-kdb: common function to get key encodings/salt types


This patch moves duplicate code in `ipadb_get_connection` to get default and
supported key encodings/salt types from Kerberos container to a common
function handling this task.

It is actually a small cosmetic enhancement of the fix of
https://fedorahosted.org/freeipa/ticket/4914
---
 daemons/ipa-kdb/ipa_kdb.c | 131 +-
 daemons/ipa-kdb/ipa_kdb.h |   3 ++
 2 files changed, 63 insertions(+), 71 deletions(-)

diff --git a/daemons/ipa-kdb/ipa_kdb.c b/daemons/ipa-kdb/ipa_kdb.c
index fff35c9c9b4cf0a1c7fd9a4e13d1029aa01160c3..3d5e1568020b97fc089f9b59fb6625fccebf3a51 100644
--- a/daemons/ipa-kdb/ipa_kdb.c
+++ b/daemons/ipa-kdb/ipa_kdb.c
@@ -317,19 +317,68 @@ ipadb_get_global_config(struct ipadb_context *ipactx)
 return &ipactx->config;
 }
 
-int ipadb_get_connection(struct ipadb_context *ipactx)
+int ipadb_get_enc_salt_types(struct ipadb_context *ipactx,
+ LDAPMessage *entry, char *attr,
+ krb5_key_salt_tuple **enc_salt_types,
+ int *n_enc_salt_types)
 {
 struct berval **vals = NULL;
-struct timeval tv = { 5, 0 };
-LDAPMessage *res = NULL;
-LDAPMessage *first;
+char **cvals = NULL;
+int c = 0;
+int i;
+int ret = 0;
 krb5_key_salt_tuple *kst;
 int n_kst;
+
+vals = ldap_get_values_len(ipactx->lcontext, entry, attr);
+if (!vals || !vals[0]) {
+goto done;
+}
+
+for (c = 0; vals[c]; c++) /* count */ ;
+cvals = calloc(c, sizeof(char *));
+if (!cvals) {
+ret = ENOMEM;
+goto done;
+}
+for (i = 0; i < c; i++) {
+cvals[i] = strndup(vals[i]->bv_val, vals[i]->bv_len);
+if (!cvals[i]) {
+ret = ENOMEM;
+goto done;
+}
+}
+
+ret = parse_bval_key_salt_tuples(ipactx->kcontext,
+ (const char * const *)cvals, c,
+ &kst, &n_kst);
+if (ret) {
+goto done;
+}
+
+if (*enc_salt_types) {
+free(*enc_salt_types);
+}
+
+*enc_salt_types = kst;
+*n_enc_salt_types = n_kst;
+
+done:
+ldap_value_free_len(vals);
+for (i = 0; i < c && cvals[i]; i++) {
+free(cvals[i]);
+}
+free(cvals);
+return ret;
+}
+
+int ipadb_get_connection(struct ipadb_context *ipactx)
+{
+struct timeval tv = { 5, 0 };
+LDAPMessage *res = NULL;
+LDAPMessage *first;
 int ret;
 int v3;
-int i;
-char **cvals = NULL;
-int c = 0;
 
 if (!ipactx->uri) {
 return EINVAL;
@@ -386,74 +435,20 @@ int ipadb_get_connection(struct ipadb_context *ipactx)
 
 /* defaults first, this is used to tell what default enc:salts to use
  * for kadmin password changes */
-vals = ldap_get_values_len(ipactx->lcontext, first,
-   "krbDefaultEncSaltTypes");
-if (!vals || !vals[0]) {
-goto done;
-}
-
-for (c = 0; vals[c]; c++) /* count */ ;
-cvals = calloc(c, sizeof(char *));
-if (!cvals) {
-ret = ENOMEM;
-goto done;
-}
-for (i = 0; i < c; i++) {
-cvals[i] = strndup(vals[i]->bv_val, vals[i]->bv_len);
-if (!cvals[i]) {
-ret = ENOMEM;
-goto done;
-}
-}
-
-ret = parse_bval_key_salt_tuples(ipactx->kcontext,
- (const char * const *)cvals, c,
- &kst, &n_kst);
+ret = ipadb_get_enc_salt_types(ipactx, first,  "krbDefaultEncSaltTypes",
+   &ipactx->def_encs, &ipactx->n_def_encs);
 if (ret) {
 goto done;
 }
 
-if (ipactx->def_encs) {
-free(ipactx->def_encs);
-}
-ipactx->def_encs = kst;
-ipactx->n_def_encs = n_kst;
-
 /* supported enc salt types, use to tell kadmin what to accept
  * but also to detect if kadmin is requesting the default set */
-vals = ldap_get_values_len(ipactx->lcontext, first,
-   "krbSupportedEncSaltTypes");
-if (!vals || !vals[0]) {
-goto done;
-}
-
-for (c = 0; vals[c]; c++) /* count */ ;
-cvals = calloc(c, sizeof(char *));
-if (!cvals) {
-ret = ENOMEM;
-goto done;
-}
-for (i = 0; i < c; i++) {
-cvals[i] = strndup(vals[i]->bv_val, vals[i]->bv_len);
-if (!cvals[i]) {
-ret = ENOMEM;
-goto done;
-}
-}
-
-ret = parse_bval_key_salt_tuples(ipactx->kcontext,
- (const char * const *)cvals, c,
- &kst, &n_kst);
+ret = ipadb_get_e

Re: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates

[Martin Basti]

On 28/05/15 14:29, Petr Spacek wrote:

On 28.5.2015 12:06, Fraser Tweedale wrote:

On Thu, May 28, 2015 at 11:52:25AM +0200, Martin Kosek wrote:

On 05/28/2015 11:17 AM, Martin Basti wrote:

On 28/05/15 10:46, Martin Kosek wrote:

On 05/27/2015 06:12 PM, 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 :)

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.

Good question. I think the suggestion was to have a global switch in IPA global
config that would configure the policy - whether the certificates removed by
this command or by host-del or host-disable are revoked or if they are just
removed (my motivation is to avoid behavior regression in case somebody
depended on this behavior).

I would prefer to keep the current behavior: revoke the certificate if it was
replaced or removed, instead of adding an extra configuration option.
This behavior is not regression.

It is not. However, it is not an ideal behavior also. In FreeIPA 4.2, we are
now adding support of certificate profiles, multiple certificates and even
certificates for user.

With that change, there may be much more certificates in play than now. If we
keep revoking all such certificates, it may cause rapid growth of CRLs. This is
something I am trying to avoid with this proposal and default to not revoking
certificates automatically (which mostly only makes sense if there is a risk
that the key is compromised), but have some option to keep the old behavior.

Does this make sense?

I would like to see some data to support the decision not to revoke certs by
default. Are there some facts to base the decision on? Or just hand-wavy
reasoning?

Sure, huge CRL may be bad, but not revoking certs may be even worse. E.g. when
older backup files are stolen (in the information sense, i.e. copied without
anyone noticing it) - attacker might get valid certs despite the fact that the
old cert is never used (because it was rotated right after the backup).

IMHO this behavior should be configurable and default to 'revoke'. We should
ship FreeIPA with secure defaults and let users to lower the standards if they
wish/need.

Petr^2 Spacek

+1

would be enought to have just option in the command --revoke-cert=true, 
with true as default, instead of global configuration?

Martin^2



It does make senes.

In regards to *this* patch, I will make -mod behave the same as -del
and -disable; i.e. the current behaviour i.e. revoke whenever we
"forget" a certificate.

Any config knobs, command options, etc to govern whether to revoke
shall be added in a subsequent patch.



--
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 0039] ipa-kdb: common function to get key encodings/salt types

[Simo Sorce]

On Thu, 2015-05-28 at 14:43 +0200, Martin Babinsky wrote:
> A small improvement upon simo's fix for 
> https://fedorahosted.org/freeipa/ticket/4914
> 
> --
> Martin^3 Babinsky

LGTM.

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] Kerberos over HTTPS (KDC proxy)

[Simo Sorce]

On Thu, 2015-05-28 at 07:42 +0200, Jan Cholasta wrote:
> 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.

Well, this is the problem, I guess there is a perception issue. The KDC
Proxy is basically nothing more than adding a new protocol to the KDC.
It doesn't really do anything special but getting packets on HTTPS and
sending them to the KDC over TCP.
SO I think that for this specific case the KDC Proxy really is
comparable to migration mode (actually simpler than migration).

> > 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.

If the migration plugin is installed the service is provided, if it is
not installed it is not provided, it is conceptually the same. Yes there
is code involved, but we plan to have the proxy always provided. There
is no plan to have it as a removable component, you can only enable or
disable it, like for migration.

>  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.)

It is completely different in size and scope, the KDCProxy really is
just an enabler to reach the KDC over a different protocol, it is not a
whole new protocol and service.

In the end it is a matter of perspective, I think most of the people
that have been dealing with it think it is much like migration and not
an entire new service like DNS.

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] Domain level for topology plugin = 2

[Simo Sorce]

On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote:
> On 28.5.2015 10:49, Martin Kosek wrote:
> > On 05/28/2015 09:05 AM, Petr Spacek wrote:
> >> On 28.5.2015 08:55, Jan Cholasta wrote:
> >>> 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?
> >>
> >> Good point!
> >>
> > 
> > It may be a good point, but it does not make the situation easier. You still
> > have RHEL/CentOS 6.x IPA out there, where some of them already support the 
> > new
> > DNS forwarders and some don't - and neither of them support Domain Levels -
> > i.e. have Domain Level 0.
> > 
> > As I said, I still see more complications with this proposals than 
> > benefits...
> 
> I would argue that it actually helps.
> 
> If domain level = 1 then we can be *sure* that all replicas support the new
> DNS semantics.
> 
> If domain level = 0 then we know nothing (because of patched RHEL 6) and it is
> a warning sign for diagnostic tools and also us when it comes to debugging.

First of all  a domain level is something we change *RARELY*, and it is
a whole number and it is an all or nothing thing.

I do not understand why plugin versions matter at all, plugin version
have nothing to do with domain levels. Each plugin *whatever* the
version MUST always support at least 2 levels, because every domain you
have will have to go through a domain_level transition when a new domain
level comes out.

Finally no single developer should be allowed to decide on  anew domain
level, this must be a well ponder team decision as all plugins that need
to change behavior based on domain level will be affected so a thorough
review of what changes are needed across all plugins must be done every
time someone propose a change that requires a domain level bump.

Last but not least we should consider domain levels as something that
changes *very* slowly, because otherwise you'll have to support many
domain levels within any plugins that have to change behavior according
to the domain level.
I would say that the domain level should not change more frequently than
once a year or so. It would be too much code churn to do otherwise.

So for now domain_level should be set to 0. And the topology plugin will
be enabled only when we turn it to 1. However we shouldn't turn it to 1
until we have the replica promotion code at least, because only then we
can make full use of the topology plugins.

The DNS mess is unfixable, unless Petr you volunteer to backport code to
change the behavior 

Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)

[Martin Kosek]

On 05/28/2015 03:06 PM, Simo Sorce wrote:
> On Thu, 2015-05-28 at 07:42 +0200, Jan Cholasta wrote:
>> 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.
> 
> Well, this is the problem, I guess there is a perception issue. The KDC
> Proxy is basically nothing more than adding a new protocol to the KDC.
> It doesn't really do anything special but getting packets on HTTPS and
> sending them to the KDC over TCP.
> SO I think that for this specific case the KDC Proxy really is
> comparable to migration mode (actually simpler than migration).
> 
>>> 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.
> 
> If the migration plugin is installed the service is provided, if it is
> not installed it is not provided, it is conceptually the same. Yes there
> is code involved, but we plan to have the proxy always provided. There
> is no plan to have it as a removable component, you can only enable or
> disable it, like for migration.
> 
>>  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.)
> 
> It is completely different in size and scope, the KDCProxy really is
> just an enabler to reach the KDC over a different protocol, it is not a
> whole new protocol and service.
> 
> In the end it is a matter of perspective, I think most of the people
> that have been dealing with it think it is much like migration and not
> an entire new service like DNS.

In the end, Alexander had a good point that there will be some needed
associated configuration changes in DNS, when the KdcProxy is enabled/disabled:

http://www.redhat.com/archives/freeipa-devel/2015-May/msg00522.html

In which case, we may want to end up with more complicated API/CLI
(ipa-kdcproxy-manage) than just config-mod command. We now mostly settled to
per replica configuration, postponing powerful API/CLI for later:

http://www.redhat.com/archives/freeipa-devel/2015-May/msg00535.html

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] Kerberos over HTTPS (KDC proxy)

[Simo Sorce]

On Thu, 2015-05-28 at 12:14 +0300, Alexander Bokovoy wrote:
> On Thu, 28 May 2015, Martin Kosek wrote:
> >On 05/28/2015 10:02 AM, Jan Cholasta wrote:
> >> Dne 28.5.2015 v 09:45 Christian Heimes napsal(a):
> >>> On 2015-05-28 07:32, Jan Cholasta wrote:
>  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?
> >>>
> >>> The python-kdcproxy package is a new dependency for the freeipa-server
> >>> package. It will always get installed with the server.
> >>
> >> Why? None of the IPA core functionality depends on it, so it should be
> >> optional. Also the overall trend in IPA is to have everything in 
> >> subpackages.
> >
> >Do not look at it as a separate component. It is mostly just a new transport
> >for Kerberos. FreeIPA already provides Kerberos via TCP and UDP. This is a
> >third transport - HTTP.
> See my other response. With changes in 
> https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-00
> we'll need to manage _kerberos.$DOMAIN URI DNS record (not just TXT one
> like now) to explicitly report where the proxies are located. This goes
> beyond just global switch in LDAP and requires ipa-kdcproxy-manage tool.

Not really, we'll use the enable/disable switch to find out which DNS
records to publish, like we do for SRV records now, not special tool is
needed for now.

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)

[Simo Sorce]

On Thu, 2015-05-28 at 12:10 +0200, Petr Spacek wrote:
> On 28.5.2015 11:59, Martin Kosek wrote:
> > On 05/28/2015 11:12 AM, Alexander Bokovoy wrote:
> >> On Thu, 28 May 2015, Petr Spacek wrote:
> >>> On 28.5.2015 07:42, Jan Cholasta wrote:
>  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.)
> >>>
> >>> I very much agree with Honza - we have per-replica boolean for every 
> >>> service
> >>> so there is no reason not to have one for kdc proxy, especially when we
> >>> consider future containerization of services.
> >> A mere 'me too' here. Note that once updates to RFC 4120 as outlined in
> >> https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery-00
> >> would be accepted, clients will not be assuming all of replicas serve
> >> MS-KKDCP proxies so there will not be need to run them everywhere.
> >> Rather, only the servers on a network boundary will need to be
> >> advertised. This means we'll eventually get per-replica need as well.
> >>
> >> It is fine to assume right now that all of them are going to run
> >> MS-KKDCP proxy but configuration isn't really going to be global.
> >>
> >> Additionally, ipa-kdcproxy-manage would need to manipulate
> >> _kerberos.$DOMAIN URI DNS records too, so there is more than just
> >> switching the boolean here.
> > 
> > I see. My question is - if we go this way, what is then the reasonable 
> > subset
> > configuration functionality realistic for FreeIPA 4.2 GA? (As we want this
> > feature in for 4.2). Is ipa-kdcproxy-manage doable?
> > 
> > What is the proposed API here?
> > 
> > ipa-kdcproxy-manage list
> > ipa-kdcproxy-manage enable 
> > ipa-kdcproxy-manage disable 
> 
> I believe that for 4.2 it is perfectly enough to have per-replica switch in
> LDAP (enabled by default) and to provide ldapmodify command in docs. User
> interface can be polished later if we get the design right.

For 4.2 is actually perfectly fine to have a global switch.

If someone wants to pick and choose they can disable the embedded proxy
and explicitly install one where they want.
Let's not complicate simple things please.

Later on, if we want, it will be simple enough to add per replica
switches which will be checked only if the proxy is globally enabled
with the current switch.

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] [PATCH 429] replica-install: Allow install on top of already configured client

[Jan Cholasta]

Dne 26.5.2015 v 17:49 Jan Cholasta napsal(a):

Dne 20.5.2015 v 17:27 Jan Cholasta napsal(a):

Hi,

the attached patch implements the initial bits for
.

Test by running ipa-client-install and then ipa-replica-install on the
same host.


Updated patch attached.


Another update, patch attached.

--
Jan Cholasta
>From 2699db4a40657cc5bbf57eca87a5e1b3dae4209c Mon Sep 17 00:00:00 2001
From: Jan Cholasta 
Date: Wed, 20 May 2015 15:20:31 +
Subject: [PATCH] replica-install: Allow install on top of already configured
 client

https://fedorahosted.org/freeipa/ticket/2888
---
 install/tools/ipa-replica-install | 187 --
 ipaserver/install/krbinstance.py  |   6 +-
 2 files changed, 142 insertions(+), 51 deletions(-)

diff --git a/install/tools/ipa-replica-install b/install/tools/ipa-replica-install
index 1df782b..d23a462 100755
--- a/install/tools/ipa-replica-install
+++ b/install/tools/ipa-replica-install
@@ -24,10 +24,12 @@ import socket
 import os, pwd, shutil
 from optparse import OptionGroup
 from contextlib import contextmanager
+from ConfigParser import RawConfigParser
 
 import dns.resolver
 import dns.reversename
 import dns.exception
+import SSSDConfig
 
 from ipapython import ipautil
 
@@ -151,6 +153,24 @@ def parse_options():
 elif options.reverse_zones and options.no_reverse:
 parser.error("You cannot specify a --reverse-zone option together with --no-reverse")
 
+client_fstore = sysrestore.FileStore(paths.IPA_CLIENT_SYSRESTORE)
+if client_fstore.has_files():
+if options.mkhomedir:
+parser.error("You cannot specify a --mkhomedir option "
+ "when IPA client is already configured")
+if options.trust_sshfp:
+parser.error("You cannot specify a --ssh-trust-dns option "
+ "when IPA client is already configured")
+if not options.conf_ssh:
+parser.error("You cannot specify a --no-ssh option "
+ "when IPA client is already configured")
+if not options.conf_sshd:
+parser.error("You cannot specify a --no-sshd option "
+ "when IPA client is already configured")
+if not options.create_sshfp:
+parser.error("You cannot specify a --no-dns-sshfp option "
+ "when IPA client is already configured")
+
 options.zonemgr = None
 options.dnssec_master = False
 
@@ -204,7 +224,7 @@ def install_replica_ds(config):
 
 return ds
 
-def install_krb(config, setup_pkinit=False):
+def install_krb(config, setup_pkinit=False, client_configured=False):
 krb = krbinstance.KrbInstance()
 
 #pkinit files
@@ -214,7 +234,7 @@ def install_krb(config, setup_pkinit=False):
 krb.create_replica(config.realm_name,
config.master_host_name, config.host_name,
config.domain_name, config.dirman_password,
-   setup_pkinit, pkcs12_info)
+   setup_pkinit, pkcs12_info, None, client_configured)
 
 return krb
 
@@ -418,11 +438,40 @@ def main():
 if not ipautil.file_exists(filename):
 sys.exit("Replica file %s does not exist" % filename)
 
+if installutils.is_ipa_configured():
+sys.exit("IPA server is already configured on this system.\n"
+ "If you want to reinstall the IPA server, please uninstall "
+ "it first using 'ipa-server-install --uninstall'.")
+
 client_fstore = sysrestore.FileStore(paths.IPA_CLIENT_SYSRESTORE)
-if client_fstore.has_files():
-sys.exit("IPA client is already configured on this system.\n" +
-"Please uninstall it first before configuring the replica, " +
-"using 'ipa-client-install --uninstall'.")
+client_configured = client_fstore.has_files()
+if client_configured:
+try:
+sssdconfig = SSSDConfig.SSSDConfig()
+sssdconfig.import_config()
+
+domains = sssdconfig.list_active_domains()
+for name in domains:
+domain = sssdconfig.get_domain(name)
+try:
+provider = domain.get_option('id_provider')
+except SSSDConfig.NoOptionError:
+continue
+if provider == 'ipa':
+break
+else:
+raise RuntimeError("IPA domain not configured in SSSD")
+
+if not services.service('sssd').is_enabled():
+raise RuntimeError("SSSD is not enabled")
+
+if not services.service('sssd').is_running():
+raise RuntimeError("SSSD is not running")
+except Exception as e:
+root_logger.error("%s", e)
+sys.exit("SSSD is not configured for IPA client on this system.\n"
+ "Please uninstall IPA client using 'ipa-client-install "
+ 

Re: [Freeipa-devel] Kerberos over HTTPS (KDC proxy)

[Christian Heimes]

On 2015-05-28 15:28, Martin Kosek wrote:
> In the end, Alexander had a good point that there will be some needed
> associated configuration changes in DNS, when the KdcProxy is 
> enabled/disabled:
> 
> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00522.html
> 
> In which case, we may want to end up with more complicated API/CLI
> (ipa-kdcproxy-manage) than just config-mod command. We now mostly settled to
> per replica configuration, postponing powerful API/CLI for later:
> 
> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00535.html

Thanks Martin,

Rob gave me some feedback on IRC, too. I'm going to sum up the decisions
and my plans for ACI/permission in a new thread.

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] Sudorules user validation help

[Drew Erny]

OK, I see now what you mean by that. That is a simpler solution. I'll do 
it that way.


On 05/28/2015 04:44 AM, Martin Kosek wrote:

On 05/27/2015 08:41 PM, Drew Erny wrote:

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?

I think it would make sense to follow the example with validate_hostname and
prepare a function validate_username(username, upn=False, netbios_name=False) 
[1].

where upn would allow using "@." on top of current validator (i.e.
u...@domain.test) and netbios_name would allow the "DOMAIN\user" style. I would
just suggest making sure the standard user validation error message is still
the same to avoid unnecessary QE fail positives.

In add_external_pre_callback you could then just simply call

validate_username(user, True, True)

just like it is already done with hostname.

My 2 cents.

Martin

[1] 
https://msdn.microsoft.com/en-us/library/windows/desktop/aa380525(v=vs.85).aspx


--
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

[Martin Kosek]

On 05/28/2015 02:29 PM, Petr Spacek wrote:
> On 28.5.2015 12:06, Fraser Tweedale wrote:
>> On Thu, May 28, 2015 at 11:52:25AM +0200, Martin Kosek wrote:
>>> On 05/28/2015 11:17 AM, Martin Basti wrote:
 On 28/05/15 10:46, Martin Kosek wrote:
> On 05/27/2015 06:12 PM, 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 :)
>>
>> 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.
> Good question. I think the suggestion was to have a global switch in IPA 
> global
> config that would configure the policy - whether the certificates removed 
> by
> this command or by host-del or host-disable are revoked or if they are 
> just
> removed (my motivation is to avoid behavior regression in case somebody
> depended on this behavior).
 I would prefer to keep the current behavior: revoke the certificate if it 
 was
 replaced or removed, instead of adding an extra configuration option.
 This behavior is not regression.
>>>
>>> It is not. However, it is not an ideal behavior also. In FreeIPA 4.2, we are
>>> now adding support of certificate profiles, multiple certificates and even
>>> certificates for user.
>>>
>>> With that change, there may be much more certificates in play than now. If 
>>> we
>>> keep revoking all such certificates, it may cause rapid growth of CRLs. 
>>> This is
>>> something I am trying to avoid with this proposal and default to not 
>>> revoking
>>> certificates automatically (which mostly only makes sense if there is a risk
>>> that the key is compromised), but have some option to keep the old behavior.
>>>
>>> Does this make sense?
> 
> I would like to see some data to support the decision not to revoke certs by
> default. Are there some facts to base the decision on? Or just hand-wavy
> reasoning?

What facts would you like to hear? If we are speaking from bugs, we already
know that large CRL lists caused lot of grief to deployments with bug
host/service turnaround. I do not have more data than this, besides my
expectation that there may be much more certificates tracked by FreeIPA than in
the past and we need to deal with it.

> Sure, huge CRL may be bad, but not revoking certs may be even worse. E.g. when
> older backup files are stolen (in the information sense, i.e. copied without
> anyone noticing it) - attacker might get valid certs despite the fact that the
> old cert is never used (because it was rotated right after the backup).

I am not convinced that this is a valid point. We cannot assume that FreeIPA
administrator leaks certificate keys and try to magically fix that by this
policy. Such fault backup can leak even when the host/service still exists.

This is about what makes most sense for certificate handling, what is the
secure behavior and a behavior that most administrators would expect (thus the
default). Are you sure revoking all deleted certificates is the expected
behavior? In my mind, certificates are being revoked from more serious reasons
- when employee "leaves" a company, machine (or it's backup) is compromised,
etc. But in that case admin would use cert-revoke command

Re: [Freeipa-devel] New replica installation and topology - we need stable base

[Martin Kosek]

On 05/27/2015 04:59 PM, Martin Kosek wrote:
...
> Domain Levels
> - Done, committed
> - Defaults to Level 1, i.e. Topology plugin powered infra enabled

With respect to related Simo's response in
http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html

Would we want to enable Topology (i.e. Domain Level 1) even if Replica
promotion is not done? I thought we do as I see those as orthogonal features.
Replica promotion would take advantage of the Topology plugin, but it does not
mean you cannot benefit from Topology plugin without it.

You can still use the API to see/manage the topology and set replication
settings with it. You do not need Replica Promotion for that...

-- 
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

[Ludwig Krispenz]

On 05/28/2015 03:26 PM, Simo Sorce wrote:

On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote:

On 28.5.2015 10:49, Martin Kosek wrote:

On 05/28/2015 09:05 AM, Petr Spacek wrote:

On 28.5.2015 08:55, Jan Cholasta wrote:

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?

Good point!


It may be a good point, but it does not make the situation easier. You still
have RHEL/CentOS 6.x IPA out there, where some of them already support the new
DNS forwarders and some don't - and neither of them support Domain Levels -
i.e. have Domain Level 0.

As I said, I still see more complications with this proposals than benefits...

I would argue that it actually helps.

If domain level = 1 then we can be *sure* that all replicas support the new
DNS semantics.

If domain level = 0 then we know nothing (because of patched RHEL 6) and it is
a warning sign for diagnostic tools and also us when it comes to debugging.

First of all  a domain level is something we change *RARELY*, and it is
a whole number and it is an all or nothing thing.

I do not understand why plugin versions matter at all, plugin version
have nothing to do with domain levels. Each plugin *whatever* the
version MUST always support at least 2 levels, because every domain you
have will have to go through a domain_level transition when a new domain
level comes out.

Finally no single developer should be allowed to decide on  anew domain
level, this must be a well ponder team decision as all plugins that need
to change behavior based on domain level will be affected so a thorough
review of what changes are needed across all plugins must be done every
time someone propose a change that requires a domain level bump.

Last but not least we should consider domain levels as something that
changes *very* slowly, because otherwise you'll have to support many
domain levels within any plugins that have to change behavior according
to the domain level.
I would say that the domain level should not change more frequently than
once a year or so. It would be too much code churn to do otherwise.

So for now domain_level should be set to 0. And the topology plugin will
be enabled only when we turn it to 1. However we shouldn't turn it to 1
until we have the replica promotion code at least, because only then we
can make full use of the topology plugins.

The DNS mess is unfixable, unless Petr you volunteer to backport code to
change the behavior of the DNS based on the domain level, if that's the
case then you can tie old behavior to level 0 and new behavior to level

= 1, but I do not think you want to do that given we already have

"level 0" servers that sport the new code and changed the data in the
directory, so let's just ignore DNS for the purpose of this discussion,
except for nothing that once we finally switch to level 1 then all
servers must be running with the newer DNS schema and older is not
supported.

Ah, I almost forgot, there is no "domain level for XYZ plugin", the
domain level is one for the whole server, I want to make it v

Re: [Freeipa-devel] Domain level for topology plugin = 2

[Simo Sorce]

On Thu, 2015-05-28 at 15:39 +0200, Oleg Fayans wrote:
> 
> On 05/28/2015 03:26 PM, Simo Sorce wrote:
> > On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote:
> >> On 28.5.2015 10:49, Martin Kosek wrote:
> >>> On 05/28/2015 09:05 AM, Petr Spacek wrote:
>  On 28.5.2015 08:55, Jan Cholasta wrote:
> > 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?
>  Good point!
> 
> >>> It may be a good point, but it does not make the situation easier. You 
> >>> still
> >>> have RHEL/CentOS 6.x IPA out there, where some of them already support 
> >>> the new
> >>> DNS forwarders and some don't - and neither of them support Domain Levels 
> >>> -
> >>> i.e. have Domain Level 0.
> >>>
> >>> As I said, I still see more complications with this proposals than 
> >>> benefits...
> >> I would argue that it actually helps.
> >>
> >> If domain level = 1 then we can be *sure* that all replicas support the new
> >> DNS semantics.
> >>
> >> If domain level = 0 then we know nothing (because of patched RHEL 6) and 
> >> it is
> >> a warning sign for diagnostic tools and also us when it comes to debugging.
> > First of all  a domain level is something we change *RARELY*, and it is
> > a whole number and it is an all or nothing thing.
> >
> > I do not understand why plugin versions matter at all, plugin version
> > have nothing to do with domain levels. Each plugin *whatever* the
> > version MUST always support at least 2 levels, because every domain you
> > have will have to go through a domain_level transition when a new domain
> > level comes out.
> >
> > Finally no single developer should be allowed to decide on  anew domain
> > level, this must be a well ponder team decision as all plugins that need
> > to change behavior based on domain level will be affected so a thorough
> > review of what changes are needed across all plugins must be done every
> > time someone propose a change that requires a domain level bump.
> >
> > Last but not least we should consider domain levels as something that
> > changes *very* slowly, because otherwise you'll have to support many
> > domain levels within any plugins that have to change behavior according
> > to the domain level.
> > I would say that the domain level should not change more frequently than
> > once a year or so. It would be too much code churn t

Re: [Freeipa-devel] New replica installation and topology - we need stable base

[Ludwig Krispenz]

On 05/28/2015 03:47 PM, Martin Kosek wrote:

On 05/27/2015 04:59 PM, Martin Kosek wrote:
...

Domain Levels
- Done, committed
- Defaults to Level 1, i.e. Topology plugin powered infra enabled

With respect to related Simo's response in
http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html

Would we want to enable Topology (i.e. Domain Level 1) even if Replica
promotion is not done?
who is we ? I thought there is an api to set the domain-level and the 
admin decides if, or do you mean to have  it by default during 
installation ?

I thought we do as I see those as orthogonal features.
Replica promotion would take advantage of the Topology plugin, but it does not
mean you cannot benefit from Topology plugin without it.

You can still use the API to see/manage the topology and set replication
settings with it. You do not need Replica Promotion for that...
well, it is not just for viewing, you restrict management to use the 
ipa-toplogy commands


--
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

[Simo Sorce]

On Thu, 2015-05-28 at 15:43 +0200, Martin Kosek wrote:
> On 05/28/2015 02:29 PM, Petr Spacek wrote:
> > On 28.5.2015 12:06, Fraser Tweedale wrote:
> >> On Thu, May 28, 2015 at 11:52:25AM +0200, Martin Kosek wrote:
> >>> On 05/28/2015 11:17 AM, Martin Basti wrote:
>  On 28/05/15 10:46, Martin Kosek wrote:
> > On 05/27/2015 06:12 PM, 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 :)
> >>
> >> 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.
> > Good question. I think the suggestion was to have a global switch in 
> > IPA global
> > config that would configure the policy - whether the certificates 
> > removed by
> > this command or by host-del or host-disable are revoked or if they are 
> > just
> > removed (my motivation is to avoid behavior regression in case somebody
> > depended on this behavior).
>  I would prefer to keep the current behavior: revoke the certificate if 
>  it was
>  replaced or removed, instead of adding an extra configuration option.
>  This behavior is not regression.
> >>>
> >>> It is not. However, it is not an ideal behavior also. In FreeIPA 4.2, we 
> >>> are
> >>> now adding support of certificate profiles, multiple certificates and even
> >>> certificates for user.
> >>>
> >>> With that change, there may be much more certificates in play than now. 
> >>> If we
> >>> keep revoking all such certificates, it may cause rapid growth of CRLs. 
> >>> This is
> >>> something I am trying to avoid with this proposal and default to not 
> >>> revoking
> >>> certificates automatically (which mostly only makes sense if there is a 
> >>> risk
> >>> that the key is compromised), but have some option to keep the old 
> >>> behavior.
> >>>
> >>> Does this make sense?
> > 
> > I would like to see some data to support the decision not to revoke certs by
> > default. Are there some facts to base the decision on? Or just hand-wavy
> > reasoning?
> 
> What facts would you like to hear? If we are speaking from bugs, we already
> know that large CRL lists caused lot of grief to deployments with bug
> host/service turnaround. I do not have more data than this, besides my
> expectation that there may be much more certificates tracked by FreeIPA than 
> in
> the past and we need to deal with it.
> 
> > Sure, huge CRL may be bad, but not revoking certs may be even worse. E.g. 
> > when
> > older backup files are stolen (in the information sense, i.e. copied without
> > anyone noticing it) - attacker might get valid certs despite the fact that 
> > the
> > old cert is never used (because it was rotated right after the backup).
> 
> I am not convinced that this is a valid point. We cannot assume that FreeIPA
> administrator leaks certificate keys and try to magically fix that by this
> policy. Such fault backup can leak even when the host/service still exists.
> 
> This is about what makes most sense for certificate handling, what is the
> secure behavior and a behavior that most administr

Re: [Freeipa-devel] Domain level for topology plugin = 2

[Ludwig Krispenz]

On 05/28/2015 03:52 PM, Simo Sorce wrote:

On Thu, 2015-05-28 at 15:39 +0200, Oleg Fayans wrote:

On 05/28/2015 03:26 PM, Simo Sorce wrote:

On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote:

On 28.5.2015 10:49, Martin Kosek wrote:

On 05/28/2015 09:05 AM, Petr Spacek wrote:

On 28.5.2015 08:55, Jan Cholasta wrote:

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?

Good point!


It may be a good point, but it does not make the situation easier. You still
have RHEL/CentOS 6.x IPA out there, where some of them already support the new
DNS forwarders and some don't - and neither of them support Domain Levels -
i.e. have Domain Level 0.

As I said, I still see more complications with this proposals than benefits...

I would argue that it actually helps.

If domain level = 1 then we can be *sure* that all replicas support the new
DNS semantics.

If domain level = 0 then we know nothing (because of patched RHEL 6) and it is
a warning sign for diagnostic tools and also us when it comes to debugging.

First of all  a domain level is something we change *RARELY*, and it is
a whole number and it is an all or nothing thing.

I do not understand why plugin versions matter at all, plugin version
have nothing to do with domain levels. Each plugin *whatever* the
version MUST always support at least 2 levels, because every domain you
have will have to go through a domain_level transition when a new domain
level comes out.

Finally no single developer should be allowed to decide on  anew domain
level, this must be a well ponder team decision as all plugins that need
to change behavior based on domain level will be affected so a thorough
review of what changes are needed across all plugins must be done every
time someone propose a change that requires a domain level bump.

Last but not least we should consider domain levels as something that
changes *very* slowly, because otherwise you'll have to support many
domain levels within any plugins that have to change behavior according
to the domain level.
I would say that the domain level should not change more frequently than
once a year or so. It would be too much code churn to do otherwise.

So for now domain_level should be set to 0. And the topology plugin will
be enabled only when we turn it to 1. However we shouldn't turn it to 1
until we have the replica promotion code at least, because only then we
can make full use of the topology plugins.

Does that mean, that by default domain level must be set to 0 and only
raised manually by the identity admin?

Yes, the domain level is established by the first server you install,
and CANNOT be raise automatically by a replica, it must be always
manually raised by the admin.
yes, for the first time it is raised, but if you install a new replica 
it will be initialized from an existing replica in the domain
and teh domain level is in the shared tree, so the new replica will have 
it automatically

  Moreover the code that raises *MUST* check
that all server are capable of handling the new domain l

Re: [Freeipa-devel] [PATCH 0014] Support multiple user and host certificates

[Petr Spacek]

On 28.5.2015 15:43, Martin Kosek wrote:
> On 05/28/2015 02:29 PM, Petr Spacek wrote:
>> On 28.5.2015 12:06, Fraser Tweedale wrote:
>>> On Thu, May 28, 2015 at 11:52:25AM +0200, Martin Kosek wrote:
 On 05/28/2015 11:17 AM, Martin Basti wrote:
> On 28/05/15 10:46, Martin Kosek wrote:
>> On 05/27/2015 06:12 PM, 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 :)
>>>
>>> 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.
>> Good question. I think the suggestion was to have a global switch in IPA 
>> global
>> config that would configure the policy - whether the certificates 
>> removed by
>> this command or by host-del or host-disable are revoked or if they are 
>> just
>> removed (my motivation is to avoid behavior regression in case somebody
>> depended on this behavior).
> I would prefer to keep the current behavior: revoke the certificate if it 
> was
> replaced or removed, instead of adding an extra configuration option.
> This behavior is not regression.

 It is not. However, it is not an ideal behavior also. In FreeIPA 4.2, we 
 are
 now adding support of certificate profiles, multiple certificates and even
 certificates for user.

 With that change, there may be much more certificates in play than now. If 
 we
 keep revoking all such certificates, it may cause rapid growth of CRLs. 
 This is
 something I am trying to avoid with this proposal and default to not 
 revoking
 certificates automatically (which mostly only makes sense if there is a 
 risk
 that the key is compromised), but have some option to keep the old 
 behavior.

 Does this make sense?
>>
>> I would like to see some data to support the decision not to revoke certs by
>> default. Are there some facts to base the decision on? Or just hand-wavy
>> reasoning?
> 
> What facts would you like to hear? If we are speaking from bugs, we already
> know that large CRL lists caused lot of grief to deployments with bug
> host/service turnaround.

"We had bugs about big CRLs" is good enough. I wanted to be sure that this is
not a premature optimization.

> I do not have more data than this, besides my
> expectation that there may be much more certificates tracked by FreeIPA than 
> in
> the past and we need to deal with it.
> 
>> Sure, huge CRL may be bad, but not revoking certs may be even worse. E.g. 
>> when
>> older backup files are stolen (in the information sense, i.e. copied without
>> anyone noticing it) - attacker might get valid certs despite the fact that 
>> the
>> old cert is never used (because it was rotated right after the backup).
> 
> I am not convinced that this is a valid point. We cannot assume that FreeIPA
> administrator leaks certificate keys and try to magically fix that by this
> policy. Such fault backup can leak even when the host/service still exists.
> 
> This is about what makes most sense for certificate handling, what is the
> secure behavior and a behavior that most administrators w

Re: [Freeipa-devel] New replica installation and topology - we need stable base

[Simo Sorce]

On Thu, 2015-05-28 at 15:47 +0200, Martin Kosek wrote:
> On 05/27/2015 04:59 PM, Martin Kosek wrote:
> ...
> > Domain Levels
> > - Done, committed
> > - Defaults to Level 1, i.e. Topology plugin powered infra enabled
> 
> With respect to related Simo's response in
> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html
> 
> Would we want to enable Topology (i.e. Domain Level 1) even if Replica
> promotion is not done? I thought we do as I see those as orthogonal features.
> Replica promotion would take advantage of the Topology plugin, but it does not
> mean you cannot benefit from Topology plugin without it.
> 
> You can still use the API to see/manage the topology and set replication
> settings with it. You do not need Replica Promotion for that...

You cannot move for domain level 0 to 1 automatically anyway. So this is
a moot point to some degree. In general we need to have the code that
checks for the domain level version to be able to change the level, so
we need new code in replicas to publish the supported domain level
version and code in the install patchs to check that we can actually
join a domain given its current domain level status.

These checks are absolutely a critical blocker to enable the whole
domain-level feature.

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

[Martin Kosek]

On 05/28/2015 03:57 PM, Ludwig Krispenz wrote:
> 
> On 05/28/2015 03:47 PM, Martin Kosek wrote:
>> On 05/27/2015 04:59 PM, Martin Kosek wrote:
>> ...
>>> Domain Levels
>>> - Done, committed
>>> - Defaults to Level 1, i.e. Topology plugin powered infra enabled
>> With respect to related Simo's response in
>> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html
>>
>> Would we want to enable Topology (i.e. Domain Level 1) even if Replica
>> promotion is not done?
> who is we ? I thought there is an api to set the domain-level and the admin
> decides if, or do you mean to have  it by default during installation ?

The question here is if Topology plugin (i.e. Domain Level 1) shall be enabled
during new FreeIPA 4.2 installation or if would be still disabled and only
enabled by domain-level-set request.

>> I thought we do as I see those as orthogonal features.
>> Replica promotion would take advantage of the Topology plugin, but it does 
>> not
>> mean you cannot benefit from Topology plugin without it.
>>
>> You can still use the API to see/manage the topology and set replication
>> settings with it. You do not need Replica Promotion for that...
> well, it is not just for viewing, you restrict management to use the
> ipa-toplogy commands

Right.

-- 
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

[Martin Kosek]

On 05/28/2015 04:00 PM, Simo Sorce wrote:
> On Thu, 2015-05-28 at 15:47 +0200, Martin Kosek wrote:
>> On 05/27/2015 04:59 PM, Martin Kosek wrote:
>> ...
>>> Domain Levels
>>> - Done, committed
>>> - Defaults to Level 1, i.e. Topology plugin powered infra enabled
>>
>> With respect to related Simo's response in
>> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html
>>
>> Would we want to enable Topology (i.e. Domain Level 1) even if Replica
>> promotion is not done? I thought we do as I see those as orthogonal features.
>> Replica promotion would take advantage of the Topology plugin, but it does 
>> not
>> mean you cannot benefit from Topology plugin without it.
>>
>> You can still use the API to see/manage the topology and set replication
>> settings with it. You do not need Replica Promotion for that...
> 
> You cannot move for domain level 0 to 1 automatically anyway. So this is
> a moot point to some degree. In general we need to have the code that
> checks for the domain level version to be able to change the level, so
> we need new code in replicas to publish the supported domain level
> version and code in the install patchs to check that we can actually
> join a domain given its current domain level status.
> 
> These checks are absolutely a critical blocker to enable the whole
> domain-level feature.

All the functionality you describe and the checks should be already there. I
was really only asking about the default domain level for *new* installations

Old/upgraded FreeIPA will be on the Domain Level 0 of course.

-- 
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

[Ludwig Krispenz]

On 05/28/2015 04:00 PM, Martin Kosek wrote:

On 05/28/2015 03:57 PM, Ludwig Krispenz wrote:

On 05/28/2015 03:47 PM, Martin Kosek wrote:

On 05/27/2015 04:59 PM, Martin Kosek wrote:
...

Domain Levels
- Done, committed
- Defaults to Level 1, i.e. Topology plugin powered infra enabled

With respect to related Simo's response in
http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html

Would we want to enable Topology (i.e. Domain Level 1) even if Replica
promotion is not done?

who is we ? I thought there is an api to set the domain-level and the admin
decides if, or do you mean to have  it by default during installation ?

The question here is if Topology plugin (i.e. Domain Level 1) shall be enabled
during new FreeIPA 4.2 installation or if would be still disabled and only
enabled by domain-level-set request.
I'm with Simo, this shoul be a deliberate action by an admin, based upon 
the info that all servers support this domain level





I thought we do as I see those as orthogonal features.
Replica promotion would take advantage of the Topology plugin, but it does not
mean you cannot benefit from Topology plugin without it.

You can still use the API to see/manage the topology and set replication
settings with it. You do not need Replica Promotion for that...

well, it is not just for viewing, you restrict management to use the
ipa-toplogy commands

Right.



--
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

[Jan Cholasta]

Dne 28.5.2015 v 16:00 Simo Sorce napsal(a):

On Thu, 2015-05-28 at 15:47 +0200, Martin Kosek wrote:

On 05/27/2015 04:59 PM, Martin Kosek wrote:
...

Domain Levels
- Done, committed
- Defaults to Level 1, i.e. Topology plugin powered infra enabled


With respect to related Simo's response in
http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html

Would we want to enable Topology (i.e. Domain Level 1) even if Replica
promotion is not done? I thought we do as I see those as orthogonal features.
Replica promotion would take advantage of the Topology plugin, but it does not
mean you cannot benefit from Topology plugin without it.

You can still use the API to see/manage the topology and set replication
settings with it. You do not need Replica Promotion for that...


You cannot move for domain level 0 to 1 automatically anyway. So this is
a moot point to some degree. In general we need to have the code that
checks for the domain level version to be able to change the level, so
we need new code in replicas to publish the supported domain level
version and code in the install patchs to check that we can actually
join a domain given its current domain level status.

These checks are absolutely a critical blocker to enable the whole
domain-level feature.


IIUC this is already done, see commit 
f3010498af2a4b98512d219b8e09101176c172fe.


--
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] New replica installation and topology - we need stable base

[Martin Kosek]

On 05/28/2015 04:04 PM, Ludwig Krispenz wrote:
> 
> On 05/28/2015 04:00 PM, Martin Kosek wrote:
>> On 05/28/2015 03:57 PM, Ludwig Krispenz wrote:
>>> On 05/28/2015 03:47 PM, Martin Kosek wrote:
 On 05/27/2015 04:59 PM, Martin Kosek wrote:
 ...
> Domain Levels
> - Done, committed
> - Defaults to Level 1, i.e. Topology plugin powered infra enabled
 With respect to related Simo's response in
 http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html

 Would we want to enable Topology (i.e. Domain Level 1) even if Replica
 promotion is not done?
>>> who is we ? I thought there is an api to set the domain-level and the admin
>>> decides if, or do you mean to have  it by default during installation ?
>> The question here is if Topology plugin (i.e. Domain Level 1) shall be 
>> enabled
>> during new FreeIPA 4.2 installation or if would be still disabled and only
>> enabled by domain-level-set request.
> I'm with Simo, this shoul be a deliberate action by an admin, based upon the
> info that all servers support this domain level

Guys, I am really talking about *new* FreeIPA server installation, not
upgrades. If you are installing FreeIPA 4.2 server, you already know that *all*
servers support Topology as we do not allow installing replica with older
version than a server.

What do I miss here?

 I thought we do as I see those as orthogonal features.
 Replica promotion would take advantage of the Topology plugin, but it does 
 not
 mean you cannot benefit from Topology plugin without it.

 You can still use the API to see/manage the topology and set replication
 settings with it. You do not need Replica Promotion for that...
>>> well, it is not just for viewing, you restrict management to use the
>>> ipa-toplogy commands
>> Right.
>>
> 

-- 
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

[Petr Spacek]

On 28.5.2015 15:26, Simo Sorce wrote:
> On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote:
>> On 28.5.2015 10:49, Martin Kosek wrote:
>>> On 05/28/2015 09:05 AM, Petr Spacek wrote:
 On 28.5.2015 08:55, Jan Cholasta wrote:
> 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?

 Good point!

>>>
>>> It may be a good point, but it does not make the situation easier. You still
>>> have RHEL/CentOS 6.x IPA out there, where some of them already support the 
>>> new
>>> DNS forwarders and some don't - and neither of them support Domain Levels -
>>> i.e. have Domain Level 0.
>>>
>>> As I said, I still see more complications with this proposals than 
>>> benefits...
>>
>> I would argue that it actually helps.
>>
>> If domain level = 1 then we can be *sure* that all replicas support the new
>> DNS semantics.
>>
>> If domain level = 0 then we know nothing (because of patched RHEL 6) and it 
>> is
>> a warning sign for diagnostic tools and also us when it comes to debugging.
> 
> First of all  a domain level is something we change *RARELY*, and it is
> a whole number and it is an all or nothing thing.
> 
> I do not understand why plugin versions matter at all, plugin version
> have nothing to do with domain levels. Each plugin *whatever* the
> version MUST always support at least 2 levels, because every domain you
> have will have to go through a domain_level transition when a new domain
> level comes out.
> 
> Finally no single developer should be allowed to decide on  anew domain
> level, this must be a well ponder team decision as all plugins that need
> to change behavior based on domain level will be affected so a thorough
> review of what changes are needed across all plugins must be done every
> time someone propose a change that requires a domain level bump.
> 
> Last but not least we should consider domain levels as something that
> changes *very* slowly, because otherwise you'll have to support many
> domain levels within any plugins that have to change behavior according
> to the domain level.
> I would say that the domain level should not change more frequently than
> once a year or so. It would be too much code churn to do otherwise.
> 
> So for now domain_level should be set to 0. And the topology plugin will
> be enabled only when we turn it to 1. However we shouldn't turn it to 1
> until we have the replica promotion code at least, because only then we
> can make full use of the topology p

Re: [Freeipa-devel] New replica installation and topology - we need stable base

[Simo Sorce]

On Thu, 2015-05-28 at 16:02 +0200, Martin Kosek wrote:
> On 05/28/2015 04:00 PM, Simo Sorce wrote:
> > On Thu, 2015-05-28 at 15:47 +0200, Martin Kosek wrote:
> >> On 05/27/2015 04:59 PM, Martin Kosek wrote:
> >> ...
> >>> Domain Levels
> >>> - Done, committed
> >>> - Defaults to Level 1, i.e. Topology plugin powered infra enabled
> >>
> >> With respect to related Simo's response in
> >> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html
> >>
> >> Would we want to enable Topology (i.e. Domain Level 1) even if Replica
> >> promotion is not done? I thought we do as I see those as orthogonal 
> >> features.
> >> Replica promotion would take advantage of the Topology plugin, but it does 
> >> not
> >> mean you cannot benefit from Topology plugin without it.
> >>
> >> You can still use the API to see/manage the topology and set replication
> >> settings with it. You do not need Replica Promotion for that...
> > 
> > You cannot move for domain level 0 to 1 automatically anyway. So this is
> > a moot point to some degree. In general we need to have the code that
> > checks for the domain level version to be able to change the level, so
> > we need new code in replicas to publish the supported domain level
> > version and code in the install patchs to check that we can actually
> > join a domain given its current domain level status.
> > 
> > These checks are absolutely a critical blocker to enable the whole
> > domain-level feature.
> 
> All the functionality you describe and the checks should be already there. I
> was really only asking about the default domain level for *new* installations
> 
> Old/upgraded FreeIPA will be on the Domain Level 0 of course.

I think new installation should be on 1 but only if we have decided and
finalized what "level 1" is.

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

[Ludwig Krispenz]

On 05/28/2015 04:04 PM, Martin Kosek wrote:

On 05/28/2015 04:04 PM, Ludwig Krispenz wrote:

On 05/28/2015 04:00 PM, Martin Kosek wrote:

On 05/28/2015 03:57 PM, Ludwig Krispenz wrote:

On 05/28/2015 03:47 PM, Martin Kosek wrote:

On 05/27/2015 04:59 PM, Martin Kosek wrote:
...

Domain Levels
- Done, committed
- Defaults to Level 1, i.e. Topology plugin powered infra enabled

With respect to related Simo's response in
http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html

Would we want to enable Topology (i.e. Domain Level 1) even if Replica
promotion is not done?

who is we ? I thought there is an api to set the domain-level and the admin
decides if, or do you mean to have  it by default during installation ?

The question here is if Topology plugin (i.e. Domain Level 1) shall be enabled
during new FreeIPA 4.2 installation or if would be still disabled and only
enabled by domain-level-set request.

I'm with Simo, this shoul be a deliberate action by an admin, based upon the
info that all servers support this domain level

Guys, I am really talking about *new* FreeIPA server installation, not
upgrades. If you are installing FreeIPA 4.2 server, you already know that *all*
servers support Topology as we do not allow installing replica with older
version than a server.

What do I miss here?
well, I was not sure where in the install process you would set the 
domain level. If you create
a 4.2 replica from a 4.1 server and in the instance creation of the 4.2 
replica you set the domain level automatically,
it depends on when it  is done what side effects it will have. but maybe 
I miss that this already is handled



I thought we do as I see those as orthogonal features.
Replica promotion would take advantage of the Topology plugin, but it does not
mean you cannot benefit from Topology plugin without it.

You can still use the API to see/manage the topology and set replication
settings with it. You do not need Replica Promotion for that...

well, it is not just for viewing, you restrict management to use the
ipa-toplogy commands

Right.



--
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

[Martin Kosek]

On 05/28/2015 04:07 PM, Simo Sorce wrote:
> On Thu, 2015-05-28 at 16:02 +0200, Martin Kosek wrote:
>> On 05/28/2015 04:00 PM, Simo Sorce wrote:
>>> On Thu, 2015-05-28 at 15:47 +0200, Martin Kosek wrote:
 On 05/27/2015 04:59 PM, Martin Kosek wrote:
 ...
> Domain Levels
> - Done, committed
> - Defaults to Level 1, i.e. Topology plugin powered infra enabled

 With respect to related Simo's response in
 http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html

 Would we want to enable Topology (i.e. Domain Level 1) even if Replica
 promotion is not done? I thought we do as I see those as orthogonal 
 features.
 Replica promotion would take advantage of the Topology plugin, but it does 
 not
 mean you cannot benefit from Topology plugin without it.

 You can still use the API to see/manage the topology and set replication
 settings with it. You do not need Replica Promotion for that...
>>>
>>> You cannot move for domain level 0 to 1 automatically anyway. So this is
>>> a moot point to some degree. In general we need to have the code that
>>> checks for the domain level version to be able to change the level, so
>>> we need new code in replicas to publish the supported domain level
>>> version and code in the install patchs to check that we can actually
>>> join a domain given its current domain level status.
>>>
>>> These checks are absolutely a critical blocker to enable the whole
>>> domain-level feature.
>>
>> All the functionality you describe and the checks should be already there. I
>> was really only asking about the default domain level for *new* installations
>>
>> Old/upgraded FreeIPA will be on the Domain Level 0 of course.
> 
> I think new installation should be on 1 but only if we have decided and
> finalized what "level 1" is.
> 
> Simo.
> 

In my mind, Domain Level 1 means:

- Topology plugins is activated for all replicas and manages the agreements
- All changes to topology can be only made via topology-* commands
- ipa-replica-manage connect|disconnect are not allowed

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] New replica installation and topology - we need stable base

[Simo Sorce]

On Thu, 2015-05-28 at 16:02 +0200, Jan Cholasta wrote:
> f3010498af2a4b98512d219b8e09101176c172fe.

This is perfect! Thanks a lot.

-- 
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

[Martin Kosek]

On 05/28/2015 04:14 PM, Ludwig Krispenz wrote:
> 
> On 05/28/2015 04:04 PM, Martin Kosek wrote:
>> On 05/28/2015 04:04 PM, Ludwig Krispenz wrote:
>>> On 05/28/2015 04:00 PM, Martin Kosek wrote:
 On 05/28/2015 03:57 PM, Ludwig Krispenz wrote:
> On 05/28/2015 03:47 PM, Martin Kosek wrote:
>> On 05/27/2015 04:59 PM, Martin Kosek wrote:
>> ...
>>> Domain Levels
>>> - Done, committed
>>> - Defaults to Level 1, i.e. Topology plugin powered infra enabled
>> With respect to related Simo's response in
>> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html
>>
>> Would we want to enable Topology (i.e. Domain Level 1) even if Replica
>> promotion is not done?
> who is we ? I thought there is an api to set the domain-level and the 
> admin
> decides if, or do you mean to have  it by default during installation ?
 The question here is if Topology plugin (i.e. Domain Level 1) shall be 
 enabled
 during new FreeIPA 4.2 installation or if would be still disabled and only
 enabled by domain-level-set request.
>>> I'm with Simo, this shoul be a deliberate action by an admin, based upon the
>>> info that all servers support this domain level
>> Guys, I am really talking about *new* FreeIPA server installation, not
>> upgrades. If you are installing FreeIPA 4.2 server, you already know that 
>> *all*
>> servers support Topology as we do not allow installing replica with older
>> version than a server.
>>
>> What do I miss here?
> well, I was not sure where in the install process you would set the domain
> level. If you create
> a 4.2 replica from a 4.1 server and in the instance creation of the 4.2 
> replica
> you set the domain level automatically,
> it depends on when it  is done what side effects it will have. but maybe I 
> miss
> that this already is handled

In the use case you described, the Domain Level should be set to 0 (i.e. no
automatic raise)

>>
>> I thought we do as I see those as orthogonal features.
>> Replica promotion would take advantage of the Topology plugin, but it
>> does not
>> mean you cannot benefit from Topology plugin without it.
>>
>> You can still use the API to see/manage the topology and set replication
>> settings with it. You do not need Replica Promotion for that...
> well, it is not just for viewing, you restrict management to use the
> ipa-toplogy commands
 Right.

> 

-- 
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

[Simo Sorce]

On Thu, 2015-05-28 at 16:04 +0200, Martin Kosek wrote:
> On 05/28/2015 04:04 PM, Ludwig Krispenz wrote:
> > 
> > On 05/28/2015 04:00 PM, Martin Kosek wrote:
> >> On 05/28/2015 03:57 PM, Ludwig Krispenz wrote:
> >>> On 05/28/2015 03:47 PM, Martin Kosek wrote:
>  On 05/27/2015 04:59 PM, Martin Kosek wrote:
>  ...
> > Domain Levels
> > - Done, committed
> > - Defaults to Level 1, i.e. Topology plugin powered infra enabled
>  With respect to related Simo's response in
>  http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html
> 
>  Would we want to enable Topology (i.e. Domain Level 1) even if Replica
>  promotion is not done?
> >>> who is we ? I thought there is an api to set the domain-level and the 
> >>> admin
> >>> decides if, or do you mean to have  it by default during installation ?
> >> The question here is if Topology plugin (i.e. Domain Level 1) shall be 
> >> enabled
> >> during new FreeIPA 4.2 installation or if would be still disabled and only
> >> enabled by domain-level-set request.
> > I'm with Simo, this shoul be a deliberate action by an admin, based upon the
> > info that all servers support this domain level
> 
> Guys, I am really talking about *new* FreeIPA server installation, not
> upgrades. If you are installing FreeIPA 4.2 server, you already know that 
> *all*
> servers support Topology as we do not allow installing replica with older
> version than a server.
> 
> What do I miss here?

I think the only thing that may be missing is that the current installer
still does the dance of using SSL and then later transitioning to
GSSAPI, I am not sure the topology plugin copes with that.

Ludwig, can you comment ?

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

[Ludwig Krispenz]

On 05/28/2015 04:17 PM, Simo Sorce wrote:

On Thu, 2015-05-28 at 16:04 +0200, Martin Kosek wrote:

On 05/28/2015 04:04 PM, Ludwig Krispenz wrote:

On 05/28/2015 04:00 PM, Martin Kosek wrote:

On 05/28/2015 03:57 PM, Ludwig Krispenz wrote:

On 05/28/2015 03:47 PM, Martin Kosek wrote:

On 05/27/2015 04:59 PM, Martin Kosek wrote:
...

Domain Levels
- Done, committed
- Defaults to Level 1, i.e. Topology plugin powered infra enabled

With respect to related Simo's response in
http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html

Would we want to enable Topology (i.e. Domain Level 1) even if Replica
promotion is not done?

who is we ? I thought there is an api to set the domain-level and the admin
decides if, or do you mean to have  it by default during installation ?

The question here is if Topology plugin (i.e. Domain Level 1) shall be enabled
during new FreeIPA 4.2 installation or if would be still disabled and only
enabled by domain-level-set request.

I'm with Simo, this shoul be a deliberate action by an admin, based upon the
info that all servers support this domain level

Guys, I am really talking about *new* FreeIPA server installation, not
upgrades. If you are installing FreeIPA 4.2 server, you already know that *all*
servers support Topology as we do not allow installing replica with older
version than a server.

What do I miss here?

I think the only thing that may be missing is that the current installer
still does the dance of using SSL and then later transitioning to
GSSAPI, I am not sure the topology plugin copes with that.

yes, it works with the current installer (except for bugs)


Ludwig, can you comment ?

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] Domain level for topology plugin = 2

[Oleg Fayans]

Hi Simo,

On 05/28/2015 03:52 PM, Simo Sorce wrote:
> On Thu, 2015-05-28 at 15:39 +0200, Oleg Fayans wrote:
>> On 05/28/2015 03:26 PM, Simo Sorce wrote:
>>> On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote:
 On 28.5.2015 10:49, Martin Kosek wrote:
> On 05/28/2015 09:05 AM, Petr Spacek wrote:
>> On 28.5.2015 08:55, Jan Cholasta wrote:
>>> 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?
>> Good point!
>>
> It may be a good point, but it does not make the situation easier. You 
> still
> have RHEL/CentOS 6.x IPA out there, where some of them already support 
> the new
> DNS forwarders and some don't - and neither of them support Domain Levels 
> -
> i.e. have Domain Level 0.
>
> As I said, I still see more complications with this proposals than 
> benefits...
 I would argue that it actually helps.

 If domain level = 1 then we can be *sure* that all replicas support the new
 DNS semantics.

 If domain level = 0 then we know nothing (because of patched RHEL 6) and 
 it is
 a warning sign for diagnostic tools and also us when it comes to debugging.
>>> First of all  a domain level is something we change *RARELY*, and it is
>>> a whole number and it is an all or nothing thing.
>>>
>>> I do not understand why plugin versions matter at all, plugin version
>>> have nothing to do with domain levels. Each plugin *whatever* the
>>> version MUST always support at least 2 levels, because every domain you
>>> have will have to go through a domain_level transition when a new domain
>>> level comes out.
>>>
>>> Finally no single developer should be allowed to decide on  anew domain
>>> level, this must be a well ponder team decision as all plugins that need
>>> to change behavior based on domain level will be affected so a thorough
>>> review of what changes are needed across all plugins must be done every
>>> time someone propose a change that requires a domain level bump.
>>>
>>> Last but not least we should consider domain levels as something that
>>> changes *very* slowly, because otherwise you'll have to support many
>>> domain levels within any plugins that have to change behavior according
>>> to the domain level.
>>> I would say that the domain level should not change more frequently than
>>> 

Re: [Freeipa-devel] Sudorules user validation help

[Drew Erny]

In the ticket, however, it's stated that if the user wants to use any 
combination of weird characters, they should be able to. Would it be 
better to just define a function like


def validate_username(username, ignore_pattern=False):

and have it ignore all username validation?

On 05/28/2015 09:40 AM, Drew Erny wrote:
OK, I see now what you mean by that. That is a simpler solution. I'll 
do it that way.


On 05/28/2015 04:44 AM, Martin Kosek wrote:

On 05/27/2015 08:41 PM, Drew Erny wrote:

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?
I think it would make sense to follow the example with 
validate_hostname and
prepare a function validate_username(username, upn=False, 
netbios_name=False) [1].


where upn would allow using "@." on top of current validator (i.e.
u...@domain.test) and netbios_name would allow the "DOMAIN\user" 
style. I would
just suggest making sure the standard user validation error message 
is still

the same to avoid unnecessary QE fail positives.

In add_external_pre_callback you could then just simply call

validate_username(user, True, True)

just like it is already done with hostname.

My 2 cents.

Martin

[1] 
https://msdn.microsoft.com/en-us/library/windows/desktop/aa380525(v=vs.85).aspx




--
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

[Simo Sorce]

On Thu, 2015-05-28 at 16:23 +0200, Oleg Fayans wrote:
> Hi Simo,
> 
> On 05/28/2015 03:52 PM, Simo Sorce wrote:
> > On Thu, 2015-05-28 at 15:39 +0200, Oleg Fayans wrote:
> >> On 05/28/2015 03:26 PM, Simo Sorce wrote:
> >>> On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote:
>  On 28.5.2015 10:49, Martin Kosek wrote:
> > On 05/28/2015 09:05 AM, Petr Spacek wrote:
> >> On 28.5.2015 08:55, Jan Cholasta wrote:
> >>> 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?
> >> Good point!
> >>
> > It may be a good point, but it does not make the situation easier. You 
> > still
> > have RHEL/CentOS 6.x IPA out there, where some of them already support 
> > the new
> > DNS forwarders and some don't - and neither of them support Domain 
> > Levels -
> > i.e. have Domain Level 0.
> >
> > As I said, I still see more complications with this proposals than 
> > benefits...
>  I would argue that it actually helps.
> 
>  If domain level = 1 then we can be *sure* that all replicas support the 
>  new
>  DNS semantics.
> 
>  If domain level = 0 then we know nothing (because of patched RHEL 6) and 
>  it is
>  a warning sign for diagnostic tools and also us when it comes to 
>  debugging.
> >>> First of all  a domain level is something we change *RARELY*, and it is
> >>> a whole number and it is an all or nothing thing.
> >>>
> >>> I do not understand why plugin versions matter at all, plugin version
> >>> have nothing to do with domain levels. Each plugin *whatever* the
> >>> version MUST always support at least 2 levels, because every domain you
> >>> have will have to go through a domain_level transition when a new domain
> >>> level comes out.
> >>>
> >>> Finally no single developer should be allowed to decide on  anew domain
> >>> level, this must be a well ponder team decision as all plugins that need
> >>> to change behavior based on domain level will be affected so a thorough
> >>> review of what changes are needed across all plugins must be done every
> >>> time someone propose a change that requires a domain level bump.
> >>>
> >>> Last but not 

[Freeipa-devel] KDC proxy implementation specs

[Christian Heimes]

Hello,

thanks you for your input. The former thread has 58 messages in total.
Since last Friday we have came to an agreement in most points. I like to
some up our decisions and focus on some minor details.

decisions
-

python-kdcproxy will be installed as a dependency of freeipa-server.
There won't be a separate freeipa-server-kdcproxy package. That may or
may not change in the future. The decision is out of scope for 4.2.0. [1]

KDC proxy support will be enabled by default. The config files and LDAP
settings will be created by ipa-server-install, ipa-server-upgrade and
ipa-replica-install.

The enabled/disabled switch will be stored per-replica in the
cn=masters,cn=ipa,cn=etc tree. An API and CLI tool for management is
postponed. [2] For now we settle for some doc examples that use the
ipa-ldap-updater as suggested by Alex. [3]


open for discussion
---

Jan has suggested to ipaConfigString=kdcProxyEnabled in
cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of
ipaConfigString=enabledService in
cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense to me.
After all MS-KKDCP is just another transport for the KDC. [4]

Martin Basti suggested a different keytab and principal for kdcproxy.
[5] The keytab is only required for GSSAPI bind to lookup the state of
the enabled/disabled switch. The current patch uses the same keytab as
webgui.
A new principal separates kdcproxy more cleanly and allows for
fine-grained ACIs. It is also more future proof. In the future we may
want to move kdcproxy from an Apache WSGI app to a separate service. A
dedicated Twisted or asyncio daemon could handle more load.
A separate keytab is easy to implement, too. I looked at the code in
HTTPInstance.__create_http_keytab().

For the ACI I plan to add a new permission 'System: Read IPA Config
String' and make the principal a direct memberOf of it. We don't have
service roles yet. cn=roles,cn=accounts look like end user roles to me.
The new ACI in cn=masters,cn=ipa,cn=etc will grant read, search and
compare permission:

(targetfilter = "(objectClass=nsContainer)")(targetattr = "cn ||
objectClass || ipaConfigString")(version 3.0; acl "Read IPA Config
String"; allow (read, search, compare) groupdn = "ldap:///cn=System:
Read IPA Config String,cn=permissions,cn=pbac,dc=ipa,dc=example";)


I should be able to modify and test my patch in a matter of a couple of
hours.

Christian

[1] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00535.html
[2] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00555.html
[3] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00533.html
[4] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00543.html
[5] http://www.redhat.com/archives/freeipa-devel/2015-May/msg00539.html



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] Domain level for topology plugin = 2

[Martin Basti]

On 28/05/15 16:29, Simo Sorce wrote:

On Thu, 2015-05-28 at 16:23 +0200, Oleg Fayans wrote:

Hi Simo,

On 05/28/2015 03:52 PM, Simo Sorce wrote:

On Thu, 2015-05-28 at 15:39 +0200, Oleg Fayans wrote:

On 05/28/2015 03:26 PM, Simo Sorce wrote:

On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote:

On 28.5.2015 10:49, Martin Kosek wrote:

On 05/28/2015 09:05 AM, Petr Spacek wrote:

On 28.5.2015 08:55, Jan Cholasta wrote:

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?

Good point!


It may be a good point, but it does not make the situation easier. You still
have RHEL/CentOS 6.x IPA out there, where some of them already support the new
DNS forwarders and some don't - and neither of them support Domain Levels -
i.e. have Domain Level 0.

As I said, I still see more complications with this proposals than benefits...

I would argue that it actually helps.

If domain level = 1 then we can be *sure* that all replicas support the new
DNS semantics.

If domain level = 0 then we know nothing (because of patched RHEL 6) and it is
a warning sign for diagnostic tools and also us when it comes to debugging.

First of all  a domain level is something we change *RARELY*, and it is
a whole number and it is an all or nothing thing.

I do not understand why plugin versions matter at all, plugin version
have nothing to do with domain levels. Each plugin *whatever* the
version MUST always support at least 2 levels, because every domain you
have will have to go through a domain_level transition when a new domain
level comes out.

Finally no single developer should be allowed to decide on  anew domain
level, this must be a well ponder team decision as all plugins that need
to change behavior based on domain level will be affected so a thorough
review of what changes are needed across all plugins must be done every
time someone propose a change that requires a domain level bump.

Last but not least we should consider domain levels as something that
changes *very* slowly, because otherwise you'll have to support many
domain levels within any plugins that have to change behavior according
to the domain level.
I would say that the domain level should not change more frequently than
once a year or so. It would be too much code churn to do otherwise.

So for now domain_level should be set to 0. And the topology plugin will
be enabled only when we turn it to 1. However we shouldn't turn it to 1
until we have the replica promotion code at least, because only then we
can make full use of the topology plugins.

Does that mean, that by default domain level must be set to 0 and only
raised manually by the identity admin?

Yes, the domain level is established by the first server you install,
and CANNOT be raise automatically by a replica, it must be always
manually raised by the admin. Moreover the code that raises *MUST* check
that all server are capable of handling the new domain level or refuse
to raise the level.
This means all servers must publish the range of domain levels they
support, a missing rang

Re: [Freeipa-devel] Domain level for topology plugin = 2

[Simo Sorce]

On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote:
> On 05/28/2015 03:26 PM, Simo Sorce wrote:
> > On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote:
> >> On 28.5.2015 10:49, Martin Kosek wrote:
> >>> On 05/28/2015 09:05 AM, Petr Spacek wrote:
>  On 28.5.2015 08:55, Jan Cholasta wrote:
> > 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?
>  Good point!
> 
> >>> It may be a good point, but it does not make the situation easier. You 
> >>> still
> >>> have RHEL/CentOS 6.x IPA out there, where some of them already support 
> >>> the new
> >>> DNS forwarders and some don't - and neither of them support Domain Levels 
> >>> -
> >>> i.e. have Domain Level 0.
> >>>
> >>> As I said, I still see more complications with this proposals than 
> >>> benefits...
> >> I would argue that it actually helps.
> >>
> >> If domain level = 1 then we can be *sure* that all replicas support the new
> >> DNS semantics.
> >>
> >> If domain level = 0 then we know nothing (because of patched RHEL 6) and 
> >> it is
> >> a warning sign for diagnostic tools and also us when it comes to debugging.
> > First of all  a domain level is something we change *RARELY*, and it is
> > a whole number and it is an all or nothing thing.
> >
> > I do not understand why plugin versions matter at all, plugin version
> > have nothing to do with domain levels. Each plugin *whatever* the
> > version MUST always support at least 2 levels, because every domain you
> > have will have to go through a domain_level transition when a new domain
> > level comes out.
> >
> > Finally no single developer should be allowed to decide on  anew domain
> > level, this must be a well ponder team decision as all plugins that need
> > to change behavior based on domain level will be affected so a thorough
> > review of what changes are needed across all plugins must be done every
> > time someone propose a change that requires a domain level bump.
> >
> > Last but not least we should consider domain levels as something that
> > changes *very* slowly, because otherwise you'll have to support many
> > domain levels within any plugins that have to change behavior according
> > to the domain level.
> > I would say that the domain level should not change more frequently than
> > once a year or so. It would be too much code churn 

Re: [Freeipa-devel] KDC proxy implementation specs

[Simo Sorce]

On Thu, 2015-05-28 at 10:48 -0400, Nathaniel McCallum wrote:
> On Thu, 2015-05-28 at 16:34 +0200, Christian Heimes wrote:
> > Hello,
> > 
> > thanks you for your input. The former thread has 58 messages in 
> > total.
> > Since last Friday we have came to an agreement in most points. I like 
> > to
> > some up our decisions and focus on some minor details.
> > 
> > decisions
> > -
> > 
> > python-kdcproxy will be installed as a dependency of freeipa-server.
> > There won't be a separate freeipa-server-kdcproxy package. That may 
> > or
> > may not change in the future. The decision is out of scope for 4.2.0. 
> > [1]
> > 
> > KDC proxy support will be enabled by default. The config files and 
> > LDAP
> > settings will be created by ipa-server-install, ipa-server-upgrade 
> > and
> > ipa-replica-install.
> > 
> > The enabled/disabled switch will be stored per-replica in the
> > cn=masters,cn=ipa,cn=etc tree. An API and CLI tool for management is
> > postponed. [2] For now we settle for some doc examples that use the
> > ipa-ldap-updater as suggested by Alex. [3]
> > 
> > 
> > open for discussion
> > ---
> > 
> > Jan has suggested to ipaConfigString=kdcProxyEnabled in
> > cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of
> > ipaConfigString=enabledService in
> > cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense to me.
> > After all MS-KKDCP is just another transport for the KDC. [4]
> 
> There may be a security concern here if we aren't careful. I think I'm
> in favor of KDCPROXY since it is a different application.
> 
> > Martin Basti suggested a different keytab and principal for kdcproxy.
> > [5] The keytab is only required for GSSAPI bind to lookup the state 
> > of
> > the enabled/disabled switch. The current patch uses the same keytab 
> > as
> > webgui.
> > A new principal separates kdcproxy more cleanly and allows for
> > fine-grained ACIs. It is also more future proof.
> 
> It may also have auditing benefits now that we are beginning to think
> about the A in FreeIPA.

We can't have 2 different keytabs with the same principal name.
If we need privilege separation we'll have to work on integrating
GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands
of both the framework, the proxy, and apache itself.

Although to be honest I do not see why the proxy need access to the
keytab at all, can we simply run it as a wsgi application under a
different user and prevent it from accessing the apache keytab at all ?

> > In the future we may
> > want to move kdcproxy from an Apache WSGI app to a separate service. 
> > A
> > dedicated Twisted or asyncio daemon could handle more load.
> > A separate keytab is easy to implement, too. I looked at the code in
> > HTTPInstance.__create_http_keytab().
> 
> An apache module would also provide similar benefits. I'm not sure I
> necessarily want to stick with python here if we're optimizing for
> performance. Another option would be to add it to the KDC itself and
> proxy through Apache like we do for Tomcat. MIT might like that option.

What do we need the keytab for ?
Is it just in order to authenticate and read if the service is enabled ?
Can we make that information available anonymously ?

> > For the ACI I plan to add a new permission 'System: Read IPA Config
> > String' and make the principal a direct memberOf of it. We don't have
> > service roles yet. cn=roles,cn=accounts look like end user roles to 
> > me.
> > The new ACI in cn=masters,cn=ipa,cn=etc will grant read, search and
> > compare permission:
> > 
> > (targetfilter = "(objectClass=nsContainer)")(targetattr = "cn ||
> > objectClass || ipaConfigString")(version 3.0; acl "Read IPA Config
> > String"; allow (read, search, compare) groupdn = "ldap:///cn=System:
> > Read IPA Config String,cn=permissions,cn=pbac,dc=ipa,dc=example";)
> > 
> > 
> > I should be able to modify and test my patch in a matter of a couple 
> > of
> > hours.
> > 
> > Christian
> > 
> > [1] 
> > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00535.html
> > [2] 
> > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00555.html
> > [3] 
> > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00533.html
> > [4] 
> > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00543.html
> > [5] 
> > http://www.redhat.com/archives/freeipa-devel/2015-May/msg00539.html
> > 
> > -- 
> > 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
> 


-- 
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] Domain level for topology plugin = 2

[Simo Sorce]

On Thu, 2015-05-28 at 10:46 -0400, Simo Sorce wrote:
> On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote:
> > On 05/28/2015 03:26 PM, Simo Sorce wrote:
> > > On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote:
> > >> On 28.5.2015 10:49, Martin Kosek wrote:
> > >>> On 05/28/2015 09:05 AM, Petr Spacek wrote:
> >  On 28.5.2015 08:55, Jan Cholasta wrote:
> > > 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?
> >  Good point!
> > 
> > >>> It may be a good point, but it does not make the situation easier. You 
> > >>> still
> > >>> have RHEL/CentOS 6.x IPA out there, where some of them already support 
> > >>> the new
> > >>> DNS forwarders and some don't - and neither of them support Domain 
> > >>> Levels -
> > >>> i.e. have Domain Level 0.
> > >>>
> > >>> As I said, I still see more complications with this proposals than 
> > >>> benefits...
> > >> I would argue that it actually helps.
> > >>
> > >> If domain level = 1 then we can be *sure* that all replicas support the 
> > >> new
> > >> DNS semantics.
> > >>
> > >> If domain level = 0 then we know nothing (because of patched RHEL 6) and 
> > >> it is
> > >> a warning sign for diagnostic tools and also us when it comes to 
> > >> debugging.
> > > First of all  a domain level is something we change *RARELY*, and it is
> > > a whole number and it is an all or nothing thing.
> > >
> > > I do not understand why plugin versions matter at all, plugin version
> > > have nothing to do with domain levels. Each plugin *whatever* the
> > > version MUST always support at least 2 levels, because every domain you
> > > have will have to go through a domain_level transition when a new domain
> > > level comes out.
> > >
> > > Finally no single developer should be allowed to decide on  anew domain
> > > level, this must be a well ponder team decision as all plugins that need
> > > to change behavior based on domain level will be affected so a thorough
> > > review of what changes are needed across all plugins must be done every
> > > time someone propose a change that requires a domain level bump.
> > >
> > > Last but not least we should consider domain levels as something that
>

Re: [Freeipa-devel] New replica installation and topology - we need stable base

[Simo Sorce]

On Thu, 2015-05-28 at 16:14 +0200, Martin Kosek wrote:
> On 05/28/2015 04:07 PM, Simo Sorce wrote:
> > On Thu, 2015-05-28 at 16:02 +0200, Martin Kosek wrote:
> >> On 05/28/2015 04:00 PM, Simo Sorce wrote:
> >>> On Thu, 2015-05-28 at 15:47 +0200, Martin Kosek wrote:
>  On 05/27/2015 04:59 PM, Martin Kosek wrote:
>  ...
> > Domain Levels
> > - Done, committed
> > - Defaults to Level 1, i.e. Topology plugin powered infra enabled
> 
>  With respect to related Simo's response in
>  http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html
> 
>  Would we want to enable Topology (i.e. Domain Level 1) even if Replica
>  promotion is not done? I thought we do as I see those as orthogonal 
>  features.
>  Replica promotion would take advantage of the Topology plugin, but it 
>  does not
>  mean you cannot benefit from Topology plugin without it.
> 
>  You can still use the API to see/manage the topology and set replication
>  settings with it. You do not need Replica Promotion for that...
> >>>
> >>> You cannot move for domain level 0 to 1 automatically anyway. So this is
> >>> a moot point to some degree. In general we need to have the code that
> >>> checks for the domain level version to be able to change the level, so
> >>> we need new code in replicas to publish the supported domain level
> >>> version and code in the install patchs to check that we can actually
> >>> join a domain given its current domain level status.
> >>>
> >>> These checks are absolutely a critical blocker to enable the whole
> >>> domain-level feature.
> >>
> >> All the functionality you describe and the checks should be already there. 
> >> I
> >> was really only asking about the default domain level for *new* 
> >> installations
> >>
> >> Old/upgraded FreeIPA will be on the Domain Level 0 of course.
> > 
> > I think new installation should be on 1 but only if we have decided and
> > finalized what "level 1" is.
> > 
> > Simo.
> > 
> 
> In my mind, Domain Level 1 means:
> 
> - Topology plugins is activated for all replicas and manages the agreements
> - All changes to topology can be only made via topology-* commands
> - ipa-replica-manage connect|disconnect are not allowed

Ok, if we want to restrict it to this then fine.
In my original plan level 1 also meant the KISS/Custodia service is
available on all master. If not then we cannot depend on it and we
cannot fully finish the work on replica promotion w/o requiring the
replica package anymore.

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] Sudorules user validation help

[Martin Kosek]

On 05/28/2015 04:27 PM, Drew Erny wrote:
> In the ticket, however, it's stated that if the user wants to use any
> combination of weird characters, they should be able to. Would it be better to
> just define a function like
> 
> def validate_username(username, ignore_pattern=False):
> 
> and have it ignore all username validation?

Tough question. FreeIPA in general tries to sanitize user input and does not
allow everything user wants and try to advise the best practices, as we see it.

In your case, if we allow only the 2 mentioned user login formats, it should
work for AD use case just fine and add some level of sanity check of the user
name. BTW, given we run an LDAP search later on this user name, isn't there a
possibility of "LDAP injection" if we choose to allow all characters, including
"(" and ")"? :-)

In any case, if we choose to ignore the pattern, we do not need the extra
validator function at all. We would just skip validation in the pre callback if
a user is being added.

> 
> On 05/28/2015 09:40 AM, Drew Erny wrote:
>> OK, I see now what you mean by that. That is a simpler solution. I'll do it
>> that way.
>>
>> On 05/28/2015 04:44 AM, Martin Kosek wrote:
>>> On 05/27/2015 08:41 PM, Drew Erny wrote:
 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?
>>> I think it would make sense to follow the example with validate_hostname and
>>> prepare a function validate_username(username, upn=False,
>>> netbios_name=False) [1].
>>>
>>> where upn would allow using "@." on top of current validator (i.e.
>>> u...@domain.test) and netbios_name would allow the "DOMAIN\user" style. I 
>>> would
>>> just suggest making sure the standard user validation error message is still
>>> the same to avoid unnecessary QE fail positives.
>>>
>>> In add_external_pre_callback you could then just simply call
>>>
>>> validate_username(user, True, True)
>>>
>>> just like it is already done with hostname.
>>>
>>> My 2 cents.
>>>
>>> Martin
>>>
>>> [1]
>>> https://msdn.microsoft.com/en-us/library/windows/desktop/aa380525(v=vs.85).aspx
>>
> 

-- 
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] KDC proxy implementation specs

[Christian Heimes]

On 2015-05-28 16:53, Simo Sorce wrote:
> We can't have 2 different keytabs with the same principal name.
> If we need privilege separation we'll have to work on integrating
> GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands
> of both the framework, the proxy, and apache itself.

I had a different principal like KDCPROXY/fqdn@realm in mind.

> Although to be honest I do not see why the proxy need access to the
> keytab at all, can we simply run it as a wsgi application under a
> different user and prevent it from accessing the apache keytab at all ?

Yes, mod_wsgi is able to run a WSGI app as a different user:

https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess

A different user needs another location for the ccache and perhaps
additional SELinux rules.

> What do we need the keytab for ?
> Is it just in order to authenticate and read if the service is enabled ?
> Can we make that information available anonymously ?

Yes, the information is not available for anon bind. It doesn't feel
right to disclose the settings to the public.

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] New replica installation and topology - we need stable base

[Martin Kosek]

On 05/28/2015 04:57 PM, Simo Sorce wrote:
> On Thu, 2015-05-28 at 16:14 +0200, Martin Kosek wrote:
>> On 05/28/2015 04:07 PM, Simo Sorce wrote:
>>> On Thu, 2015-05-28 at 16:02 +0200, Martin Kosek wrote:
 On 05/28/2015 04:00 PM, Simo Sorce wrote:
> On Thu, 2015-05-28 at 15:47 +0200, Martin Kosek wrote:
>> On 05/27/2015 04:59 PM, Martin Kosek wrote:
>> ...
>>> Domain Levels
>>> - Done, committed
>>> - Defaults to Level 1, i.e. Topology plugin powered infra enabled
>>
>> With respect to related Simo's response in
>> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00553.html
>>
>> Would we want to enable Topology (i.e. Domain Level 1) even if Replica
>> promotion is not done? I thought we do as I see those as orthogonal 
>> features.
>> Replica promotion would take advantage of the Topology plugin, but it 
>> does not
>> mean you cannot benefit from Topology plugin without it.
>>
>> You can still use the API to see/manage the topology and set replication
>> settings with it. You do not need Replica Promotion for that...
>
> You cannot move for domain level 0 to 1 automatically anyway. So this is
> a moot point to some degree. In general we need to have the code that
> checks for the domain level version to be able to change the level, so
> we need new code in replicas to publish the supported domain level
> version and code in the install patchs to check that we can actually
> join a domain given its current domain level status.
>
> These checks are absolutely a critical blocker to enable the whole
> domain-level feature.

 All the functionality you describe and the checks should be already there. 
 I
 was really only asking about the default domain level for *new* 
 installations

 Old/upgraded FreeIPA will be on the Domain Level 0 of course.
>>>
>>> I think new installation should be on 1 but only if we have decided and
>>> finalized what "level 1" is.
>>>
>>> Simo.
>>>
>>
>> In my mind, Domain Level 1 means:
>>
>> - Topology plugins is activated for all replicas and manages the agreements
>> - All changes to topology can be only made via topology-* commands
>> - ipa-replica-manage connect|disconnect are not allowed
> 
> Ok, if we want to restrict it to this then fine.
> In my original plan level 1 also meant the KISS/Custodia service is
> available on all master. If not then we cannot depend on it and we
> cannot fully finish the work on replica promotion w/o requiring the
> replica package anymore.

The Custodia/Replica promotion will depend on Topology plugin to be there, but
I do not think we necessarily need to make it a new Domain Level just for it.
During "ipa-replica-install", the installer can simply check if Custodia is
accessible on remote server and bail out if it is not accessible and it does
not have the replica file.

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] Domain level for topology plugin = 2

[Simo Sorce]

On Thu, 2015-05-28 at 16:40 +0200, Martin Basti wrote:
> On 28/05/15 16:29, Simo Sorce wrote:
> > On Thu, 2015-05-28 at 16:23 +0200, Oleg Fayans wrote:
> >> Hi Simo,
> >>
> >> On 05/28/2015 03:52 PM, Simo Sorce wrote:
> >>> On Thu, 2015-05-28 at 15:39 +0200, Oleg Fayans wrote:
>  On 05/28/2015 03:26 PM, Simo Sorce wrote:
> > On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote:
> >> On 28.5.2015 10:49, Martin Kosek wrote:
> >>> On 05/28/2015 09:05 AM, Petr Spacek wrote:
>  On 28.5.2015 08:55, Jan Cholasta wrote:
> > 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?
>  Good point!
> 
> >>> It may be a good point, but it does not make the situation easier. 
> >>> You still
> >>> have RHEL/CentOS 6.x IPA out there, where some of them already 
> >>> support the new
> >>> DNS forwarders and some don't - and neither of them support Domain 
> >>> Levels -
> >>> i.e. have Domain Level 0.
> >>>
> >>> As I said, I still see more complications with this proposals than 
> >>> benefits...
> >> I would argue that it actually helps.
> >>
> >> If domain level = 1 then we can be *sure* that all replicas support 
> >> the new
> >> DNS semantics.
> >>
> >> If domain level = 0 then we know nothing (because of patched RHEL 6) 
> >> and it is
> >> a warning sign for diagnostic tools and also us when it comes to 
> >> debugging.
> > First of all  a domain level is something we change *RARELY*, and it is
> > a whole number and it is an all or nothing thing.
> >
> > I do not understand why plugin versions matter at all, plugin version
> > have nothing to do with domain levels. Each plugin *whatever* the
> > version MUST always support at least 2 levels, because every domain you
> > have will have to go through a domain_level transition when a new domain
> > level comes out.
> >
> > Finally no single developer should be allowed to decide on  anew domain
> > l

Re: [Freeipa-devel] Domain level for topology plugin = 2

[Martin Kosek]

On 05/28/2015 04:59 PM, Ludwig Krispenz wrote:
> 
> On 05/28/2015 04:46 PM, Simo Sorce wrote:
>> On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote:
>>> On 05/28/2015 03:26 PM, Simo Sorce wrote:
 On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote:
> On 28.5.2015 10:49, Martin Kosek wrote:
>> On 05/28/2015 09:05 AM, Petr Spacek wrote:
>>> On 28.5.2015 08:55, Jan Cholasta wrote:
 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?
>>> Good point!
>>>
>> It may be a good point, but it does not make the situation easier. You 
>> still
>> have RHEL/CentOS 6.x IPA out there, where some of them already support
>> the new
>> DNS forwarders and some don't - and neither of them support Domain 
>> Levels -
>> i.e. have Domain Level 0.
>>
>> As I said, I still see more complications with this proposals than
>> benefits...
> I would argue that it actually helps.
>
> If domain level = 1 then we can be *sure* that all replicas support the 
> new
> DNS semantics.
>
> If domain level = 0 then we know nothing (because of patched RHEL 6) and
> it is
> a warning sign for diagnostic tools and also us when it comes to 
> debugging.
 First of all  a domain level is something we change *RARELY*, and it is
 a whole number and it is an all or nothing thing.

 I do not understand why plugin versions matter at all, plugin version
 have nothing to do with domain levels. Each plugin *whatever* the
 version MUST always support at least 2 levels, because every domain you
 have will have to go through a domain_level transition when a new domain
 level comes out.

 Finally no single developer should be allowed to decide on  anew domain
 level, this must be a well ponder team decision as all plugins that need
 to change behavior based on domain level will be affected so a thorough
 review of what changes are needed across all plugins must be done every
 time someone propose a change that requires a domain level bump.

 Last but not least we should consider domain levels as something that
 changes *very* slowly, because otherwise you'll have to support many
 domain levels within any

Re: [Freeipa-devel] Domain level for topology plugin = 2

[Ludwig Krispenz]

On 05/28/2015 04:46 PM, Simo Sorce wrote:

On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote:

On 05/28/2015 03:26 PM, Simo Sorce wrote:

On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote:

On 28.5.2015 10:49, Martin Kosek wrote:

On 05/28/2015 09:05 AM, Petr Spacek wrote:

On 28.5.2015 08:55, Jan Cholasta wrote:

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?

Good point!


It may be a good point, but it does not make the situation easier. You still
have RHEL/CentOS 6.x IPA out there, where some of them already support the new
DNS forwarders and some don't - and neither of them support Domain Levels -
i.e. have Domain Level 0.

As I said, I still see more complications with this proposals than benefits...

I would argue that it actually helps.

If domain level = 1 then we can be *sure* that all replicas support the new
DNS semantics.

If domain level = 0 then we know nothing (because of patched RHEL 6) and it is
a warning sign for diagnostic tools and also us when it comes to debugging.

First of all  a domain level is something we change *RARELY*, and it is
a whole number and it is an all or nothing thing.

I do not understand why plugin versions matter at all, plugin version
have nothing to do with domain levels. Each plugin *whatever* the
version MUST always support at least 2 levels, because every domain you
have will have to go through a domain_level transition when a new domain
level comes out.

Finally no single developer should be allowed to decide on  anew domain
level, this must be a well ponder team decision as all plugins that need
to change behavior based on domain level will be affected so a thorough
review of what changes are needed across all plugins must be done every
time someone propose a change that requires a domain level bump.

Last but not least we should consider domain levels as something that
changes *very* slowly, because otherwise you'll have to support many
domain levels within any plugins that have to change behavior according
to the domain level.
I would say that the domain level should not change more frequently than
once a year or so. It would be too much code churn to do otherwise.

So for now domain_level should be set to 0. And the topology plugin will
be enabled only when we turn it to 1. However we shouldn't turn it to 1
until we have the replica promotion code at least, because only then we
can make full use of the topology plugins.

The DNS mess is unfixable, unless Petr you volunteer to backport code to
change the behavior of the DNS based on the domain level, if that's the
case then you can tie old behavior to level 0 and new behavior to level

= 1, but I do not think you want to do that given we already have

"level 0" servers that sport the new code and changed the data in the
directory, so let's just ignore DNS for the purpose of this discussion,
except for nothing that once we finally switch to level 1 then all
servers must be running with the newer DNS schema and older is not
supported.

Ah, I almost forgot, there 

Re: [Freeipa-devel] Domain level for topology plugin = 2

[Simo Sorce]

On Thu, 2015-05-28 at 16:59 +0200, Ludwig Krispenz wrote:
> On 05/28/2015 04:46 PM, Simo Sorce wrote:
> > On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote:
> >> On 05/28/2015 03:26 PM, Simo Sorce wrote:
> >>> On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote:
>  On 28.5.2015 10:49, Martin Kosek wrote:
> > On 05/28/2015 09:05 AM, Petr Spacek wrote:
> >> On 28.5.2015 08:55, Jan Cholasta wrote:
> >>> 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?
> >> Good point!
> >>
> > It may be a good point, but it does not make the situation easier. You 
> > still
> > have RHEL/CentOS 6.x IPA out there, where some of them already support 
> > the new
> > DNS forwarders and some don't - and neither of them support Domain 
> > Levels -
> > i.e. have Domain Level 0.
> >
> > As I said, I still see more complications with this proposals than 
> > benefits...
>  I would argue that it actually helps.
> 
>  If domain level = 1 then we can be *sure* that all replicas support the 
>  new
>  DNS semantics.
> 
>  If domain level = 0 then we know nothing (because of patched RHEL 6) and 
>  it is
>  a warning sign for diagnostic tools and also us when it comes to 
>  debugging.
> >>> First of all  a domain level is something we change *RARELY*, and it is
> >>> a whole number and it is an all or nothing thing.
> >>>
> >>> I do not understand why plugin versions matter at all, plugin version
> >>> have nothing to do with domain levels. Each plugin *whatever* the
> >>> version MUST always support at least 2 levels, because every domain you
> >>> have will have to go through a domain_level transition when a new domain
> >>> level comes out.
> >>>
> >>> Finally no single developer should be allowed to decide on  anew domain
> >>> level, this must be a well ponder team decision as all plugins that need
> >>> to change behavior based on domain level will be affected so a thorough
> >>> review of what changes are needed across all plugins must be done every
> >>> time someone propose a change that requires a domain level bump.
> >>>
> >>> Last but not least 

Re: [Freeipa-devel] KDC proxy implementation specs

[Christian Heimes]

On 2015-05-28 16:48, Nathaniel McCallum wrote:
> An apache module would also provide similar benefits. I'm not sure I
> necessarily want to stick with python here if we're optimizing for
> performance. Another option would be to add it to the KDC itself and
> proxy through Apache like we do for Tomcat. MIT might like that option.

For that kind of network code Python is really fast enough. An event
driven framework like asyncio or Twisted can handle lots of connections
simultaneous. We aren't speaking about several GBit/sec where zero-copy
is required.

I'm more worried about Apache than Python. Apache is tuned for the needs
of the webui, e.g. prefork MPM. Let's see how it works out in a
production system.

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] KDC proxy implementation specs

[Nathaniel McCallum]

On Thu, 2015-05-28 at 16:34 +0200, Christian Heimes wrote:
> Hello,
> 
> thanks you for your input. The former thread has 58 messages in 
> total.
> Since last Friday we have came to an agreement in most points. I like 
> to
> some up our decisions and focus on some minor details.
> 
> decisions
> -
> 
> python-kdcproxy will be installed as a dependency of freeipa-server.
> There won't be a separate freeipa-server-kdcproxy package. That may 
> or
> may not change in the future. The decision is out of scope for 4.2.0. 
> [1]
> 
> KDC proxy support will be enabled by default. The config files and 
> LDAP
> settings will be created by ipa-server-install, ipa-server-upgrade 
> and
> ipa-replica-install.
> 
> The enabled/disabled switch will be stored per-replica in the
> cn=masters,cn=ipa,cn=etc tree. An API and CLI tool for management is
> postponed. [2] For now we settle for some doc examples that use the
> ipa-ldap-updater as suggested by Alex. [3]
> 
> 
> open for discussion
> ---
> 
> Jan has suggested to ipaConfigString=kdcProxyEnabled in
> cn=KDC,cn=$FQDN,cn=masters,cn=ipa,cn=etc instead of
> ipaConfigString=enabledService in
> cn=KDCPROXY,cn=$FQDN,cn=masters,cn=ipa,cn=etc. It makes sense to me.
> After all MS-KKDCP is just another transport for the KDC. [4]

There may be a security concern here if we aren't careful. I think I'm
in favor of KDCPROXY since it is a different application.

> Martin Basti suggested a different keytab and principal for kdcproxy.
> [5] The keytab is only required for GSSAPI bind to lookup the state 
> of
> the enabled/disabled switch. The current patch uses the same keytab 
> as
> webgui.
> A new principal separates kdcproxy more cleanly and allows for
> fine-grained ACIs. It is also more future proof.

It may also have auditing benefits now that we are beginning to think
about the A in FreeIPA.

> In the future we may
> want to move kdcproxy from an Apache WSGI app to a separate service. 
> A
> dedicated Twisted or asyncio daemon could handle more load.
> A separate keytab is easy to implement, too. I looked at the code in
> HTTPInstance.__create_http_keytab().

An apache module would also provide similar benefits. I'm not sure I
necessarily want to stick with python here if we're optimizing for
performance. Another option would be to add it to the KDC itself and
proxy through Apache like we do for Tomcat. MIT might like that option.

> For the ACI I plan to add a new permission 'System: Read IPA Config
> String' and make the principal a direct memberOf of it. We don't have
> service roles yet. cn=roles,cn=accounts look like end user roles to 
> me.
> The new ACI in cn=masters,cn=ipa,cn=etc will grant read, search and
> compare permission:
> 
> (targetfilter = "(objectClass=nsContainer)")(targetattr = "cn ||
> objectClass || ipaConfigString")(version 3.0; acl "Read IPA Config
> String"; allow (read, search, compare) groupdn = "ldap:///cn=System:
> Read IPA Config String,cn=permissions,cn=pbac,dc=ipa,dc=example";)
> 
> 
> I should be able to modify and test my patch in a matter of a couple 
> of
> hours.
> 
> Christian
> 
> [1] 
> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00535.html
> [2] 
> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00555.html
> [3] 
> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00533.html
> [4] 
> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00543.html
> [5] 
> http://www.redhat.com/archives/freeipa-devel/2015-May/msg00539.html
> 
> -- 
> 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] KDC proxy implementation specs

[Nathaniel McCallum]

On Thu, 2015-05-28 at 17:07 +0200, Christian Heimes wrote:
> On 2015-05-28 16:48, Nathaniel McCallum wrote:
> > An apache module would also provide similar benefits. I'm not sure 
> > I
> > necessarily want to stick with python here if we're optimizing for
> > performance. Another option would be to add it to the KDC itself 
> > and
> > proxy through Apache like we do for Tomcat. MIT might like that 
> > option.
> 
> For that kind of network code Python is really fast enough. An event
> driven framework like asyncio or Twisted can handle lots of 
> connections
> simultaneous. We aren't speaking about several GBit/sec where zero
> -copy
> is required.
> 
> I'm more worried about Apache than Python. Apache is tuned for the 
> needs
> of the webui, e.g. prefork MPM. Let's see how it works out in a
> production system.

Right. And the KDC could just parse the messages directly.

I agree. Let's wait and see.

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] KDC proxy implementation specs

[Simo Sorce]

On Thu, 2015-05-28 at 17:00 +0200, Christian Heimes wrote:
> On 2015-05-28 16:53, Simo Sorce wrote:
> > We can't have 2 different keytabs with the same principal name.
> > If we need privilege separation we'll have to work on integrating
> > GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands
> > of both the framework, the proxy, and apache itself.
> 
> I had a different principal like KDCPROXY/fqdn@realm in mind.
> 
> > Although to be honest I do not see why the proxy need access to the
> > keytab at all, can we simply run it as a wsgi application under a
> > different user and prevent it from accessing the apache keytab at all ?
> 
> Yes, mod_wsgi is able to run a WSGI app as a different user:
> 
> https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess
> 
> A different user needs another location for the ccache and perhaps
> additional SELinux rules.

If you are using the keytab only to acquire credentials to access ldap
you could use a memory ccache and not have to deal with locations:
KRB5CCNAME=MEMORY:kdcproxy_

> > What do we need the keytab for ?
> > Is it just in order to authenticate and read if the service is enabled ?
> > Can we make that information available anonymously ?
> 
> Yes, the information is not available for anon bind. It doesn't feel
> right to disclose the settings to the public.

Another option is to use ldapi and external auth, I forgot if we allow
automatic binding for no-root users though.

Rob,
do you remember ?

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] KDC proxy implementation specs

[Rob Crittenden]

Simo Sorce wrote:

On Thu, 2015-05-28 at 17:00 +0200, Christian Heimes wrote:

On 2015-05-28 16:53, Simo Sorce wrote:

We can't have 2 different keytabs with the same principal name.
If we need privilege separation we'll have to work on integrating
GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands
of both the framework, the proxy, and apache itself.


I had a different principal like KDCPROXY/fqdn@realm in mind.


Although to be honest I do not see why the proxy need access to the
keytab at all, can we simply run it as a wsgi application under a
different user and prevent it from accessing the apache keytab at all ?


Yes, mod_wsgi is able to run a WSGI app as a different user:

https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess

A different user needs another location for the ccache and perhaps
additional SELinux rules.


If you are using the keytab only to acquire credentials to access ldap
you could use a memory ccache and not have to deal with locations:
KRB5CCNAME=MEMORY:kdcproxy_


What do we need the keytab for ?
Is it just in order to authenticate and read if the service is enabled ?
Can we make that information available anonymously ?


Yes, the information is not available for anon bind. It doesn't feel
right to disclose the settings to the public.


Another option is to use ldapi and external auth, I forgot if we allow
automatic binding for no-root users though.

Rob,
do you remember ?


AFAIK we have no rules other than root -> DM.

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] KDC proxy implementation specs

[Christian Heimes]

On 2015-05-28 17:10, Simo Sorce wrote:
> On Thu, 2015-05-28 at 17:00 +0200, Christian Heimes wrote:
>> On 2015-05-28 16:53, Simo Sorce wrote:
>>> We can't have 2 different keytabs with the same principal name.
>>> If we need privilege separation we'll have to work on integrating
>>> GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands
>>> of both the framework, the proxy, and apache itself.
>>
>> I had a different principal like KDCPROXY/fqdn@realm in mind.
>>
>>> Although to be honest I do not see why the proxy need access to the
>>> keytab at all, can we simply run it as a wsgi application under a
>>> different user and prevent it from accessing the apache keytab at all ?
>>
>> Yes, mod_wsgi is able to run a WSGI app as a different user:
>>
>> https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess
>>
>> A different user needs another location for the ccache and perhaps
>> additional SELinux rules.
> 
> If you are using the keytab only to acquire credentials to access ldap
> you could use a memory ccache and not have to deal with locations:
> KRB5CCNAME=MEMORY:kdcproxy_

Oh nice, I wasn't aware about the MEMORY scheme. Is that supported on
older versions of RHEL, too?

>>> What do we need the keytab for ?
>>> Is it just in order to authenticate and read if the service is enabled ?
>>> Can we make that information available anonymously ?
>>
>> Yes, the information is not available for anon bind. It doesn't feel
>> right to disclose the settings to the public.
> 
> Another option is to use ldapi and external auth, I forgot if we allow
> automatic binding for no-root users though.

No, been there, tried it, failed. It works as root but not as Apache
user or my test user.

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] Domain level for topology plugin = 2

[Ludwig Krispenz]

On 05/28/2015 05:03 PM, Martin Kosek wrote:

On 05/28/2015 04:59 PM, Ludwig Krispenz wrote:

On 05/28/2015 04:46 PM, Simo Sorce wrote:

On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote:

On 05/28/2015 03:26 PM, Simo Sorce wrote:

On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote:

On 28.5.2015 10:49, Martin Kosek wrote:

On 05/28/2015 09:05 AM, Petr Spacek wrote:

On 28.5.2015 08:55, Jan Cholasta wrote:

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?

Good point!


It may be a good point, but it does not make the situation easier. You still
have RHEL/CentOS 6.x IPA out there, where some of them already support
the new
DNS forwarders and some don't - and neither of them support Domain Levels -
i.e. have Domain Level 0.

As I said, I still see more complications with this proposals than
benefits...

I would argue that it actually helps.

If domain level = 1 then we can be *sure* that all replicas support the new
DNS semantics.

If domain level = 0 then we know nothing (because of patched RHEL 6) and
it is
a warning sign for diagnostic tools and also us when it comes to debugging.

First of all  a domain level is something we change *RARELY*, and it is
a whole number and it is an all or nothing thing.

I do not understand why plugin versions matter at all, plugin version
have nothing to do with domain levels. Each plugin *whatever* the
version MUST always support at least 2 levels, because every domain you
have will have to go through a domain_level transition when a new domain
level comes out.

Finally no single developer should be allowed to decide on  anew domain
level, this must be a well ponder team decision as all plugins that need
to change behavior based on domain level will be affected so a thorough
review of what changes are needed across all plugins must be done every
time someone propose a change that requires a domain level bump.

Last but not least we should consider domain levels as something that
changes *very* slowly, because otherwise you'll have to support many
domain levels within any plugins that have to change behavior according
to the domain level.
I would say that the domain level should not change more frequently than
once a year or so. It would be too much code churn to do otherwise.

So for now domain_level should be set to 0. And the topology plugin will
be enabled only when we turn it to 1. However we shouldn't turn it to 1
until we have the replica promotion code at least, because only then we
can make full use of the topology plugins.

The DNS mess is unfixable, unless Petr you volunteer to backport code to
change the behavior of the DNS based on the domain level, if that's the
case then you can tie old behavior to level 0 and new behavior to level

= 1, but I do not think you want to do that given we already have

"level 0" servers that sport the new code and changed the data in the
directory, so let's just ignore DNS for the purpose of this discussion,
except for nothing that once we finally switch to level 1 then all
servers must 

Re: [Freeipa-devel] KDC proxy implementation specs

[Simo Sorce]

On Thu, 2015-05-28 at 17:13 +0200, Christian Heimes wrote:
> On 2015-05-28 17:10, Simo Sorce wrote:
> > On Thu, 2015-05-28 at 17:00 +0200, Christian Heimes wrote:
> >> On 2015-05-28 16:53, Simo Sorce wrote:
> >>> We can't have 2 different keytabs with the same principal name.
> >>> If we need privilege separation we'll have to work on integrating
> >>> GSS-Proxy and give the keytab only to GSS-Proxy leaving it off the hands
> >>> of both the framework, the proxy, and apache itself.
> >>
> >> I had a different principal like KDCPROXY/fqdn@realm in mind.
> >>
> >>> Although to be honest I do not see why the proxy need access to the
> >>> keytab at all, can we simply run it as a wsgi application under a
> >>> different user and prevent it from accessing the apache keytab at all ?
> >>
> >> Yes, mod_wsgi is able to run a WSGI app as a different user:
> >>
> >> https://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess
> >>
> >> A different user needs another location for the ccache and perhaps
> >> additional SELinux rules.
> > 
> > If you are using the keytab only to acquire credentials to access ldap
> > you could use a memory ccache and not have to deal with locations:
> > KRB5CCNAME=MEMORY:kdcproxy_
> 
> Oh nice, I wasn't aware about the MEMORY scheme. Is that supported on
> older versions of RHEL, too?

Yes, it has been there for a long while.

> >>> What do we need the keytab for ?
> >>> Is it just in order to authenticate and read if the service is enabled ?
> >>> Can we make that information available anonymously ?
> >>
> >> Yes, the information is not available for anon bind. It doesn't feel
> >> right to disclose the settings to the public.
> > 
> > Another option is to use ldapi and external auth, I forgot if we allow
> > automatic binding for no-root users though.
> 
> No, been there, tried it, failed. It works as root but not as Apache
> user or my test user.

Maybe we can enable it in cn=config, need to check what's needed, but it
may be worth, if all you need is to read a few entries.

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] Domain level for topology plugin = 2

[Simo Sorce]

On Thu, 2015-05-28 at 17:18 +0200, Ludwig Krispenz wrote:
> On 05/28/2015 05:03 PM, Martin Kosek wrote:
> > On 05/28/2015 04:59 PM, Ludwig Krispenz wrote:
> >> On 05/28/2015 04:46 PM, Simo Sorce wrote:
> >>> On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote:
>  On 05/28/2015 03:26 PM, Simo Sorce wrote:
> > On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote:
> >> On 28.5.2015 10:49, Martin Kosek wrote:
> >>> On 05/28/2015 09:05 AM, Petr Spacek wrote:
>  On 28.5.2015 08:55, Jan Cholasta wrote:
> > 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?
>  Good point!
> 
> >>> It may be a good point, but it does not make the situation easier. 
> >>> You still
> >>> have RHEL/CentOS 6.x IPA out there, where some of them already support
> >>> the new
> >>> DNS forwarders and some don't - and neither of them support Domain 
> >>> Levels -
> >>> i.e. have Domain Level 0.
> >>>
> >>> As I said, I still see more complications with this proposals than
> >>> benefits...
> >> I would argue that it actually helps.
> >>
> >> If domain level = 1 then we can be *sure* that all replicas support 
> >> the new
> >> DNS semantics.
> >>
> >> If domain level = 0 then we know nothing (because of patched RHEL 6) 
> >> and
> >> it is
> >> a warning sign for diagnostic tools and also us when it comes to 
> >> debugging.
> > First of all  a domain level is something we change *RARELY*, and it is
> > a whole number and it is an all or nothing thing.
> >
> > I do not understand why plugin versions matter at all, plugin version
> > have nothing to do with domain levels. Each plugin *whatever* the
> > version MUST always support at least 2 levels, because every domain you
> > have will have to go through a domain_level transition when a new domain
> > level comes o

Re: [Freeipa-devel] Domain level for topology plugin = 2

[Ludwig Krispenz]

On 05/28/2015 05:35 PM, Simo Sorce wrote:

On Thu, 2015-05-28 at 17:18 +0200, Ludwig Krispenz wrote:

On 05/28/2015 05:03 PM, Martin Kosek wrote:

On 05/28/2015 04:59 PM, Ludwig Krispenz wrote:

On 05/28/2015 04:46 PM, Simo Sorce wrote:

On Thu, 2015-05-28 at 15:54 +0200, Ludwig Krispenz wrote:

On 05/28/2015 03:26 PM, Simo Sorce wrote:

On Thu, 2015-05-28 at 14:11 +0200, Petr Spacek wrote:

On 28.5.2015 10:49, Martin Kosek wrote:

On 05/28/2015 09:05 AM, Petr Spacek wrote:

On 28.5.2015 08:55, Jan Cholasta wrote:

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?

Good point!


It may be a good point, but it does not make the situation easier. You still
have RHEL/CentOS 6.x IPA out there, where some of them already support
the new
DNS forwarders and some don't - and neither of them support Domain Levels -
i.e. have Domain Level 0.

As I said, I still see more complications with this proposals than
benefits...

I would argue that it actually helps.

If domain level = 1 then we can be *sure* that all replicas support the new
DNS semantics.

If domain level = 0 then we know nothing (because of patched RHEL 6) and
it is
a warning sign for diagnostic tools and also us when it comes to debugging.

First of all  a domain level is something we change *RARELY*, and it is
a whole number and it is an all or nothing thing.

I do not understand why plugin versions matter at all, plugin version
have nothing to do with domain levels. Each plugin *whatever* the
version MUST always support at least 2 levels, because every domain you
have will have to go through a domain_level transition when a new domain
level comes out.

Finally no single developer should be allowed to decide on  anew domain
level, this must be a well ponder team decision as all plugins that need
to change behavior based on domain level will be affected so a thorough
review of what changes are needed across all plugins must be done every
time someone propose a change that requires a domain level bump.

Last but not least we should consider domain levels as something that
changes *very* slowly, because otherwise you'll have to support many
domain levels within any plugins that have to change behavior according
to the domain level.
I would say that the domain level should not change more frequently than
once a year or so. It would be too much code churn to do otherwise.

So for now domain_level should be set to 0. And the topology plugin will
be enabled only when we turn it to 1. However we shouldn't turn it to 1
until we have the replica promotion code at least, because only then we
can make full use of the topology plugins.

The DNS mess is unfixable, unless Petr you volunteer to backport code to
change the behavior of the DNS based on the domain level, if that's the
case then you can tie old behavior to level 0 and new behavior to level

= 1, but I do not think you want to do that given we already have

"level 0" servers that sport the new code and changed the data in the
directory, so let's just ignore DNS for the purpos