openldap-technical

openldap-technical@openldap.org

9 participants
9868 discussions

Mixing multi-master and master-slave replication
by Robert Minsk 04 Nov '13

04 Nov '13

As a factility we have locations world wide. Within each facility we would like to use multi-master replication. We would also like to sync each facility to a glued set of databases on the global servers with simple master slave replication. See ASCII art diagram below. If every OpenLDAP server across all our locations has a unique "serverID" will the global master-slave replication play nice with the facility multi-master replication? -------- -------- -------- -------- | la01 |<-- multi-master --> | la02 | | ny01 |<-- multi-master -->| ny02 | -------- -------- -------- -------- | | -- master-slave -- -- master-slave -- | | v v ------------ | global01 | ------------ -- Robert Minsk Systems and Software Engineer WWW.METHODSTUDIOS.COM <http://www.methodstudios.com> 730 Arizona Ave, Santa Monica, CA 90401 O:+1 310 434 6500 <tel:+13104346500> // F:+1 310 434 6501 <tel:+13104346501> Los Angeles <http://www.methodstudios.com/signature/url/los-angeles><http://www.methodstudios.com/signature/url/los-angeles> This e-mail and any attachments are intended only for use by the addressee(s) named herein and may contain confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email and any attachments is strictly prohibited. If you receive this email in error, please immediately notify the sender by return email and permanently delete the original, any copy and any printout thereof. The integrity and security of e-mail cannot be guaranteed.

2 2

Invalid credentials
by yan＠seiner.com 31 Oct '13

31 Oct '13

I am setting up a simple LDAP server. I have a few entries that I am playing with for user authentication. I have phpldapadmin set up and I can verify that the passwords are correct. However, when I test authentication usign ldapwhoami or ldapsearch (anonymous) it always fails with invalid credentials or no records found. Can anyone provide any clues on what might be going on? yan@NewMoon:/etc$ ldapwhoami -x -W -D uid=yan,ou=People,dc=seiner,dc=lan -H ldap://eluonhea1.seiner.lan/ -d 255 ldap_url_parse_ext(ldap://eluonhea1.seiner.lan/) ldap_create ldap_url_parse_ext(ldap://eluonhea1.seiner.lan:389/??base) Enter LDAP Password: ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP eluonhea1.seiner.lan:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.128.21:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x7f567246c800 ptr=0x7f567246c800 end=0x7f567246c83c len=60 0000: 30 3a 02 01 01 60 35 02 01 03 04 22 75 69 64 3d 0:...`5...."uid= 0010: 79 61 6e 2c 6f 75 3d 50 65 6f 70 6c 65 2c 64 63 yan,ou=People,dc 0020: 3d 73 65 69 6e 65 72 2c 64 63 3d 6c 61 6e 80 0c =seiner,dc=lan.. 0030: xx (password deleted) ber_scanf fmt ({i) ber: ber_dump: buf=0x7f567246c800 ptr=0x7f567246c805 end=0x7f567246c83c len=55 0000: 60 35 02 01 03 04 22 75 69 64 3d 79 61 6e 2c 6f `5...."uid=yan,o 0010: 75 3d 50 65 6f 70 6c 65 2c 64 63 3d 73 65 69 6e u=People,dc=sein xx (password deleted) ber_flush2: 60 bytes to sd 3 0000: 30 3a 02 01 01 60 35 02 01 03 04 22 75 69 64 3d 0:...`5...."uid= 0010: 79 61 6e 2c 6f 75 3d 50 65 6f 70 6c 65 2c 64 63 yan,ou=People,dc 0020: 3d 73 65 69 6e 65 72 2c 64 63 3d 6c 61 6e 80 0c =seiner,dc=lan.. xx (password deleted) ldap_write: want=60, written=60 0000: 30 3a 02 01 01 60 35 02 01 03 04 22 75 69 64 3d 0:...`5...."uid= 0010: 79 61 6e 2c 6f 75 3d 50 65 6f 70 6c 65 2c 64 63 yan,ou=People,dc 0020: 3d 73 65 69 6e 65 72 2c 64 63 3d 6c 61 6e 80 0c =seiner,dc=lan.. xx (password deleted) ldap_result ld 0x7f5672464250 msgid 1 wait4msg ld 0x7f5672464250 msgid 1 (infinite timeout) wait4msg continue ld 0x7f5672464250 msgid 1 all 1 ** ld 0x7f5672464250 Connections: * host: eluonhea1.seiner.lan port: 389 (default) refcnt: 2 status: Connected last used: Thu Oct 31 09:42:03 2013 ** ld 0x7f5672464250 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x7f5672464250 request count 1 (abandoned 0) ** ld 0x7f5672464250 Response Queue: Empty ld 0x7f5672464250 response count 0 ldap_chkResponseList ld 0x7f5672464250 msgid 1 all 1 ldap_chkResponseList returns ld 0x7f5672464250 NULL ldap_int_select read1msg: ld 0x7f5672464250 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=0x7f567246daa0 ptr=0x7f567246daa0 end=0x7f567246daac len=12 0000: 02 01 01 61 07 0a 01 31 04 00 04 00 ...a...1.... read1msg: ld 0x7f5672464250 msgid 1 message type bind ber_scanf fmt ({eAA) ber: ber_dump: buf=0x7f567246daa0 ptr=0x7f567246daa3 end=0x7f567246daac len=9 0000: 61 07 0a 01 31 04 00 04 00 a...1.... read1msg: ld 0x7f5672464250 0 new referrals read1msg: mark request completed, ld 0x7f5672464250 msgid 1 request done: ld 0x7f5672464250 msgid 1 res_errno: 49, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x7f567246daa0 ptr=0x7f567246daa3 end=0x7f567246daac len=9 0000: 61 07 0a 01 31 04 00 04 00 a...1.... ber_scanf fmt (}) ber: ber_dump: buf=0x7f567246daa0 ptr=0x7f567246daac end=0x7f567246daac len=0 ldap_msgfree ldap_err2string ldap_bind: Invalid credentials (49) ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 3 0000: 30 05 02 01 02 42 00 0....B. ldap_write: want=7, written=7 0000: 30 05 02 01 02 42 00 0....B. ldap_free_connection: actually freed ========================= slapd.conf root@EluOnHea1:/etc/openldap# cat slapd.conf | grep -v ^# | grep -v ^$ include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/inetorgperson.schema pidfile /var/run/slapd.pid argsfile /var/run/slapd.args moduleload back_bdb.la access to * by self write by users read by anonymous auth database ldif suffix "dc=seiner,dc=lan" rootdn "cn=admin,dc=seiner,dc=lan" rootpw xxx directory /usr/lib/openldap-data

1 0

ldap_set_option() of LDAP_OPT_X_TLS_REQUIRE_CERT
by Todd Lyons 31 Oct '13

31 Oct '13

Hello, I'm a developer on the Exim MTA and I have some questions about differing behavior I am seeing across different systems. I would like some suggestions about the best way to handle each issue. First, I have not gotten "a ton of complaints." One person contacted me with the issues I am describing below. I do not know his server or client versions, other than his workstation is Debian Squeeze. I'll just refer to him as "the guy". Second, my test server is running openldap 2.3.34, my workstation on which I am running my test builds of Exim is using openldap 2.4.28 client libs. Issues: 1. When multiple servers are specified, our ldap code just did an unbind to all servers defined when it was finished. The guy contacted me with the problem that the unbind call hangs when one of the ldap servers was unavailable for whatever reason. On *my* system, the blind unbind worked properly no matter if the bind succeeded. I modified the ldap code so that it only unbinds if the original bind succeeded. That seems the proper/correct way to handle it in all cases, so this issue really is already solved. I'm just wondering if there are any gotchas I might be missing by doing it this way. 2. A few months ago I helped (a different) someone troubleshoot a really strange problem where setting the LDAP_OPT_X_TLS_REQUIRE_CERT option in our code did not have any impact on his machine. Our code set that option per connection. It turns out that, for him, setting that option per connection did not affect the TLS require cert option that the bind used. He found some comment somewhere advising that NULL for the ldap handle sets the option globally in the ldap client. We tried it and it solved the problem for him. I saw identical behavior on my system (NULL worked, ldap handle did not) so we assumed that the code had never really worked properly. I then changed our ldap code to use NULL instead of the ldap handle when setting the TLS require cert option. The guy (with the current problem) runs a system that worked just fine previously, but using the new code (NULL instead of ldap handle when setting TLS require cert option) does not affect the TLS require certificate setting when his bind is attempted. After much testing and debugging, I had him merely change that one line back to using the ldap handle in ldap_set_option() and it then worked properly for him. So I have two systems (mine and his) which behave differently after the ldap_set_option() on LDAP_OPT_X_TLS_REQUIRE_CERT. In a fit of psychotic testing, I decided on my system to just blindly set it both globally and per connection. It worked, and produced no errors. That surprised me, I expected one or the other to complain. My potential code looks like the following (apologize if Gmail wraps), can you explain any pitfalls of doing it this way? Should the two be #ifdef guarded by client lib version checks or something? /* Use NULL ldap handle b/c is global in some client libs */ rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &cert_option); if (rc) { DEBUG(D_lookup) debug_printf("Unable to set TLS require cert_option(%d) globally: %s\n", cert_option, ldap_err2string(rc)); } /* Use current ldap handle b/c is per-connection in others */ rc = ldap_set_option(ld, LDAP_OPT_X_TLS_REQUIRE_CERT, &cert_option); if (rc) { DEBUG(D_lookup) debug_printf("Unable to set TLS require cert_option(%d) on LDAP server " "%s%s: %s\n", cert_option, host, porttext, ldap_err2string(rc)); } Any comments or suggestions are appreciated. ...Todd -- The total budget at all receivers for solving senders' problems is $0. If you want them to accept your mail and manage it the way you want, send it the way the spec says to. --John Levine

1 1

substring matching rule not working in extensible search filter
by David Coutadeur 31 Oct '13

31 Oct '13

Hi everybody, I tryied this filter in a ldapsearch operation: (&(objectClass=inetOrgPerson)(description:2.5.13.7:=*abcd)) but this results in a "Bad search filter (-7)". However if I write this without the joker it works: (&(objectClass=inetOrgPerson)(description:2.5.13.7:=abcd)) I don't see any restriction on matching rule extensible notation in RFC 4515 (http://tools.ietf.org/html/rfc4515). Is this syntax not implemented in OpenLDAP, or did I make a mistake in my filter ? Thank you in advance, DC

1 0

invalid value for attributeType objectClass
by limpteam＠gmail.com 31 Oct '13

31 Oct '13

Hello community! Have a Centos 6.4 server with new openldap 2.4.23-32.el6_4.1 installled. I'm new to ldap and just install it and configure for easy use. I edit only than 2 files olcDatabase={0}config.ldif and olcDatabase={2}bdb.ldif It's starts, I worked with it, add some OU and CN via phpLdapAdmin and tested it on Thunderbird. But after I decide to restart slapd i got error: PROXIED attributeDescription "DC" inserted. str2entry: invalid value for attributeType objectClass #0 (syntax 1.3.6.1.4.1.1466.115.121.1.38) slaptest: bad configuration file! and didn't start. it's problem with ppolicy and pwdAttribute? How can i solve this? Thanks for answer! P.S. Google can't help me or I just don't understand the whole theory.

2 1

About LDAP PAM authentication
by Ernesto Manuel Suarez Ojeda 30 Oct '13

30 Oct '13

Hi, I have 4 goals in configurating ldap pam authentication in my workstations Ubuntu 12.04 and 10.04: 1. Authenticate both ldap users and unix users. 2. Login using cached credentials when ldap server is down. 3. Warnings and dialog for password change when password expired or is about to expire. 4. Password length and complexity check. We have an openldap server with an operational ppolicy.schema and we need a comprehensive explanation about configuring Ubuntu clients for achieve this goals. I have read some documents but I'm not satisfied. Thanks, Ernesto Suárez Ojeda

1 0

OpenLDAP 2.4.26 SRPM for RHEL
by Aaron Bennett 30 Oct '13

30 Oct '13

Hi, Just in case anyone's using them, I've updated the SRPMS for our local build of OpenLDAP for RHEL/CentOS to 2.4.36. https://wordpress.clarku.edu/abennett/2012/03/16/openldap-src-rpms-for-rhel… It's basically as stock-as-possible, build against BDB 5.1.29 and OpenSSL. - Aaron --- Aaron Bennett Manager of Systems Administration Clark University ITS W:508.793.7315

2 1

limit on number of members in groupOfNames
by Dorit Eitan 30 Oct '13

30 Oct '13

2 2

Trouble with delta-syncrepl MMR: delta-sync lost sync on X, switching to REFRESH
by Patrick Lists 29 Oct '13

29 Oct '13

Hi, I'm trying to create a 2-node delta-syncrepl Multi-Master setup with the help of the Admin Guide, man pages and tests/scripts/test063-delta-multimaster. I see the following problem repeat on the "slave" master aka ldap02 which initially syncs with ldap01 aka the "primary" master: Oct 28 04:12:14 ldap02 slapd[9998]: do_syncrep2: rid=001 delta-sync lost sync on (reqStart=20131028012214.000002Z,cn=accesslog), switching to REFRESH I found ITS#7274 which mentions that some order should be changed (syncprov before olcServerID) but I have no idea how that applies to my setup. Being new to all this magic I came up empty. So here's my config. Hopefully it isn't too messed up :) I would appreciate it if someone could share a clue or 2 how to make this work. Comments on the config not related to the problem are also most welcome. OS: CentOS 6.4 x86_64 - clean install, all OpenLDAP dirs are empty OpenLDAP version: RE24 git rev f9e417a from around 10/23/2013. On the initial/"primary" master (note that the config is the same for the "slave" up to the comment): $ sudo /usr/local/sbin/slapadd -v -F $LDAP_ETC/slapd.d \ -l ./delta-syncrepl-MMR.ldif -n 0 $ cat ./delta-syncrepl-MMR.ldif # global configuration settings dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/openldap-2.4/slapd-2.4.args olcPidFile: /var/run/openldap-2.4/slapd-2.4.pid olcLogFile: /var/log/openldap-2.4/slapd-2.4.log olcLogLevel: conns stats stats2 sync olcTLSCACertificateFile: /etc/pki/tls/certs/DS-CA.crt olcTLSCertificateFile: /etc/pki/tls/certs/slapd.crt olcTLSCertificateKeyFile: /etc/pki/tls/private/slapd.key.crt olcTLSCipherSuite: TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!3DES:!RC4:@STRENGTH olcTLSVerifyClient: demand olcLocalSSF: 256 olcSecurity: ssf=256 olcPasswordCryptSaltFormat: $6$%s olcPasswordHash: {CRYPT} olcServerID: 1 ldap://ldap01 olcServerID: 2 ldap://ldap02 # load modules dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulePath: /usr/local/lib64/openldap-2.4 olcModuleload: {0}syncprov.la olcModuleload: {1}accesslog.la olcModuleLoad: {2}back_mdb.la olcModuleLoad: {3}back_monitor.la olcModuleLoad: {4}memberof.la olcModuleLoad: {5}refint.la olcModuleLoad: {6}ppolicy.la # schema definitions dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema # include the schemas include: file:///etc/openldap-2.4/schema/core.ldif include: file:///etc/openldap-2.4/schema/corba.ldif include: file:///etc/openldap-2.4/schema/cosine.ldif include: file:///etc/openldap-2.4/schema/duaconf.ldif include: file:///etc/openldap-2.4/schema/dyngroup.ldif include: file:///etc/openldap-2.4/schema/inetorgperson.ldif include: file:///etc/openldap-2.4/schema/java.ldif include: file:///etc/openldap-2.4/schema/misc.ldif include: file:///etc/openldap-2.4/schema/nis.ldif include: file:///etc/openldap-2.4/schema/openldap.ldif include: file:///etc/openldap-2.4/schema/ppolicy.ldif include: file:///etc/openldap-2.4/schema/collective.ldif # global database parameters dn: olcDatabase=frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: frontend # setup cn=config (password = 1234) dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW: {CRYPT}$6$... olcSyncrepl: {0}rid=001 provider=ldap://ldap01 binddn="cn=Manager,dc=test" bindmethod=sasl saslmech=external searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 schemachecking=off interval=00:00:00:5 retry="5 +" starttls=critical tls_cert=/etc/pki/tls/certs/Manager.crt tls_key=/etc/pki/tls/private/Manager.key.crt tls_cacert=/etc/pki/tls/certs/DS-CA.crt tls_reqcert=demand logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog olcSyncrepl: {1}rid=002 provider=ldap://ldap02 binddn="cn=Manager,dc=test" bindmethod=sasl saslmech=external searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 schemachecking=off interval=00:00:00:5 retry="5 +" starttls=critical tls_cert=/etc/pki/tls/certs/Manager.crt tls_key=/etc/pki/tls/private/Manager.key.crt tls_cacert=/etc/pki/tls/certs/DS-CA.crt tls_reqcert=demand logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog olcMirrorMode: TRUE olcAccess: to * by dn.exact="cn=Manager,dc=test" write by * none olcLimits: dn.exact="cn=Manager,dc=test" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # add the syncprov overlay to the cn=config database dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE # setup monitoring dn: olcDatabase=monitor,cn=config objectClass: olcDatabaseConfig objectClass: olcMonitorConfig olcDatabase: monitor olcAccess: to dn.subtree=cn=Monitor by dn.exact="cn=config" write by dn.exact="cn=Manager,dc=test" write by * none # setup Accesslog database definitions dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /var/lib/ldap-2.4/accesslog olcSuffix: cn=accesslog olcAccess: {0}to dn.subtree="cn=accesslog" by dn.exact="cn=Manager,dc=test" read olcRootDN: cn=Manager,dc=test olcDbIndex: objectClass,entryCSN,reqStart,reqEnd,reqResult,reqDN eq olcDbMode: 0600 # max size in bytes - 1GB = 1073741824 bytes olcDbMaxsize: 1073741824 # add the syncprov overlay to the cn=accesslog database dn: olcOverlay=syncprov,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE # up to here ^^^ is also the config for the "slave" # main mdb database definition dn: olcDatabase={3}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {3}mdb olcSuffix: dc=test olcDbDirectory: /var/lib/ldap-2.4/test olcRootDN: cn=Manager,dc=test olcRootPW: {CRYPT}$6$... olcSyncrepl: {0}rid=003 provider=ldap://ldap01 binddn="cn=Manager,dc=test" bindmethod=sasl saslmech=external searchbase="dc=test" type=refreshAndPersist retry="5 5 300 5" timeout=1 schemachecking=off interval=00:00:00:5 retry="5 +" starttls=critical tls_cert=/etc/pki/tls/certs/Manager.crt tls_key=/etc/pki/tls/private/Manager_nopass.key.crt tls_cacert=/etc/pki/tls/certs/DS-CA.crt tls_reqcert=demand logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog olcSyncrepl: {1}rid=004 provider=ldap://ldap02 binddn="cn=Manager,test" bindmethod=sasl saslmech=external searchbase="dc=test" type=refreshAndPersist retry="5 5 300 5" timeout=1 schemachecking=off interval=00:00:00:5 retry="5 +" starttls=critical tls_cert=/etc/pki/tls/certs/Manager.crt tls_key=/etc/pki/tls/private/Manager.key.crt tls_cacert=/etc/pki/tls/certs/DS-CA.crt tls_reqcert=demand logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog olcMirrorMode: TRUE olcDbIndex: cn pres,eq,sub olcDbIndex: gidNumber pres,eq olcDbIndex: mail pres,eq,sub olcDbIndex: memberUid pres,eq olcDbIndex: objectClass pres,eq olcDbIndex: ou pres,eq,sub olcDbIndex: sn pres,eq,sub olcDbIndex: uid pres,eq olcDbIndex: uidNumber pres,eq olcDbIndex: entryCSN,entryUUID eq olcDbMode: 0600 # max size in bytes - 1GB = 1073741824 bytes olcDbMaxSize: 5368709120 olcAccess: to attrs=userPassword by dn.exact="cn=Manager,dc=test" write by self write by anonymous auth by * none olcAccess: to * by dn.exact="cn=Manager,dc=test" write by self read by * read olcLimits: dn.exact="cn=Manager,dc=test" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited # add the syncprov overlay to the main mdb database dn: olcOverlay={0}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpCheckPoint: 20 10 # add the accesslog overlay to the main mdb database dn: olcOverlay={1}accesslog,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogSuccess: TRUE olcAccessLogPurge: 01+00:00 04+00:00 # add memberof overlay to mdb database dn: olcOverlay={2}memberof,olcDatabase={3}mdb,cn=config objectClass: olcConfig objectClass: olcMemberOf objectClass: olcOverlayConfig objectClass: top olcOverlay: memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfNames olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf # add refint overlay to mdb database dn: olcOverlay={3}refint,olcDatabase={3}mdb,cn=config objectClass: olcConfig objectClass: olcOverlayConfig objectClass: olcRefintConfig objectClass: top olcOverlay: refint olcRefintAttribute: member memberOf olcRefintNothing: cn=Manager,dc=test # add the ppolicy overlay to the main mdb database dn: olcOverlay={4}ppolicy,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: ppolicy olcPPolicyDefault: cn=default,ou=policies,dc=test olcPPolicyHashCleartext: TRUE $ sudo /usr/local/bin/ldapadd -v -f ./test-data.ldif x -D "cn=Manager,dc=test" -w $(cat ./ldap.secret) -d0 -ZZ # Organization dn: dc=test objectClass: dcObject objectClass: organization dc: test o: Test description: Test LDAP Root # add ppolicy ou dn: ou=policies,dc=test ou: policies objectClass: top objectClass: organizationalUnit # add password policy dn: cn=default,ou=policies,dc=test cn: default objectClass: pwdPolicy objectClass: pwdPolicyChecker objectClass: person objectClass: top pwdAllowUserChange: TRUE pwdAttribute: userPassword pwdCheckQuality: 2 pwdExpireWarning: 600 pwdFailureCountInterval: 30 pwdGraceAuthNLimit: 5 pwdInHistory: 5 pwdLockout: TRUE pwdLockoutDuration: 0 pwdMaxAge: 0 pwdMaxFailure: 5 pwdMinAge: 0 pwdMinLength: 5 pwdMustChange: FALSE pwdSafeModify: FALSE pwdCheckModule: check_password.so sn: dummy value ... Thanks! Regards, Patrick

4 6

Used port
by Muhammad Bashir Al-Noimi 29 Oct '13

29 Oct '13

Hello, As I know OpenLDAP uses by default 389. How can I be sure what if my server use it or not? -- Best Regards Muhammad Bashir Al-Noimi

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical