Dear list!
Is there any way to specify sasl-secprops separately for each transport type? For ldapi:/// is want "sasl-secprops noanonymous,noplain", and "sasl-secprops noanonymous,noplain,noactive" for the rest.
The idea is to require SASL GSSAPI for everyone with only exception for clients connecting via ldapi (like heimdal KDC) - they need SASL EXTERNAL.
On Thursday 26 October 2006 03:49, Hai Zaar wrote:
Dear list!
Is there any way to specify sasl-secprops separately for each transport type? For ldapi:/// is want "sasl-secprops noanonymous,noplain", and "sasl-secprops noanonymous,noplain,noactive" for the rest.
The idea is to require SASL GSSAPI for everyone with only exception for clients connecting via ldapi (like heimdal KDC) - they need SASL EXTERNAL.
Why don't you just remove the SASL mechanisms you don't want? The SASL/EXTERNAL will always be there but the others are just shared libraries which live in /usr/lib/sasl2 or something similar (at least on my system). The slapd won't offer any mechanism which isn't installed.
Karsten.
Why don't you just remove the SASL mechanisms you don't want? The SASL/EXTERNAL will always be there
Does not look like that - if I set "sasl-secprops noanonymous,noplain,noactive" then heimdal-kdc, which uses SASL/EXTERNAL over slapi fails to connect (removing 'noactive' solves that).
Karsten.
Hai Zaar wrote:
Why don't you just remove the SASL mechanisms you don't want? The SASL/EXTERNAL will always be there
Does not look like that - if I set "sasl-secprops noanonymous,noplain,noactive" then heimdal-kdc, which uses SASL/EXTERNAL over slapi fails to connect (removing 'noactive' solves that).
You're missing the point. Leave the sasl-secprops at their default setting and just remove the modules for the SASL mechanisms that you don't want to allow.
On Thursday 26 October 2006 09:48, Hai Zaar wrote:
Why don't you just remove the SASL mechanisms you don't want? The SASL/EXTERNAL will always be there
Does not look like that - if I set "sasl-secprops noanonymous,noplain,noactive" then heimdal-kdc, which uses SASL/EXTERNAL over slapi fails to connect (removing 'noactive' solves that).
I'm not talking about sasl-secprops but deinstalling the unneeded SASL mechanisms and leave only SASL/GSSAPI installed. Then you'll have SASL/GSSAPI and SASL/EXTERNAL, but SASL/EXTERNAL will only show up if you connect via ldapi or use SSL/TLS. I thought that's what you wanted.
Karsten.
Why don't you just remove the SASL mechanisms you don't want? The SASL/EXTERNAL will always be there
Does not look like that - if I set "sasl-secprops noanonymous,noplain,noactive" then heimdal-kdc, which uses SASL/EXTERNAL over slapi fails to connect (removing 'noactive' solves that).
Rather then removing the mechanism libraries from your system, you can just limit the available mechanisms for your application, by setting mech_list: GSSAPI EXTERNAL in your sasl configuration file for slapd (likely /usr/lib/sasl2/slapd.conf).
openldap-software@openldap.org
-
Hai Zaar -
Howard Chu -
Karsten Künne -
Norbert Klasen