Search results for "starttls" - openldap-technical

Re: Ppolicy issues

by Tony Earnshaw

Bryan Payne skrev, on 21-02-2008 15:52: > If the account is locked, the user cannot login. If the password has > expired, the user can login. Not at my site. > I would like for it to prompt for the > password but it fails to work for linux machines using pam or windows > machines using pgina. How are your users logging in - at a CLI login, gdm, su, ssh? On all of these at my site the user gets prompted for his password. This *is* a pam matter. > I understand this is an openldap list so if you > tell me the issue is client side (and pam related) regarding changing > the password upon expiration, I'll take my question there. Have a look at (haven't forgotten you're using CentOS4) /etc/pam.d/system-auth, if in doubt about what the different libraries do, read the html docs. Pam login and password change sub-*mechanism*s can also defined in /etc/ldap.conf. Bits of what you're finding are pam related, bits are OL ppolicy. What happens if you comment out all the ppolicy-related stuff in slapd.conf? Are your users still not getting prompted for a password? > What about > notification of expiration? As it is right now, the user is never shown > if their password is expiring soon. It sends it to a log on the ldap > server, but nothing pops up on the client machine. Is this pam related too? No, purely OL ppolicy, works well at my site. Best, --Tonni -- > Buchan Milne wrote: >> On Wednesday 20 February 2008 17:10:00 Bryan Payne wrote: >> >>> Thank you for your help. I added the pwdPolicySubentry to a user to no >>> avail. I did find this in the logfile though: >>> >>> Feb 20 09:01:13 ldapserver slapd[6709]: conn=95289 op=4 SEARCH RESULT >>> tag=101 err=50 nentries=0 text=Operations are restricted to >>> bind/unbind/abandon/StartTLS/modify password >>> >>> So it looks like it's trying to do something but cannot. While I'm >>> concerned about password strength, I'm more concerned (at this point) >>> with just having the machine prompt for a password change. >> >> Well, what do you mean by "the machine" ? It looks like the password >> has expired, but if you're expecting a prompt for a password change, >> that's a client side issue. So, what is the client in this case? >> Recent versions of pam_ldap support ppolicy (IIRC including the one >> shipped with RHEL4), but you didn't say which client this is. >> >> Also, you said accounts get locked, but users can still log in? This >> sounds like you might not actually be using pam_ldap for >> authentication, but the pam_unix->nss_ldap (NIS replacement and >> nothing more) method, which won't see anything relating to ppolicy. >> >> Regards, >> Buchan >> > -- Tony Earnshaw Email: tonni at hetnet dot nl

16 years, 9 months

[SOLVED] Re: SLAPD 2.4.9 and OpenSSL 0.9.8g on Ubuntu 8.04 server - client certificate not read

by Hauke Coltzau

Hi everybody, thank you all for your immediate replies. As you correctly pointed out, the options I used were wrong. With following ldap.conf, everything works out fine. base dc=... URI ldaps://<fqdn of ldap server>/ ldap_version 3 rootbinddn cn=... bind_policy soft pam_password md5 TLS_REQCERT yes TLS_CACERT /usr/lib/ssl/certs/<ca>.chain.crt The ldap.conf I used before has been created by dpkg-reconfigure and I simply changed the default values there. That was a mistake ;-) Creating a new ldap.conf from scratch with a man-page at hand obviously did the trick. Thank you very much for your help, Best regards, Hauke -- ----- Ursprüngliche Mail ----- Von: "Howard Chu" <hyc(a)symas.com> An: "Hauke Coltzau" <hauke.coltzau(a)FernUni-Hagen.de> CC: "openldap-technical" <openldap-technical(a)openldap.org> Gesendet: Mittwoch, 27. August 2008 20:37:44 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien Betreff: Re: SLAPD 2.4.9 and OpenSSL 0.9.8g on Ubuntu 8.04 server - client certificate not read Hauke Coltzau wrote: > Hello everybody, > > I'm just trying to set up a LDAPS server using my own > certification authority, but the ldap server does not > accept/understand my client certificate. Instead, the server > sais: > > TLS: can't accept: The peer did not send any certificate.. > Here are the details: > > Client: > ======= > > # ldapsearch -x -LLL -ZZ -d 1 > > ldap_create > ldap_extended_operation_s > ldap_extended_operation > ldap_send_initial_request > ldap_new_connection 1 1 0 > ldap_int_open_connection > ldap_connect_to_host: TCP<serverip>:636 > ldap_new_socket: 3 > ldap_prepare_socket: 3 > ldap_connect_to_host: Trying<serverip>:636 > ldap_pvt_connect: fd: 3 tm: -1 async: 0 > TLS: can't connect: A TLS packet with unexpected length was received.. > ldap_err2string > ldap_start_tls: Can't contact LDAP server (-1) > > > Server: > ======== > > # slapd -VV > @(#) $OpenLDAP: slapd 2.4.9 (Aug 1 2008 01:09:46) $ > buildd@king:/build/buildd/openldap2.3-2.4.9/debian/build/servers/slapd > > > # slapd -h "ldaps://<ip>/" -u openldap -g openldap -d 127 You cannot use StartTLS (ldapsearch -Z) with an ldaps:// server, it's redundant. > ldap.conf (partially) > --------------------- > > uri ldaps://132.176.4.6/ > ssl yes > tls_cacertfile /usr/lib/ssl/cacartes/<ca>.chain.crt > tls_ciphers TLSv1 The above 3 keywords are not valid for ldap.conf. Read the ldap.conf(5) manpage. > tls_cert /usr/lib/ssl/certs/<clientfqdn>.cert.pem > tls_key /usr/lib/ssl/private/<clientfqdn>.key.pem > What did I do wrong? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- ------------------------------------ Fernuniversität in Hagen Lehrgebiet Kommunikationsnetze http://www.fernuni-hagen.de/kn Fon/Fax: +49 2331 987 -1142 / -353 ------------------------------------

16 years, 3 months

Re: Proxycache overlay to back-ldap with cn=config

by Nicolas Brisac

Sorry to bump on my own question... Does anyone have an idea how I could solve this? Nico Hi, I'm trying to set up a proxy-cache to a couple of OpenLDAP servers configured in mirror mode. The back-ldap part is working fine and I can query the underlying slapd instances through the proxy. However, I'm still struggling with the caching bit. I couldn't find any documentation or posts related to setting this up using the new cn=config way of configuring LDAP. So after some reading and a bit of guessing, I came up with the following config: # {1}ldap, config dn: olcDatabase={1}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {1}ldap olcSuffix: dc=sol1,dc=net olcAccess: {0}to dn.base="" by * read olcAccess: {1}to dn.base="cn=Subschema" by * read olcAccess: {2}to * by self write by users read by anonymous auth olcRootDN: uid=ldapadmin,dc=sol1,dc=net olcRootPW: secret olcDbURI: "ldap://192.168.200.12 ldap://192.168.200.14" olcDbACLBind: bindmethod=simple binddn="uid=ldapadmin,dc=sol1,dc=net" credentials="secret" starttls=no # {0}pcache, {1}ldap, config dn: olcOverlay={0}pcache,olcDatabase={1}ldap,cn=config objectClass: olcOverlayConfig objectClass: olcPcacheConfig olcOverlay: {0}pcache olcPcache: bdb 10000 3 1000 100 olcPcacheAttrset: 0 uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass olcPcacheAttrset: 1 sudoCommand sudoHost olcPcacheAttrset: 2 gidNumber olcPcacheTemplate: (&(objectClass=)(uid=)) 0 300 olcPcacheTemplate: (sudoUser=) 1 300 olcPcacheTemplate: (&(objectClass=)(memberUid=)) 2 300 # {2}bdb, config dn: olcDatabase={2}bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {2}bdb olcDbDirectory: /var/lib/ldap/cache olcSuffix: cn=proxy olcRootDN: uid=ldapadmin,dc=sol1,dc=net olcDbCacheSize: 5000 olcDbConfig: {0}set_cachesize 0 2097152 0 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbIndex: objectClass eq olcDbIndex: uid eq olcDbIndex: cn eq olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbIndex: memberUid eq olcDbIndex: uniqueMember eq olcDbIndex: mail eq olcDbIndex: surname eq olcDbIndex: givenname eq olcDbIndex: sambaSID eq olcDbIndex: sambaPrimaryGroupSID eq olcDbIndex: sambaDomainName eq olcDbIndex: sudoUser eq But running ldapsearch keeps returning: # search result search: 2 result: 52 Server is unavailable text: pcachePrivDB: cacheDB not available I didn't find any way to specify which database to use when declaring the overlay, apart from the 'bdb' part of olcPcache, but that seems to be interpreted as the database type, not its name (I've tried replacing it with cn=proxy, but that throws an error). Looking at the pcache overlay source (I'm running 2.4.21 from Ubuntu Lucid and also checked the latest 2.4.23 stable source), I can see this bit: { "pcache-", "private database args", 1, 0, STRLENOF("pcache-"), ARG_MAGIC|PC_PRIVATE_DB, pc_cf_gen, NULL, NULL, NULL }, That seems to be for the private DB options, but the other equivalent "pcacheXXXX" in this file have the corresponding attribute declaration for the schema instead of 'NULL, NULL, NULL'. Anyway, I'm obviously missing something :) If someone who's got this working or a developer could point me in the right direction, that would be greatly appreciated! Thanks, Nico

14 years, 3 months

problem with syncrepl and STARTTLS

by r0m5

Hello, I am facing an issue with syncrepl and STARTTLS on 389 port. The kind of problem happening only sometimes, and disappearing "by itself". I use Debian Jessie, OpenLDAP 2.4.40+dfsg-1+deb8u2. Description : I have a production environment, and a preproduction environment. Both of them consist of one provider and multiple consumers. Right now all is working fine. Then 2 times a days a script injects the production data in the preproduction environment : ldapsearch on prod / ldapdelete on preprod / stop slapd on preprod / slapadd on preprod / start slapd on preprod. Then sometimes during this injection I get a problem : one or more of the consumers in preprod fail to sync. But sometimes all are OK. Then the consumers facing the issue succeed syncrepl again "by themselves" after a few dozens of minutes / hours. If I restart slapd on the failing consumers, then the syncrepl succeeds immediately. When the syncrepl is failing, I can still perform an ldapsearch using STARTTLS and the syncrepl binding credentials from the consumer to the provider. There is no issue with non-TLS LDAP replications. Also, using ldapsearch with option "-d 3" I get TLS debug, but even with "olcLogLevel -1" in cn=config I can't get precise debug for TLS during syncrepl. I captured the trafic and when there is the error, wireshark at some point can't understand TLS sent by the consumer (SSL "ignored unknown record"). Corresponding data is "30 05 02 01 02 42 00". Not sure it's related to the problem though, but it looks like since (if I am right) the first information in TLS is the content-type, and 30 is not a valid value for content type (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-pa…). Any idea ? I would like to avoid making the injection script connect to all my preprod consumers and restart slapd on them. Please feel free to ask for more logs / configurations. Log on the provider : May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: slap_listener_activate(9): May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 busy May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: >>> slap_listener(ldap:///) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: listen=9, new connection on 18 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: added 18r (active) listener=(nil) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 fd=18 ACCEPT from IP=192.168.115.61:33816 (IP=0.0.0.0:389) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: 18r May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: read active on 18 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18): got connid=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_read(18): checking for input on id=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: op tag 0x77, time 1496231248 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 op=0 do_extended May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 op=0 EXT oid=1.3.6.1.4.1.1466.20037 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: do_extended: oid=1.3.6.1.4.1.1466.20037 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 op=0 STARTTLS May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: send_ldap_extended: err=0 oid= len=0 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: send_ldap_response: msgid=1 tag=120 err=0 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 op=0 RESULT oid= err=0 text= May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: 18r May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: read active on 18 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18): got connid=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_read(18): checking for input on id=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: 18r May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: read active on 18 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18): got connid=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_read(18): checking for input on id=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_read(18): unable to get TLS client DN, error=49 id=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 fd=18 TLS established tls_ssf=128 ssf=128 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 2 descriptors May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: 18r May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: read active on 18 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_get(18): got connid=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_read(18): checking for input on id=1010 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: ber_get_next on fd 18 failed errno=0 (Success) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_read(18): input error=-2 id=1010, closing. May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_closing: readying conn=1010 sd=18 for close May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: connection_close: conn=1010 sd=18 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: removing 18 May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: conn=1010 fd=18 closed (connection lost) May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=12 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-master-pp slapd[5828]: daemon: epoll: listen=13 active_threads=0 tvp=zero Log on the consumer : May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: =>do_syncrepl rid=006 May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: epoll: listen=11 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: slap_client_connect: URI=ldap://ldap-master-pp.acme Error, ldap_start_tls failed (-11) May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: do_syncrepl: rid=006 rc -11 retrying May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: activity on 1 descriptor May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: activity on: May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: epoll: listen=9 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: epoll: listen=10 active_threads=0 tvp=zero May 31 13:47:28 lxc-sd-ldap-replica-pp-prim slapd[32753]: daemon: epoll: listen=11 active_threads=0 tvp=zero syncrepl config on consumer : olcSyncrepl: {0}rid=6 provider=ldap://ldap-master-pp.acme starttls=critical t ls_reqcert=never bindmethod=simple binddn="cn=replication,ou=Applications,d c=acme,dc=fr" credentials=**** searchbase="dc=acme,dc=fr" schemacheck ing=off type=refreshAndPersist filter="(objectClass=*)" attrs="*" scope=sub retry="60 +" TLS config on provider : dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcPidFile: /var/run/slapd/slapd.pid olcToolThreads: 1 structuralObjectClass: olcGlobal entryUUID: 9efabaca-b31f-1036-9746-2d4f8feb88f1 creatorsName: cn=config createTimestamp: 20170411162820Z olcTLSCertificateFile: /etc/ssl/certs/ssl-cert-snakeoil.pem olcTLSCertificateKeyFile: /etc/ssl/private/ssl-cert-snakeoil.key olcLogLevel: 256 entryCSN: 20170531131949.877388Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20170531131949Z

7 years, 5 months

delta-synrepl consumer randomly delete objects

by Raffael Sahli

Hi What can lead a consumer to "randomly" delete ~50% of all objects in his database? I have this problem now for ~1-2months and on 3 different master/slave groups. The consumer starts to delete objects (but those are all present on the master): Oct 19 17:16:22 ldap-slave002.xxx slapd[8554]: do_syncrep2: rid=999 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Oct 19 17:16:22 ldap-slave002.xxx slapd[8554]: do_syncrep2: rid=999 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 9c802b18-7c2c-1033-9f25-2d4a65066d19, dn uid=jasmin.mans,ou=none,o=dd,dc=xxx,dc=xxx Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 650ada00-e996-1035-80ac-a173474274df, dn uid=jasmine.suddr,ou=none,o=dd,dc=xxx,dc=xxx Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID ec5c9aa4-7c2c-1033-9fa4-2d4a65066d19, dn uid=jonas.beffrnn,ou=none,o=dd,dc=xxx,dc=xxx Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 7461d22e-e996-1035-80f6-a173474274df, dn uid=juerg.klegegeli,ou=none,o=dd,dc=xxx,dc=xxx Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 758c744c-e996-1035-8100-a173474274df, dn uid=julia.sxgegegea,ou=none,o=dd,dc=xxx,dc=xxx Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 47e4f6b4-7c2d-1033-8015-2d4a65066d19, dn uid=karin.vivwvwe,ou=none,o=dd,dc=xxx,dc=xxx Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 8d26a4f2-7c2d-1033-807b-2d4a65066d19, dn uid=larissa.fewfewf,ou=none,o=dd,dc=xxx,dc=xxx Oct 19 17:16:24 ldap-slave002.xxx slapd[8554]: nonpresent_callback: rid=999 nonpresent UUID 98310aa4-7c2d-1033-808b-2d4a65066d19, dn uid=laura.cfwfew,ou=none,o=dd,dc=xxx,dc=xxx syncrepl config: olcSyncrepl: {0}rid=999 provider=ldap://ldap-master002.xxx.xxx:389 bindmethod=simple timeout=0 network-timeout=10 binddn="uid=replicator,ou=system,o=de,dc=xxx,dc=xxx" credentials="pass" keepalive=0:0:0 starttls=yes tls_cacert="/etc/ssl/certs/SwissSign_Silver_CA_-_G2.pem" tls_reqcert=allow filter="(objectClass=*)" searchbase="dc=xxx,dc=xxx" scope=sub attrs="*,+" syncdata="accesslog" logbase="cn=accesslog_xxx" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=off type=refreshOnly interval="00:00:01:00" retry="10 5 60 +" Misconfiguration? (We've been running this configuration for years...) Workaround is to remove the whole mdb database and restart slapd to let it resync. I've found some posts with a similar problem but those are all related to pre 2.4.21, we're running slapd 2.4.44. Cheers

8 years, 1 month

ppolicy overlay - not seeming to function?

by John Cooter

So, before I ask my question, here are my referenced objects, from a "slapcat -n 0": dn: olcDatabase={2}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /var/lib/ldap olcDbIndex: objectClass eq,pres olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub structuralObjectClass: olcHdbConfig entryUUID: eb941fcc-bef3-1036-9d74-0d6e032eb747 creatorsName: cn=config createTimestamp: 20170426174545Z olcAccess: {0}to dn.base="" by self write by dn="cn=ldapadmin,dc=XXXXXXX ,dc=net" write by * read olcAccess: {1}to * by self write by dn="cn=ldapadmin,dc=XXXXXXX,dc=net" w rite by * read olcAccess: {2}to dn.subtree="ou=mail,ou=hosting,dc=XXXXXXX,dc=net" attrs= userPassword,UseAppPassword,children,entry,objectClass,cn,sn,uid by self w rite by dn="cn=ldapadmin,dc=XXXXXXX,dc=net" write by * auth by * read olcSuffix: dc=XXXXXXXX,dc=net olcRootDN: cn=ldapadmin,dc=XXXXXXX,dc=net olcRootPW:: e1NTSEF9K2p6YnhXL0xQTDJKZFFIZitac3l6RzVXaEN3UEhQUkc= entryCSN: 20170508155547.001404Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20170508155547Z dn: olcOverlay={0}ppolicy,olcDatabase={2}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {0}ppolicy olcPPolicyDefault: cn=passwordDefault,ou=policies,dc=XXXXXXX,dc=net olcPPolicyHashCleartext: FALSE olcPPolicyUseLockout: FALSE olcPPolicyForwardUpdates: FALSE structuralObjectClass: olcPPolicyConfig the passwordDefaul policy exists in the correct location, and appears to apply to all user objects BUT when I change a user object to a value that either violates the base policy (say, has only 4 characters instead of 5 or more), or would not conform to the check_password.so function, as established by various outside sources, it does not give me an error of any kind, and instead, writes the password to the DB and writes the following to the log: May 10 11:00:05 ldapv slapd[1984]: conn=1007 op=0 EXT oid=1.3.6.1.4.1.1466.20037 May 10 11:00:05 ldapv slapd[1984]: conn=1007 op=0 STARTTLS May 10 11:00:05 ldapv slapd[1984]: conn=1007 op=0 RESULT oid= err=0 text= May 10 11:00:06 ldapv slapd[1984]: conn=1007 fd=11 TLS established tls_ssf=256 ssf=256 May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=1 BIND dn="cn=ldapadmin,dc=XXXXXXX,dc=net" method=128 May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=1 BIND dn="cn=ldapadmin,dc=XXXXXXX,dc=net" mech=SIMPLE ssf=0 May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=1 RESULT tag=97 err=0 text= May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=2 MOD dn="uid=USER,cn=TESTDOMAIN.com,ou=domain,ou=mail,ou=hosting,dc=XXXXXXX,dc=net" May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=2 MOD attr=userPassword May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=2 RESULT tag=103 err=0 text= And the entry, as referenced by phpLDAPadmin, appears to correspond to the "bad" password. How can I go about confirming that the password policy is being enforced?

7 years, 6 months

Delta-syncrepl not syncing entire directory: Entry CSN greater than snapshot

by Pedro Roger

Hello, i'm trying to setup a master/slave replication via delta-syncrepl, but for the most of the entries i get the message: "Entry CSN greater than snapshot". I had search in the archive of the mail list but i couldn't get a solution for this. Any help is appreciate. Some entrie i get in the syslog: Oct 20 20:23:57 temperance slapd[7645]: Entry uid=ari_oliveira,ou=uvanet.br,ou=mail,dc=uvanet,dc=br CSN 20151015141738.689470Z#000000#000#000000 greater than snapshot 20150709142425.146445Z#000000#000#000000 Oct 20 20:23:57 temperance slapd[7645]: Entry cn=SAPLIC,ou=groupOfNames,ou=intranet,dc=uvanet,dc=br CSN 20151020152042.450209Z#000000#000#000000 greater than snapshot 20150709142425.146445Z#000000#000#000000 Oct 20 20:23:57 temperance slapd[7645]: Entry cn=SIGU,ou=groupOfNames,ou=intranet,dc=uvanet,dc=br CSN 20151020152042.636081Z#000000#000#000000 greater than snapshot 20150709142425.146445Z#000000#000#000000 I have the following config in the provider (slapd 2.4.23): ... moduleload accesslog.la moduleload syncprov.la database hdb suffix cn=accesslog directory /opt/ldap/accesslog rootdn cn=accesslog index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart eq dbconfig set_cachesize 0 2097152 0 dbconfig set_lk_max_objects 1500 dbconfig set_lk_max_locks 1500 dbconfig set_lk_max_lockers 1500 overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE database hdb suffix "dc=uvanet,dc=br" rootdn "xxxxxx" directory "/var/lib/ldap" overlay syncprov syncprov-checkpoint 1000 60 #syncprov-checkpoint 500 30 syncprov-reloadhint TRUE syncprov-sessionlog 500 # accesslog overlay definitions for primary db overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE # scan the accesslog DB every day, and purge entries older than 7 days logpurge 07+00:00 01+00:00 index objectClass eq,pres index ou,cn,sn,mail,givenname eq,pres,sub index uidNumber,gidNumber,memberUid eq,pres index loginShell eq,pres index memberOf eq ## required to support pdb_getsampwnam index uid pres,sub,eq # required to support pdb_getsambapwrid() index displayName pres,sub,eq index nisMapName,nisMapEntry eq,pres,sub index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index default sub index uniqueMember eq index sambaGroupType eq index sambaSIDList eq # syncprov specific indexing index entryUUID eq index entryCSN eq overlay memberof In the consumer server we have: syncrepl rid=1 provider=ldap://X.X.X.X type=refreshAndPersist retry="5 + 5 +" interval=00:00:00:01 searchbase="dc=uvanet,dc=br" filter="(objectClass=*)" scope=sub starttls=no logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog attrs="*" schemachecking=on bindmethod=simple binddn="XXXX" credentials="XXXX" # Refer updates to the master updateref ldap://X.X.X.X Thanks in advance -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Pedro Roger Magalhães Vasconcelos http://www.proger.eti.br

9 years, 1 month

Re: MirrorMode sync only happening in one direction

by Daniel Qian

On 11-09-22 7:37 PM, Howard Chu wrote: > Daniel Qian wrote: >> The problem direction has the same syncrepl configuration as the working >> one except for the rid and provider name: >> >> olcSyncrepl: {0} >> rid=102 provider="ldap://server2.prod:389/" >> type=refreshAndPersist >> retry="60 30 300 +" >> keepalive=1200:10:3 >> searchbase="dc=mydomain,dc=com" >> bindmethod=simple >> binddn="cn=replica,dc=mydomain,dc=com" >> credentials=xxxxxx >> starttls=critical >> tls_cacert="/etc/pki/CA/cacert.pem" >> >> On the consumer side I am seeing these messages: >> >> Sep 22 22:02:02 ldaprov1 slapd[15466]: do_syncrep2: rid=102 got search >> entry without Sync State control >> Sep 22 22:02:02 ldaprov1 slapd[15466]: do_syncrepl: rid=102 rc -1 >> retrying (29 retries left) >> >> and on the provider side I am seeing these: > > >> The sync connection is supposed to be persistent but it keeps closing >> down and reconnecting. >> >> Anyone know what could be the reason? > > Obviously your "provider side" doesn't actually have the syncprov > overlay configured. > I put the exact same configuration for syncprov on two servers [root@localhost cn=config]# ldapsearch -LLL -b cn=config -D cn=admin,cn=config -W -ZZ -h ldaprov1.prod cn=module{0} Enter LDAP Password: dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap olcModuleLoad: {0}syncprov [root@localhost cn=config]# ldapsearch -LLL -b cn=config -D cn=admin,cn=config -W -ZZ -h ldaprov2.prod cn=module{0} Enter LDAP Password: dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap olcModuleLoad: {0}syncprov [root@localhost cn=config]# ls /usr/lib64/openldap accesslog-2.4.so.2 constraint-2.4.so.2 dyngroup-2.4.so.2 pcache-2.4.so.2 retcode-2.4.so.2 smbk5pwd-2.4.so.2 translucent-2.4.so.2 accesslog-2.4.so.2.6.0 constraint-2.4.so.2.6.0 dyngroup-2.4.so.2.6.0 pcache-2.4.so.2.6.0 retcode-2.4.so.2.6.0 smbk5pwd-2.4.so.2.6.0 translucent-2.4.so.2.6.0 accesslog.la constraint.la dyngroup.la pcache.la retcode.la smbk5pwd.la translucent.la auditlog-2.4.so.2 dds-2.4.so.2 dynlist-2.4.so.2 ppolicy-2.4.so.2 rwm-2.4.so.2 sssvlv-2.4.so.2 unique-2.4.so.2 auditlog-2.4.so.2.6.0 dds-2.4.so.2.6.0 dynlist-2.4.so.2.6.0 ppolicy-2.4.so.2.6.0 rwm-2.4.so.2.6.0 sssvlv-2.4.so.2.6.0 unique-2.4.so.2.6.0 auditlog.la dds.la dynlist.la ppolicy.la rwm.la sssvlv.la unique.la collect-2.4.so.2 deref-2.4.so.2 memberof-2.4.so.2 refint-2.4.so.2 seqmod-2.4.so.2 syncprov-2.4.so.2 valsort-2.4.so.2 collect-2.4.so.2.6.0 deref-2.4.so.2.6.0 memberof-2.4.so.2.6.0 refint-2.4.so.2.6.0 seqmod-2.4.so.2.6.0 syncprov-2.4.so.2.6.0 valsort-2.4.so.2.6.0 collect.la deref.la memberof.la refint.la seqmod.la syncprov.la valsort.la Can you tell what is missing on one of the two servers? Is there a command to tell if the module is actually loaded into the execution space? Thanks, Daniel

13 years, 2 months

Re: Security between server and client nodes.

by Jayavant Patil

>>On 11/30/2011 08:01 AM, Jayavant Patil wrote: >> >> >> On Tue, Nov 29, 2011 at 6:26 PM, Jayavant Patil >> <jayavant.patil82(a)gmail.com <mailto:jayavant.patil82@gmail.com>> wrote: >> >> >> >>Mon, 28 Nov 2011 11:25:16 +0100 Raffael Sahli >> <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>> wrote: >> >>Hi >> >> >>I think you mean SSL connection or the STARTTLS Layer...? >> >>Please read the manual http://www.openldap.org/doc/admin24/tls.html >> >Ok. >> >> >>And tree security: >> >>On my server, a client user can only see his own object: >> >Are you using simple authentication mechanism? >> >> >>Maybe create a rule like this: >> >>access to filter=(objectClass= >> >>simpleSecurityObject) >> >> by self read >> >> by * none >> >> >I am not getting what the ACL rule specifies. Any suggestions? >> >> >> I have two users ldap_6 and ldap_7. I want to restrict a user to >> see his own data only. >> In slapd.conf, I specified the rule as follows: >> access to * >> by self write >> by * none >> >> But ldap_6 can see the ldap_7 user entries (or vice versa) with >> $ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b >> "ou=People,dc=abc,dc=com" "uid=ldap_7" >> >> Any suggestions? >> >On Wed, 30 Nov 2011 08:38:32 +0100 Raffael Sahli <public(a)raffaelsahli.com> wrote: >Yes, that's exactly the rule I wrote above. >access to filter=(objectClass= >simpleSecurityObject) > by self read > by * none >Maybe you have to change the objectClass to posixAccount, or both or >whatever.... >access to >filter=(|(objectClass=simpleSecurityObject)(objectClass=posixAccount)) > by self read > by * none >Just add this rule before the global rule "access to *" >>ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b >>"ou=People,dc=abc,dc=com" "uid=ldap_7" >And if you search like this with bind "admin dn", you will see every >object.... >You have to bind with user ldap_6 and not with root But anyway client user knows the admin dn and rootbindpassword. So, with this he will look into all directory information to which he is not supposed to do. e.g. ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -w cluster So, how to avoid this? -- Thanks & Regards, Jayavant Ningoji Patil Engineer: System Software Computational Research Laboratories Ltd. Pune-411 004. Maharashtra, India. +91 9923536030.

12 years, 12 months

mmr pair stops replicating: "consumer state is newer than provider"

by btb

hi. i have two servers, in an mmr arrangement, using delta-syncrepl. on a couple of occasions, the servers have stopped replicating, and the following is logged: dsa1: Jun 27 06:13:29 ldap0 slapd[8699]: do_syncrep2: rid=000 LDAP_RES_SEARCH_RESULT Jun 27 06:13:29 ldap0 slapd[8699]: do_syncrep2: rid=000 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Jun 27 06:13:29 ldap0 slapd[8699]: do_syncrep2: rid=000 (53) Server is unwilling to perform Jun 27 06:13:29 ldap0 slapd[8699]: do_syncrepl: rid=000 rc -2 retrying dsa2: Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 fd=9 ACCEPT from IP=10.200.41.20:49141 (IP=0.0.0.0:389) Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=0 STARTTLS Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=0 RESULT oid= err=0 text= Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 fd=9 TLS established tls_ssf=256 ssf=256 Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=1 BIND dn="uid=dsa1_slapd-repl-content,ou=dsa1.example.org,ou=services,ou=accounts,dc=example,dc=org" method=128 Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=1 BIND dn="uid=dsa1_slapd-repl-content,ou=dsa1.example.org,ou=services,ou=accounts,dc=example,dc=org" mech=SIMPLE ssf=0 Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=1 RESULT tag=97 err=0 text= Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=2 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=3 UNBIND Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 fd=9 closed if i reload data and restart replication, things work again, for a period of time, but then this happens again. what determines "consumer state is newer than provider"? i'm also a little bit confused about this message in the context of mmr. if one has newer data than the other, i had sort of expected that the newer data would replace the old [obviously it's not that simple, so i'd like to understand what i'm missing]. lastly, how can i further troubleshoot why this happened in the first place? i'm using 2.4.44 on freebsd, built from ports. i can provide any config details etc - i just didn't want to inundate the post with guesses on detail that might not be relevant. thanks -ben

7 years, 5 months

openldap-technical search results for query "starttls"