openldap-software January 2007

openldap-software@openldap.org

98 participants
123 discussions

refreshAndPersist and Monitor -> slapd core dump
by Niels Frimodt Sørensen 22 Jan '07

22 Jan '07

Hi, I am testing refreshAndPersist mode of syncrepl and would like to use Monitor. The slave is however dumping core when I do ldapsearch against cn=Connections, cn=Monitor. The system is running on Solaris 9 and based on OpenLDAP 2.3.32. Replication works just fine. If I change syncrepl type to refreshOnly then the ldapsearch is completed without core dump. Further information on configuration and debug below. What am I doing wrong? -- Venlig hilsen/Kind regards Niels Frimodt Sørensen Signaturgruppen A/S www.signaturgruppen.dk The Master has the following conf: # slapd.conf # Schema include /opt/ldap/content2/schema/core.schema # Control files pidfile /opt/ldap/backend2/var/slapd.pid argsfile /opt/ldap/backend2/var/slapd.args database bdb suffix "c=NO" rootdn "cn=Manager,c=NO" rootpw Test1234 directory /opt/ldap/content2/data checkpoint 128 10 # Indices to maintain index objectclass,entryCSN,entryUUID eq index serialNumber pres,eq index mail pres,eq index cn pres,eq cachesize 100000 threads 64 overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 database monitor The slave has the following conf: # slapd.conf # Schema include /opt/ldap/content-buslave/schema/core.schema # Control files pidfile /opt/ldap/backend-buslave/var/slapd.pid argsfile /opt/ldap/backend-buslave/var/slapd.args # database defs database bdb suffix "c=NO" rootdn "cn=Manager,c=NO" rootpw Test1234 directory /opt/ldap/content-buslave/data checkpoint 128 10 # Indices to maintain index objectclass,entryCSN,entryUUID eq index serialNumber pres,eq index mail pres,eq index cn pres,eq cachesize 100000 threads 32 syncrepl rid=123 provider=ldap://127.0.0.1:3892 type=refreshAndPersist searchbase="c=NO" filter="(objectClass=*)" scobe=sub attrs="" schemachecking=off bindmethod=simple updatedn="cn=Manager,c=NO" binddn="cn=Manager,c=NO" credentials="Test1234" database monitor The ldapsearch output that indicate the problem: ldapsearch -h localhost -p 3891 -b "cn=Monitor" "cn=Connections" + # extended LDIF # # LDAPv3 # base <cn=Monitor> with scope subtree # filter: cn=Connections # requesting: + # # Connections, Monitor dn: cn=Connections,cn=Monitor structuralObjectClass: monitorContainer creatorsName: modifiersName: createTimestamp: 20070122103402Z modifyTimestamp: 20070122103402Z entryDN: cn=Connections,cn=Monitor subschemaSubentry: cn=Subschema hasSubordinates: TRUE ldap_result: Can't contact LDAP server (-1) The slave debugs the following during the search: ... => test_filter EQUALITY => access_allowed: search access to "cn=Connections,cn=Monitor" "cn" requested => access_allowed: backend default search access granted to "(anonymous)" <= test_filter 6 => send_search_entry: conn 0 dn="cn=Connections,cn=Monitor" => access_allowed: read access to "cn=Connections,cn=Monitor" "entry" requested => access_allowed: backend default read access granted to "(anonymous)" => access_allowed: read access to "cn=Connections,cn=Monitor" "structuralObjectClass" requested => access_allowed: backend default read access granted to "(anonymous)" => access_allowed: read access to "cn=Connections,cn=Monitor" "creatorsName" requested => access_allowed: backend default read access granted to "(anonymous)" => access_allowed: read access to "cn=Connections,cn=Monitor" "modifiersName" requested => access_allowed: backend default read access granted to "(anonymous)" => access_allowed: read access to "cn=Connections,cn=Monitor" "createTimestamp" requested => access_allowed: backend default read access granted to "(anonymous)" => access_allowed: read access to "cn=Connections,cn=Monitor" "modifyTimestamp" requested => access_allowed: backend default read access granted to "(anonymous)" => access_allowed: read access to "cn=Connections,cn=Monitor" "entryDN" requested => access_allowed: backend default read access granted to "(anonymous)" => access_allowed: read access to "cn=Connections,cn=Monitor" "subschemaSubentry" requested => access_allowed: backend default read access granted to "(anonymous)" => access_allowed: read access to "cn=Connections,cn=Monitor" "hasSubordinates" requested => access_allowed: backend default read access granted to "(anonymous)" ber_flush: 308 bytes to sd 13 0000: 30 82 01 30 02 01 02 64 82 01 29 04 19 63 6e 3d 0..0...d..)..cn= 0010: 43 6f 6e 6e 65 63 74 69 6f 6e 73 2c 63 6e 3d 4d Connections,cn=M 0020: 6f 6e 69 74 6f 72 30 82 01 0a 30 2b 04 15 73 74 onitor0...0+..st 0030: 72 75 63 74 75 72 61 6c 4f 62 6a 65 63 74 43 6c ructuralObjectCl 0040: 61 73 73 31 12 04 10 6d 6f 6e 69 74 6f 72 43 6f ass1...monitorCo 0050: 6e 74 61 69 6e 65 72 30 12 04 0c 63 72 65 61 74 ntainer0...creat 0060: 6f 72 73 4e 61 6d 65 31 02 04 00 30 13 04 0d 6d orsName1...0...m 0070: 6f 64 69 66 69 65 72 73 4e 61 6d 65 31 02 04 00 odifiersName1... 0080: 30 24 04 0f 63 72 65 61 74 65 54 69 6d 65 73 74 0$..createTimest 0090: 61 6d 70 31 11 04 0f 32 30 30 37 30 31 32 32 31 amp1...200701221 00a0: 30 30 39 34 32 5a 30 24 04 0f 6d 6f 64 69 66 79 00942Z0$..modify 00b0: 54 69 6d 65 73 74 61 6d 70 31 11 04 0f 32 30 30 Timestamp1...200 00c0: 37 30 31 32 32 31 30 30 39 34 32 5a 30 26 04 07 70122100942Z0&.. 00d0: 65 6e 74 72 79 44 4e 31 1b 04 19 63 6e 3d 43 6f entryDN1...cn=Co 00e0: 6e 6e 65 63 74 69 6f 6e 73 2c 63 6e 3d 4d 6f 6e nnections,cn=Mon 00f0: 69 74 6f 72 30 23 04 11 73 75 62 73 63 68 65 6d itor0#..subschem 0100: 61 53 75 62 65 6e 74 72 79 31 0e 04 0c 63 6e 3d aSubentry1...cn= 0110: 53 75 62 73 63 68 65 6d 61 30 19 04 0f 68 61 73 Subschema0...has 0120: 53 75 62 6f 72 64 69 6e 61 74 65 73 31 06 04 04 Subordinates1... 0130: 54 52 55 45 TRUE ldap_write: want=308, written=308 0000: 30 82 01 30 02 01 02 64 82 01 29 04 19 63 6e 3d 0..0...d..)..cn= 0010: 43 6f 6e 6e 65 63 74 69 6f 6e 73 2c 63 6e 3d 4d Connections,cn=M 0020: 6f 6e 69 74 6f 72 30 82 01 0a 30 2b 04 15 73 74 onitor0...0+..st 0030: 72 75 63 74 75 72 61 6c 4f 62 6a 65 63 74 43 6c ructuralObjectCl 0040: 61 73 73 31 12 04 10 6d 6f 6e 69 74 6f 72 43 6f ass1...monitorCo 0050: 6e 74 61 69 6e 65 72 30 12 04 0c 63 72 65 61 74 ntainer0...creat 0060: 6f 72 73 4e 61 6d 65 31 02 04 00 30 13 04 0d 6d orsName1...0...m 0070: 6f 64 69 66 69 65 72 73 4e 61 6d 65 31 02 04 00 odifiersName1... 0080: 30 24 04 0f 63 72 65 61 74 65 54 69 6d 65 73 74 0$..createTimest 0090: 61 6d 70 31 11 04 0f 32 30 30 37 30 31 32 32 31 amp1...200701221 00a0: 30 30 39 34 32 5a 30 24 04 0f 6d 6f 64 69 66 79 00942Z0$..modify 00b0: 54 69 6d 65 73 74 61 6d 70 31 11 04 0f 32 30 30 Timestamp1...200 00c0: 37 30 31 32 32 31 30 30 39 34 32 5a 30 26 04 07 70122100942Z0&.. 00d0: 65 6e 74 72 79 44 4e 31 1b 04 19 63 6e 3d 43 6f entryDN1...cn=Co 00e0: 6e 6e 65 63 74 69 6f 6e 73 2c 63 6e 3d 4d 6f 6e nnections,cn=Mon 00f0: 69 74 6f 72 30 23 04 11 73 75 62 73 63 68 65 6d itor0#..subschem 0100: 61 53 75 62 65 6e 74 72 79 31 0e 04 0c 63 6e 3d aSubentry1...cn= 0110: 53 75 62 73 63 68 65 6d 61 30 19 04 0f 68 61 73 Subschema0...has 0120: 53 75 62 6f 72 64 69 6e 61 74 65 73 31 06 04 04 Subordinates1... 0130: 54 52 55 45 TRUE conn=0 op=1 ENTRY dn="cn=connections,cn=monitor" <= send_search_entry: conn 0 exit. Segmentation Fault - core dumped

2 1

Re: OpenLDAP issues when connecting over SSL
by Jean-Yves Avenard 22 Jan '07

22 Jan '07

Hello On 1/22/07, FRLinux <frlinux(a)gmail.com> wrote: > > TLSCipherSuite HIGH:MEDIUM:+SSLv2 > > I am curious, why do you want to specify this ? (and also not use SSLv3 ?) I simply followed this page: http://www.openldap.org/pub/ksoper/OpenLDAP_TLS.html And this was one of the configuration line, but I haven't given much thought about it. As part of my various attempts, I had also tried without this configuration line. It made no difference. > I am not sure what you are trying to do, but this is our configuration > (FreeBSD servers with Linux clients). They contact the ldap server for > libnss/pam auth. Thank you for this. I also use a FreeBSD server (6.2) and I'm in the process of migrating from YP to LDAP, this will surely help > > slapd.conf (from bsd server) : > > TLSCACertificateFile /usr/local/etc/openldap/cert/cacert.pem could you email me privately your cacert.pem ? I'm using the ca-bundle.crt that comes by default, but I'm not sure it's the right file JY

2 1

slurpd access control problems
by Andrea Venturoli 22 Jan '07

22 Jan '07

Hello. I guess this must be a FAQ, but I tried searching for a whole day and didn't came up with any answer. I've got two FreeBSD servers running openldap 2.3.32 in a master/slave configuration. I'm using slurpd to keep them in sync: I tried this with the rootdn as the slurp binddn and from a network perspective it works. Now, I obviously don't want to use rootdn for this, so I created a new user and I'm using simple authentication (on an SSL layer). I get problems with access control, however, that prevent it from working. What I did: I created this user: dn: uid=slurpd,ou=users,dc=xxxxxxxx,dc=xx cn: slurpd objectClass: account objectClass: posixAccount objectClass: shadowAccount objectClass: top uid: slurpd uidNumber: 1033 gidNumber: 389 userPassword:: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX loginShell: /sbin/nologin homeDirectory: /nonexistent On the slave I edited slapd.conf as follows: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/local/etc/samba.schema pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args access to * by dn="uid=slurp,ou=users,dc=xxxxxxxx,dc=xx" write access to * by * none TLSCertificateFile /usr/local/local/etc/openssl/openldap_newcert.pem TLSCertificateKeyFile /usr/local/local/etc/openssl/openldap_newcertkey.pem TLSCACertificateFile /usr/local/local/etc/openssl/netfence_ca.pem database bdb suffix "dc=xxxxxxxx,dc=xx" rootdn "cn=root,dc=xxxxxxxx,dc=xx" rootpw xxxxxxxx directory /var/db/openldap-data index objectClass eq index uid pres,eq index rid eq index cn eq updatedn "uid=slurp,ou=users,dc=xxxxxxxx,dc=xx" updateref "ldaps://master.xxxxxxxxx.xx" The problem is I cannot access the slave database with dn="uid=slurp,ou=users,dc=xxxxxxxx,dc=xx". What I get is: slave# ldapsearch -w xxxxxxx -D 'uid=slurp,ou=users,dc=xxxxxxxx,dc=xx' -b 'dc=xxxxxxxxx,dc=xx' -d 255 ldap_create ldap_bind ldap_simple_bind ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:389 ldap_new_socket: -1 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 127.0.0.1:389 ldap_connect_timeout: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x00517000 ptr=0x00517000 end=0x00517039 len=57 0000: 30 37 02 01 01 60 32 02 01 03 04 24 75 69 64 3d 07...`2....$uid= 0010: 73 6c 75 72 70 2c 6f 75 3d 75 73 65 72 73 2c 64 slurp,ou=users,d 0020: 63 3d XX XX XX XX XX XX XX XX 2c 64 63 3d XX XX c=xxxxxxxx,dc=xx 0030: 80 07 XX XX XX XX XX XX XX ..xxxxxxx ber_scanf fmt ({i) ber: ber_dump: buf=0x00517000 ptr=0x00517005 end=0x00517039 len=52 0000: 60 32 02 01 03 04 24 75 69 64 3d 73 6c 75 72 70 `2....$uid=slurp 0010: 2c 6f 75 3d 75 73 65 72 73 2c 64 63 3d XX XX XX ,ou=users,dc=xxx 0020: XX XX XX XX XX 2c 64 63 3d XX XX 80 07 XX XX XX xxxxx,dc=xx..xxx 0030: XX XX XX XX xxxx ber_flush: 57 bytes to sd 3 0000: 30 37 02 01 01 60 32 02 01 03 04 24 75 69 64 3d 07...`2....$uid= 0010: 73 6c 75 72 70 2c 6f 75 3d 75 73 65 72 73 2c 64 slurp,ou=users,d 0020: 63 3d XX XX XX XX XX XX XX XX 2c 64 63 3d XX XX c=xxxxxxxx,dc=xx 0030: 80 07 XX XX XX XX XX XX XX ..xxxxxxx ldap_write: want=57, written=57 0000: 30 37 02 01 01 60 32 02 01 03 04 24 75 69 64 3d 07...`2....$uid= 0010: 73 6c 75 72 70 2c 6f 75 3d 75 73 65 72 73 2c 64 slurp,ou=users,d 0020: 63 3d XX XX XX XX XX XX XX XX 2c 64 63 3d XX XX c=xxxxxxx,dc=xx 0030: 80 07 XX XX XX XX XX XX XX ..xxxxxxx ldap_result ld 0x515400 msgid 1 ldap_chkResponseList ld 0x515400 msgid 1 all 1 ldap_chkResponseList returns ld 0x515400 NULL wait4msg ld 0x515400 msgid 1 (infinite timeout) wait4msg continue ld 0x515400 msgid 1 all 1 ** ld 0x515400 Connections: * host: localhost port: 389 (default) refcnt: 2 status: Connected last used: Fri Jan 19 23:10:47 2007 ** ld 0x515400 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ** ld 0x515400 Response Queue: Empty ldap_chkResponseList ld 0x515400 msgid 1 all 1 ldap_chkResponseList returns ld 0x515400 NULL ldap_int_select read1msg: ld 0x515400 msgid 1 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 01 61 07 0a 0....a.. ldap_read: want=6, got=6 0000: 01 31 04 00 04 00 .1.... ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0x00514210 ptr=0x00514210 end=0x0051421c len=12 0000: 02 01 01 61 07 0a 01 31 04 00 04 00 ...a...1.... read1msg: ld 0x515400 msgid 1 message type bind ber_scanf fmt ({eaa) ber: ber_dump: buf=0x00514210 ptr=0x00514213 end=0x0051421c len=9 0000: 61 07 0a 01 31 04 00 04 00 a...1.... read1msg: ld 0x515400 0 new referrals read1msg: mark request completed, ld 0x515400 msgid 1 request done: ld 0x515400 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_result ber_scanf fmt ({iaa) ber: ber_dump: buf=0x00514210 ptr=0x00514213 end=0x0051421c len=9 0000: 61 07 0a 01 31 04 00 04 00 a...1.... ber_scanf fmt (}) ber: ber_dump: buf=0x00514210 ptr=0x0051421c end=0x0051421c len=0 ldap_msgfree ldap_err2string ldap_bind: Invalid credentials (49) Obviously the same command works if used with rootdn. What am I doing wrong? bye & Thanks av.

5 8

How to only accept TLS connection on port 389
by Jean-Yves Avenard 21 Jan '07

21 Jan '07

Hi Is there a way to have OpenLDAP listening on port 389 (standard ldap) but only accept tls encrypted session? I've searched for quite a while and it seems that the only option is to disable listening on port 389 alltogether and only listen on port 636. But this isn't good for my purpose, as some broken clients only work over TLS on port 389 Thank you Jean-Yves

1 0

Re: OpenLDAP issues when connecting over SSL
by Kurt D. Zeilenga 21 Jan '07

21 Jan '07

At 02:07 AM 1/21/2007, Jean-Yves Avenard wrote: >Other clients seem to work well over SSL. >I am missing something in the slapd.conf? Given other clients seem to work well using ldaps://, it seems more likely that this particular client is not properly configured or is otherwise flawed. >conn=14 fd=14 ACCEPT from IP=124.168.139.185:50884 (IP=0.0.0.0:636) >TLS: can't accept. >TLS: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown I guess that the client is configured to use ldap://server:636 not ldaps://server:636. Kurt

2 1

OpenLDAP issues when connecting over SSL
by Jean-Yves Avenard 21 Jan '07

21 Jan '07

Hi. I am trying to get a client to connect over SSL. A ldapsearch work on linux using SSL, however, when this specific client tried to access (which I can't name here for some reasons!) it I get the following error in OpenLDAP: conn=14 fd=14 ACCEPT from IP=124.168.139.185:50884 (IP=0.0.0.0:636) TLS: can't accept. TLS: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol s23_srvr.c:562 conn=14 fd=14 closed (TLS negotiation failure) conn=9 op=3 BIND dn="" method=128 conn=9 op=3 RESULT tag=97 err=0 text= conn=9 op=4 UNBIND conn=9 fd=13 closed Other clients seem to work well over SSL. I am missing something in the slapd.conf? The SSL related configuration I have are: TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCertificateFile /usr/local/etc/openldap/cert.pem TLSCertificateKeyFile /usr/local/etc/openldap/cert.pem TLSCACertificateFile /usr/local/etc/openldap/ca-bundle.crt TLSVerifyClient allow Somebody posted a similar question last year on this distribution list, however he didn't get any answers. I was hopeful this is a common issue. Thank you Jean-Yves

1 0

some minor issues with the new ldif-config-style
by Wolfgang Hennerbichler 20 Jan '07

20 Jan '07

Hi, I switched to the new ldif-config-style today. I would have 3 questions: 1) slapd converted my slapd.conf to ldif files successfully, I could look at the cn=config hierachy - pretty cool. Nevertheless I can't write into it. I defined: olcRootDN: "cn=admin,cn=config" olcRootPW: "{SSHA}..." olcAccess: {5}to * by dn.base="cn=admin,cn=config" write in olcDatabase={0}config.ldif. Is it possible to write there? 2) All my schemas were converted to ldif, too. Pretty cool, I thought. But I can't find an option to include a schema. Of course I could still include the files with olcIncludeFile, but that sucks, doesn't it? 3) This is the really interesting stuff: is it possible to start a "stupid" replication server with syncrepl, who only knows how to connect to the main server, and then syncs the schemas and parts of the config to itself? that would be cool, and I guess it can be done. Yet it's still dependend on question 1 :) Thanks for a reply, wogri -- wogri(a)wogri.com http://www.wogri.com http://www.einradfilm.at

2 1

RE: WARNING: No dynamic config support for overlay ppolicy?
by Errol Neal 19 Jan '07

19 Jan '07

>>Hi, >> >>I don't see a problem description anywhere in this email. What exactly is the issue you are facing with ppolicy Sorry. Essentially, I'm trying to replicate the tests done specifically to test account lockout when you run 'make test' after compiling openldap. Here is a slapcat of my directory: [root@dgovit-pap02 sbin]# ./slapcat dn: dc=ttpua,dc=portal dc: ttpua objectClass: dcObject objectClass: organizationalUnit ou: TTPUA Portal structuralObjectClass: organizationalUnit entryUUID: f0a9c1ec-dd27-102a-9bfc-3fef944328a2 creatorsName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal modifiersName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal createTimestamp: 20060920191410Z modifyTimestamp: 20060920191410Z entryCSN: 20060920191410Z#000000#00#000000 dn: ou=users,dc=ttpua,dc=portal ou: users objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: f0b2c404-dd27-102a-9bfd-3fef944328a2 creatorsName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal modifiersName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal createTimestamp: 20060920191410Z modifyTimestamp: 20060920191410Z entryCSN: 20060920191410Z#000001#00#000000 dn: ou=system,ou=users,dc=ttpua,dc=portal ou: system objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: f0b3d042-dd27-102a-9bfe-3fef944328a2 creatorsName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal modifiersName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal createTimestamp: 20060920191410Z modifyTimestamp: 20060920191410Z entryCSN: 20060920191410Z#000002#00#000000 dn: ou=portal,ou=users,dc=ttpua,dc=portal ou: portal objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: f0b4b8c2-dd27-102a-9bff-3fef944328a2 creatorsName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal modifiersName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal createTimestamp: 20060920191410Z modifyTimestamp: 20060920191410Z entryCSN: 20060920191410Z#000003#00#000000 dn: ou=disabled,ou=portal,ou=users,dc=ttpua,dc=portal ou: disabled objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: f0b5a19c-dd27-102a-9c00-3fef944328a2 creatorsName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal modifiersName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal createTimestamp: 20060920191410Z modifyTimestamp: 20060920191410Z entryCSN: 20060920191410Z#000004#00#000000 dn: ou=active,ou=portal,ou=users,dc=ttpua,dc=portal ou: active objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: f0b663e8-dd27-102a-9c01-3fef944328a2 creatorsName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal modifiersName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal createTimestamp: 20060920191410Z modifyTimestamp: 20060920191410Z entryCSN: 20060920191410Z#000005#00#000000 dn: ou=pending,ou=portal,ou=users,dc=ttpua,dc=portal ou: pending objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: f0b750fa-dd27-102a-9c02-3fef944328a2 creatorsName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal modifiersName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal createTimestamp: 20060920191410Z modifyTimestamp: 20060920191410Z entryCSN: 20060920191410Z#000006#00#000000 dn: ou=roles,dc=ttpua,dc=portal ou: roles objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: f0b839e8-dd27-102a-9c03-3fef944328a2 creatorsName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal modifiersName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal createTimestamp: 20060920191410Z modifyTimestamp: 20060920191410Z entryCSN: 20060920191410Z#000007#00#000000 dn: ou=portal,ou=roles,dc=ttpua,dc=portal ou: portal objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: f0b92a9c-dd27-102a-9c04-3fef944328a2 creatorsName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal modifiersName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal createTimestamp: 20060920191410Z modifyTimestamp: 20060920191410Z entryCSN: 20060920191410Z#000008#00#000000 dn: ou=policies,dc=ttpua,dc=portal ou: policies objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: f0ba10ec-dd27-102a-9c05-3fef944328a2 creatorsName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal modifiersName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal createTimestamp: 20060920191410Z modifyTimestamp: 20060920191410Z entryCSN: 20060920191410Z#000009#00#000000 dn: ou=portal,ou=policies,dc=ttpua,dc=portal ou: portal objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: f0bafb4c-dd27-102a-9c06-3fef944328a2 creatorsName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal modifiersName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal createTimestamp: 20060920191410Z modifyTimestamp: 20060920191410Z entryCSN: 20060920191410Z#00000a#00#000000 dn: cn=std,ou=portal,ou=policies,dc=ttpua,dc=portal objectClass: pwdPolicy objectClass: top objectClass: device cn: std pwdAttribute: userPassword pwdMaxAge: 7516800 pwdExpireWarning: 432000 pwdInHistory: 6 pwdCheckQuality: 1 pwdMinLength: 8 pwdMaxFailure: 4 pwdLockout: TRUE pwdLockoutDuration: 1920 pwdGraceAuthNLimit: 0 pwdFailureCountInterval: 0 pwdMustChange: TRUE pwdAllowUserChange: TRUE pwdSafeModify: TRUE structuralObjectClass: device entryUUID: b0976292-dd29-102a-8aff-4f205a2326f4 creatorsName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal modifiersName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal createTimestamp: 20060920192642Z modifyTimestamp: 20060920192642Z entryCSN: 20060920192642Z#000000#00#000000 dn: ou=testing,ou=portal,ou=users,dc=ttpua,dc=portal ou: testing objectClass: top objectClass: organizationalUnit structuralObjectClass: organizationalUnit entryUUID: badddc52-dd30-102a-8afe-613291c80c74 creatorsName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal createTimestamp: 20060920201706Z entryCSN: 20060920201706Z#000000#00#000000 modifiersName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal modifyTimestamp: 20060920201706Z dn: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal objectClass: top objectClass: person sn: scoobydoo cn: scoobydoo structuralObjectClass: person entryUUID: 56d4aa34-dd39-102a-93bd-2d2088fc7504 creatorsName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal createTimestamp: 20060920211843Z entryCSN: 20060920211922Z#000000#00#000000 modifiersName: cn=scoobydoo,ou=system,ou=users,dc=ttpua,dc=portal modifyTimestamp: 20060920211922Z dn: cn=test,ou=portal,ou=policies,dc=ttpua,dc=portal objectClass: pwdPolicy objectClass: top objectClass: device cn: test pwdAttribute: userPassword pwdMaxAge: 360 pwdExpireWarning: 120 pwdInHistory: 3 pwdCheckQuality: 1 pwdMinLength: 8 pwdMaxFailure: 3 pwdLockout: TRUE pwdLockoutDuration: 60 pwdFailureCountInterval: 120 pwdMustChange: TRUE pwdAllowUserChange: TRUE pwdSafeModify: TRUE pwdGraceAuthNLimit: 3 structuralObjectClass: device entryUUID: dde41790-ddb0-102a-9d8f-2524a04c2d05 creatorsName: cn=scoobydoo,dc=ttpua,dc=portal modifiersName: cn=scoobydoo,dc=ttpua,dc=portal createTimestamp: 20060921113420Z modifyTimestamp: 20060921113420Z entryCSN: 20060921113420Z#000000#00#000000 dn: cn=webuser,ou=portal,ou=roles,dc=ttpua,dc=portal objectClass: top objectClass: person objectClass: organizationalPerson sn: webuser cn: webuser structuralObjectClass: organizationalPerson entryUUID: 6ae140ba-de0a-102a-8cfb-0b9650b2dbbe creatorsName: cn=scoobydoo,dc=ttpua,dc=portal createTimestamp: 20060921221522Z entryCSN: 20060921221522Z#000000#00#000000 modifiersName: cn=scoobydoo,dc=ttpua,dc=portal modifyTimestamp: 20060921221522Z dn: cn=lnelson,ou=active,ou=portal,ou=users,dc=ttpua,dc=portal uid: 1 objectClass: organizationalPerson objectClass: inetOrgPerson givenName: Lamont sn: Nelson cn: lnelson structuralObjectClass: inetOrgPerson entryUUID: 5ca463c6-e0fb-102a-9d43-93b4dcc2b715 creatorsName: cn=scoobydoo,dc=ttpua,dc=portal createTimestamp: 20060925160509Z userPassword:: cGFzc3dvcmQxMjM= entryCSN: 20060925170645Z#000000#00#000000 modifiersName: cn=scoobydoo,dc=ttpua,dc=portal modifyTimestamp: 20060925170645Z dn: cn=User,ou=active,ou=portal,ou=users,dc=ttpua,dc=portal uid: 2 objectClass: organizationalPerson objectClass: inetOrgPerson givenName: UA User sn: UA cn: User structuralObjectClass: inetOrgPerson entryUUID: b4f5dd42-e106-102a-9d44-93b4dcc2b715 creatorsName: cn=scoobydoo,dc=ttpua,dc=portal createTimestamp: 20060925172621Z userPassword:: dHRwdWE= entryCSN: 20060925172716Z#000000#00#000000 modifiersName: cn=scoobydoo,dc=ttpua,dc=portal modifyTimestamp: 20060925172716Z dn: cn=Rnewton,ou=active,ou=portal,ou=users,dc=ttpua,dc=portal objectClass: organizationalPerson objectClass: inetOrgPerson sn: Newton cn: Rnewton structuralObjectClass: inetOrgPerson entryUUID: d35e7c30-05d7-102b-9d47-93b4dcc2b715 creatorsName: cn=scoobydoo,dc=ttpua,dc=portal createTimestamp: 20061111135359Z uid: 3 givenName: R Newton userPassword:: ZGhzMXVh entryCSN: 20061111135646Z#000000#00#000000 modifiersName: cn=scoobydoo,dc=ttpua,dc=portal modifyTimestamp: 20061111135646Z dn: cn=lnelson123,ou=pending,ou=portal,ou=users,dc=ttpua,dc=portal supervisorName: test o: test telephoneNumber: test street: test sn: test userPassword:: cGFzc1dPUkQxMjMh city: test givenName: test mail: test objectClass: dfittpuser accessReason: test postalCode: test supervisorEmail: test cn: lnelson123 title: test businessCategory: test st: AR structuralObjectClass: dfittpuser entryUUID: 1c673d44-3bf3-102b-912c-2d95986cd7a9 creatorsName: cn=scoobydoo,dc=ttpua,dc=portal createTimestamp: 20070119102521Z entryCSN: 20070119102521Z#000000#00#000000 modifiersName: cn=scoobydoo,dc=ttpua,dc=portal modifyTimestamp: 20070119102521Z dn: cn=Username,ou=pending,ou=portal,ou=users,dc=ttpua,dc=portal supervisorName: Supervisor's Name o: Employer Name telephoneNumber: Professional Phone Number street: Professional Street Address sn: Last Name userPassword:: cGFzc1dPUkQxMjMh city: City givenName: First Name mail: Professional Email Address objectClass: dfittpuser accessReason: Reason for requesting access postalCode: Zip Code supervisorEmail: Supervisor's Email Address cn: Username title: Title businessCategory: Job Title st: DE structuralObjectClass: dfittpuser entryUUID: 695d0502-3bf3-102b-912d-2d95986cd7a9 creatorsName: cn=scoobydoo,dc=ttpua,dc=portal createTimestamp: 20070119102730Z entryCSN: 20070119102730Z#000000#00#000000 modifiersName: cn=scoobydoo,dc=ttpua,dc=portal modifyTimestamp: 20070119102730Z dn: cn=tuser,ou=testing,ou=portal,ou=users,dc=ttpua,dc=portal userPassword:: e1NIQX1XNnBoNU1tNVB6OEdnaVVMYlBnekczN21qOWc9 objectClass: top objectClass: inetOrgPerson objectClass: organizationalPerson sn: User cn: tuser structuralObjectClass: inetOrgPerson entryUUID: 15847d74-3bf4-102b-912f-2d95986cd7a9 creatorsName: cn=scoobydoo,dc=ttpua,dc=portal createTimestamp: 20070119103219Z pwdPolicySubentry: cn=test,ou=portal,ou=policies,dc=ttpua,dc=portal entryCSN: 20070119103245Z#000000#00#000000 modifiersName: cn=scoobydoo,dc=ttpua,dc=portal modifyTimestamp: 20070119103245Z So, as test022-policy does, I should be able to lock myself out after 3 unsuccessful attempts.. ./ldapsearch -x -b "dc=ttpua,dc=portal" -P 3 -LLL -e ppolicy -h localhost -D cn=tuser,ou=testing,ou=portal,ou=users,dc=ttpua,dc=portal -w badpassword I do that 3 times, and after third attempt,I should receive a response back from the server indicating that my acct is locked out. But I don't and if I use the correct password for the account, I am able to authenticate and my search returns data. Also, when I start up my ldap server, I get the following error: Stopping slapd: [ OK ] Checking configuration files for slapd: WARNING: No dynamic config support for overlay ppolicy. config file testing succeeded Starting slapd: So I'm not sure whats wrong here. This is already long so I don't want to respost my slapd.conf.

1 0

ppolicy and sync replication
by Sadique Puthen 19 Jan '07

19 Jan '07

Hi, Is it possible to replicate password policy related attributes using sync replication while using ppolicy overlay? I am specifically asking about replicating pwdChangedTime, pwdAccountLockedTime, pwdHistory and etc... not about password configuration related attributes, Regards, Sadique

5 9

WARNING: No dynamic config support for overlay ppolicy?
by Errol Neal 19 Jan '07

19 Jan '07

I've been trying to play with the ppolicy features of openldap for a few months now I have been very unsucessful. Here is my slapd.conf file: [root@dgovit-pap02 openldap]# cat slapd.conf ############################################################ include /usr/local/ldap/etc/openldap/schema/core.schema include /usr/local/ldap/etc/openldap/schema/cosine.schema include /usr/local/ldap/etc/openldap/schema/nis.schema include /usr/local/ldap/etc/openldap/schema/corba.schema include /usr/local/ldap/etc/openldap/schema/inetorgperson.schema include /usr/local/ldap/etc/openldap/schema/misc.schema include /usr/local/ldap/etc/openldap/schema/openldap.schema include /usr/local/ldap/etc/openldap/schema/ppolicy.schema include /usr/local/ldap/etc/openldap/schema/ttpua.schema pidfile /var/run/ldap/slapd.pid argsfile /var/run/ldap/slapd.args # Load dynamic backend modules: modulepath /usr/local/ldap/libexec/openldap # moduleload back_bdb.la # moduleload back_ldap.la # moduleload back_ldbm.la # moduleload back_passwd.la # moduleload back_shell.la # moduleload ppolicy.la overlay ppolicy ppolicy_default "cn=std,ou=portal,ou=policies,dc=ttpua,dc=portal" ppolicy_use_lockout access to dn="" by * read password-hash {SSHA} database bdb suffix "dc=ttpua,dc=portal" rootdn "cn=scoobydoo,dc=ttpua,dc=portal" rootpw {SSHA}hPdD1ypslgiUX6ANvpBoQRdJ7rAK9ab2 # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /usr/local/ldap/var/openldap-data # indexing index default eq # basic use index objectClass,uid,dc,o,ou # references index member,owner,seeAlso # mail index mail # names index cn,sn,givenName,displayName eq,sub access to attrs=userPassword by self write by anonymous auth by * none access to attrs=shadowLastChange by self write by * auth access to * by * read loglevel 255 database monitor EOF I compiled openldap-2.3.32 as follows: ./configure --with-threads=posix --with-tls=openssl --enable-dynamic --with-cyrus-sasl --enable-modules--enable-ldbm=mod --enable-crypt --enable-lmpasswd --enable-ldap=mod --enable-meta=mod --enable-rewrite --enable-null=mod --enable-monitor=mod --enable-accesslog --enable-denyop --enable-dyngroup --enable-dynlist --enable-lastmod --enable-ppolicy --enable-proxycache --enable-refint --enable-retcode --enable-rwm --enable-syncprov --enable-translucent --enable-unique --enable-valsort --enable-aci --enable-bdb=mod --enable-hdb=mod --enable-ldbm-api=berkeley --enable-spasswd --enable-wrappers --prefix=/usr/local/ldap Can someone help me out here. Not sure what I'm doing wrong. I've followed every example I can find on the net but its still not working out for me. TIA, Errol Neal

2 1

← Newer
1
2
3
4
5
6
7
8
9
...
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software January 2007