On 09/15/2011 04:37 PM, David Partridge wrote:
Attempting to configure Certificate based authentication with SASL
such that if TLS successfully completed the user is authenticated by
certificate DN as an authenticated user without the requirement for the
corresponding DN to be present in the Directory Server.
nsslapd-sasl-force-external: on is part of the puzzle
This setting means
"force SIMPLE bind to be SASL/EXTERNAL if client cert
credentials were supplied" - there are some (broken) clients that expect
to connect with a client cert and bind with SIMPLE bind instead of
SASL/EXTERNAL and expect the directory server to use the client cert
credentials. It doesn't mean "force SASL/EXTERNAL to proceed if missing
bind DN entry".
what other SASL
mapping configurations are required to allow successful completion of
authenticated access. We can complete OU, O, C RDN values can be mapped and
certificate trust for clients properly configured, but cannot necessarily
make any mappings on certificate CN RDN values.
Example cert DN value: cn=[Lastname.Firstname.MI], OU=[Affiliation],
O=[Company Name], C=[ISO 3166 Country Code]
were OU could be multivalued in cert RDN.
There are at least two problems with 389
* certmap is not very good - would be better to just use the regex based
sasl mapping we now have
* should allow cert to map to a DN that does not have an entry
These two items are on our Roadmap
but we don't yet have
them targeted for a release.
David M. Partridge
389 users mailing list