[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Configuring Password Policy - Control not working
tj.murphy@virgin.net wrote:
I checked if the password policy control was supported
ldapsearch -x -b "" -s base "" supportedFeatures supportedControl supportedExtension
and got something like:
supportedControl: 1.3.6.1.4.1.4203.1.9.1.1
supportedControl: 2.16.840.1.113730.3.4.18
supportedControl: 2.16.840.1.113730.3.4.2
supportedControl: 1.3.6.1.4.1.4203.1.10.1
supportedControl: 1.2.840.113556.1.4.319
supportedControl: 1.2.826.0.1.334810.2.3
supportedControl: 1.2.826.0.1.3344810.2.3
supportedControl: 1.3.6.1.1.13.2
supportedControl: 1.3.6.1.1.13.1
supportedControl: 1.3.6.1.1.12
supportedExtension: 1.3.6.1.4.1.1466.20037
supportedExtension: 1.3.6.1.4.1.4203.1.11.1
supportedExtension: 1.3.6.1.4.1.4203.1.11.3
supportedFeatures: 1.3.6.1.1.14
supportedFeatures: 1.3.6.1.4.1.4203.1.5.1
supportedFeatures: 1.3.6.1.4.1.4203.1.5.2
supportedFeatures: 1.3.6.1.4.1.4203.1.5.3
supportedFeatures: 1.3.6.1.4.1.4203.1.5.4
supportedFeatures: 1.3.6.1.4.1.4203.1.5.5
but it was missing password policy control 1.3.6.1.4.1.42.2.27.8.5.1
Can anyone help explain why this is the case?
The password policy control is not advertised since the spec is still
not finalized.
My custom client is not working, I think the missing control is causing my
problems.
In an effort to figure out what was going on, I've seen people have entries in
slapd.conf like this
modulepath /usr/local/libexec/openldap
moduleload ppolicy.la
So I tried to get this working (thought it might have something to do with
dynamic support), however, I failed miserably to get /usr/local/libexec/openldap/ppolicy.
la to build.
./configure -q --with-cyrus-sasl=yes --enable-overlays=yes --enable-modules=yes
--enable-dynamic=yes
or..
./configure -q --enable-syncprov=no --enable-ppolicy=yes --enable-accesslog=yes --
with-cyrus-sasl=yes --enable-overlays=yes --enable-modules=yes --enable-
dynamic=yes
On investigation, I understand that password policy is not available as a
dynamic module (http://www.openldap.org/faq/data/cache/362.html) , modules
are only available to backends !?
No. Aside from the need for a moduleload statement, overlays (and
backends) behave the same whether built statically or dynamically. You
were fine before with the statically linked ppolicy. As for enabling it
as a dynamic module instead, see "configure --help".
My custom client provides request controls, setting the password policy control
to be critical, i.e. must be supported by the server. This is an extract
of the debug:
There's been a change in the draft; earlier versions didn't allow this
control to be Critical. The current code rejects requests with the
control marked critical, which is the error message you're seeing below.
The current draft allows the control to be marked critical, so I guess
we need to remove this error check.
do_bind
ber_scanf fmt ({imt) ber:
ber_scanf fmt (m}) ber:
=> get_ctrls
ber_scanf fmt ({m) ber:
ber_scanf fmt (b) ber:
=> get_ctrls: oid="1.3.6.1.4.1.42.2.27.8.5.1" (critical)
<= get_ctrls: n=1 rc=2 err="passwordPolicyRequest control invalid criticality"
send_ldap_result: conn=2 op=0 p=3
send_ldap_response: msgid=1 tag=97 err=2
ber_flush: 63 bytes to sd 14
do_bind: get_ctrls failed
connection_get(14): got connid=2
connection_read(14): checking for input on id=2
ber_get_next
TLS trace: SSL3 alert read:warning:close notify
The custom client receives error code 2, which I believe (from http://www.directory-
info.com/LDAP/LDAPErrorCodes.html) is:
2-> LDAP_PROTOCOL_ERROR: Indicates that the server has received an invalid
or malformed request from the client.
I would have expected error code 12 as the server didn't support the control:
12 -> LDAP_UNAVAILABLE_CRITICAL_EXTENSION: Indicates that the LDAP server
was unable to satisfy a request because one or more critical extensions
were not available. Either the server does not support the control or the
control is not appropriate for the operation type.
If anyone can help or point me in a direction where I may be able to get to
the bottom of this problem, I'd greatly appreciate it.
You received LDAP_PROTOCOL_ERROR because the ppolicy module considered
the Critical control to be a violation of the ppolicy specification.
Clearly slapd recognizes and supports the control, so
Unavailable_Critical_extension is not the appropriate response.
Your solution is to either change the client to leave Critical off, or
change the overlay code to ignore the Critical flag. Since the current
draft allows the Critical flag to be set, the latter would be more
appropriate. You should file an ITS for this so that the issue can be
tracked.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/