from:"Alexander Bokovoy"

On ke, 01 maalis 2017, Simo Sorce wrote:

> My take is: cut API/UI work, and do the underlying infrastructure work
> for the widest set of serves/clients possible instead.
>
> It is much more important to get the underlying gears done than to add
> UI candy, that can be delayed.
>
> Simo.
>

I agree, we just have to come to agreement of *which* gears are really
necessary.

Indeed, but adding attributes to ipaConfig and the ID Views is not hard,
it is a matter of extending two objectclasses instead of one ... if we
decide that Id Views are a good abstraction point.

Adding the same attribute to ID View and to ipaConfig sounds logical to
me.

Martin, if you want help with this, I can implement ID View-related
parts. SSSD does have code to retrieve ipaConfig already, and it also
has support for reading ID View associated with the host. The resulting
value wouldn't end up in the same place, though, but this is something
to handle on SSSD side.

--
/ 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] Please review: V4/AD user short names design draft


On ke, 01 maalis 2017, Jan Cholasta wrote:

On 1.3.2017 14:05, Alexander Bokovoy wrote:

On ke, 01 maalis 2017, Jan Cholasta wrote:

On 1.3.2017 13:39, Martin Babinsky wrote:

Alexander,

thank you for your comments. Replies inline:

On 02/28/2017 01:48 PM, Alexander Bokovoy wrote:

On ti, 28 helmi 2017, Martin Babinsky wrote:

Hello list,

I have put together a draft of design page describing server-side
implementation of user short name -> fully-qualified name
resolution.[1]

In the end I have taken the liberty to change a few aspects of the
design we have agreed on before and I will be grad if we can discuss
them further.

Me and Honza have discussed the object that should hold the domain
resolution order and given the fact that IPA domain can also be a part
of this list, we have decided that this information is no longer bound
to trust configuration and should be a part of the global config
instead.

Also we have purposefully cut down the API only to a raw manipulation
of the attribute using an option of `ipa config-mod`. The reasons for
this are twofold:

* the developer resources are quite scarce and it may be good to
follow YAGNI[2] principle to implement the dumbest API now and not to
invest into more high-level interface unless there is a demand for it

* we can imagine that the manipulation of the domain resolution order
is a rare operation (ideally only once all trusts are established), so
I am not convinced that it is worth investing into designing
higher-level API

I propose we first develop the "dumber" parts first to unblock the
SSSD part. If we have spare cycle afterwards then we can design and
implement more bells-and-whistles afterwards.

Looks mostly OK, but there are few comments I have:

- I do not see you mention how validation of the
ipaDomainResolutionOrder is done. This is important to avoid hard to
debug issues because SSSD will ignore domains it doesn't know about.



The validation is described in a Design section as follows:

"""
Finally, any modification of the domain resolution order must ensure
that each of the specified domain names corresponds either to that of
FreeIPA domain or to one of the trusted AD domains stored in LDAP
backend. In the case of trusted domains, the domain must not be marked
as disabled.
"""

Is this sufficient or is a more thorough validation required? Shall I
split the whole section into sub-sections for easier navigation?


- Space separator initially caused me to look up DNS RFCs as strictly
speaking domain names can contain any 8-bit octet (while host names
should follow LDH rule). But then [1] does explicitly say space is not
allowed in AD domain names.



I have discussed this with Jan and consulted the same document that you
cited, that's why I have arrived to the conclusion to use whitespace as
separator. Jakub/Fabiano, is this ok with the way SSSD decodes domain
names or should we consider other options to avoid breakage with more
exotic domain names?


Actually I would prefer something else than whitespace as a separator.
A ':' maybe?

or ',' or ';'. Any would work.


I have considered a empty attribute value to be a distinct state from
the missing attribute and assigned a different semantic meaning to it.

The reasoning is as follows: if the attribute is not set, SSSD will not
retrieve it and this signals that it should continue operate in usual
way.

If the attribute is present but is empty, the semantics change slightly
as now we consider *no* domains during short name resolution (extension
of the missing domain behavior to the case of all domains are missing
from list).


It doesn't have to be literally empty (LDAP character string syntaxes
don't allow it anyway IIRC), there can be a value which denotes an
empty list of domain (e.g. the separator alone).

I don't see *why* there should be this distinction. The deciding party
is SSSD. Whether this attirbute exists and empty or does not exist at
all does not change anything. Changing how SSSD interprets own defaults
depending on absense or emptiness of certain attribute in IPA config
object is not user friendly at all.

SSSD default behavior should stay the same whether it finds missing or
empty attribute because the attribute will not be known to older SSSD
anyway. Missing or empty attribute should, in my opinion, be equal to
older SSSD behavior.



"No value is set in configuration => use built-in default / some value 
is set configuration => use the value" is perfectly user friendly and 
pretty much common virtually everywhere I believe, much more so than 
"empty value is set in configuration => ignore the value even if the 
user deliberately set it empty and use the default value instead".

I'm not arguing with "no value is set in configuration -> use built-in
default". I do argue on having empty but present attribute because it
does not add anything useful for SSSD to decide on. And as it is not

Re: [Freeipa-devel] Please review: V4/AD user short names design draft


On ke, 01 maalis 2017, Martin Babinsky wrote:

Alexander,

thank you for your comments. Replies inline:

On 02/28/2017 01:48 PM, Alexander Bokovoy wrote:

On ti, 28 helmi 2017, Martin Babinsky wrote:

Hello list,

I have put together a draft of design page describing server-side
implementation of user short name -> fully-qualified name resolution.[1]

In the end I have taken the liberty to change a few aspects of the
design we have agreed on before and I will be grad if we can discuss
them further.

Me and Honza have discussed the object that should hold the domain
resolution order and given the fact that IPA domain can also be a part
of this list, we have decided that this information is no longer bound
to trust configuration and should be a part of the global config instead.

Also we have purposefully cut down the API only to a raw manipulation
of the attribute using an option of `ipa config-mod`. The reasons for
this are twofold:

* the developer resources are quite scarce and it may be good to
follow YAGNI[2] principle to implement the dumbest API now and not to
invest into more high-level interface unless there is a demand for it

* we can imagine that the manipulation of the domain resolution order
is a rare operation (ideally only once all trusts are established), so
I am not convinced that it is worth investing into designing
higher-level API

I propose we first develop the "dumber" parts first to unblock the
SSSD part. If we have spare cycle afterwards then we can design and
implement more bells-and-whistles afterwards.

Looks mostly OK, but there are few comments I have:

- I do not see you mention how validation of the
ipaDomainResolutionOrder is done. This is important to avoid hard to
debug issues because SSSD will ignore domains it doesn't know about.



The validation is described in a Design section as follows:

"""
Finally, any modification of the domain resolution order must ensure 
that each of the specified domain names corresponds either to that of 
FreeIPA domain or to one of the trusted AD domains stored in LDAP 
backend. In the case of trusted domains, the domain must not be marked 
as disabled.

"""

Is this sufficient or is a more thorough validation required? Shall I 
split the whole section into sub-sections for easier navigation?

I think it would be good to increase visibility by making subsections.

However, I'd like to spell it out that trusted forest root domain is
also verified on the list. We have trusts structured hierarchically,
this means both levels have to be checked.


- Space separator initially caused me to look up DNS RFCs as strictly
speaking domain names can contain any 8-bit octet (while host names
should follow LDH rule). But then [1] does explicitly say space is not
allowed in AD domain names.



I have discussed this with Jan and consulted the same document that 
you cited, that's why I have arrived to the conclusion to use 
whitespace as separator. Jakub/Fabiano, is this ok with the way SSSD 
decodes domain names or should we consider other options to avoid 
breakage with more exotic domain names?



- "If ipaDomainResolutionOrder is empty then *all* users must use fully
qualified names." This is not correct with regards to the current
behavior. I think we should change this to "if
ipaDomainResolutionOrder is empty, then standard SSSD configuration
logic applies on each client." This would make current behavior
compatible with either empty or ipaDomainResolutionOrder value of
a single IPA domain name.



I have considered a empty attribute value to be a distinct state from 
the missing attribute and assigned a different semantic meaning to it.


The reasoning is as follows: if the attribute is not set, SSSD will 
not retrieve it and this signals that it should continue operate in 
usual way.


If the attribute is present but is empty, the semantics change 
slightly as now we consider *no* domains during short name resolution 
(extension of the missing domain behavior to the case of all domains 
are missing from list).

I'd rather avoid making this distinction. You always can override things
on SSSD side and default on SSSD side is to *not* use fully qualified
domain names for a domain.

I don't think we have any use case of having all domains with fully
qualified names. Even in case of NFS and sss_rpcidmapd, SSSD will
happily handle both non-fully qualified names and fully qualified ones.

--
/ 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] Please review: V4/AD user short names design draft


On ke, 01 maalis 2017, David Kupka wrote:

On Tue, Feb 28, 2017 at 02:48:02PM +0200, Alexander Bokovoy wrote:

On ti, 28 helmi 2017, Martin Babinsky wrote:
> Hello list,
>
> I have put together a draft of design page describing server-side
> implementation of user short name -> fully-qualified name resolution.[1]
>
> In the end I have taken the liberty to change a few aspects of the
> design we have agreed on before and I will be grad if we can discuss
> them further.
>
> Me and Honza have discussed the object that should hold the domain
> resolution order and given the fact that IPA domain can also be a part
> of this list, we have decided that this information is no longer bound
> to trust configuration and should be a part of the global config
> instead.
>
> Also we have purposefully cut down the API only to a raw manipulation of
> the attribute using an option of `ipa config-mod`. The reasons for this
> are twofold:
>
>  * the developer resources are quite scarce and it may be good to follow
> YAGNI[2] principle to implement the dumbest API now and not to invest
> into more high-level interface unless there is a demand for it
>
>  * we can imagine that the manipulation of the domain resolution order
> is a rare operation (ideally only once all trusts are established), so I
> am not convinced that it is worth investing into designing higher-level
> API
>
> I propose we first develop the "dumber" parts first to unblock the SSSD
> part. If we have spare cycle afterwards then we can design and implement
> more bells-and-whistles afterwards.
Looks mostly OK, but there are few comments I have:

- I do not see you mention how validation of the
 ipaDomainResolutionOrder is done. This is important to avoid hard to
 debug issues because SSSD will ignore domains it doesn't know about.

- Space separator initially caused me to look up DNS RFCs as strictly
 speaking domain names can contain any 8-bit octet (while host names
 should follow LDH rule). But then [1] does explicitly say space is not
 allowed in AD domain names.

- "If ipaDomainResolutionOrder is empty then *all* users must use fully
 qualified names." This is not correct with regards to the current
 behavior. I think we should change this to "if
 ipaDomainResolutionOrder is empty, then standard SSSD configuration
 logic applies on each client." This would make current behavior
 compatible with either empty or ipaDomainResolutionOrder value of
 a single IPA domain name.


Would it make sense to add ipaDomainResolutionOrder attribute during upgrade
with the FreeIPA domain and have the behavior as proposed? That would ensure
that users will be resolved the same way as before unless someone changes the
attribute.

I'm not sure it changes anything. Newer SSSD still needs to handle cases when
talking to servers which has no ipaDomainResolutionOrder attribute so
they would treat missing attribute the same way which means we don't
need to handle upgrade 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] Please review: V4/AD user short names design draft

2017-02-28 Thread Alexander Bokovoy


On ti, 28 helmi 2017, Martin Babinsky wrote:

Hello list,

I have put together a draft of design page describing server-side 
implementation of user short name -> fully-qualified name 
resolution.[1]


In the end I have taken the liberty to change a few aspects of the 
design we have agreed on before and I will be grad if we can discuss 
them further.


Me and Honza have discussed the object that should hold the domain 
resolution order and given the fact that IPA domain can also be a part 
of this list, we have decided that this information is no longer bound 
to trust configuration and should be a part of the global config 
instead.


Also we have purposefully cut down the API only to a raw manipulation 
of the attribute using an option of `ipa config-mod`. The reasons for 
this are twofold:


 * the developer resources are quite scarce and it may be good to 
follow YAGNI[2] principle to implement the dumbest API now and not to 
invest into more high-level interface unless there is a demand for it


 * we can imagine that the manipulation of the domain resolution 
order is a rare operation (ideally only once all trusts are 
established), so I am not convinced that it is worth investing into 
designing higher-level API


I propose we first develop the "dumber" parts first to unblock the 
SSSD part. If we have spare cycle afterwards then we can design and 
implement more bells-and-whistles afterwards.

Looks mostly OK, but there are few comments I have:

- I do not see you mention how validation of the
 ipaDomainResolutionOrder is done. This is important to avoid hard to
 debug issues because SSSD will ignore domains it doesn't know about.

- Space separator initially caused me to look up DNS RFCs as strictly
 speaking domain names can contain any 8-bit octet (while host names
 should follow LDH rule). But then [1] does explicitly say space is not
 allowed in AD domain names.

- "If ipaDomainResolutionOrder is empty then *all* users must use fully
 qualified names." This is not correct with regards to the current
 behavior. I think we should change this to "if
 ipaDomainResolutionOrder is empty, then standard SSSD configuration
 logic applies on each client." This would make current behavior
 compatible with either empty or ipaDomainResolutionOrder value of
 a single IPA domain name.

- There are typos in the page.

[1] 
https://support.microsoft.com/en-us/help/909264/naming-conventions-in-active-directory-for-computers,-domains,-sites,-and-ous


--
/ 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] python-ipaserver & freeipa-server-trust-ad split

2017-02-20 Thread Alexander Bokovoy


On la, 18 helmi 2017, Timo Aaltonen wrote:


Hi,

So Fedora puts all of dist-packages/ipaserver/* in python-ipaserver,
but dcerpc.py imports python-samba which -ipaserver does not depend on.
So I've kept dcerpc.py and adtrustinstance.py in freeipa-server-trust-ad
on Debian, but now with 4.4.3 (because of fd8c17252fbc) it seems that
ipa-server-install wants to import adtrustinstance and fails to run if
it's not installed.

Traceback (most recent call last):
 File "/usr/sbin/ipa-server-install", line 25, in 
   from ipaserver.install.server import Server
 File
"/usr/lib/python2.7/dist-packages/ipaserver/install/server/__init__.py",
line 8, in 
   from .upgrade import upgrade_check, upgrade
 File
"/usr/lib/python2.7/dist-packages/ipaserver/install/server/upgrade.py",
line 49, in 
   from ipaserver.install import adtrustinstance
ImportError: cannot import name adtrustinstance


So what to do here? I can't remember exactly what problems I hit when
everything was in python-ipaserver while testing 4.3.0, but I think they
were about the samba stuff.. and don't want to test again without asking
first. Should the upgrader stuff be split?

I think we simply can move ipa_smb_conf_exists() to ipapython or ipalib.
It only needs to read a config file and check a signature. Signature could be
moved to constants. Then ipa_smb_conf_exists() can be imported in both
upgrade tool and in adtrustinstance.

Want to make a PR?
--
/ 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] FreeIPA and wildcard certificates

2017-02-08 Thread Alexander Bokovoy

On to, 09 helmi 2017, Fraser Tweedale wrote:

On Wed, Feb 08, 2017 at 10:19:54AM +0200, Alexander Bokovoy wrote:

On ke, 08 helmi 2017, Martin Kosek wrote:
> Hi Fraser and the list,
>
> I recently was in a conversation about integrating OpenShift with FreeIPA. One
> of the gaps was around generating a wildcard certificate by FreeIPA that will
> be used in the default OpenShift router for applications that do not deploy 
own
> certificates [1].
>
> Is there any way that FreeIPA can generate it? I was thinking that uploading
> some custom certificate profile in FreeIPA may let us get such certificate...
> Or is the the only way we can add it by adding a new RFE in FreeIPA, tracked 
in
> [2]?
Yes, we need a new RFE. There are checks in IPA that prevent wildcard
certificates to be issued:

- we ensure subject 'cn' of the certificate matches a Kerberos principal
  specified in the request

- we validate that host object exists in IPA when the Kerberos
  principal is host/...

We could lift off these two limitations for 'cn=*,$suffix' but there is
still a need to apply proper ACLs when issuing the cert -- e.g. some
object has to be used for performing access rights check. The wildcard
certificate does not need to be stored anywhere in the tree, but a
check still needs to be done.

For example, for Kerberos PKINIT certificate which is issued to KDC we
don't store public certificate in LDAP either but we do two checks:
- a special KDC certificate profile is used to issue the cert
- a special hostname check is done so that only IPA masters are able to
  request this certificate

For the wildcard certificate I think we could have following:
- use a separate profile for the wildcard, associated with a sub-CA
- hardcode CN default in the profile to always be 'CN=*, O=$SUB_CA_SUBJECT' so 
that
  actual certificate ignores requested CN.
- a special check to be done so that only wildcard-based subject
  alternative names can be added to a wildcard certificate request
- all Kerberos principal / hostname checks are skipped.
- actual ACL check is done by CA ACL.

Issuing wildcard certs is a deprecated practice[1].  I am not
dismissing the needs of OpenShift (or PaaS/IaaS solutions in
general) but I'd like to have a discussion with them about how
they're currently dealing with certs and whether a different
direction other than wildcard certs is feasible.  Martin, who should
I reach out to?  Feel free to copy them into this discussion.

[1] https://tools.ietf.org/html/rfc6125#section-7.2

While it is not recommended to issue wildcard certificates, it is far
from being a deprecated practice. In fact, almost all commercial CAs do
have wildcard certificate product in their portfolio. We also have seen
customers coming to use FreeIPA with wildcard certificates issued by
external CAs. This practice is not going to disappear. 

If we do go ahead with wildcard cert support in FreeIPA, some of my
initial questions are:

- For the OpenShift use case, what is the "parent" domain name and
 is it the same as the IPA domain name?  Is it a subdomain of the
 IPA domain name?

- Do we need to support issuing "*.${IPA_DOMAIN}"? i.e. wildcard
 cert under entire IPA domain name.

- Do we need to support issuing "*.${IPA_HOSTNAME}"?  i.e. wildcard
 certs under names of IPA host principals.

Another question would be:

- Do we need to support issuing "hostname.*.${IPA_DOMAIN}"? I.e.
 wildcard cert where a '*' character is not a leftmost label.

--
/ 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] FreeIPA and wildcard certificates

2017-02-08 Thread Alexander Bokovoy


On ke, 08 helmi 2017, Martin Kosek wrote:

Hi Fraser and the list,

I recently was in a conversation about integrating OpenShift with FreeIPA. One
of the gaps was around generating a wildcard certificate by FreeIPA that will
be used in the default OpenShift router for applications that do not deploy own
certificates [1].

Is there any way that FreeIPA can generate it? I was thinking that uploading
some custom certificate profile in FreeIPA may let us get such certificate...
Or is the the only way we can add it by adding a new RFE in FreeIPA, tracked in
[2]?

Yes, we need a new RFE. There are checks in IPA that prevent wildcard
certificates to be issued:

- we ensure subject 'cn' of the certificate matches a Kerberos principal
  specified in the request

- we validate that host object exists in IPA when the Kerberos
  principal is host/...

We could lift off these two limitations for 'cn=*,$suffix' but there is
still a need to apply proper ACLs when issuing the cert -- e.g. some
object has to be used for performing access rights check. The wildcard
certificate does not need to be stored anywhere in the tree, but a
check still needs to be done.

For example, for Kerberos PKINIT certificate which is issued to KDC we
don't store public certificate in LDAP either but we do two checks:
- a special KDC certificate profile is used to issue the cert
- a special hostname check is done so that only IPA masters are able to
  request this certificate

For the wildcard certificate I think we could have following:
- use a separate profile for the wildcard, associated with a sub-CA
- hardcode CN default in the profile to always be 'CN=*, O=$SUB_CA_SUBJECT' so 
that
  actual certificate ignores requested CN.
- a special check to be done so that only wildcard-based subject
  alternative names can be added to a wildcard certificate request
- all Kerberos principal / hostname checks are skipped.
- actual ACL check is done by CA ACL.

--
/ 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] [DESIGN] Dogtag GSS-API Authentication

2017-02-06 Thread Alexander Bokovoy


On ma, 06 helmi 2017, Jan Cholasta wrote:

On 11.1.2017 02:09, Fraser Tweedale wrote:

On Tue, Jan 10, 2017 at 10:48:08AM +0100, Martin Babinsky wrote:

Hi Fraser,

I have some rather inane comments. I guess Jan cholasta will do a more
thorough review of your design. See below:

On 01/06/2017 09:08 AM, Fraser Tweedale wrote:

Hi comrades,

I have written up the high-level details of the FreeIPA->Dogtag
GSS-API authentication design.  The goal is improve security by
removing an egregious privilege separation violation: the RA Agent
cert.

There is a fair bit of work still to do on the Dogtag side but
things are shaping up there and it's time to work out the IPA
aspects.  The design is at:

 http://www.freeipa.org/page/V4/Dogtag_GSS-API_Authentication


first of all, you link a internal document from publicly available design
page. you should prepare a publicly visible version of the Dogtag-side
design and link that.


Will do; thanks.


It would also be nice to have a high-level graphical representation of the
proposed CSR processing workflow. I think you can re-use the one that is in
the Dogtag part, omit the Dogtag internals and add IPA-specific parts.


I will definitely do this a bit later, once more details of IPA
design are established.



Right now, I need feedback about the Domain Level aspects: whether
it is the right approach, whether there are mechanisms to perform
update steps (specifically: LDAP updates and/or api calls) alongside
a DL bump, or if there aren't, how to deal with that (implement such
a mechanism, make admins do extra steps, ???).



Is the DL bump really necessary? Are you sure we really can not just update
the profile configuration and let older Dogtag installation handle it
gracefully? IIRC we have done some profile inclusion work in 4.2 development
and on and never really bothered about older Dogtag understanding them.


The problem is that the new profiles will refer to plugins (i.e.
classes) that do not exist in older versions of Dogtag.  Profile
config is replicated, so if we upgrade profile config with old
versions of Dogtag in the topology, it breaks them.

I considered a mechanism where multiple versions of a profile exist
in LDAP (i.e. multiple attribute values), and Dogtag picks the one
that's "right" for it.  (An example of how to do this might be
attribute tagging where tag indicates minimum version of Dogtag
containing components used in that profile version, and Dogag picks
the highest that it supports).  The advantage of such a mechanism is
that we could use it for any future scenario where we introduce new
profile components that we want to use in IPA.  The downside is that
it significantly complicates profile management (including for
administrators), and can result in the same profile having different
behaviour on different Dogtag instances, which could be confusing
and make it harder to diagnose issues.  Given the tradeoffs, I think
a DL bump is preferable.


I don't like the prospect of having to bump DL every time a new 
component is introduced. This time it might be OK, because the new DL 
is apparently required for the RA -> GSSAPI change, but IMHO in 
general a change in a certificate profile does not warrant a DL bump.


I agree that maintaining multiple versions of a profile is not the way 
to go, but I think there are other options:


* Change `auth.instance_id` from `raCertAuth` to a new, IPA-specific 
`ipaAuth`. Configure `auths.instance.ipaAuth` in CS.cfg to behave 
exactly the same as `raCertAuth`. This will have to be done on all 
masters, including old ones, which can receive the change in a bug fix 
update (4.4.x). Then, on upgrade to new IPA with GSSAPI enabled 
Dogtag, change `auths.instance.ipaAuth` to use external script for 
authentication. Similar thing could be done for other profile 
components.


* Do not care about old masters. Update the profile and let 
certificate requests on old masters fail. This should be fine, as the 
situation where there are different version masters should be only 
temporary until all masters are upgraded. If an appropriate error is 
returned from cert-request, automated requests via certmonger will be 
re-attempted and will succeed once all masters are upgraded.

I'd prefer an option number one. Using an IPA-specific auth instance
would allow us to be more flexible in manipulating the properties of it
in future without worrying to break older setups. 


--
/ 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] [design] add nsupdate output format to dns-update-system-records

2017-01-27 Thread Alexander Bokovoy

Top post (sorry). 

Is suggest use --out option and document that it writes nsupdate-compatible 
content.



- Martin Basti <mba...@redhat.com> wrote:
> Hello all,
> 
> I'm working on adding support of nsupdate format to output of `ipa 
> dns-update-system-records` command, that will allow to copy output 
> to nsupdate utility and update IPA DNS records on external server. I 
> propose following:
> 
> 1) new option --nsupdate-format
> 
> This option will replace standard output with nsupdate format output. 
> Feel free to propose better name.
> 
> 
> 2) client or server side plugin?
> 
> I'd like to implement this behavior only at client side. But this will 
> not work in cases when only server api or RPC calls are used. Do you 
> think that we should support this uses case (in server side plugin)?
> 
> 
> 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

-- 
/ 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] Stageuser API

2017-01-17 Thread Alexander Bokovoy


On ti, 17 tammi 2017, Christian Heimes wrote:

On 2017-01-17 12:56, David Kupka wrote:

Hi Christian,
uniqueness of uid is not checked in staging area on purpose, it may be
changed multiple times before the stageuser is transformed into user
(activated). The uid uniqueness is then checked during activation.

Third party application that use FreeIPA's LDAP should:
1) search for users (and usercertificate attribute) only in
cn=users,cn=accounts
2) respect the value of nsAccountLock that is set to true for all staged
users.

But it would be nice to have this scenario (stageuser.uid == user.uid)
implemented as a part of [1].


Can we safely assume that all parts of FreeIPA, Kerberos and all 3rd
party application *always* use the FreeIPA API or LDAP to validate a
user cert? Some applications may just validate the certificate and
OCSP/CRL for client cert authentication with e.g. mod_ssl.

Consider this scenario:

1) IT issues a smart card for a staging user. The smart card contains a
valid private/public key pair for FreeIPA.
2) HR sends the smart card to a new hire.
3) HR creates a standard user with same login as staging user
4) New hire uses the smart card to log into a system that only verifies
validity of cert (signature, dates, OCSP status) and uses subject to
identify user.

The certificate validity for a future users should have
validity.notBefore property set.  A login before that time should not be
possible with systems like (4) describes.


Even if we 'fix' the issue with non-unique UIDs in staging, it stays
dangerous to hand a valid certificate to a not-yet-valid user. At least
we should try to reduce risks with a couple of measures:

* Add a "valid from" field to stage users and set the cert's valid from
date accordingly. That renders the public key useless until the
estimated first day on the job.

According to RFC 3280, validity is the mandatory part of the x.509
certificate. Granted, certmonger does not allow you to set
validity.notBefore to some externally defined value, but this is
something we could implement. You can already achieve that with your own
certificate signing request. And it this case we deal with externally
provided user certificates, so we could have no ability to influence
what happens at all.


* Lock the smart card with a PIN and don't release the PIN until the
user has been moved from staging area to user area. This arrangement
makes the smart card inaccessible. We could use the KRA to store the PIN.

This is just a process, not a technical solution. Someone needs to
communicate PIN separate to the smartcard to a new hire anyway.


--
/ 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] Stageuser API

2017-01-17 Thread Alexander Bokovoy


On ti, 17 tammi 2017, Martin Basti wrote:



On 17.01.2017 12:38, Christian Heimes wrote:

On 2017-01-16 15:52, David Kupka wrote:

Hello everyone!

I've noticed that our API for stageuser is missing some commands that
user has (stageuser-{add,remove}-{principal,cert}). I was wondering if
there is reason for it but after asking some fellows developers it seems
that there's none.

I understand the stageuser area as a place where user entry can be
created and amended during the hiring process in organization, example:

1. HR creates the entry with just basic informations (givenname,
surname, manager)
2. IT assigns basic account information (uid, gid)
3. based on to-be-employee manager's request IT adds additional group
membership (memberOf)
4. based on to-be-employee request IT adds login alias (krbPrincipalName)
5. Security Officer adds certificate from Smart Card assigned to the
to-be-employee
6. HR adds extra information to the account (address, marital status, ...)
7. Facilities update work place related information (seat number, phone
number, ...)
8. At the first day IT activates the user account.

Considering this work flow I think it might be useful to have the same
API for stageuser as for the user.

Does the example work flow make sense?
Should we provide the same set of commands for user and stageuser?

I see one potential issue in your proposal. A stage user does not
reserve its user name. The unique index on uid excludes the staging user
and deleted user branch. Therefore it is possible to create a user with
the same login name as a staging user.

We either have to ensure that this name clash does not cause any trouble
with certificates or we have to enforce uniqueness of uid across the
whole tree. For FreeIPA it's probably fine because we compare certs
bytes. Third party applications parse the cert subject instead and use
the subject to identify a user.

Christian





AFAIK the non-uniques of stageuser and user names causes more pain 
than gain, this is not the first case when we have an issue with that. 
Maybe we should reevaluate this behavior and enforce uid uniqueness 
with stageusers too.


Note: we explicitly updated uniqueness plugin to allow conflicting 
names but I don't remember the reason from top of my head.

There might be workflows where an existing normal user would be deleted
and a new but completely separate stageuser would be promoted to a
normal one, both having the same name over an overlapping period of time.
In this case non-uniqueness requirement is needed.

This is a fairly common situation for English-speaking countries with
rather short common surnames and a typical username built out of a
first name + surname combination.



--
/ 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] Stageuser API

2017-01-17 Thread Alexander Bokovoy


On ti, 17 tammi 2017, Florence Blanc-Renaud wrote:

On 01/16/2017 03:52 PM, David Kupka wrote:

Hello everyone!

I've noticed that our API for stageuser is missing some commands that
user has (stageuser-{add,remove}-{principal,cert}). I was wondering if
there is reason for it but after asking some fellows developers it seems
that there's none.

I understand the stageuser area as a place where user entry can be
created and amended during the hiring process in organization, example:

1. HR creates the entry with just basic informations (givenname,
surname, manager)
2. IT assigns basic account information (uid, gid)
3. based on to-be-employee manager's request IT adds additional group
membership (memberOf)
4. based on to-be-employee request IT adds login alias (krbPrincipalName)
5. Security Officer adds certificate from Smart Card assigned to the
to-be-employee
6. HR adds extra information to the account (address, marital status, ...)
7. Facilities update work place related information (seat number, phone
number, ...)
8. At the first day IT activates the user account.

Considering this work flow I think it might be useful to have the same
API for stageuser as for the user.

Does the example work flow make sense?
Should we provide the same set of commands for user and stageuser?

Thanks for your ideas and opinions!

Hi David,

I would be in favor of providing the same API for stageuser and user.

It is already possible to add a certificate or a principal alias to a 
stageuser with ipa stageuser-mod --cert or ipa stageuser-mod 
--principal, meaning that those operations are not forbidden.


I also checked that a stageuser
- is not able to perform kinit with any of his principal aliases
- is not able to authenticate to the LDAP server with a DN/pwd
- is not able to authenticate to the LDAP server using his SSL cert
- is not able to login with user/pwd on a client console
so I do not see any security concern with your proposal.

Thank you, Flo. Let's then proceed with the David's proposal.

For the record, we discussed this proposal on a weekly development call
and I raised the questions about authentication above. Florence
volunteered to experiment with it to see if SSL certificate
authentication would be possible. It is not, so we can unify the API
behind both user and stageuser.


--
/ 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] [DESIGN] FreeIPA on FIPS + NSS question

2017-01-12 Thread Alexander Bokovoy


On to, 12 tammi 2017, Christian Heimes wrote:

On 2016-12-19 15:07, John Dennis wrote:

I'm not a big fan of NSS, it has it's issues. As the author of the
Python binding I'm quite aware of all the nasty behaviors NSS has and
needs to be worked around. I wouldn't be sad to see it go but OpenSSL
has it's own issues too. If you remove NSS you're also removing the
option to support smart cards, HSM's etc. Perhaps before removing
functionality it would be good to assess what the requirements are.


When Standa started to work on the PR, I raised similar concerns
regarding the feature set of OpenSSL. I asked him to write a design spec
to address some of the concerns.

HSM and smart card authentication are of no concern. Standa's PR
replaces FreeIPA's internal HTTS connection with a OpenSSL based
implementation. It's used to communicate from an IPA client to an IPA
server or from an IPA server to Dogtag. We don't support client cert
auth for client to server. Smart card authentication is performed based
on pkinit and Kerberos. Currently just IPA server to Dogtag uses client
cert authentication. That part will be replaced with GSSAPI eventually.

We are adding client cert authentication in 4.5. This is pretty big part
of the release, actually, as we are getting external authentication and
privilege separation support. See Simo's PR#314 which is very close to
be merged.

We don't plan yet to use this for IPA client itself, but nothing prevent
clients other than web browsers to utilize client cert auth to establish
TLS session authentication. In fact, this is something which most likely
will be used for external entities anyway.



I'm more concerned that we loose the ability to check revocation state
of certificates. Python's ssl module has no support for OCSP. OpenSSL's
and Python's CRL capabilities are sub-par compared to NSS. The ssl
module can load CRLs but it has no means to retrieve or update a CRL
from a remote server.

For Fedora 26 we will have to deal with similar concerns for libldap.
Fedora has switched from NSS to OpenSSL as TLS backend.

Christian







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



--
/ 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] require n out of m keys/users to authenticate an ssh session?

2016-12-19 Thread Alexander Bokovoy


On ma, 19 joulu 2016, Oucema Bellagha wrote:

Hi folks,


Thanks for the feedback, I already tried the AuthenticationMethods
"publickey,publickey" but is there any tool allowing this kind of
connection from two clients to the server in the same time using
ssh-Key cause it's not possible using putty ..

No, as I said, it is not designed in the SSH protocol

P.S. Answer to the list, not personally.




Cheers,


____
From: Alexander Bokovoy <aboko...@redhat.com>
Sent: Monday, December 19, 2016 9:06:51 AM
To: Oucema Bellagha
Cc: freeipa-devel@redhat.com
Subject: Re: [Freeipa-devel] require n out of m keys/users to authenticate an 
ssh session?

On ma, 19 joulu 2016, Oucema Bellagha wrote:

I'm looking for an option - eventually to extend standard ssh - in such
a way that I need (at least) two people/keys out of m possible to
authenticate a session instead of one out of m known once...

e.g:
to authenticate to server X : I need two people A and (B or C) together.

anyone seen this or know how to do?

I know there is key + password (which is kind of this direction) but
not exactly what I'm looking for...

You can use the very same directive AuthenticationMethods to ask for
multiple keys too.

  AuthenticationMethods "publickey,publickey,publickey"

would require three different public keys to authenticate.

However, there is nothing in SSH protocol that would enforce different
people to be involved at the client side.
--
/ Alexander Bokovoy


--
/ 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] require n out of m keys/users to authenticate an ssh session?

2016-12-19 Thread Alexander Bokovoy


On ma, 19 joulu 2016, Oucema Bellagha wrote:

I'm looking for an option - eventually to extend standard ssh - in such
a way that I need (at least) two people/keys out of m possible to
authenticate a session instead of one out of m known once...

e.g:
to authenticate to server X : I need two people A and (B or C) together.

anyone seen this or know how to do?

I know there is key + password (which is kind of this direction) but
not exactly what I'm looking for...

You can use the very same directive AuthenticationMethods to ask for
multiple keys too.

  AuthenticationMethods "publickey,publickey,publickey"

would require three different public keys to authenticate.

However, there is nothing in SSH protocol that would enforce different
people to be involved at the client side.
--
/ 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] ABI report for Samba libraries

2016-12-12 Thread Alexander Bokovoy


On ma, 12 joulu 2016, Ponomarenko Andrey wrote:

Hi Alexander,
 
The report is updated on Mon,Wed and Fri at 11:00 UTC: https://abi-
laboratory.pro/index.php?view=abi-tracker

Ok, thanks.

Could you please extend the report to include all libraries that are
built as part of Samba? E.g. not only public ones but also the privately
used by the Samba itself.


--
/ 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] Anonymous PKINIT and kdcproxy

2016-12-12 Thread Alexander Bokovoy


On ma, 12 joulu 2016, Alexander Bokovoy wrote:

On ma, 12 joulu 2016, Christian Heimes wrote:

On 2016-12-12 09:54, Alexander Bokovoy wrote:

On ma, 12 joulu 2016, Christian Heimes wrote:

Hi Simo,

I'm wondering if we need to change kdcproxy for anon pkinit. What kind
of Kerberos requests are performed by anon pkinit and to establish a
FAST tunnel? python-kdcproxy allows only request types AS-REQ, TGS-REQ
and AP-REQ+KRB-PRV. Responses are not filtered.

Anonymous principal as configured in FreeIPA can only be used to obtain
a TGT, nothing else.

See https://tools.ietf.org/html/rfc6112 for a spec definition.


That doesn't answer my question for me. Or does 'only TGT' imply that
request types are limited to AS-REQ and TGS-REQ? RFC 6112 just talks
about the two request types.

You can only obtain a TGT and this TGT can only be used for FAST
channel. You cannot obtain any service ticket with this TGT.

To close the loop, no changes in kdcproxy are needed because PKINIT is a
pre-authentication scheme and it works just fine with kdcproxy as it is.
I just tested this.
--
/ 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] Anonymous PKINIT and kdcproxy

2016-12-12 Thread Alexander Bokovoy


On ma, 12 joulu 2016, Christian Heimes wrote:

Hi Simo,

I'm wondering if we need to change kdcproxy for anon pkinit. What kind
of Kerberos requests are performed by anon pkinit and to establish a
FAST tunnel? python-kdcproxy allows only request types AS-REQ, TGS-REQ
and AP-REQ+KRB-PRV. Responses are not filtered.

Anonymous principal as configured in FreeIPA can only be used to obtain
a TGT, nothing else.

See https://tools.ietf.org/html/rfc6112 for a spec definition.
--
/ 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] NTP in FreeIPA

2016-11-30 Thread Alexander Bokovoy


On ke, 30 marras 2016, Rob Crittenden wrote:

David Kupka wrote:

On 29/11/16 18:10, Alexander Bokovoy wrote:

Still, bug reports and users' complaints is the only external measure we
have. There are close to nothing in complaints about NTP functionality,
other than requests to support chronyd and a better discover of existing
NTP setups. I don't think that requires dramatic action like removal of
NTP support at all.



As Petr already pointed out, since Fedora 16 chronyd is enabled by
default and ipa-client-install doesn't configure time synchronization
when chronyd is enabled.

I believe that majority of users haven't used '--force-ntpd' and since
it still worked they haven't filed any ticket.

IMO in this case no bug reports means no users rather than no bugs or
requests.

Unfortunately, this is just my guess and AFAIK we don't have any data
from users showing how they use FreeIPA.


For argument's sake, let's say NTP configuration in the client is
dropped and managed by the OS or other administrators.

What implication does this have for configuring NTP server on masters?
Would that be stopped as well? What about existing installs?

Here is the problem: in Kerberos realm services must have time
synchronized with KDC. The patches from StefW which added ability to
record a time skew between the Kerberos client and KDC do not apply to
Kerberos client - Kerberos service communication.

Given that IPA clients can host Kerberos services (at the very least,
SSH is such a service), this practically means they need to have a time
source that is synchronized with the KDC(s) they are talking to.

To me this means we should not really remove NTP configuration but
instead expand ntpd support to cover chronyd as well.



I don't believe there is a precedence for removing a service from IPA.

Neither do I.

--
/ 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] NTP in FreeIPA

2016-11-29 Thread Alexander Bokovoy


On ti, 29 marras 2016, Petr Spacek wrote:

On 29.11.2016 16:02, Rob Crittenden wrote:

Petr Spacek wrote:

On 29.11.2016 09:11, Jan Cholasta wrote:

On 28.11.2016 20:57, Rob Crittenden wrote:

David Kupka wrote:

On 22/11/16 23:15, Gabe Alford wrote:

I would say that it is worth keeping in FreeIPA. I know myself and some
customers use its functionality by having the clients sync to the IPA
servers and have the servers sync to the NTP source. This way if the NTP
source ever gets disrupted for long periods of time (which has
happened in
my environment) the client time drifts with the authentication source.
This
is the way that AD often works and is configured.


Hello Gabe,
I agree that it's common practice to synchronize all nodes in network
with single source in order to have the same time and save bandwidth.
Also I understand that it's comfortable to let FreeIPA installer take
care of it.
But I don't think FreeIPA should do it IMO this is job for Ansible or
similar tool. Also the problem is that in some situations FreeIPA
installer makes it worse.

Example:

1. Install FreeIPA server (ipa1.example.org)
2. Install FreeIPA client on all nodes in network
3. Install replica (ipa2.example.org) of FreeIPA server to increase
redundancy

Now all the clients have ipa1.example.org as the only server in
/etc/ntp.conf. If the first FreeIPA server becomes unreachable all
clients will be able to contact KDC on the other server thanks to DNS
autodiscovery in libkrb5 but will be unable to synchronize time.


Remember that the goal of IPA was to herd together a bunch of software
to make hard things easier. This included dealing with the 5-minute
Kerberos window so ntp was configured on the client and server (which is
less of any issue now).

When making changes you have to ask yourself who are you making this
easier for: you or the user.

Yes, getting NTP right is hard, but does it meet the 80/20 rule in terms
of success? I'd think so. I

If someone wants to configure it using Ansible they can use the
--no-ntp. If they want to use different time servers they can pass in
--ntp-server. But by default IMHO it should do something sane to give a
good experience.


I think to do something sane is exactly the point of this, and the sanest
thing we can do is to not touch NTP configuration at all:

  * if the NTP configuration obtained via DHCP works, we can't make it any
better by touching it, only worse,
  * if the default NTP configuration shipped with the distribution works, we
again can't make it any better by touching it,
  * if we are running inside container, time is synchronized by other means
and we should not touch NTP configuration at all,
  * if neither the default NTP configuration nor the NTP configuration
obtained via DHCP works and we are not running inside container, we may
attempt to fix the configuration, but it will not be permanent and will work
only for this specific host.

I think the first 3 points cover 99% of real-life deployments, and yet we are
optimized towards the remaining 1%, with the potential of breaking the
configuration for the 99%. This is far from sane IMHO.


+1 for Honza's point.

Current NTP code is works only for initial setup and silently breaks
synchronization later on. Most importantly it breaks synchronization as soon
as admin removes old replicas and replaces them with new ones - there is no
mechanism to update the records in the client configuration (and SRV discovery
is not supported by clients).

I.e. when admin decommission replicas which were around at the time of client
installation, the NTP on client will silently break. This would not happen if
you did not touch it.

(This also implicitly means that IPA-configured NTP is broken on all clients
in topologies which were completely migrated from RHEL 6 to RHEL 7.)

Either DHCP or default distro config would solve the problem better.


That's fair but where are the huge pile of bugs, tickets and user
e-mails complaining about time? Or has nobody noticed yet?


Hard to say. There might be multiple reasons for this. E.g.

- Starting with Fedora 16, there is Chronyd installed by default. IPA client
installer does not configure Chronyd by default so there is nothing to break.

- DHCP integration still modifies IPA-generated ntp.conf.

- Users who care might use configuration management tool.

Still, bug reports and users' complaints is the only external measure we
have. There are close to nothing in complaints about NTP functionality,
other than requests to support chronyd and a better discover of existing
NTP setups. I don't think that requires dramatic action like removal of
NTP support at all.

--
/ 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] client-only FreeIPA build

2016-11-22 Thread Alexander Bokovoy


On ke, 23 marras 2016, Jan Cholasta wrote:

On 22.11.2016 18:10, Petr Vobornik wrote:

On 11/22/2016 05:25 PM, Rob Crittenden wrote:

Lukas Slebodnik wrote:

On (22/11/16 16:29), Petr Spacek wrote:

On 22.11.2016 16:27, Jan Cholasta wrote:

Hi,

On 22.11.2016 16:04, Petr Spacek wrote:

Hello,

the recent changes with regard to
http://www.freeipa.org/page/V4/Integration_Improvements
beg a question whether we should invest into supporting client-only builds in
FreeIPA build system.


Note that the Integration efforts don't really apply. The client-only
install is for doing client enrollment and integration can mean lots of
things.



Right now, FreeIPA can be built on all architectures we care about so there is
no incentive to invest into client-only build - this applies to binary/RPM
builds.


Client-only build lowers the barrier for porting IPA to new platforms (porting
only client code is *much* easier than porting the whole thing), so I would
very much prefer if we kept it.


Understood.


Agree about portability

But upstream spec file needn't have such relicts.
The upstream spec file is pure fedora specific.


The upstream spec is what is used to document and verify that the
client-only build actually works.

I also think it is a worthy goal to maintain.


Wondering out loud: What prevents the "porter" from doing full build and then
packaging only client bits? Yes, he has to install come of the dependencies
for the build to pass but still, it is way easier than actually making server
fully functional.


It is not an insignificant amount of dependencies to build all of IPA.


Petr, are you going to allocate time for this soonish or should I open a
ticket and forget about it for now?


IMHO this should be covered under the build refactoring to avoid
regressions.


+1



rob



I think we should not implement it. I see no need. Fedora, Debian, RHEL
all work with server build. Difference between arches is not issue as well.


This assumes that these are the only ports out there, which I know for 
fact they are not [1].

Right. I also inclined to keep client-only build for bootstrapping new
distros. For example, nothing prevents us to have a FreeBSD support for
client side but I don't think there will be any effort of porting the
whole server side there.

--
/ 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] 0221 fix trustdomain-del

2016-11-01 Thread Alexander Bokovoy


On ti, 01 marras 2016, Martin Babinsky wrote:

On 10/31/2016 05:23 PM, Alexander Bokovoy wrote:

See description. This is a regression since FreeIPA 4.4.0.





Hi Alexander,

Please link upstream ticket[1] to the commit message, not BZ.

I have put on my Travis hat and found:

1.) pep8 error:

./ipaserver/plugins/trust.py:1623:25: E128 continuation line 
under-indented for visual indent


I know that this is a piece of code that was only moved around but it 
should conform to pep8 anyway.


2.) unused variable:

Pylint is running, please wait ...
* Module ipaserver.plugins.trust
ipaserver/plugins/trust.py:1619: [W0612(unused-variable), 
trustdomain_del.execute] Unused variable 'entry')

Makefile:130: recipe for target 'pylint' failed
make: *** [pylint] Error 1

Also, if you just want to check if the domain exists, I think that you 
can use `get_dn_if_exists` method of LDAPObject (you will get rid of 
unused variable as a bonus):


diff --git a/ipaserver/plugins/trust.py b/ipaserver/plugins/trust.py
index 3540742..2cd4722 100644
--- a/ipaserver/plugins/trust.py
+++ b/ipaserver/plugins/trust.py
@@ -1615,8 +1615,7 @@ class trustdomain_del(LDAPDelete):

for domain in keys[1]:
try:
-dn = self.obj.get_dn(keys[0], domain, trust_type=u'ad')
-entry = ldap.get_entry(dn)
+self.obj.get_dn_if_exists(keys[0], domain, 
trust_type=u'ad')

except errors.NotFound:
if keys[0].lower() == domain:
raise errors.ValidationError(name='domain'

[1] https://fedorahosted.org/freeipa/ticket/6445

Thanks, I've fixed these issues.

Updated patch is attached.

--
/ Alexander Bokovoy
From 2b7cb26a5e95ee6f780b3484ca673fdb5e8bd67e Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy <aboko...@redhat.com>
Date: Mon, 31 Oct 2016 18:17:35 +0200
Subject: [PATCH 2/2] trustdomain-del: fix the way how subdomain is searched

With FreeIPA 4.4 we moved child domains behind the 'trustdomain' topic.
Update 'ipa trustdomain-del' command to properly calculate DN to the
actual child domain and handle the case when it is missing correctly.

Fixes https://fedorahosted.org/freeipa/ticket/6445
---
 ipaserver/plugins/trust.py | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/ipaserver/plugins/trust.py b/ipaserver/plugins/trust.py
index c0c080d..c84b1aa 100644
--- a/ipaserver/plugins/trust.py
+++ b/ipaserver/plugins/trust.py
@@ -1614,13 +1614,16 @@ class trustdomain_del(LDAPDelete):
 # to always receive empty keys. We need to catch the case when root 
domain is being deleted
 
 for domain in keys[1]:
-# Fetch the trust to verify that the entered domain is trusted
-self.api.Command.trust_show(domain)
+try:
+self.obj.get_dn_if_exists(keys[0], domain, trust_type=u'ad')
+except errors.NotFound:
+if keys[0].lower() == domain:
+raise errors.ValidationError(
+name='domain',
+error=_("cannot delete root domain of the trust, "
+"use trust-del to delete the trust itself"))
+self.obj.handle_not_found(keys[0], domain)
 
-if keys[0].lower() == domain:
-raise errors.ValidationError(name='domain',
-error=_("cannot delete root domain of the trust, "
-"use trust-del to delete the trust itself"))
 try:
 self.api.Command.trustdomain_enable(keys[0], domain)
 except errors.AlreadyActive:
-- 
2.9.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

[Freeipa-devel] [PATCH] 0221 fix trustdomain-del

2016-10-31 Thread Alexander Bokovoy


See description. This is a regression since FreeIPA 4.4.0.

--
/ Alexander Bokovoy
From ce6dcc38fe4b1772941b281880ab156d7ae0db7c Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy <aboko...@redhat.com>
Date: Mon, 31 Oct 2016 18:17:35 +0200
Subject: [PATCH 2/2] trustdomain-del: fix the way how subdomain is searched

With FreeIPA 4.4 we moved child domains behind the 'trustdomain' topic.
Update 'ipa trustdomain-del' command to properly calculate DN to the
actual child domain and handle the case when it is missing correctly.

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1389709
---
 ipaserver/plugins/trust.py | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/ipaserver/plugins/trust.py b/ipaserver/plugins/trust.py
index c0c080d..3540742 100644
--- a/ipaserver/plugins/trust.py
+++ b/ipaserver/plugins/trust.py
@@ -1614,13 +1614,16 @@ class trustdomain_del(LDAPDelete):
 # to always receive empty keys. We need to catch the case when root 
domain is being deleted
 
 for domain in keys[1]:
-# Fetch the trust to verify that the entered domain is trusted
-self.api.Command.trust_show(domain)
+try:
+dn = self.obj.get_dn(keys[0], domain, trust_type=u'ad')
+entry = ldap.get_entry(dn)
+except errors.NotFound:
+if keys[0].lower() == domain:
+raise errors.ValidationError(name='domain',
+error=_("cannot delete root domain of the trust, "
+"use trust-del to delete the trust itself"))
+self.obj.handle_not_found(keys[0], domain)
 
-if keys[0].lower() == domain:
-raise errors.ValidationError(name='domain',
-error=_("cannot delete root domain of the trust, "
-"use trust-del to delete the trust itself"))
 try:
 self.api.Command.trustdomain_enable(keys[0], domain)
 except errors.AlreadyActive:
-- 
2.9.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] tomcat-8.0.37-3.fc24.noarch package from updates testing breaks CA instance spawn

2016-10-25 Thread Alexander Bokovoy


On ti, 25 loka 2016, Martin Babinsky wrote:
An update for Apache Tmocat recently pushed into bodhi[1] seems to 
break CA instance spawning in a spectacular way.[2] It seems that the 
update once again breaks the loading of Java classes during Dogtag 
server initialization.


I gave the package negative karma and I suggest for you to do the same 
until the issue is resolved.


As a workaround you can either disable updates-testing or use:

"""
dnf downgrade --allowerasing tomcat
"""

to downgrade tomcat and dependencies to version 8.0.36-2.fc24 which works.

[1] https://bodhi.fedoraproject.org/updates/FEDORA-2016-c1b01b9278
[2] https://paste.fedoraproject.org/460589/77394029

Thank you Martin.

I've found the corresponding Apache bugzilla entry:
https://bz.apache.org/bugzilla/show_bug.cgi?id=60101

Tomcat needs to be rebased to 8.0.38 to work. I just broke my test
install ;)
--
/ 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] [freeipa PR#184][comment] Minor install script fixes

2016-10-24 Thread Alexander Bokovoy


On ma, 24 loka 2016, Simo Sorce wrote:

On Mon, 2016-10-24 at 17:38 +0200, abbra wrote:

  URL: https://github.com/freeipa/freeipa/pull/184
Title: #184: Minor install script fixes

abbra commented:
"""
ACK from my side if you would split the commit into two small ones, please.

Note that CI integration is currently broken so travis says your commits failed 
the checks.
"""


Done, and the CI seem happy ?

Yes, thank you. I acked the request.

--
/ 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] FleetCommander integration

2016-10-13 Thread Alexander Bokovoy


On to, 13 loka 2016, Sumit Bose wrote:

On Tue, Sep 06, 2016 at 01:18:14PM +0300, Alexander Bokovoy wrote:

Hi,

Now that FreeIPA 4.4.1 is out, I've pushed to github my prototype for
FleetCommander integration: https://github.com/abbra/freeipa-desktop-profile/

You can read the design page:
https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/Feature.mediawiki


Hi Alexander,

if I understand it correctly each profile has a priority which is used
by FleetCommander on the client side to order the different profiles if
for a given user and host multiple rules matches.

To make this work smoothly each priority value should be only assigned
once to avoid a tie. Are you planning to use the uniqueness plugin on
the priority value or are there other ways to solve ties reliable in
FleetCommander?

I'm not planning to make priorities unique. Do we really need that?
My idea was to make sure we provide clear sorting logic:

profilename.json file name is built using profile RDN and is prefixed by
the priority of the profile rule using leading zeros. To ease handling
of the files, SSSD may transform RDN value by removing certain
characters used by the shell for globing purposes and by replacing
spaces with underscores. Since the name of the file is only used to
ensure ordering of the profiles when merging them, a lexicographical
sort of names should be enough.



Example: For a profile rule 'Minimal Desktop For Guests' stored as
cn=Minimal desktop for guests,cn=rules,cn=desktop-profile,$SUFFIX with a
priority 100, SSSD would use a file name '000100_Minimal_desktop_for_guests.json'. 



Given that you would not be able to have exact same RDN value in two
different profiles, using lexicographical sort gives you explicit
ordering schema. 


--
/ 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] Feature branches for sub-team efforts

2016-10-12 Thread Alexander Bokovoy


On ke, 12 loka 2016, David Kupka wrote:

On 11/10/16 16:27, Alexander Bokovoy wrote:

On ti, 11 loka 2016, Petr Vobornik wrote:

On 10/11/2016 03:50 PM, Alexander Bokovoy wrote:

On ti, 11 loka 2016, Petr Vobornik wrote:

Hi List,

we discussed locally a proposal about creating a feature branch for
each
sub-team effort in our main git. Currently it would be for the 4
ongoing
refactoring efforts + Simo's work

Why?
It will allow each developer to create a pull request against the
feature branch and thus it will enable iterative development by
multiple
devs without affecting other sub-teams. When the
feature(refactoring) is
finished, the branch would be rebased on master and merged there. Note:
rebases can be done as needed - e.g. when other subteam finishes its
work.

Concerns:
1. Upstream git repo would be full of such branches.
- This can be mitigated by deleting the feature branches when their are
released or merged(up to discussion)

Don't put them in the upstream git repo. Let people decide where they
want to have them -- all Fedora contributors have access to
fedorapeople.org git hosting and there is github one button click
('Clone') away from the github mirror.

It is not a problem to keep a separate git branch published this way.



It is not a matter of making the code public. That can be done easily as
you write. Other alternative is own branch in GitHub fork.


May be I misunderstand you -- if you just want people to propose merge
requests on github with pre-defined names, then that's just fine.



Basically it's all about review.

Example use case: More than 1 devs are working on a same big effort.
This effort will probably consists of 10s of commits. The big effort is
divided into smaller ones which can be implemented and reviewed
separately. In our previous mode, the sub task would be merged to master
it is reviewed and ACKed. But now we cannot do that. We want to merge
the whole big task at once when it is finishes and tested.

One dev could probably have a branch on personal fork of FreeIPA on
GitHub which would work as the feature branch. Other team members would
create pull requests against it.

In such case we would loose mail notifications and would have to extend
our tooling because ipatool can use only one upstream on push.

So I still think this is not a problem. If people can agree which git
repo clone will be primary one and submit merge requests against it,
then there is no problem in having that git repo's branch to be
submitted as the pull request against the main git repo. This way you'll
get all the changes seen at the pull request sync time.



From my POV, when we create the refactoring branches in upstream we 
get this for free:

* our minimal but convenient CI (lint + build on each PR)
* mail notifications
* tooling (ipatool pr-push XYZ -b refactoring-xyz just works)

When creating them elsewhere we get:
* confusion (no team-wide notifications, each effort in other fork)
* manual rebasing and pushing

This is rehashing of what Petr wrote already. And I understand the
benefits of it. However, I don't like one part of the proposal: removing
branches from upstream when feature is merged. This is heavily against
accountability -- we should never remove anything from the primary git
tree. Also, this churn of branches creates a lot of issues in terms of
maintaining internal git datastore as you'll need to clean it from time
to time.

At this point I don't really see how benefits could outweigh the
negatives in the longer term. Thousands of projects are working with
separate git trees and do pull requests without negative of having to
keep all the temporary feature branches in the main git tree. Why can't
we?



So I think it's best to create the branches in upstream repo. I don't 
care about names and also I don't care what happens with them after 
the effort is done.


--
David Kupka


--
/ 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] HBAC for AD users Active Directory trust setup

2016-10-12 Thread Alexander Bokovoy


On ke, 12 loka 2016, rajat gupta wrote:

Hi,

thank you for answering.

I this case i need to create multiple group in AD side. like user1  have
only "server1.example.com" and "server2.example.com" access and some other
user have some other server access. Then only the my  HBAC
rule will be implemented to particular  group  and every time i need to add
user in  AD side on particular group if I want to give some other server
access to user. And i don't want do like this.

It is up to you what you want to implement. The means are all there. But
read my responses on the freeipa-users@ to understand why we implemented
it this way.

--
/ 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] HBAC for AD users Active Directory trust setup

2016-10-12 Thread Alexander Bokovoy

On ke, 12 loka 2016, rajat gupta wrote:

Hi,

Normally HBAC for AD users should be done through an external group.

You should use freeipa-users@ mailing list for these questions.

And start with documentation:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html

So for example if we have 500+ users on AD and only 100 user are
administrator and they have Linux server access.

I want to set the HBAC and sudo rules for users. So user have correct
access server access and sudo rights and I am using the *Active Directory
trust setup*

In this case i need to add all of the 100 users on in Freeipa as external
group.

for example :- user1 user name in AD

*user1-external* external group in IPA for trusted domain users
*user1 :- *POSIX group for external

No, you don't need to do that. All you need to do is to create a group
on AD side where your users to access Linux systems would be added and
then add that group to the external group on IPA side.

Do we have document for implementing the HBAC and Sudo Rules for external
group.

See above documentation and discussions on freeipa-users@ mailing list.

--
/ 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] Feature branches for sub-team efforts


On ti, 11 loka 2016, Petr Vobornik wrote:

On 10/11/2016 03:50 PM, Alexander Bokovoy wrote:

On ti, 11 loka 2016, Petr Vobornik wrote:

Hi List,

we discussed locally a proposal about creating a feature branch for each
sub-team effort in our main git. Currently it would be for the 4 ongoing
refactoring efforts + Simo's work

Why?
It will allow each developer to create a pull request against the
feature branch and thus it will enable iterative development by multiple
devs without affecting other sub-teams. When the feature(refactoring) is
finished, the branch would be rebased on master and merged there. Note:
rebases can be done as needed - e.g. when other subteam finishes its
work.

Concerns:
1. Upstream git repo would be full of such branches.
- This can be mitigated by deleting the feature branches when their are
released or merged(up to discussion)

Don't put them in the upstream git repo. Let people decide where they
want to have them -- all Fedora contributors have access to
fedorapeople.org git hosting and there is github one button click
('Clone') away from the github mirror.

It is not a problem to keep a separate git branch published this way.



It is not a matter of making the code public. That can be done easily as
you write. Other alternative is own branch in GitHub fork.


May be I misunderstand you -- if you just want people to propose merge
requests on github with pre-defined names, then that's just fine.



Basically it's all about review.

Example use case: More than 1 devs are working on a same big effort.
This effort will probably consists of 10s of commits. The big effort is
divided into smaller ones which can be implemented and reviewed
separately. In our previous mode, the sub task would be merged to master
it is reviewed and ACKed. But now we cannot do that. We want to merge
the whole big task at once when it is finishes and tested.

One dev could probably have a branch on personal fork of FreeIPA on
GitHub which would work as the feature branch. Other team members would
create pull requests against it.

In such case we would loose mail notifications and would have to extend
our tooling because ipatool can use only one upstream on push.

So I still think this is not a problem. If people can agree which git
repo clone will be primary one and submit merge requests against it,
then there is no problem in having that git repo's branch to be
submitted as the pull request against the main git repo. This way you'll
get all the changes seen at the pull request sync time.

--
/ 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] Feature branches for sub-team efforts


On ti, 11 loka 2016, Petr Vobornik wrote:

Hi List,

we discussed locally a proposal about creating a feature branch for each
sub-team effort in our main git. Currently it would be for the 4 ongoing
refactoring efforts + Simo's work

Why?
It will allow each developer to create a pull request against the
feature branch and thus it will enable iterative development by multiple
devs without affecting other sub-teams. When the feature(refactoring) is
finished, the branch would be rebased on master and merged there. Note:
rebases can be done as needed - e.g. when other subteam finishes its work.

Concerns:
1. Upstream git repo would be full of such branches.
- This can be mitigated by deleting the feature branches when their are
released or merged(up to discussion)

Don't put them in the upstream git repo. Let people decide where they
want to have them -- all Fedora contributors have access to
fedorapeople.org git hosting and there is github one button click
('Clone') away from the github mirror.

It is not a problem to keep a separate git branch published this way.

May be I misunderstand you -- if you just want people to propose merge
requests on github with pre-defined names, then that's just fine.

--
/ 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] Build system refactoring - design document


On ti, 11 loka 2016, Petr Spacek wrote:

On 11.10.2016 10:04, Jan Cholasta wrote:

On 11.10.2016 09:36, Petr Spacek wrote:

On 11.10.2016 09:00, Jan Cholasta wrote:

Hi,

On 7.10.2016 11:56, Petr Spacek wrote:

Dear FreeIPA developers and packagers,

you can find first version of the Build system refactoring design document
on:
http://www.freeipa.org/page/V4/Build_system_refactoring

If you do not care about implementation details, please be so kind and
quickly
scan through chapter
http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management

I'm not an FreeIPA packager so I might miss some important thing which needs
to be configurable.


1) There should be a --with-python switch to select the version of Python to
use in our command line tools and/or during build. The default would be
"python", i.e. the default Python interpreter found in the path.


Okay. Can we pick some descriptive name?

--with-default-python
or
--with--python?

I think that it would be confusing if we had just
--with-python
--with-python2
--with-python3


If the default values are "python", "python2", "python3" respectively, I don't


These need to be full paths. I hope that some autoconf detection logic will
help with autodetection.



think it would be confusing, since most of the time you only need to specify
--with-python, if anything.


Okay, let me be explicit: It *is* confusing for me. Would you be okay with
--with-default-python ?



Do we even need --with-python2 and --with-python3? I think they would only
make sense if you had multiple Python minor versions installed and wanted to
make packages for all of them.


AFAIK autoconf-style is to provide these for options where path to external
binary is needed. I would like to keep these conventions to avoid NIH syndrome
in the new build system.

Also, --without-python2/--without-python3 is needed anyway to disable this
part of build on systems without Python X version. I want to keep this
explicit (as with any other optional part of the build).

Why so complex? Allow --with-python to be specified multiple times and
enable all python versions that resolve through --with-python specified 
executables:

 --with-python=/bin/python2 --with-python=/bin/python3

would enable both Python 2 and Python 3. Specifying none will enable
default version found on the system. Specifying one will enable
explicitly only one.


--
/ 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] Build system refactoring - design document


On ti, 11 loka 2016, Petr Spacek wrote:

On 11.10.2016 09:00, Jan Cholasta wrote:

Hi,

On 7.10.2016 11:56, Petr Spacek wrote:

Dear FreeIPA developers and packagers,

you can find first version of the Build system refactoring design document on:
http://www.freeipa.org/page/V4/Build_system_refactoring

If you do not care about implementation details, please be so kind and quickly
scan through chapter
http://www.freeipa.org/page/V4/Build_system_refactoring#Feature_Management

I'm not an FreeIPA packager so I might miss some important thing which needs
to be configurable.


1) There should be a --with-python switch to select the version of Python to
use in our command line tools and/or during build. The default would be
"python", i.e. the default Python interpreter found in the path.


Okay. Can we pick some descriptive name?

--with-default-python
or
--with--python?

I think that it would be confusing if we had just
--with-python
--with-python2
--with-python3

--with-python=/path/to/python.binary is enough. We have the same in
Samba where a secondary build against another python interpreter is
regulated with '--extra-python' pointing to the Python's executable.



Besides that, I would make --with-default-python to accept either "2" or "3"
(and thus use path specified by --with-python? option).

I don't think we need --with-default-python=2|3 at all. Once you have a
Python binary, you can discover the flavor in the code:
$ python -c 'import sys; print sys.version_info.major'
2


--
/ 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] Freeipa-devel Digest, Vol 113, Issue 35

2016-10-10 Thread Alexander Bokovoy

 Cannot contact any KDC for
realm... from Freeipa clinet (Active Directory trust setup)
Message-ID: <74136c2e-87aa-e18a-b16e-d2839ea12...@redhat.com>
Content-Type: text/plain; charset=windows-1252

On 10.10.2016 05:23, rajat gupta wrote:
> Hi,
>
> I am trying to setup the freeipa  Active Directory trust setup and i am
> following
> the http://www.freeipa.org/page/Active_Directory_trust_setup
documentation.
>
> I am able to login on freeipa Server with AD users.
>
> But when i am trying to login with some other IPA client machine I am not
> able to to login with AD user.
>
> Required firewall port is opened between freeipa server to AD server and
> freeipa server to freeipa clinets
>
> There is no firewall port is opened between from  freeipa client to AD
> server.
>
> =
> against addomain from ipaserver :-
>
> ipa01 ~]# KRB5_TRACE=/dev/stdout kinit raja...@ad.addomain.com
> [24633] 1476069033.462976: Resolving unique ccache of type KEYRING
> [24633] 1476069033.463027: Getting initial credentials for
> raja...@ad.addomain.com
> [24633] 1476069033.465229: Sending request (183 bytes) to
AD.ADDOMAIN.COM
> [24633] 1476069033.471891: Resolving hostname ad1.ad.addomain.com
> [24633] 1476069033.474439: Sending initial UDP request to dgram
> 192.168.20.100:88
> [24633] 1476069033.487765: Received answer (212 bytes) from dgram
> 192.168.20.100:88
> [24633] 1476069033.488098: Response was not from master KDC
> [24633] 1476069033.488136: Received error from KDC:
-1765328359/Additional
> pre-authentication required
> [24633] 1476069033.488179: Processing preauth types: 16, 15, 19, 2
> [24633] 1476069033.488192: Selected etype info: etype aes256-cts, salt
> "AD.ADDOMAIN.COMRajat.Gupta", params ""
> [24633] 1476069033.488215: PKINIT client has no configured identity;
giving
> up
> [24633] 1476069033.488233: PKINIT client has no configured identity;
giving
> up
> [24633] 1476069033.488242: Preauth module pkinit (16) (real) returned:
> 22/Invalid argument
> [24633] 1476069033.488250: PKINIT client has no configured identity;
giving
> up
> [24633] 1476069033.488255: Preauth module pkinit (14) (real) returned:
> 22/Invalid argument
> Password for raja...@ad.addomain.com:
>
> this is working fine.
> =
>
>
> =
> against addomain from ipaclinet :-
>
> *ipaclinet ~] #  KRB5_TRACE=/dev/stdout kinit  raja...@ad.addomain.com
> <raja...@ad.addomain.com>[4133] 1476067599.43421: Getting initial
> credentials for raja...@ad.addomain.com <http://AD.ADDOMAIN.COM>[4133]
> 1476067599.43599: Sending request (183 bytes) to AD.ADDOMAIN.COM
> <http://AD.ADDOMAIN.COM>*
> *[4133] 1476067599.49544: Resolving hostname *
> *ad1.ad.addomain.com <http://ad1.ad.addomain.com>.*
> *[4133] 1476067599.53762: Sending initial UDP request to dgram
> 192.168.20.100*
>
> NOT WORKING
> =
>
> =========
> against ipdomain from ipaclinet
>
> # KRB5_TRACE=/dev/stdout kinit  admin@IPA.IPASERVER.LOCAL
> [4914] 1476068067.763574: Getting initial credentials for
> admin@IPA.IPASERVER.LOCAL
> [4914] 1476068067.763889: Sending request (177 bytes) to
IPA.IPASERVER.LOCAL
> [4914] 1476068067.764033: Initiating TCP connection to stream
> 10.246.104.14:88
> [4914] 1476068067.765089: Sending TCP request to stream
192.168.100.100:88
> [4914] 1476068067.767593: Received answer (356 bytes) from stream
> 192.168.100.100:88
> [4914] 1476068067.767603: Terminating TCP connection to stream
> 192.168.100.100:88
> [4914] 1476068067.767661: Response was from master KDC
> [4914] 1476068067.767685: Received error from KDC: -1765328359/Additional
> pre-authentication required
> [4914] 1476068067.767730: Processing preauth types: 136, 19, 2, 133
> [4914] 1476068067.767742: Selected etype info: etype aes256-cts, salt
> "k},(k&+qA)Mosf6z", params ""
> [4914] 1476068067.767747: Received cookie: MIT
> Password for admin@IPA.IPASERVER.LOCAL:
>
> this is working fine.
> =
>
>
> it looks for password-based authentication requests, the IPA clients
> connect directly to the AD servers using Kerberos.
>
> then there is port firewall opening required  between ipaclinet and AD
> Server as well. Is it required ? OR I am doing something wrong.

Yes, IPA clients need to talk to AD servers as well. Please see
https://access.redhat.com/documentation/en-US/Red_Hat_
Enterprise_Linux/7/html/Windows_Integration_Guide/
trust-requirements.html#trust-req-ports


--
Petr^2 Spacek



--

Message: 6
Date: Mon, 10 Oct 2016 09:21:40 +0200
From: pvomacka <freeipa-github-notificat...@redhat.com>
To: freeipa-devel@redhat.com
Subject: [Freeipa-devel] [freeipa PR#146][opened] WebUI: fix API
Browser menu label
Message-ID:

Content-Type: text/plain; charset="utf-8"

   URL: https://github.com/freeipa/freeipa/pull/146
Author: pvomacka
 Title: #146: WebUI: fix API Browser menu label
Action: opened

PR body:
"""
The label of API Browser is now in translatable strings and it has
uppercase B at the beginnig of second word.

https://fedorahosted.org/freeipa/ticket/6384
"""

To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/146/head:pr146
git checkout pr146
-- next part --
A non-text attachment was scrubbed...
Name: freeipa-pr-146.patch
Type: text/x-diff
Size: 2069 bytes
Desc: not available
URL: <https://www.redhat.com/archives/freeipa-devel/
attachments/20161010/5dc80c2e/attachment.bin>

--

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

End of Freeipa-devel Digest, Vol 113, Issue 35
**





--

*Rajat Gupta *



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



--
/ 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] [RFC] Matching and Mapping Certificates

2016-10-07 Thread Alexander Bokovoy


On pe, 07 loka 2016, Fraser Tweedale wrote:

On Thu, Oct 06, 2016 at 12:49:30PM +0200, Sumit Bose wrote:


Question, do we need search-and-replace at all (or at this
stage)? Most of the interesting values from the SAN should be
directly map-able to LDAP attributes. And processing the string
representation of  might be tricky as discussed below.
Nevertheless the following might be possible:

* /regexp/replacement/
* /regexp/replacement/

where "/regexp/replacement/" stands for optional sed-like
substitution rules. E.g. a rule like

   /^CN=\([^,]*\).*$/\1/

would take the subject string
'CN=Certuser,CN=Users,DC=example,DC=com' from the certificate and
generate a LDAP search filter component
'(samAccountName=Certuser)' which can be included in a LDAP search
filter which includes additional components like e.g. an
objectClass.


A counter-proposal w.r.t. DN mapping:

   

Where OID is either an actual OID or the corresponding string i.e.
"CN", "O", etc.  This would extract the "most specific" (leftmost in
the LDAP sense, rightmost in the X.500 sense) attribute value of the
specified type from the Subject DN.

IMO this would cover most DN mapping use cases whilst avoiding regex
or confusion about RDN order.  Therefore your original example of:

   /^CN=\([^,]*\).*$/\1/

can be accomplished with:

   

In the spirit of "make the simple things simple, and the hard things
possible" it is probably necessary to retain the regex variant to
handle more complex DN mapping use cases, e.g. where there are
multiple occurrences of a single attribute type, a particular fixed
RDN must be matched, etc.

w.r.t. SAN mapping, I concur that search/replace is probably not
needed.

How all these syntax extensions are going to handle multi-valued RDN?

--
/ 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] python-nss-1.0.0-2.fc24.x86_64 from updates-testing breaks FreeIPA client API

2016-09-29 Thread Alexander Bokovoy


On to, 29 syys 2016, Martin Babinsky wrote:

Hi list,

today I noticed the following exceptions in my VMs when 
installing/using FreeIPA:


"""
# ipa ping
exception in SSLSocket.handshake_callback
Traceback (most recent call last):
 File "/usr/lib/python2.7/site-packages/ipapython/nsslib.py", line 
258, in handshake_callback

   channel = sock.get_ssl_channel_info()
nss.error.NSPRError: (SEC_ERROR_INVALID_ARGS) security library: 
invalid arguments.


IPA server version 4.4.90. API version 2.215

"""

This was caused by python-nss-1.0.0-2.fc24.x86_64 which was pushed to 
updates-testing. Reverting the package to previous versions fixed the 
problem.

python-nss-1.0.0-1.fc25 (note fc25) works fine. There is no 1.0.0-2.fc25
which is a packaging bug, but that's should not be bringing any
difference as the tarball (1.0.0) is the same and no additional patches
were applied.

Also, we didn't have any changes between 4.4.1 and git master that could
have affected ipapython/nsslib.py other than 
0f88f8fe889ae4801fc8d5ece1ad51c5246718ac,
which is this chunk of changes:

diff --git a/ipapython/nsslib.py b/ipapython/nsslib.py
index 1573de9..f9f64c1 100644
--- a/ipapython/nsslib.py
+++ b/ipapython/nsslib.py
@@ -234,7 +234,7 @@ class NSSConnection(httplib.HTTPConnection,
NSSAddressFamilyFallback):
self.sock.set_ssl_option(ssl.SSL_HANDSHAKE_AS_CLIENT, True)
try:
self.sock.set_ssl_version_range(self.tls_version_min, 
self.tls_version_max)
-except NSPRError as e:
+except NSPRError:
root_logger.error('Failed to set TLS range to %s, %s' % 
(self.tls_version_min, self.tls_version_max))
raise
self.sock.set_ssl_option(ssl_require_safe_negotiation, False)

e.g. nothing that is relevant to the trace you provided.


--
/ 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 0097] Properly handle LDAP socket closures in ipa-otpd

2016-09-27 Thread Alexander Bokovoy


On ti, 27 syys 2016, Nathaniel McCallum wrote:

In at least one case, when an LDAP socket closes, a read event is fired
rather than an error event. Without this patch, ipa-otpd silently
ignores this event and enters a state where all bind auths fail.

To remedy this problem, we pass error events along the same path as
read events. Should the actual read fail, we exit.

Please add the bugzilla link.

--
/ 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] FleetCommander integration

2016-09-21 Thread Alexander Bokovoy


Hi Alberto,

On Wed, 21 Sep 2016, Alberto Ruiz Ruiz wrote:

Hello Alexander,

So, I've been assigned with a new team/project just this week (related to
hardware enablement/support), I'll still manage Fleet Commander but this
means I won't have time to be involved in the implementation.

I will be delegating the discussion between you and Oliver Gutierrez,
Oliver is spending a few weeks in Brno, so I'm expecting he will catch up a
bit on Fleet Commander with Fabiano.

As I was the sole maintainer of the client daemon so I'll still be around
for questions and small changes, if only until I find someone to assign to
it within the bigger team.

I would expect Oliver would go ahead and start testing your test plugin
right away.

Got it. Let's discuss on IRC (freenode, #freeipa or #sssd) whenever you
guys would have time any issues you'll encounter. 


--
/ 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] [Test][Patch-0049, 0050] Certs in ID overrides test

2016-09-14 Thread Alexander Bokovoy


On Wed, 14 Sep 2016, Martin Basti wrote:



On 14.09.2016 17:53, Alexander Bokovoy wrote:

On Wed, 14 Sep 2016, Martin Basti wrote:



On 14.09.2016 17:41, Alexander Bokovoy wrote:

On Wed, 14 Sep 2016, Martin Basti wrote:

1)
I still don't see the reason why AD trust is needed. Default 
trust ID view is added just by ipa-adtrust-install, adding 
trust is not needed for current implementation. You don't need 
AD for this, IDviews is generic feature not just for AD. Is 
that user configured on AD side?

You cannot add non-AD user to 'default trust view', so you will not be
able to set up certificates to ID override which does not exist.

For non-'default trust view' you can add both IPA and AD users, 
so using

some other view and then assign certificate for a ID override in that
one.



Ok then, but anyway I would like to see API/CLI tests for this 
feature with proper output validation.



How can be this tested with SSSD?

You need to log into the system with a certificate...
Is this possible from test? We are logged remotely as root, is there 
any cmdline util which allows us to test certificate against AD user?

https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardAuthenticationTestingWithAD

The only thing that differentiates AD user from IPA is the fact that
you'd need to trust a certificate authority that issued the certificate
for this user.
--
/ 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] [Test][Patch-0049, 0050] Certs in ID overrides test

2016-09-14 Thread Alexander Bokovoy


On Wed, 14 Sep 2016, Martin Basti wrote:

1)
I still don't see the reason why AD trust is needed. Default trust ID 
view is added just by ipa-adtrust-install, adding trust is not needed 
for current implementation. You don't need AD for this, IDviews is 
generic feature not just for AD. Is that user configured on AD side?

You cannot add non-AD user to 'default trust view', so you will not be
able to set up certificates to ID override which does not exist.

For non-'default trust view' you can add both IPA and AD users, so using
some other view and then assign certificate for a ID override in that
one.

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

[Freeipa-devel] FleetCommander integration

2016-09-06 Thread Alexander Bokovoy


Hi,

Now that FreeIPA 4.4.1 is out, I've pushed to github my prototype for
FleetCommander integration: https://github.com/abbra/freeipa-desktop-profile/

You can read the design page:
https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/Feature.mediawiki

The design was mostly figured out in discussions with Alberto, Fabiano,
Nathaniel, and Jakub, so we are more or less on the common ground here
between SSSD and FleetCommander. You can send pull requests to me on
github to update the design. ;)

You can cut a tarball using
git archive --format=tar.gz --prefix=freeipa-desktop-profile-0.0.1/ \
  --output ~/rpmbuild/SOURCES/freeipa-desktop-profile-0.0.1.tar.gz \
  freeipa-desktop-profile-0.0.1

And then build the package with
rpmbuild -ta freeipa-desktop-profile-0.0.1.tar.gz

When installed, the package does not run ipa-server-upgrade by itself,
yet. So you need to run ipa-server-upgrade manually. Once ran,
deskprofile/deskprofilerule topics would become available and can be
used for testing purposes. For Fedora 24 one can use FreeIPA 4.4.1 from
COPR, for Fedora 25 we have FreeIPA 4.4.1 in updates stable as of today.

UI plugin is not ready yet and is disabled in the spec file as it breaks
loading the whole UI.

--
/ 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] Karma Requests for pki-core-10.3.5-4

2016-09-03 Thread Alexander Bokovoy


On Tue, 30 Aug 2016, Matthew Harmsen wrote:
*The following updated candidate builds of pki-core 10.3.5 on Fedora 
24, 25, and 26 (rawhide) consist of the following:

*

* *Fedora 24*
o *pki-core-10.3.5-4.fc24
  <http://koji.fedoraproject.org/koji/buildinfo?buildID=795475>
  *
* *Fedora 25*
o *pki-core-10.3.5-4.fc25
  <http://koji.fedoraproject.org/koji/buildinfo?buildID=795726>
  *
* *Fedora 26*
o *pki-core-10.3.5-4.fc26
  <http://koji.fedoraproject.org/koji/buildinfo?buildID=795727>
  *


Unfortunately, upgrade in Fedora 24 does not work for existing FreeIPA
deployments due to lack upgrade for dangling symlinks of jaxrs-api.jar.

I filed a ticket https://fedorahosted.org/pki/ticket/2452. Please fix it
ASAP because we already have users in Fedora 24 complaining about broken
deployments after a mere 'dnf update'.


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

[Freeipa-devel] Release 4.4.1 planning

2016-08-30 Thread Alexander Bokovoy


Hi,

we have a plan to release FreeIPA 4.4.1 on Wednesday, Aug 31st.

I started preparing a release page:
http://www.freeipa.org/page/Releases/4.4.1

It has staggering 140+ closed tickets already.

Please help me with filling in enhancements and bug fixes sections.

--
/ 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] [DESIGN][UPDATE] Time-Based HBAC Policies

2016-08-30 Thread Alexander Bokovoy


On Tue, 30 Aug 2016, Jan Cholasta wrote:

On 30.8.2016 08:47, Standa Laznicka wrote:

On 08/26/2016 05:37 PM, Simo Sorce wrote:

On Fri, 2016-08-26 at 11:26 -0400, Simo Sorce wrote:

On Fri, 2016-08-26 at 18:09 +0300, Alexander Bokovoy wrote:

On Fri, 26 Aug 2016, Simo Sorce wrote:

On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote:

I miss "why" part of "To be able to handle backward compatibility

with

ease, a new object called ipaHBACRulev2 is introduced. " in the

design

page. If the reason is the above - old client's should ignore time

rules

then it has to be mentioned there. Otherwise I don't see a reason to
introduce a new object type instead of extending the current.

How do you want to enforce HBAC rule that have set time from 10 to 14
everyday? With the same objectclass old clients will allow this HBAC
for
all day. Isn't this CVE?

This is a discussion worth having.

In general it is a CVE only if an authorization mechanism fails to
work
as advertised.

If you make it clear that old clients *DO NOT* respect time rules then
there is no CVE material, it is working as "described".

The admins already have a way to not set those rules for older clients
by simply grouping newer clients in a different host group and
applying
time rules only there.

So the question really is: should we allow admins to apply an HBAC
Rule
potentially to older clients that do not understand it and will
therefore allow access at any time of the day, or should we prevent
it ?

This is a hard question to answer and can go both ways.

A time rule may be something that admins want to enforce at all
cost or
deny access. In this case a client that fails to handle it would be a
problem.

But it may be something that is just used for defense in depth and
not a
strictly hard requirement. In this case allowing older clients would
make it an easy transition as you just set up the rule and the client
will start enforcing the time when it is upgraded but work otherwise
with the same rules.

I am a bit conflicted on trying to decide what scenario we should
target, but the second one appeals to me because host groups do
already
give admins a good way to apply rules to a specific set of hosts and
exclude old clients w/o us making it a hard rule.
OTOH if an admin does not understand this difference, they may be
surprised to find out there are clients that do not honor it.

Perhaps we could find a way to set a flag on the rule such that
when set
(and only when set) older clients get excluded by way of changing the
objectlass or something else to similar effect.

Open to discussion.

At this point using new object class becomes an attractive approach. We
don't have means to exclude HBAC rules other than applying them
per-host/hostgroup. We also have no deny rules.

I have another idea: what about enforcing time rules always to apply
per-host or per-hostgroup by default? Add --force option to override
the
behavior but default to not allow --hostcat=all. This would raise
awareness and make sure admins are actually applying these rules with
intention.

This sounds like a good idea, but it is not a silver bullet I am afraid.

Simo.

I was thinking that for future proofing we could add a version field,
then reasoned more and realized that changing the object class is
basically the same thing.

There is only one big problem, ipaHBACRule is a STRUCTURAL objectclass.
(I know 389ds allows us to do an LDAPv3 illegal operation and change it,
but I do not like to depend on that behavoir).

Now looking into this I had an idea to solve the problem of legacy
clients without having to swap classes.
We can redefine the accessRuleType attribute to be a "capability" type.

Ie rules that have a timeAccess component will be of type
"allow_with_time" instead of just "allow".
Old clients are supposed to search with accessRuleType=allow (and I can
see that SSSD does that), so an older client will fail to get those
rules as they won't match.

New clients instead can recognize both types.

Also if we need a future extension we will simpy add a new access rule
type and we can have the same effect.
The nice thing is that accessRyleType is defined as multivalue (no
SINGLE in schema) so we may actually create compatible rules if we want
to.
Ie we could set both "allow" and "allow_with_time" on an object for
cases where the admin wants to enforce the time part only o newer client
but otherwise apply the rule to any client.

This should give us the best of all options at once.

Thoughts ?

Simo.


Sorry to join the discussion so late, I was away yesterday.

I have to say I too like this idea much better than fiddling with the
objectClasses.


Note that the resulting code will be exactly the same except for the 
attribute name - you won't be fiddling with objectClass but with 
attributeRuleType.



Also, I believe that accessRuleType was originally
actually used to distinguish newer v

Re: [Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

2016-08-26 Thread Alexander Bokovoy

On Fri, 26 Aug 2016, Simo Sorce wrote:

On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote:

> I miss "why" part of "To be able to handle backward compatibility
with
> ease, a new object called ipaHBACRulev2 is introduced. " in the
design
> page. If the reason is the above - old client's should ignore time
rules
> then it has to be mentioned there. Otherwise I don't see a reason to
> introduce a new object type instead of extending the current.

How do you want to enforce HBAC rule that have set time from 10 to 14
everyday? With the same objectclass old clients will allow this HBAC
for
all day. Isn't this CVE?

This is a discussion worth having.

In general it is a CVE only if an authorization mechanism fails to work
as advertised.

If you make it clear that old clients *DO NOT* respect time rules then
there is no CVE material, it is working as "described".

The admins already have a way to not set those rules for older clients
by simply grouping newer clients in a different host group and applying
time rules only there.

So the question really is: should we allow admins to apply an HBAC Rule
potentially to older clients that do not understand it and will
therefore allow access at any time of the day, or should we prevent it ?

This is a hard question to answer and can go both ways.

A time rule may be something that admins want to enforce at all cost or
deny access. In this case a client that fails to handle it would be a
problem.

But it may be something that is just used for defense in depth and not a
strictly hard requirement. In this case allowing older clients would
make it an easy transition as you just set up the rule and the client
will start enforcing the time when it is upgraded but work otherwise
with the same rules.

I am a bit conflicted on trying to decide what scenario we should
target, but the second one appeals to me because host groups do already
give admins a good way to apply rules to a specific set of hosts and
exclude old clients w/o us making it a hard rule.
OTOH if an admin does not understand this difference, they may be
surprised to find out there are clients that do not honor it.

Perhaps we could find a way to set a flag on the rule such that when set
(and only when set) older clients get excluded by way of changing the
objectlass or something else to similar effect.

Open to discussion.

At this point using new object class becomes an attractive approach. We
don't have means to exclude HBAC rules other than applying them
per-host/hostgroup. We also have no deny rules.

I have another idea: what about enforcing time rules always to apply
per-host or per-hostgroup by default? Add --force option to override the
behavior but default to not allow --hostcat=all. This would raise
awareness and make sure admins are actually applying these rules with
intention.

--
/ 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] [DESIGN][UPDATE] Time-Based HBAC Policies

2016-08-26 Thread Alexander Bokovoy


On Fri, 26 Aug 2016, Jan Cholasta wrote:

On 26.8.2016 11:55, Martin Basti wrote:



On 26.08.2016 11:43, Jan Cholasta wrote:

Hi,

On 11.8.2016 12:34, Stanislav Laznicka wrote:

Hello,

I updated the design of the Time-Based HBAC Policies according to the
discussion we led here earlier. Please check the design page
http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest
changes are in the Implementation and Feature Management sections. I
also added a short How to Use section.


1) Please use the 'ipa' prefix for new attributes: memberTimeRule ->
ipaMemberTimeRule


2) Source hosts are deprecated and thus should be removed from
ipaHBACRuleV2.


3) Since time rules are defined by memberTimeRule, accessTime should
be removed from ipaHBACRuleV2.


ad 2) 3)

Because backward compatibility, ipaHBACRuleV2 must contain all
attributes from ipaHBACRule as MAY


Not true.



With current approach, when timerule is added to HBAC, we just change
objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all
attributes that was defined in older HBAC. Removing any attrs from
ipaHBACRuleV2 can cause schema violation.


Which is perfectly fine.




I'm not sure if want to handle this in code (removing deprecated
attributes from HBAC entry when timerule is added)


We don't have to do anything. If any of the deprecated attributes are 
present when you change the object class (which they shouldn't 
anyway), you'll get schema violation, otherwise it will work just 
fine.




I realized that AccessTime is MUST for 'ipahbacrule', so when timerule
('ipahbacrulev2') is removed and somebody deleted accesstime we have to
add it back.


It is MAY. The only MUST attribute is accessRuleType, but that is 
deprecated as well and should be removed from ipaHBACRuleV2. We only 
support allow rules, so when timerule is removed, that's the value you 
set accessRuleType to.


SSSD does search for HBAC rules by '(objectclass=ipaHBACRule)' filter.
Changing to ipaHBACRuleV2 means these rules will not be found by older
SSSD versions and therefore people will experience problems with older
clients not being able to use new rules even if they would lack time
component.

--
/ 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] 0220 move /bin/ipa to freeipa-client

2016-08-25 Thread Alexander Bokovoy


On Thu, 25 Aug 2016, Jan Cholasta wrote:

Hi,

On 25.8.2016 11:27, Alexander Bokovoy wrote:

Hi,

attached patch moves ipa CLI to freeipa-client and obsoletes
freeipa-admintools


The Obsoletes (both) should be on version < 4.4.1 rather than 
%{version}, as per Fedora packaging guidelines [1].


Please move the Obsoletes and Provides on %{name}-admintools right 
below Group (Obsoletes first) and put a newline between the 
%{alt_name}-client and %{alt_name}-admintools blocks, for consistent 
layout accross all subpackages in the spec file.




Solves https://fedorahosted.org/freeipa/ticket/5934

Here is how upgrade looks when running 'dnf':

Upgrading:
freeipa-client x86_64
4.4.0.201608250913GIT9c20682-0.fc24@commandline
146 k
   replacing  freeipa-admintools.noarch
4.4.0.201608051228GIT590e30f-0.fc24


I'm going to test with yum as well, for RHEL and CentOS.

Updated patch attached.

--
/ Alexander Bokovoy
From 2256c872ec31223c8d1c3dcfbf715326ccd0b2b2 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy <aboko...@redhat.com>
Date: Thu, 25 Aug 2016 11:59:34 +0300
Subject: [PATCH 2/2] freeipa.spec.in: move ipa CLI utility to freeipa-client

There is no notable package size cost, as all the libraries and
packages are already in the freeipa-client package and
freeipa-admintools only contained a short shim calling this code.

Move /bin/ipa to freeipa-client, along with a man page and bash
completion.

Resolves: https://fedorahosted.org/freeipa/ticket/5934
---
 freeipa.spec.in | 43 ---
 1 file changed, 12 insertions(+), 31 deletions(-)

diff --git a/freeipa.spec.in b/freeipa.spec.in
index e3ad5b6..589060b 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -1,4 +1,4 @@
-# Define ONLY_CLIENT to only make the ipa-admintools, ipa-client and ipa-python
+# Define ONLY_CLIENT to only make the ipa-client and ipa-python
 # subpackages
 %{!?ONLY_CLIENT:%global ONLY_CLIENT 0}
 
@@ -135,7 +135,6 @@ Summary: The IPA authentication server
 Group: System Environment/Base
 Requires: %{name}-server-common = %{version}-%{release}
 Requires: %{name}-client = %{version}-%{release}
-Requires: %{name}-admintools = %{version}-%{release}
 Requires: %{name}-common = %{version}-%{release}
 Requires: python2-ipaserver = %{version}-%{release}
 Requires: 389-ds-base >= 1.3.5.6
@@ -350,6 +349,13 @@ Provides: %{alt_name}-client = %{version}
 Conflicts: %{alt_name}-client
 Obsoletes: %{alt_name}-client < %{version}
 
+Provides: %{alt_name}-admintools = %{version}
+Conflicts: %{alt_name}-admintools
+Obsoletes: %{alt_name}-admintools < 4.4.1
+
+Obsoletes: %{name}-admintools < 4.4.1
+Provides: %{name}-admintools = %{version}-%{release}
+
 %description client
 IPA is an integrated solution to provide centrally managed Identity (users,
 hosts, services), Authentication (SSO, 2FA), and Authorization
@@ -358,6 +364,7 @@ features for further integration with Linux based clients 
(SUDO, automount)
 and integration with Active Directory based infrastructures (Trusts).
 If your network uses IPA for authentication, this package should be
 installed on every client machine.
+This package provides command-line tools for IPA administrators.
 
 
 %package -n python2-ipaclient
@@ -423,26 +430,6 @@ If your network uses IPA for authentication, this package 
should be
 installed on every client machine.
 
 
-%package admintools
-Summary: IPA administrative tools
-Group: System Environment/Base
-BuildArch: noarch
-Requires: python2-ipaclient = %{version}-%{release}
-Requires: python-ldap
-
-Provides: %{alt_name}-admintools = %{version}
-Conflicts: %{alt_name}-admintools
-Obsoletes: %{alt_name}-admintools < %{version}
-
-%description admintools
-IPA is an integrated solution to provide centrally managed Identity (users,
-hosts, services), Authentication (SSO, 2FA), and Authorization
-(host access control, SELinux user roles, services). The solution provides
-features for further integration with Linux based clients (SUDO, automount)
-and integration with Active Directory based infrastructures (Trusts).
-This package provides command-line tools for IPA administrators.
-
-
 %package python-compat
 Summary: Compatiblity package for Python libraries used by IPA
 Group: System Environment/Libraries
@@ -1293,6 +1280,9 @@ fi
 %{_sbindir}/ipa-getkeytab
 %{_sbindir}/ipa-rmkeytab
 %{_sbindir}/ipa-join
+%{_bindir}/ipa
+%config %{_sysconfdir}/bash_completion.d
+%{_mandir}/man1/ipa.1.gz
 %{_mandir}/man1/ipa-getkeytab.1.gz
 %{_mandir}/man1/ipa-rmkeytab.1.gz
 %{_mandir}/man1/ipa-client-install.1.gz
@@ -1352,15 +1342,6 @@ fi
 %{_mandir}/man5/default.conf.5.gz
 
 
-%files admintools
-%defattr(-,root,root,-)
-%doc README Contributors.txt
-%license COPYING
-%{_bindir}/ipa
-%config %{_sysconfdir}/bash_completion.d
-%{_mandir}/man1/ipa.1.gz
-
-
 %files python-compat
 %defattr(-,root,root,-)
 %doc README Contributors.txt
-- 
2.7.4

-- 
Manage your subscription for t

[Freeipa-devel] [PATCH] 0220 move /bin/ipa to freeipa-client

2016-08-25 Thread Alexander Bokovoy


Hi,

attached patch moves ipa CLI to freeipa-client and obsoletes
freeipa-admintools

Solves https://fedorahosted.org/freeipa/ticket/5934

Here is how upgrade looks when running 'dnf':

Upgrading:
freeipa-client x86_64 
4.4.0.201608250913GIT9c20682-0.fc24@commandline 146 k
replacing  freeipa-admintools.noarch 4.4.0.201608051228GIT590e30f-0.fc24

--
/ Alexander Bokovoy
From 8a22131718cf6fdbff380ff447b502d22c735f1a Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy <aboko...@redhat.com>
Date: Thu, 25 Aug 2016 11:59:34 +0300
Subject: [PATCH] freeipa.spec.in: move ipa CLI utility to freeipa-client

There is no notable package size cost, as all the libraries and
packages are already in the freeipa-client package and
freeipa-admintools only contained a short shim calling this code.

Move /bin/ipa to freeipa-client, along with a man page and bash
completion.

Resolves: https://fedorahosted.org/freeipa/ticket/5934
---
 freeipa.spec.in | 41 ++---
 1 file changed, 10 insertions(+), 31 deletions(-)

diff --git a/freeipa.spec.in b/freeipa.spec.in
index e3ad5b6..a9308dd 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -1,4 +1,4 @@
-# Define ONLY_CLIENT to only make the ipa-admintools, ipa-client and ipa-python
+# Define ONLY_CLIENT to only make the ipa-client and ipa-python
 # subpackages
 %{!?ONLY_CLIENT:%global ONLY_CLIENT 0}
 
@@ -135,7 +135,6 @@ Summary: The IPA authentication server
 Group: System Environment/Base
 Requires: %{name}-server-common = %{version}-%{release}
 Requires: %{name}-client = %{version}-%{release}
-Requires: %{name}-admintools = %{version}-%{release}
 Requires: %{name}-common = %{version}-%{release}
 Requires: python2-ipaserver = %{version}-%{release}
 Requires: 389-ds-base >= 1.3.5.6
@@ -349,6 +348,11 @@ Requires(post): policycoreutils
 Provides: %{alt_name}-client = %{version}
 Conflicts: %{alt_name}-client
 Obsoletes: %{alt_name}-client < %{version}
+Provides: %{name}-admintools = %{version}-%{release}
+Obsoletes: %{name}-admintools < %{version}
+Provides: %{alt_name}-admintools = %{version}
+Conflicts: %{alt_name}-admintools
+Obsoletes: %{alt_name}-admintools < %{version}
 
 %description client
 IPA is an integrated solution to provide centrally managed Identity (users,
@@ -358,6 +362,7 @@ features for further integration with Linux based clients 
(SUDO, automount)
 and integration with Active Directory based infrastructures (Trusts).
 If your network uses IPA for authentication, this package should be
 installed on every client machine.
+This package provides command-line tools for IPA administrators.
 
 
 %package -n python2-ipaclient
@@ -423,26 +428,6 @@ If your network uses IPA for authentication, this package 
should be
 installed on every client machine.
 
 
-%package admintools
-Summary: IPA administrative tools
-Group: System Environment/Base
-BuildArch: noarch
-Requires: python2-ipaclient = %{version}-%{release}
-Requires: python-ldap
-
-Provides: %{alt_name}-admintools = %{version}
-Conflicts: %{alt_name}-admintools
-Obsoletes: %{alt_name}-admintools < %{version}
-
-%description admintools
-IPA is an integrated solution to provide centrally managed Identity (users,
-hosts, services), Authentication (SSO, 2FA), and Authorization
-(host access control, SELinux user roles, services). The solution provides
-features for further integration with Linux based clients (SUDO, automount)
-and integration with Active Directory based infrastructures (Trusts).
-This package provides command-line tools for IPA administrators.
-
-
 %package python-compat
 Summary: Compatiblity package for Python libraries used by IPA
 Group: System Environment/Libraries
@@ -1293,6 +1278,9 @@ fi
 %{_sbindir}/ipa-getkeytab
 %{_sbindir}/ipa-rmkeytab
 %{_sbindir}/ipa-join
+%{_bindir}/ipa
+%config %{_sysconfdir}/bash_completion.d
+%{_mandir}/man1/ipa.1.gz
 %{_mandir}/man1/ipa-getkeytab.1.gz
 %{_mandir}/man1/ipa-rmkeytab.1.gz
 %{_mandir}/man1/ipa-client-install.1.gz
@@ -1352,15 +1340,6 @@ fi
 %{_mandir}/man5/default.conf.5.gz
 
 
-%files admintools
-%defattr(-,root,root,-)
-%doc README Contributors.txt
-%license COPYING
-%{_bindir}/ipa
-%config %{_sysconfdir}/bash_completion.d
-%{_mandir}/man1/ipa.1.gz
-
-
 %files python-compat
 %defattr(-,root,root,-)
 %doc README Contributors.txt
-- 
2.7.4

-- 
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 0213] support multiple uid values in slapi-nis users map

2016-08-25 Thread Alexander Bokovoy


On Tue, 23 Aug 2016, thierry bordaz wrote:

acceptance is now completed (successfully).  ACK


bump

so ACKed ab's 213-1 fixes https://fedorahosted.org/freeipa/ticket/6138 ?


Yes that is my understanding. patch 213-1 fixes #6138.
I verified that lookup of UPN entries does return the domain. But did 
not know how to check that entries with multiple uid values only 
returns the first value.

Can we push 0213-1?
--
/ 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 0019] Corrected minor spell check in AD Trust information doc messages

2016-08-22 Thread Alexander Bokovoy


On Mon, 22 Aug 2016, Abhijeet Kasurde wrote:

Hi All,

Please find the patch attached.

It's a minor spelling correction so, I have not created ticket for this.


ACK.

--
/ 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 0038][Tests] ID views does not recognize ipakrboktoauthasdelegate attribute

2016-08-22 Thread Alexander Bokovoy


On Mon, 22 Aug 2016, Lenka Doudova wrote:

Hi,

due to implementation of [1] some ID views tests fail because they do 
not recognize ipakrboktoauthasdelegate attribute. Providing fix for 
this.


Ticket: https://fedorahosted.org/freeipa/ticket/6241

ACK.

--
/ 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 0214] Support schema files for external plugins

2016-08-19 Thread Alexander Bokovoy


On Fri, 19 Aug 2016, Martin Basti wrote:



On 19.08.2016 11:43, Alexander Bokovoy wrote:

On Mon, 08 Aug 2016, Alexander Bokovoy wrote:

On Mon, 08 Aug 2016, Petr Vobornik wrote:

On 08/08/2016 12:26 PM, Alexander Bokovoy wrote:

On Mon, 08 Aug 2016, Alexander Bokovoy wrote:

Hi!

Attached patch is what is needed to allow external plugins 
for FreeIPA

framework to be functional if they need to extend a schema.

The idea is that we would have a separate directory as
/usr/share/ipa/schema.d and will allow to use schema 
(*.ldif) files from

it and its subdirectories during install and upgrade stages.

Without the patch only selected schema files from /usr/share/ipa are
used during install and upgrade. This leads to a failure to 
install IPA

server (or upgrade it) if a new plugin is added. If plugin defines
managed permissions, upgrade tool will generate ACIs which 
will fail to
be inserted into LDAP store due to references to missing 
attributes and

object classes.

The patch adds a directory to be installed and a helper utility that
loads files from the directory and adds them to the list of 
schema files

used during update of dsinstance and upgrade of the server.

With this patch I'm successfully managed to make FleetCommander
integration plugin completely independent of FreeIPA.

Patch attached now. ;)



I'll assume that we want to target 4.4.x therefore it can be pushed to
master, right? I.e. no need for creating ipa-4-4 branch atm.

Right.


Reasoning is that currently F24 has 4.3.x. F25 will most likely have
4.4.x because 4.5 is still in planning.

Sounds good to me. FleetCommander (which is one of drivers behind the
patches) is targeting F25 as well.

Can we get the patch reviewed?


ACK

However ticket is in future releases, so we have to branch master and 
ipa 4.4 before push

Why? We agreed above to get the patch into 4.4. Moving ticket to 4.4.1
milestone is certainly possible and does not require branching.
--
/ 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 0214] Support schema files for external plugins

2016-08-19 Thread Alexander Bokovoy


On Mon, 08 Aug 2016, Alexander Bokovoy wrote:

On Mon, 08 Aug 2016, Petr Vobornik wrote:

On 08/08/2016 12:26 PM, Alexander Bokovoy wrote:

On Mon, 08 Aug 2016, Alexander Bokovoy wrote:

Hi!

Attached patch is what is needed to allow external plugins for FreeIPA
framework to be functional if they need to extend a schema.

The idea is that we would have a separate directory as
/usr/share/ipa/schema.d and will allow to use schema (*.ldif) files from
it and its subdirectories during install and upgrade stages.

Without the patch only selected schema files from /usr/share/ipa are
used during install and upgrade. This leads to a failure to install IPA
server (or upgrade it) if a new plugin is added. If plugin defines
managed permissions, upgrade tool will generate ACIs which will fail to
be inserted into LDAP store due to references to missing attributes and
object classes.

The patch adds a directory to be installed and a helper utility that
loads files from the directory and adds them to the list of schema files
used during update of dsinstance and upgrade of the server.

With this patch I'm successfully managed to make FleetCommander
integration plugin completely independent of FreeIPA.

Patch attached now. ;)



I'll assume that we want to target 4.4.x therefore it can be pushed to
master, right? I.e. no need for creating ipa-4-4 branch atm.

Right.


Reasoning is that currently F24 has 4.3.x. F25 will most likely have
4.4.x because 4.5 is still in planning.

Sounds good to me. FleetCommander (which is one of drivers behind the
patches) is targeting F25 as well.

Can we get the patch reviewed?
--
/ 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 0215-0216] Child domain fixes for AD trust

2016-08-19 Thread Alexander Bokovoy


On Wed, 17 Aug 2016, Martin Babinsky wrote:

On 08/08/2016 01:27 PM, Alexander Bokovoy wrote:

Hi!

Attached two patches attempt to fix some of the issues we see with child
domains.

SSSD only 'sees' users from child domains if there is an ID range for
each of them. However, after refactoring of trust code when external
trust was introduced, part of the range creation had wrong assumption
that if a trusted domain exists, its range also exists. This is now
fixed to try to create range even if the domain exists. In fact, because
the older code was not going to the range creation for trusted domains
which already existed, adding ranges was done incorrectly: ID ranges use
full domain name and don't need - hierarchy, but the code
was passing both parent and the child names. As result, an attempt to
create an ID range for parent was done instead of the child. Parent ID
range already existed so we never got to create child ID ranges at all
in that case.

Finally, there is a fix in SSSD to properly generate CA paths so that
libkrb5 can calculate correct trust path via forest root (parent)
domain. While looking at that, I also decided to simplify logic in
ipa-kdb driver because for cross-forest trust we never can transit to
the child domain directly, we always have to use the forest root domain.
However, old code could actually set a immediate domain's parent instead
of the forest root for deep level trust relationship within the forest
we trust. As we still cannot get to second level or beyond directly or
via their actual parent domain, we always have to go through the forest
root domain. The simplified code enforces this logic.






ACK, but patch 215 needs rebase for ipa-4-3 and ipa-4-2.


Rebased version attached.
--
/ Alexander Bokovoy
From 62f3af93ca780921355d8ed17ab6d9c42e452cb3 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy <aboko...@redhat.com>
Date: Sat, 6 Aug 2016 11:12:13 +0300
Subject: [PATCH 1/3] trust: make sure ID range is created for the child domain
 even if it exists

ID ranges for child domains of a forest trust were created incorrectly
in FreeIPA 4.4.0 due to refactoring of -- if the domain was already
existing, we never attempted to create the ID range for it.

At the same time, when domain was missing, we attempted to add ID range
and passed both forest root and the child domain names to add_range().
However, add_range() only looks at the first positional argument which
was the forest root name. That ID range always exists (it is created
before child domains are processed).

Modify the code to make sure child domain name is passed as the first
positional argument. In addition, the oddjob helper should explicitly
set context='server' so that idrange code will be able to see and use
ipaserver/dcerpc.py helpers.

Resolves: https://fedorahosted.org/freeipa/ticket/5738
---
 install/oddjob/com.redhat.idm.trust-fetch-domains |  2 +-
 ipalib/plugins/trust.py   | 13 +
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/install/oddjob/com.redhat.idm.trust-fetch-domains 
b/install/oddjob/com.redhat.idm.trust-fetch-domains
index 4c50c43..f5ec8d7 100755
--- a/install/oddjob/com.redhat.idm.trust-fetch-domains
+++ b/install/oddjob/com.redhat.idm.trust-fetch-domains
@@ -75,7 +75,7 @@ env._bootstrap(context='server', debug=options.debug, 
log=None)
 env._finalize_core(**dict(DEFAULT_CONFIG))
 
 # Initialize the API with the proper debug level
-api.bootstrap(context='server', debug=env.debug, log=None)
+api.bootstrap(in_server=True, debug=env.debug, log=None, context='server')
 api.finalize()
 
 # Only import trust plugin after api is initialized or internal imports
diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py
index 8672669..c2e5745 100644
--- a/ipalib/plugins/trust.py
+++ b/ipalib/plugins/trust.py
@@ -1592,14 +1592,19 @@ def add_new_domains_from_trust(myapi, trustinstance, 
trust_entry, domains, **opt
 if 'raw' in options:
 dom['raw'] = options['raw']
 
-res = myapi.Command.trustdomain_add(trust_name, name, **dom)
-result.append(res['result'])
+try:
+res = myapi.Command.trustdomain_add(trust_name, name, **dom)
+result.append(res['result'])
+except errors.DuplicateEntry:
+# Ignore updating duplicate entries
+pass
 
 if idrange_type != u'ipa-ad-trust-posix':
 range_name = name.upper() + '_id_range'
 dom['range_type'] = u'ipa-ad-trust'
-add_range(myapi, trustinstance, range_name, 
dom['ipanttrusteddomainsid'],
-  trust_name, name, **dom)
+add_range(myapi, trustinstance,
+  range_name, dom['ipanttrusteddomainsid'],
+  name, **dom)
 except errors.DuplicateEntry:
 # Ignore updating duplicate entries
 pass
-- 
2.7.4

--

Re: [Freeipa-devel] [PATCH] 0001 Added new authentication method


On Thu, 11 Aug 2016, Petr Vobornik wrote:

On 08/11/2016 07:21 PM, Martin Basti wrote:



On 11.08.2016 18:57, Pavel Vomacka wrote:



On 08/11/2016 02:00 PM, Petr Vobornik wrote:

On 08/11/2016 10:54 AM, Alexander Bokovoy wrote:

On Thu, 11 Aug 2016, Jan Cholasta wrote:

On 4.8.2016 17:27, Jan Pazdziora wrote:

On Wed, Aug 03, 2016 at 10:29:52AM +0300, Alexander Bokovoy wrote:

Got it. One thing I would correct, though, -- don't use
kadmin.local, we
do support setting ok_as_delegate on the service principals via IPA
CLI:
$ ipa service-mod --help |grep -A1 ok-as-delegate
--ok-as-delegate=BOOL
   Client credentials may be delegated to the
service

I've tried

 ipa service-mod --ok-as-delegate=True HTTP/$(hostname)

but that does not seem to have the same effect as

 modprinc +ok_to_auth_as_delegate HTTP/ipa.example.test

-- obtaining the delegated certificated fails.

That's because ok_as_delegate and ok_to_auth_as_delegate are different
flags.

Right. The following patch adds ok_to_auth_as_delegate to the service
principal.

I haven't added any tickets to it yet.



This might deserve also nice Web UI checkbox similar to "Trusted for
delegation". CCing Pavel.


Here is patch with new checkbox. It is without ticket in commit message so
once we will have the ticket I will send another patch witch updated commit
message.


https://fedorahosted.org/freeipa/newticket

;-)


It's prerequisite for https://fedorahosted.org/freeipa/ticket/5764 so we
might use that.

Sounds good. Patch with updated commit message is attached.

--
/ Alexander Bokovoy
From e2cebaa4e4b30b588d484e111cb11779cb863c0f Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy <aboko...@redhat.com>
Date: Thu, 11 Aug 2016 11:52:05 +0300
Subject: [PATCH 06/10] service: add flag to allow S4U2Self

Prerequisite for: https://fedorahosted.org/freeipa/ticket/5764
---
 API.txt  | 12 
 VERSION  |  4 ++--
 ipaserver/plugins/service.py |  7 +++
 3 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/API.txt b/API.txt
index 535d8ec..5b83bfb 100644
--- a/API.txt
+++ b/API.txt
@@ -2260,7 +2260,7 @@ output: Output('summary', type=[, ])
 output: Output('value', type=[])
 output: Output('warning', type=[, , ])
 command: host_add/1
-args: 1,24,3
+args: 1,25,3
 arg: Str('fqdn', cli_name='hostname')
 option: Str('addattr*', cli_name='addattr')
 option: Flag('all', autofill=True, cli_name='all', default=False)
@@ -2269,6 +2269,7 @@ option: Flag('force', autofill=True, default=False)
 option: Str('ip_address?')
 option: Str('ipaassignedidview?')
 option: Bool('ipakrbokasdelegate?', cli_name='ok_as_delegate')
+option: Bool('ipakrboktoauthasdelegate?', cli_name='ok_to_auth_as_delegate')
 option: Bool('ipakrbrequirespreauth?', cli_name='requires_pre_auth')
 option: Str('ipasshpubkey*', cli_name='sshpubkey')
 option: Str('krbprincipalauthind*', cli_name='auth_ind')
@@ -2437,7 +2438,7 @@ output: ListOfEntries('result')
 output: Output('summary', type=[, ])
 output: Output('truncated', type=[])
 command: host_mod/1
-args: 1,25,3
+args: 1,26,3
 arg: Str('fqdn', cli_name='hostname')
 option: Str('addattr*', cli_name='addattr')
 option: Flag('all', autofill=True, cli_name='all', default=False)
@@ -2445,6 +2446,7 @@ option: Str('delattr*', cli_name='delattr')
 option: Str('description?', autofill=False, cli_name='desc')
 option: Str('ipaassignedidview?', autofill=False)
 option: Bool('ipakrbokasdelegate?', autofill=False, cli_name='ok_as_delegate')
+option: Bool('ipakrboktoauthasdelegate?', autofill=False, 
cli_name='ok_to_auth_as_delegate')
 option: Bool('ipakrbrequirespreauth?', autofill=False, 
cli_name='requires_pre_auth')
 option: Str('ipasshpubkey*', autofill=False, cli_name='sshpubkey')
 option: Str('krbprincipalauthind*', autofill=False, cli_name='auth_ind')
@@ -4293,13 +4295,14 @@ output: Entry('result')
 output: Output('summary', type=[, ])
 output: PrimaryKey('value')
 command: service_add/1
-args: 1,12,3
+args: 1,13,3
 arg: Principal('krbcanonicalname', cli_name='canonical_principal')
 option: Str('addattr*', cli_name='addattr')
 option: Flag('all', autofill=True, cli_name='all', default=False)
 option: Flag('force', autofill=True, default=False)
 option: StrEnum('ipakrbauthzdata*', cli_name='pac_type', values=[u'MS-PAC', 
u'PAD', u'NONE'])
 option: Bool('ipakrbokasdelegate?', cli_name='ok_as_delegate')
+option: Bool('ipakrboktoauthasdelegate?', cli_name='ok_to_auth_as_delegate')
 option: Bool('ipakrbrequirespreauth?', cli_name='requires_pre_auth')
 option: Str('krbprincipalauthind*', cli_name='auth_ind')
 option: Flag('no_members', autofill=True, default=False)
@@ -4435,13 +4438,14 @@ output: ListOfEntries('result')
 output: Output('summary', type=[, ])
 output: Output('truncated', type=[])
 command: service_mod/1
-args: 1,14,3
+args: 1,15,3
 arg: Principal('krbcanonicalname', cli_name='canonical_principal')
 option: Str('addattr*', cli_name='addattr')
 o

Re: [Freeipa-devel] [PATCH] 0207, 0218-0219 Solving trust conflicts and external trust topology fixes


On Wed, 17 Aug 2016, Martin Babinsky wrote:

On 08/17/2016 12:41 PM, Alexander Bokovoy wrote:

On Wed, 17 Aug 2016, Martin Babinsky wrote:

On 08/15/2016 06:06 PM, Alexander Bokovoy wrote:

On Mon, 15 Aug 2016, Alexander Bokovoy wrote:

Hi!

Attached are trust-related patches.

0207 is a pre-requisite. I did send it before, it is re-formatting of
the ipaserver/dcerpc.py to be close to PEP8 requirements.

0218 is an automated trust topology conflict resolver for DNS namespace
conflicts. Read the commit message for details, and also comments in
the
code. With this patch FreeIPA becomes more smart than Windows Server
which doesn't have automated trust topology conflict resolution. ;)

0219 fixes issue of topology details leaking through external trust.
The
problem is only in presentation as we store more data than needed -- it
is impossible to cross external trust boundary anyway as it is handled
by AD DC side, but one important consequence is that we need to store
UPN suffixes before we start storing information about child domains.
Again, read the commit message.

These patches also are on top of my previously sent patches 0215-0216.

Patches attached.





Hi Alexander,

patch 207: LGTM, but I have a feeling that the patch should be linked
to both #6021 and #6076 so that it is not lost during backports.

patch 218:

ipalib/errors.py:

1.)
I'm not sure if TrustTopologyConflictError should inherit from
InvocationError. The semantics of InvocationError implies that
something was wrong when trying to invoke the command (a param failed
to validate/convert, incorrect number of args, etc.), while this is
more of an exception during command execution (no. and type of params
was correct, command started to execute but encountered an error
condition). Thus I think it should inherit from ExecutionError. CC'ing
Jan for more thoughts on this.

2.)

Why is TrustTopologyConflictSolved listed amogn public errors? Since
it is used only in dcerpc.py to restart trust establishment after
resolving conflicts, it should be a private exception in dcerpc.py for
this purpose.

3.)
Also please split the exception format string like this so that the
line is not too long (there is not much we can do about doctest so
leave that line as it is):

@@ -882,7 +882,8 @@ class TrustTopologyConflictError(InvocationError):
   """

   errno = 3017
-format = _("Forest '%(forest)s' has existing trust to forest(s)
%(domains)s which prevents a trust to '%(conflict)s'")
+format = _("Forest '%(forest)s' has existing trust to forest(s) "
+   "%(domains)s which prevents a trust to '%(conflict)s'")

Do not worry about gettext, it can handle it just fine, there are
plenty of examples in server plugins, for example.


ipaserver/dcerpc.py:

1.)

I think that instead of returning result and raising
TrustTopologyConflictError based on that, the 'clear_ftinfo_conflict'
can raise this exception directly. You can have an empty list defined
at the beginning instead of 'result list', append unresolvable
conflicts to it and then at the end of the method check if it is
non-empty and raise the exception.

2.)

+# In the code below:
+# self -- the forest we establish trust to
+# another_domain -- a forest that establishes trust to 'self'
+# cinfo -- lsa_ForestTrustCollisionInfo structure that contain
+#  set of of lsa_ForestTrustCollisionRecord structures
I would add this directly into the method docstring:

"""
...

:param self: the forest we establish trust to
:param another_domain: a forest that establishes trust to 'self'
:param cinfo: lsa_ForestTrustCollisionInfo structure that contain
 set of of lsa_ForestTrustCollisionRecord structures
"""

Additionally, the behavior specifed in previous comment can be added
using :raises: stanza:

"""
:raises: errors.TrustTopologyConflictError if there are unresolvable
  namespace conflicts between trusted domains
"""

3.)

rewriting 'clear_ftinfo_conflict' according to point 1.) will allow to
simplify code in 'update_ftinfo' like this:

"""
-res = self.clear_ftinfo_conflict(another_domain, cinfo)
-if len(res[1]) != 0:
-domains = [x.name.string for x in res[1]]
-raise errors.TrustTopologyConflictError(
-  target=self.info['dns_domain'],
-
conflict=another_domain.info['dns_domain'],
-  domains=domains)
-else:
-raise errors.TrustTopologyConflictSolved(
-  target=self.info['dns_domain'],
-
conflict=another_domain.info['dns_domain'])
+self.clear_ftinfo_conflict(another_domain, cinfo)
+raise errors.TrustTopologyConflictSolved(
+target=self.info['dns_domain'],
+confli

Re: [Freeipa-devel] [PATCH] 0207, 0218-0219 Solving trust conflicts and external trust topology fixes


On Wed, 17 Aug 2016, Petr Spacek wrote:

On 17.8.2016 12:41, Alexander Bokovoy wrote:

On Wed, 17 Aug 2016, Martin Babinsky wrote:

On 08/15/2016 06:06 PM, Alexander Bokovoy wrote:

On Mon, 15 Aug 2016, Alexander Bokovoy wrote:

Hi!

Attached are trust-related patches.

0207 is a pre-requisite. I did send it before, it is re-formatting of
the ipaserver/dcerpc.py to be close to PEP8 requirements.

0218 is an automated trust topology conflict resolver for DNS namespace
conflicts. Read the commit message for details, and also comments in the
code. With this patch FreeIPA becomes more smart than Windows Server
which doesn't have automated trust topology conflict resolution. ;)

0219 fixes issue of topology details leaking through external trust. The
problem is only in presentation as we store more data than needed -- it
is impossible to cross external trust boundary anyway as it is handled
by AD DC side, but one important consequence is that we need to store
UPN suffixes before we start storing information about child domains.
Again, read the commit message.

These patches also are on top of my previously sent patches 0215-0216.

Patches attached.





Hi Alexander,

patch 207: LGTM, but I have a feeling that the patch should be linked to
both #6021 and #6076 so that it is not lost during backports.

patch 218:

ipalib/errors.py:

1.)
I'm not sure if TrustTopologyConflictError should inherit from
InvocationError. The semantics of InvocationError implies that something was
wrong when trying to invoke the command (a param failed to validate/convert,
incorrect number of args, etc.), while this is more of an exception during
command execution (no. and type of params was correct, command started to
execute but encountered an error condition). Thus I think it should inherit
from ExecutionError. CC'ing Jan for more thoughts on this.

2.)

Why is TrustTopologyConflictSolved listed amogn public errors? Since it is
used only in dcerpc.py to restart trust establishment after resolving
conflicts, it should be a private exception in dcerpc.py for this purpose.

3.)
Also please split the exception format string like this so that the line is
not too long (there is not much we can do about doctest so leave that line
as it is):

@@ -882,7 +882,8 @@ class TrustTopologyConflictError(InvocationError):
"""

errno = 3017
-format = _("Forest '%(forest)s' has existing trust to forest(s)
%(domains)s which prevents a trust to '%(conflict)s'")
+format = _("Forest '%(forest)s' has existing trust to forest(s) "
+   "%(domains)s which prevents a trust to '%(conflict)s'")

Do not worry about gettext, it can handle it just fine, there are plenty of
examples in server plugins, for example.


ipaserver/dcerpc.py:

1.)

I think that instead of returning result and raising
TrustTopologyConflictError based on that, the 'clear_ftinfo_conflict' can
raise this exception directly. You can have an empty list defined at the
beginning instead of 'result list', append unresolvable conflicts to it and
then at the end of the method check if it is non-empty and raise the exception.

2.)

+# In the code below:
+# self -- the forest we establish trust to
+# another_domain -- a forest that establishes trust to 'self'
+# cinfo -- lsa_ForestTrustCollisionInfo structure that contain
+#  set of of lsa_ForestTrustCollisionRecord structures
I would add this directly into the method docstring:

"""
...

:param self: the forest we establish trust to
:param another_domain: a forest that establishes trust to 'self'
:param cinfo: lsa_ForestTrustCollisionInfo structure that contain
  set of of lsa_ForestTrustCollisionRecord structures
"""

Additionally, the behavior specifed in previous comment can be added using
:raises: stanza:

"""
:raises: errors.TrustTopologyConflictError if there are unresolvable
   namespace conflicts between trusted domains
"""

3.)

rewriting 'clear_ftinfo_conflict' according to point 1.) will allow to
simplify code in 'update_ftinfo' like this:

"""
-res = self.clear_ftinfo_conflict(another_domain, cinfo)
-if len(res[1]) != 0:
-domains = [x.name.string for x in res[1]]
-raise errors.TrustTopologyConflictError(
-  target=self.info['dns_domain'],
-  conflict=another_domain.info['dns_domain'],
-  domains=domains)
-else:
-raise errors.TrustTopologyConflictSolved(
-  target=self.info['dns_domain'],
-  conflict=another_domain.info['dns_domain'])
+self.clear_ftinfo_conflict(another_domain, cinfo)
+raise errors.TrustTopologyConflictSolved(
+target=self.info

Re: [Freeipa-devel] [PATCH] 0207, 0218-0219 Solving trust conflicts and external trust topology fixes


On Wed, 17 Aug 2016, Martin Babinsky wrote:

Hi Alexander,

patch 207: LGTM, but I have a feeling that the patch should be linked 
to both #6021 and #6076 so that it is not lost during backports.


patch 218:

ipalib/errors.py:

1.)
I'm not sure if TrustTopologyConflictError should inherit from 
InvocationError. The semantics of InvocationError implies that 
something was wrong when trying to invoke the command (a param failed 
to validate/convert, incorrect number of args, etc.), while this is 
more of an exception during command execution (no. and type of params 
was correct, command started to execute but encountered an error 
condition). Thus I think it should inherit from ExecutionError. CC'ing 
Jan for more thoughts on this.

Using ExecutionError would work to me too, as long as we display the
error to a user. 

Why is TrustTopologyConflictSolved listed amogn public errors? Since 
it is used only in dcerpc.py to restart trust establishment after 
resolving conflicts, it should be a private exception in dcerpc.py for 
this purpose.

I originally wanted to make it a warning -- i.e. if we fixed the
conflict, return the result and show the warning that we did solve the
conflict. After all, the code is modifying another trusted forest's
topology on behalf of the user. I can move the error class to dcerpc.py



3.)
Also please split the exception format string like this so that the 
line is not too long (there is not much we can do about doctest so 
leave that line as it is):


@@ -882,7 +882,8 @@ class TrustTopologyConflictError(InvocationError):
"""

errno = 3017
-format = _("Forest '%(forest)s' has existing trust to forest(s) 
%(domains)s which prevents a trust to '%(conflict)s'")

+format = _("Forest '%(forest)s' has existing trust to forest(s) "
+   "%(domains)s which prevents a trust to '%(conflict)s'")

Do not worry about gettext, it can handle it just fine, there are 
plenty of examples in server plugins, for example.

Done.


ipaserver/dcerpc.py:

1.)

I think that instead of returning result and raising 
TrustTopologyConflictError based on that, the 'clear_ftinfo_conflict' 
can raise this exception directly. You can have an empty list defined 
at the beginning instead of 'result list', append unresolvable 
conflicts to it and then at the end of the method check if it is 
non-empty and raise the exception.

Good suggestion, fixed.



2.)

+# In the code below:
+# self -- the forest we establish trust to
+# another_domain -- a forest that establishes trust to 'self'
+# cinfo -- lsa_ForestTrustCollisionInfo structure that contain
+#  set of of lsa_ForestTrustCollisionRecord structures
I would add this directly into the method docstring:

"""
...

:param self: the forest we establish trust to
:param another_domain: a forest that establishes trust to 'self'
:param cinfo: lsa_ForestTrustCollisionInfo structure that contain
  set of of lsa_ForestTrustCollisionRecord structures
"""

Added.

Additionally, the behavior specifed in previous comment can be added 
using :raises: stanza:


"""
:raises: errors.TrustTopologyConflictError if there are unresolvable
   namespace conflicts between trusted domains
"""

Added.



3.)

rewriting 'clear_ftinfo_conflict' according to point 1.) will allow to 
simplify code in 'update_ftinfo' like this:


"""
-res = self.clear_ftinfo_conflict(another_domain, cinfo)
-if len(res[1]) != 0:
-domains = [x.name.string for x in res[1]]
-raise errors.TrustTopologyConflictError(
-  target=self.info['dns_domain'],
-  conflict=another_domain.info['dns_domain'],
-  domains=domains)
-else:
-raise errors.TrustTopologyConflictSolved(
-  target=self.info['dns_domain'],
-  conflict=another_domain.info['dns_domain'])
+self.clear_ftinfo_conflict(another_domain, cinfo)
+raise errors.TrustTopologyConflictSolved(
+target=self.info['dns_domain'],
+conflict=another_domain.info['dns_domain'])
"""

done.



Patch 218:

1.)
typo in the commit message:

"""
...
suffixes are forest-wide, there *are could be* user accounts in the
...
"""

Fixed.

Updated patches attached.
--
/ Alexander Bokovoy
From 4c6e1c5ce1eddd70aac5cf97075af3cf15bb951a Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy <aboko...@redhat.com>
Date: Mon, 15 Aug 2016 18:14:00 +0300
Subject: [PATCH 09/10] trust: automatically resolve DNS trust conflicts for
 triangle trusts

For configuration where:
  - AD example.com trusts IPA at ipa.example.com
  - AD example.org

Re: [Freeipa-devel] [PATCH] 0207, 0218-0219 Solving trust conflicts and external trust topology fixes


On Wed, 17 Aug 2016, Martin Babinsky wrote:

On 08/17/2016 12:13 PM, Martin Babinsky wrote:

On 08/15/2016 06:06 PM, Alexander Bokovoy wrote:

On Mon, 15 Aug 2016, Alexander Bokovoy wrote:

Hi!

Attached are trust-related patches.

0207 is a pre-requisite. I did send it before, it is re-formatting of
the ipaserver/dcerpc.py to be close to PEP8 requirements.

0218 is an automated trust topology conflict resolver for DNS namespace
conflicts. Read the commit message for details, and also comments in the
code. With this patch FreeIPA becomes more smart than Windows Server
which doesn't have automated trust topology conflict resolution. ;)

0219 fixes issue of topology details leaking through external trust. The
problem is only in presentation as we store more data than needed -- it
is impossible to cross external trust boundary anyway as it is handled
by AD DC side, but one important consequence is that we need to store
UPN suffixes before we start storing information about child domains.
Again, read the commit message.

These patches also are on top of my previously sent patches 0215-0216.

Patches attached.





Hi Alexander,

patch 207: LGTM, but I have a feeling that the patch should be linked to
both #6021 and #6076 so that it is not lost during backports.

patch 218:

ipalib/errors.py:

1.)
I'm not sure if TrustTopologyConflictError should inherit from
InvocationError. The semantics of InvocationError implies that something
was wrong when trying to invoke the command (a param failed to
validate/convert, incorrect number of args, etc.), while this is more of
an exception during command execution (no. and type of params was
correct, command started to execute but encountered an error condition).
Thus I think it should inherit from ExecutionError. CC'ing Jan for more
thoughts on this.

2.)

Why is TrustTopologyConflictSolved listed amogn public errors? Since it
is used only in dcerpc.py to restart trust establishment after resolving
conflicts, it should be a private exception in dcerpc.py for this purpose.

3.)
Also please split the exception format string like this so that the line
is not too long (there is not much we can do about doctest so leave that
line as it is):

@@ -882,7 +882,8 @@ class TrustTopologyConflictError(InvocationError):
"""

errno = 3017
-format = _("Forest '%(forest)s' has existing trust to forest(s)
%(domains)s which prevents a trust to '%(conflict)s'")
+format = _("Forest '%(forest)s' has existing trust to forest(s) "
+   "%(domains)s which prevents a trust to '%(conflict)s'")

Do not worry about gettext, it can handle it just fine, there are plenty
of examples in server plugins, for example.


ipaserver/dcerpc.py:

1.)

I think that instead of returning result and raising
TrustTopologyConflictError based on that, the 'clear_ftinfo_conflict'
can raise this exception directly. You can have an empty list defined at
the beginning instead of 'result list', append unresolvable conflicts to
it and then at the end of the method check if it is non-empty and raise
the exception.

2.)

+# In the code below:
+# self -- the forest we establish trust to
+# another_domain -- a forest that establishes trust to 'self'
+# cinfo -- lsa_ForestTrustCollisionInfo structure that contain
+#  set of of lsa_ForestTrustCollisionRecord structures
I would add this directly into the method docstring:

"""
...

:param self: the forest we establish trust to
:param another_domain: a forest that establishes trust to 'self'
:param cinfo: lsa_ForestTrustCollisionInfo structure that contain
 set of of lsa_ForestTrustCollisionRecord structures
"""

Additionally, the behavior specifed in previous comment can be added
using :raises: stanza:

"""
:raises: errors.TrustTopologyConflictError if there are unresolvable
   namespace conflicts between trusted domains
"""

3.)

rewriting 'clear_ftinfo_conflict' according to point 1.) will allow to
simplify code in 'update_ftinfo' like this:

"""
-res = self.clear_ftinfo_conflict(another_domain, cinfo)
-if len(res[1]) != 0:
-domains = [x.name.string for x in res[1]]
-raise errors.TrustTopologyConflictError(
-  target=self.info['dns_domain'],
-  conflict=another_domain.info['dns_domain'],
-  domains=domains)
-else:
-raise errors.TrustTopologyConflictSolved(
-  target=self.info['dns_domain'],
-  conflict=another_domain.info['dns_domain'])
+self.clear_ftinfo_conflict(another_domain, cinfo)
+raise errors.TrustTopologyConflictSolved(
+target=self.info['dns_domain'],
+c

Re: [Freeipa-devel] [PATCH] 0207, 0218-0219 Solving trust conflicts and external trust topology fixes


On Wed, 17 Aug 2016, Martin Babinsky wrote:

On 08/15/2016 06:06 PM, Alexander Bokovoy wrote:

On Mon, 15 Aug 2016, Alexander Bokovoy wrote:

Hi!

Attached are trust-related patches.

0207 is a pre-requisite. I did send it before, it is re-formatting of
the ipaserver/dcerpc.py to be close to PEP8 requirements.

0218 is an automated trust topology conflict resolver for DNS namespace
conflicts. Read the commit message for details, and also comments in the
code. With this patch FreeIPA becomes more smart than Windows Server
which doesn't have automated trust topology conflict resolution. ;)

0219 fixes issue of topology details leaking through external trust. The
problem is only in presentation as we store more data than needed -- it
is impossible to cross external trust boundary anyway as it is handled
by AD DC side, but one important consequence is that we need to store
UPN suffixes before we start storing information about child domains.
Again, read the commit message.

These patches also are on top of my previously sent patches 0215-0216.

Patches attached.





Hi Alexander,

patch 207: LGTM, but I have a feeling that the patch should be linked 
to both #6021 and #6076 so that it is not lost during backports.


patch 218:

ipalib/errors.py:

1.)
I'm not sure if TrustTopologyConflictError should inherit from 
InvocationError. The semantics of InvocationError implies that 
something was wrong when trying to invoke the command (a param failed 
to validate/convert, incorrect number of args, etc.), while this is 
more of an exception during command execution (no. and type of params 
was correct, command started to execute but encountered an error 
condition). Thus I think it should inherit from ExecutionError. CC'ing 
Jan for more thoughts on this.


2.)

Why is TrustTopologyConflictSolved listed amogn public errors? Since 
it is used only in dcerpc.py to restart trust establishment after 
resolving conflicts, it should be a private exception in dcerpc.py for 
this purpose.


3.)
Also please split the exception format string like this so that the 
line is not too long (there is not much we can do about doctest so 
leave that line as it is):


@@ -882,7 +882,8 @@ class TrustTopologyConflictError(InvocationError):
"""

errno = 3017
-format = _("Forest '%(forest)s' has existing trust to forest(s) 
%(domains)s which prevents a trust to '%(conflict)s'")

+format = _("Forest '%(forest)s' has existing trust to forest(s) "
+   "%(domains)s which prevents a trust to '%(conflict)s'")

Do not worry about gettext, it can handle it just fine, there are 
plenty of examples in server plugins, for example.



ipaserver/dcerpc.py:

1.)

I think that instead of returning result and raising 
TrustTopologyConflictError based on that, the 'clear_ftinfo_conflict' 
can raise this exception directly. You can have an empty list defined 
at the beginning instead of 'result list', append unresolvable 
conflicts to it and then at the end of the method check if it is 
non-empty and raise the exception.


2.)

+# In the code below:
+# self -- the forest we establish trust to
+# another_domain -- a forest that establishes trust to 'self'
+# cinfo -- lsa_ForestTrustCollisionInfo structure that contain
+#  set of of lsa_ForestTrustCollisionRecord structures
I would add this directly into the method docstring:

"""
...

:param self: the forest we establish trust to
:param another_domain: a forest that establishes trust to 'self'
:param cinfo: lsa_ForestTrustCollisionInfo structure that contain
  set of of lsa_ForestTrustCollisionRecord structures
"""

Additionally, the behavior specifed in previous comment can be added 
using :raises: stanza:


"""
:raises: errors.TrustTopologyConflictError if there are unresolvable
   namespace conflicts between trusted domains
"""

3.)

rewriting 'clear_ftinfo_conflict' according to point 1.) will allow to 
simplify code in 'update_ftinfo' like this:


"""
-res = self.clear_ftinfo_conflict(another_domain, cinfo)
-if len(res[1]) != 0:
-domains = [x.name.string for x in res[1]]
-raise errors.TrustTopologyConflictError(
-  target=self.info['dns_domain'],
-  conflict=another_domain.info['dns_domain'],
-  domains=domains)
-else:
-raise errors.TrustTopologyConflictSolved(
-  target=self.info['dns_domain'],
-  conflict=another_domain.info['dns_domain'])
+self.clear_ftinfo_conflict(another_domain, cinfo)
+raise errors.TrustTopologyConflictSolved(
+target=self.info['dns_domain'],
+confli

Re: [Freeipa-devel] [PATCH 0004-0012] Automatic CSR generation

2016-08-16 Thread Alexander Bokovoy


On Tue, 16 Aug 2016, Ben Lipton wrote:

On 08/10/2016 08:52 AM, Ben Lipton wrote:
The pull request at 
https://github.com/LiptonB/freeipa/pull/4/commits has been brought 
up to date (with a force push), and also includes 3 more patches, 
described below.


The patchset is also attached. To make sure that everything applies, 
I just regenerated the whole set, though there may not be meaningful 
changes.


After a discussion about how to address some of the concerns that have 
been voiced about this project, there have been some changes to the 
project direction. So, I wanted to provide an update about what the 
plans are. If you have objections or feel that I'm not representing it 
correctly, please let me know.


Since we have yet to see all the ways people will want to use this 
feature, the immediate goal is to provide something that we can 
iterate on. To make this easier, we will avoid storing rule data on 
the server or modifying the server schema, as those changes would need 
to be supported long term/handled correctly on update. I plan to 
approach this as follows:
- Separate the provider of mapping rules into a separate component 
from the generation of a config based on those rules
- Build an alternative rule provider that reads local files rather 
than querying IPA
- Move the implementation of CSR config formatting from the server API 
into a library (where should this go? ipalib? ipapython?), and then 
provide a client-side command that builds a config using the library.

Up to you -- ipapython is traditionally used for very basic dependencies
when nothing is configured and is used by both installers and the
framework, ipalib -- for common code in the framework itself.

- Templates for at least two profiles ("user" profile with 
CN=, subject and email address SAN, "service" 
profile with CN=, subject and DNS SAN) will be 
provided. Users will be able to build custom profiles by putting files 
in the appropriate directories on their client machines (but we will 
not guarantee backward compatibility for the format of these files).
- If we decide to move forward with storing rules on the server, the 
library call can be referenced from the server code, using the rule 
provider that pulls rules from the API. However, at that point we may 
also go in the direction of making automatic cert generation fully the 
responsibility of Dogtag, and keep the CSR-generation approach 
client-side only.


Comments welcome! Unless the changes are more complex than I 
anticipate, I hope to have a prototype of this approach for review by 
the end of this week.

The summary above looks fine.

--
/ 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] pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=ilt-gif-ipa01.ipa.preprod.local user=adu...@corp.addomain.com

2016-08-16 Thread Alexander Bokovoy

9
(ilt-gif-ipa02.ipa.preprod.local)
-sh-4.2$



]# ssh  adu...@corp.addomain.com@ilt-gif-ipa02.ipa.preprod.local
e600...@corp.corpcommon.com@ilt-gif-ipa02.ipa.preprod.local's password:
Permission denied, please try again.
e600...@corp.corpcommon.com@ilt-gif-ipa02.ipa.preprod.local's password:


Can you please help me i am not able to login with AD user
password authentication.

If you cannot login with password but can with Kerberos credentials, you
need to look into SSSD logs on the ilt-gif-ipa02.ipa.preprod.local host.
See https://fedorahosted.org/sssd/wiki/Troubleshooting


--
/ 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] [DESIGN][UPDATE] Time-Based HBAC Policies

2016-08-16 Thread Alexander Bokovoy


On Tue, 16 Aug 2016, Stanislav Laznicka wrote:

On 08/12/2016 06:48 PM, Petr Spacek wrote:

On 11.8.2016 12:34, Stanislav Laznicka wrote:

Hello,

I updated the design of the Time-Based HBAC Policies according to the
discussion we led here earlier. Please check the design page
http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The biggest
changes are in the Implementation and Feature Management sections. I also
added a short How to Use section.

Thank you for the review! I will add some comments inline.

Nice page!

On the high level it all makes sense.

ad LDAP schema
==
1) Why accessTime attribute is MAY in ipaTimeRule object class?
Does it make sense to have the object without accessTime? I do not think so.
My idea was that we allow users prepare a few time rule objects before 
filling them with the actual times.

Also, it could be good to add description attribute to the object class and
incorporate it into commands (including find).


Definitely a good idea, I will work that in.

2) Besides all this, I spent few minutes in dark history of IPA. The
accessTime attribute was introduced back in 2009 in commit
"55ba300c7cb59cf05b16cc01281f51d93eb25acf" aka "Incorporate new schema for 
IPAv2".

The commit does not contain any reasoning for the change but I can see that
the attribute is already used as MAY in old object classes ipaHBACRule and
ipaSELinuxUserMap.

Is any of these a problem?
I believe that the accessTime attribute was originally brought to IPA 
when there was an implementation of time policies for HBAC objects and 
it's been rotting there ever since those capabilities were removed. We 
may eventually use a new attribute for storage of the time strings as 
accessTime by definition is multi-valued which is not what's currently 
desired (although we may end up with it some day in the future). 
However, I don't think any other use of accessTime should be a problem 
as it's been obsoleted for a long time.

If the attribute can be used, let's use it. We can limit multiple values
in the framework and actively complain about multi-valued accessTime.


Why is it even in ipaSELinuxUserMap object class?
I'm sorry to say I have no idea. I used it for what it originally was 
- a means for storing time strings at HBAC rules.

accessTime was part of HBAC rule but when SELinuxUserMap support was
added, HBAC lost accessTime functionality --- that's why
ipaSELinuxUserMap object class carries accessTime attribute, to specify
the time when associated HBAC rule applies.

This is one more argument to re-use accessTime attribute.


--
/ 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] 0207, 0218-0219 Solving trust conflicts and external trust topology fixes

2016-08-15 Thread Alexander Bokovoy


On Mon, 15 Aug 2016, Alexander Bokovoy wrote:

Hi!

Attached are trust-related patches.

0207 is a pre-requisite. I did send it before, it is re-formatting of
the ipaserver/dcerpc.py to be close to PEP8 requirements.

0218 is an automated trust topology conflict resolver for DNS namespace
conflicts. Read the commit message for details, and also comments in the
code. With this patch FreeIPA becomes more smart than Windows Server
which doesn't have automated trust topology conflict resolution. ;)

0219 fixes issue of topology details leaking through external trust. The
problem is only in presentation as we store more data than needed -- it
is impossible to cross external trust boundary anyway as it is handled
by AD DC side, but one important consequence is that we need to store
UPN suffixes before we start storing information about child domains.
Again, read the commit message.

These patches also are on top of my previously sent patches 0215-0216.

Patches attached.

--
/ Alexander Bokovoy
From 356f5b81af065ee808ab953c7103ae536cd0136f Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy <aboko...@redhat.com>
Date: Tue, 7 Jun 2016 22:41:10 +0300
Subject: [PATCH 07/10] ipaserver/dcerpc: reformat to make the code closer to
 pep8

Because Samba Python bindings provide long-named methods and constants,
sometimes it is impossible to fit into 80 columns without causing
damage to readability of the code. This patchset attempts to reduce
pep8 complaints to a minimum.
---
 ipaserver/dcerpc.py | 473 +---
 1 file changed, 298 insertions(+), 175 deletions(-)

diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py
index 21ac89d..19be6bf 100644
--- a/ipaserver/dcerpc.py
+++ b/ipaserver/dcerpc.py
@@ -44,10 +44,12 @@ import samba
 import random
 from cryptography.hazmat.primitives.ciphers import Cipher, algorithms
 from cryptography.hazmat.backends import default_backend
+# pylint: disable=F0401
 try:
-from ldap.controls import RequestControl as LDAPControl #pylint: 
disable=F0401
+from ldap.controls import RequestControl as LDAPControl
 except ImportError:
-from ldap.controls import LDAPControl as LDAPControl#pylint: 
disable=F0401
+from ldap.controls import LDAPControl as LDAPControl
+# pylint: enable=F0401
 import ldap as _ldap
 from ipapython.ipaldap import IPAdmin
 from ipaserver.session import krbccache_dir, krbccache_prefix
@@ -74,7 +76,7 @@ and Samba4 python bindings.
 
 # Both constants can be used as masks against trust direction
 # because bi-directional has two lower bits set.
-TRUST_ONEWAY= 1
+TRUST_ONEWAY = 1
 TRUST_BIDIRECTIONAL = 3
 
 # Trust join behavior
@@ -91,31 +93,44 @@ def is_sid_valid(sid):
 return True
 
 
-access_denied_error =  errors.ACIError(info=_('CIFS server denied your 
credentials'))
+access_denied_error = errors.ACIError(
+  info=_('CIFS server denied your credentials'))
 dcerpc_error_codes = {
 -1073741823:
-errors.RemoteRetrieveError(reason=_('communication with CIFS server 
was unsuccessful')),
+errors.RemoteRetrieveError(
+reason=_('communication with CIFS server was unsuccessful')),
 -1073741790: access_denied_error,
 -1073741715: access_denied_error,
 -1073741614: access_denied_error,
 -1073741603:
-errors.ValidationError(name=_('AD domain controller'), 
error=_('unsupported functional level')),
--1073741811: # NT_STATUS_INVALID_PARAMETER
+errors.ValidationError(
+name=_('AD domain controller'),
+error=_('unsupported functional level')),
+-1073741811:  # NT_STATUS_INVALID_PARAMETER
 errors.RemoteRetrieveError(
-reason=_('AD domain controller complains about communication 
sequence. It may mean unsynchronized time on both sides, for example')),
--1073741776: # NT_STATUS_INVALID_PARAMETER_MIX, we simply will skip the 
binding
+reason=_('AD domain controller complains about communication '
+ 'sequence. It may mean unsynchronized time on both '
+ 'sides, for example')),
+-1073741776:  # NT_STATUS_INVALID_PARAMETER_MIX,
+  # we simply will skip the binding
 access_denied_error,
--1073741772: # NT_STATUS_OBJECT_NAME_NOT_FOUND
-errors.RemoteRetrieveError(reason=_('CIFS server configuration does 
not allow access to pipe\\lsarpc')),
+-1073741772:  # NT_STATUS_OBJECT_NAME_NOT_FOUND
+errors.RemoteRetrieveError(
+reason=_('CIFS server configuration does not allow '
+ 'access to pipe\\lsarpc')),
 }
 
 dcerpc_error_messages = {
 "NT_STATUS_OBJECT_NAME_NOT_FOUND":
- errors.NotFound(reason=_('Cannot find specified domain or server 
name')),
+errors.NotFound(
+reason=_('Cannot find specified domain or server name')),
 "WERR_NO_LOGON_SERVERS":
- errors.RemoteRet

[Freeipa-devel] [PATCH] 0207, 0218-0219 Solving trust conflicts and external trust topology fixes

2016-08-15 Thread Alexander Bokovoy


Hi!

Attached are trust-related patches.

0207 is a pre-requisite. I did send it before, it is re-formatting of
the ipaserver/dcerpc.py to be close to PEP8 requirements.

0218 is an automated trust topology conflict resolver for DNS namespace
conflicts. Read the commit message for details, and also comments in the
code. With this patch FreeIPA becomes more smart than Windows Server
which doesn't have automated trust topology conflict resolution. ;)

0219 fixes issue of topology details leaking through external trust. The
problem is only in presentation as we store more data than needed -- it
is impossible to cross external trust boundary anyway as it is handled
by AD DC side, but one important consequence is that we need to store
UPN suffixes before we start storing information about child domains.
Again, read the commit message.

These patches also are on top of my previously sent patches 0215-0216.


--
/ 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] default debug_level of sssd

2016-08-15 Thread Alexander Bokovoy


On Mon, 15 Aug 2016, Oleg Fayans wrote:

Hi all,

Does anyone know what is the default debug_level for sssd daemon in 
ipa? We've found out that some tests (mainly basic-trust) generate 
huge volumes of sssd logs which we have to store. A quick glance into 
the logs show that these log every tiny bit of really low level 
information that we probably never gonna need. We'd like to tweak the 
tests to configure sssd for less logging, but I was unable to find 
info on default debug_level. The sssd configuration file does not 
explicitly specify it.

man page sssd.conf:
Options usable in all sections
  debug_level (integer)
  

  Currently supported debug levels:

   0, 0x0010: Fatal failures. Anything that would prevent SSSD
 from starting up or causes it to cease running.

  
  Default: 0


--
/ 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] 0024 memory leak in ipapwd plugin

2016-08-11 Thread Alexander Bokovoy


On Thu, 11 Aug 2016, thierry bordaz wrote:
+/* rc should always be 0 (else slapi_sdn_new_dn_byref 
should have sigsev)
+ * but if we end in rc==LDAP_OPERATIONS_ERROR be sure to 
stop here

+ * because ret is not significant */

A short note here. You talk about slapi_sdn_new_dn_byref() but your
patch replaces that with slapi_sdn_new_dn_byval(). Does the comment
still apply?


+if (rc != 0) {
+LOG_OOM();
+goto free_and_return;
+}
+
   if (ret == 0) {
   Slapi_Value *cpw[2] = { NULL, NULL };
   Slapi_Value *pw;
--
2.7.4





Good catch Alexander. Yes the comment contained a wrong cut/paste

ACK.


--
/ 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] 0001 Added new authentication method

2016-08-11 Thread Alexander Bokovoy


On Thu, 11 Aug 2016, Jan Cholasta wrote:

On 4.8.2016 17:27, Jan Pazdziora wrote:

On Wed, Aug 03, 2016 at 10:29:52AM +0300, Alexander Bokovoy wrote:


Got it. One thing I would correct, though, -- don't use kadmin.local, we
do support setting ok_as_delegate on the service principals via IPA CLI:
$ ipa service-mod --help |grep -A1 ok-as-delegate
--ok-as-delegate=BOOL
  Client credentials may be delegated to the service


I've tried

ipa service-mod --ok-as-delegate=True HTTP/$(hostname)

but that does not seem to have the same effect as

modprinc +ok_to_auth_as_delegate HTTP/ipa.example.test

-- obtaining the delegated certificated fails.


That's because ok_as_delegate and ok_to_auth_as_delegate are different 
flags.

Right. The following patch adds ok_to_auth_as_delegate to the service
principal.

I haven't added any tickets to it yet.
--
/ Alexander Bokovoy
From 9af1c479cf8d1862c001fccd5345bd93dd6e54a8 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy <aboko...@redhat.com>
Date: Thu, 11 Aug 2016 11:52:05 +0300
Subject: [PATCH 6/6] service: add flag to allow S4U2Self

---
 API.txt  | 12 
 ipaserver/plugins/service.py |  7 +++
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/API.txt b/API.txt
index 535d8ec..5b83bfb 100644
--- a/API.txt
+++ b/API.txt
@@ -2260,7 +2260,7 @@ output: Output('summary', type=[, ])
 output: Output('value', type=[])
 output: Output('warning', type=[, , ])
 command: host_add/1
-args: 1,24,3
+args: 1,25,3
 arg: Str('fqdn', cli_name='hostname')
 option: Str('addattr*', cli_name='addattr')
 option: Flag('all', autofill=True, cli_name='all', default=False)
@@ -2269,6 +2269,7 @@ option: Flag('force', autofill=True, default=False)
 option: Str('ip_address?')
 option: Str('ipaassignedidview?')
 option: Bool('ipakrbokasdelegate?', cli_name='ok_as_delegate')
+option: Bool('ipakrboktoauthasdelegate?', cli_name='ok_to_auth_as_delegate')
 option: Bool('ipakrbrequirespreauth?', cli_name='requires_pre_auth')
 option: Str('ipasshpubkey*', cli_name='sshpubkey')
 option: Str('krbprincipalauthind*', cli_name='auth_ind')
@@ -2437,7 +2438,7 @@ output: ListOfEntries('result')
 output: Output('summary', type=[, ])
 output: Output('truncated', type=[])
 command: host_mod/1
-args: 1,25,3
+args: 1,26,3
 arg: Str('fqdn', cli_name='hostname')
 option: Str('addattr*', cli_name='addattr')
 option: Flag('all', autofill=True, cli_name='all', default=False)
@@ -2445,6 +2446,7 @@ option: Str('delattr*', cli_name='delattr')
 option: Str('description?', autofill=False, cli_name='desc')
 option: Str('ipaassignedidview?', autofill=False)
 option: Bool('ipakrbokasdelegate?', autofill=False, cli_name='ok_as_delegate')
+option: Bool('ipakrboktoauthasdelegate?', autofill=False, 
cli_name='ok_to_auth_as_delegate')
 option: Bool('ipakrbrequirespreauth?', autofill=False, 
cli_name='requires_pre_auth')
 option: Str('ipasshpubkey*', autofill=False, cli_name='sshpubkey')
 option: Str('krbprincipalauthind*', autofill=False, cli_name='auth_ind')
@@ -4293,13 +4295,14 @@ output: Entry('result')
 output: Output('summary', type=[, ])
 output: PrimaryKey('value')
 command: service_add/1
-args: 1,12,3
+args: 1,13,3
 arg: Principal('krbcanonicalname', cli_name='canonical_principal')
 option: Str('addattr*', cli_name='addattr')
 option: Flag('all', autofill=True, cli_name='all', default=False)
 option: Flag('force', autofill=True, default=False)
 option: StrEnum('ipakrbauthzdata*', cli_name='pac_type', values=[u'MS-PAC', 
u'PAD', u'NONE'])
 option: Bool('ipakrbokasdelegate?', cli_name='ok_as_delegate')
+option: Bool('ipakrboktoauthasdelegate?', cli_name='ok_to_auth_as_delegate')
 option: Bool('ipakrbrequirespreauth?', cli_name='requires_pre_auth')
 option: Str('krbprincipalauthind*', cli_name='auth_ind')
 option: Flag('no_members', autofill=True, default=False)
@@ -4435,13 +4438,14 @@ output: ListOfEntries('result')
 output: Output('summary', type=[, ])
 output: Output('truncated', type=[])
 command: service_mod/1
-args: 1,14,3
+args: 1,15,3
 arg: Principal('krbcanonicalname', cli_name='canonical_principal')
 option: Str('addattr*', cli_name='addattr')
 option: Flag('all', autofill=True, cli_name='all', default=False)
 option: Str('delattr*', cli_name='delattr')
 option: StrEnum('ipakrbauthzdata*', autofill=False, cli_name='pac_type', 
values=[u'MS-PAC', u'PAD', u'NONE'])
 option: Bool('ipakrbokasdelegate?', autofill=False, cli_name='ok_as_delegate')
+option: Bool('ipakrboktoauthasdelegate?', autofill=False, 
cli_name='ok_to_auth_as_delegate')
 option: Bool('ipakrbrequirespreauth?', autofill=False, 
cli_name='requires_pre_auth')
 option: Str('krbprincipalauthind*', autofill=False, cli_name='auth_ind')
 option: Principal('krbprincipalname*', autofill=False, cli_name='principal')
diff --git a/ipaserver/plugins/service.py b/ipaserver/plugins/service.py
index a44dcaa..04d1916 100644
--- a/ipaserver/plugins/service.py
+++ b/ipaserver/plugins/serv

Re: [Freeipa-devel] [PATCH] 0024 memory leak in ipapwd plugin


On Wed, 10 Aug 2016, thierry bordaz wrote:



On 08/10/2016 11:24 AM, Alexander Bokovoy wrote:

On Wed, 10 Aug 2016, thierry bordaz wrote:





From 13bb55f9d97f82062f5b496d4164acb562afc7a0 Mon Sep 17 00:00:00 2001

From: Thierry Bordaz <tbor...@redhat.com>
Date: Tue, 9 Aug 2016 16:46:25 +0200
Subject: [PATCH] ipa-pwd-extop memory leak during passord update

During an extend op password update, there is a test if the
user is changing the password is himself. It uses local Slapi_SDN
variable that are not freed
---
daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)

diff --git 
a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c 
b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c

index 6a87a27..2eda6c6 100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c
@@ -398,16 +398,20 @@ parse_req_done:
   /* if the user changing the password is self, we must 
request the

* old password and verify it matches the current one before
* proceeding with the password change */
-bind_sdn = slapi_sdn_new_dn_byref(bindDN);
-target_sdn = slapi_sdn_new_dn_byref(dn);
+bind_sdn = slapi_sdn_new_dn_byval(bindDN);
+target_sdn = slapi_sdn_new_dn_byval(dn);
   if (!bind_sdn || !target_sdn) {
   LOG_OOM();
+slapi_sdn_free(_sdn);
+slapi_sdn_free(_sdn);
   rc = LDAP_OPERATIONS_ERROR;
   goto free_and_return;
   }
   /* this one will normalize and compare, so difference in 
case will be

* correctly handled */
   ret = slapi_sdn_compare(bind_sdn, target_sdn);
+slapi_sdn_free(_sdn);
+slapi_sdn_free(_sdn);
   if (ret == 0) {
   Slapi_Value *cpw[2] = { NULL, NULL };
   Slapi_Value *pw;

I would prefer to unify memory freeing. Because slapi_sdn_compare() can
be run with NULL arguments (it will return 0), and slapi_sdn_free() is
no-op for NULL argument, you can actually do comparison, then free the
SDNs and then do error handling:


bind_sdn = slapi_sdn_new_dn_byval(bindDN);
target_sdn = slapi_sdn_new_dn_byval(dn);

rc = (!bind_sdn || !target_sdn) ? LDAP_OPERATIONS_ERROR : 0;
ret = slapi_sdn_compare(bind_sdn, target_sdn);

slapi_sdn_free(_sdn);
slapi_sdn_free(_sdn);

if (rc != 0) {
   LOG_OOM();
   goto free_and_return;
}

if (ret == 0) {
 
}




--
2.7.4




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




Thanks again Alexander for the review. Here is the revisited patch



From db4211d855b4d21354dc619952b2b2e1ad31f3b9 Mon Sep 17 00:00:00 2001
From: Thierry Bordaz <tbor...@redhat.com>
Date: Tue, 9 Aug 2016 16:46:25 +0200
Subject: [PATCH] ipa-pwd-extop memory leak during passord update

During an extend op password update, there is a test if the
user is changing the password is himself. It uses local Slapi_SDN
variable that are not freed
---
.../ipa-pwd-extop/ipa_pwd_extop.c  | 24 +++---
1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c 
b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c
index 6a87a27..eaca0dc 100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c
@@ -398,16 +398,26 @@ parse_req_done:
/* if the user changing the password is self, we must request the
 * old password and verify it matches the current one before
 * proceeding with the password change */
-bind_sdn = slapi_sdn_new_dn_byref(bindDN);
-target_sdn = slapi_sdn_new_dn_byref(dn);
-if (!bind_sdn || !target_sdn) {
-LOG_OOM();
-rc = LDAP_OPERATIONS_ERROR;
-goto free_and_return;
-}
+bind_sdn = slapi_sdn_new_dn_byval(bindDN);
+target_sdn = slapi_sdn_new_dn_byval(dn);
+
+rc = (!bind_sdn || !target_sdn) ? LDAP_OPERATIONS_ERROR : 0;
+
/* this one will normalize and compare, so difference in case will be
 * correctly handled */
ret = slapi_sdn_compare(bind_sdn, target_sdn);
+
+slapi_sdn_free(_sdn);
+slapi_sdn_free(_sdn);
+
+/* rc should always be 0 (else slapi_sdn_new_dn_byref should have 
sigsev)
+ * but if we end in rc==LDAP_OPERATIONS_ERROR be sure to stop here
+ * because ret is not significant */

A short note here. You talk about slapi_sdn_new_dn_byref() but your
patch replaces that with slapi_sdn_new_dn_byval(). Does the comment
still apply?


+if (rc != 0) {
+LOG_OOM();
+goto free_and_return;
+}
+
if (ret == 0) {
Slapi_Value *cpw[2] = { NULL, NULL };
Slapi_Value *

Re: [Freeipa-devel] [PATCH 0213] support multiple uid values in slapi-nis users map


On Wed, 10 Aug 2016, Alexander Bokovoy wrote:

On Wed, 10 Aug 2016, thierry bordaz wrote:



On 08/09/2016 01:38 PM, Alexander Bokovoy wrote:

On Tue, 09 Aug 2016, thierry bordaz wrote:



On 08/09/2016 12:49 PM, Martin Basti wrote:



On 08.08.2016 17:30, thierry bordaz wrote:



On 08/08/2016 05:20 PM, Alexander Bokovoy wrote:

On Mon, 08 Aug 2016, thierry bordaz wrote:



On 08/08/2016 04:20 PM, Alexander Bokovoy wrote:

On Mon, 08 Aug 2016, thierry bordaz wrote:



On 08/08/2016 10:56 AM, Alexander Bokovoy wrote:

On Mon, 08 Aug 2016, Lukas Slebodnik wrote:

On (08/08/16 11:35), Alexander Bokovoy wrote:

On Mon, 08 Aug 2016, Martin Basti wrote:



On 08.08.2016 09:34, Alexander Bokovoy wrote:

When SSSD resolves AD users on behalf of slapi-nis, it can

accept any
user identifier, including user principal 
name (UPN) which may be

different than the canonical user name which SSSD returns.

As result, the entry created by slapi-nis will be using

canonical user
name but the filter for search will refer 
to the original (aliased)

name. The search will not match the newly created entry.

The issue is fixed  in slapi-nis-0.56.1 by 
returning two values for
'uid' attribute: the canonical one and the 
aliased one. This way the

search will match.

Standard LDAP schema allows multiple 
values for 'uid' attribute. We
actually use the same trick for 'cn' 
attribute in the groups map

already.

https://fedorahosted.org/freeipa/ticket/6138





Hello,

should we bump requires to slapi-nis-0.56.1 in freeipa.spec?
No, this is not required. In Fedora we'll 
submit a combined update --
I've built slapi-nis-0.56.1-1 packages for 
f24, f25, and rawhide already

but did not submit a Bodhi request.


How is combined updated related to requires to slapi-nis-0.56.1?
It will not prevent tu update freeipa without new slapi-nis.

e.g.
dnf update freeipa-server.
An update file in FreeIPA that is proposed by this 
patch does not affect
operation of the older slapi-nis deployment once 
update is applied.




Hi,

Is '%first' returning the first value of the attribute 'uid' ?
If there are several values (canonical, alias,... ), 
does the order matters ?

We insert the canonical one first and it seems that 389-ds does not
change the order, at least in my tests. You can see 
the output in the

bug https://bugzilla.redhat.com/show_bug.cgi?id=1361123#c2


From ldap pov 
(https://tools.ietf.org/html/rfc4511#section-4.1.7) the 
order of the values is not preserved.
I think it is a bit risky to rely on a specific order 
especially with complex updates (adding several values 
in a single mod, replace) and replication.
would it help to add canonical value with a subtype 
(e.g. 'uid;canonical: ') ?

Not sure how what you are mention is relevant here. We talk about
slapi-nis map cache entries which are not modified, replaced or
replicated anywhere by anything other than slapi-nis itself. When
entries are changed by slapi-nis, they are regenerated from scratch.

Your worries do not apply here.

ok.
I understand my mistake, I was thinking the compat entry had 
a associated real entry in ldap and this real entry had two 
uid values.




So, could you provide ack thierry?

Martin


Sure but I would have to test first :-)

Alexander, how can I test this ?

slapi-nis 0.56.1-1 packages are available in koji for f24-f26:
http://koji.fedoraproject.org/koji/packageinfo?packageID=6609


Thanks Alexander. So to test this change is there an other way 
(simpler) than setting up AD/trust ?

I don't think so. We don't have UPNs in FreeIPA on the level of identity
lookups and we don't allow to lookup identity by email, so you are left
with using a proper AD trust and UPN suffixes in AD forest.

Attached is an updated patch that adds versioned require of slapi-nis
which supports the feature.


--
/ Alexander Bokovoy
From 4a75c02c66e2ecacb0cb3b6e8c2255805e9f68b5 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy <aboko...@redhat.com>
Date: Thu, 4 Aug 2016 09:58:50 +0300
Subject: [PATCH 2/5] support multiple uid values in schema compatibility tree

---
 freeipa.spec.in | 4 +++-
 install/updates/10-schema_compat.update | 4 
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/freeipa.spec.in b/freeipa.spec.in
index 78ab8ca..c8146e1 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -12,9 +12,11 @@
 %if 0%{?rhel}
 %global samba_version 4.0.5-1
 %global selinux_policy_version 3.12.1-153
+%global slapi_nis_version 0.56.0-4
 %else
 %global samba_version 2:4.0.5-1
 %global selinux_policy_version 3.13.1-158.4
+%global slapi_nis_version 0.56.1
 %endif
 
 %define krb5_base_version %(LC_ALL=C rpm -q --qf '%%{VERSION}' krb5-devel | 
grep -Eo '^[^.]+\.[^.]+')
@@ -157,7 +159,7 @@ Requires(pre): systemd-units
 Requires(post): systemd-units
 Requires: selinux-policy >= %{selinux_policy_version}
 Requires(post): selinux-policy-base >= %{selinux_policy_version}
-Requires: slapi-nis >= 0.56.0
+Requires: slapi-nis >= %

Re: [Freeipa-devel] [PATCH] 0024 memory leak in ipapwd plugin


On Wed, 10 Aug 2016, thierry bordaz wrote:





From 13bb55f9d97f82062f5b496d4164acb562afc7a0 Mon Sep 17 00:00:00 2001

From: Thierry Bordaz <tbor...@redhat.com>
Date: Tue, 9 Aug 2016 16:46:25 +0200
Subject: [PATCH] ipa-pwd-extop memory leak during passord update

During an extend op password update, there is a test if the
user is changing the password is himself. It uses local Slapi_SDN
variable that are not freed
---
daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c 
b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c
index 6a87a27..2eda6c6 100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c
@@ -398,16 +398,20 @@ parse_req_done:
/* if the user changing the password is self, we must request the
 * old password and verify it matches the current one before
 * proceeding with the password change */
-bind_sdn = slapi_sdn_new_dn_byref(bindDN);
-target_sdn = slapi_sdn_new_dn_byref(dn);
+bind_sdn = slapi_sdn_new_dn_byval(bindDN);
+target_sdn = slapi_sdn_new_dn_byval(dn);
if (!bind_sdn || !target_sdn) {
LOG_OOM();
+slapi_sdn_free(_sdn);
+slapi_sdn_free(_sdn);
rc = LDAP_OPERATIONS_ERROR;
goto free_and_return;
}
/* this one will normalize and compare, so difference in case will be
 * correctly handled */
ret = slapi_sdn_compare(bind_sdn, target_sdn);
+slapi_sdn_free(_sdn);
+slapi_sdn_free(_sdn);
if (ret == 0) {
Slapi_Value *cpw[2] = { NULL, NULL };
Slapi_Value *pw;

I would prefer to unify memory freeing. Because slapi_sdn_compare() can
be run with NULL arguments (it will return 0), and slapi_sdn_free() is
no-op for NULL argument, you can actually do comparison, then free the
SDNs and then do error handling:


 bind_sdn = slapi_sdn_new_dn_byval(bindDN);
 target_sdn = slapi_sdn_new_dn_byval(dn);

 rc = (!bind_sdn || !target_sdn) ? LDAP_OPERATIONS_ERROR : 0;
 ret = slapi_sdn_compare(bind_sdn, target_sdn);

 slapi_sdn_free(_sdn);
 slapi_sdn_free(_sdn);

 if (rc != 0) {
LOG_OOM();
goto free_and_return;
 }

 if (ret == 0) {
  
 }




--
2.7.4




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



--
/ 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 0013-0015] Automatic CSR generation - usability improvements


On Wed, 10 Aug 2016, Petr Spacek wrote:

On 9.8.2016 22:07, Ben Lipton wrote:

Aaand there's a typo in patch 15. Updated version attached.


Ben,

it would be great if you can always send whole patch set, including the
patches which were not changed from the previous iteration.

It is getting quite hard to follow and mix-and-match patches from e-mails into
one patch set.

As a nice to have addition, you can push the whole patch set to Github (or
somewhere else) so we can just clone the repo and be done with it :-)

I concur here. I'm a bit lost which patches have what state, jumping
from thread to thread and from response to response. ;)


--
/ 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 687] client: add missing output params to client-side commands


On Wed, 10 Aug 2016, Jan Cholasta wrote:

Hi,

the attached patch fixes <https://fedorahosted.org/freeipa/ticket/6182>.

Honza

--
Jan Cholasta



From 2f21d1eee2ea2e3cc568b75bd32f24d7188cbe59 Mon Sep 17 00:00:00 2001
From: Jan Cholasta <jchol...@redhat.com>
Date: Wed, 10 Aug 2016 09:02:47 +0200
Subject: [PATCH] client: add missing output params to client-side commands

Add output params for the otptoken-add-yubikey, vault-add, vault-mod,
vault-archive and vault-retrieve commands.

This fixes the commands not having any output in CLI.

https://fedorahosted.org/freeipa/ticket/6182
---
ipaclient/plugins/otptoken_yubikey.py |  6 ++
ipaclient/plugins/vault.py| 24 
2 files changed, 30 insertions(+)

diff --git a/ipaclient/plugins/otptoken_yubikey.py 
b/ipaclient/plugins/otptoken_yubikey.py
index bfa244c..549376a 100644
--- a/ipaclient/plugins/otptoken_yubikey.py
+++ b/ipaclient/plugins/otptoken_yubikey.py
@@ -106,6 +106,12 @@ class otptoken_add_yubikey(Command):
for option in super(otptoken_add_yubikey, self).get_options():
yield option

+def get_output_params(self):
+for param in self.api.Command.otptoken_add.output_params():
+yield param
+for param in super(otptoken_add_yubikey, self).get_output_params():
+yield param
+
def _iter_output(self):
return self.api.Command.otptoken_add.output()

diff --git a/ipaclient/plugins/vault.py b/ipaclient/plugins/vault.py
index 1e715fd..c0ded21 100644
--- a/ipaclient/plugins/vault.py
+++ b/ipaclient/plugins/vault.py
@@ -223,6 +223,12 @@ class vault_add(Local):
for option in super(vault_add, self).get_options():
yield option

+def get_output_params(self):
+for param in self.api.Command.vault_add_internal.output_params():
+yield param
+for param in super(vault_add, self).get_output_params():
+yield param
+
def _iter_output(self):
return self.api.Command.vault_add_internal.output()

@@ -423,6 +429,12 @@ class vault_mod(Local):
for option in super(vault_mod, self).get_options():
yield option

+def get_output_params(self):
+for param in self.api.Command.vault_mod_internal.output_params():
+yield param
+for param in super(vault_mod, self).get_output_params():
+yield param
+
def _iter_output(self):
return self.api.Command.vault_mod_internal.output()

@@ -607,6 +619,12 @@ class vault_archive(Local):
for option in super(vault_archive, self).get_options():
yield option

+def get_output_params(self):
+for param in self.api.Command.vault_archive_internal.output_params():
+yield param
+for param in super(vault_archive, self).get_output_params():
+yield param
+
def _iter_output(self):
return self.api.Command.vault_archive_internal.output()

@@ -855,6 +873,12 @@ class vault_retrieve(Local):
for option in super(vault_retrieve, self).get_options():
yield option

+def get_output_params(self):
+for param in self.api.Command.vault_retrieve_internal.output_params():
+yield param
+for param in super(vault_retrieve, self).get_output_params():
+yield param
+
def _iter_output(self):
return self.api.Command.vault_retrieve_internal.output()


ACK.

--
/ 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 0213] support multiple uid values in slapi-nis users map


On Wed, 10 Aug 2016, thierry bordaz wrote:



On 08/09/2016 01:38 PM, Alexander Bokovoy wrote:

On Tue, 09 Aug 2016, thierry bordaz wrote:



On 08/09/2016 12:49 PM, Martin Basti wrote:



On 08.08.2016 17:30, thierry bordaz wrote:



On 08/08/2016 05:20 PM, Alexander Bokovoy wrote:

On Mon, 08 Aug 2016, thierry bordaz wrote:



On 08/08/2016 04:20 PM, Alexander Bokovoy wrote:

On Mon, 08 Aug 2016, thierry bordaz wrote:



On 08/08/2016 10:56 AM, Alexander Bokovoy wrote:

On Mon, 08 Aug 2016, Lukas Slebodnik wrote:

On (08/08/16 11:35), Alexander Bokovoy wrote:

On Mon, 08 Aug 2016, Martin Basti wrote:



On 08.08.2016 09:34, Alexander Bokovoy wrote:

When SSSD resolves AD users on behalf of slapi-nis, it can

accept any
user identifier, including user principal 
name (UPN) which may be

different than the canonical user name which SSSD returns.

As result, the entry created by slapi-nis will be using

canonical user
name but the filter for search will refer to 
the original (aliased)

name. The search will not match the newly created entry.

The issue is fixed  in slapi-nis-0.56.1 by 
returning two values for
'uid' attribute: the canonical one and the 
aliased one. This way the

search will match.

Standard LDAP schema allows multiple values 
for 'uid' attribute. We
actually use the same trick for 'cn' 
attribute in the groups map

already.

https://fedorahosted.org/freeipa/ticket/6138





Hello,

should we bump requires to slapi-nis-0.56.1 in freeipa.spec?
No, this is not required. In Fedora we'll submit 
a combined update --
I've built slapi-nis-0.56.1-1 packages for f24, 
f25, and rawhide already

but did not submit a Bodhi request.


How is combined updated related to requires to slapi-nis-0.56.1?
It will not prevent tu update freeipa without new slapi-nis.

e.g.
dnf update freeipa-server.
An update file in FreeIPA that is proposed by this 
patch does not affect
operation of the older slapi-nis deployment once 
update is applied.




Hi,

Is '%first' returning the first value of the attribute 'uid' ?
If there are several values (canonical, alias,... ), 
does the order matters ?

We insert the canonical one first and it seems that 389-ds does not
change the order, at least in my tests. You can see the 
output in the

bug https://bugzilla.redhat.com/show_bug.cgi?id=1361123#c2


From ldap pov 
(https://tools.ietf.org/html/rfc4511#section-4.1.7) the 
order of the values is not preserved.
I think it is a bit risky to rely on a specific order 
especially with complex updates (adding several values in 
a single mod, replace) and replication.
would it help to add canonical value with a subtype (e.g. 
'uid;canonical: ') ?

Not sure how what you are mention is relevant here. We talk about
slapi-nis map cache entries which are not modified, replaced or
replicated anywhere by anything other than slapi-nis itself. When
entries are changed by slapi-nis, they are regenerated from scratch.

Your worries do not apply here.

ok.
I understand my mistake, I was thinking the compat entry had a 
associated real entry in ldap and this real entry had two uid 
values.




So, could you provide ack thierry?

Martin


Sure but I would have to test first :-)

Alexander, how can I test this ?

slapi-nis 0.56.1-1 packages are available in koji for f24-f26:
http://koji.fedoraproject.org/koji/packageinfo?packageID=6609


Thanks Alexander. So to test this change is there an other way 
(simpler) than setting up AD/trust ?

I don't think so. We don't have UPNs in FreeIPA on the level of identity
lookups and we don't allow to lookup identity by email, so you are left
with using a proper AD trust and UPN suffixes in AD forest.
--
/ 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] ipa-kdb: Allow to build with samba 4.5

2016-08-09 Thread Alexander Bokovoy


On Tue, 09 Aug 2016, Lukas Slebodnik wrote:

On (09/08/16 14:59), Alexander Bokovoy wrote:

On Fri, 05 Aug 2016, Lukas Slebodnik wrote:

ehlo,

attached patches fix a build of freeipa on fedora 25 and fedora rawhide.
IMHO, this change in krb5pac.h is an ABI change and samba guys should
also bump a SONAME to related (private?) libraries. I could not see it;
but maybe I overlooked it.

It an interesting question which you might raise upstream. krb5pac.h is
auto-generated from krb5pac.idl, the same happens for all IDL-based
definitions. They are not versioned, though.


I can ask but I am not sure which library is connected to the
header file "gen_ndr/krb5pac.h". If it is a internal library then
ABI change is not guaranted but ipa might have problems without requires.

We have dependency to libndr-krb5pac.so.0(NDR_KRB5PAC_0.0.1)(64bit)

The problem here is that we could get some heads up with ABI tracker
(http://abi-laboratory.pro/tracker/) but Samba is not there. I can ask
Andrey P. about adding it, though.

Fedora's Taskotron has dist.abicheck but any attempt to get results for
Samba builds caused server error for me.

--
/ 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] ipa-kdb: Allow to build with samba 4.5

2016-08-09 Thread Alexander Bokovoy


On Fri, 05 Aug 2016, Lukas Slebodnik wrote:

ehlo,

attached patches fix a build of freeipa on fedora 25 and fedora rawhide.
IMHO, this change in krb5pac.h is an ABI change and samba guys should
also bump a SONAME to related (private?) libraries. I could not see it;
but maybe I overlooked it.

It an interesting question which you might raise upstream. krb5pac.h is
auto-generated from krb5pac.idl, the same happens for all IDL-based
definitions. They are not versioned, though.

As for the patch, ACK. The change came with 
4406cf792a599724f55777a45efb6367a9bd92b2,
'krb5pac.idl: introduce PAC_DOMAIN_GROUP_MEMBERSHIP to handle the resource 
groups'
which landed upstream in May 2016.



LS



From 02db5adc82c36592f8aef5fd4d5e2f2e27f15b11 Mon Sep 17 00:00:00 2001

From: Lukas Slebodnik <lsleb...@redhat.com>
Date: Fri, 5 Aug 2016 08:29:27 +0200
Subject: [PATCH 1/2] ipa-kdb: Allow to build with samba 4.5

daemons/ipa-kdb/ipa_kdb_mspac.c: In function 'filter_logon_info':
daemons/ipa-kdb/ipa_kdb_mspac.c:1536:19: error: 'struct PAC_LOGON_INFO'
 has no member named 'res_group_dom_sid'
if (info->info->res_group_dom_sid != NULL &&
  ^~
daemons/ipa-kdb/ipa_kdb_mspac.c:1537:19: error: 'struct PAC_LOGON_INFO'
 has no member named 'res_groups'; did you mean 'resource_groups'?
info->info->res_groups.count != 0) {
  ^~
mv -f .deps/ipa_kdb_delegation.Tpo .deps/ipa_kdb_delegation.Plo
Makefile:806: recipe for target 'ipa_kdb_mspac.lo' failed
make[3]: *** [ipa_kdb_mspac.lo] Error 1
make[3]: *** Waiting for unfinished jobs

Related change in samba
https://github.com/samba-team/samba/commit/4406cf792a599724f55777a45efb6367a9bd92b2

Resolves:
https://fedorahosted.org/freeipa/ticket/6173
---
daemons/configure.ac| 12 
daemons/ipa-kdb/ipa_kdb_mspac.c |  9 +
2 files changed, 21 insertions(+)

diff --git a/daemons/configure.ac b/daemons/configure.ac
index 
94d66d813728fe4e32f9e3c0eef920d8e2395d8f..5c5a1046397aa97ba18cafc1b81dc2a6fb2dfd34
 100644
--- a/daemons/configure.ac
+++ b/daemons/configure.ac
@@ -170,6 +170,18 @@ PKG_CHECK_MODULES([SAMBAUTIL], [samba-util])
SAMBA40EXTRA_LIBPATH="-L`$PKG_CONFIG --variable=libdir samba-util`/samba 
-Wl,-rpath=`$PKG_CONFIG --variable=libdir samba-util`/samba"
AC_SUBST(SAMBA40EXTRA_LIBPATH)

+bck_cflags="$CFLAGS"
+CFLAGS="$NDRPAC_CFLAGS"
+AC_CHECK_MEMBER(
+[struct PAC_DOMAIN_GROUP_MEMBERSHIP.domain_sid],
+[AC_DEFINE([HAVE_STRUCT_PAC_DOMAIN_GROUP_MEMBERSHIP], [1],
+   [struct PAC_DOMAIN_GROUP_MEMBERSHIP is available.])],
+[AC_MSG_NOTICE([struct PAC_DOMAIN_GROUP_MEMBERSHIP is not available])],
+ [[#include 
+   #include ]])
+
+CFLAGS="$bck_cflags"
+
LIBPDB_NAME=""
AC_CHECK_LIB([samba-passdb],
 [make_pdb_method],
diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c
index 
80e7055fd6cd7b962eeffbccc675a73d73700793..65cc03565dc06d1052c6acd0c0d6ee7265b37b36
 100644
--- a/daemons/ipa-kdb/ipa_kdb_mspac.c
+++ b/daemons/ipa-kdb/ipa_kdb_mspac.c
@@ -20,6 +20,8 @@
 * along with this program.  If not, see <http://www.gnu.org/licenses/>.
 */

+#include "config.h"
+
#include "ipa_kdb.h"
#include "ipa_mspac.h"
#include 
@@ -1533,10 +1535,17 @@ krb5_error_code filter_logon_info(krb5_context context,

/* According to MS-KILE, ResourceGroups must be zero, so check
 * that it is the case here */
+#ifdef HAVE_STRUCT_PAC_DOMAIN_GROUP_MEMBERSHIP
+if (info->info->resource_groups.domain_sid != NULL &&
+info->info->resource_groups.groups.count != 0) {
+return EINVAL;
+}
+#else
if (info->info->res_group_dom_sid != NULL &&
info->info->res_groups.count != 0) {
return EINVAL;
}
+#endif

return 0;
}
--
2.9.2




From 7d064bc2dda88552f597c1e8dfa2cf176a89ac77 Mon Sep 17 00:00:00 2001

From: Lukas Slebodnik <lsleb...@redhat.com>
Date: Fri, 5 Aug 2016 08:34:23 +0200
Subject: [PATCH 2/2] ipa-kdb: Fix unit test after packaging changes in krb5

Resolves:
https://fedorahosted.org/freeipa/ticket/6173
---
freeipa.spec.in | 2 ++
1 file changed, 2 insertions(+)

diff --git a/freeipa.spec.in b/freeipa.spec.in
index 
135e9c980011c6c2730c6c29a3c22098e48270d5..7b5bb906ea541da10e0a9f5f9970f5937728ee11
 100644
--- a/freeipa.spec.in
+++ b/freeipa.spec.in
@@ -108,6 +108,8 @@ BuildRequires:  python-netifaces >= 0.10.4
# Build dependencies for unit tests
BuildRequires:  libcmocka-devel
BuildRequires:  nss_wrapper
+# Required by ipa_kdb_tests
+BuildRequires:  %{_libdir}/krb5/plugins/kdb/db2.so

%if 0%{?with_python3}
BuildRequires:  python3-devel
--
2.9.2




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



--
/ Alexander Bokovoy

--

Re: [Freeipa-devel] [PATCH 0213] support multiple uid values in slapi-nis users map

2016-08-09 Thread Alexander Bokovoy


On Tue, 09 Aug 2016, thierry bordaz wrote:



On 08/09/2016 12:49 PM, Martin Basti wrote:



On 08.08.2016 17:30, thierry bordaz wrote:



On 08/08/2016 05:20 PM, Alexander Bokovoy wrote:

On Mon, 08 Aug 2016, thierry bordaz wrote:



On 08/08/2016 04:20 PM, Alexander Bokovoy wrote:

On Mon, 08 Aug 2016, thierry bordaz wrote:



On 08/08/2016 10:56 AM, Alexander Bokovoy wrote:

On Mon, 08 Aug 2016, Lukas Slebodnik wrote:

On (08/08/16 11:35), Alexander Bokovoy wrote:

On Mon, 08 Aug 2016, Martin Basti wrote:



On 08.08.2016 09:34, Alexander Bokovoy wrote:

When SSSD resolves AD users on behalf of slapi-nis, it can

accept any
user identifier, including user principal name 
(UPN) which may be

different than the canonical user name which SSSD returns.

As result, the entry created by slapi-nis will be using

canonical user
name but the filter for search will refer to the 
original (aliased)

name. The search will not match the newly created entry.

The issue is fixed  in slapi-nis-0.56.1 by 
returning two values for
'uid' attribute: the canonical one and the 
aliased one. This way the

search will match.

Standard LDAP schema allows multiple values for 
'uid' attribute. We
actually use the same trick for 'cn' attribute 
in the groups map

already.

https://fedorahosted.org/freeipa/ticket/6138





Hello,

should we bump requires to slapi-nis-0.56.1 in freeipa.spec?
No, this is not required. In Fedora we'll submit a 
combined update --
I've built slapi-nis-0.56.1-1 packages for f24, f25, 
and rawhide already

but did not submit a Bodhi request.


How is combined updated related to requires to slapi-nis-0.56.1?
It will not prevent tu update freeipa without new slapi-nis.

e.g.
dnf update freeipa-server.
An update file in FreeIPA that is proposed by this patch 
does not affect

operation of the older slapi-nis deployment once update is applied.



Hi,

Is '%first' returning the first value of the attribute 'uid' ?
If there are several values (canonical, alias,... ), does 
the order matters ?

We insert the canonical one first and it seems that 389-ds does not
change the order, at least in my tests. You can see the output in the
bug https://bugzilla.redhat.com/show_bug.cgi?id=1361123#c2


From ldap pov 
(https://tools.ietf.org/html/rfc4511#section-4.1.7) the order 
of the values is not preserved.
I think it is a bit risky to rely on a specific order 
especially with complex updates (adding several values in a 
single mod, replace) and replication.
would it help to add canonical value with a subtype (e.g. 
'uid;canonical: ') ?

Not sure how what you are mention is relevant here. We talk about
slapi-nis map cache entries which are not modified, replaced or
replicated anywhere by anything other than slapi-nis itself. When
entries are changed by slapi-nis, they are regenerated from scratch.

Your worries do not apply here.

ok.
I understand my mistake, I was thinking the compat entry had a 
associated real entry in ldap and this real entry had two uid 
values.




So, could you provide ack thierry?

Martin


Sure but I would have to test first :-)

Alexander, how can I test this ?

slapi-nis 0.56.1-1 packages are available in koji for f24-f26:
http://koji.fedoraproject.org/koji/packageinfo?packageID=6609
--
/ 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 0213] support multiple uid values in slapi-nis users map


On Mon, 08 Aug 2016, thierry bordaz wrote:



On 08/08/2016 04:20 PM, Alexander Bokovoy wrote:

On Mon, 08 Aug 2016, thierry bordaz wrote:



On 08/08/2016 10:56 AM, Alexander Bokovoy wrote:

On Mon, 08 Aug 2016, Lukas Slebodnik wrote:

On (08/08/16 11:35), Alexander Bokovoy wrote:

On Mon, 08 Aug 2016, Martin Basti wrote:



On 08.08.2016 09:34, Alexander Bokovoy wrote:
When SSSD resolves AD users on behalf of slapi-nis, it 
can

accept any

user identifier, including user principal name (UPN) which may be
different than the canonical user name which SSSD returns.

As result, the entry created by slapi-nis will be using

canonical user

name but the filter for search will refer to the original (aliased)
name. The search will not match the newly created entry.

The issue is fixed  in slapi-nis-0.56.1 by returning two values for
'uid' attribute: the canonical one and the aliased one. 
This way the

search will match.

Standard LDAP schema allows multiple values for 'uid' attribute. We
actually use the same trick for 'cn' attribute in the groups map
already.

https://fedorahosted.org/freeipa/ticket/6138





Hello,

should we bump requires to slapi-nis-0.56.1 in freeipa.spec?

No, this is not required. In Fedora we'll submit a combined update --
I've built slapi-nis-0.56.1-1 packages for f24, f25, and 
rawhide already

but did not submit a Bodhi request.


How is combined updated related to requires to slapi-nis-0.56.1?
It will not prevent tu update freeipa without new slapi-nis.

e.g.
dnf update freeipa-server.
An update file in FreeIPA that is proposed by this patch does 
not affect

operation of the older slapi-nis deployment once update is applied.



Hi,

Is '%first' returning the first value of the attribute 'uid' ?
If there are several values (canonical, alias,... ), does the 
order matters ?

We insert the canonical one first and it seems that 389-ds does not
change the order, at least in my tests. You can see the output in the
bug https://bugzilla.redhat.com/show_bug.cgi?id=1361123#c2


From ldap pov (https://tools.ietf.org/html/rfc4511#section-4.1.7) the 
order of the values is not preserved.
I think it is a bit risky to rely on a specific order especially with 
complex updates (adding several values in a single mod, replace) and 
replication.
would it help to add canonical value with a subtype (e.g. 
'uid;canonical: ') ?

Not sure how what you are mention is relevant here. We talk about
slapi-nis map cache entries which are not modified, replaced or
replicated anywhere by anything other than slapi-nis itself. When
entries are changed by slapi-nis, they are regenerated from scratch.

Your worries do not apply 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] [PATCH 0213] support multiple uid values in slapi-nis users map


On Mon, 08 Aug 2016, thierry bordaz wrote:



On 08/08/2016 10:56 AM, Alexander Bokovoy wrote:

On Mon, 08 Aug 2016, Lukas Slebodnik wrote:

On (08/08/16 11:35), Alexander Bokovoy wrote:

On Mon, 08 Aug 2016, Martin Basti wrote:



On 08.08.2016 09:34, Alexander Bokovoy wrote:
When SSSD resolves AD users on behalf of slapi-nis, it can 

accept any

user identifier, including user principal name (UPN) which may be
different than the canonical user name which SSSD returns.

As result, the entry created by slapi-nis will be using 

canonical user

name but the filter for search will refer to the original (aliased)
name. The search will not match the newly created entry.

The issue is fixed  in slapi-nis-0.56.1 by returning two values for
'uid' attribute: the canonical one and the aliased one. This way the
search will match.

Standard LDAP schema allows multiple values for 'uid' attribute. We
actually use the same trick for 'cn' attribute in the groups map
already.

https://fedorahosted.org/freeipa/ticket/6138





Hello,

should we bump requires to slapi-nis-0.56.1 in freeipa.spec?

No, this is not required. In Fedora we'll submit a combined update --
I've built slapi-nis-0.56.1-1 packages for f24, f25, and rawhide 
already

but did not submit a Bodhi request.


How is combined updated related to requires to slapi-nis-0.56.1?
It will not prevent tu update freeipa without new slapi-nis.

e.g.
dnf update freeipa-server.

An update file in FreeIPA that is proposed by this patch does not affect
operation of the older slapi-nis deployment once update is applied.



Hi,

Is '%first' returning the first value of the attribute 'uid' ?
If there are several values (canonical, alias,... ), does the order 
matters ?

We insert the canonical one first and it seems that 389-ds does not
change the order, at least in my tests. You can see the output in the
bug https://bugzilla.redhat.com/show_bug.cgi?id=1361123#c2
--
/ 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] 0001: Silence sshd messages during install


On Mon, 08 Aug 2016, Jan Cholasta wrote:

On 19.7.2016 08:40, Jan Cholasta wrote:

Hi,

On 9.7.2016 14:46, Ben Lipton wrote:

On 07/07/2016 11:19 AM, Ben Lipton wrote:


Thanks for the review! Comments below.


On 07/01/2016 07:42 AM, Martin Basti wrote:




On 29.06.2016 20:46, Ben Lipton wrote:

The attached patch silences some annoying messages I've been getting
when upgrading the freeipa-client package on F24:
"""
WARNING: 'UseLogin yes' is not supported in Fedora and may cause
several problems.

This will be fixed by openssh-7.2p2-9.fc24
(https://bugzilla.redhat.com/show_bug.cgi?id=1350347) so we probably
shouldn't worry about it.

Could not load host key: /etc/ssh/ssh_host_dsa_key

This is because by default sshd looks for all of
/etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_ecdsa_key,
/etc/ssh/ssh_host_ed25519_key and /etc/ssh/ssh_host_rsa_key, but
Fedora doesn't generate a DSA key by default.

"""

Since the script causing the message only looks at the return code
from sshd to determine the right options to use, I thought it might
be ok to discard the output. What do you think?

Ben




Hello, I don't like to hiding errors/warnings. Can you determine and
solve the root cause?


I definitely agree with this in principle, but in this case the
purpose of this code is to try different, potentially wrong,
parameters to sshd until it finds a combination that it accepts. It
seems like in some environments this would produce error messages that
aren't actionable and don't indicate any problem for package function,
which is why I didn't think these messages were necessarily worth
preserving.

On the other hand, if the code makes the wrong decision about sshd
version we might be interested in error logs that show why. Can we log
this to a file instead of the console, maybe?

If you'd prefer just addressing the root cause, a patch that prevents
the missing host key error is attached, but it won't stop the error
messages showing up when openssh is an older version.

Thanks,
Ben



Whoops, realized that my patch created a tempfile and didn't delete it.
Updated.


I think the first version of the patch was OK. sshd is called only to
check which set of authorized keys options to use, we don't really care
about anything else, so we can safely ignore whatever it puts to stderr.


Bump.

ACK on the first version of the patch 
(freeipa-blipton-0001-Silence-sshd-messages-during-install.patch).


Anyone against pushing it?

Given that newer OpenSSH version will silence it anyway, I'm OK with the
interim fix.
--
/ 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

[Freeipa-devel] [PATCH 0215-0216] Child domain fixes for AD trust


Hi!

Attached two patches attempt to fix some of the issues we see with child
domains.

SSSD only 'sees' users from child domains if there is an ID range for
each of them. However, after refactoring of trust code when external
trust was introduced, part of the range creation had wrong assumption
that if a trusted domain exists, its range also exists. This is now
fixed to try to create range even if the domain exists. In fact, because
the older code was not going to the range creation for trusted domains
which already existed, adding ranges was done incorrectly: ID ranges use
full domain name and don't need - hierarchy, but the code
was passing both parent and the child names. As result, an attempt to
create an ID range for parent was done instead of the child. Parent ID
range already existed so we never got to create child ID ranges at all
in that case.

Finally, there is a fix in SSSD to properly generate CA paths so that
libkrb5 can calculate correct trust path via forest root (parent)
domain. While looking at that, I also decided to simplify logic in
ipa-kdb driver because for cross-forest trust we never can transit to
the child domain directly, we always have to use the forest root domain.
However, old code could actually set a immediate domain's parent instead
of the forest root for deep level trust relationship within the forest
we trust. As we still cannot get to second level or beyond directly or
via their actual parent domain, we always have to go through the forest
root domain. The simplified code enforces this logic.


--
/ Alexander Bokovoy
From 37e4ab4786aec94bfb057fa3146d4e18e30df391 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy <aboko...@redhat.com>
Date: Sat, 6 Aug 2016 11:12:13 +0300
Subject: [PATCH 4/5] trust: make sure ID range is created for the child domain
 even if it exists

ID ranges for child domains of a forest trust were created incorrectly
in FreeIPA 4.4.0 due to refactoring of -- if the domain was already
existing, we never attempted to create the ID range for it.

At the same time, when domain was missing, we attempted to add ID range
and passed both forest root and the child domain names to add_range().
However, add_range() only looks at the first positional argument which
was the forest root name. That ID range always exists (it is created
before child domains are processed).

Modify the code to make sure child domain name is passed as the first
positional argument. In addition, the oddjob helper should explicitly
set context='server' so that idrange code will be able to see and use
ipaserver/dcerpc.py helpers.

Resolves: https://fedorahosted.org/freeipa/ticket/5738
---
 install/oddjob/com.redhat.idm.trust-fetch-domains |  2 +-
 ipaserver/plugins/trust.py| 10 +++---
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/install/oddjob/com.redhat.idm.trust-fetch-domains 
b/install/oddjob/com.redhat.idm.trust-fetch-domains
index 7c948fd..bffa021 100755
--- a/install/oddjob/com.redhat.idm.trust-fetch-domains
+++ b/install/oddjob/com.redhat.idm.trust-fetch-domains
@@ -76,7 +76,7 @@ env._bootstrap(debug=options.debug, log=None)
 env._finalize_core(**dict(DEFAULT_CONFIG))
 
 # Initialize the API with the proper debug level
-api.bootstrap(in_server=True, debug=env.debug, log=None)
+api.bootstrap(in_server=True, debug=env.debug, log=None, context='server')
 api.finalize()
 
 # Only import trust plugin after api is initialized or internal imports
diff --git a/ipaserver/plugins/trust.py b/ipaserver/plugins/trust.py
index f2e0b1e..f90d9c1 100644
--- a/ipaserver/plugins/trust.py
+++ b/ipaserver/plugins/trust.py
@@ -1673,15 +1673,19 @@ def add_new_domains_from_trust(myapi, trustinstance, 
trust_entry, domains, **opt
 if 'raw' in options:
 dom['raw'] = options['raw']
 
-res = myapi.Command.trustdomain_add(trust_name, name, **dom)
-result.append(res['result'])
+try:
+res = myapi.Command.trustdomain_add(trust_name, name, **dom)
+result.append(res['result'])
+except errors.DuplicateEntry:
+# Ignore updating duplicate entries
+pass
 
 if idrange_type != u'ipa-ad-trust-posix':
 range_name = name.upper() + '_id_range'
 dom['range_type'] = u'ipa-ad-trust'
 add_range(myapi, trustinstance,
   range_name, dom['ipanttrusteddomainsid'],
-  trust_name, name, **dom)
+  name, **dom)
 except errors.DuplicateEntry:
 # Ignore updating duplicate entries
 pass
-- 
2.7.4

From 767458d1532feb7029ff9a52e67e931fd87869ec Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy <aboko...@redhat.com>
Date: Sun, 7 Aug 2016 21:42:14 +0300
Subject: [PATCH 5/5] ipa-kdb: simplify trusted domain parent search

In terms of cross-forest trust parent domain is the root domain o

Re: [Freeipa-devel] [PATCH] 0002 Added support for authentication with user certificate


On Mon, 08 Aug 2016, Martin Kosek wrote:

On 08/05/2016 02:57 PM, Tibor Dudlak wrote:

Hi,

I have extended my previous patch for authentication with user
certificate/smartcard. This patch includes patches and plugin described here:
http://www.freeipa.org/page/V4/External_Authentication/Setup
Page also contains steps to configure and test this feature. Once this patch is
merged and released we will simplify this page to not confuse customers.
Addressing ticket: https://fedorahosted.org/freeipa/ticket/5764

Thanks.


I discussed this with Jan Pazdziora on IRC, outside of this mail thread, so let
me repeat my suggestion here. I still think it is premature to add plugins like
that to FreeIPA core git. We are not agreed yet how we will distribute FreeIPA
plugins, so I would not rush adding this plugin to FreeIPA core, especially
since it is very experimental and not even secure yet. FreeIPA plugin
distribution should be more thought through and discussed.

As I proposed, this plugin can now live outside of FreeIPA core git, in it's
own life cycle (maybe in freeipa-plugins github git repo we create?) so that it
can be updated without updating whole FreeIPA core. In this effort, I would
suggest to only consider updates of

* ipaserver/plugins/xmlserver.py
* ipaserver/rpcserver.py

as these would have to patched by admin deploying this feature and would be
overwritten by RPM updates. The plugin itself or server.conf can be deployed
and installed separatenly, even via other RPM.

Right. This was my thinking too when I saw the patches.
--
/ 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 0214] Support schema files for external plugins


On Mon, 08 Aug 2016, Petr Vobornik wrote:

On 08/08/2016 12:26 PM, Alexander Bokovoy wrote:

On Mon, 08 Aug 2016, Alexander Bokovoy wrote:

Hi!

Attached patch is what is needed to allow external plugins for FreeIPA
framework to be functional if they need to extend a schema.

The idea is that we would have a separate directory as
/usr/share/ipa/schema.d and will allow to use schema (*.ldif) files from
it and its subdirectories during install and upgrade stages.

Without the patch only selected schema files from /usr/share/ipa are
used during install and upgrade. This leads to a failure to install IPA
server (or upgrade it) if a new plugin is added. If plugin defines
managed permissions, upgrade tool will generate ACIs which will fail to
be inserted into LDAP store due to references to missing attributes and
object classes.

The patch adds a directory to be installed and a helper utility that
loads files from the directory and adds them to the list of schema files
used during update of dsinstance and upgrade of the server.

With this patch I'm successfully managed to make FleetCommander
integration plugin completely independent of FreeIPA.

Patch attached now. ;)



I'll assume that we want to target 4.4.x therefore it can be pushed to
master, right? I.e. no need for creating ipa-4-4 branch atm.

Right.


Reasoning is that currently F24 has 4.3.x. F25 will most likely have
4.4.x because 4.5 is still in planning.

Sounds good to me. FleetCommander (which is one of drivers behind the
patches) is targeting F25 as well.

--
/ 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 0214] Support schema files for external plugins