openldap-technical

openldap-technical@openldap.org

11 participants
9876 discussions

Syncrepl issues, "glue" objectClass
by Mark Cairney 17 Jun '11

17 Jun '11

Hi, I've been trying to use a tool called "Grouper" to provision a hierarchical structure into my LDAP directory. I'm currently running OpenLDAP 2.4.25 with BDB 4.8.30 on 3 SL5.5 servers in a multi-master configuration. During the provisioning process it seems to be hitting a race condition where it creates a higher-level ou before the base-level ou is there resulting in the base-level ou existing in the tree with the "glue" objectClass. As this is invisible to searches I end up with syncrepl constantly trying to replicate it ad infinitum: Jun 10 14:53:16 alder slapd[20702]: syncrepl_entry: rid=031 be_modify ou=2010/2011,ou=courses,ou=grouper,dc=authorise,dc=ed,dc=ac,dc=uk (0) Jun 10 14:53:16 alder slapd[20702]: syncprov_sendresp: cookie= Jun 10 14:53:16 alder slapd[20702]: do_syncrep2: rid=032 cookie= Jun 10 14:53:16 alder slapd[20702]: do_syncrep2: rid=031 cookie= Jun 10 14:53:16 alder slapd[20702]: syncrepl_entry: rid=032 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) Jun 10 14:53:16 alder slapd[20702]: syncrepl_entry: rid=032 be_search (0) Jun 10 14:53:16 alder slapd[20702]: syncrepl_entry: rid=032 ou=2010/2011,ou=courses,ou=grouper,dc=authorise,dc=ed,dc=ac,dc=uk Jun 10 14:53:16 alder slapd[20702]: syncrepl_entry: rid=031 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) Jun 10 14:53:16 alder slapd[20702]: syncrepl_entry: rid=031 be_search (0) Jun 10 14:53:16 alder slapd[20702]: syncrepl_entry: rid=031 ou=2010/2011,ou=courses,ou=grouper,dc=authorise,dc=ed,dc=ac,dc=uk Jun 10 14:53:16 alder slapd[20702]: syncprov_sendresp: cookie= Jun 10 14:53:17 alder last message repeated 210 times Jun 10 14:53:17 alder slapd[20702]: syncrepl_entry: rid=032 be_modify ou=2010/2011,ou=courses,ou=grouper,dc=authorise,dc=ed,dc=ac,dc=uk (0) Jun 10 14:53:17 alder slapd[20702]: do_syncrep2: rid=032 cookie= Jun 10 14:53:17 alder slapd[20702]: syncrepl_entry: rid=032 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) Doing a bit of digging on the web the suggested solution is to modify the object and remove the glue objectlcass but there doesn't seem to be an obvious way to do this given that it's invisible to ldapsearch and if you try an ldapadd the object already exists? Even a sample ldif file for ldapmodify would be grand. Cheers, Mark /********************************* Mark Cairney ITI UNIX Section Information Services University of Edinburgh Tel: 0131 650 6565 Email: mark.cairney(a)ed.ac.uk *********************************/ -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

2 3

allow or deny certain user access to certain hosts
by Hai Tao 16 Jun '11

16 Jun '11

I like to deny certain ldap user from ssh to certain hosts. I wonder how this can be done? Is there a way to associate with the /etc/security/access.conf file with ldap? Thanks. Hai Tao

1 0

Support Reverse Group Membership Maintenance for OpenLDAP 2.3
by Pedro Rodrigo Cardiel 16 Jun '11

16 Jun '11

Hello, I have some doubts about a topic openldap. I am working with groups in ldap and I have the need to ask users of a certain group. I have read that when you ask you can only filter by the field name and the value of this. And there is a way that when you add a user to a group, plus add the field member in the object group, adds a field memberOf to the object person. This is named "Reverse Group Membership Maintenance". I understand that I have to load a module in openldap of this way "moduleload memberof.la" but openldap can not find it. I have seen on the internet there is a package to install that module to the version 2.4. My question is: Does the openfire version 2.3 supports this functionality? I use: Centos Linux ia3 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:53:09 EST 2011 i686 i686 i386 GNU/Linux. Installed Packages Name : openldap Arch : i386 Version : 2.3.43 Release : 12.el5_6.7 Size : 593 k Repo : installed Regards -- ----------------------------------------------------------- Pedro Rodrigo Cardiel Programador Senior GeoSLab Logo C/ Carlos Marx, 6 CP 50015 Zaragoza (Spain) Tlf: +34 976 762134 +34 976 065152 Fax: +34 976 106201 prodrig(a)GeoSLab.com <mailto:suzarso@GeoSLab.com> http://www.GeoSLab.com Follow us on Twitter <http://twitter.com/GeoSLab> ------------------------------------------------------------------------ / Antes de imprimir este correo piensa si realmente es necesario hacerlo / Before printing this email, assess if it is really needed / / ---- ADVERTENCIA ---- La información contenida en este correo electrónico, y en su caso, cualquier fichero anexo al mismo, son de carácter privado y confidencial siendo para uso exclusivo de su destinatario. Si usted no es el destinatario correcto, el empleado o agente responsable de entregar el mensaje al destinatario, o ha recibido esta comunicación por error, le informamos que está totalmente prohibida cualquier divulgación, distribución o reproducción de esta comunicación según la legislación vigente y le rogamos que nos lo notifique inmediatamente, procediendo a su destrucción sin continuar su lectura. / / ---- WARNING ---- Information contained in this email, and any attached files, are private and confidential for the addressee. If you are not the intended recipient, employee or agent responsible for delivering this message to the addressee, or have received this communication by mistake, please be aware that any dissemination, distribution or duplication under current laws is forbidden and we request you to notify us immediately and destroy the message without continue reading. / ------------------------------------------------------------------------

2 1

parse_syncrepl_line: unable to parse "bindmethod=sasl"
by devendra ayalasomayajula 16 Jun '11

16 Jun '11

I am trying to setup mirror mode configuration setup. Attempted to set bindmethod to sasl and I see following error when slapd starts. invalid bind config value bindmethod=sasl /home/y/conf/atlas/slapd_ldapmaster.conf: line 62: Error: parse_syncrepl_line: unable to parse "bindmethod=sasl" . failed to add syncinfo slapd destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy. The setups runs fine when bindmethod is set to simple. Appreciate any info on why this is failing. --dev

2 1

slapd is pinned at 100% utilization
by Bryce Powell 16 Jun '11

16 Jun '11

Hi, I have two OpenLDAP 2.4.11 servers, using BDB 4.6.21 (Patches 4.6.21.1 & 4.6.21.2 & 4.6.21.3 applied), hosted on CentOS 5.2, setup for multi-master replication. Works great except that every couple of months either one of the slapd servers will pin the CPU at 100%. Requests continue to be served without any noticeable degradation in response, and no discernable errors in the LDAP logs. I see the forums frequently mention CPU utilization issues, but most of the time this seems to be related to non-indexed queries, which I don't believe is the cause in this case. Restarting slapd resolves the issue, temporarily ... Any suggestions would be appreciated. Regards, Bryce Powell

2 1

schema replication problems with test059-slave-config
by Christopher Strider Cook 16 Jun '11

16 Jun '11

I have a setup based on the one created in test059-slave-config, but complicating matters, the providers are a mirrormode pair. Running 2.4.25 under Debian Squeeze. On this pair I have cn=config,cn=slave created as laid out in test059-slave-config, with additional syncing to allow mirrormode operation. dn: olcDatabase={2}ldif,cn=config objectClass: olcConfig objectClass: olcDatabaseConfig objectClass: olcLdifConfig objectClass: top olcDatabase: {2}ldif olcDbDirectory: /var/lib/ldap-slave-config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=extern al,cn=auth manage by * break olcAccess: {1}to * by dn.base="cn=admin,dc=savagebeast,dc=com" olcAccess: {2}to * by dn.base="cn=repl,dc=savagebeast,dc=com" olcAccess: {3}to dn.base="" by * write olcMirrorMode: TRUE olcRootDN: cn=admin,cn=config,cn=slave olcRootPW: {SHA}xxx olcSuffix: cn=config,cn=slave olcSyncrepl: {0}rid=006 provider=ldaps://guess.savagebeast.com bindmethod=si mple binddn="cn=admin,cn=config" credentials=xxx searchbase="cn=schema,cn =config" schemachecking=off type=refreshAndPersist retry="60 +" suffixmassa ge="cn=schema,cn=config,cn=slave" olcSyncrepl: {1}rid=005 provider=ldaps://who.savagebeast.com bindmethod=simp le binddn="cn=admin,cn=config" credentials=xxx searchbase="cn=schema,cn=c onfig" schemachecking=off type=refreshAndPersist retry="60 +" suffixmassage ="cn=schema,cn=config,cn=slave" olcSyncrepl: {2}rid=007 provider=ldaps://who.savagebeast.com bindmethod=simp le binddn="cn=admin,cn=config,cn=slave" credentials=xxx searchbase="cn=co nfig,cn=slave" schemachecking=on type=refreshAndPersist retry="60 +" olcSyncrepl: {3}rid=008 provider=ldaps://guess.savagebeast.com bindmethod=si mple binddn="cn=admin,cn=config,cn=slave" credentials=xxx searchbase="cn= config,cn=slave" schemachecking=on type=refreshAndPersist retry="60 +" createTimestamp: 20110609185532Z creatorsName: cn=admin,cn=config entryCSN: 20110616183041.867322Z#000000#002#000000 entryDN: olcDatabase={2}ldif,cn=config entryUUID:: Y2JmNTE3MTAtMjcxNS0xMDMwLThkMGYtNWY4MDFiNjU0MGFl modifiersName: cn=admin,cn=config modifyTimestamp: 20110616183041Z structuralObjectClass: olcLdifConfig subschemaSubentry: cn=Subschema {NB: To future google searchers; I originally had this database setup as a HDB. After a week of use, this failed to allow new consumers to sync with it because <ASSUMING> the database ordering dictates how the initial sync is ordered, which normally wouldn't be a problem, but since the cn=config database is interpreted as it's loaded ordering became important. IE: defining a database before the back_ module used was loaded; Moving to the ldif database format seems to provide a consistent top down ordering.} RID 7 and 8 work fine and configurations changes propagate between the Mirrormode providers and the remote consumers. RID 5 and 6 performed the initial sync properly but have since started issuing errors on both masters: Jun 16 12:02:41 who slapd[9589]: do_syncrep2: rid=006 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Jun 16 12:02:41 who slapd[9589]: do_syncrep2: rid=006 (53) Server is unwilling to perform Jun 16 12:02:41 who slapd[9589]: do_syncrepl: rid=006 rc -2 retrying Jun 16 12:02:59 who slapd[9589]: do_syncrep2: rid=005 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Jun 16 12:02:59 who slapd[9589]: do_syncrep2: rid=005 (53) Server is unwilling to perform Jun 16 12:02:59 who slapd[9589]: do_syncrepl: rid=005 rc -2 retrying Running in full debug I see errors about the CSN timestamps: ber_dump: buf=0x7fae40019d00 ptr=0x7fae40019dea end=0x7fae40019ded len=3 0000: 00 01 ff ... => get_ctrls: oid="2.16.840.1.113730.3.4.2" (critical) <= get_ctrls: n=2 rc=0 err="" attrs: * + conn=1000 op=1 SRCH base="cn=schema,cn=config" scope=2 deref=0 filter="(objectClass=*)" conn=1000 op=1 SRCH attr=* + send_ldap_result: conn=1000 op=1 p=3 send_ldap_result: err=53 matched="" text="consumer state is newer than provider!" send_ldap_response: msgid=2 tag=101 err=53 ber_flush2: 52 bytes to sd 17 0000: 30 32 02 01 02 65 2d 0a 01 35 04 00 04 26 63 6f 02...e-..5...&co 0010: 6e 73 75 6d 65 72 20 73 74 61 74 65 20 69 73 20 nsumer state is 0020: 6e 65 77 65 72 20 74 68 61 6e 20 70 72 6f 76 69 newer than provi 0030: 64 65 72 21 der! tls_write: want=165, written=165 0000: 17 03 02 00 a0 0b 68 27 f3 13 cc 34 a9 75 cd 8d ......h'...4.u.. 0010: f7 f9 35 d5 b8 4c f5 a8 49 4e e1 fb e2 c5 3b 72 ..5..L..IN....;r 0020: df f8 e0 d2 72 34 1e e3 bd 6e 26 ca 25 8a c1 3e ....r4...n&.%..> 0030: 20 65 e2 56 f5 f4 b0 60 09 a2 eb ab b5 b7 2f e2 e.V...`....../. 0040: 6a bd f3 48 12 c3 59 bb 87 cd 7d bd 99 76 5f 29 j..H..Y...}..v_) 0050: f9 5f 27 d4 09 4f 0e 31 a9 89 b6 33 43 f3 65 ab ._'..O.1...3C.e. 0060: 69 bf a1 19 3c 51 70 52 79 3d a6 d1 39 c7 c1 1d i...<QpRy=..9... 0070: 5c 37 ac 89 a4 82 ed 68 cf f4 1a e4 52 90 20 6b \7.....h....R. k 0080: 51 11 db 0e e2 a4 38 04 17 aa 65 b3 e2 38 5a 1e Q.....8...e..8Z. 0090: 00 15 52 2e 75 2f 05 81 86 a0 41 cd 91 ca 5b 92 ..R.u/....A...[. 00a0: e5 69 bd 41 d6 .i.A. ldap_write: want=52, written=52 0000: 30 32 02 01 02 65 2d 0a 01 35 04 00 04 26 63 6f 02...e-..5...&co 0010: 6e 73 75 6d 65 72 20 73 74 61 74 65 20 69 73 20 nsumer state is 0020: 6e 65 77 65 72 20 74 68 61 6e 20 70 72 6f 76 69 newer than provi 0030: 64 65 72 21 der! read1msg: ld 0x7fae44100d60 msgid 2 all 0 conn=1000 op=1 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! ber_get_next tls_read: want=5, got=5 0000: 17 03 02 00 a0 ..... tls_read: want=160, got=160 0000: 0b 68 27 f3 13 cc 34 a9 75 cd 8d f7 f9 35 d5 b8 .h'...4.u....5.. 0010: 4c f5 a8 49 4e e1 fb e2 c5 3b 72 df f8 e0 d2 72 L..IN....;r....r 0020: 34 1e e3 bd 6e 26 ca 25 8a c1 3e 20 65 e2 56 f5 4...n&.%..> e.V. 0030: f4 b0 60 09 a2 eb ab b5 b7 2f e2 6a bd f3 48 12 ..`....../.j..H. 0040: c3 59 bb 87 cd 7d bd 99 76 5f 29 f9 5f 27 d4 09 .Y...}..v_)._'.. 0050: 4f 0e 31 a9 89 b6 33 43 f3 65 ab 69 bf a1 19 3c O.1...3C.e.i...< 0060: 51 70 52 79 3d a6 d1 39 c7 c1 1d 5c 37 ac 89 a4 QpRy=..9...\7... 0070: 82 ed 68 cf f4 1a e4 52 90 20 6b 51 11 db 0e e2 ..h....R. kQ.... 0080: a4 38 04 17 aa 65 b3 e2 38 5a 1e 00 15 52 2e 75 .8...e..8Z...R.u 0090: 2f 05 81 86 a0 41 cd 91 ca 5b 92 e5 69 bd 41 d6 /....A...[..i.A. ldap_read: want=8, got=8 0000: 30 32 02 01 02 65 2d 0a 02...e-. ldap_read: want=44, got=44 0000: 01 35 04 00 04 26 63 6f 6e 73 75 6d 65 72 20 73 .5...&consumer s 0010: 74 61 74 65 20 69 73 20 6e 65 77 65 72 20 74 68 tate is newer th 0020: 61 6e 20 70 72 6f 76 69 64 65 72 21 an provider! ber_get_next: tag 0x30 len 50 contents: ber_dump: buf=0x7fae340013a0 ptr=0x7fae340013a0 end=0x7fae340013d2 len=50 0000: 02 01 02 65 2d 0a 01 35 04 00 04 26 63 6f 6e 73 ...e-..5...&cons 0010: 75 6d 65 72 20 73 74 61 74 65 20 69 73 20 6e 65 umer state is ne 0020: 77 65 72 20 74 68 61 6e 20 70 72 6f 76 69 64 65 wer than provide 0030: 72 21 r! read1msg: ld 0x7fae44100d60 msgid 2 message type search-result ber_scanf fmt ({eAA) ber: ber_dump: buf=0x7fae340013a0 ptr=0x7fae340013a3 end=0x7fae340013d2 len=47 0000: 65 2d 0a 01 35 04 00 04 26 63 6f 6e 73 75 6d 65 e-..5...&consume 0010: 72 20 73 74 61 74 65 20 69 73 20 6e 65 77 65 72 r state is newer 0020: 20 74 68 61 6e 20 70 72 6f 76 69 64 65 72 21 than provider! read1msg: ld 0x7fae44100d60 0 new referrals read1msg: mark request completed, ld 0x7fae44100d60 msgid 2 request done: ld 0x7fae44100d60 msgid 2 res_errno: 53, res_error: <consumer state is newer than provider!>, res_matched: <> ldap_free_request (origid 2, msgid 2) do_syncrep2: rid=005 LDAP_RES_SEARCH_RESULT ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x7fae340013a0 ptr=0x7fae340013a3 end=0x7fae340013d2 len=47 0000: 65 2d 0a 01 35 04 00 04 26 63 6f 6e 73 75 6d 65 e-..5...&consume 0010: 72 20 73 74 61 74 65 20 69 73 20 6e 65 77 65 72 r state is newer 0020: 20 74 68 61 6e 20 70 72 6f 76 69 64 65 72 21 than provider! ber_scanf fmt (}) ber: ber_dump: buf=0x7fae340013a0 ptr=0x7fae340013d2 end=0x7fae340013d2 len=0 ldap_err2string do_syncrep2: rid=005 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform ldap_err2string ldap_err2string do_syncrep2: rid=005 (53) Server is unwilling to perform ldap_err2string ldap_msgfree ldap_free_connection 1 1 ldap_send_unbind Any pointers on where to troubleshoot and resolve this?

2 2

Password Policy
by ldap＠mm.st 14 Jun '11

14 Jun '11

Running RH5 with openldap-2.3.43. We have a script that pulls ssha passwords from a ldap server out of our control. So when a user updates their passwords on that server, the script pulls the password periodically and updates our ldap servers so users can use our ldap servers with posix attributes to authenticate to systems using ldap and pam settings. We need to inactivate accounts after a period of inactivity. We can do this using the shadowInactive attribute in ldap that is based on when the user password expired. So the issue we have is that when the user logs into a system and their accounts are expired they can enter a new password and our ldap servers our updated with the new password, but when the script runs at a later time, the password is reset back to whatever is in the ldap server we pull passwords from. We would like users to not be able to change their password using the password command. We can accomplish this in a few ways including: 1. pam_password_prohibit_message in ldap.conf 2. Just commenting out the ldap module in pam that controls password updates. The problem is that we have a small group of users that are added manually that we would like to be able to change their passwords using the passwd command. The above will impact all users. We are looking for suggestions on how to handle the above. We thought of the following: 1. Use the ppolocy overlay and create a default policy for all users that sets pwdAllowUserChange to no and then create individual policies to that allow certain users to change their pass. In this method, what happens to all the shadow attributes, are they overwridden by the ppolicy. I don't see anything regarding Inactive accounts in ppolicy like the shadowInactive attribute. 2. Could we accomplish this by figuring out a ACL in slapd.conf that only users with a special attribute value are able to write to the userPassword attribute? Any other suggestions?

3 4

Re: Client App and STARTLS auth
by Massimiliano Pala 14 Jun '11

14 Jun '11

Hi Rich, to provide a better vision, I am trying to use openldap to connect to a server and ignoring errors in authentication of the certificates. I am working on a *client*. In particular the code I wrote is like this: ldap_initialize(&ld, url); if(crypto_api == LDAP_CRYPTO_API_OPENSSL) { // This Works.. SSL_CTX *ctx = NULL; ... } else { int opt_val = 0; if(ldap_set_option(ld, LDAP_OPT_X_TLS_NEWCTX, &opt_val) != LDAP_OPT_SUCCESS) { /// ERROR if here (does not happen) } // This works till now opt_val = LDAP_OPT_X_TLS_TRY; if(ldap_set_option(ld, LDAP_OPT_X_TLS_REQUIRE_CERT, &opt_val) != LDAP_OPT_SUCCESS) { if(ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &opt_val) != LDAP_OPT_SUCCESS) { // Error .. } } m_error = ldap_start_tls_s(corePnt->m_ldap, NULL, NULL); ... Note that m_error gets a -11... On the server the output (-d 1) is: connection_get(14): got connid=1007 connection_read(14): checking for input on id=1007 TLS: error: accept - force handshake failure: errno 11 - moznss error -5938 TLS: can't accept: (unknown). I have no clue why this is not working. Another thing which is interesting.. on Ubuntu I tried to change the TLS_CERTREQ option to "allow" ... and the code works - but I can not have it working by using the ldap_set_option().. (on Fedora 14/15 setting the option in the ldap.conf file - in /etc/openldap/ - does not work..). Heeeeeellp!!! :D Cheers, Max On 06/10/2011 10:50 PM, Rich Megginson wrote: > On Fri, Jun 10, 2011 at 4:19 PM, Massimiliano Pala<pala(a)isis.poly.edu> wrote: >> Hi Philip, all, >> >> thanks for the advice. I have changed the code.. and the option is set >> correctly. Question, do you think it is safe to do this as a fallback: >> >> if(ldap_set_option(ld, LDAP_OPT_X_TLS_REQUIRE_CERT,&level) != >> LDAP_OPT_SUCCESS) >> { >> if(ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT,&level) != >> LDAP_OPT_SUCCESS) >> { >> /// Total Failure >> } >> } >> >> Still.. although I set the option, I still get the -11 error when >> trying to bind. > > What -11 error? Client or server? Can you run with -d 1 to get > detailed trace information? > >> >> Is there any other option I have to set to "disable" certificate >> verification for non-openssl crypto api ? >> >> Cheers, >> Max >> >> >> On 06/10/2011 05:23 PM, Philip Guenther wrote: >> [..] >>> >>> Howard has already pointed out that the value must be an LDAP_OPT_X_TLS_* >>> constant and not a string; I just wanted to add that in version 2.3 and >>> earlier, that option (and most of the other TLS options) could only be set >>> globally: ldap_set_option() would fail for them if the first argument >>> wasn't NULL. So, make sure you're building against a current version. >>> >>> >>> Philip Guenther >> >> >> -- >> >> http://member.acm.org/~openca/ >> >> Massimiliano Pala, Ph.D. >> Director, OpenCA Labs >> Professor, NYU Poly >> >> -- http://member.acm.org/~openca/ Massimiliano Pala, Ph.D. Director, OpenCA Labs Professor, NYU Poly

2 3

How to migrate master and keep slave in sync?
by Stefano Zanmarchi 14 Jun '11

14 Jun '11

Hi, we have a 2.4.21 master on Solaris and a syncrepl 2.4.21 slave on Linux, and need to migrate the master to a new platform (Linux) and new version (2.4.21). Of course we need that the syncrepl slave (not managed by us) keeps in sync with the new master. Given that the ip, ports and certificates of the new master will not change, would it be enough to do the following? 1) stop the "old" 2.4.21/Solaris master 2) import its contents (via slapcat and slapadd) into the "new" 2.4.23/Linux (stopped) master 3) start the new 2.4.23/Linux master Thank you very much, Stefano

2 1

Linking Clients - which Crypto API ?
by Massimiliano Pala 14 Jun '11

14 Jun '11

Hi all, I have a little problem. I am implementing an application that uses the OpenLDAP libraries. Until not too much time ago, linking with OpenSSL was sufficiently safe (on almost every Linux distros) and providing my own verification function through the SSL_CTX (by using the ldap_set_option(m_ldap, LDAP_OPT_SERVER_CERTIFICATE, _my_verify)) was easy. Now, Linux distros started to use GnuTLS, NSS, and OpenSSL as the crypto API. My question is: how do I develop an application that when deployed on different systems might need to use functions and data structures from different crypto-api (e.g., when I distribute the binaries of my app) ? How can I retrieve that info *at runtime* (I'd like my binaries to be compatible) ? At least, is there a function that allows me to know which crypto APIs are expected by libldap_r (so that I don't pass in the wrong data structure since it is a (void *)) ? Or at least, is there a way to set/get options so that I would know which API is in use ? Thanks, -- http://member.acm.org/~openca/ Massimiliano Pala, Ph.D. Director, OpenCA Labs Professor, NYU Poly

2 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical