[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Configuring Password Policy - Control not working

Thanks Howard for help. Changed the control from critical to non
critical and got a step further. Think there is still something wrong
with my configuration as no control response is returned.

I ran an ldapsearch with -e ppolicy option

ldapsearch -x -b "dc=example,dc=org" -e ppolicy objectclass=myUser

and got the following response
slap_global_control: unavailable control: 1.3.6.1.4.1.42.2.27.8.5.1

Full log below....

slapd startup: initiated.
backend_startup_one: starting "cn=config"
config_back_db_open
config_build_entry: "cn=config"
config_build_entry: "cn=include{0}"
config_build_entry: "cn=include{1}"
config_build_entry: "cn=include{2}"
config_build_entry: "cn=include{3}"
config_build_entry: "cn=include{4}"
config_build_entry: "cn=schema"
config_build_entry: "cn={0}core"
config_build_entry: "cn={1}cosine"
config_build_entry: "cn={2}inetorgperson"
config_build_entry: "cn={3}ppolicy"
config_build_entry: "cn={4}mySchema"
config_build_entry: "olcDatabase={-1}frontend"
config_build_entry: "olcDatabase={0}config"
config_build_entry: "olcDatabase={1}bdb"
WARNING: No dynamic config support for overlay ppolicy.
config_build_entry: "olcOverlay={0}ppolicy"
backend_startup_one: starting "dc=example,dc=org"
bdb_db_open: Warning - No DB_CONFIG file found in directory
/usr/local/var/openldap-
data: (2)
Expect poor performance for suffix dc=example,dc=org.
bdb_db_open: dbenv_open(/usr/local/var/openldap-data)
slapd starting
ldap_pvt_gethostbyname_a: host=devpc-tm1, r=0
connection_get(14): got connid=0
connection_read(14): checking for input on id=0 ber_get_next
ber_get_next: tag 0x30 len 43 contents:
ber_get_next
ber_get_next on fd 14 failed errno=11 (Resource temporarily unavailable)
do_bind ber_scanf fmt ({imt) ber:
ber_scanf fmt (m}) ber:
=> get_ctrls
ber_scanf fmt ({m) ber:
=> get_ctrls: oid="1.3.6.1.4.1.42.2.27.8.5.1" (noncritical) <=
get_ctrls: n=1 rc=0 err=""
>>> dnPrettyNormal: <>
<<< dnPrettyNormal: <>, <>
do_bind: version=3 dn="" method=128
slap_global_control: unavailable control: 1.3.6.1.4.1.42.2.27.8.5.1
send_ldap_result: conn=0 op=0 p=3
send_ldap_response: msgid=1 tag=97 err=0
ber_flush: 14 bytes to sd 14
connection_get(14): got connid=0
connection_read(14): checking for input on id=0 ber_get_next
ber_get_next: tag 0x30 len 98 contents:
ber_get_next
ber_get_next on fd 14 failed errno=11 (Resource temporarily unavailable)
do_bind: v3 anonymous bind
do_search
ber_scanf fmt ({miiiib) ber:
>>> dnPrettyNormal: <dc=example,dc=org>
<<< dnPrettyNormal: <dc=example,dc=org>, <dc=example,dc=org> ber_scanf
fmt ({mm}) ber:
ber_scanf fmt ({M}}) ber:
=> get_ctrls
ber_scanf fmt ({m) ber:
=> get_ctrls: oid="1.3.6.1.4.1.42.2.27.8.5.1" (noncritical) <=
get_ctrls: n=1 rc=0 err=""
slap_global_control: unavailable control: 1.3.6.1.4.1.42.2.27.8.5.1 ==>
limits_get: conn=0 op=1 dn="[anonymous]"
=> bdb_search
bdb_dn2entry("dc=example,dc=org")
=> bdb_dn2id("dc=example,dc=org")
<= bdb_dn2id: got id=0x00000001
entry_decode: "dc=example,dc=org"
<= entry_decode(dc=example,dc=org)
search_candidates: base="dc=example,dc=org" (0x00000001) scope=2 =>
bdb_dn2idl("dc=example,dc=org") => bdb_equality_candidates (objectClass)
=> key_read <= bdb_index_read: failed (-30989) <=
bdb_equality_candidates: id=0, first=0, last=0 =>
bdb_equality_candidates (objectClass) => key_read <= bdb_index_read 2
candidates <= bdb_equality_candidates: id=2, first=1678, last=1679
bdb_search_candidates: id=-1 first=1678 last=1679
entry_decode: "uid=aaaa,ou=people,dc=example,dc=org"
<= entry_decode(uid=aaaa,ou=people,dc=example,dc=org)
=> bdb_dn2id("ou=people,dc=example,dc=org")
<= bdb_dn2id: got id=0x00000003
=> bdb_dn2id("uid=aaaa,ou=people,dc=example,dc=org")
<= bdb_dn2id: got id=0x0000068e
=> send_search_entry: conn 0 dn="uid=aaaa,ou=people,dc=example,dc=org"
ber_flush: 256 bytes to sd 14
<= send_search_entry: conn 0 exit.
entry_decode: "uid=admin,ou=people,dc=example,dc=org"
<= entry_decode(uid=admin,ou=people,dc=example,dc=org)
=> bdb_dn2id("uid=admin,ou=people,dc=example,dc=org")
<= bdb_dn2id: got id=0x0000068f
=> send_search_entry: conn 0 dn="uid=admin,ou=people,dc=example,dc=org"
ber_flush: 331 bytes to sd 14
<= send_search_entry: conn 0 exit.
send_ldap_result: conn=0 op=1 p=3
send_ldap_response: msgid=2 tag=101 err=0
ber_flush: 14 bytes to sd 14
connection_get(14): got connid=0
connection_read(14): checking for input on id=0 ber_get_next
ber_get_next: tag 0x30 len 5 contents:
ber_get_next
ber_get_next on fd 14 failed errno=0 (Success)
connection_read(14): input error=-2 id=0, closing.
connection_closing: readying conn=0 sd=14 for close
connection_close: deferring conn=0 sd=14
connection_resched: attempting closing conn=0 sd=14
connection_close: deferring conn=0 sd=14 do_unbind
connection_resched: attempting closing conn=0 sd=14
connection_close: conn=0 sd=14
connection_get(14): connection not used
connection_read(14): no connection!


-----Original Message-----
From: owner-openldap-software@OpenLDAP.org
[mailto:owner-openldap-software@OpenLDAP.org] On Behalf Of Howard Chu
Sent: 21 June 2006 21:29
To: tj.murphy@virgin.net
Cc: openldap-software@OpenLDAP.org
Subject: 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 
> 2-> 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/


-- 

Visit our website at www.roke.co.uk

Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK.

The information contained in this e-mail and any attachments is proprietary to
Roke Manor Research Ltd and must not be passed to any third party without
permission. This communication is for information only and shall not create or
change any contractual relationship.