Config options for IPA provider

[Sumit Bose]

Hi,

the IPA provider has its own set of config options:

- ipa_domain
- ipa_server
- ipa_hostname

in the most simple case only ipa_server is needed. (If we can resolve
service records we wouldn't even need this.)

Behind the scenes the IPA provider is the LDAP identity provider glued
together with the Kerberos authentication/change password provider and
an IPA specific access provider.

The options for the LDAP and Kerberos provider are set to defaults that
will work with an IPAv2 server in a secure way.

As documented in the man page it is possible to set LDAP or Kerberos
specific options to override the defaults set by the IPA provider. While
this makes sense e.g. for the timeout options there are other cases,
especially for the LDAP provider, where is doesn't. So it is possible to
set ldap_id_use_start_tls to true which is kind of useless and has
performance penalties, because the communication is already protected by
GSSAPI. Or it would be possible to disable GSSAPI by setting
ldap_sasl_mech to none.

So the question arises how to handle this situation?
- Shall we keep everything as it is and only update the man page to
  underline that the default configuration is secure and you really only
  need the ipa_* options?
- Shall we stop parsing ldap_* and krb5_* options and introduce ipa_*
  options for timeouts and other useful options?
- Shall we start reading the config from the IPA server only?
- Shall we do sometime completely different?

Comments?

bye,
Sumit

[Jakub Hrozek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/16/2010 01:51 PM, Sumit Bose wrote:
>  in the most simple case only ipa_server is needed. (If we can
> resolve
>  service records we wouldn't even need this.) 
Related question: when resolving service records, should ipa_domain be
required? Or should we try machine's domain name?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkvIVi8ACgkQHsardTLnvCXEGwCeNlHJ+mB/lBJsVBXB3QTjWcmy
> CT4An3Zr1RhZFx+U1PIySR5siqs7tMwZ
> =S08+
> -----END PGP SIGNATURE-----

[Sumit Bose]

On Fri, Apr 16, 2010 at 02:21:03PM +0200, Jakub Hrozek wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>  
>  On 04/16/2010 01:51 PM, Sumit Bose wrote:
>  > in the most simple case only ipa_server is needed. (If we can resolve
>  > service records we wouldn't even need this.)
>  
>  Related question: when resolving service records, should ipa_domain be
>  required? Or should we try machine's domain name? 
no, we take the name of the sssd domain:

[domain/ipa.test]
id_provider = ipa

the domain name is ipa.test.

bye,
Sumit

> >  -----BEGIN PGP SIGNATURE-----
> >  Version: GnuPG v1.4.10 (GNU/Linux)
> >  Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
> >  
> >  iEYEARECAAYFAkvIVi8ACgkQHsardTLnvCXEGwCeNlHJ+mB/lBJsVBXB3QTjWcmy
> >  CT4An3Zr1RhZFx+U1PIySR5siqs7tMwZ
> >  =S08+
> >  -----END PGP SIGNATURE----- 
>  _______________________________________________
>  sssd-devel mailing list
>  sssd-devel(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/sssd-devel

[Simo Sorce]

On Fri, 16 Apr 2010 13:51:49 +0200
Sumit Bose <sbose(a)redhat.com&gt; wrote:

>  Hi,
>  
>  the IPA provider has its own set of config options:
>  
>  - ipa_domain
>  - ipa_server
>  - ipa_hostname
>  
>  in the most simple case only ipa_server is needed. (If we can resolve
>  service records we wouldn't even need this.)
>  
>  Behind the scenes the IPA provider is the LDAP identity provider glued
>  together with the Kerberos authentication/change password provider and
>  an IPA specific access provider.
>  
>  The options for the LDAP and Kerberos provider are set to defaults
>  that will work with an IPAv2 server in a secure way.
>  
>  As documented in the man page it is possible to set LDAP or Kerberos
>  specific options to override the defaults set by the IPA provider.
>  While this makes sense e.g. for the timeout options there are other
>  cases, especially for the LDAP provider, where is doesn't. So it is
>  possible to set ldap_id_use_start_tls to true which is kind of
>  useless and has performance penalties, because the communication is
>  already protected by GSSAPI. Or it would be possible to disable
>  GSSAPI by setting ldap_sasl_mech to none.
>  
>  So the question arises how to handle this situation?
>  - Shall we keep everything as it is and only update the man page to
>    underline that the default configuration is secure and you really
>  only need the ipa_* options? 
This would probably be a good idea.

>  - Shall we stop parsing ldap_* and krb5_* options and introduce
> ipa_*
>    options for timeouts and other useful options? 
No, I think it would cause a lot more issues, as we will certainly
forget to create/modify the corresponding ipa_ options when we
create/modify ldap_ or krb5_ options.

I think we shouldn't shoot ourselves in the feet just because we fear
someone is going to misconfigure their installation.
Very persistent users would always be able to misconfigure their system
anyway :)

>  - Shall we start reading the config from the IPA server only? 
At some point we want to read the config out of the IPA server, but we
want to keep reading local options as "overrides".

>  - Shall we do sometime completely different? 
I think this is a thunderstorm in a tea cup :-)
We should reasonably prevent users from shooting their feet, but this
is going beyond that. Let's just make it clear in the docs that a
normal installation doesn't require to specify any ldap_ or krb5_
options to operate correctly. If a user insists then they will get what
they ask for.

Simo.

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

[Stephen Gallagher]

On 04/16/2010 09:36 AM, Simo Sorce wrote:
>  On Fri, 16 Apr 2010 13:51:49 +0200
>  Sumit Bose<sbose(a)redhat.com>  wrote:
>
> > Hi,
> >
> > the IPA provider has its own set of config options:
> >
> > - ipa_domain
> > - ipa_server
> > - ipa_hostname
> >
> > in the most simple case only ipa_server is needed. (If we can resolve
> > service records we wouldn't even need this.)
> >
> > Behind the scenes the IPA provider is the LDAP identity provider glued
> > together with the Kerberos authentication/change password provider and
> > an IPA specific access provider.
> >
> > The options for the LDAP and Kerberos provider are set to defaults
> > that will work with an IPAv2 server in a secure way.
> >
> > As documented in the man page it is possible to set LDAP or Kerberos
> > specific options to override the defaults set by the IPA provider.
> > While this makes sense e.g. for the timeout options there are other
> > cases, especially for the LDAP provider, where is doesn't. So it is
> > possible to set ldap_id_use_start_tls to true which is kind of
> > useless and has performance penalties, because the communication is
> > already protected by GSSAPI. Or it would be possible to disable
> > GSSAPI by setting ldap_sasl_mech to none.
> >
> > So the question arises how to handle this situation?
> > - Shall we keep everything as it is and only update the man page to
> >    underline that the default configuration is secure and you really
> > only need the ipa_* options?
>
>  This would probably be a good idea.
>
> > - Shall we stop parsing ldap_* and krb5_* options and introduce ipa_*
> >    options for timeouts and other useful options?
>
>  No, I think it would cause a lot more issues, as we will certainly
>  forget to create/modify the corresponding ipa_ options when we
>  create/modify ldap_ or krb5_ options.
>
>  I think we shouldn't shoot ourselves in the feet just because we fear
>  someone is going to misconfigure their installation.
>  Very persistent users would always be able to misconfigure their system
>  anyway :)
>
> > - Shall we start reading the config from the IPA server only?
>
>  At some point we want to read the config out of the IPA server, but we
>  want to keep reading local options as "overrides".
>
> > - Shall we do sometime completely different?
>
>  I think this is a thunderstorm in a tea cup :-)
>  We should reasonably prevent users from shooting their feet, but this
>  is going beyond that. Let's just make it clear in the docs that a
>  normal installation doesn't require to specify any ldap_ or krb5_
>  options to operate correctly. If a user insists then they will get what
>  they ask for.
>
>  Simo.
>  
Simo makes some strong arguments. I think he's right that we should just 
be more clear in the manpages and leave things as-is.


-- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/

[Dmitri Pal]

Stephen Gallagher wrote:
>  On 04/16/2010 09:36 AM, Simo Sorce wrote:
>    
> > On Fri, 16 Apr 2010 13:51:49 +0200
> > Sumit Bose<sbose(a)redhat.com>  wrote:
> >
> >     
> >> Hi,
> >>
> >> the IPA provider has its own set of config options:
> >>
> >> - ipa_domain
> >> - ipa_server
> >> - ipa_hostname
> >>
> >> in the most simple case only ipa_server is needed. (If we can resolve
> >> service records we wouldn't even need this.)
> >>
> >> Behind the scenes the IPA provider is the LDAP identity provider glued
> >> together with the Kerberos authentication/change password provider and
> >> an IPA specific access provider.
> >>
> >> The options for the LDAP and Kerberos provider are set to defaults
> >> that will work with an IPAv2 server in a secure way.
> >>
> >> As documented in the man page it is possible to set LDAP or Kerberos
> >> specific options to override the defaults set by the IPA provider.
> >> While this makes sense e.g. for the timeout options there are other
> >> cases, especially for the LDAP provider, where is doesn't. So it is
> >> possible to set ldap_id_use_start_tls to true which is kind of
> >> useless and has performance penalties, because the communication is
> >> already protected by GSSAPI. Or it would be possible to disable
> >> GSSAPI by setting ldap_sasl_mech to none.
> >>
> >> So the question arises how to handle this situation?
> >> - Shall we keep everything as it is and only update the man page to
> >>    underline that the default configuration is secure and you really
> >> only need the ipa_* options?
> >>       
> > This would probably be a good idea.
> >
> >     
> >> - Shall we stop parsing ldap_* and krb5_* options and introduce ipa_*
> >>    options for timeouts and other useful options?
> >>       
> > No, I think it would cause a lot more issues, as we will certainly
> > forget to create/modify the corresponding ipa_ options when we
> > create/modify ldap_ or krb5_ options.
> >
> > I think we shouldn't shoot ourselves in the feet just because we fear
> > someone is going to misconfigure their installation.
> > Very persistent users would always be able to misconfigure their system
> > anyway :)
> >
> >     
> >> - Shall we start reading the config from the IPA server only?
> >>       
> > At some point we want to read the config out of the IPA server, but we
> > want to keep reading local options as "overrides".
> >
> >     
> >> - Shall we do sometime completely different?
> >>       
> > I think this is a thunderstorm in a tea cup :-)
> > We should reasonably prevent users from shooting their feet, but this
> > is going beyond that. Let's just make it clear in the docs that a
> > normal installation doesn't require to specify any ldap_ or krb5_
> > options to operate correctly. If a user insists then they will get what
> > they ask for.
> >
> > Simo.
> >
> >     
>
>  Simo makes some strong arguments. I think he's right that we should just 
>  be more clear in the manpages and leave things as-is.
>
>
>     
+1

-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/