Is there support in certmap.conf for using DN's with dc= attributes

Hi Folks-

The Question:

Is there any support on certmap.conf (or the like) for dealing with suffixes that use the "dc=example,dc=com" format (in either 5.2 or 6.0)?

The Details/Background:

Like many places our suffixes are named ending with "dc" attributes (e.g. dc=example,dc=com). I've been setting up SSL Client Certificate based authentication. It's working via the CmapLdapAttr with a custom attribute/class added to the schema (I haven't finished with VerifyCert yet).

The docs say that DNComps and FilterComps support the following RDN keywords: cn, ou, o, c, l, st, e, and mail. Notably missing from both is "dc". This seems to leave no valid value for DNComps (forcing all the searches to be across ALL suffixes including cn=config and co). With those global searches FilterComps also seems to be fairly limited (especially if uid is not part of the Certificate's Subject DN which it arguably shouldn't be in many situations).

It seems all I'm left with is CmapLdapAttr (after creating the custom attribute & class) with every search across all suffixes. I don't think I can (or should) place indexes in the stuff in dse.ldif, hopefully they won't stop the other suffixes to be searched using their indexes and these should be small enough (and hopefully in memory) that they don't make a real difference.

Thanks,

-Scott-

[1398 byte] By [Scott.R.Corzinea] at [2007-11-27 5:18:00]
# 1
I believe the bug is still opened and dc is not yet supported for certmap.conf.For sure, it is not fixed in 5.2patchX.Ludovic.
ludovicpa at 2007-7-12 10:40:58 > top of Java-index,Web & Directory Servers,Directory Servers...
# 2

Ok, so as far as I can tell that just leaves using "CmapLdapAttr" with a custom attribute (& class) extension to the schema.

Since I won't be able to restrict the suffix being searched it's going to do at least 6 separate scans: one each on userRoot (and any other user suffixes), NetscapeRoot, "", cn=schema, cn=config, and cn=monitor (based on what it's reported in the logs already).

(1) Am I correct in my assumption that creating indexes on attributes in the suffixes in dse.ldif is probably not possible and would be a bad idea?

My guess is that everything in dse.ldif gets loaded into memory on startup and stays there. Also these aren't that big so the combination should mean that their search time is negligible.

(2) When automatically searching all 6+ suffixes (on every client certificate authenticated connection) will it perform indexed searches on userRoot & NetscapeRoot (assuming the correct indexes exist for CmapLdapAttr) and unindexed searches for the suffixes in dse.ldif? Or will the lack of indexes in the dse.ldif suffixes cause all of the searches to be unindexed?

(3) Is there something I'm missing that would be a better approach?

Thanks,

-Scott-

Scott.R.Corzinea at 2007-7-12 10:40:58 > top of Java-index,Web & Directory Servers,Directory Servers...