Re: Configuration Files. Was Re: Newbie with a base suffix searching problem

["Kurt D. Zeilenga" <Kurt@openldap.org>]

At 03:23 PM 12/30/98 -0800, Greg Retkowski wrote:
>Perhaps pam_ldap and nss_ldap should split of their application-specific
>data to another file

In my view, they are separate:
	/etc/ldap/ldap.conf -> pam_ldap/nss_ldap configuration settings
	$sysconfdir/openldap/ldap.conf -> OpenLDAP session defaults

Note: The administrator may want to a particular basedn (or any
other configuration variable) for specific applications that
differ from the session defaults.  This is why it is important to
separate session defaults from per-application and, in some cases,
per-operation settings.

I believe that all applications requiring external configuration
information should create a separate and distinct file.  (or better
yet, fetch their configuration information from the directory).

>however I think
>ldap.conf also needs to be expanded to include a few more attibutes that
>are dependant on the directory, not the application... LDAP-aware
>applications should get basic LDAP configration information from it.
>
>scope one|sub|base	The default search scope

scope is a per-search operation setting that must be set in the
context of the application.  I recommend applications wanting to
externalize search parameters use the ldap_getfilter(3) mechanism.
A separate filter file (from ldapfilter.conf) should be considered
for separately packaged applications.

>crypt md5|sha|des|none	applications should be told the preferred
>			password encryption logarithm for the server.

Very few applications need to know such details of the server's
configuration.  Personally, I think this info should be set in
slapd.conf and provided to clients as attributes of 'cn=config'.

>Perhaps something should be added to the LDAP API to abstract the physical
>location of this data.

I was actually thinking of externalizing our initialization routines
and require an explicit call of an initialization routine (for
applications desiring such defaulting).   Some developers might find
it odd for the library to implicitly set such defaults.

Long term, I'd like to use LDIF format files for basic configuration
information and store the rest in the directory itself.

>> It would be pretty easy to implement acl's which used UID information
>> fetched with RFC1423 (pidentd())...
>That would be a neet feature, although I'd still want a tight
>authentication scheme for the really sensitive stuff.

Agreed, this is why I said "to implement acl's".  I do not believe it wise
to rely on RFC1423 for authentication (though one could easily implement
such a mechanism).  I believe the RFC1423 information is more suitably
used for access control (similar to how you can use domain and
ip address information in acls).  Basically, we would add some additional
qualifiers (or one overloaded one).
	ident-uid=2			# match uid 2
	ident-user=greg		# match user greg
	ident-gid=5			# match gid 5
	...
or something like:
	ident(",%L,")=", *wheel *," # match group 'wheel'

Of course, adding support to additional ACL qualifiers is actually quite
straight forward (assuming the require information is readily available)...
using them in sensible ways is the challedge.

>Would it be trivial
>to expand the LDAP ACL's to who you are _and_ how you authenticated?

We could add a authmethod=<METHOD>;<level> qualifier and then
you could use 'authmethod=.*;weak' or 'authmethod=KERBEROS.*;.*' or
'authmethod=SASL-.*;strong'  This could be used, say, to give write
access to only those authenticated with strong methods, read or none
to weak ones.  This could be very useful.

>PS. Where can I find documentation on the group acl syntax? I've looked
>around but failed to come up with anything.

I really should put this into the FAQ...

access to *
  by group="cn=Administrators,dc=domain,dc=com" write
  by * read