SASL support for kldap

[Chris Hecker]

> it but it's never used). Beyond that, we'd want to introduce a more 
> structured convention for differentiating LDAP options between the
> KDC and kadmind before introducing 13 new config parameters with
> global, KDC, and kadmind variants.

Is there a limit on the depth of the profile nesting?  In other words,
is this valid?

[dbmodules]
    ldapconf = {
        dbname = ldap
        db_library = kldap
	ldap_kadmin = {
		ldap_tls_cert_file = blah
	}
     }

I've only ever seen three levels, not four, but I'm not very experienced
here.  If it works (profile_add_relation looks like it would at a quick
glance), you could imagine reusing the same parameters and checking the
ldapconf, ldap_kadmin, and ldap_kdc levels for the most specific
version, which would get rid of a bunch of the names.

Or, were you talking about some more general solution, not sure for this
case?

> * There's also a lot of repeated code for processing these options. 
> That would need to be refactored.

Ah, I didn't look at the patch yet.

Chris



On 2011/11/14 08:42, Greg Hudson wrote:
> On 11/14/2011 12:22 AM, Chris Hecker wrote:
>> Any hope of getting this integrated into the trunk?
> 
> We have been regrettably slow about processing this work, due to
> resource constraints.  I do have some notes about it, which I should
> have sent long ago:
> 
> * There is a lot of duplication of parameter names for
> KDC/kadmind/kpasswdd.  It turns out that kpasswdd isn't a separate
> service as far as the DAL is concerned (there's a constant defined for
> it but it's never used).  Beyond that, we'd want to introduce a more
> structured convention for differentiating LDAP options between the KDC
> and kadmind before introducing 13 new config parameters with global,
> KDC, and kadmind variants.
> 
> * There's also a lot of repeated code for processing these options.
> That would need to be refactored.
> 
> * We would need to document this while integrating it, since the patch
> doesn't include amendments to our texinfo documentation (or the RST
> conversion of it).
> 
> * We would need to test this, at least manually, while integrating it,
> which requires a fair amount of spin-up time on OpenLDAP setup.  (Adding
> automated testing for the LDAP back end is on my private hit list for
> 1.11, but I don't know if testing SASL access is likely to be feasible
> when I do that.)
>