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 Sorce * Red Hat, Inc * New York