Re: [Freeipa-devel] Automated Fedora update testing

[Simo Sorce]

Top posting FTW! (sorry)

Excellent news Adam, this is awesome!

Simo.

On Fri, 2017-04-28 at 17:07 -0700, Adam Williamson wrote:
> Hi folks! I thought this might be of interest to the FreeIPA
> community,
> so I thought I'd write it up here in case anyone missed it elsewhere.
> 
> I work on the Fedora QA team, and we have been using the openQA
> automated test system (developed by our friends at SUSE) to run
> various
> functional tests on Fedora composes for the last couple of years.
> 
> As FreeIPA is considered a critical part of Fedora Server, we run a
> few
> tests that exercise FreeIPA. The tests set up a FreeIPA server, run
> some basic checks on it, and also enrol two systems as clients of the
> domain, one using the 'realm join' command directly, one using
> Cockpit.
> The client tests do some basic client functionality testing (getent,
> logging in as a domain user, changing passwords, etc.) and also test
> the web UI to some extent.
> 
> Until recently we ran these tests only on Fedora's nightly
> development
> release distribution composes. Recently, though, we deployed some
> enhancements to our openQA setup that let us run tests on Fedora
> distribution updates as well, and have the results made visible
> through
> the Fedora update system (Bodhi). The tests are automatically run on
> any critical path package, and as of today, they are also run on any
> update containing any of a manually-tended list of FreeIPA-related
> packages:
> 
> 389-ds
> 389-ds-base
> bind
> bind-dyndb-ldap
> certmonger
> ding-libs
> freeipa
> krb5-server
> pki-core
> sssd
> tomcat
> cockpit
> 
> This means that for any Fedora update containing one of these or any
> critical path package, Fedora's openQA FreeIPA tests should run, and
> you should see the results in the Fedora update system (Bodhi). You
> can
> see the results in Bodhi by clicking the Automated Updates tab for
> any
> update. For instance, here's a recent 389-ds-base update for Fedora
> 26:
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2017-15e2a038b2
> 
> If you look at the Automated Tests tab, you can see passes for:
> 
> update.server_role_deploy_domain_controller
> update.realmd_join_cockpit
> update.realmd_join_sssd
> 
> indicating that this update didn't cause any problems for FreeIPA.
> Clicking on any test result will take you to the openQA page for the
> test, where you can diagnose failures and so on (explaining how to do
> this is a bit beyond the scope of this mail, please do ask me if
> you're
> interested!)
> 
> I hope this stuff will help us avoid shipping updates that break
> FreeIPA (and other key components). If you have any questions,
> concerns, comments, or suggestions, please do ask!
> 
> To anticipate one question: you can cause *all* the tests for an
> update
> to be re-run by editing the update in any way (you don't have to
> change
> the package loadout, just changing a single character in the
> description or something will do). If you think just one test result
> is
> bogus and want it re-run, currently, you'll have to ask someone with
> the necessary power - either me or Jan Sedlak (garretraziel on IRC).
> I'm in North America and he's in Europe, so we should have most
> timezones covered between us. We're hoping to set up a better
> mechanism
> for this in future.
> 
> Note, if you're interested in the results for the nightly Fedora
> distribution composes, an email summary of the results for those is
> sent each time they're run to the Fedora test@ and devel@ lists, look
> for mails with "compose check report" in the subject. Any time any of
> the FreeIPA tests fails, the failure will be listed in the mail
> (passed
> tests are not specifically listed, just a count of them). I usually
> keep an eye on those results and analyze failures and file bugs,
> though.
> -- 
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin .
> net
> http://www.happyassassin.net
> 

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] KDC proxy URI records

[Simo Sorce]

On Thu, 2017-04-27 at 15:56 +0200, Petr Vobornik wrote:
> On 04/27/2017 02:19 PM, Christian Heimes wrote:
> > On 2017-04-27 14:00, Martin Bašti wrote:
> > > I would like to discuss consequences of adding kdc URI records:
> > > 
> > > 1. basically all ipa clients enrolled using autodiscovery will
> > > use
> > > kdcproxy instead of KDC on port 88, because URI takes precedence
> > > over
> > > SRV in KRB5 client implementation. Are we ok with such a big
> > > change?
> > 
> > Does the client also prefer KKDCP if you give the Kerberos 88/UDP
> > and
> > 88/TCP URIs a higher priority than the KKDCP HTTPS URIs?
> > 
> > > 2. probably client installer must be updated because currently
> > > with
> > > CA-full installation it is not working.
> > > 
> > > ipa-client-install (with autodiscovery) failed on kinit, see
> > > KRB5_TRACE
> > > bellow that it refuses self signed certificate
> > 
> > Actually it is not a self-sigend EE certificate. The validation
> > message
> > is bogus because FreeIPA TLS configuration is slightly buggy. We
> > send
> > the trust anchor (root CA) although a server should not include its
> > trust anchor in its ServerHello message. OpenSSL detects an
> > untrusted
> > root CA in the ServerHello peer chain and emits the message.
> > 
> > If I read the 600 lines (!) function
> > ipaclient.install.client._install
> > correctly, then ipa-client-install first attempts to negotiate a
> > TGT and
> > then installs the trust anchor in the global trust store. It should
> > be
> > enough to reverse the order and inject the trust anchor first.
> > 
> > Christian
> > 
> 
> By reading this, even if we do the change in client install, I'd
> rather 
> not generate the DNS records in 4.5.1 release and rather make sure
> that 
> everything works during 4.6 development.
> 
> The reason is that there might also be something else not working and
> it 
> is better to time test it + the fix would not fix older clients.
> 
> If anybody wants to use/try it, then the records can be created
> manually.



We need to ix clients regardless, o someone enabling it will find the
same issues.

Simo.


-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [freeipa PR#723][+ack] Store GSSAPI session key in /var/run/httpd

[Simo Sorce]

On Thu, 2017-04-27 at 10:42 +0200, MartinBasti wrote:
>   URL: https://github.com/freeipa/freeipa/pull/723
> Title: #723: Store GSSAPI session key in /var/run/httpd
> 
> Label: +ack

Guys I explained in the bug[1] that this is wrong, why was this acked
and pushed ?

Besides how does this even work ? /var/run/ipa is owned by root and
apache has no rights to create files there and the patch does not
address any permission problem.

I assume what happens is that now mod_auth_gssapi is runnig with an
ephemeral in-process key, which means any reload or restart of apache
will change the key.

Please revert!

Simo.

[1] https://pagure.io/freeipa/issue/6880#comment-437767

-- 
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] Pagure issue template

[Simo Sorce]

On Fri, 2017-04-21 at 10:17 +0200, Petr Vobornik wrote:
> On 04/21/2017 08:49 AM, Standa Laznicka wrote:
> > On 04/21/2017 08:12 AM, Abhijeet Kasurde wrote:
> >> +1
> >>
> >> On 20/04/17 9:36 PM, Petr Vobornik wrote:
> >>> Hi all,
> >>>
> >>> I'd like to improve quality of bug reports and RFEs.
> >>>
> >>> A possibility I see is to create and issue template [1].
> > Sounds like a good idea! Please see my comments.
> >>>
> >>> What do you think of the following template? Should we use it?
> >>>
> >>> """"
> >>> ### Request for enhancement
> >>> As  , I want <what?> so that <why?>.
> > This sounds very labored. How about using:
> > "I am a  and I want ..."
> >>>
> >>> ### Bug
> >>>  What doesn't work (what was the goal)
> > "What's not working" proposes the situation will change and
> > sounds better IMO
> >>>
> 
> I took some inspiration from the Atom template. But tried to keep it 
> shorter. As a bonus I added a link where people can find log files and a 
> link to troubleshooting page.
> 
> New one:
> """
> ### Request for enhancement
> As <persona, e.g. admin> , I want <what?> so that <why?>.
> 
> ### Issue
> [description of the issue]
> 
>  Steps to Reproduce
> 1.
> 2.
> 3.
> 
>  Actual behavior
> (what happens)
> 
>  Expected behavior
> (what do you expect to happen)
> 
>  Version/Release/Distribution
> $ rpm -q freeipa-server freeipa-client ipa-server ipa-client 
> 389-ds-base pki-ca krb5-server
> 
>  Additional info:
> Any additional information, configuration, data or log snippets that is 
> needed for reproduction or investigation of the issue.
> 
> Log file locations: 
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/config-files-logs.html
> Troubleshooting guide: https://www.freeipa.org/page/Troubleshooting
> """

+1 

> 
> >>>
> >>
> >> 1.  Can we add pre-defined set of components in title ? for example,
> 
> I don't know if it is possible. Probably not.
> 
> >>
> >> [CERT] some_cert_related bug description
> >> [installer] some installer related bug description
> > This is what Pagure has tags for. But you're right we might be missing
> > some, although "CERT" is probably not a good example, installer is. On
> > the other hand, "userstory" is a tag I will myself never use on purpose.
> >>
> >> 2. Also, Having a bot in place which will enforce or atleast suggest
> >> reporter to modify bug report.
> 
> Could you elaborate?
> 
> >>
> >>> [1] https://docs.pagure.org/pagure/usage/ticket_templates.html
> >>
> > My hope is that the issue template should do itself.
> >
> > For the record, I love the way Atom guides you through their issue
> > creation: https://github.com/atom/atom/issues/new.
> >
> 
> -- 
> Petr Vobornik
> 
> Associate Manager, Engineering, Identity Management
> Red Hat
> 


-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc


-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] KDC proxy URI records

[Simo Sorce]

On Wed, 2017-04-26 at 12:57 +0200, Martin Bašti wrote:
> 
> On 25.04.2017 16:57, Martin Bašti wrote:
> > Hello all,
> >
> > I'm going to implement automatic URI records for kdc proxy and I'd 
> > like to clarify if following URI records are the right one.
> >
> >
> > _kerberos-adm.example.com. IN URI  0 
> > "krb5srv:M:kkdcp:https://ipaserver.example.com/KdcProxy;
> >
> > _krb5kdc.example.com. IN URI  0 
> > "krb5srv:M:kkdcp:https://ipaserver.example.com/KdcProxy;
> >
> > _kpasswd.example.com. IN URI  0 
> > "krb5srv:M:kkdcp:https://ipaserver.example.com/KdcProxy;
> >
> >
> > I assume we want to use "kkdcp" and "https", and "M" flag as all IPA 
> > servers are masters, please confirm.
> >
> >
> > Sources:
> >
> > https://k5wiki.kerberos.org/wiki/Projects/KDC_Discovery
> >
> > https://tools.ietf.org/id/draft-mccallum-kitten-krb-service-discovery-02.txt
> >  
> >
> >
> >
> > Thank you
> >
> 
> I found out that wiki page differs from the RFC draft and from the 
> source in git
> 
> There is "_kerberos.REALM" record instead of "_krb5kdc.REALM"
> 
> 
> And I'm not sure if _kerberos-adm should be included as we don't really 
> support kadmin.

We shouldn't.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc


-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] PKINIT Handling in mixed/CA-less topologies

[Simo Sorce]

On Fri, 2017-03-24 at 11:52 +0100, Martin Babinsky wrote:
> On Fri, Mar 24, 2017 at 10:53:49AM +0200, Alexander Bokovoy wrote:
> >On pe, 24 maalis 2017, Martin Babinsky wrote:
> >> On Thu, Mar 23, 2017 at 04:46:20PM +0200, Alexander Bokovoy wrote:
> >> > On to, 23 maalis 2017, Simo Sorce wrote:
> >> > > On Thu, 2017-03-23 at 16:08 +0200, Alexander Bokovoy wrote:
> >> > > > On to, 23 maalis 2017, Martin Babinsky wrote:
> >> > > > >Hi List,
> >> > > > >
> >> > > > >TL;DR we have to handle FAST channer establishment  when KDC is not 
> >> > > > >issued
> >> > > > >PKINIT keypair
> >> > > > >
> >> > > > >I have spent some time studying and fixing bugs/regressions caused 
> >> > > > >by
> >> > > > >incomplete consideration of PKINIT and anonymous principal setup 
> >> > > > >regarding to
> >> > > > >
> >> > > > >* replicas standed up against old (3.0.0) masters
> >> > > > >* domain level 0 topologies
> >> > > > >* CA-less deployments
> >> > > > >
> >> > > > >I want to discuss the impact of these findings on existing 
> >> > > > >functionality and
> >> > > > >how to fix them so that 4.5.1 release will be more usable and free 
> >> > > > >of subtle
> >> > > > >but serious bugs (more on this later).
> >> > > > >
> >> > > > >From conversation from Alexander and Simo it follows that anonymous 
> >> > > > >PKINIT
> >> > > > >feature is supposed to be used in domain level 1 deployments 
> >> > > > >because only these
> >> > > > >guarantee the presence of the features (CA ACLs and custom 
> >> > > > >certificate
> >> > > > >profiles) which allow for issuing certificates suitable for PKINIT
> >> > > > >authentication. This leads to the following considerations:
> >> > > > >
> >> > > > >* on DL0 enforce no_pkinit on server/replica deployments
> >> > > > >* during upgrade of DL0 deployments, do not issue PKINIT 
> >> > > > >certificates
> >> > > > >* during upgrade of DL1 deployments issue PKINIT certs
> >> > > > >* extend ipa-server-certinstall to install/issue PKINIT 
> >> > > > >certificates after
> >> > > > >  DL0/DL1 ugrade (have to be manually).
> >> > > > >
> >> > > > >However, I found out that the only case when anonymous PKINIT 
> >> > > > >actually works is
> >> > > > >for fresh DL1 server install and upgrade and install of 4.5.0 
> >> > > > >replica against
> >> > > > >4.5.0 master in DL1. The following use-cases either fail to install 
> >> > > > >or leave
> >> > > > >the system with unusable password auth (e.g. WebUI login):
> >> > > > >
> >> > > > >* setting up 4.5 replica against <4.5 master fails during anonymous
> >> > > > >  principal setup[1] (ticket states domain level 0, but DL1 is also
> >> > > > >  affected)
> >> > > > >* setting up server-replica with `no_pkinit` option (CA-full or 
> >> > > > >CA-less)
> >> > > > >  leaves the installation without non-working WebUI as anonymous 
> >> > > > > PKINIT does
> >> > > > >  not work (ticket incoming)
> >> > > > >* If we restrict DL0 installs to force no_pkinit[2] we will be left 
> >> > > > >with
> >> > > > >  whole topologies where anonymous PKINIT does not work, so no 
> >> > > > > WebUI auth
> >> > > > >  for them
> >> > > > >
> >> > > > >We now have to decide how to properly support or avoid non-PKINIT 
> >> > > > >deployments.
> >> > > > >The current code which handles armoring of password auth 
> >> > > > >requests[3] does not
> >> > > > >actually work without PKINIT certificates, the fallback mechanism 
> >> > > > >still fails
> >> > > > >to obtain armor ccache[4].
> >> > > > >
&

Re: [Freeipa-devel] PKINIT Handling in mixed/CA-less topologies

[Simo Sorce]

On Thu, 2017-03-23 at 16:08 +0200, Alexander Bokovoy wrote:
> On to, 23 maalis 2017, Martin Babinsky wrote:
> >Hi List,
> >
> >TL;DR we have to handle FAST channer establishment  when KDC is not issued
> >PKINIT keypair
> >
> >I have spent some time studying and fixing bugs/regressions caused by
> >incomplete consideration of PKINIT and anonymous principal setup regarding to
> >
> >* replicas standed up against old (3.0.0) masters
> >* domain level 0 topologies
> >* CA-less deployments
> >
> >I want to discuss the impact of these findings on existing functionality and
> >how to fix them so that 4.5.1 release will be more usable and free of subtle
> >but serious bugs (more on this later).
> >
> >From conversation from Alexander and Simo it follows that anonymous PKINIT
> >feature is supposed to be used in domain level 1 deployments because only 
> >these
> >guarantee the presence of the features (CA ACLs and custom certificate
> >profiles) which allow for issuing certificates suitable for PKINIT
> >authentication. This leads to the following considerations:
> >
> >* on DL0 enforce no_pkinit on server/replica deployments
> >* during upgrade of DL0 deployments, do not issue PKINIT certificates
> >* during upgrade of DL1 deployments issue PKINIT certs
> >* extend ipa-server-certinstall to install/issue PKINIT certificates after
> >  DL0/DL1 ugrade (have to be manually).
> >
> >However, I found out that the only case when anonymous PKINIT actually works 
> >is
> >for fresh DL1 server install and upgrade and install of 4.5.0 replica against
> >4.5.0 master in DL1. The following use-cases either fail to install or leave
> >the system with unusable password auth (e.g. WebUI login):
> >
> >* setting up 4.5 replica against <4.5 master fails during anonymous
> >  principal setup[1] (ticket states domain level 0, but DL1 is also
> >  affected)
> >* setting up server-replica with `no_pkinit` option (CA-full or CA-less)
> >  leaves the installation without non-working WebUI as anonymous PKINIT does
> >  not work (ticket incoming)
> >* If we restrict DL0 installs to force no_pkinit[2] we will be left with
> >  whole topologies where anonymous PKINIT does not work, so no WebUI auth
> >  for them
> >
> >We now have to decide how to properly support or avoid non-PKINIT 
> >deployments.
> >The current code which handles armoring of password auth requests[3] does not
> >actually work without PKINIT certificates, the fallback mechanism still fails
> >to obtain armor ccache[4].
> >
> >I have concluded that for non-PKINIT cases we have
> >to use the old way to armor TGT request (i.e. establish fast channel by
> >kinit as service principal), but this means that the framewrok has to use a
> >service principal whose keytab it can read and use. After privilege 
> >separation,
> >however, we do not have direct access to HTTP keytab so how should we proceed
> >in this case? We definitely need to discuss this further.
> >
> >Please state your suggestions and comments, and sorry for the long mail.
> Thanks, Martin, for the thorough analysis.
> 
> I need to clarify *why* we need working Anonymous PKINIT. There are two
> separate needs here:
> 
>  - Enable clients with no access to a separate key to be usable for 2FA
>accounts. This can be best explained as to support Kerberos auth from
>non-enrolled machines or machines where no SSSD is in use. In such
>cases we cannot use another credentials to create FAST channel and
>pass 2FA creds with kinit.
> 
>  - Enable IPA framework to perform password-based login for 2FA. With
>privilege separation we don't have access to HTTP/... principal's
>keytab anymore (gssproxy does) and neither GSSAPI nor gssproxy
>support FAST channel wrapping for explicitly specified password+2FA
>token.
> 
> For DL0 we do not officially support PKINIT, so first case is not
> relevant. However, second case is what we need even on DL0 because
> otherwise IPA framework does not work, as you have witnessed.
> 
> We thought that we could solve this problem by re-using anonymous
> principal as 'normal' principal -- by fetching its keytab and
> authenticating with the keys from it. But for anonymous principal MIT
> Kerberos library does verification of the session key and requires it to
> be provided with PKINIT PA DATA when there is no wrapping principal
> keys.
> 
> See RFC 6112 section 4.1: https://tools.ietf.org/html/rfc6112#section-4.1
> 
> 
>The Kerberos client can use the client's long-term keys, the client's
>X.509 certificates [RFC4556], or any other pre-authentication data,
>to authenticate to the KDC and requests an anonymous ticket in an AS
>exchange where the client's identity is known to the KDC.
> 
>If the client in the AS request is anonymous, the anonymous KDC
>option MUST be set in the request.  Otherwise, the KDC MUST return a
>KRB-ERROR message with the code KDC_ERR_BADOPTION.
> 
> 
> Corresponding code in MIT Kerberos is this: 
> 

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

[Simo Sorce]

On Tue, 2017-03-07 at 09:38 +0100, Martin Babinsky wrote:
> On 03/06/2017 01:48 PM, Simo Sorce wrote:
> > On Mon, 2017-03-06 at 07:47 +0100, Martin Babinsky wrote:
> >> On 03/02/2017 02:54 PM, Simo Sorce wrote:
> >>> On Thu, 2017-03-02 at 08:10 +0100, Martin Babinsky wrote:
> >>>> In this case it would probably be a good idea to think about "forward
> >>>> compatibility" and define a new AUX objectclass bringing in
> >>>> 'ipaDomainResolutionOrder' instead of extending two separate
> >>>> objectclasses. In this way we may the just extend whathever object we
> >>>> desire to carry the override in an easy and clean way.
> >>>
> >>> I agree.
> >>> Simo.
> >>>
> >>
> >> Now the most difficult question remains... How to name this objectclass.
> >> I personally am out of ideas but will try my best to come up with
> >> something meaningful.
> >
> > Try to describe what the option ultimately does with as few words as
> > possible.
> >
> > Simo.
> >
> >
> 
> I was thinking about this and since we are performing name qualification 
> (short-name -> fully-qualified name incl. domain/realm part), I would 
> like to propose the following naming schema:
> 
> objectlasses: ( OID_TBD NAME ipaNameQualificationData Desc 'data used 
> for short name qualification data' SUP top AUXILIARY MAY 
> (ipaNameQualificationDomainList) X-ORIGIN 'IPA 4.5' )
> 
> attributeTypes: ( OID_TBD NAME 'ipaNameQualificationDomainList' DESC 
> 'List of domains used to qualify user short name' EQUALITY 
> caseIgnoreIA5Match SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
> X-ORIGIN 'IPA v4.5' )
> 
> Let me know if you are ok with this or am I overengineering the names?
> 
> I would like to solve this quickly so that I can finish the design and 
> start implementation.

I was thinking that we can use acronyms here to make it less of a
mouthful and also more easily recognizable:
My idea is:
- ipaNameQualificationData -> ipaFQDNPolicies
- ipaNameQualificationDomainList -> ipaFQDNCheckOrder

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

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

[Simo Sorce]

On Mon, 2017-03-06 at 07:47 +0100, Martin Babinsky wrote:
> On 03/02/2017 02:54 PM, Simo Sorce wrote:
> > On Thu, 2017-03-02 at 08:10 +0100, Martin Babinsky wrote:
> >> In this case it would probably be a good idea to think about "forward
> >> compatibility" and define a new AUX objectclass bringing in
> >> 'ipaDomainResolutionOrder' instead of extending two separate
> >> objectclasses. In this way we may the just extend whathever object we
> >> desire to carry the override in an easy and clean way.
> >
> > I agree.
> > Simo.
> >
> 
> Now the most difficult question remains... How to name this objectclass. 
> I personally am out of ideas but will try my best to come up with 
> something meaningful.

Try to describe what the option ultimately does with as few words as
possible.

Simo.


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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

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

[Simo Sorce]

On Thu, 2017-03-02 at 08:10 +0100, Martin Babinsky wrote:
> In this case it would probably be a good idea to think about "forward 
> compatibility" and define a new AUX objectclass bringing in 
> 'ipaDomainResolutionOrder' instead of extending two separate 
> objectclasses. In this way we may the just extend whathever object we 
> desire to carry the override in an easy and clean way.

I agree.
Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

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

[Simo Sorce]

On Wed, 2017-03-01 at 17:29 +0100, Martin Basti wrote:
> 
> On 01.03.2017 17:04, Simo Sorce wrote:
> > On Wed, 2017-03-01 at 16:47 +0100, Martin Babinsky wrote:
> >> On 03/01/2017 04:32 PM, Simo Sorce wrote:
> >>> On Wed, 2017-03-01 at 16:17 +0100, Martin Babinsky wrote:
> >>>> On 03/01/2017 03:42 PM, Simo Sorce wrote:
> >>>>> On Tue, 2017-02-28 at 13:29 +0100, 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.
> >>>>>>
> >>>>>> [1] https://www.freeipa.org/page/V4/AD_User_Short_Names
> >>>>>> [2] https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
> >>>>> Thank you Martin,
> >>>>> this is a good initial proposal.
> >>>>>
> >>>>> I have a few issues with this design:
> >>>>> - It conflates the idea of ordering with the idea of shortening user
> >>>>> names
> >>>> I fail to see where the conflation takes place. The ordered list is
> >>>> stored on the server. The client then uses it to expand short names. I
> >>>> guess I am just missing something.
> >>> The attribute is called ipaNTDomainResolutionOrder, nothing in that
> >>> attribute says anything about making names become short names.
> >>> If it were ipaNTShortNameDomainResolutionOrder then it would be
> >>> specific, as it is it seem just to refer to the order in which domain
> >>> are resolved, but that is somethign we want in order to determine which
> >>> domains SSSD is going to make use short names too, not just the order in
> >>> which domains are resolved.
> >>> I hope this makes it clearer.
> >>>
> >>>>> - It allows only for one setting for all the machines, no way to treat
> >>>>> different groups of machines differently
> >>>>>
> >>>> Yes it was discussed that the setting will be global. I would implement
> >>>> local overrides only when there is a demand for the feature given
> >>>> development time is short.
> >>> Demand is immediate, and it is obvious IMO.
> >>>
> >> Such demand was not made clear during previous discussions and was not
> >> mentioned by SSSD guys either AFAIK.
> > I guess this is why we do reviews :-)
> &g

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

[Simo Sorce]

On Wed, 2017-03-01 at 16:47 +0100, Martin Babinsky wrote:
> On 03/01/2017 04:32 PM, Simo Sorce wrote:
> > On Wed, 2017-03-01 at 16:17 +0100, Martin Babinsky wrote:
> >> On 03/01/2017 03:42 PM, Simo Sorce wrote:
> >>> On Tue, 2017-02-28 at 13:29 +0100, 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.
> >>>>
> >>>> [1] https://www.freeipa.org/page/V4/AD_User_Short_Names
> >>>> [2] https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
> >>>
> >>> Thank you Martin,
> >>> this is a good initial proposal.
> >>>
> >>> I have a few issues with this design:
> >>> - It conflates the idea of ordering with the idea of shortening user
> >>> names
> >>
> >> I fail to see where the conflation takes place. The ordered list is
> >> stored on the server. The client then uses it to expand short names. I
> >> guess I am just missing something.
> >
> > The attribute is called ipaNTDomainResolutionOrder, nothing in that
> > attribute says anything about making names become short names.
> > If it were ipaNTShortNameDomainResolutionOrder then it would be
> > specific, as it is it seem just to refer to the order in which domain
> > are resolved, but that is somethign we want in order to determine which
> > domains SSSD is going to make use short names too, not just the order in
> > which domains are resolved.
> > I hope this makes it clearer.
> >
> >>> - It allows only for one setting for all the machines, no way to treat
> >>> different groups of machines differently
> >>>
> >>
> >> Yes it was discussed that the setting will be global. I would implement
> >> local overrides only when there is a demand for the feature given
> >> development time is short.
> >
> > Demand is immediate, and it is obvious IMO.
> >
> 
> Such demand was not made clear during previous discussions and was not 
> mentioned by SSSD guys either AFAIK.

I guess this is why we do reviews :-)

> >>> The first one is probably just a matter of using a more specific name
> >>> for the new attribute, or, perhaps not use a new attribute at all but
> >>> just use ipaConfigString with an agreed syntax like:
> >>> ipaConfigString: Domains Use Short Name List: aaa bbb ccc ddd
> >>>
> >>> The side effect of using ipaConfigString is that we can set this on
> >>> older servers too, so people do not have to upgrade their servers to use
> >>> this. Old servers will not have any validation, but that is ok, sssd
> >>> must be prepared to receive a bad list and deal with it appropriately
> >>> anyway.
> >>>
> >>

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

[Simo Sorce]

On Wed, 2017-03-01 at 16:17 +0100, Martin Babinsky wrote:
> On 03/01/2017 03:42 PM, Simo Sorce wrote:
> > On Tue, 2017-02-28 at 13:29 +0100, 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.
> >>
> >> [1] https://www.freeipa.org/page/V4/AD_User_Short_Names
> >> [2] https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
> >
> > Thank you Martin,
> > this is a good initial proposal.
> >
> > I have a few issues with this design:
> > - It conflates the idea of ordering with the idea of shortening user
> > names
> 
> I fail to see where the conflation takes place. The ordered list is 
> stored on the server. The client then uses it to expand short names. I 
> guess I am just missing something.

The attribute is called ipaNTDomainResolutionOrder, nothing in that
attribute says anything about making names become short names.
If it were ipaNTShortNameDomainResolutionOrder then it would be
specific, as it is it seem just to refer to the order in which domain
are resolved, but that is somethign we want in order to determine which
domains SSSD is going to make use short names too, not just the order in
which domains are resolved.
I hope this makes it clearer.

> > - It allows only for one setting for all the machines, no way to treat
> > different groups of machines differently
> >
> 
> Yes it was discussed that the setting will be global. I would implement 
> local overrides only when there is a demand for the feature given 
> development time is short.

Demand is immediate, and it is obvious IMO.

> > The first one is probably just a matter of using a more specific name
> > for the new attribute, or, perhaps not use a new attribute at all but
> > just use ipaConfigString with an agreed syntax like:
> > ipaConfigString: Domains Use Short Name List: aaa bbb ccc ddd
> >
> > The side effect of using ipaConfigString is that we can set this on
> > older servers too, so people do not have to upgrade their servers to use
> > this. Old servers will not have any validation, but that is ok, sssd
> > must be prepared to receive a bad list and deal with it appropriately
> > anyway.
> >
> 
> No more 'ipaConfigString' attribute values, please. Me and everyone else 
> fixing e.g. replication issues can relate to the pain of doing CRUD 
> operations involving them.

ipaConfigString was devised explicitly so that configuration options
could be added without replication issues because the string can be
accepted by any server version.
So what replication issues are there ?
What has CRUD to do with it ?

> If the admin wishes old servers to server new clients this information, 

They do not "wish", this is pretty much what happens all the time ...

> all he has to do is upgrade a single replica, set the attribute value 
> there and let replication take care of the rest.

Come on, really ?
If you have RHEL6 it is not a matter of "simply" upgrading a single
replica, it means upgrade of the whole infrastructure ...

> Yes, the management CLI 
> will not be available on the old masters but 

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

[Simo Sorce]

On Tue, 2017-02-28 at 13:29 +0100, 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.
> 
> [1] https://www.freeipa.org/page/V4/AD_User_Short_Names
> [2] https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

Thank you Martin,
this is a good initial proposal.

I have a few issues with this design:
- It conflates the idea of ordering with the idea of shortening user
names
- It allows only for one setting for all the machines, no way to treat
different groups of machines differently

The first one is probably just a matter of using a more specific name
for the new attribute, or, perhaps not use a new attribute at all but
just use ipaConfigString with an agreed syntax like:
ipaConfigString: Domains Use Short Name List: aaa bbb ccc ddd

The side effect of using ipaConfigString is that we can set this on
older servers too, so people do not have to upgrade their servers to use
this. Old servers will not have any validation, but that is ok, sssd
must be prepared to receive a bad list and deal with it appropriately
anyway.


The second one is something we *may* address later, and use the setting
in cn=ipaConfig as a default, but there are two reasons why I think a
setting applicable to just a host group makes sense:
- it allows to test the setting on a small set of machines to see if
everything works right, this is going to be especially important on
existing setups, where people do not want to risk all machines
misbehaving at once if something goes wrong.
- it allows to migrate machines slowly, in some cases people may need to
change local files/application settings on machines if the usernames
change, so they may need a controlled roll out before changing a setting
globally.

This may achieved by adding this setting to an ID View for example, then
only hosts in that IDView would get this. Or a new object could be
created that has members, the former has the advantage of being already
in place and SSSD already downloads that data, the latter allows to
target an even smaller set of hosts unrelated to previous ID views
settings.

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Requiring simultaneous authentication to Linux resources

[Simo Sorce]

On Wed, 2017-02-22 at 10:59 +, Oucema Bellagha wrote:
> I want to figure out a solution which allow user"a" to authenticate to
> a host only when user"b" is accessing the host for security reasons.
> 
> 
> Easy explanation: authenticate to hostx needs (user a + user b)
> 
> 
> I'm brainstorming some ideas using Yubikey or ssh-keys.. Is there any
> application which allow us to access a host only when 2 users are
> present cause putty doesn't have this feature which can be a step to
> solve this problem ..
> 
> 
> Or in applying some specified rules in IPA itself ?

As explained, there is no such concept in Unix/Linux to start with, but
maybe you mean that you want to check credentials of 2 different users
to allow privileged login, like root login ?

Or is this something else ?

It'd be nice if you can describe precisely what actions and results you
expect to see.

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Anonymous PKINIT and kdcproxy

[Simo Sorce]

On Mon, 2016-12-12 at 09:42 +0100, 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.

No changes needed, we only use AS and TGS request types.

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [freeipa PR#314][edited] RFC: privilege separation for ipa framework code

[Simo Sorce]

On Fri, 2016-12-09 at 08:31 +0100, Martin Basti wrote:
> 
> On 08.12.2016 22:47, Simo Sorce wrote:
> > On Thu, 2016-12-08 at 21:46 +0100, simo5 wrote:
> >> URL: https://github.com/freeipa/freeipa/pull/314
> >> Author: simo5
> >>   Title: #314: RFC: privilege separation for ipa framework code
> >> Action: edited
> >>
> >>   Changed field: body
> >> Original value:
> >> """
> >> As part of the External Authentication work this PR implements the 
> >> privilege separation portion of the design available here: 
> >> https://www.freeipa.org/page/V4/External_Authentication and implements 
> >> tickets: https://fedorahosted.org/freeipa/ticket/5959 and 
> >> https://fedorahosted.org/freeipa/ticket/4189
> >>
> >> The update process from an old server has not been implemented yet, so 
> >> this is just an RFC request at this stage. Please look at the code and let 
> >> me know if you notice any major issue with it so we can correct mistakes 
> >> early.
> >>
> >> This PR depends on improvements and fixes to two dependencies: 
> >> mod_auth_gssapi and gssproxy, which are not released/accepted upstream yet 
> >> (all PRs filed, and will be available soon).
> >> In order to allow trying the code, I made two copr repos with the 
> >> necessary changes available here:
> >> - https://copr.fedorainfracloud.org/coprs/simo/mod_auth_gssapi/
> >> - https://copr.fedorainfracloud.org/coprs/simo/gssproxy/
> >>
> >> I tested a new install and both gssapi as well as password authentication 
> >> work (via command line and web browser). I have not tested OTP 
> >> authentication yet.
> >>
> >> There are 2 fundamental changes in this code:
> >> - the session handling code has been dropped in favor of deferring session 
> >> handling to mod_auth_gssapi, simplifying the code greatly. As part of this 
> >> change we stop using memcached.
> >> - the framework configuration is changed to work as a different user from 
> >> the Apache framework and depends on gssproxy in order to be able to access 
> >> necessary credentials. (Apache itself is also using gssproxy and does not 
> >> have direct access to the HTTP keytab.)
> >>This required two changes in the form-based authentication workflow:
> >>* The armor cache is obtained via anonymous pkinit as we do not have 
> >> access anymore to the HTTP keytab. This means this PR depends on #62 
> >> (until it is accepted commits from that PR are in this PR)
> >>* The actual authentication is done via a loopback HTTP request to 
> >> apache after we obtain a TGT, this is done in order to obtain a session 
> >> cookie from mod_auth_gssapi as well as to be able to immediately discard 
> >> the TGT and just keep the HTTP ticket instead.
> >>
> >> @jcholast @pvoborni Please provide comments on the framework changes.
> >> @rcritten @abbra do you have ideas on how to deal with dropping a service 
> >> (memcached) on upgrade ?
> >> """
> >>
> >> -- 
> >> 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
> > There seem to be a bug in the mailing list posting script when someone
> > edits a PR description, I see the original text here but not the new
> > text!
> >
> > Simo.
> >
> It is expected,
> 
>   Changed field: body
> Original value:
> 
> I just haven't had time to implement sending a new values (because of format, 
> of github messages it is not so simple) I may try to finish github 
> notification RFEs today

Ok thanks,
just wanted to make sure you knew about this.

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [freeipa PR#314][edited] RFC: privilege separation for ipa framework code

[Simo Sorce]

On Thu, 2016-12-08 at 21:46 +0100, simo5 wrote:
>URL: https://github.com/freeipa/freeipa/pull/314
> Author: simo5
>  Title: #314: RFC: privilege separation for ipa framework code
> Action: edited
> 
>  Changed field: body
> Original value:
> """
> As part of the External Authentication work this PR implements the privilege 
> separation portion of the design available here: 
> https://www.freeipa.org/page/V4/External_Authentication and implements 
> tickets: https://fedorahosted.org/freeipa/ticket/5959 and 
> https://fedorahosted.org/freeipa/ticket/4189
> 
> The update process from an old server has not been implemented yet, so this 
> is just an RFC request at this stage. Please look at the code and let me know 
> if you notice any major issue with it so we can correct mistakes early.
> 
> This PR depends on improvements and fixes to two dependencies: 
> mod_auth_gssapi and gssproxy, which are not released/accepted upstream yet 
> (all PRs filed, and will be available soon).
> In order to allow trying the code, I made two copr repos with the necessary 
> changes available here:
> - https://copr.fedorainfracloud.org/coprs/simo/mod_auth_gssapi/
> - https://copr.fedorainfracloud.org/coprs/simo/gssproxy/
> 
> I tested a new install and both gssapi as well as password authentication 
> work (via command line and web browser). I have not tested OTP authentication 
> yet.
> 
> There are 2 fundamental changes in this code:
> - the session handling code has been dropped in favor of deferring session 
> handling to mod_auth_gssapi, simplifying the code greatly. As part of this 
> change we stop using memcached.
> - the framework configuration is changed to work as a different user from the 
> Apache framework and depends on gssproxy in order to be able to access 
> necessary credentials. (Apache itself is also using gssproxy and does not 
> have direct access to the HTTP keytab.)
>   This required two changes in the form-based authentication workflow:
>   * The armor cache is obtained via anonymous pkinit as we do not have access 
> anymore to the HTTP keytab. This means this PR depends on #62 (until it is 
> accepted commits from that PR are in this PR)
>   * The actual authentication is done via a loopback HTTP request to apache 
> after we obtain a TGT, this is done in order to obtain a session cookie from 
> mod_auth_gssapi as well as to be able to immediately discard the TGT and just 
> keep the HTTP ticket instead.
> 
> @jcholast @pvoborni Please provide comments on the framework changes.
> @rcritten @abbra do you have ideas on how to deal with dropping a service 
> (memcached) on upgrade ?
> """
> 
> -- 
> 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

There seem to be a bug in the mailing list posting script when someone
edits a PR description, I see the original text here but not the new
text!

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] NTP in FreeIPA

[Simo Sorce]

On Wed, 2016-11-30 at 16:57 +0100, David Kupka wrote:
> Upgrades to 4.x will revert configuration if done by FreeIPA.

Why would you revert a perfectly valid configuration ?
I can understand that you wan to stop managing the server, but I do not
see why you should un-configure it.

> I think it's actually that simple. The only hard part is reaching the 
> agreement.

I still think we need to offer the NTP option even if not on by default,
so on upgrade we would have to keep maintaining it.

Keep in mind that NTP is extremely important, still, in virtualized
environment and PoC environment where you must assure, with your own
means, that clocks are synchronized. Testing environments are often very
broken, reason why we also offer a DNS server.
And a testing environment generally give you the first impression, so if
it breaks horrible (as it does when clocks are not in sync then people
just stop caring and do not move to production.

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [freeipa PR#184][comment] Minor install script fixes

[Simo Sorce]

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 ?

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Feature branches for sub-team efforts

[Simo Sorce]

On Tue, 2016-10-11 at 16:19 +0200, 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.

Please go with this.
I see no point in having these branches in the main repo, it is just
clutter.

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

Exactly.

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

Why would you need ipatool for a working branch ?

> Pre-defined names for PRs is a good idea - we could easily see what
> effort the pull request is related to.

Predefined how ?

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] What would break if loopback addresses were allowed for IPA server?

[Simo Sorce]

On Mon, 2016-10-17 at 09:02 +0200, Petr Spacek wrote:
> On 27.9.2016 14:31, Jan Pazdziora wrote:
> > On Wed, Sep 21, 2016 at 12:01:44PM +0200, Jan Pazdziora wrote:
> >>
> >> I've recently hit again the situation of IPA installer not happy
> >> about the provided IP address not being local to it, this time in
> >> containerized environment:
> >>
> >>https://bugzilla.redhat.com/show_bug.cgi?id=1377973
> >>
> >> During the discussion, we came to an interesting question:
> >>
> >>What would break if loopback addresses were allowed for IPA
> >>server?
> >>
> >> Of course, the idea is that it would only be used for installation and
> >> then IPA would change its IP address in DNS to whatever is the real IP
> >> address under which it is accessible.
> >>
> >> Where does the allow_loopback=False requirement in the installer come
> >> from and what would break if it was removed altogether?
> > 
> > I also see messages like
> > 
> > Adding [10.11.12.13 ipa.example.com] to your /etc/hosts file
> > 
> > in some cases. Actually, it's
> > 
> > 10.11.12.13 ipa.example.com ipa
> > 
> > which gets added so the message is not accurate.
> > 
> > Modification of /etc/hosts itself seems unfortunate. Should the IP
> > address change in the future, there will be one more place where
> > the IP address stays hardcoded.
> > 
> > I wonder why
> > 
> > hosts:  files dns myhostname
> > 
> > isn't enough, and whether
> > 
> > hosts:  files myhostname dns
> > 
> > might actually be better order.
> 
> Theoretically yes. Practically it will break Dogtag and other components which
> are not able to cope up with link-local addresses returned from myhostname 
> module.
> 
> 
> > When the value is not in /etc/hosts,
> > I see weird startup issues, presumably because individual components
> > time out resolving $HOSTNAME, so systemctl start ipa fails. Perhaps
> > it has something to do with named being up at that point, rather than
> > unreachable, just not resolving anything yet. Chicken and egg.
> > 
> > I wonder why we cannot add ipa.example.com to 127.0.0.1. I've tried
> > that and have seen
> > 
> > named-pkcs11[453]: LDAP error: Local error: SASL(-1): generic
> > failure: GSSAPI Error: Unspecified GSS failure.  Minor code
> > may provide more information (Server
> > ldap/localh...@example.test not found in Kerberos database):
> > bind to LDAP server failed
> > 
> > which suggests something derives the hostname and thus the principal
> > from the IP address used. Why is not $HOSTNAME used everywhere? What
> > part of the system cares about the IP address (and the reverse
> > resolution)?
> 
> AFAIK FQDN is used everywhere. The "localhost" name might be coming from
> Kerberos name canonicalization, which works like this:
> FQDN (name resolution) record-> IP address (IP address resolution)->new name.
> 
> You might try to add rdns=false to [libdefaults] section in /etc/krb5.conf. It
> should be default anyway, but why not try it explicitly.
> 
> Also, I would try if dns_canonicalize_hostname=false makes any difference or 
> not.

Btw this attribute came up also elsewhere, I think we should consider
changing ipa-client-install (or SSSD) to make
dns_canonicalize_hostname=false the default in IPa installs.

Should we open a ticket for that?

Simo.

> 
> > If overloading 127.0.0.1 with the $HOSTNAME does not work, could
> > 127.0.0.2 do the trick? It seems to work for subsequent starts (did
> > not try it during ipa-server-install) in containers.
> 
> It will likely suffer with very similar problems. It if works, it works just
> accidentally and might break at any time in future.
> 
> Before we touch IP address/domain name logic, we need to agree how it should
> behave.
> 
> What is the purpose of --ip-address option?
> a) Specify IP addresses used in DNS.
> ab) What checks should be performed on it?
> b) To bind deamons only to specific IP addresses instead of all interfaces?
> 
> I have seen requests for both. We need to decide what is the intended behavior
> and design it before making further changes. The spaghetti code is too
> intertwined for making any non-systematic changes.
> 
> -- 
> Petr^2 Spacek
> 


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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [RFC] Matching and Mapping Certificates

[Simo Sorce]

On Thu, 2016-10-13 at 18:52 +0200, Sumit Bose wrote:
>  Compatibility with Active Directory 
> Active Directory uses a per-user LDAP attribute
> [https://msdn.microsoft.com/en-us/library/cc220106.aspx 
> altSecurityIdentities] to allow arbitrary user-certificate mappings is there 
> is no suitable user-principal-name entry in the SAN of the certificate.
> 
> Unfortunately it is more or less undocumented how AD use the values of
> this attribute. The best overview I found is in
> https://blogs.msdn.microsoft.com/spatdsg/2010/06/18/howto-map-a-user-to-a-certificate-via-all-the-methods-available-in-the-altsecurityidentities-attribute/.

A few more pointers Sumit:
- This describes what is allowed for users:
https://msdn.microsoft.com/en-us/library/ms677943%28v=vs.85%29.aspx

- This describes a use for devices:
https://msdn.microsoft.com/en-us/library/dn408946.aspx

- additional description specific for PKINIT:
https://msdn.microsoft.com/en-us/library/hh536384.aspx

- This is a good detailed overview of the Smart Card logon workflow in
windows, it describes Vista but I do not think it changed in fundamental
ways in following releases:
https://msdn.microsoft.com/en-us/library/bb905527.aspx

NOTE: Please look at the small paragraph named "Smart card logon across
forests", we definitely want to think about this problem as well from
the get-go and not try to retrofit something later on.


HTH,
Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0097] Properly handle LDAP socket closures in ipa-otpd

[Simo Sorce]

On Tue, 2016-09-27 at 14:54 -0400, 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.

LGTM

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

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

[Simo Sorce]

On Fri, 2016-09-09 at 13:14 +0200, Standa Laznicka wrote:
> On 09/03/2016 06:25 PM, Jan Pazdziora wrote:
> > On Thu, Sep 01, 2016 at 11:18:45AM -0400, Simo Sorce wrote:
> >> The thing is we (and admins) will be stuck with old client s for a loong
> >> time, so we need to make it clear to them what works for what. We need
> >> to allow admins to create rules that work for both new and old client
> >> w/o interfering with each other.
> >> In your scheme there must be a way to create a set of rule such that old
> >> clients can login at any time while newer clients use time rules.
> >> that was easy to accomplish by adding an auxiliary class and simply
> >> defining a new type.
> >> Old clients would see old stuff only, new clients would add time rules
> >> if present.
> >> If we have 2 completely different objects because the admin has to
> >> create both, then old clients still care only for the old rule, new
> >> clients instead have an interesting challenge, what rule do they apply ?
> > You use host groups to serve the old rule to old clients and time-based
> > rule to new clients. Each client will apply the rule they see.
> >
> > If you happen to serve the old rule to the new client, access will
> > be allowed no matter what the other, time-based rule says.
> >
> > You do not use magic to interpret one rule differently, one way on
> > one version of client and other way on different client version.
> >
> >> How do you make sure a new client will enforce time restriction when it
> >> looks up the old rule as well ?
> > You make sure the new client does not see the old rule.
> >
> >> Of course admins can always create very barrow host groups and apply
> >> rules only to them, but this is burdensome if you have a *lot* of
> >> clients and some other people are tasked to slowly upgrade them. It is
> >> possible though, so having 2 separate objects that new clients know
> >> about is potentially ok. I would prefer a scheme where they could be
> >> combined though for maximum flexibility with as little as possible
> >> ambiguity.
> > I agree that managing separate host group membership might be
> > and extra work. But it seems to be the only way to remove the ambiguity.
> >
> I also believe there's no way avoiding that (if we want to be somehow 
> backward compatible).
> 
> I would just love us to come to a consensus as I am growing weary of 
> this discussion and am willing to go with just anything as long as it's 
> somehow OK with most people. Could we therefore decide to go with 
> something, please?

As long as the tooling does not try to replace object classes I am ok
with the solution most people agree on.

Simo.


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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

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

[Simo Sorce]

On Thu, 2016-09-01 at 17:48 +0200, Standa Laznicka wrote:
> If an admin wants the capabilities of time rules then they should just
> upgrade the clients. If that is a problem, it's their choice. They can
> either create a special host group for those clients that just won't 
> upgrade or just revoke access to them if it's a problem of a stubborn 
> user who does not want their system upgraded.

This is a very naive view of the problem. first of all what admins want
and what admins can have *and when* are 2 completely different things.

Admins may *prefer* to enforce time rules but it may not be a deal
breaker if some clients do not follow them. They may be ok to have a
period of time i which this is not a hard rule.

Say they are in the process of migrating 3000 clients from RHEL5.11 to
RHEL7.4, they know the roll out will take 6 months, they want a time
rule established so that in 6 months all clients will allow access only
from 8AM CET to 6PM CET, but they are ok to allow access at all times
until a client is migrated.

Of course they may simply wait and change rules after all clients are
migrated, but maybe their goal in setting rules immediately is that they
can test them to see if their users are negatively impacted immediately
so they deal with issues as they come slowly as one client after the
other is migrated instead of having it all at once on "judgment" day. 

This is just an example scenario but I find it totally reasonable.
Are there other ways to go about it ? Yes, definitely, as mentioned host
groups can be used to control which clients see what. I am just saying
this is not a black and white problem, there are various shades of gray.

> Having a single object would also be wrong - there's no way telling
> the older clients to ignore the objects you want them to ignore if you
> want them not to ignore some.

Yes there is, hostgroups again, you see, it works both ways :-)

> But all and all thank you for the explanation with the example, it
> made some of your previous points more clear.

Sure.

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

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

[Simo Sorce]

On Thu, 2016-09-01 at 16:35 +0200, Standa Laznicka wrote:
> On 09/01/2016 03:06 PM, Simo Sorce wrote:
> > On Thu, 2016-09-01 at 14:09 +0200, Standa Laznicka wrote:
> >> The class ipaHBACRuleV2 is dynamically switched to from ipaHBACRule
> >> upon
> >> addition of a time rule to a certain HBAC rule.
> > Honestly I am against this.
> >
> > If you really want the two objects to be incompatible then you tell the
> > admin he can't add time rules to old objects.
> > The new object type should clearly identified as a new rule type and the
> > admin will have to create a new rule of the correct type and
> > remove/disable or retain the old rule as he prefers.
> >
> > I do not think we should ever try to switch objectclasses dynamically.
> >
> > Simo.
> >
> A child's question: why not?
> 
> Also, should it come to life like you propose, what would you expect the 
> user interface to be like?

LDAPv3 does not allow changing structural classes, 389ds allows it but
it is a non-standard feature.
I do not want to create issues to people that create solutions that do
things like synchronizing our LDAP tree to another LDAP server, for
caching, proxying or anything else.
It is one thing to allow to do something illegal in the LDAP protocol,
it is *entirely* different to rely on an illegal feature in day to day
operations.

Furthermore when you change a rule this way old clients will suddenly
see a rule disappear as it will not match their queries anymore. If you
silently do this change in the framework an admin may not realize this
is the case and break access to his legacy clients. If the admin has to
delete and recreate a rule instead it will be much clear to the admin
that this is the case.

So the above is for why I am pretty against switching objectclass.
Please do not do that, it is a NACK from me.


But below find additional things I have been thinking:

The thing is we (and admins) will be stuck with old client s for a loong
time, so we need to make it clear to them what works for what. We need
to allow admins to create rules that work for both new and old client
w/o interfering with each other.
In your scheme there must be a way to create a set of rule such that old
clients can login at any time while newer clients use time rules.
that was easy to accomplish by adding an auxiliary class and simply
defining a new type.
Old clients would see old stuff only, new clients would add time rules
if present.
If we have 2 completely different objects because the admin has to
create both, then old clients still care only for the old rule, new
clients instead have an interesting challenge, what rule do they apply ?

How do you make sure a new client will enforce time restriction when it
looks up the old rule as well ?
After all the old rule grants access at "all times".

Of course admins can always create very barrow host groups and apply
rules only to them, but this is burdensome if you have a *lot* of
clients and some other people are tasked to slowly upgrade them. It is
possible though, so having 2 separate objects that new clients know
about is potentially ok. I would prefer a scheme where they could be
combined though for maximum flexibility with as little as possible
ambiguity.

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

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

[Simo Sorce]

On Thu, 2016-09-01 at 14:09 +0200, Standa Laznicka wrote:
> The class ipaHBACRuleV2 is dynamically switched to from ipaHBACRule
> upon 
> addition of a time rule to a certain HBAC rule.

Honestly I am against this.

If you really want the two objects to be incompatible then you tell the
admin he can't add time rules to old objects.
The new object type should clearly identified as a new rule type and the
admin will have to create a new rule of the correct type and
remove/disable or retain the old rule as he prefers.

I do not think we should ever try to switch objectclasses dynamically.

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

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

[Simo Sorce]

On Tue, 2016-08-30 at 08:47 +0200, 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,
> > bu

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

[Simo Sorce]

On Mon, 2016-08-29 at 16:35 +0200, Petr Spacek wrote:
> On 29.8.2016 16:34, Simo Sorce wrote:
> > On Mon, 2016-08-29 at 09:13 +0200, Petr Spacek wrote:
> >> On 26.8.2016 17:40, Simo Sorce wrote:
> >>> On Fri, 2016-08-26 at 11:37 -0400, Simo Sorce wrote:
> >>>> 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.
> >>>
> >>> I notice that SSSD does not like it if there are multiple values on this
> >>> attribute, but we could change this easily in older clients when we
> >>> update them. worst case the rule will not apply and admins have to
> >>> create 2 rules, one with allow and one with allow_with_time.
> >>
> >> I like the idea in general but it needs proper design and detailed
> >> specification first.
> >>
> >> Given that we have to modify SSSD anyway, I would go for ipaHBACRulev2 
> >> object
> >> class with clear definition of "capabilities" (without any obsolete cruft).
> >>
> >> That should be future proof and without any negative impact to existing 
> >> clients.
> > 
> > ipaHBACRule2 is needed anyway, it is just how it is implemented that
> > differs, I really think we should go the accessRuleType route, I find it
> > superior to messing with objects by ripping off structural objectclasses
> > and replacing them.
> 
> So we are in agreement ;-)

If you liked my proposal then I guess we are, it wasn't clear to me :-)

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

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

[Simo Sorce]

On Mon, 2016-08-29 at 11:15 +0200, Jan Pazdziora wrote:
> On Fri, Aug 26, 2016 at 10:39:53AM -0400, Simo Sorce wrote:
> > On Fri, 2016-08-26 at 12:39 +0200, Martin Basti wrote:
> > > 
> > > 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".
> 
> While that is true, it is worth helping admins to avoid creating
> inadvertent holes in their system. Since the rule needs some
> additional processing on the client, different from the old rules, it
> makes sense to limit exposure to these rules for old clients by
> technical means.
> 
> Note that the URI-based access control of
> 
>   https://fedorahosted.org/freeipa/ticket/5030
>   https://www.freeipa.org/page/V4/URI-based_HBAC
> 
> planned/plans to do exactly the same, to avoid wrong processing of new
> rules by old clients.
> 
> Do you see some issue with the new object class being used?
> 
> > 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 ?
> 
> We should allow admins to apply the rule to any client and then
> ensure that the rule does not authorize access where it should not be
> allowed. Yes, access to some (old) clients will be denied even if the
> admin things it should be allowed. We can likely solve that problem by
> a note on the WebUI, about the client version requirements.
> 
> That was we do not need to play games with guessing client's versions
> and have race situations when the admin knows they have upgraded the
> particular client yet IPA not knowing about it yet.
> 
> > 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.
> 
> I prefer the first option. We shouldn't introduce new feature and make
> its behaviour ambiguous from the very start.
> 
> If the access is denied for old clients when the time-based mechanism
> is used, at least it's a motivation to upgrade the clients.

All good arguments except the last one. We are not here to make admins
lices difficult, we are here to make them better. They are often stuck
with older OS version for reasons beyond their control, so we need to
give them options not aut-auts

Simo.


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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

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

[Simo Sorce]

On Mon, 2016-08-29 at 09:13 +0200, Petr Spacek wrote:
> On 26.8.2016 17:40, Simo Sorce wrote:
> > On Fri, 2016-08-26 at 11:37 -0400, Simo Sorce wrote:
> >> 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.
> > 
> > I notice that SSSD does not like it if there are multiple values on this
> > attribute, but we could change this easily in older clients when we
> > update them. worst case the rule will not apply and admins have to
> > create 2 rules, one with allow and one with allow_with_time.
> 
> I like the idea in general but it needs proper design and detailed
> specification first.
> 
> Given that we have to modify SSSD anyway, I would go for ipaHBACRulev2 object
> class with clear definition of "capabilities" (without any obsolete cruft).
> 
> That should be future proof and without any negative impact to existing 
> clients.

ipaHBACRule2 is needed anyway, it is just how it is implemented that
differs, I really think we should go the accessRuleType route, I find it
superior to messing with objects by ripping off structural objectclasses
and replacing them.

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

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

[Simo Sorce]

On Mon, 2016-08-29 at 08:29 +0200, Jan Cholasta wrote:
> On 26.8.2016 16:39, 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.
> 
> That does not make a lot of sense to me. If the admin does not really 
> care about enforcing the access time, why would they bother setting it 
> in the first place?

It's not that they do not care, but life is not black and white and
sometimes you need to compromise, so you restrict what you can and let
the rest keep working, as client upgrades slide in situation will
improve.


> > 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.
> 
> The second one does not appeal to me, because it is inviting to the kind 
> of mistakes which would allow access when it should not be allowed and 
> IMHO it's better to be safe than sorry.

As a general advice yes, but we need to care about other things, like
usability, and progression.
We did not have time rules at all till now, so allowing smooth upgrades
is important I think.
The nice think about using accessRuleType is that we can set a good
default and then let admins to decide, I like that a lot as it keeps
admins in control and does not force behavior.

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

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

[Simo Sorce]

On Fri, 2016-08-26 at 11:37 -0400, Simo Sorce wrote:
> 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.

I notice that SSSD does not like it if there are multiple values on this
attribute, but we could change this easily in older clients when we
update them. worst case the rule will not apply and admins have to
create 2 rules, one with allow and one with allow_with_time.

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

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

[Simo Sorce]

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.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

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

[Simo Sorce]

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.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

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

[Simo Sorce]

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.

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

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

[Simo Sorce]

On Fri, 2016-08-26 at 11:55 +0200, 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
> 
> 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.

Is there a good reason to "change" the objectclass instead of just
"adding" to it ?
Are v1 and v2 "incompatible" at the object lvl ?
(Sorry I probably knew the answer last I looked at it but I somehow
forgot).

> I'm not sure if want to handle this in code (removing deprecated 
> attributes from HBAC entry when timerule is added)
> 
> I realized that AccessTime is MUST for 'ipahbacrule', so when timerule 
> ('ipahbacrulev2') is removed and somebody deleted accesstime we have to 
> add it back.

What is it set to these days ?

Simo.

> 
> 
> >
> >
> > 4) The CLI sections needs more work, especially for non-standard 
> > commands like timerule-test.
> >
> >>
> >> On the link below is a PROTOTYPE-patched FreeIPA that covers most of the
> >> CLI functionality (except for the creation of iCalendar strings from
> >> options) for better illustration of the design.
> >>
> >> https://github.com/stlaz/freeipa/tree/timerules_2
> >>
> >> I will add FreeIPA people that recently had some say about this to CC so
> >> that we can get the discussion flowing.
> >
> > Honza
> >
> 


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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES] Coverity fixes

[Simo Sorce]

On Tue, 2016-08-16 at 12:34 +0200, Martin Basti wrote:
> 
> On 14.08.2016 10:59, Simo Sorce wrote:
> > 
> > On Thu, 2016-08-11 at 14:51 +0200, Martin Basti wrote:
> > > 
> > > On 05.08.2016 14:13, Lukas Slebodnik wrote:
> > > > 
> > > > On (05/08/16 12:43), Petr Vobornik wrote:
> > > > > 
> > > > > On 07/28/2016 01:01 PM, Martin Basti wrote:
> > > > > > 
> > > > > > On 25.07.2016 11:46, Simo Sorce wrote:
> > > > > > > 
> > > > > > > The attached patches fix some minor issues found by
> > > > > > > coverity, and pull
> > > > > > > in other fixes released by the asn1c project.
> > > > > > > 
> > > > > > > Simo.
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > I cannot build RPMS with this patch, is there any missing
> > > > > > build dependency?
> > > > > > 
> > > > > > /bin/sh ./libtool  --tag=CC   --mode=link gcc  -Wall
> > > > > > -Wshadow
> > > > > > -Wstrict-prototypes -Wpointer-arith -Wcast-align
> > > > > > -Werror-implicit-function-declaration  -O2 -g -pipe -Wall
> > > > > > -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> > > > > > -fexceptions
> > > > > > -fstack-protector-strong --param=ssp-buffer-size=4
> > > > > > -grecord-gcc-switches
> > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64
> > > > > > -mtune=generic -g -O2 -Wall
> > > > > > -Wextra -Wformat-security -Wno-unused-parameter -Wno-sign-
> > > > > > compare
> > > > > > -Wno-missing-field-initializers   -Wl,-z,relro
> > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld  -o ipa-
> > > > > > getkeytab ipa-getkeytab.o
> > > > > > ipa-client-common.o ipa_krb5.o ../asn1/libipaasn1.la -lkrb5
> > > > > > -lk5crypto -lcom_err
> > > > > > -llber -lldap -lsasl2 -lpopt  -lini_config -lbasicobjects
> > > > > > -lref_array
> > > > > > -lcollection  -lini_config -lini_config
> > > > > > libtool: link: gcc -Wall -Wshadow -Wstrict-prototypes
> > > > > > -Wpointer-arith
> > > > > > -Wcast-align -Werror-implicit-function-declaration -O2 -g
> > > > > > -pipe -Wall
> > > > > > -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> > > > > > -fexceptions
> > > > > > -fstack-protector-strong --param=ssp-buffer-size=4
> > > > > > -grecord-gcc-switches
> > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64
> > > > > > -mtune=generic -g -O2 -Wall
> > > > > > -Wextra -Wformat-security -Wno-unused-parameter -Wno-sign-
> > > > > > compare
> > > > > > -Wno-missing-field-initializers -Wl,-z -Wl,relro
> > > > > > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o ipa-
> > > > > > getkeytab ipa-getkeytab.o
> > > > > > ipa-client-common.o ipa_krb5.o ../asn1/.libs/libipaasn1.a
> > > > > > -lkrb5 -lk5crypto
> > > > > > -lcom_err -llber -lldap -lsasl2 -lpopt -lbasicobjects
> > > > > > -lref_array -lcollection
> > > > > > -lini_config
> > > > > > ../asn1/.libs/libipaasn1.a(constr_CHOICE.o): In function
> > > > > > `CHOICE_decode_uper':
> > > > > > /root/freeipa/rpmbuild/BUILD/freeipa-
> > > > > > 4.4.0/asn1/asn1c/constr_CHOICE.c:897:
> > > > > > undefined reference to `uper_open_type_get'
> > > > > > ../asn1/.libs/libipaasn1.a(constr_CHOICE.o): In function
> > > > > > `CHOICE_encode_uper':
> > > > > > /root/freeipa/rpmbuild/BUILD/freeipa-
> > > > > > 4.4.0/asn1/asn1c/constr_CHOICE.c:982:
> > > > > > undefined reference to `uper_open_type_put'
> > > > > > ../asn1/.libs/libipaasn1.a(constr_SEQUENCE.o): In function
> > > > > > `SEQUENCE_handle_extensions':
> > > > > > /root/freeipa/rpmbuild/BUILD/freeipa-
> > > > > > 4.4.0/asn1/asn1c/constr_SEQUENCE.c:1285:
> > > > > > undefined reference to `uper_open_type_put'
> > > > > > ../asn1/.libs/libipaasn1.a(constr_SEQUENCE.o): In function
> > >

Re: [Freeipa-devel] [PATCHES] Coverity fixes

[Simo Sorce]

On Thu, 2016-08-11 at 14:51 +0200, Martin Basti wrote:
> 
> On 05.08.2016 14:13, Lukas Slebodnik wrote:
> > On (05/08/16 12:43), Petr Vobornik wrote:
> >> On 07/28/2016 01:01 PM, Martin Basti wrote:
> >>>
> >>> On 25.07.2016 11:46, Simo Sorce wrote:
> >>>> The attached patches fix some minor issues found by coverity, and pull
> >>>> in other fixes released by the asn1c project.
> >>>>
> >>>> Simo.
> >>>>
> >>>>
> >>>>
> >>> I cannot build RPMS with this patch, is there any missing build 
> >>> dependency?
> >>>
> >>> /bin/sh ./libtool  --tag=CC   --mode=link gcc  -Wall -Wshadow
> >>> -Wstrict-prototypes -Wpointer-arith -Wcast-align
> >>> -Werror-implicit-function-declaration  -O2 -g -pipe -Wall
> >>> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> >>> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
> >>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -g -O2 
> >>> -Wall
> >>> -Wextra -Wformat-security -Wno-unused-parameter -Wno-sign-compare
> >>> -Wno-missing-field-initializers   -Wl,-z,relro
> >>> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld  -o ipa-getkeytab 
> >>> ipa-getkeytab.o
> >>> ipa-client-common.o ipa_krb5.o ../asn1/libipaasn1.la -lkrb5 -lk5crypto 
> >>> -lcom_err
> >>> -llber -lldap -lsasl2 -lpopt  -lini_config -lbasicobjects -lref_array
> >>> -lcollection  -lini_config -lini_config
> >>> libtool: link: gcc -Wall -Wshadow -Wstrict-prototypes -Wpointer-arith
> >>> -Wcast-align -Werror-implicit-function-declaration -O2 -g -pipe -Wall
> >>> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> >>> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
> >>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic -g -O2 
> >>> -Wall
> >>> -Wextra -Wformat-security -Wno-unused-parameter -Wno-sign-compare
> >>> -Wno-missing-field-initializers -Wl,-z -Wl,relro
> >>> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -o ipa-getkeytab 
> >>> ipa-getkeytab.o
> >>> ipa-client-common.o ipa_krb5.o ../asn1/.libs/libipaasn1.a -lkrb5 
> >>> -lk5crypto
> >>> -lcom_err -llber -lldap -lsasl2 -lpopt -lbasicobjects -lref_array 
> >>> -lcollection
> >>> -lini_config
> >>> ../asn1/.libs/libipaasn1.a(constr_CHOICE.o): In function 
> >>> `CHOICE_decode_uper':
> >>> /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_CHOICE.c:897:
> >>> undefined reference to `uper_open_type_get'
> >>> ../asn1/.libs/libipaasn1.a(constr_CHOICE.o): In function 
> >>> `CHOICE_encode_uper':
> >>> /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_CHOICE.c:982:
> >>> undefined reference to `uper_open_type_put'
> >>> ../asn1/.libs/libipaasn1.a(constr_SEQUENCE.o): In function
> >>> `SEQUENCE_handle_extensions':
> >>> /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1285:
> >>> undefined reference to `uper_open_type_put'
> >>> ../asn1/.libs/libipaasn1.a(constr_SEQUENCE.o): In function 
> >>> `SEQUENCE_decode_uper':
> >>> /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1187:
> >>> undefined reference to `uper_open_type_get'
> >>> /root/freeipa/rpmbuild/BUILD/freeipa-4.4.0/asn1/asn1c/constr_SEQUENCE.c:1203:
> >>> undefined reference to `uper_open_type_skip'
> >>> collect2: error: ld returned 1 exit status
> >>>
> >>> Martin^2
> >>>
> >> Bumping. Was it temporary issue or issue in the patch?
> >>
> > I could not see such error.
> > However, these patches would be good to test with coverity.
> > We need to use fedora rawhide for testing due to BuildRequires
> > in freeipa.spec. But C-part of freeIPA cannot be compiled on rawhide
> > due to new samba (4.5). Patches are already on the list.
> >
> > LS
> >
> 
> Lukas helped me to fix error I reported before (missing entries in 
> Makefile.am), so I run covscan and I get bunch of new errors.
> 
> Question is, do we want push autogenerated code?

Yes we definitely want it pushed, so covscan can look at it and we can
commit fixes before the upstream project (which is very slow) takes them
in.

Once these errors crop up in our covscan report I will take another pas

Re: [Freeipa-devel] [PATCH 0197] re-set canonical principal name on migrated users

[Simo Sorce]

On Fri, 2016-07-29 at 15:19 +0200, Martin Basti wrote:
> 
> On 29.07.2016 15:12, Simo Sorce wrote:
> > On Fri, 2016-07-29 at 15:10 +0200, Martin Basti wrote:
> >> On 29.07.2016 14:42, Florence Blanc-Renaud wrote:
> >>> On 07/28/2016 10:56 AM, Martin Babinsky wrote:
> >>>> Fixes https://fedorahosted.org/freeipa/ticket/6101
> >>>>
> >>>> I have also noticed that the principal aliases are not preserved during
> >>>> migration from FreeIPA 4.4.
> >>>>
> >>>> That, however, requires more powerful runes to transform the realm of
> >>>> all values and warrants a separate ticket if we even want to support
> >>>> migration of user aliases.
> >>>>
> >>>>
> >>>>
> >>> Hi Martin,
> >>>
> >>> thanks for your patch. From a technical standpoint, it looks good to
> >>> me as I tested the following scenarios:
> >>>
> >>> 1/ without --user-ignore-attribute
> >>> - call ipa migrate-ds without specifying any attributes to ignore
> >>> The user entries are migrated, and contain a migrated krbprincipalname
> >>> and krbcanonicalname.
> >>> At this point kinit fails but this is expected as the krb attributes
> >>> were not re-generated. Login to the web https://hostname/ipa/ui also
> >>> fails as expected.
> >>> - login to https://hostname/ipa/migration with the user credentials
> >>> - perform kinit => OK
> >>> - login to https://hostname/ipa/ui => OK
> >>>
> >>> 2/ with --user-ignore-attribute={krbPrincipalName,krbextradata,...} as
> >>> explained in the Migration page [1]
> >>> At this point kinit fails as expected, as well as login to the web
> >>> ipa/ui.
> >>> - login to https://hostname/ipa/migration with the user credentials
> >>> - perform kinit => OK
> >>> - login to https://hostname/ipa/ui => OK
> >>>
> >>>
> >>> But the patch produces new pep8 complaints:
> >>> ./ipaserver/plugins/migration.py:39:1: E402 module level import not at
> >>> top of file
> >> This is caused by old code, it should not prevent this patch to be
> >> acked. Imports are heavily mixed in code already, it is not possible to
> >> keep importing right without fixing old ones.
> >> Martin^2
> > Can we make a patch to fix all import order issues across the code base
> > so we can maintain them properly going forward ?
> >
> > Simo.
> >
> 
> Is it worth it?
> 
> a) it will makes git blame harder, you will have to go always deeper to 
> history with any import

I considered this, but I rarely found that imports were such a big
issue, usually it's code in the file that is, so IMO the trade-off is
worth it.

> b) it makes backporting of patches harder. We fixed unused imports in 
> 4.4, and it was PITA to backport patches, always conflicts, several 
> bugs. Changing all import to correct order will be even worse.

Sure backports will be somewhat harder, but I wouldn't say it is a
nightmare, it is not code logic that changes, it is just individual
import lines.

> However plus is, when we once fix it, we can enable pylint check to keep 
> it right forever.

Exactly, this is the appealing point, we get it right once and then the
tool keeps us honest going forward.

> We can open refactoring ticket and we'll see.

Please do.

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0197] re-set canonical principal name on migrated users

[Simo Sorce]

On Fri, 2016-07-29 at 15:10 +0200, Martin Basti wrote:
> 
> On 29.07.2016 14:42, Florence Blanc-Renaud wrote:
> > On 07/28/2016 10:56 AM, Martin Babinsky wrote:
> >> Fixes https://fedorahosted.org/freeipa/ticket/6101
> >>
> >> I have also noticed that the principal aliases are not preserved during
> >> migration from FreeIPA 4.4.
> >>
> >> That, however, requires more powerful runes to transform the realm of
> >> all values and warrants a separate ticket if we even want to support
> >> migration of user aliases.
> >>
> >>
> >>
> > Hi Martin,
> >
> > thanks for your patch. From a technical standpoint, it looks good to 
> > me as I tested the following scenarios:
> >
> > 1/ without --user-ignore-attribute
> > - call ipa migrate-ds without specifying any attributes to ignore
> > The user entries are migrated, and contain a migrated krbprincipalname 
> > and krbcanonicalname.
> > At this point kinit fails but this is expected as the krb attributes 
> > were not re-generated. Login to the web https://hostname/ipa/ui also 
> > fails as expected.
> > - login to https://hostname/ipa/migration with the user credentials
> > - perform kinit => OK
> > - login to https://hostname/ipa/ui => OK
> >
> > 2/ with --user-ignore-attribute={krbPrincipalName,krbextradata,...} as 
> > explained in the Migration page [1]
> > At this point kinit fails as expected, as well as login to the web 
> > ipa/ui.
> > - login to https://hostname/ipa/migration with the user credentials
> > - perform kinit => OK
> > - login to https://hostname/ipa/ui => OK
> >
> >
> > But the patch produces new pep8 complaints:
> > ./ipaserver/plugins/migration.py:39:1: E402 module level import not at 
> > top of file
> 
> This is caused by old code, it should not prevent this patch to be 
> acked. Imports are heavily mixed in code already, it is not possible to 
> keep importing right without fixing old ones.
> Martin^2

Can we make a patch to fix all import order issues across the code base
so we can maintain them properly going forward ?

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH] restrict setkeytab operation

[Simo Sorce]

On Mon, 2016-07-25 at 11:26 -0400, Simo Sorce wrote:
> On Mon, 2016-07-25 at 11:10 -0400, Rob Crittenden wrote:
> > Simo Sorce wrote:
> > > On Mon, 2016-07-25 at 10:55 -0400, Rob Crittenden wrote:
> > >> Simo Sorce wrote:
> > >>> As described in #232 start restricting the use of the setkeytab
> > >>> operation to just the computers objects.
> > >>>
> > >>> I haven't tested this with older RHEL/CentOS machines that actully use
> > >>> the setkeytab operation as I do not have such an old VM handy right now.
> > >>>
> > >>> Meanwhile I'd like to know if ppl agree with this approach.
> > >>
> > >> What about services?
> > >
> > > Do we automatically acquire keytab for services in the old clients ?
> > >
> > > Are you thinking about scripted ipa-getkytab callouts ?
> > 
> > You are limiting access to host keytabs, what about service keytabs? 
> > Should they be or are they now similarly restricted?
> > 
> > Installers for something like Foreman may try to generate a service 
> > keytab in its installer, probably using admin credentials. I am planning 
> > to do the same in Openstack.
> 
> Ok I'll amend the patch to allow service keytabs to still use the
> setkeytab control still, and restrict only users.
> However note that the idea of using this method is that admin can change
> this default on their own, so they can restrict more or less if they
> want, to that end I need to remember how to set a default that we do not
> override in the update file.
> 
> Simo.
> 
Amended patch to allow services too.
Only users are excluded.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
From e91403837f1ca679898030591f3fcc64f9378b98 Mon Sep 17 00:00:00 2001
From: Simo Sorce <s...@redhat.com>
Date: Mon, 25 Jul 2016 06:46:24 -0400
Subject: [PATCH] Restrict the old setkeytab operation

Allow it only to set computers/services keys by default. This is to allow
older clients to join a newer IPA Server and manage their service. But at
the same time prevent users from bypassing password policies by using this
old broken interface.

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

Signed-off-by: Simo Sorce <s...@redhat.com>
---
 daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c | 13 -
 install/updates/20-aci.update   |  4 
 2 files changed, 16 insertions(+), 1 deletion(-)

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 3c2c44f6198bf74615fff1ae231a48bed77526ee..48880cdb74d2d12f016905c151f8fa9ad36c6d8a 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
@@ -1171,6 +1171,8 @@ done:
 return rc;
 }
 
+#define SETKEYS_OP_CHECK "ipaProtectedOperation;set_keys"
+
 /* Password Modify Extended operation plugin function */
 static int ipapwd_setkeytab(Slapi_PBlock *pb, struct ipapwd_krbcfg *krbcfg)
 {
@@ -1238,15 +1240,24 @@ static int ipapwd_setkeytab(Slapi_PBlock *pb, struct ipapwd_krbcfg *krbcfg)
 goto free_and_return;
 }
 
-/* Accesseck strategy:
+/* Access check strategy:
  * If the user has WRITE access, a new keytab can be set on the entry.
  * If not, then we fail immediately with insufficient access. This
  * means that we don't leak any useful information to the client such
  * as current password wrong, etc.
+ *
+ * In addition to the historic check, we now also check if the setkeytab
+ * operation is allowed at all.
  */
 allowed_access = is_allowed_to_access_attr(pb, bindDN, targetEntry,
"krbPrincipalKey", NULL,
SLAPI_ACL_WRITE);
+if (allowed_access) {
+/* check if we are allowed to *set* keys */
+allowed_access = is_allowed_to_access_attr(pb, bindDN, targetEntry,
+   SETKEYS_OP_CHECK, NULL,
+   SLAPI_ACL_WRITE);
+}
 if (!allowed_access) {
 LOG_FATAL("Access not allowed to set keytab on [%s]!\n",
   serviceName);
diff --git a/install/updates/20-aci.update b/install/updates/20-aci.update
index e9c10f54aadf5062c5a03f0d4b36343079462919..b12018004d6dfc51aabd5d6a006ee62660914dd6 100644
--- a/install/updates/20-aci.update
+++ b/install/updates/20-aci.update
@@ -113,6 +113,10 @@ add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Group
 add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Entities are allowed to rekey themselves"; allow(write) us

Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation

[Simo Sorce]

On Mon, 2016-07-25 at 12:13 -0400, Ben Lipton wrote:
> On 07/25/2016 11:07 AM, Simo Sorce wrote:
> > On Mon, 2016-07-25 at 11:04 -0400, Simo Sorce wrote:
> >> On Mon, 2016-07-25 at 10:51 -0400, Ben Lipton wrote:
> >>> On 07/25/2016 05:07 AM, Simo Sorce wrote:
> >>>> On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote:
> >>>>> Anyway, my main grudge is that the transformation rules shouldn't
> >>>>> really
> >>>>> be stored on and processed by the server. The server should know the
> >>>>> *what* (mapping rules), but not the *how* (transformation rules). The
> >>>>> *how* is an implementation detail and does not change in time, so
> >>>>> there's no benefit in handling it on the server. It should be handled
> >>>>> exclusively on the client, which I believe would also make the whole
> >>>>> thing more robust (it would not be possible for a bug on the server
> >>>>> to
> >>>>> break all the clients).
> >>>> W/o entering in specific +1 as a general comment on this.
> >>>> If it can be done on the client, probably better be done there.
> >>>>
> >>>> Simo.
> >>>>
> >>> My thinking was that while the CSR generation must be done on the
> >>> client, the retrieval and formatting of the data for the CSR should be
> >>> done on the server, so that the functionality is available to all
> >>> consumers of the API (ipa command-line, certmonger, Web UI, something
> >>> else?). I imagine it would be relatively easy to move the formatting
> >>> stuff into the ipa CLI, but all the other clients would then need an
> >>> implementation of their own, and so we'd need to worry about
> >>> interpreting the templates and generating CSRs in multiple different
> >>> languages. It's true that as it stands a bug on the server could break
> >>> all the clients, but on the other hand there's only one implementation
> >>> to maintain, rather than a different one in each client.
> >>>
> >>> But maybe I'm not seeing the proper priorities here. Perhaps it's more
> >>> of a problem because clients are easier to update with bugfixes than the
> >>> server? Or maybe the preference for the client is for scalability
> >>> reasons? Could you tell me more about why you prefer a client
> >>> implementation?
> >>>
> >>> (And yeah, everything here carries a disclaimer of "I probably can't
> >>> make any large changes in the remaining 3 weeks of my internship," but I
> >>> think it's still good to know and document what the limitations of the
> >>> current implementation are.)
> >>>
> >>> Thanks,
> >>> Ben
> >> You do not want to have to upgrade the server because tool foobarx
> >> became suddenly the most used. Client tools may change over the time as
> >> well, so if you try to generate stuff on the server you may end up
> >> having to support multiple version with little way of knowing which
> >> version that is.
> >>
> >> It is true that multiple client would have to implement "something", but
> >> that something could be a python library+binary that other tools/script
> >> can call or pipe through as needed.
> > Note, from my pov the code should be more or less the same except it
> > would run on the client rather than the server. Templates would be
> > delivered via the same package that delivers the tool/module and admins
> > would have the option to add more locally, though I am not against
> > sharing templates via the server if we think that is a good idea in
> > general (but the same issue vs tools changing and rendering templates
> > broken with one or another version remain).
> >
> > Simo.
> >
> Ok, I definitely see your point here about making it easier to support 
> the shifting versions of the helper utilities. Pulling the formatting 
> out into a standalone binary that could be used by different clients 
> seems achievable. The Web UI wouldn't be able to use it, I guess, but as 
> of now there's no web UI for this feature anyway. I'll make sure this is 
> at least documented as a desirable modification.

Note, that the same tool *could* be used server side in the UI, should
it be desirable.

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation

[Simo Sorce]

On Mon, 2016-07-25 at 12:09 -0400, Ben Lipton wrote:
> On 07/25/2016 12:03 PM, Simo Sorce wrote:
> > On Mon, 2016-07-25 at 18:05 +0300, Alexander Bokovoy wrote:
> >>> But maybe I'm not seeing the proper priorities here. Perhaps it's
> >> more
> >>> of a problem because clients are easier to update with bugfixes than
> >>> the server? Or maybe the preference for the client is for
> >> scalability
> >>> reasons? Could you tell me more about why you prefer a client
> >>> implementation?
> >> Making client responsible for generating the certificate signing
> >> request serves several purposes where privacy is one of main benefits:
> >> access to private key stays at the client side.
> > I would definitely veto any scheme where the client must send the
> > private key to the server. I thought the server would generate the CSR,
> > but then it would be sent to the client for signing ?
> >
> > Simo.
> >
> The server generates the data and formats it for the helper tool. The 
> helper runs on the client and generates the CSR, with signature. I don't 
> think we were considering signing anything server-side; in this thread I 
> was referring to whether the data should be requested and formatted on 
> the server or client side.

This was my understanding as well, but Alexander's comment startled me,
thanks for confirming.

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation

[Simo Sorce]

On Mon, 2016-07-25 at 18:05 +0300, Alexander Bokovoy wrote:
> >But maybe I'm not seeing the proper priorities here. Perhaps it's
> more 
> >of a problem because clients are easier to update with bugfixes than 
> >the server? Or maybe the preference for the client is for
> scalability 
> >reasons? Could you tell me more about why you prefer a client 
> >implementation?
> Making client responsible for generating the certificate signing
> request serves several purposes where privacy is one of main benefits:
> access to private key stays at the client side.

I would definitely veto any scheme where the client must send the
private key to the server. I thought the server would generate the CSR,
but then it would be sent to the client for signing ?

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH] restrict setkeytab operation

[Simo Sorce]

On Mon, 2016-07-25 at 11:10 -0400, Rob Crittenden wrote:
> Simo Sorce wrote:
> > On Mon, 2016-07-25 at 10:55 -0400, Rob Crittenden wrote:
> >> Simo Sorce wrote:
> >>> As described in #232 start restricting the use of the setkeytab
> >>> operation to just the computers objects.
> >>>
> >>> I haven't tested this with older RHEL/CentOS machines that actully use
> >>> the setkeytab operation as I do not have such an old VM handy right now.
> >>>
> >>> Meanwhile I'd like to know if ppl agree with this approach.
> >>
> >> What about services?
> >
> > Do we automatically acquire keytab for services in the old clients ?
> >
> > Are you thinking about scripted ipa-getkytab callouts ?
> 
> You are limiting access to host keytabs, what about service keytabs? 
> Should they be or are they now similarly restricted?
> 
> Installers for something like Foreman may try to generate a service 
> keytab in its installer, probably using admin credentials. I am planning 
> to do the same in Openstack.

Ok I'll amend the patch to allow service keytabs to still use the
setkeytab control still, and restrict only users.
However note that the idea of using this method is that admin can change
this default on their own, so they can restrict more or less if they
want, to that end I need to remember how to set a default that we do not
override in the update file.

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation

[Simo Sorce]

On Mon, 2016-07-25 at 11:04 -0400, Simo Sorce wrote:
> On Mon, 2016-07-25 at 10:51 -0400, Ben Lipton wrote:
> > On 07/25/2016 05:07 AM, Simo Sorce wrote:
> > > On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote:
> > >> Anyway, my main grudge is that the transformation rules shouldn't
> > >> really
> > >> be stored on and processed by the server. The server should know the
> > >> *what* (mapping rules), but not the *how* (transformation rules). The
> > >> *how* is an implementation detail and does not change in time, so
> > >> there's no benefit in handling it on the server. It should be handled
> > >> exclusively on the client, which I believe would also make the whole
> > >> thing more robust (it would not be possible for a bug on the server
> > >> to
> > >> break all the clients).
> > > W/o entering in specific +1 as a general comment on this.
> > > If it can be done on the client, probably better be done there.
> > >
> > > Simo.
> > >
> > My thinking was that while the CSR generation must be done on the 
> > client, the retrieval and formatting of the data for the CSR should be 
> > done on the server, so that the functionality is available to all 
> > consumers of the API (ipa command-line, certmonger, Web UI, something 
> > else?). I imagine it would be relatively easy to move the formatting 
> > stuff into the ipa CLI, but all the other clients would then need an 
> > implementation of their own, and so we'd need to worry about 
> > interpreting the templates and generating CSRs in multiple different 
> > languages. It's true that as it stands a bug on the server could break 
> > all the clients, but on the other hand there's only one implementation 
> > to maintain, rather than a different one in each client.
> > 
> > But maybe I'm not seeing the proper priorities here. Perhaps it's more 
> > of a problem because clients are easier to update with bugfixes than the 
> > server? Or maybe the preference for the client is for scalability 
> > reasons? Could you tell me more about why you prefer a client 
> > implementation?
> > 
> > (And yeah, everything here carries a disclaimer of "I probably can't 
> > make any large changes in the remaining 3 weeks of my internship," but I 
> > think it's still good to know and document what the limitations of the 
> > current implementation are.)
> > 
> > Thanks,
> > Ben
> 
> You do not want to have to upgrade the server because tool foobarx
> became suddenly the most used. Client tools may change over the time as
> well, so if you try to generate stuff on the server you may end up
> having to support multiple version with little way of knowing which
> version that is.
> 
> It is true that multiple client would have to implement "something", but
> that something could be a python library+binary that other tools/script
> can call or pipe through as needed.

Note, from my pov the code should be more or less the same except it
would run on the client rather than the server. Templates would be
delivered via the same package that delivers the tool/module and admins
would have the option to add more locally, though I am not against
sharing templates via the server if we think that is a good idea in
general (but the same issue vs tools changing and rendering templates
broken with one or another version remain).

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation

[Simo Sorce]

On Mon, 2016-07-25 at 10:51 -0400, Ben Lipton wrote:
> On 07/25/2016 05:07 AM, Simo Sorce wrote:
> > On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote:
> >> Anyway, my main grudge is that the transformation rules shouldn't
> >> really
> >> be stored on and processed by the server. The server should know the
> >> *what* (mapping rules), but not the *how* (transformation rules). The
> >> *how* is an implementation detail and does not change in time, so
> >> there's no benefit in handling it on the server. It should be handled
> >> exclusively on the client, which I believe would also make the whole
> >> thing more robust (it would not be possible for a bug on the server
> >> to
> >> break all the clients).
> > W/o entering in specific +1 as a general comment on this.
> > If it can be done on the client, probably better be done there.
> >
> > Simo.
> >
> My thinking was that while the CSR generation must be done on the 
> client, the retrieval and formatting of the data for the CSR should be 
> done on the server, so that the functionality is available to all 
> consumers of the API (ipa command-line, certmonger, Web UI, something 
> else?). I imagine it would be relatively easy to move the formatting 
> stuff into the ipa CLI, but all the other clients would then need an 
> implementation of their own, and so we'd need to worry about 
> interpreting the templates and generating CSRs in multiple different 
> languages. It's true that as it stands a bug on the server could break 
> all the clients, but on the other hand there's only one implementation 
> to maintain, rather than a different one in each client.
> 
> But maybe I'm not seeing the proper priorities here. Perhaps it's more 
> of a problem because clients are easier to update with bugfixes than the 
> server? Or maybe the preference for the client is for scalability 
> reasons? Could you tell me more about why you prefer a client 
> implementation?
> 
> (And yeah, everything here carries a disclaimer of "I probably can't 
> make any large changes in the remaining 3 weeks of my internship," but I 
> think it's still good to know and document what the limitations of the 
> current implementation are.)
> 
> Thanks,
> Ben

You do not want to have to upgrade the server because tool foobarx
became suddenly the most used. Client tools may change over the time as
well, so if you try to generate stuff on the server you may end up
having to support multiple version with little way of knowing which
version that is.

It is true that multiple client would have to implement "something", but
that something could be a python library+binary that other tools/script
can call or pipe through as needed.

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH] restrict setkeytab operation

[Simo Sorce]

On Mon, 2016-07-25 at 10:55 -0400, Rob Crittenden wrote:
> Simo Sorce wrote:
> > As described in #232 start restricting the use of the setkeytab
> > operation to just the computers objects.
> >
> > I haven't tested this with older RHEL/CentOS machines that actully use
> > the setkeytab operation as I do not have such an old VM handy right now.
> >
> > Meanwhile I'd like to know if ppl agree with this approach.
> 
> What about services?

Do we automatically acquire keytab for services in the old clients ?

Are you thinking about scripted ipa-getkytab callouts ?

Simo.


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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] [PATCH] restrict setkeytab operation

[Simo Sorce]

As described in #232 start restricting the use of the setkeytab
operation to just the computers objects.

I haven't tested this with older RHEL/CentOS machines that actully use
the setkeytab operation as I do not have such an old VM handy right now.

Meanwhile I'd like to know if ppl agree with this approach.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
From 26afe94cea65ba50041592cf31f97b9e0502aeb0 Mon Sep 17 00:00:00 2001
From: Simo Sorce <s...@redhat.com>
Date: Mon, 25 Jul 2016 06:46:24 -0400
Subject: [PATCH] Restrict the old setkeytab operation

Allow it only to set computers keys by default. This is to allow older hosts
to join a newer IPA Server only. All other principals are denied access to
the setkeytab operation by default.

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

Signed-off-by: Simo Sorce <s...@redhat.com>
---
 daemons/ipa-slapi-plugins/ipa-pwd-extop/ipa_pwd_extop.c | 13 -
 install/updates/20-aci.update   |  5 +
 2 files changed, 17 insertions(+), 1 deletion(-)

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 3c2c44f6198bf74615fff1ae231a48bed77526ee..48880cdb74d2d12f016905c151f8fa9ad36c6d8a 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
@@ -1171,6 +1171,8 @@ done:
 return rc;
 }
 
+#define SETKEYS_OP_CHECK "ipaProtectedOperation;set_keys"
+
 /* Password Modify Extended operation plugin function */
 static int ipapwd_setkeytab(Slapi_PBlock *pb, struct ipapwd_krbcfg *krbcfg)
 {
@@ -1238,15 +1240,24 @@ static int ipapwd_setkeytab(Slapi_PBlock *pb, struct ipapwd_krbcfg *krbcfg)
 goto free_and_return;
 }
 
-/* Accesseck strategy:
+/* Access check strategy:
  * If the user has WRITE access, a new keytab can be set on the entry.
  * If not, then we fail immediately with insufficient access. This
  * means that we don't leak any useful information to the client such
  * as current password wrong, etc.
+ *
+ * In addition to the historic check, we now also check if the setkeytab
+ * operation is allowed at all.
  */
 allowed_access = is_allowed_to_access_attr(pb, bindDN, targetEntry,
"krbPrincipalKey", NULL,
SLAPI_ACL_WRITE);
+if (allowed_access) {
+/* check if we are allowed to *set* keys */
+allowed_access = is_allowed_to_access_attr(pb, bindDN, targetEntry,
+   SETKEYS_OP_CHECK, NULL,
+   SLAPI_ACL_WRITE);
+}
 if (!allowed_access) {
 LOG_FATAL("Access not allowed to set keytab on [%s]!\n",
   serviceName);
diff --git a/install/updates/20-aci.update b/install/updates/20-aci.update
index e9c10f54aadf5062c5a03f0d4b36343079462919..0251a7af9b7520f7164b112d19a59d897226f218 100644
--- a/install/updates/20-aci.update
+++ b/install/updates/20-aci.update
@@ -114,6 +114,11 @@ add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Entit
 add:aci: (targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Admins are allowed to rekey any entity"; allow(write) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX;;)
 add:aci: (targetfilter="(|(objectclass=ipaHost)(objectclass=ipaService))")(targetattr="ipaProtectedOperation;write_keys")(version 3.0; acl "Entities are allowed to rekey managed entries"; allow(write) userattr="managedby#USERDN";)
 
+# Set Keytab operation Access Control - legacy interface for host joins
+dn: cn=computers,cn=accounts,$SUFFIX
+add:aci: (targetattr="ipaProtectedOperation;set_keys")(version 3.0; acl "Installers are allowed to set host keytabs"; allow(write) userattr="managedby#USERDN";)
+add:aci: (targetattr="ipaProtectedOperation;set_keys")(version 3.0; acl "Admins are allowed to set host keytabs"; allow(write) groupdn = "ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX;;)
+
 # User certificates
 dn: $SUFFIX
 add:aci:(targetattr = "usercertificate")(version 3.0;acl "selfservice:Users can manage their own X.509 certificates";allow (write) userdn = "ldap:///self;;)
-- 
2.5.5

-- 
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: Improve on #2795 patches

[Simo Sorce]

On Wed, 2016-07-20 at 15:17 +0200, David Kupka wrote:
> On 20/07/16 12:11, Simo Sorce wrote:
> > Attached patch introduces a helper function and avoids the questionable
> > replace+delete operations where possible (still employed in the
> > entry_to_mods function).
> > Compiles and I am about to test it, but I'd like feedback on it if
> > anyone wants to take a look.
> >
> > Simo.
> >
> >
> >
> 
> Looks and works good, ACK.
> 

Pushed to master: ab4fcb0fe25e313c93caae3b90f68b4010a9f2eb

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [Design Review Request] V4/Automatic_Certificate_Request_Generation

[Simo Sorce]

On Mon, 2016-07-25 at 10:50 +0200, Jan Cholasta wrote:
> Anyway, my main grudge is that the transformation rules shouldn't
> really 
> be stored on and processed by the server. The server should know the 
> *what* (mapping rules), but not the *how* (transformation rules). The 
> *how* is an implementation detail and does not change in time, so 
> there's no benefit in handling it on the server. It should be handled 
> exclusively on the client, which I believe would also make the whole 
> thing more robust (it would not be possible for a bug on the server
> to 
> break all the clients).

W/o entering in specific +1 as a general comment on this.
If it can be done on the client, probably better be done there.

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [DESIGN] Text-based rules for CSR autogeneration using Jinja2

[Simo Sorce]

On Wed, 2016-07-20 at 12:14 -0400, Ben Lipton wrote:
> On 07/20/2016 10:37 AM, Simo Sorce wrote:
> > 
> > On Wed, 2016-07-20 at 10:17 -0400, Ben Lipton wrote:
> > > 
> > > On 07/20/2016 06:27 AM, Simo Sorce wrote:
> > > > 
> > > > On Tue, 2016-07-19 at 16:20 -0400, Ben Lipton wrote:
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > I have updated the design page
> > > > > http://www.freeipa.org/page/V4/Automatic_Certificate_Request_
> > > > > Gene
> > > > > rati
> > > > > on/Mapping_Rules
> > > > > with my plan for implementing user-configurable rules for
> > > > > mapping
> > > > > IPA
> > > > > data into certificate requests. In brief: we will use Jinja2
> > > > > for
> > > > > templating. Data rules (which map individual data items) and
> > > > > syntax
> > > > > rules (which group them into certificate fields) will both be
> > > > > snippets
> > > > > of Jinja2 markup. The formatting process will be as follows:
> > > > > 1. Syntax rules will be rendered using Jinja2. Data rules
> > > > > (rule
> > > > > text,
> > > > > not rendered) will be passed as the datarules attribute.
> > > > > 2. Rendered syntax rules will be processed by the Formatter
> > > > > class
> > > > > for
> > > > > the selected CSR generation helper (e.g. openssl or
> > > > > certutil).
> > > > > The
> > > > > formatter combines these partial rules into a full template
> > > > > for
> > > > > the
> > > > > config.
> > > > > 3. The template will be rendered using Jinja2. Relevant data
> > > > > from
> > > > > the
> > > > > IPA database will be available in the context for this
> > > > > rendering.
> > > > > 4. The final rendered template will be returned to the
> > > > > caller,
> > > > > labeled
> > > > > with its function (e.g. a command line or a config file).
> > > > > 
> > > > > Are there any comments or objections to this approach? Here's
> > > > > an
> > > > > example
> > > > > to show what it might look like in practice.
> > > > > 
> > > > > Example data rules:
> > > > > email={{subject.email}}
> > > > > O={{config.ipacertificatesubjectbase}}\nCN={{subject.username
> > > > > }}
> > > > > 
> > > > > Example syntax rule:
> > > > > subjectAltName=@{% section %}{{datarules|join('\n')}}{%
> > > > > endsection %}
> > > > > 
> > > > > Example composed config template:
> > > > > [ req ]
> > > > > prompt = no
> > > > > encrypt_key = no
> > > > > 
> > > > > distinguished_name = {% section
> > > > > %}O={{config.ipacertificatesubjectbase}}
> > > > > CN={{subject.username}}{% endsection %}
> > > > > 
> > > > > req_extensions = exts
> > > > > 
> > > > > [ exts ]
> > > > > subjectAltName=@{% section %}email={{subject.email}}{%
> > > > > endsection
> > > > > %}
> > > > > 
> > > > > There's a lot more information about the thinking behind this
> > > > > at
> > > > > http://blog.benjaminlipton.com/2016/07/19/csr-generation-temp
> > > > > lati
> > > > > ng.h
> > > > > tml
> > > > > if you're interested, as well.
> > > > Nice work Ben,
> > > > it's been really nice to be able to follow your notes on the
> > > > blog
> > > > post,
> > > > one question remains lingering in my head, why jinja2 ?
> > > > I know that engine relatively well as I used it in ipsilon, so
> > > > I am
> > > > not
> > > > questioning the choice just asking why specifically jinja2 and
> > > > not
> > > > something else, potentially language agnostic.
> > > > 
> > > > Simo.
> > > Honestly, my reasoning didn't go very far beyond that it seems to
> > > be
> > > widely used and is compatible with python, which is the language
> > > where
> > > the implementation 

Re: [Freeipa-devel] [DESIGN] Text-based rules for CSR autogeneration using Jinja2

[Simo Sorce]

On Tue, 2016-07-19 at 16:20 -0400, Ben Lipton wrote:
> Hi,
> 
> I have updated the design page 
> http://www.freeipa.org/page/V4/Automatic_Certificate_Request_Generati
> on/Mapping_Rules 
> with my plan for implementing user-configurable rules for mapping
> IPA 
> data into certificate requests. In brief: we will use Jinja2 for 
> templating. Data rules (which map individual data items) and syntax 
> rules (which group them into certificate fields) will both be
> snippets 
> of Jinja2 markup. The formatting process will be as follows:
> 1. Syntax rules will be rendered using Jinja2. Data rules (rule
> text, 
> not rendered) will be passed as the datarules attribute.
> 2. Rendered syntax rules will be processed by the Formatter class
> for 
> the selected CSR generation helper (e.g. openssl or certutil). The 
> formatter combines these partial rules into a full template for the
> config.
> 3. The template will be rendered using Jinja2. Relevant data from
> the 
> IPA database will be available in the context for this rendering.
> 4. The final rendered template will be returned to the caller,
> labeled 
> with its function (e.g. a command line or a config file).
> 
> Are there any comments or objections to this approach? Here's an
> example 
> to show what it might look like in practice.
> 
> Example data rules:
> email={{subject.email}}
> O={{config.ipacertificatesubjectbase}}\nCN={{subject.username}}
> 
> Example syntax rule:
> subjectAltName=@{% section %}{{datarules|join('\n')}}{% endsection %}
> 
> Example composed config template:
> [ req ]
> prompt = no
> encrypt_key = no
> 
> distinguished_name = {% section
> %}O={{config.ipacertificatesubjectbase}}
> CN={{subject.username}}{% endsection %}
> 
> req_extensions = exts
> 
> [ exts ]
> subjectAltName=@{% section %}email={{subject.email}}{% endsection %}
> 
> There's a lot more information about the thinking behind this at 
> http://blog.benjaminlipton.com/2016/07/19/csr-generation-templating.h
> tml 
> if you're interested, as well.

Nice work Ben,
it's been really nice to be able to follow your notes on the blog post,
one question remains lingering in my head, why jinja2 ?
I know that engine relatively well as I used it in ipsilon, so I am not
questioning the choice just asking why specifically jinja2 and not
something else, potentially language agnostic.

Simo.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] PATCH: Improve on #2795 patches

[Simo Sorce]

Attached patch introduces a helper function and avoids the questionable
replace+delete operations where possible (still employed in the
entry_to_mods function).
Compiles and I am about to test it, but I'd like feedback on it if
anyone wants to take a look.

Simo.From fec7ed2d2d7d8352d1a6a9cf5607476c9fd5d65f Mon Sep 17 00:00:00 2001
From: Simo Sorce <s...@redhat.com>
Date: Tue, 19 Jul 2016 07:43:50 -0400
Subject: [PATCH] Simplify date manipulation in pwd plugin

Use a helper function to perform operations on dates in LDAP attributes.

Related to #2795

Signed-off-by: Simo Sorce <s...@redhat.com>
---
 daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c  | 66 +--
 daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h  |  2 +
 daemons/ipa-slapi-plugins/ipa-pwd-extop/prepost.c | 31 ---
 3 files changed, 50 insertions(+), 49 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c b/daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c
index 0bb50fc319e2b2520d36534d369ad42f95c80c8e..cab7b7c7bf0816de736cceaa9a8067920b770a2e 100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/common.c
@@ -702,6 +702,33 @@ next:
 return kvno;
 }
 
+int ipapwd_setdate(Slapi_Entry *source, Slapi_Mods *smods, const char *attr,
+   time_t date, bool remove)
+{
+char timestr[GENERALIZED_TIME_LENGTH+1];
+struct tm utctime;
+Slapi_Attr *t;
+bool exists;
+
+exists = (slapi_entry_attr_find(source, attr, ) == 0);
+
+if (remove) {
+if (exists) {
+ slapi_mods_add_mod_values(smods, LDAP_MOD_DELETE, attr, NULL);
+}
+return LDAP_SUCCESS;
+}
+
+if (!gmtime_r(, )) {
+LOG_FATAL("failed to convert %s date\n", attr);
+return LDAP_OPERATIONS_ERROR;
+}
+strftime(timestr, GENERALIZED_TIME_LENGTH + 1, "%Y%m%d%H%M%SZ", );
+slapi_mods_add_string(smods, exists ?  LDAP_MOD_REPLACE : LDAP_MOD_ADD,
+  attr, timestr);
+return LDAP_SUCCESS;
+}
+
 /* Modify the Password attributes of the entry */
 int ipapwd_SetPassword(struct ipapwd_krbcfg *krbcfg,
struct ipapwd_data *data, int is_krb)
@@ -711,8 +738,6 @@ int ipapwd_SetPassword(struct ipapwd_krbcfg *krbcfg,
 Slapi_Value **svals = NULL;
 Slapi_Value **ntvals = NULL;
 Slapi_Value **pwvals = NULL;
-struct tm utctime;
-char timestr[GENERALIZED_TIME_LENGTH+1];
 char *nt = NULL;
 int is_smb = 0;
 int is_ipant = 0;
@@ -764,34 +789,19 @@ int ipapwd_SetPassword(struct ipapwd_krbcfg *krbcfg,
 		 * keytab so don't set it on hosts.
 		 */
 if (!is_host) {
-	/* change Last Password Change field with the current date */
-			if (!gmtime_r(&(data->timeNow), )) {
-LOG_FATAL("failed to retrieve current date (buggy gmtime_r ?)\n");
-ret = LDAP_OPERATIONS_ERROR;
-goto free_and_return;
-			}
-			strftime(timestr, GENERALIZED_TIME_LENGTH + 1,
- "%Y%m%d%H%M%SZ", );
-			slapi_mods_add_string(smods, LDAP_MOD_REPLACE,
-  "krbLastPwdChange", timestr);
+	/* change Last Password Change field with the current date */
+ret = ipapwd_setdate(data->target, smods, "krbLastPwdChange",
+ data->timeNow, false);
+if (ret != LDAP_SUCCESS)
+goto free_and_return;
 
-			/* set Password Expiration date */
-			if (!gmtime_r(&(data->expireTime), )) {
-LOG_FATAL("failed to convert expiration date\n");
-ret = LDAP_OPERATIONS_ERROR;
-goto free_and_return;
-			}
-			strftime(timestr, GENERALIZED_TIME_LENGTH + 1,
- "%Y%m%d%H%M%SZ", );
-			slapi_mods_add_string(smods, LDAP_MOD_REPLACE,
-  "krbPasswordExpiration", timestr);
-			if (data->expireTime == 0) {
-			slapi_mods_add_string(smods, LDAP_MOD_DELETE,
-			  "krbPasswordExpiration", timestr);
-			}
-
-		}
+	/* set Password Expiration date */
+ret = ipapwd_setdate(data->target, smods, "krbPasswordExpiration",
+ data->expireTime, (data->expireTime == 0));
+if (ret != LDAP_SUCCESS)
+goto free_and_return;
 	}
+}
 
 if (nt && is_smb) {
 slapi_mods_add_string(smods, LDAP_MOD_REPLACE,
diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h
index 83c0222635ece033a37b3540201ae674b5191257..e96aa44d2fb19251c43d8a981dea5f8441007c6a 100644
--- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h
+++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/ipapwd.h
@@ -119,6 +119,8 @@ int ipapwd_gen_checks(Slapi_PBlock *pb, char **errMesg,
 int ipapwd_CheckPolicy(struct ipapwd_data *data);
 int ipapwd_getEntry(const char *d

Re: [Freeipa-devel] [PATCH] 0023 Bug in the ipapwd plugin

[Simo Sorce]

On Tue, 2016-07-19 at 10:17 +0200, thierry bordaz wrote:
> 
> 
> On 07/13/2016 10:02 PM, Lukas Slebodnik wrote:
> > On (13/07/16 16:50), thierry bordaz wrote:
> >> https://fedorahosted.org/freeipa/ticket/6030
> >> >From 4efedc5e674db92f9f7c160429df543422ed8afb Mon Sep 17 00:00:00
> 2001
> >> From: Thierry Bordaz 
> >> Date: Wed, 13 Jul 2016 15:34:20 +0200
> >> Subject: [PATCH] Ticket 6030 Bug in the ipapwd plugin
> >>
> >> ipapwd_encrypt_encode_key allocates 'kset' on the heap but
> >> with num_keys and keys not being initialized.
> >> Then ipa_krb5_generate_key_data initializes them with the
> >> generated keys.
> >> If ipa_krb5_generate_key_data fails (here EINVAL meaning no
> >> principal->realm.data), num_keys and keys are left uninitialized.
> >> Upon failure, ipapwd_keyset_free is called to free 'kset'
> >> that contains random num_keys and keys.
> >>
> >> allocates kset with calloc so that kset->num_keys==0 and
> >> kset->keys==NULL
> >>
> >> https://fedorahosted.org/freeipa/ticket/6030
> >> ---
> >> daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c
> b/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c
> >> index 5ca155d..46bf79a 100644
> >> --- a/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c
> >> +++ b/daemons/ipa-slapi-plugins/ipa-pwd-extop/encoding.c
> >> @@ -148,7 +148,7 @@ Slapi_Value **ipapwd_encrypt_encode_key(struct
> ipapwd_krbcfg *krbcfg,
> >>  pwd.length = strlen(data->password);
> >>  }
> >>
> >> -    kset = malloc(sizeof(struct ipapwd_keyset));
> >> +    kset = calloc(sizeof(struct ipapwd_keyset));
> > I though that calloc need two arguments
> >
> > man malloc says:
> > void *malloc(size_t size);
> > void *calloc(size_t nmemb, size_t size);
> >
> > LS
> Oppss,  sorry for this dummy patch. Here is the right one

ACK,
Simo.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

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

[Simo Sorce]

On Fri, 2016-07-15 at 14:29 +0200, Stanislav Laznicka wrote:
> On 07/15/2016 02:10 PM, Simo Sorce wrote:
> > 
> > On Wed, 2016-05-18 at 15:28 +0200, Stanislav Laznicka wrote:
> > > 
> > > On 05/18/2016 02:19 PM, Alexander Bokovoy wrote:
> > > > 
> > > > On Wed, 18 May 2016, Stanislav Laznicka wrote:
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > when removal succeeds but addition fails for some reason?
> > > > > > > The
> > > > > > > operation is not atomic anymore.
> > > > > > > 
> > > > > We offline-discussed this with Honza. There should be a new
> > > > > command
> > > > > `ipa hbacrule-replace-accesstime rule_name --orig-
> > > > > time=icalstr1
> > > > > --new-time=icalstr2`. As it would be derived from LDAPQuery,
> > > > > the
> > > > > atomicity is kept. This may not be very nice for CLI but
> > > > > should
> > > > > work
> > > > > well for WebUI. Both icalstr1 and icalstr2 need to be encoded
> > > > > as
> > > > > newlines that appear so often in iCalendar strings would only
> > > > > make a
> > > > > mess here.
> > > > > 
> > > > > Example of use:
> > > > > 
> > > > > ipa hbacrule-replace-accesstime rule_name
> > > > > --orig-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The
> > > > > Company//iCal4j
> > > > > 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVEN
> > > > > T\\r
> > > > > \\nUID:1...@company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTA
> > > > > RT:2
> > > > > 0101115T05Z\\r\\nDTEND:20101115T07Z\\r\\nRRULE:FREQ=M
> > > > > ONTH
> > > > > LY;INTERVAL=5;BYDAY=MO;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VC
> > > > > ALEN
> > > > > DAR\\r\\n'"
> > > > > --new-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The
> > > > > Company//iCal4j
> > > > > 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVEN
> > > > > T\\r
> > > > > \\nUID:1...@company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTA
> > > > > RT:2
> > > > > 0101115T05Z\\r\\nDTEND:20101115T07Z\\r\\nRRULE:FREQ=M
> > > > > ONTH
> > > > > LY;INTERVAL=5;BYDAY=MO,TU;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND
> > > > > :VCA
> > > > > LENDAR\\r\\n'"
> > > > > 
> > > > > 
> > > > > to add Tuesdays to the timespan defined by the rule.
> > > > I would really like to see a file input support here. It would
> > > > be
> > > > simpler to operate in CLI as you would anyway create vCal files
> > > > --
> > > > no
> > > > sane person is going to deal with these strings directly on the
> > > > command
> > > > line.
> > > > 
> > > That is correct and some basic file support is already in the
> > > patches
> > > I
> > > sent earlier, though replacing rules is not a part of it.
> > > However,
> > > it
> > > does not solve the problem as you would still need access to the
> > > files
> > > to work with the attributes and then change the files
> > > accordingly.
> > > 
> > > However, we've had yet another brainstorm with Petr^2, Martin^2
> > > and
> > > Honza. We really don't want the above so we came up with some
> > > ideas
> > > that
> > > I'm listing below. Note that we also do not want more than one
> > > VEVENT
> > > component in any of the time rules. So, the ideas:
> > >   1) Have the time rules as separate objects. This approach
> > > got
> > > most
> > > support here. Adding Simo and Jakub to CC should they have any
> > > input
> > > against this.
> > >   2) Have the time rules stored as strings in the multi-
> > > valued
> > > accesstime attribute at each rule. These would be referenced by
> > > their
> > > UID property of the VEVENT component of the iCalendar string
> > > (instead
> > > of
> > > that pure hell above). As each of the strings can only contain
> > > one
> > > VEVENT which has to define a UID, the only problem would be to
> > > keep
> &g

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

[Simo Sorce]

On Wed, 2016-05-18 at 15:28 +0200, Stanislav Laznicka wrote:
> On 05/18/2016 02:19 PM, Alexander Bokovoy wrote:
> > 
> > On Wed, 18 May 2016, Stanislav Laznicka wrote:
> > > 
> > > > 
> > > > > 
> > > > > when removal succeeds but addition fails for some reason?
> > > > > The 
> > > > > operation is not atomic anymore.
> > > > > 
> > > We offline-discussed this with Honza. There should be a new
> > > command 
> > > `ipa hbacrule-replace-accesstime rule_name --orig-time=icalstr1 
> > > --new-time=icalstr2`. As it would be derived from LDAPQuery, the 
> > > atomicity is kept. This may not be very nice for CLI but should
> > > work 
> > > well for WebUI. Both icalstr1 and icalstr2 need to be encoded as 
> > > newlines that appear so often in iCalendar strings would only
> > > make a 
> > > mess here.
> > > 
> > > Example of use:
> > > 
> > > ipa hbacrule-replace-accesstime rule_name 
> > > --orig-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The Company//iCal4j 
> > > 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVENT\\r
> > > \\nUID:1...@company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTART:2
> > > 0101115T05Z\\r\\nDTEND:20101115T07Z\\r\\nRRULE:FREQ=MONTH
> > > LY;INTERVAL=5;BYDAY=MO;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALEN
> > > DAR\\r\\n'" 
> > > --new-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The Company//iCal4j 
> > > 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVENT\\r
> > > \\nUID:1...@company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTART:2
> > > 0101115T05Z\\r\\nDTEND:20101115T07Z\\r\\nRRULE:FREQ=MONTH
> > > LY;INTERVAL=5;BYDAY=MO,TU;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCA
> > > LENDAR\\r\\n'" 
> > > 
> > > 
> > > to add Tuesdays to the timespan defined by the rule.
> > I would really like to see a file input support here. It would be
> > simpler to operate in CLI as you would anyway create vCal files --
> > no
> > sane person is going to deal with these strings directly on the
> > command
> > line.
> > 
> That is correct and some basic file support is already in the patches
> I 
> sent earlier, though replacing rules is not a part of it. However,
> it 
> does not solve the problem as you would still need access to the
> files 
> to work with the attributes and then change the files accordingly.
> 
> However, we've had yet another brainstorm with Petr^2, Martin^2 and 
> Honza. We really don't want the above so we came up with some ideas
> that 
> I'm listing below. Note that we also do not want more than one
> VEVENT 
> component in any of the time rules. So, the ideas:
>  1) Have the time rules as separate objects. This approach got
> most 
> support here. Adding Simo and Jakub to CC should they have any input 
> against this.
>  2) Have the time rules stored as strings in the multi-valued 
> accesstime attribute at each rule. These would be referenced by
> their 
> UID property of the VEVENT component of the iCalendar string (instead
> of 
> that pure hell above). As each of the strings can only contain one 
> VEVENT which has to define a UID, the only problem would be to keep
> the 
> uniqueness of UIDs consistent.
> 
>  From my point of view, 1) seems rather better but your experience
> might 
> be different. Don't hesitate to share your opinions, please.

Can you please give me an example ldif of a complete hbac rule
including time rules with the 2 different proposals ?

I do not really care a lot how the framework ends up managing the
objetcs, I care mostly about how the information is stored in LDAP and
how efficient the storage will be for SSSD retrieval.

That's my evaluation pov.
Keep in mind that rules are modified rarely but downloaded much more
frequently, so it is ok to have a slightly harder way to store them to
gain efficiency in retrieving and downloading them.

Simo.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0179] Preserve user principal aliases during rename operation

[Simo Sorce]

On Wed, 2016-07-13 at 16:35 +0200, Martin Babinsky wrote:
> On 07/13/2016 04:28 PM, Simo Sorce wrote:
> > 
> > On Wed, 2016-07-13 at 16:19 +0200, Martin Babinsky wrote:
> > > 
> > > On 07/13/2016 03:08 PM, Simo Sorce wrote:
> > > > 
> > > > 
> > > > On Wed, 2016-07-13 at 14:37 +0200, Petr Vobornik wrote:
> > > > > 
> > > > > 
> > > > > On 07/12/2016 04:19 PM, Simo Sorce wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Tue, 2016-07-12 at 15:46 +0200, Martin Babinsky wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 07/12/2016 02:00 PM, Martin Babinsky wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On 07/12/2016 01:05 PM, Alexander Bokovoy wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On Mon, 11 Jul 2016, Martin Babinsky wrote:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > From 185bde00a76459430d95ff207bf1fb3fe31e811a Mon
> > > > > > > > > > Sep
> > > > > > > > > > 17
> > > > > > > > > > 00:00:00 2001
> > > > > > > > > > From: Martin Babinsky <mbabi...@redhat.com>
> > > > > > > > > > Date: Fri, 1 Jul 2016 18:09:04 +0200
> > > > > > > > > > Subject: [PATCH] Preserve user principal aliases
> > > > > > > > > > during
> > > > > > > > > > rename
> > > > > > > > > > operation
> > > > > > > > > > 
> > > > > > > > > > When a MODRDN is performed on the user entry, the
> > > > > > > > > > MODRDN
> > > > > > > > > > plugin
> > > > > > > > > > resets
> > > > > > > > > > both
> > > > > > > > > > krbPrincipalName and krbCanonicalName to the value
> > > > > > > > > > constructed
> > > > > > > > > > from
> > > > > > > > > > uid. In
> > > > > > > > > > doing so, hovewer, any principal aliases added to
> > > > > > > > > > the
> > > > > > > > > > krbPrincipalName
> > > > > > > > > > are
> > > > > > > > > > wiped clean. In this patch old aliases are fetched
> > > > > > > > > > before
> > > > > > > > > > the
> > > > > > > > > > MODRDN
> > > > > > > > > > operation
> > > > > > > > > > takes place and inserted back after it is
> > > > > > > > > > performed.
> > > > > > > > > > 
> > > > > > > > > > This also preserves previous user logins which can
> > > > > > > > > > be
> > > > > > > > > > used
> > > > > > > > > > further for
> > > > > > > > > > authentication as aliases.
> > > > > > > > > > 
> > > > > > > > > > https://fedorahosted.org/freeipa/ticket/6028
> > > > > > > > > > ---
> > > > > > > > > > ipaserver/plugins/baseuser.py | 46
> > > > > > > > > > +++
> > > > > > > > > > 1 file changed, 46 insertions(+)
> > > > > > > > > > 
> > > > > > > > > > diff --git a/ipaserver/plugins/baseuser.py
> > > > > > > > > > b/ipaserver/plugins/baseuser.py
> > > > > > > > > > index
> > > > > > > > > > 0052e718afe639bcc1c0a698ded39ea8407a0551..e4288a5a1
> >

Re: [Freeipa-devel] [PATCH 0179] Preserve user principal aliases during rename operation

[Simo Sorce]

On Wed, 2016-07-13 at 16:19 +0200, Martin Babinsky wrote:
> On 07/13/2016 03:08 PM, Simo Sorce wrote:
> > 
> > On Wed, 2016-07-13 at 14:37 +0200, Petr Vobornik wrote:
> > > 
> > > On 07/12/2016 04:19 PM, Simo Sorce wrote:
> > > > 
> > > > 
> > > > On Tue, 2016-07-12 at 15:46 +0200, Martin Babinsky wrote:
> > > > > 
> > > > > 
> > > > > On 07/12/2016 02:00 PM, Martin Babinsky wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On 07/12/2016 01:05 PM, Alexander Bokovoy wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On Mon, 11 Jul 2016, Martin Babinsky wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > From 185bde00a76459430d95ff207bf1fb3fe31e811a Mon Sep
> > > > > > > > 17
> > > > > > > > 00:00:00 2001
> > > > > > > > From: Martin Babinsky <mbabi...@redhat.com>
> > > > > > > > Date: Fri, 1 Jul 2016 18:09:04 +0200
> > > > > > > > Subject: [PATCH] Preserve user principal aliases during
> > > > > > > > rename
> > > > > > > > operation
> > > > > > > > 
> > > > > > > > When a MODRDN is performed on the user entry, the
> > > > > > > > MODRDN
> > > > > > > > plugin
> > > > > > > > resets
> > > > > > > > both
> > > > > > > > krbPrincipalName and krbCanonicalName to the value
> > > > > > > > constructed
> > > > > > > > from
> > > > > > > > uid. In
> > > > > > > > doing so, hovewer, any principal aliases added to the
> > > > > > > > krbPrincipalName
> > > > > > > > are
> > > > > > > > wiped clean. In this patch old aliases are fetched
> > > > > > > > before
> > > > > > > > the
> > > > > > > > MODRDN
> > > > > > > > operation
> > > > > > > > takes place and inserted back after it is performed.
> > > > > > > > 
> > > > > > > > This also preserves previous user logins which can be
> > > > > > > > used
> > > > > > > > further for
> > > > > > > > authentication as aliases.
> > > > > > > > 
> > > > > > > > https://fedorahosted.org/freeipa/ticket/6028
> > > > > > > > ---
> > > > > > > > ipaserver/plugins/baseuser.py | 46
> > > > > > > > +++
> > > > > > > > 1 file changed, 46 insertions(+)
> > > > > > > > 
> > > > > > > > diff --git a/ipaserver/plugins/baseuser.py
> > > > > > > > b/ipaserver/plugins/baseuser.py
> > > > > > > > index
> > > > > > > > 0052e718afe639bcc1c0a698ded39ea8407a0551..e4288a5a13115
> > > > > > > > 7815
> > > > > > > > ffb2
> > > > > > > > 452692a7edb342f6ac3
> > > > > > > > 
> > > > > > > > 100644
> > > > > > > > --- a/ipaserver/plugins/baseuser.py
> > > > > > > > +++ b/ipaserver/plugins/baseuser.py
> > > > > > > > @@ -498,6 +498,50 @@ class baseuser_mod(LDAPUpdate):
> > > > > > > > len =
> > > > > > > > int(config.get('ipamaxusernamelength')[0])
> > > > > > > > )
> > > > > > > > )
> > > > > > > > +
> > > > > > > > +def preserve_krbprincipalname_pre(self, ldap,
> > > > > > > > entry_attrs,
> > > > > > > > *keys,
> > > > > > > > **options):
> > > > > > > > +"""
> > > > > > > > +preserve user principal aliases during rename
> > > > > > > > operation. This
> > > > > > >

Re: [Freeipa-devel] [PATCH 0179] Preserve user principal aliases during rename operation

[Simo Sorce]

On Wed, 2016-07-13 at 14:37 +0200, Petr Vobornik wrote:
> On 07/12/2016 04:19 PM, Simo Sorce wrote:
> > 
> > On Tue, 2016-07-12 at 15:46 +0200, Martin Babinsky wrote:
> > > 
> > > On 07/12/2016 02:00 PM, Martin Babinsky wrote:
> > > > 
> > > > 
> > > > On 07/12/2016 01:05 PM, Alexander Bokovoy wrote:
> > > > > 
> > > > > 
> > > > > On Mon, 11 Jul 2016, Martin Babinsky wrote:
> > > > > > 
> > > > > > 
> > > > > > From 185bde00a76459430d95ff207bf1fb3fe31e811a Mon Sep 17
> > > > > > 00:00:00 2001
> > > > > > From: Martin Babinsky <mbabi...@redhat.com>
> > > > > > Date: Fri, 1 Jul 2016 18:09:04 +0200
> > > > > > Subject: [PATCH] Preserve user principal aliases during
> > > > > > rename
> > > > > > operation
> > > > > > 
> > > > > > When a MODRDN is performed on the user entry, the MODRDN
> > > > > > plugin
> > > > > > resets
> > > > > > both
> > > > > > krbPrincipalName and krbCanonicalName to the value
> > > > > > constructed
> > > > > > from
> > > > > > uid. In
> > > > > > doing so, hovewer, any principal aliases added to the
> > > > > > krbPrincipalName
> > > > > > are
> > > > > > wiped clean. In this patch old aliases are fetched before
> > > > > > the
> > > > > > MODRDN
> > > > > > operation
> > > > > > takes place and inserted back after it is performed.
> > > > > > 
> > > > > > This also preserves previous user logins which can be used
> > > > > > further for
> > > > > > authentication as aliases.
> > > > > > 
> > > > > > https://fedorahosted.org/freeipa/ticket/6028
> > > > > > ---
> > > > > > ipaserver/plugins/baseuser.py | 46
> > > > > > +++
> > > > > > 1 file changed, 46 insertions(+)
> > > > > > 
> > > > > > diff --git a/ipaserver/plugins/baseuser.py
> > > > > > b/ipaserver/plugins/baseuser.py
> > > > > > index
> > > > > > 0052e718afe639bcc1c0a698ded39ea8407a0551..e4288a5a131157815
> > > > > > ffb2
> > > > > > 452692a7edb342f6ac3
> > > > > > 
> > > > > > 100644
> > > > > > --- a/ipaserver/plugins/baseuser.py
> > > > > > +++ b/ipaserver/plugins/baseuser.py
> > > > > > @@ -498,6 +498,50 @@ class baseuser_mod(LDAPUpdate):
> > > > > > len =
> > > > > > int(config.get('ipamaxusernamelength')[0])
> > > > > > )
> > > > > > )
> > > > > > +
> > > > > > +def preserve_krbprincipalname_pre(self, ldap,
> > > > > > entry_attrs,
> > > > > > *keys,
> > > > > > **options):
> > > > > > +"""
> > > > > > +preserve user principal aliases during rename
> > > > > > operation. This
> > > > > > is the
> > > > > > +pre-callback part of this. Another method called
> > > > > > during
> > > > > > post-callback
> > > > > > +shall insert the principals back
> > > > > > +"""
> > > > > > +if options.get('rename', None) is None:
> > > > > > +return
> > > > > > +
> > > > > > +try:
> > > > > > +old_entry = ldap.get_entry(
> > > > > > +entry_attrs.dn, attrs_list=(
> > > > > > +'krbprincipalname',
> > > > > > 'krbcanonicalname'))
> > > > > > +
> > > > > > +if 'krbcanonicalname' not in old_entry:
> > > > > > +return
> > > > > > +except errors.NotFound:
> > > > > > +self.obj.handle_not_found(*keys)
> > > > > > +
> > > > > > +self.context.krbprincipalname = old_entry.get(
> &

Re: [Freeipa-devel] [PATCH 0179] Preserve user principal aliases during rename operation

[Simo Sorce]

On Wed, 2016-07-13 at 13:53 +0200, Martin Babinsky wrote:
> On 07/12/2016 04:19 PM, Simo Sorce wrote:
> > 
> > On Tue, 2016-07-12 at 15:46 +0200, Martin Babinsky wrote:
> > > 
> > > On 07/12/2016 02:00 PM, Martin Babinsky wrote:
> > > > 
> > > > 
> > > > On 07/12/2016 01:05 PM, Alexander Bokovoy wrote:
> > > > > 
> > > > > 
> > > > > On Mon, 11 Jul 2016, Martin Babinsky wrote:
> > > > > > 
> > > > > > 
> > > > > > From 185bde00a76459430d95ff207bf1fb3fe31e811a Mon Sep 17
> > > > > > 00:00:00 2001
> > > > > > From: Martin Babinsky <mbabi...@redhat.com>
> > > > > > Date: Fri, 1 Jul 2016 18:09:04 +0200
> > > > > > Subject: [PATCH] Preserve user principal aliases during
> > > > > > rename
> > > > > > operation
> > > > > > 
> > > > > > When a MODRDN is performed on the user entry, the MODRDN
> > > > > > plugin
> > > > > > resets
> > > > > > both
> > > > > > krbPrincipalName and krbCanonicalName to the value
> > > > > > constructed
> > > > > > from
> > > > > > uid. In
> > > > > > doing so, hovewer, any principal aliases added to the
> > > > > > krbPrincipalName
> > > > > > are
> > > > > > wiped clean. In this patch old aliases are fetched before
> > > > > > the
> > > > > > MODRDN
> > > > > > operation
> > > > > > takes place and inserted back after it is performed.
> > > > > > 
> > > > > > This also preserves previous user logins which can be used
> > > > > > further for
> > > > > > authentication as aliases.
> > > > > > 
> > > > > > https://fedorahosted.org/freeipa/ticket/6028
> > > > > > ---
> > > > > > ipaserver/plugins/baseuser.py | 46
> > > > > > +++
> > > > > > 1 file changed, 46 insertions(+)
> > > > > > 
> > > > > > diff --git a/ipaserver/plugins/baseuser.py
> > > > > > b/ipaserver/plugins/baseuser.py
> > > > > > index
> > > > > > 0052e718afe639bcc1c0a698ded39ea8407a0551..e4288a5a131157815
> > > > > > ffb2
> > > > > > 452692a7edb342f6ac3
> > > > > > 
> > > > > > 100644
> > > > > > --- a/ipaserver/plugins/baseuser.py
> > > > > > +++ b/ipaserver/plugins/baseuser.py
> > > > > > @@ -498,6 +498,50 @@ class baseuser_mod(LDAPUpdate):
> > > > > > len =
> > > > > > int(config.get('ipamaxusernamelength')[0])
> > > > > > )
> > > > > > )
> > > > > > +
> > > > > > +def preserve_krbprincipalname_pre(self, ldap,
> > > > > > entry_attrs,
> > > > > > *keys,
> > > > > > **options):
> > > > > > +"""
> > > > > > +preserve user principal aliases during rename
> > > > > > operation. This
> > > > > > is the
> > > > > > +pre-callback part of this. Another method called
> > > > > > during
> > > > > > post-callback
> > > > > > +shall insert the principals back
> > > > > > +"""
> > > > > > +if options.get('rename', None) is None:
> > > > > > +return
> > > > > > +
> > > > > > +try:
> > > > > > +old_entry = ldap.get_entry(
> > > > > > +entry_attrs.dn, attrs_list=(
> > > > > > +'krbprincipalname',
> > > > > > 'krbcanonicalname'))
> > > > > > +
> > > > > > +if 'krbcanonicalname' not in old_entry:
> > > > > > +return
> > > > > > +except errors.NotFound:
> > > > > > +self.obj.handle_not_found(*keys)
> > > > > > +
> > > > > > +self.context.krbprincipalname = old_entry.get(
&g

Re: [Freeipa-devel] [PATCH 0179] Preserve user principal aliases during rename operation

[Simo Sorce]

On Tue, 2016-07-12 at 15:46 +0200, Martin Babinsky wrote:
> On 07/12/2016 02:00 PM, Martin Babinsky wrote:
> > 
> > On 07/12/2016 01:05 PM, Alexander Bokovoy wrote:
> > > 
> > > On Mon, 11 Jul 2016, Martin Babinsky wrote:
> > > > 
> > > > From 185bde00a76459430d95ff207bf1fb3fe31e811a Mon Sep 17
> > > > 00:00:00 2001
> > > > From: Martin Babinsky 
> > > > Date: Fri, 1 Jul 2016 18:09:04 +0200
> > > > Subject: [PATCH] Preserve user principal aliases during rename
> > > > operation
> > > > 
> > > > When a MODRDN is performed on the user entry, the MODRDN plugin
> > > > resets
> > > > both
> > > > krbPrincipalName and krbCanonicalName to the value constructed
> > > > from
> > > > uid. In
> > > > doing so, hovewer, any principal aliases added to the
> > > > krbPrincipalName
> > > > are
> > > > wiped clean. In this patch old aliases are fetched before the
> > > > MODRDN
> > > > operation
> > > > takes place and inserted back after it is performed.
> > > > 
> > > > This also preserves previous user logins which can be used
> > > > further for
> > > > authentication as aliases.
> > > > 
> > > > https://fedorahosted.org/freeipa/ticket/6028
> > > > ---
> > > > ipaserver/plugins/baseuser.py | 46
> > > > +++
> > > > 1 file changed, 46 insertions(+)
> > > > 
> > > > diff --git a/ipaserver/plugins/baseuser.py
> > > > b/ipaserver/plugins/baseuser.py
> > > > index
> > > > 0052e718afe639bcc1c0a698ded39ea8407a0551..e4288a5a131157815ffb2
> > > > 452692a7edb342f6ac3
> > > > 
> > > > 100644
> > > > --- a/ipaserver/plugins/baseuser.py
> > > > +++ b/ipaserver/plugins/baseuser.py
> > > > @@ -498,6 +498,50 @@ class baseuser_mod(LDAPUpdate):
> > > > len =
> > > > int(config.get('ipamaxusernamelength')[0])
> > > > )
> > > > )
> > > > +
> > > > +def preserve_krbprincipalname_pre(self, ldap, entry_attrs,
> > > > *keys,
> > > > **options):
> > > > +"""
> > > > +preserve user principal aliases during rename
> > > > operation. This
> > > > is the
> > > > +pre-callback part of this. Another method called
> > > > during
> > > > post-callback
> > > > +shall insert the principals back
> > > > +"""
> > > > +if options.get('rename', None) is None:
> > > > +return
> > > > +
> > > > +try:
> > > > +old_entry = ldap.get_entry(
> > > > +entry_attrs.dn, attrs_list=(
> > > > +'krbprincipalname', 'krbcanonicalname'))
> > > > +
> > > > +if 'krbcanonicalname' not in old_entry:
> > > > +return
> > > > +except errors.NotFound:
> > > > +self.obj.handle_not_found(*keys)
> > > > +
> > > > +self.context.krbprincipalname = old_entry.get(
> > > > +'krbprincipalname', [])
> > > > +
> > > > +def preserve_krbprincipalname_post(self, ldap,
> > > > entry_attrs,
> > > > **options):
> > > > +"""
> > > > +Insert the preserved aliases back to the user entry
> > > > during
> > > > rename
> > > > +operation
> > > > +"""
> > > > +if options.get('rename', None) is None or not hasattr(
> > > > +self.context, 'krbprincipalname'):
> > > > +return
> > > > +
> > > > +obj_pkey =
> > > > self.obj.get_primary_key_from_dn(entry_attrs.dn)
> > > > +canonical_name = entry_attrs['krbcanonicalname'][0]
> > > > +
> > > > +principals_to_add = tuple(p for p in
> > > > self.context.krbprincipalname if
> > > > +  p != canonical_name)
> > > > +
> > > > +if principals_to_add:
> > > > +result = self.api.Command.user_add_principal(
> > > > +obj_pkey, principals_to_add)['result']
> > > > +
> > > > +entry_attrs['krbprincipalname'] =
> > > > result.get('krbprincipalname', [])
> > > > +
> > > > def check_mail(self, entry_attrs):
> > > > if 'mail' in entry_attrs:
> > > > entry_attrs['mail'] =
> > > > self.obj.normalize_and_validate_email(entry_attrs['mail'])
> > > > @@ -557,9 +601,11 @@ class baseuser_mod(LDAPUpdate):
> > > > 
> > > > self.check_objectclass(ldap, dn, entry_attrs)
> > > > self.obj.convert_usercertificate_pre(entry_attrs)
> > > > +self.preserve_krbprincipalname_pre(ldap, entry_attrs,
> > > > *keys,
> > > > **options)
> > > > 
> > > > def post_common_callback(self, ldap, dn, entry_attrs,
> > > > *keys,
> > > > **options):
> > > > assert isinstance(dn, DN)
> > > > +self.preserve_krbprincipalname_post(ldap, entry_attrs,
> > > > **options)
> > > > if options.get('random', False):
> > > > try:
> > > > entry_attrs['randompassword'] =
> > > > unicode(getattr(context, 'randompassword'))
> > > > --
> > > > 2.5.5
> > > > 
> > > The approach looks good.
> > > 
> > > For the record, we also support aliases 

Re: [Freeipa-devel] [PATCHES 0069-0077] support for proper Kerberos principal canonicalization

[Simo Sorce]

On Wed, 2016-06-22 at 18:36 +0200, Martin Babinsky wrote:
> On 06/22/2016 06:26 PM, Simo Sorce wrote:
> > On Wed, 2016-06-22 at 09:46 +0200, Martin Babinsky wrote:
> >> On 10/05/2015 03:00 PM, Martin Babinsky wrote:
> >>> These patches implement the plumbing required to properly support
> >>> canonicalization of Kerberos principals (
> >>> https://fedorahosted.org/freeipa/ticket/3864).
> >>>
> >>> Setting multiple principal aliases on hosts/services is beyond the scope
> >>> of this patchset and should be done after these patches are pushed.
> >>>
> >>> I will try to send some tests for the patches later this week.
> >>>
> >>> Please review the hell out of them.
> >>>
> >>>
> >>>
> >>
> >> Long time no see.
> >>
> >> I am attaching rebased infrastructure patches which were reviewed and
> >> tested by David a year ago :). Now that all related DS bugs were fixed
> >> and the patches still work as expected, we may push them so that the
> >> plumbing for further work (API for alias handling etc.) is in place.
> >>
> >
> > If the patches were all reviewed and tested I say push them.
> >
> > Simo.
> >
> 
> There is one problem remaining, however, that when a user is kinit'ing 
> for the first name using his alias and has to change password, the 
> operation fails:
> 
> """
> [root@master1 ~]# kinit -C talias
> Password for tal...@ipa.test:
> kinit: KDC reply did not match expectations while getting initial 
> credentials
> 
> """
> 
> This is the related snippet from KDC log:
> 
> """
> Jun 22 16:29:24 master1.ipa.test krb5kdc[31003](info): AS_REQ (6 etypes 
> {18 17 16 23 25 26}) 192.168.122.100: CLIENT KEY EXPIRED: 
> tal...@ipa.test for krbtgt/ipa.t...@ipa.test, Password has expired
> Jun 22 16:29:24 master1.ipa.test krb5kdc[31003](info): closing down fd 12
> Jun 22 16:29:24 master1.ipa.test krb5kdc[31003](info): AS_REQ (6 etypes 
> {18 17 16 23 25 26}) 192.168.122.100: NEEDED_PREAUTH: tal...@ipa.test 
> for kadmin/chang...@ipa.test, Additional pre-authentication required
> Jun 22 16:29:24 master1.ipa.test krb5kdc[31003](info): closing down fd 12
> Jun 22 16:29:28 master1.ipa.test krb5kdc[31003](info): AS_REQ (6 etypes 
> {18 17 16 23 25 26}) 192.168.122.100: ISSUE: authtime 1466612968, etypes 
> {rep=18 tkt=18 ses=18}, tal...@ipa.test for kadmin/chang...@ipa.test
> Jun 22 16:29:28 master1.ipa.test krb5kdc[31003](info): closing down fd 12
> 
> """
> 
> Here is the same command repeated with captured libkrb5 trace: 
> https://paste.fedoraproject.org/383358/14666131
> 
> If I use kinit with the canonical principal everything works as 
> expected, even with '-C' and '-'E' options. Subsequent kinits using 
> canonicalization work as expected.
> 
> Frankly I have no idea why this happens and I do not know how much this 
> error blocks us. We may need to investigate this before pizza orders arrive.

I guess the password changing code is making a request without
canonicalization flags set for the kpasswd service.
As you can see the kpasswd case is special because we are making an AS
REQ (not a TGS req) directly for that service, and that request needs to
use canonicalization as well, it probably isn't.

Simo.


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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 0069-0077] support for proper Kerberos principal canonicalization

[Simo Sorce]

On Wed, 2016-06-22 at 09:46 +0200, Martin Babinsky wrote:
> On 10/05/2015 03:00 PM, Martin Babinsky wrote:
> > These patches implement the plumbing required to properly support
> > canonicalization of Kerberos principals (
> > https://fedorahosted.org/freeipa/ticket/3864).
> >
> > Setting multiple principal aliases on hosts/services is beyond the scope
> > of this patchset and should be done after these patches are pushed.
> >
> > I will try to send some tests for the patches later this week.
> >
> > Please review the hell out of them.
> >
> >
> >
> 
> Long time no see.
> 
> I am attaching rebased infrastructure patches which were reviewed and 
> tested by David a year ago :). Now that all related DS bugs were fixed 
> and the patches still work as expected, we may push them so that the 
> plumbing for further work (API for alias handling etc.) is in place.
> 

If the patches were all reviewed and tested I say push them.

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [DESIGN] IPA client in AD DNS domain

[Simo Sorce]

On Tue, 2016-05-24 at 16:32 +0300, Alexander Bokovoy wrote:
> On Tue, 24 May 2016, Simo Sorce wrote:
> >On Tue, 2016-05-24 at 10:44 +0300, Alexander Bokovoy wrote:
> >> >Alternative technical approach is to add aliases to an host's
> >> attribute and
> >> >use it from there. I suspect that this would be less flexible and
> >> less
> >> >future-proof.
> >
> >> I don't see a need for alias-as-a-property. Instead, I'm interested in
> >> having a possibility to have different keys, certificates, etc, on
> >> objects used as aliases. This improves security position by splitting
> >> the manager and the user of the resource.
> >
> >Can you elaborate on this ?
> >Are you misusing the "alias" word here to just mean "host that have
> >multiple identities" like clusters/load ballancers/proxies etc... ?
> Precisely. 

then let's find a term that will not make comms, confusing, what about
"Shared ID" ?

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCHES 0089-0093] Authentication Indicators

[Simo Sorce]

On Tue, 2016-05-24 at 15:25 +0200, Sumit Bose wrote:
> >  #define OTP_SYNC_REQUEST_OID "2.16.840.1.113730.3.8.10.6"
> >  
> > +/* This control has no data. */
> > +#define OTP_REQUIRED_OID "1.2.3.4.5.6.7.8.9"
> > +
> 
> Simo, can you assign a proper OID for OTP_REQUIRED_OID ?


@@ -446,6 +446,9 @@ IPA Extensions and Controls OIDs
 
 2.16.840.1.113730.3.8.10.6 Token Resynchronization Control OID
 
+2.16.840.1.113730.3.8.10.7 Token Required Control OID
+Control to signal an OTP bind is required
+
 


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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [DESIGN] IPA client in AD DNS domain

[Simo Sorce]

On Tue, 2016-05-24 at 09:55 +0200, Petr Spacek wrote:
> >> Alternative technical approach is to add aliases to an host's
> attribute and
> >> use it from there. I suspect that this would be less flexible and
> less
> >> future-proof.
> > I don't see a need for alias-as-a-property. Instead, I'm interested
> in
> > having a possibility to have different keys, certificates, etc, on
> > objects used as aliases. This improves security position by
> splitting
> > the manager and the user of the resource.
> 
> I think that these two are not mutually exclusive.
> 
> a) If you need separate keys (and the headache associated with it) use
> a new host object.

This is what we do today, and we need to keep it that way, we do not
really have a choice, it's how it works, 1 identity 1 key, attaching
multiple identities to a single object is just going to cause a lot of
issues, and I do not see any benefit.

> b) If you need to share keys use alias.

No, you need to use a separate identity, that just happens to be common
to multiple hosts. Please let's not conflate the "alias" concept with
"additional identity". 

> Aliases could have other advantages, e.g. using diffrent DNS checks to
> the user does not need to use --force just to create the alias.

How ?

> Right now we do not have the (b) option so code needs to use hacks
> like the one you proposed above:
> "we can add this one specifically as an option to existing code to
> just follow managedBy"

This is news to me. I suspect there is a language issue here ?

> This is simply a hack and relies on user not forgetting to add option
> --follow-managed-by (e.g.) when requesting a certificate. Not speaking
> about automated processes requesting certs which would need own
> heuristics to detect when the option should be supplied.

What problem, exactly, are we trying to solve here ?

For certs, if you have multiple identities you should really use SNI,
not try to put all names of the world in one cert, but if you really
want to cobble together a fake identity that uses multiple different
names with the same key, you should do that manually, there is no
automation that can read the admin mind.

Note that "manually" may simply mean that the admin prepares appropriate
reference attributes on the main object, but it still is a manual
setting of "referrals" somewhere.

> I really do not like these ad-hoc hacks and I'm looking for a
> systematic solution.

Is this just for certs ? Or something else ?

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [DESIGN] IPA client in AD DNS domain

[Simo Sorce]

On Tue, 2016-05-24 at 10:44 +0300, Alexander Bokovoy wrote:
> >Alternative technical approach is to add aliases to an host's
> attribute and
> >use it from there. I suspect that this would be less flexible and
> less
> >future-proof.

> I don't see a need for alias-as-a-property. Instead, I'm interested in
> having a possibility to have different keys, certificates, etc, on
> objects used as aliases. This improves security position by splitting
> the manager and the user of the resource.

Can you elaborate on this ?
Are you misusing the "alias" word here to just mean "host that have
multiple identities" like clusters/load ballancers/proxies etc... ?

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH] pwpolicy: Do not expire passwords when maxlife is set to 0 (infinity).

[Simo Sorce]

On Wed, 2016-05-04 at 15:39 +0200, Martin Kosek wrote:
> On 05/02/2016 02:28 PM, David Kupka wrote:
> > https://fedorahosted.org/freeipa/ticket/2795
> 
> That patch looks suspiciously short given the struggles I saw in
> http://www.redhat.com/archives/freeipa-devel/2015-June/msg00198.html
> :-)
> 
> Instead of setting to IPAPWD_END_OF_TIME, should we instead avoid filling
> "krbPasswordExpiration" attribute at all, i.e. have password *without*
> expiration? Or is krbPasswordExpiration mandatory?

So I looked at the MIT code, and it seem like they are coping just fine
with a missing (ie value = 0 internally) pw_expiration attribute.

So if we make our code cope with omitting any expiration if the
attribute is missing then yes, we can mark no expiration with simply
removing (or not setting) the krbPasswordExpiration attribute.
The attribute itself is optional and can be omitted.

I think this is a good idea, and is definitely better than inventing a a
magic value.

Simo.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] External trust to AD

[Simo Sorce]

On Wed, 2016-03-02 at 21:11 +0200, Alexander Bokovoy wrote:
> On Wed, 02 Mar 2016, Petr Vobornik wrote:
> >On 03/02/2016 11:13 AM, Alexander Bokovoy wrote:
> >>Hi,
> >>
> >>http://www.freeipa.org/page/V4/External_trust_to_AD documents a design
> >>for external trust to AD feature.
> >>
> >>The text is included below for easier review.
> >>---
> >>{{Feature|version=TODO|ticket=TODO|author=Ab}}
> >>
> >>== Overview ==
> >>Support for external trust to a domain from Active Directory forest
> >>
> >>An external trust is a trust relationship between Active Directory
> >>domains that are in different Active Directory forests. While forest
> >>trust always requires to establish trust between root domains of the
> >>Active Directory forests, external trust can be established to any
> >>domain within the forest.
> >>
> >>== Use Cases ==
> >>
> >>As an Active Directory domain admin, I want to establish trust between
> >>IPA and my domain only. The trust between IPA and an external Active
> >>Directory domain will be non-transitive as no users or groups from other
> >>Active Directory domains will have access to IPA resources.
> >>
> >>== Design==
> >>
> >>External trust between Active Directory domains is by definition
> >>non-transitive and enforces SID filtering between the domain boundaries.
> >>This means only users and groups with SIDs from the trusted domain can
> >>use the resources and be visible on IPA systems. None of other users and
> >>groups from domains the trusted domain trusts within its own Active
> >>Directory forest or other externally trusted domains will be allowed to
> >>access IPA resources.
> >>
> >>== Implementation ==
> >>
> >>External trust feature re-uses existing forest trust infrastructure.
> >>There are several specific changes to allow supporting external trust:
> >>* '''Non-transitivity''': since external trust is non-transitive by
> >>* definition, any attempt to set transitivity feature of the trust link
> >>* with LSA SetInformationTrustedDomain() command will fail. Thus, there
> >>* is no need to set transitivity for the external trust.
> >
> >Sounds very simple :)
> >
> >Do I get it right that it is possible to do it today? Because now the 
> >code just do:
> >   root_logger.error('unable to set trust to transitive: %s' % (str(e)))
> >   pass
> I have a patchset to add this support already. I want to clean up some
> parts of it, namely, reporting of the resulting trust type, but it all works.
> 
> >
> >>* '''Trust attributes''': external trust can be detected by looking into
> >>* absense of ipaNTTrustAttributes LDAP attribute of the trusted domain
> >>* object.
> >>
> >>== Feature Management ==
> >>
> >>=== UI ===
> >>An option 'external trust' needs to be added to Web UI, corresponding to
> >>'--external' flag in 'trust-add' command in CLI.
> >>
> >>=== CLI ===
> >>An external trust creation can be requested by passing additional flag
> >>'--external=true' to the 'trust-add' command. The flag defaults to
> >>'false', e.g. no external trust would be created.
> >>
> >>{| class="wikitable"
> >>|-
> >>! Command
> >>! Options
> >>|-
> >>| trust-add
> >>| --external=true/false
> >>|}
> >
> >We should also add 'external' param to output of trust_find and 
> >trust_show + corresponding change in Web UI and CLI.
> It will be part of trust type string, not a separate param.


I reviewed the design and associated tickts, and all checks out for me.
I have only one nitpick that is not spelled out.

What happens if someone has a forest trust and tries to also set up an
external trust with a child domain of the existing forest trust ?

Do we need to add code to prevent it, or should we allow it ?

Secondary nitpick that came to mind right now, will one-way external
trust also be allowed/supported in the first implementation ?

I have some ideas on the answers to the above questions, but I think
they should be put in the design as considerations and explained there. 

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Locations design v2: LDAP schema & user interface

[Simo Sorce]

On Thu, 2016-04-21 at 17:39 +0200, Petr Spacek wrote:
> On 19.4.2016 19:17, Simo Sorce wrote:
> > On Tue, 2016-04-19 at 11:11 +0200, Petr Spacek wrote:
> >> On 18.4.2016 21:33, Simo Sorce wrote:
> >>> On Mon, 2016-04-18 at 17:44 +0200, Petr Spacek wrote:
> >>>> * Find, filter and copy hand-made records from main tree into the
> >>>> _locations sub-trees. This means that every hand-made record
> >>>> needs to be copied and synchronized N-times where N = number of IPA
> >>>> locations.
> >>>
> >>> This ^^ seem the one that provides the best semantics for admins and the
> >>> least unexpected results.
> >>>
> >>>> My favorite option for the first version is 'document that enabling
> >>>> DNS location will hide hand-made records in IPA domain.'
> >>>
> >>> I do not think this is acceptable, sorry.
> >>>
> >>>> The feature is disabled by default and needs additional configuration
> >>>> anyway so simply upgrading should not break anything.
> >>>
> >>> It is also useless this way.
> >>>
> >>>> I'm eager to hear opinions and answers to questions above.
> >>>
> >>> HTH,
> >>
> >> Well it does not help because you did not answer the questions listed in 
> >> the
> >> design page.
> >>
> >> Anyway, here is third version of the design. It avoids copying user-made
> >> records (basically 2 DNAMEs were replaced with bunch of CNAMEs):
> >>
> >> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Design_.28Version_3:_CNAME_per_service_name.29
> >>
> >> It seems like a good middle ground:
> >> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Comparison_of_proposals
> > 
> > It does seem like a decent middle ground.
> > And I guess an admin would be able to add custom templates if he wants
> > to have specific services forwarded to the location specific subtree ?
> 
> Yes, the bind-dyndb-ldap's RecordGenerator and PerServerConfigInLDAP are
> generic enough. At the moment we do not plan to expose these mechanisms in
> user interface, we might do that later on.
> 
> 
> >> This required changes in RecordGenerator design, too:
> >> https://fedorahosted.org/bind-dyndb-ldap/wiki/Design/RecordGenerator
> > 
> > I do not see where you specify the specific record names you forward to
> > the location trees here?
> 
> I do not understand the question. Let's have a look at the example:
> 
> # DN specifies DNS node name which will hold the generated record:
> dn: idnsName=_udp,idnsname=example.com.,cn=dns,dc=example,dc=com
> # this is equivalent to _udp.example.com.
> 
> objectClass: idnsTemplateObject
> objectClass: top
> objectClass: idnsRecord
> idnsName: _udp
> 
> # sub-type determines type of the generated record = DNAME
> idnsTemplateAttribute;dnamerecord:
> _udp.\{substitutionvariable_ipalocation\}._locations
> # generated value will be _udp.your-location._locations
> # it is a relative name so zone name (example.com) will be automatically 
> appended
> 
> The template is just string, so you can specify an absolute name if you want:
> idnsTemplateAttribute;dnamerecord:
> _udp.\{substitutionvariable_ipalocation\}._locations.another.zone.example.
> 
> Of course 'ipalocation' is just a variable name so user can define his own in
> PerServerConfigInLDAP.
> 
> Is it clearer now?

Sorry I thought you said in option 3 that you would only create records
for specific services using CNAMEs
I was looking for how you configure which services you are going to pick
in that case and couldn't see it.
This example is a DNAME one and looks to me it is about option 2 ?

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [DESIGN] Sub-CAs; authenticating to Custodia

[Simo Sorce]

On Tue, 2016-04-19 at 21:57 -0400, Simo Sorce wrote:
> On Wed, 2016-04-20 at 11:32 +1000, Fraser Tweedale wrote:
> > On Tue, Apr 19, 2016 at 07:48:27AM +0200, Jan Cholasta wrote:
> > > On 14.4.2016 08:56, Jan Cholasta wrote:
> > > >On 7.4.2016 16:17, Petr Spacek wrote:
> > > >>On 7.4.2016 15:20, Fraser Tweedale wrote:
> > > >>>On Thu, Apr 07, 2016 at 12:29:00PM +0200, Jan Cholasta wrote:
> > > >>>>On 7.4.2016 12:13, Christian Heimes wrote:
> > > >>>>>On 2016-04-07 11:09, Petr Spacek wrote:
> > > >>>>>>On 7.4.2016 08:43, Fraser Tweedale wrote:
> > > >>>>>>>Hi team,
> > > >>>>>>>
> > > >>>>>>>I updated the Sub-CAs design page with more detail for the key
> > > >>>>>>>replication[1].  This part of the design is nearly complete (a 
> > > >>>>>>>large
> > > >>>>>>>patchset is in review over at pki-devel@) but there are various
> > > >>>>>>>options about how to authenticate to Custodia.
> > > >>>>>>>
> > > >>>>>>>[1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication
> > > >>>>>>>
> > > >>>>>>>In brief, the options are:
> > > >>>>>>>
> > > >>>>>>>1) authenticate as host principal; install binary setuid
> > > >>>>>>>root:pkiuser to read host keytab and custodia keys.
> > > >>>>>>
> > > >>>>>>Huh, I really do not like this. Host keytab on IPA master is one
> > > >>>>>>of the most
> > > >>>>>>sensitive keys we have.
> > > >>>>>>
> > > >>>>>>Maybe gssproxy can be used somehow, but I think it would be better
> > > >>>>>>to use
> > > >>>>>>separate key.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>>2) authenticate as host principal; copy host keytab and custodia
> > > >>>>>>>keys to location readable by pkiuser.
> > > >>>>>>
> > > >>>>>>No, really, do not copy host keytab anywhere.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>>3) create new principal for pkiuser to use, along with custodia 
> > > >>>>>>>keys
> > > >>>>>>>and keytab in location readable by pkiuser.
> > > >>>>>>>
> > > >>>>>>>I prefer option (1) for reasons outlined in the design page.  The
> > > >>>>>>>design page goes into quite a bit more detail so please review the
> > > >>>>>>>section linked above and get back to me with your thoughts.
> > > >>>>>>
> > > >>>>>>The only downside of (3) using new keys is:
> > > >>>>>>... This approach requires the creation of new principals, and
> > > >>>>>>Kerberos
> > > >>>>>>keytabs and Custodia keys for those principals, as part of the
> > > >>>>>>installation/upgrade process.
> > > >>>>>>
> > > >>>>>>Compared with additional SUID binary this seems as safer and
> > > >>>>>>easier way to go.
> > > >>>>>>FreeIPA installers already create quite a lot of principals and
> > > >>>>>>keytabs so
> > > >>>>>>this is well understood task.
> > > >>>>>>
> > > >>>>>>I would do (3).
> > > >>>>>
> > > >>>>>+1 for (3)
> > > >>>>>
> > > >>>>>A SUID binary feels like a dangerous hack.
> > > >>>>
> > > >>>>+1
> > > >>>>
> > > >>>OK, (3) it is.  Thanks all for your input.
> > > >>>
> > > >>>Now for next question: what should service principal name be?  I
> > > >>>think `dogtag/example@example.com' but am open to other
> > > >>>suggestions, e.g. `pki/...'.
> > > >>
> > > >>Do you plan to attempt t

Re: [Freeipa-devel] [DESIGN] Sub-CAs; authenticating to Custodia

[Simo Sorce]

On Wed, 2016-04-20 at 11:32 +1000, Fraser Tweedale wrote:
> On Tue, Apr 19, 2016 at 07:48:27AM +0200, Jan Cholasta wrote:
> > On 14.4.2016 08:56, Jan Cholasta wrote:
> > >On 7.4.2016 16:17, Petr Spacek wrote:
> > >>On 7.4.2016 15:20, Fraser Tweedale wrote:
> > >>>On Thu, Apr 07, 2016 at 12:29:00PM +0200, Jan Cholasta wrote:
> > >>>>On 7.4.2016 12:13, Christian Heimes wrote:
> > >>>>>On 2016-04-07 11:09, Petr Spacek wrote:
> > >>>>>>On 7.4.2016 08:43, Fraser Tweedale wrote:
> > >>>>>>>Hi team,
> > >>>>>>>
> > >>>>>>>I updated the Sub-CAs design page with more detail for the key
> > >>>>>>>replication[1].  This part of the design is nearly complete (a large
> > >>>>>>>patchset is in review over at pki-devel@) but there are various
> > >>>>>>>options about how to authenticate to Custodia.
> > >>>>>>>
> > >>>>>>>[1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication
> > >>>>>>>
> > >>>>>>>In brief, the options are:
> > >>>>>>>
> > >>>>>>>1) authenticate as host principal; install binary setuid
> > >>>>>>>root:pkiuser to read host keytab and custodia keys.
> > >>>>>>
> > >>>>>>Huh, I really do not like this. Host keytab on IPA master is one
> > >>>>>>of the most
> > >>>>>>sensitive keys we have.
> > >>>>>>
> > >>>>>>Maybe gssproxy can be used somehow, but I think it would be better
> > >>>>>>to use
> > >>>>>>separate key.
> > >>>>>>
> > >>>>>>
> > >>>>>>>2) authenticate as host principal; copy host keytab and custodia
> > >>>>>>>keys to location readable by pkiuser.
> > >>>>>>
> > >>>>>>No, really, do not copy host keytab anywhere.
> > >>>>>>
> > >>>>>>
> > >>>>>>>3) create new principal for pkiuser to use, along with custodia keys
> > >>>>>>>and keytab in location readable by pkiuser.
> > >>>>>>>
> > >>>>>>>I prefer option (1) for reasons outlined in the design page.  The
> > >>>>>>>design page goes into quite a bit more detail so please review the
> > >>>>>>>section linked above and get back to me with your thoughts.
> > >>>>>>
> > >>>>>>The only downside of (3) using new keys is:
> > >>>>>>... This approach requires the creation of new principals, and
> > >>>>>>Kerberos
> > >>>>>>keytabs and Custodia keys for those principals, as part of the
> > >>>>>>installation/upgrade process.
> > >>>>>>
> > >>>>>>Compared with additional SUID binary this seems as safer and
> > >>>>>>easier way to go.
> > >>>>>>FreeIPA installers already create quite a lot of principals and
> > >>>>>>keytabs so
> > >>>>>>this is well understood task.
> > >>>>>>
> > >>>>>>I would do (3).
> > >>>>>
> > >>>>>+1 for (3)
> > >>>>>
> > >>>>>A SUID binary feels like a dangerous hack.
> > >>>>
> > >>>>+1
> > >>>>
> > >>>OK, (3) it is.  Thanks all for your input.
> > >>>
> > >>>Now for next question: what should service principal name be?  I
> > >>>think `dogtag/example@example.com' but am open to other
> > >>>suggestions, e.g. `pki/...'.
> > >>
> > >>Do you plan to attempt to standardize this name in future? I do not
> > >>expect that.
> > >>
> > >>Considering private nature of it, it should be as specific as possible to
> > >>avoid any potential conflicts with future standards.
> > >>"dogtag-key-replication"
> > >>sounds like a good candidate.
> > >
> > >IMO it shouldn't be *that* specific, considering we want to switch
> > >Dogtag from SSL to GSSAPI authentication to DS, which will probably use
> > >the same principal name. I think "ipa-pki/..." or "dogtag/..." should be
> > >fine.
> > 
> > (Forgot to CC Fraser.)
> > 
> What is HTTP client support like for principal names with service
> part /= "HTTP"?

As a target ?
None, in which case are you going to use the dogtag keytab for the
acceptor though ?

>   For communication from IPA framework to Dogtag,
> we will need a way to force the client to use an alternative service
> name.

Our pbox design says differently.
We'll just interpose gssproxy and we'll be able to safely share the HTTP
key for all services.

> As for the actual service name, I will use "dogtag/..."

Good to use as a client.

Simo.

> Cheers,
> Fraser
> 
> > >
> > >>
> > >>Before you set the name in stone make sure it does not conflict with
> > >>anything
> > >>listed on
> > >>http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
> > >>
> > >>
> > >>These names have potential to be used by someone else.
> > >
> > 
> > -- 
> > Jan Cholasta
> 


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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Locations design v2: LDAP schema & user interface

[Simo Sorce]

On Tue, 2016-04-19 at 11:11 +0200, Petr Spacek wrote:
> On 18.4.2016 21:33, Simo Sorce wrote:
> > On Mon, 2016-04-18 at 17:44 +0200, Petr Spacek wrote:
> >> * Find, filter and copy hand-made records from main tree into the
> >> _locations sub-trees. This means that every hand-made record
> >> needs to be copied and synchronized N-times where N = number of IPA
> >> locations.
> > 
> > This ^^ seem the one that provides the best semantics for admins and the
> > least unexpected results.
> > 
> >> My favorite option for the first version is 'document that enabling
> >> DNS location will hide hand-made records in IPA domain.'
> > 
> > I do not think this is acceptable, sorry.
> > 
> >> The feature is disabled by default and needs additional configuration
> >> anyway so simply upgrading should not break anything.
> > 
> > It is also useless this way.
> > 
> >> I'm eager to hear opinions and answers to questions above.
> > 
> > HTH,
> 
> Well it does not help because you did not answer the questions listed in the
> design page.
> 
> Anyway, here is third version of the design. It avoids copying user-made
> records (basically 2 DNAMEs were replaced with bunch of CNAMEs):
> 
> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Design_.28Version_3:_CNAME_per_service_name.29
> 
> It seems like a good middle ground:
> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#Comparison_of_proposals

It does seem like a decent middle ground.
And I guess an admin would be able to add custom templates if he wants
to have specific services forwarded to the location specific subtree ?

> This required changes in RecordGenerator design, too:
> https://fedorahosted.org/bind-dyndb-ldap/wiki/Design/RecordGenerator

I do not see where you specify the specific record names you forward to
the location trees here?

> Also, CLI was updated to follow Honza's recommendations from previous e-mails:
> http://www.freeipa.org/page/V4/DNS_Location_Mechanism#CLI

Thanks for updating all designs in concert.

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling

[Simo Sorce]

On Tue, 2016-04-19 at 12:37 +0200, Martin Babinsky wrote:
> On 04/19/2016 10:11 AM, David Kupka wrote:
> > On 18/04/16 21:42, Simo Sorce wrote:
> >> On Wed, 2016-04-13 at 07:50 +0200, David Kupka wrote:
> >>> On 08/04/16 17:10, Martin Babinsky wrote:
> >>>> Hi list,
> >>>>
> >>>> I have put together a draft [1] outlining the effort to reimplement the
> >>>> handling of Kerberos principals in both backend and frontend layers of
> >>>> FreeIPA so that we may have multiple aliases per user, host or service
> >>>> and thus implement stuff like
> >>>> https://fedorahosted.org/freeipa/ticket/3961 and
> >>>> https://fedorahosted.org/freeipa/ticket/5413 .
> >>>>
> >>>> Since much of the plumbing was already implemented,[2] the document
> >>>> mainly describes what the patches do. Some parts required by other use
> >>>> cases may be missing so please point these out.
> >>>>
> >>>> I would also be happy if you could correct all factual inacurracies, I
> >>>> did research on this issue a long time ago and my knowledge turned a
> >>>> bit
> >>>> rusty.
> >>>>
> >>>> [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases
> >>>> [2]
> >>>> https://www.redhat.com/archives/freeipa-devel/2015-October/msg00048.html
> >>>>
> >>>>
> >>>
> >>> Hi,
> >>> after reading the designs following thoughts comes to my mind.
> >>>
> >>> 1) Just to be sure that I understand the new ticket obtaining process
> >>> correctly I'd like to summarize.
> >>> We need to always search all krbPrincipalName values, krbCanonicalName
> >>> and ipaKrbPrincipalAlias (for backward compatibility).
> >>> For TGT request case sensitivity of the search and principal in returned
> >>> ticket depends on canonicalization. When canonicalization is requested
> >>> the search is case-insensitive and krbCanonicalName is used otherwise
> >>> case-sensitive search is performed and principal from request is used.
> >>
> >> Yes.
> >>
> >>> When requesting TGS search is always case-sensitive and principal from
> >>> request is used.
> >>
> >> No, this sounds wrong to me, I think we want a case-insensitve search
> >> for TGS requests.
> >>
> >>> In pseudo-code:
> >>>
> >>> get_tgt(principal, secret, canonicalization)
> >>>   if canonicalization
> >>>   if principal case-insensitive-in {krbPrincipalName +
> >>> ipaKrbPrincipalAlias + krbCanonicalName}
> >>>   # verify secret, perform various other checks...
> >>>   return TGT(krbCanonicalName)
> >>>   else
> >>>   if principal case-sensitive-in {krbPrincipalName +
> >>> ipaKrbPrincipalAlias + krbCanonicalName}
> >>>   # verify secret, perform various other checks...
> >>>   return TGT(principal)
> >>>
> >>> get_tgs(service_principal, TGT)
> >>>   if service_principal case-sensitive-in {krbPrincipalName +
> >>> ipaKrbPrincipalAlias + krbCanonicalName}
> >>>   # verify TGT, perform various other checks...
> >>>   return TGS(service_principal)
> >>>
> >>> Do I understand it right?
> >>
> >> I do not think the TGS part is right.
> >> A case insensitive search in TGS would allow to match upper case service
> >> or host names which are sometime mistakenly used, especially in Windows
> >> born software, given that the AD KDC is case insensitive.
> >>
> >
> > Ok, thanks for correcting me.
> >
> >>> 2) I would like to add following constrains for
> >>> krb{Canonical,Principal}Name attributes:
> >>>
> >>> when user/host/service is created krbCanonicalName is set to the same
> >>> value as krbPrincipalName
> >>> krbCanonicalName cannot be modified
> >>> krbPrincipalName with the same value as krbCanonicalName cannot be
> >>> removed/modified
> >>> krbPrincipalName must be case-insensitively unique in whole DB
> >>> krbPrincipalName attributes can be added and/or removed
> >>
> >> +1
> >>
> >>> This will allow us to keep the first krbPrincipalName as RDN for
&g

Re: [Freeipa-devel] [PATCH] 0051 Allow CustodiaClient to be used by arbitrary principals

[Simo Sorce]

On Thu, 2016-04-14 at 16:33 +1000, Fraser Tweedale wrote:
> On Wed, Apr 13, 2016 at 11:15:50AM +1000, Fraser Tweedale wrote:
> > On Tue, Apr 12, 2016 at 09:31:30AM -0400, Simo Sorce wrote:
> > > On Sat, 2016-04-09 at 10:11 +1000, Fraser Tweedale wrote:
> > > > On Fri, Apr 08, 2016 at 10:47:19AM -0400, Simo Sorce wrote:
> > > > > On Sat, 2016-04-09 at 00:23 +1000, Fraser Tweedale wrote:
> > > > > > -name = gssapi.Name('host@%s' % (self.client,),
> > > > > > 
> > > > > > -   gssapi.NameType.hostbased_service)
> > > > > 
> > > > > If you remove this then on a serve that has nfs keys in the keytab you
> > > > > may end up acquiring the wrong credentials.
> > > > > You need to pass down what credentials you want to use to initialize 
> > > > > the
> > > > > cred store, we canot rely on ordering in the system keytab case.
> > > > > 
> > > > > Simo.
> > > > > 
> > > > Thanks Simo; updated patch attached.
> > > 
> > > Except the ACI the rest looks good to me.
> > > For ACI please add a separate patch that follows the naming scheme for
> > > subCA keys.
> > > 
> > The ACI here targets the Custodia server public keys, so the client
> > can search and read them.  It should just read:
> > 
> > add:aci: (target = "ldap:///cn=*,cn=custodia,cn=ipa,cn=etc,$SUFFIX;)
> > (targetattr = "ipaPublicKey || ipaKeyUsage || memberPrincipal")
> > (version 3.0; acl "Anyone can search Custodia public keys";
> > allow(read, search, compare) userdn = "ldap:///all;;)
> > 
> > I don't mind putting the ACI in a separate patch, but it is
> > necessary to restrict read access on the public keys to only the
> > dogtag-ipa-custodia service principals.
> > 
> Updated patches attached.  ACI was split into new patch and
> simplified (removed ($dn) macro).

Ack on the custodia patch.
However do we really need to allow *anyone* to look up these keys ?
I know they are "public" keys, but still  ... I think I would prefer a
stricter ACI.

Simo.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [DESIGN] Kerberos principal alias handling

[Simo Sorce]

Cs are at a specific level before allowing to turn on
this behavior, but then we need to make it conditional and this all
starts to sound a lot like a new domain level.
OTOH only alias resolution fails on older KDCs, so that may be ok in
some cases.

Are there any strong opinions?
Should we make this change optional and activate it only when enough
features come up that demand a new domain level ?
We can always generate the canonicalName now to be ready, but prevent
adding aliases until a new domain level is created ?
Any other idea ?

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Locations design v2: LDAP schema & user interface

[Simo Sorce]

On Mon, 2016-04-18 at 17:44 +0200, Petr Spacek wrote:
> * Find, filter and copy hand-made records from main tree into the
> _locations sub-trees. This means that every hand-made record
> needs to be copied and synchronized N-times where N = number of IPA
> locations.

This ^^ seem the one that provides the best semantics for admins and the
least unexpected results.

> My favorite option for the first version is 'document that enabling
> DNS location will hide hand-made records in IPA domain.'

I do not think this is acceptable, sorry.

> The feature is disabled by default and needs additional configuration
> anyway so simply upgrading should not break anything.

It is also useless this way.

> I'm eager to hear opinions and answers to questions above.

HTH,
Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH] 0051 Allow CustodiaClient to be used by arbitrary principals

[Simo Sorce]

On Sat, 2016-04-09 at 10:11 +1000, Fraser Tweedale wrote:
> On Fri, Apr 08, 2016 at 10:47:19AM -0400, Simo Sorce wrote:
> > On Sat, 2016-04-09 at 00:23 +1000, Fraser Tweedale wrote:
> > > -name = gssapi.Name('host@%s' % (self.client,),
> > > 
> > > -   gssapi.NameType.hostbased_service)
> > 
> > If you remove this then on a serve that has nfs keys in the keytab you
> > may end up acquiring the wrong credentials.
> > You need to pass down what credentials you want to use to initialize the
> > cred store, we canot rely on ordering in the system keytab case.
> > 
> > Simo.
> > 
> Thanks Simo; updated patch attached.

Except the ACI the rest looks good to me.
For ACI please add a separate patch that follows the naming scheme for
subCA keys.

Simo.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] DNs of Custodia keys

[Simo Sorce]

On Tue, 2016-04-12 at 21:26 +1000, Fraser Tweedale wrote:
> On Tue, Apr 12, 2016 at 12:55:50PM +0200, Jan Cholasta wrote:
> > Hi,
> > 
> > On 12.4.2016 09:03, Fraser Tweedale wrote:
> > >Hi Simo and Honza et al,
> > >
> > >I have a design challenge pertaining to DNs for Custodia keys.
> > >DNs for Custodia keys for host principals currently take the form:
> > >
> > > cn={sig,enc}/$HOSTNAME,cn=custodia,cn=ipa,cn=etc,$SUFFIX
> > >
> > >This prevents the creation of Custodia keys for service principals
> > >(pursuant to another recent design decision[1] the service principal
> > >'dogtag-ipa-custodia/$HOSTNAME@$REALM' shall be used as a Custodia
> > >client for Dogtag lightweight CA key replication).
> > 
> > This naming scheme is relevant only to IPA server keys, otherwise the cn can
> > be anything, as long as it does not conflict with existing keys.
> > 
> > >
> > >[1] https://www.redhat.com/archives/freeipa-devel/2016-April/msg00044.html
> > >
> > >Searches for custodia keys use a filter on 'ipaKeyUsage' and
> > >'memberPrincipal' attributes, so the CN is unimportant except for
> > >a) uniqueness, and b) ACIs (see below).
> > >
> > >Based on this, my first attempt to resolve the conflict was to use
> > >the service name and host name instead of the just the hostname:
> > >
> > > 
> > > cn=sig/host/f23-5.ipa.local@IPA.LOCAL,cn=custodia,cn=ipa,cn=etc,dc=ipa,dc=local
> > >
> > >However, this fails during replica install:
> > >
> > >   [2/5]: Generating ipa-custodia keys
> > >   {'info': "Insufficient 'add' privilege to add the entry
> > > 
> > > 'cn=sig/host/f23-5.ipa.local,cn=custodia,cn=ipa,cn=etc,dc=ipa,dc=local'.\n",
> > >'desc': 'Insufficient access'}
> > >
> > >due to the ACI:
> > >
> > > dn: cn=ipa,cn=etc,$SUFFIX
> > > add:aci: (target = 
> > > "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")
> > > (version 3.0; acl "IPA server hosts can create own Custodia 
> > > secrets";
> > > allow(add) groupdn = 
> > > "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX;
> > > and userdn = 
> > > "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";)
> > >
> > >The wildcard '*' in the target is not greedy and stops at the first
> > >slash '/', so the value captured by the ($dn) macro does not match
> > >the bind DN.
> > 
> > Again, this is relevant only to IPA server keys, you should add your own ACI
> > for lightweight CAs.
> > 
> > >
> > >
> > >Proposed solution
> > >-
> > >
> > >Use a delimiter other than '/' between the key type and service
> > >name, e.g.
> > >
> > > cn={sig,enc}+$SERVICENAME/$HOSTNAME(rule)
> > > cn=sig+dogtag-ipa-custodia/f23-3.ipa.local (example)
> > >
> > >Pros: should work with existing ACIs.
> > >
> > >Cons: continues with an arguably suboptimal design choice.
> > >
> > >
> > >Alternative solution
> > >
> > >
> > >Add an 'ipaCustodiaKey' object class, which has 'managedBy'
> > >attribute for linking the key to the host that manages it, and
> > >'ipaUniqueId'.
> > >
> > >Create key entries with autogenerated ipaUniqueId as RDN.
> > >
> > >Add ACIs:
> > >
> > > dn: cn=ipa,cn=etc,$SUFFIX
> > > add:aci: (target = "ldap:///*,cn=custodia,cn=ipa,cn=etc,$SUFFIX;)
> > > (version 3.0; acl "IPA server hosts can create own Custodia 
> > > secrets";
> > > allow(add) groupdn = 
> > > "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX;
> > > and userattr = "managedby#USERDN";)
> > > add:aci: (target = "ldap:///*,cn=custodia,cn=ipa,cn=etc,$SUFFIX;) 
> > > (targetattr = "ipaPublicKey")
> > > (version 3.0; acl "IPA server hosts can manage own Custodia 
> > > secrets";
> > > allow(write) groupdn = 
> > > "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX;
> > > and userattr = "managedby#USERDN";)
> > >
> > >(Retain existing ACIs for backwards compatiblity.)
> > 
> > Actually this has been discussed before:
> > 
> > 
> Thanks for the link and feedback.
> 
> Something like the following ACI should do the trick, I think?
> 
>   add:aci: (target = 
> "ldap:///cn=*/dogtag-ipa-custodia/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")
>   (version 3.0; acl "IPA server hosts can manage Custodia secrets for the 
> dogtag-ipa-custodia service on same host";
>   allow(add) groupdn = 
> "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX;
>   and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";)
> 
> Host Custodia keys would keep the existing CN schema and existing
> ACLs will apply only to them.

You may also think of adding a subtree specific to subCA keys perhaps.

Simo.


-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH] 0051 Allow CustodiaClient to be used by arbitrary principals

[Simo Sorce]

On Sat, 2016-04-09 at 00:23 +1000, Fraser Tweedale wrote:
> -name = gssapi.Name('host@%s' % (self.client,),
> 
> -   gssapi.NameType.hostbased_service)

If you remove this then on a serve that has nfs keys in the keytab you
may end up acquiring the wrong credentials.
You need to pass down what credentials you want to use to initialize the
cred store, we canot rely on ordering in the system keytab case.

Simo.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [DESIGN] Sub-CAs; authenticating to Custodia

[Simo Sorce]

On Thu, 2016-04-07 at 16:43 +1000, Fraser Tweedale wrote:
> Hi team,
> 
> I updated the Sub-CAs design page with more detail for the key
> replication[1].  This part of the design is nearly complete (a large
> patchset is in review over at pki-devel@) but there are various
> options about how to authenticate to Custodia.
> 
> [1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication
> 
> In brief, the options are:
> 
> 1) authenticate as host principal; install binary setuid
>root:pkiuser to read host keytab and custodia keys.
> 
> 2) authenticate as host principal; copy host keytab and custodia
>keys to location readable by pkiuser.
> 
> 3) create new principal for pkiuser to use, along with custodia keys
>and keytab in location readable by pkiuser.
> 
> I prefer option (1) for reasons outlined in the design page.  The
> design page goes into quite a bit more detail so please review the
> section linked above and get back to me with your thoughts.

I haven't read the whole design completely yet (sorry, busy with some
critical bug), only the Key Replication part.
We are moving toward removing access to the HTTP key from even the IPA
framework, and I would definitely not want to give access to the host
keytab to unprivileged processes.

So I lean very heavily on (3).

Simo. 


-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [DESIGN] Server Roles

[Simo Sorce]

ases:
> 
> $ server-role-find
> "CA"
> "CA renewal master"
> "DNS server"
> "DNSSec Key Master"
> ...
> 
> maybe is should print also description, but help might be enough.
> 
> 
> $ ipa server-role-enable $SERVER "CA renewal master"
> Error: Server must have a "CA" role.
> 
> $ ipa server-role-enable $SERVER "CA"
> Error: run ipa-ca-install on $SERVER to enable the CA role
> 
> Note: if in future we implement a privileged daemon then the 
> installation can be done by the daemon.
> 
> # ipa-ca-install
> 
> $ ipa server-role-enable $SERVER "CA"
> INFO: Server already in CA role
> 
> $ server-show $SERVER
> ...
> Roles: DNS Server, CA
> ...
> 
> $ ipa server-role-enable $SERVER "CA renewal master"
> SUCCESS: $server is now "CA renewal master"
> INFO: "CA renewal master" role was unset from $SERVER_PREVIOUS
> 
> What is a purpose of `ipa server-role-disable`?
> 
> If in future we need to configure a role then:
> 
> $ ipa server-role-mod $SERVER $ROLE --fooattr=value (this is not 
> supported in FW now because the attrs might differ based on $ROLE)

I am not sure why we use enable/disable verbs here, why not a simple
add/remove ?
enable/disabled usually means you can add a role but keep it disabled,
or that you can keep a role installed and just disabled it, but that is
not really the case.

Also I would like to draw attention to one other aspect.
Roles != Services, in the list of roles for example I see memcached, it
is in the list because you picked up all services and made a role out of
them, but they are not all roles.

in fact memcached is just an implementation detail of the framework and
should not be mentioned at all (and in fact we are planning to stop
using it altogether).

Another "role" thaat should probably not exist is kpasswd, again kpasswd
is there only because we required to start a separate service to
implement its functionality, but semantically it is just an
implementation detail of the KDC role. A master KDC will *always* have
it, and in future, a Read Only KDC will not have it or use a different
service that can proxy password change requests to a writable master, in
any case an admin should not be able to "enable/disable" this role
disjointly from the KDC role.

Finally, although the KRA is a separate Role it has a dependency on the
CA Role, how is that expressed ?

Last but not least, why do we need a "role" concept ? Cab't we simply
expose the running services ? If not, the reasons why need to be
explained in the design page, as currently it only says that Role are
introduced to expose the information, but it doesn't say why just
exposing the information w/o changing any semantics is not desirable.

My 2c,
Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH] 955 sessions: use unique mod_auth_gssapi ccaches

[Simo Sorce]

- Original Message -
> From: "Petr Vobornik" <pvobo...@redhat.com>
> To: "Simo Sorce" <s...@redhat.com>
> Cc: "freeipa-devel" <freeipa-devel@redhat.com>
> Sent: Wednesday, March 16, 2016 12:16:02 PM
> Subject: Re: [PATCH] 955 sessions: use unique mod_auth_gssapi ccaches
> 
> On 03/10/2016 03:25 PM, Simo Sorce wrote:
> > On Thu, 2016-03-10 at 15:03 +0100, Petr Vobornik wrote:
> >> Attaching also mod_auth_gssapi patch. If the approach is good, then I'd
> >> send it as a push request to upstream git repo.
> >>
> >> Copr build of mod_auth_gssapi with the patch:
> >> https://copr.fedorainfracloud.org/coprs/pvoborni/freeipa-4-3/build/167157/
> >>
> >> IPA patch attached uses the functionality.
> >>
> >> https://fedorahosted.org/freeipa/ticket/5653
> >
> > I think the mod_auth_gssapi patch needs more work.
> 
> New iteration, but not a final patch, mostly because of reaping of the
> files, but there are also some debug prints.
> 
> >
> > For one you are not storing the generated ccname in the cookie, which
> > means any following request using mod_auth_gssapi sessions will not be
> > able to point to the ccache file.
> 
> Do you mean session? Cookie should contain only session ID, right?

No, in other to avoid having to keep state on the server we create a session 
storage
structure, encrypt it in a key known only to the server, and send it as a 
cookie.

This way we do not have to store anything on the server side.

> >
> > It is also not clear to me why you are using a timestamp and not just
> > call something like mkstemp() with a template, and add an option called
> > GssapiDelegCcacheTemplate instead.
> 
> I didn't think about that.
> 
> >
> > The templated part would have to be saved in the session so that
> > following requests can keep using the same ccache file.
> 
> Fixed (but not tested yet)
> 
> >
> > There are other minor niticks around naming stuff, but those can be
> > handled in the PR.
> >
> > One thing I am still undecided about is deletion of the files, I'd like
> > to have a better option than "application must delete them", I was
> > thinking about keeping a record of the expiration time (not sure where
> > yet), and then provide a cron job or a systemd timer to clean up all
> > expired stuff.
> 
> I thought we won't need it and that it could be handled by apps, but
> that won't work.
> 
> Case 1: ipa kerberize entire /ipa directory so a request to a random
> resource might leave a ccache behind, e.g.:
>curl -v --negotiate -u : --cacert /etc/ipa/ca.crt
> https://$(hostname)/ipa/foo
> 
> leaves:
> ls /var/run/httpd/ipa/clientcaches/
> ipacchache-sgwB9v
> 
> Case 2: custodia, it doesn't clean anything as well.
> 
> When sessions are not it play then, the plugin can remove the ccache at
> the end of request. AFAIK mod_auth_kerb does it.
> 
> With sessions, there needs to be a reaper.

Exactly.

Simo.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [DESIGN] Server Roles

[Simo Sorce]

On Fri, 2016-03-18 at 15:28 +0100, Petr Vobornik wrote:
> On 03/18/2016 02:59 PM, Simo Sorce wrote:
> > On Fri, 2016-03-18 at 14:44 +0100, Petr Vobornik wrote:
> >> On 03/18/2016 10:59 AM, Martin Kosek wrote:
> >>> On 03/18/2016 10:47 AM, Martin Babinsky wrote:
> >>>> On 03/18/2016 10:21 AM, Martin Kosek wrote:
> >>>>> On 03/17/2016 06:16 PM, Martin Babinsky wrote:
> >>>>>> Hi list,
> >>>>>>
> >>>>>> here is a link (http://www.freeipa.org/page/V4/Server_Roles) to WIP 
> >>>>>> design
> >>>>>> document concerning the concept of Server Roles as a user-friendly 
> >>>>>> abstraction
> >>>>>> of the services running on IPA masters.
> >>>>>>
> >>>>>> The main aim of this feature is to provide a higher level interface to 
> >>>>>> query
> >>>>>> and manipulate service-related information stored in dirsrv backend.
> >>>>>>
> >>>>>> I have not touched the design much from the post-Devconf session, 
> >>>>>> mainly
> >>>>>> because there are some points to clarify and agree upon.
> >>>>>
> >>>>> Initial thoughts:
> >>>>>
> >>>>> * Use Cases: these are rather vague points what you want to implement. 
> >>>>> In Use
> >>>>> Case section, I would like to see what specific *user* use cases you are
> >>>>> addressing, i.e. what user problems you are solving. Ideally in a form 
> >>>>> of a
> >>>>> user story. Like here:
> >>>>>
> >>>>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Use_Cases
> >>>>> or here:
> >>>>> http://www.freeipa.org/page/V4/Authentication_Indicators#Use_Cases
> >>>>> or here:
> >>>>> http://www.freeipa.org/page/V4/External_trust_to_AD#Use_Cases
> >>>>>
> >>>> Ok I will thing of some clearer points.
> >>>>
> >>>>>> I have the following points to discuss:
> >>>>>>
> >>>>>> 1.) the design assumes that there is a distinction between roles such 
> >>>>>> as DNS
> >>>>>> server, CA, etc. and the more specific sub-roles such as DNSSec key 
> >>>>>> master, CRL
> >>>>>> master, etc. Now in the hindsight I think this distinction is quite 
> >>>>>> artificial
> >>>>>> and just clutters the interface unnecessarily. We might implement this 
> >>>>>> kind of
> >>>>>> hierarchy in the code itself but that is something the user needs not 
> >>>>>> be
> >>>>>> aware of.
> >>>>>
> >>>>> Well, there are dependencies. A server cannot be a CRL master without 
> >>>>> also
> >>>>> being a CA role. I assume same applies to DNSSEC master.
> >>>>>
> >>>>> I think we need to think more about distinguishing what is role, what 
> >>>>> is just
> >>>>> an attribute of a role, etc. AD for example distinguishes roles, role 
> >>>>> service
> >>>>> and features:
> >>>>>
> >>>>> https://technet.microsoft.com/en-us/library/cc754923.aspx
> >>>>>
> >>>> We will have to implement the role/subrole/unicorn hierarchy anyhow. 
> >>>> What I
> >>>> would like to discuss is whether it is necessary to expose this 
> >>>> hierarchy to
> >>>> the users. Consider a case when user wants to find which server is a CA 
> >>>> renewal
> >>>> master:
> >>>>
> >>>> ipa server-role-find "CA renewal master"
> >>>>
> >>>> vs.
> >>>>
> >>>> ipa server-role-find --subrole "Renewal master"
> >>>>
> >>>> Behind the scenes, the code has to do the same thing (e.g. issue a 
> >>>> search using
> >>>> (&(cn=CA)(ipaConfigString=enabledService)(ipaConfigString=caRenewalMaster))),
> >>>> but the UX is a bit different.
> >>>
> >>> Well, even the LDAP structure is different in this case. CA role is an 
> >>> object
> >>> in cn=masters, 

Re: [Freeipa-devel] [PATCH] 0008 Add X-Frame-Options and frame-ancestors options

[Simo Sorce]

On Thu, 2016-03-10 at 19:20 +0100, Pavel Vomacka wrote:
> 
> On 03/10/2016 07:02 PM, Simo Sorce wrote:
> > On Thu, 2016-03-10 at 18:47 +0100, Pavel Vomacka wrote:
> >> Hi,
> >>
> >> These two options allow preventing clickjacking attacks. They don't
> >> allow open FreeIPA in frame, iframe or object element.
> > Will these apply to the whole server or just to /ipa ?
> >
> Yes, you are right, these apply to whole server. In this new patch they 
> are applied only on /ipa.
> 
> --
> Pavel^3 Vomacka

Thanks,
LGTM

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH] 0008 Add X-Frame-Options and frame-ancestors options

[Simo Sorce]

On Thu, 2016-03-10 at 18:47 +0100, Pavel Vomacka wrote:
> Hi,
> 
> These two options allow preventing clickjacking attacks. They don't 
> allow open FreeIPA in frame, iframe or object element.

Will these apply to the whole server or just to /ipa ?

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH] 955 sessions: use unique mod_auth_gssapi ccaches

[Simo Sorce]

On Thu, 2016-03-10 at 15:03 +0100, Petr Vobornik wrote:
> Attaching also mod_auth_gssapi patch. If the approach is good, then I'd 
> send it as a push request to upstream git repo.
> 
> Copr build of mod_auth_gssapi with the patch: 
> https://copr.fedorainfracloud.org/coprs/pvoborni/freeipa-4-3/build/167157/
> 
> IPA patch attached uses the functionality.
> 
> https://fedorahosted.org/freeipa/ticket/5653

I think the mod_auth_gssapi patch needs more work.

For one you are not storing the generated ccname in the cookie, which
means any following request using mod_auth_gssapi sessions will not be
able to point to the ccache file.

It is also not clear to me why you are using a timestamp and not just
call something like mkstemp() with a template, and add an option called
GssapiDelegCcacheTemplate instead.

The templated part would have to be saved in the session so that
following requests can keep using the same ccache file.

There are other minor niticks around naming stuff, but those can be
handled in the PR.

One thing I am still undecided about is deletion of the files, I'd like
to have a better option than "application must delete them", I was
thinking about keeping a record of the expiration time (not sure where
yet), and then provide a cron job or a systemd timer to clean up all
expired stuff.

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 558] Allow disabling requireing preauth by default for Service Principal Names

[Simo Sorce]

On Tue, 2016-03-08 at 17:20 +0100, Martin Babinsky wrote:
> On 03/08/2016 05:00 PM, Simo Sorce wrote:
> > On Tue, 2016-03-08 at 16:51 +0100, Martin Babinsky wrote:
> >> On 03/08/2016 04:49 PM, Simo Sorce wrote:
> >>> On Fri, 2015-12-04 at 14:23 +0100, Martin Babinsky wrote:
> >>>> On 12/01/2015 10:08 PM, Simo Sorce wrote:
> >>>>> On Tue, 2015-12-01 at 15:59 +0100, Martin Babinsky wrote:
> >>>>>> On 11/30/2015 07:42 PM, Simo Sorce wrote:
> >>>>>>> On Wed, 2015-11-25 at 10:33 +0100, Martin Babinsky wrote:
> >>>>>>>> On 11/24/2015 10:20 PM, Simo Sorce wrote:
> >>>>>>>>> This addresses #3860, giving admins the option to not require 
> >>>>>>>>> preauth
> >>>>>>>>> for Hosts and services.
> >>>>>>>>>
> >>>>>>>>> I did not add this option by default, although it does reduce the 
> >>>>>>>>> load
> >>>>>>>>> on the KDC as well as speed up TGT acquisition for service principal
> >>>>>>>>> accounts that acquire TGTs.
> >>>>>>>>>
> >>>>>>>>> Tested and working as expected (SPNs are not returned PREAUTH_NEEDED
> >>>>>>>>> error while normal users are).
> >>>>>>>>>
> >>>>>>>>> HTH,
> >>>>>>>>> Simo.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> Hi Simo,
> >>>>>>>>
> >>>>>>>> I was not able to apply the patch on current master branch:
> >>>>>>>>
> >>>>>>>> """
> >>>>>>>> git am
> >>>>>>>> ../review/ssorce/3860/freeipa-simo-558-1-Allow-admins-to-disable-preauth-for-SPNs.patch
> >>>>>>>> -3
> >>>>>>>>
> >>>>>>>> Applying: Allow admins to disable preauth for SPNs.
> >>>>>>>> error: invalid object 100644 a6b4d4349a9ac6de453d9ad3c679ec32add4e43b
> >>>>>>>> for 'ipalib/plugins/config.py'
> >>>>>>>> fatal: git-write-tree: error building trees
> >>>>>>>> Repository lacks necessary blobs to fall back on 3-way merge.
> >>>>>>>> Cannot fall back to three-way merge.
> >>>>>>>> Patch failed at 0001 Allow admins to disable preauth for SPNs.
> >>>>>>>> """
> >>>>>>>>
> >>>>>>>> It seems that I nedd to apply some of your other patches first 
> >>>>>>>> (which one?)
> >>>>>>>
> >>>>>>> Sorry did not see this question earlier, it requires 556 and 557, I 
> >>>>>>> just
> >>>>>>> bumped that thread.
> >>>>>>>
> >>>>>>> Simo.
> >>>>>>>
> >>>>>> It seems that I need something else, patch 556-2 applies cleanly, but
> >>>>>> patch 557-3 fails with http://fpaste.org/296230/89819431/ on both 
> >>>>>> master
> >>>>>> and 4-2 branch.
> >>>>>>
> >>>>>
> >>>>> Rebased 556,557 in their thread, and here is the rebase for 558 on top
> >>>>> of them.
> >>>>>
> >>>>> Simo.
> >>>>>
> >>>>
> >>>> ACK. I'm afraid that this patch and 556, 557 will require another round
> >>>> of rebase before pushing, though.
> >>>
> >>> Rebased on top of master (not on 556/557) per Petr's request.
> >>>
> >>> Simo.
> >>>
> >>>
> >>
> >> NACK, if you do API changes please increment API version in VERSION.
> >
> > Why wasn't this a problem in the previous ACK ?
> >
> > Simo.
> >
> 
> Probably because I missed it, sorry.
> 

Fixed.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
From 83ca7587d706f380d3384e378002009aa9116c06 Mon Sep 17 00:00:00 2001
From: Simo Sorce <s...@redhat.com>
Date: Tue, 24 Nov 2015 15:39:08 -0500
Subject: [PATCH] Allow admins to disable preauth for SPNs.

Some legacy softare is not able to properly cope 

Re: [Freeipa-devel] [PATCH 558] Allow disabling requireing preauth by default for Service Principal Names

[Simo Sorce]

On Tue, 2016-03-08 at 16:51 +0100, Martin Babinsky wrote:
> On 03/08/2016 04:49 PM, Simo Sorce wrote:
> > On Fri, 2015-12-04 at 14:23 +0100, Martin Babinsky wrote:
> >> On 12/01/2015 10:08 PM, Simo Sorce wrote:
> >>> On Tue, 2015-12-01 at 15:59 +0100, Martin Babinsky wrote:
> >>>> On 11/30/2015 07:42 PM, Simo Sorce wrote:
> >>>>> On Wed, 2015-11-25 at 10:33 +0100, Martin Babinsky wrote:
> >>>>>> On 11/24/2015 10:20 PM, Simo Sorce wrote:
> >>>>>>> This addresses #3860, giving admins the option to not require preauth
> >>>>>>> for Hosts and services.
> >>>>>>>
> >>>>>>> I did not add this option by default, although it does reduce the load
> >>>>>>> on the KDC as well as speed up TGT acquisition for service principal
> >>>>>>> accounts that acquire TGTs.
> >>>>>>>
> >>>>>>> Tested and working as expected (SPNs are not returned PREAUTH_NEEDED
> >>>>>>> error while normal users are).
> >>>>>>>
> >>>>>>> HTH,
> >>>>>>> Simo.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> Hi Simo,
> >>>>>>
> >>>>>> I was not able to apply the patch on current master branch:
> >>>>>>
> >>>>>> """
> >>>>>> git am
> >>>>>> ../review/ssorce/3860/freeipa-simo-558-1-Allow-admins-to-disable-preauth-for-SPNs.patch
> >>>>>> -3
> >>>>>>
> >>>>>> Applying: Allow admins to disable preauth for SPNs.
> >>>>>> error: invalid object 100644 a6b4d4349a9ac6de453d9ad3c679ec32add4e43b
> >>>>>> for 'ipalib/plugins/config.py'
> >>>>>> fatal: git-write-tree: error building trees
> >>>>>> Repository lacks necessary blobs to fall back on 3-way merge.
> >>>>>> Cannot fall back to three-way merge.
> >>>>>> Patch failed at 0001 Allow admins to disable preauth for SPNs.
> >>>>>> """
> >>>>>>
> >>>>>> It seems that I nedd to apply some of your other patches first (which 
> >>>>>> one?)
> >>>>>
> >>>>> Sorry did not see this question earlier, it requires 556 and 557, I just
> >>>>> bumped that thread.
> >>>>>
> >>>>> Simo.
> >>>>>
> >>>> It seems that I need something else, patch 556-2 applies cleanly, but
> >>>> patch 557-3 fails with http://fpaste.org/296230/89819431/ on both master
> >>>> and 4-2 branch.
> >>>>
> >>>
> >>> Rebased 556,557 in their thread, and here is the rebase for 558 on top
> >>> of them.
> >>>
> >>> Simo.
> >>>
> >>
> >> ACK. I'm afraid that this patch and 556, 557 will require another round
> >> of rebase before pushing, though.
> >
> > Rebased on top of master (not on 556/557) per Petr's request.
> >
> > Simo.
> >
> >
> 
> NACK, if you do API changes please increment API version in VERSION.

Why wasn't this a problem in the previous ACK ?

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 558] Allow disabling requireing preauth by default for Service Principal Names

[Simo Sorce]

On Fri, 2015-12-04 at 14:23 +0100, Martin Babinsky wrote:
> On 12/01/2015 10:08 PM, Simo Sorce wrote:
> > On Tue, 2015-12-01 at 15:59 +0100, Martin Babinsky wrote:
> >> On 11/30/2015 07:42 PM, Simo Sorce wrote:
> >>> On Wed, 2015-11-25 at 10:33 +0100, Martin Babinsky wrote:
> >>>> On 11/24/2015 10:20 PM, Simo Sorce wrote:
> >>>>> This addresses #3860, giving admins the option to not require preauth
> >>>>> for Hosts and services.
> >>>>>
> >>>>> I did not add this option by default, although it does reduce the load
> >>>>> on the KDC as well as speed up TGT acquisition for service principal
> >>>>> accounts that acquire TGTs.
> >>>>>
> >>>>> Tested and working as expected (SPNs are not returned PREAUTH_NEEDED
> >>>>> error while normal users are).
> >>>>>
> >>>>> HTH,
> >>>>> Simo.
> >>>>>
> >>>>>
> >>>>>
> >>>> Hi Simo,
> >>>>
> >>>> I was not able to apply the patch on current master branch:
> >>>>
> >>>> """
> >>>> git am
> >>>> ../review/ssorce/3860/freeipa-simo-558-1-Allow-admins-to-disable-preauth-for-SPNs.patch
> >>>> -3
> >>>>
> >>>> Applying: Allow admins to disable preauth for SPNs.
> >>>> error: invalid object 100644 a6b4d4349a9ac6de453d9ad3c679ec32add4e43b
> >>>> for 'ipalib/plugins/config.py'
> >>>> fatal: git-write-tree: error building trees
> >>>> Repository lacks necessary blobs to fall back on 3-way merge.
> >>>> Cannot fall back to three-way merge.
> >>>> Patch failed at 0001 Allow admins to disable preauth for SPNs.
> >>>> """
> >>>>
> >>>> It seems that I nedd to apply some of your other patches first (which 
> >>>> one?)
> >>>
> >>> Sorry did not see this question earlier, it requires 556 and 557, I just
> >>> bumped that thread.
> >>>
> >>> Simo.
> >>>
> >> It seems that I need something else, patch 556-2 applies cleanly, but
> >> patch 557-3 fails with http://fpaste.org/296230/89819431/ on both master
> >> and 4-2 branch.
> >>
> >
> > Rebased 556,557 in their thread, and here is the rebase for 558 on top
> > of them.
> >
> > Simo.
> >
> 
> ACK. I'm afraid that this patch and 556, 557 will require another round 
> of rebase before pushing, though.

Rebased on top of master (not on 556/557) per Petr's request.

Simo.


-- 
Simo Sorce * Red Hat, Inc * New York
From 7e94cfbaf8a11360f404fe48215ffe6c43dec94d Mon Sep 17 00:00:00 2001
From: Simo Sorce <s...@redhat.com>
Date: Tue, 24 Nov 2015 15:39:08 -0500
Subject: [PATCH] Allow admins to disable preauth for SPNs.

Some legacy softare is not able to properly cope with preauthentication,
allow the admins to disable the requirement to use preauthentication for
all Service Principal Names if they so desire. IPA Users are excluded,
for users, which use password of lessere entrpy, preauthentication is
always required by default.

This setting does NOT override explicit policies set on service principals
or in the global policy, it only affects the default.

Signed-off-by: Simo Sorce <s...@redhat.com>

Ticket: https://fedorahosted.org/freeipa/ticket/3860
---
 API.txt  |  2 +-
 daemons/ipa-kdb/ipa_kdb.c|  9 +
 daemons/ipa-kdb/ipa_kdb.h|  1 +
 daemons/ipa-kdb/ipa_kdb_principals.c | 23 +--
 ipalib/plugins/config.py |  3 ++-
 5 files changed, 30 insertions(+), 8 deletions(-)

diff --git a/API.txt b/API.txt
index e2976e0e2897355bdb7ead438d4b67524f2fb1e8..5b75413f930d0e9caaffc68023bed8106d786653 100644
--- a/API.txt
+++ b/API.txt
@@ -766,7 +766,7 @@ args: 0,25,3
 option: Str('addattr*', cli_name='addattr', exclude='webui')
 option: Flag('all', autofill=True, cli_name='all', default=False, exclude='webui')
 option: Str('delattr*', cli_name='delattr', exclude='webui')
-option: StrEnum('ipaconfigstring', attribute=True, autofill=False, cli_name='ipaconfigstring', csv=True, multivalue=True, required=False, values=(u'AllowNThash', u'KDC:Disable Last Success', u'KDC:Disable Lockout'))
+option: StrEnum('ipaconfigstring', attribute=True, autofill=False, cli_name='ipaconfigstring', csv=True, multivalue=True, required=False, values=(u'AllowNThash', u'KDC:Disable Last Success', u'KDC:Disable Lockout', u'KDC:Disable Default Preauth for SPNs'))
 option: Str('ipadefa

Re: [Freeipa-devel] Supporting UPNs of trusted forests

[Simo Sorce]

tree root may have associated name suffixes.
> 
> There are actually two different approaches we discussed with Sumit
> -- one is to store TLNs as attributes of TDO, another is to create
> separate TDOs, building on the fact you noticed:
> >Btw trustdomain object has ipantflatname and ipanttrusteddomainsid 
> >attributes as optional so it is possible to store it there assuming 
> >modification of KDB driver.
> This is what I did already in the prototype: 
> https://abbra.fedorapeople.org/.paste/0001-WIP-support-UPNs-for-trusted-domain-users.master.patch
> 
> So we are sure that either way would work, the question is what would be
> more usable UX-wise.

How does Windows represent them ?
I'd try to stick to something close to what AD does to avoid pain if
later is found that the way Windows does things is necessary (or just
easier) to keep adding further options down the road.

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators

[Simo Sorce]

On Fri, 2016-02-26 at 15:44 -0500, Nathaniel McCallum wrote:
> On Fri, 2016-02-26 at 11:20 -0500, Simo Sorce wrote:
> > On Fri, 2016-02-26 at 10:24 -0500, Nathaniel McCallum wrote:
> > > I was thinking:
> > > 1. Bind as the entity validating the 2nd factor.
> > > 2. Extop which takes the:
> > >* user dn
> > >* type of 2nd factor
> > >* validation data
> > >* dn of 2nd factor (optional)
> > > 
> > > This provides an audit trail of who is validating 2nd factors.
> > Ok, this makes sense.
> > I wish we didn't have to create yet another extop, but if we want to
> > gate the check via another bind it makes sense.
> 
> I wish we had done this the first time. However, this really only makes
> complete sense in a post-SPAKE world.
> 
> I actually think we should have a different extop for each 2F type.
> Each 2F type can define its own interface (and possibly more than one
> round-trip; such as token sync).

Not sure about this.

> > > > > I'm thus not sure if we'll ever add more second factors to the
> > > > > existing
> > > > > simple bind mechanism.
> > > > LDAP binds still need to test both factors if they are required
> > > > ...
> > > We would grandfather OTP. But all new 2FA would require GSSAPI
> > > (using
> > > AIs) to use LDAP.
> > I do not think we can enforce this, we still have a lot of
> > deployments
> > that rely on LDAP binds to check credentials, and we should try to
> > support this as much as possible.
> 
> Consider the case of U2F. I don't think we can ever support LDAP simple
> bind with U2F. And I think U2F will be supported long before anything
> else.

For things like U2F it may make more sense to develop a SASL mechanism,
we use SASL for GSSAPI too.

> > > > > > - Even if ipa-otpd will not grow such a feature, I see this
> > > > > > control
> > > > > > could be useful for pure LDAP auth clients, so perhaps a
> > > > > > different
> > > > > > kind
> > > > > > of client may want to set this control ? Perhaps one day we
> > > > > > can
> > > > > > have
> > > > > > a
> > > > > > way to do GSSAPI auth and check that the AI on the ldap
> > > > > > ticket
> > > > > > was a
> > > > > > 2FA
> > > > > > and then DS will refuse login if the otp AI was missing on
> > > > > > the
> > > > > > ticket
> > > > > > it
> > > > > > received and the control requires it ? (could be used for the
> > > > > > IPA
> > > > > > UI
> > > > > > connection to LDAP maybe ?)
> > > > > That seems to me like a decision LDAP can make internally. No?
> > > > Not if the user has optional 2FA and you want to enforce the
> > > > second
> > > > factor only for certain operations from the framework (like say
> > > > changing
> > > > passwords or other more privileged operations).
> > > Why can't we just use GSSAPI with AIs?
> > We would! But the AI check would be done (optionally) for the LDAP
> > server, not the HTTP service, remember that we do s4u2proxy and use
> > GSSAPI auth from the framework.
> 
> I'm missing something here.

The idea is that the framework may use the control that the server
should fail the bind if 2FA AI is not present on the ticket and re-bind
to LDAP before performing a high privilege operation. The bind would
fail if the required AI is not present and the higher priv. operation
would fail. for normally privileged operation (like listing users) the
control 2 require OTP AI wouldn't be sent so a bind would succeed even
if original credentials were 1FA.

Hope this makes it more clear.

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] URI in HBAC rules - patch - request for feedback

[Simo Sorce]

On Fri, 2016-02-26 at 17:17 +0100, Jakub Hrozek wrote:
> On Fri, Feb 26, 2016 at 10:58:57AM -0500, Simo Sorce wrote:
> > On Fri, 2016-02-26 at 13:17 +0100, Lukáš Hellebrandt wrote:
> > > Hi, FreeIPA and SSSD communities!
> > > 
> > > I am working on adding URI to HBAC as my thesis [1]. The goal is to
> > > control access not only based on (user, host, service), but on (user,
> > > host, service, resource's URI).
> > > 
> > > I created a patch for FreeIPA [2] so it is capable of storing URI as
> > > part of HBAC rule. I created a patch for SSSD [3] so it is able to get
> > > this URI from FreeIPA and use it in HBAC evaluation.
> > > 
> > > I still need to develop a part of SSSD receiving URI-aware requests. It
> > > will either be an enhancement of Infopipe or I will use PAM responder
> > > (any suggestions?).
> > > 
> > > I wanted to kindly ask you for review and your opinions on the patches
> > > and generally on my approach. This would be my first contribution to
> > > FreeIPA and SSSD so there might be bugs. What do you think?
> > > 
> > > Btw, is there some better place to share patches than a pasting tool?
> > > Maybe some form of pull request?
> > > 
> > > Thanks for your opinions!
> > > 
> > > [1]
> > > https://diplomky.redhat.com/topic/show/326/store-and-manage-access-to-uris-in-freeipa
> > > [2]
> > > http://pastebin.com/rsHzXeAR
> > > [3]
> > > http://pastebin.com/atcZMuP1
> > > 
> > 
> > Hi Lukas, could please post your patches here using git-format-patch or
> > even better provide a public git tree with them applied ?
> > (Any place github, fedorapeople, your own server, etc. is fine)
> > 
> > 
> > First a question, what service can actually use this scheme and how ?
> > there is no URL field in PAM.
> 
> When Lukas started the work, we IIRC concluded that PAM is not an
> appropriate interface and we should probably expose some DBUS methods
> for access control. We haven't really discussed any details since then.

This only shifts the question, what service would use this interface ?
note I am not opposed to it, but would like to understand how we are
going to test that it actually works and is useful.

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators

[Simo Sorce]

On Fri, 2016-02-26 at 10:24 -0500, Nathaniel McCallum wrote:
> On Fri, 2016-02-26 at 10:12 -0500, Simo Sorce wrote:
> > On Fri, 2016-02-26 at 09:30 -0500, Nathaniel McCallum wrote:
> > > 
> > > On Thu, 2016-02-25 at 16:51 -0500, Simo Sorce wrote:
> > > > Questions:
> > > > - Should the control specify what kind of auth specifically
> > > > should be
> > > > required ?
> > > I had also wondered that. I'm certainly not against it. But I'd
> > > probably prefer a simple utf8 string value to avoid parsing
> > > complexity.
> > > 
> > > > 
> > > > - Will it make sense in future to have different strength otp-
> > > > like
> > > > second factors and have ipa-otpd be able to specify which one it
> > > > is
> > > > expecting to be validated ?
> > > I'm personally hoping that we can deprecate ipa-otpd after SPAKE
> > > lands.
> > > Post-SPAKE validations will require a method for validating OTP-
> > > only
> > > (excluding password). This will probably be an extop. The same will
> > > be
> > > true for all new second factors.
> > Why an extop ? I was thinking you'd do a bind with this same control
> > with a string that specifies you want to check only the second
> > factor.
> > (The result of the bind will be positive but you won't be logged in
> > as
> > the user the connection will still be marked anonymous.)
> 
> How can you do this anonymously?

The bind is not done anonymously, but the outcome of the bind operation
is that the user DS sees is the anonymous user (because you didn't use
the first factor at all).

>  You need to know which tokens to
> validate. This requires a user dn.

Sure this is a different concern, I was concerned about the outcome of
the bind operation not its setup.

>  Besides, I would think we also want
> to be bound *before* performing this operation. Otherwise, we could
> allow brute force tries on the 2nd factor.

Yes, this is a concern, but only with HOTP, with TOTP, you cannot really
brute force easily as you have to wait 30 sec. between each try
(assuming we mark the current OTP has been used and immediately return
an error on any further attempt ?)

We can also still lock the user account if too many attempts are
performed.

However it is a concern indeed.

> I was thinking:
> 1. Bind as the entity validating the 2nd factor.
> 2. Extop which takes the:
>* user dn
>* type of 2nd factor
>* validation data
>* dn of 2nd factor (optional)
> 
> This provides an audit trail of who is validating 2nd factors.

Ok, this makes sense.
I wish we didn't have to create yet another extop, but if we want to
gate the check via another bind it makes sense.

> > > I'm thus not sure if we'll ever add more second factors to the
> > > existing
> > > simple bind mechanism.
> > LDAP binds still need to test both factors if they are required ...
> 
> We would grandfather OTP. But all new 2FA would require GSSAPI (using
> AIs) to use LDAP.

I do not think we can enforce this, we still have a lot of deployments
that rely on LDAP binds to check credentials, and we should try to
support this as much as possible.

> > > > - Even if ipa-otpd will not grow such a feature, I see this
> > > > control
> > > > could be useful for pure LDAP auth clients, so perhaps a
> > > > different
> > > > kind
> > > > of client may want to set this control ? Perhaps one day we can
> > > > have
> > > > a
> > > > way to do GSSAPI auth and check that the AI on the ldap ticket
> > > > was a
> > > > 2FA
> > > > and then DS will refuse login if the otp AI was missing on the
> > > > ticket
> > > > it
> > > > received and the control requires it ? (could be used for the IPA
> > > > UI
> > > > connection to LDAP maybe ?)
> > > That seems to me like a decision LDAP can make internally. No?
> > Not if the user has optional 2FA and you want to enforce the second
> > factor only for certain operations from the framework (like say
> > changing
> > passwords or other more privileged operations).
> 
> Why can't we just use GSSAPI with AIs?

We would! But the AI check would be done (optionally) for the LDAP
server, not the HTTP service, remember that we do s4u2proxy and use
GSSAPI auth from the framework.

Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] URI in HBAC rules - patch - request for feedback

[Simo Sorce]

On Fri, 2016-02-26 at 13:17 +0100, Lukáš Hellebrandt wrote:
> Hi, FreeIPA and SSSD communities!
> 
> I am working on adding URI to HBAC as my thesis [1]. The goal is to
> control access not only based on (user, host, service), but on (user,
> host, service, resource's URI).
> 
> I created a patch for FreeIPA [2] so it is capable of storing URI as
> part of HBAC rule. I created a patch for SSSD [3] so it is able to get
> this URI from FreeIPA and use it in HBAC evaluation.
> 
> I still need to develop a part of SSSD receiving URI-aware requests. It
> will either be an enhancement of Infopipe or I will use PAM responder
> (any suggestions?).
> 
> I wanted to kindly ask you for review and your opinions on the patches
> and generally on my approach. This would be my first contribution to
> FreeIPA and SSSD so there might be bugs. What do you think?
> 
> Btw, is there some better place to share patches than a pasting tool?
> Maybe some form of pull request?
> 
> Thanks for your opinions!
> 
> [1]
> https://diplomky.redhat.com/topic/show/326/store-and-manage-access-to-uris-in-freeipa
> [2]
> http://pastebin.com/rsHzXeAR
> [3]
> http://pastebin.com/atcZMuP1
> 

Hi Lukas, could please post your patches here using git-format-patch or
even better provide a public git tree with them applied ?
(Any place github, fedorapeople, your own server, etc. is fine)


First a question, what service can actually use this scheme and how ?
there is no URL field in PAM.


On the patches:

[2] you define a new attribute Url which is fine, but the actual
attribute is not ok in several way.

- You assigned an OID from a hole in the IPAv2 Attibutes space, it
should be an assigned ID from the IPAv3 attribute space instead

- You do not namespace the attribute, it should at least be ipaUrl 

- you are using case Exact matching, is this intentional? Are the URIs
in there case sensitive strings ?

- there is an available attribute called labeledURI (with alias
labeledurl) in the standard schema (however I notice it also has
caseExactMatch) that has basically the same definition of your Url
attribute, why not use that one ?

[3] If I read the patch correctly failing to find a Url is a fatal
condition, this is not ok as it would fail to operate with older servers
that do not have a url on the rules.


It is not clear to me what happen on an older client if URL is used but
not the service? Or is service always enforced ? (It is not clear to me
that it is).


HTH,
Simo.

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

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators

[Simo Sorce]

On Fri, 2016-02-26 at 09:30 -0500, Nathaniel McCallum wrote:
> On Thu, 2016-02-25 at 16:51 -0500, Simo Sorce wrote:
> > On Thu, 2016-02-25 at 16:13 -0500, Nathaniel McCallum wrote:
> > > 
> > > On Thu, 2016-02-25 at 12:19 -0500, Nathaniel McCallum wrote:
> > > > 
> > > > On Thu, 2016-02-25 at 10:49 -0500, Simo Sorce wrote:
> > > > > 
> > > > > 
> > > > > On Thu, 2016-02-25 at 10:32 -0500, Nathaniel McCallum wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Wed, 2016-02-24 at 09:55 -0500, Nathaniel McCallum wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On Sun, 2016-02-21 at 20:50 -0500, Simo Sorce wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Sun, 2016-02-21 at 20:20 -0500, Nathaniel McCallum
> > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > https://github.com/npmccallum/freeipa/pull/1
> > > > > > > > > 
> > > > > > > > > The above (pseudo) pull request contains four patches
> > > > > > > > > against
> > > > > > > > > FreeIPA
> > > > > > > > > to enable the insertion of Authentication Indicators
> > > > > > > > > into
> > > > > > > > > Kerberos
> > > > > > > > > tickets. The basic flow looks like this.
> > > > > > > > > 
> > > > > > > > > First, we patch ipa-pwd-extop to return a control
> > > > > > > > > indicating
> > > > > > > > > what
> > > > > > > > > authentication method succeeded resulting in a
> > > > > > > > > successful
> > > > > > > > > bind.
> > > > > > > > > 
> > > > > > > > > Second, we patch ipa-otpd to check the returned control
> > > > > > > > > to
> > > > > > > > > ensure
> > > > > > > > > that
> > > > > > > > > the bind resulted from an otp validation.
> > > > > > > > > 
> > > > > > > > > Third, we patch ipa-kdb to enable the KDC to return
> > > > > > > > > either
> > > > > > > > > the
> > > > > > > > > encrypted timestamp or encrypted challenge preauth
> > > > > > > > > mechanism
> > > > > > > > > when
> > > > > > > > > the
> > > > > > > > > user is configured for optional 2FA logins. Clients can
> > > > > > > > > then
> > > > > > > > > decide
> > > > > > > > > whether to do 1FA or 2FA login (for kinit, sane
> > > > > > > > > behavior
> > > > > > > > > already
> > > > > > > > > exists).
> > > > > > > > > 
> > > > > > > > > Forth, we patch ipa-kdb again to insert hard-coded
> > > > > > > > > authentication
> > > > > > > > > indicators for either OTP or RADIUS.
> > > > > > > > > 
> > > > > > > > > Some explanation is required for the first two patches.
> > > > > > > > > Currently,
> > > > > > > > > it
> > > > > > > > > is possible to do a 1FA through the otp
> > > > > > > > > preauthentication
> > > > > > > > > mechanism
> > > > > > > > > if
> > > > > > > > > the user is configured for doing optional 2FA. However,
> > > > > > > > > because
> > > > > > > > > we
> > > > > > > > > want
> > > > > > > > > to insert an authentication indicator in this co

Re: [Freeipa-devel] [REVIEW] Intial stab towards Authentication Indicators

[Simo Sorce]

On Thu, 2016-02-25 at 16:13 -0500, Nathaniel McCallum wrote:
> On Thu, 2016-02-25 at 12:19 -0500, Nathaniel McCallum wrote:
> > On Thu, 2016-02-25 at 10:49 -0500, Simo Sorce wrote:
> > > 
> > > On Thu, 2016-02-25 at 10:32 -0500, Nathaniel McCallum wrote:
> > > > 
> > > > 
> > > > On Wed, 2016-02-24 at 09:55 -0500, Nathaniel McCallum wrote:
> > > > > 
> > > > > 
> > > > > On Sun, 2016-02-21 at 20:50 -0500, Simo Sorce wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Sun, 2016-02-21 at 20:20 -0500, Nathaniel McCallum wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > https://github.com/npmccallum/freeipa/pull/1
> > > > > > > 
> > > > > > > The above (pseudo) pull request contains four patches
> > > > > > > against
> > > > > > > FreeIPA
> > > > > > > to enable the insertion of Authentication Indicators into
> > > > > > > Kerberos
> > > > > > > tickets. The basic flow looks like this.
> > > > > > > 
> > > > > > > First, we patch ipa-pwd-extop to return a control
> > > > > > > indicating
> > > > > > > what
> > > > > > > authentication method succeeded resulting in a successful
> > > > > > > bind.
> > > > > > > 
> > > > > > > Second, we patch ipa-otpd to check the returned control to
> > > > > > > ensure
> > > > > > > that
> > > > > > > the bind resulted from an otp validation.
> > > > > > > 
> > > > > > > Third, we patch ipa-kdb to enable the KDC to return either
> > > > > > > the
> > > > > > > encrypted timestamp or encrypted challenge preauth
> > > > > > > mechanism
> > > > > > > when
> > > > > > > the
> > > > > > > user is configured for optional 2FA logins. Clients can
> > > > > > > then
> > > > > > > decide
> > > > > > > whether to do 1FA or 2FA login (for kinit, sane behavior
> > > > > > > already
> > > > > > > exists).
> > > > > > > 
> > > > > > > Forth, we patch ipa-kdb again to insert hard-coded
> > > > > > > authentication
> > > > > > > indicators for either OTP or RADIUS.
> > > > > > > 
> > > > > > > Some explanation is required for the first two patches.
> > > > > > > Currently,
> > > > > > > it
> > > > > > > is possible to do a 1FA through the otp preauthentication
> > > > > > > mechanism
> > > > > > > if
> > > > > > > the user is configured for doing optional 2FA. However,
> > > > > > > because
> > > > > > > we
> > > > > > > want
> > > > > > > to insert an authentication indicator in this code path, we
> > > > > > > need
> > > > > > > to
> > > > > > > guarantee that a request going through the otp preauth
> > > > > > > mechanism
> > > > > > > actually validates an OTP. This is the purpose of the
> > > > > > > control.
> > > > > > > 
> > > > > > > Items still on the TODO list:
> > > > > > > 
> > > > > > >   * Authentication Indicator enforcement
> > > > > > > - Upstream libkrb5 needs to grow funcs for reading
> > > > > > > indicators
> > > > > > > - Schema change to add indicators multi-value attr to
> > > > > > > services
> > > > > > > - ipa-kdb needs to implement check_policy_tgs()
> > > > > > > 
> > > > > > > 
> > > > > > >   * SSSD needs to learn to handle optional 2FA
> > > > > > > 
> > > > > > > I will write up a project page for all of this tomorrow.
> > > > > > > But
> > > > > > > this
> > > > > > > small
> >