openldap-devel

openldap-devel@openldap.org

1418 discussions

ITS#8286 round 2
by Quanah Gibson-Mount 18 Dec '18

18 Dec '18

Here's where I've ended up with for ITS#8286. Only 2 real remaining questions if this looks good (olcTLSCertificateKey and olcTLSVerifyClient). Commit is currently <https://github.com/quanah/openldap-scratch/commit/efef34db2f36e00a44c3f2dee…> ---------------- servers/slapd/bconfig.c ----------------------- olcConfigFile -- Changed to case exact match olcConfigDir -- Changed to case exact match olcArgsFile -- Changed to case exact match olcLogFile -- case exact match olcModulePath -- case exact match olcPasswordCryptSaltFormat -- case ignore match olcPidFile -- case exact match olcPluginLogFile -- case exact match olcRootPw -- octetStringMatch olcSaslAuxprops -- case ignore match olcSaslHost -- case ignore match olcSaslRealm -- case exact match olcSaslSecProps -- case exact match olcSizeLimit -- case exact match olcSubordinate -- case exact match olcTCPBuffer -- case exact match olcTimeLimit -- case exact match olcTLSCACertificateFile -- case exact match olcTLSCACertificatePath -- case exact match olcTLSCertificateFile -- case exact match olcTLSCertificateKey -- ??? (Private SYNTAX OID) Shouldn't the SYNTAX be 1.3.6.1.4.1.1466.115.121.1.8? And use certificateExactMatch? olcTLSCertificateKeyFile -- case exact match olcTLSCipherSuite -- case exact match olcTLSCRLCheck -- case exact match olcTLSCRLFile -- case exact match olcTLSRandFile -- case exact match olcTLSVerifyClient -- case exact match (Shouldn't this be an enum, like olcMemberOfDangling ?) olcTLSDHParamFile -- case exact match olcTLSECName -- case exact match olcTLSProtocolMin -- case exact match ---------------- BACKENDS ----------------------- --- back-asyncmeta olcDbURI -- case exact match olcDbStartTLS -- case exact match olcDbACLPasswd -- DELETE olcDbIDAssertBind -- case ignore match olcDbTFSupport -- case ignore match olcDbTimeout -- case ignore match olcDbIdleTimeout -- case ignore match olcDbNetworkTimeout -- case ignore match olcDbCancel -- case ignore match olcDbQuarantine -- case ignore match olcDbDefaultTarget -- case ignore match olcDbDnCacheTtl -- case ignore match olcDbBindTimeout -- integer match olcDbOnErr -- case ignore match olcDbNretries -- case ignore match olcDbClientPr -- case ignore match olcDbKeepalive -- case ignore match --- back-bdb/hdb olcDbCheckpoint -- case ignore match olcDbCryptFile -- case exact match olcDbCryptKey -- case exact match olcDbConfig -- IA5 case ignore match olcDbLockDetect -- case ignore match olcDbMode -- case ignore match --- back-ldap olcDbURI -- case exact match olcDbStartTLS -- case exact match olcDbACLPasswd -- DELETE olcDbACLBind -- case ignore match olcDbIDAssertPasswd -- DELETE olcDbIDAssertBind -- case ignore match olcDbIDAssertMode -- DELETE olcDbTFSupport -- case ignore match olcDbTimeout -- case ignore match olcDbIdleTimeout -- case ignore match olcDbConnTtl -- case ignore match olcDbNetworkTimeout -- case ignore match olcDbCancel -- case ignore match olcDbQuarantine -- case ignore match olcDbOnErr -- case ignore match olcDbKeepalive -- case ignore match --- back-mdb olcDbDirectory -- Changed to case exact match olcDbCheckpoint -- case ignore match olcDbMode -- case ignore match --- back-meta olcDbURI -- case exact match olcDbStartTLS -- case exact match olcDbACLPasswd -- DELETE olcDbIDAssertBind -- case ignore match olcDbTFSupport -- case ignore match olcDbTimeout -- case ignore match olcDbIdleTimeout -- case ignore match olcDbConnTtl -- case ignore match olcDbNetworkTimeout -- case ignore match olcDbCancel -- case ignore match olcDbQuarantine -- case ignore match olcDbDefaultTarget -- case ignore match olcDbDnCacheTtl -- case ignore match olcDbBindTimeout -- integer match olcDbOnErr -- case ignore match olcDbNretries -- case ignore match olcDbClientPr -- case ignore match olcDbKeepalive -- case ignore match --- back-sql olcDbHost -- case exact match olcDbName -- case exact match olcDbUser -- case exact match olcDbPass -- case exact match olcSqlConcatPattern -- case exact match olcSqlSubtreeCond -- case exact match olcSqlChildrenCond -- case exact match olcSqlDnMatchCond-- case exact match olcSqlOcQuery -- case exact match olcSqlAtQuery -- case exact match olcSqlInsEntryStmt -- case exact match olcSqlUpperFunc -- case exact match olcSqlStrcastFunc -- case exact match olcSqlDelEntryStmt -- case exact match olcSqlRenEntryStmt -- case exact match olcSqlDelObjclassesStmt -- case exact match olcSqlBaseObject -- case exact match olcSqlLayer -- case exact match olcSqlFetchAttrs -- case ignore match olcSqlAliasingKeyword -- case exact match olcSqlAliasingQuote -- case ignore match olcSqlIdQuery -- case exact match ---------------- OVERLAYS ----------------------- --- accesslog.c logpurge -- case ignore match logold -- case exact match --- auditlog.c olcAuditLogFile -- case exact match --- autoca.c olcACAuserClass -- case ignore match olcACAserverClass -- case ignore match --- dds.c olcDDSmaxTtl -- case ignore match olcDDSminTtl -- case ignore match olcDDSdefaultTtl -- case ignore match olcDDSinterval -- case ignore match olcDDStolerance -- case ignore match --- dyngroup.c olcDGAttrPair -- case ignore match --- memberof.c olcMemberOfDangling -- case ignore match olcMemberOfGroupOC -- case ignore match olcMemberOfMemberAD -- case ignore match olcMemberOfMemberOfAD -- case ignore match olcMemberOfDanglingError -- case ignore match --- pcache.c olcProxyCache -- case ignore match olcPcachePosition -- case ignore match olcPcacheMaxQueries -- case ignore match --- rwm.c olcRwmTFSupport -- case ignore match --- syncprov.c olcSpCheckpoint -- case ignore match --- translucent.c olcTranslucentLocal -- case ignore match olcTranslucentRemote -- case ignore match ---------------- CONTRIB ----------------------- --- adremap.c olcADremapDowncase -- case ignore match olcADremapDNmap -- case ignore match --- autogroup.c olcAGmemberOfAd -- case ignore match --- smbk5pwd.c olcSmbK5PwdEnable -- case ignore match --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 5

Re: openldap.git branch master updated. 9cc97ea9e1c9ee2ee9f7d427ef9b950e890c219f
by Howard Chu 18 Dec '18

18 Dec '18

openldap-commit2devel(a)OpenLDAP.org wrote: > A ref change was pushed to the OpenLDAP (openldap.git) repository. > It will be available in the public mirror shortly. > > The branch, master has been updated > via 9cc97ea9e1c9ee2ee9f7d427ef9b950e890c219f (commit) > from 2731ff0c23ae29414d12658f31d9d3bde6b5c374 (commit) > > Those revisions listed above that are new to this repository have > not appeared on any other notification email; so we list those > revisions in full, below. > > - Log ----------------------------------------------------------------- > commit 9cc97ea9e1c9ee2ee9f7d427ef9b950e890c219f > Author: Howard Chu <hyc(a)openldap.org> > Date: Thu Dec 13 06:29:32 2018 -0800 > > MS AD DirSync support > > Requires "attribute_option range=" in config. Correction: "attributeoptions range=" > No test script provided yet, since testing requires an actual AD server. Here's a sample config, assuming the AD server's baseDN is "dc=ldapsync,dc=local" It's based on the consumer config from test017. include ./schema/core.schema include ./schema/cosine.schema include ./schema/inetorgperson.schema include ./schema/nis.schema include ./schema/msuser.schema attributeoptions range= database mdb suffix "dc=ldapsync,dc=local" rootdn "cn=Replica,dc=ldapsync,dc=local" rootpw secret directory ./testrun/db.2.a index objectClass eq index cn,sn,uid pres,eq,sub index entryUUID,entryCSN eq syncrepl rid=1 provider=ldap://ldapsync/ binddn="cn=Administrator,cn=users,dc=ldapsync,dc=local" bindmethod=simple credentials=MSAD-secret searchbase="dc=ldapsync,dc=local" filter="(|(objectClass=user)(objectclass=group))" schemachecking=off scope=sub type=dirSync interval=00:00:00:03 updateref ldap://ldapsync/ database monitor > > ----------------------------------------------------------------------- > > Summary of changes: > servers/slapd/schema/msuser.ldif | 4299 ++++++++++++++++++++++++++++++++++++ > servers/slapd/schema/msuser.schema | 4295 +++++++++++++++++++++++++++++++++++ > servers/slapd/syncrepl.c | 610 ++++- > 3 files changed, 9140 insertions(+), 64 deletions(-) > create mode 100644 servers/slapd/schema/msuser.ldif > create mode 100644 servers/slapd/schema/msuser.schema -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

CVE-2017-17740 aka ITS#8759
by Michael Ströder 17 Dec '18

17 Dec '18

HI! This ITS was answered with won't fix / send patches: https://www.openldap.org/its/index.cgi?findid=8759 But in the mean-time somebody assigned a CVE number to it: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17740 The SUSE folks added a patch: https://build.opensuse.org/package/view_file/network:ldap/openldap2/0017-Fi… Could anybody review this and comment whether it makes sense at all? If the patch is correct would it make sense to release it with 2.4.47? Ciao, Michael.

2 1

Re: Regarding the feature to introduce new LDAP option to set source bind IP address
by Howard Chu 15 Oct '18

15 Oct '18

Sharma, Ramakant 2. (Nokia - IN/Bangalore) wrote: > Hi Howard, > > Please provide your valuable comments. > > Can we start implementation with the proposed design? Yes this sounds fine to me. I'm guessing no one else on the list has any comments at this point. > > BR, > Ramakant Sharma > > -----Original Message----- > From: Sharma, Ramakant 2. (Nokia - IN/Bangalore) > Sent: Wednesday, October 10, 2018 2:21 PM > To: 'hyc(a)symas.com' <hyc(a)symas.com>; 'openldap-devel(a)openldap.org' <openldap-devel(a)openldap.org> > Cc: Singam, Sudhir (Nokia - IN/Bangalore) <sudhir.singam(a)nokia.com> > Subject: RE: Regarding the feature to introduce new LDAP option to set source bind IP address > > Hi Howard, > >>> Not sure I understand the value of a list of multiple addresses here. > > [Ramakant]: Yes you are right that there is no use case for multiple IPv4 or multiple IPv6 address setting for an LDAP client. The list can have only one IPv4 and one IPv6. LDAP client will chose either IPv4 or IPv6 address for binding, based on the target address type. > >>> Seems like these should be char* arrays, especially since we already have str2charray(). > [Ramakant]: Modified as per comment and now only one variable will hold both IPv4 and IPv6. > >>> What specific LDAP API error code will be returned in each instance? > [Ramakant]: We are planning to re-use " LDAP_CONNECT_ERROR ". > > Please find the update content here after above comments. > > " > *Requirement:* > > User shall be able to set IPv4/IPv6 socket bind address to be able to route the LDAP traffic via desired network interface. Based on the target IP address type, matching IP address will be picked for explicit binding*//**at client side*. > > *Work items:* > 1. *LDAP option to set the IPv4/IPv6 socket bind addresses.* > /Format: space separated list of IP addresses/ > > New configuration option LDAP_OPT_SOCKET_BIND_ADDRESSES (0x5013) will be introduced (in ldap.h) to be used via ldap_set_option. > > For example, > > char* p = "10.24.56.34 2001:0db8:85a3:0000:0000:8a2e:0370:7334"; > ldap_set_option(NULL, LDAP_OPT_SOCKET_BIND_ADDRESSES, p); > > Bind addresses can also be provided in ldap.conf file via the option "SOCKET_BIND_ADDRESSES" > > Valid examples: > > SOCKET_BIND_ADDRESSES 10.24.56.45 2001:0db8:85a3:0000:0000:8a2e:0370:7334 > SOCKET_BIND_ADDRESSES 10.24.56.45 > SOCKET_BIND_ADDRESSES 2001:0db8:85a3:0000:0000:8a2e:0370:7334 > SOCKET_BIND_ADDRESSES 2001:0db8:85a3:0000:0000:8a2e:0370:7334 10.24.56.45 > > Invalid examples: > SOCKET_BIND_ADDRESSES 2001:0db8:85a3:0000:0000:8a2e:0370:7334 2001:0db8:85a3:0000:0000:8a2e:0370:7335 > SOCKET_BIND_ADDRESSES 10.24.56.45 10.24.56.47 > > Note : > Option set to ldap handle will override the global option. > Setting the option multiple times will override the previous values but does not append. > > 2. *Parsing & validations* > > Space separated IP addresses will be parsed & validated. > Basic syntax validation will be done for IPv4 or IPv6 addresses, if any error, setting of the option will fail and LDAP client will use the default IP address or previously successfully validated IP addresses provided by set option. > If multiple IPv4 or multiple IPv6 address is set, validation will fail. > > "ldapoptions" structure in ldap-int.h will be modified to add new variable to hold given IPv4 and IPv6 address. > char** ldo_local_IP_addresses > > Any new function /ldap_options_parseBindAddress() will be introduced in options.c to parse, validate and store the IP address to " ldo_local_IP_addresses" variable. This function will be similar to ldap_url_parseHosts. > If parseBindAddress() fails to parse & validate the addresses successfully then previously set IP address will not be overwritten. If there were no previous address then default kernel address will be used during connection. > > 3. *Using Bind IP addresses during connection* > > File:os-ip.c > Function: ldap_connect_to_host > - After the connection socket is created (ldap_int_socket) and before it is connected (ldap_pvt_connect). > Check if the target address family type, *I*f it is AF_INET, IPv4 bind > - If the list is empty means there were no addresses provided from user, then default kernel provided address will be used for binding the interface. > - If the list is not empty and not able to bind to provided IPv4 address, connection will fail> > - if the list is not empty and it just contains IPV6 address then default kernel provided IPv4 address will be used for binding the interface. > If it is AF_INET6, IPv6 bind address will be used from the list. > - If the list is not empty and not able to bind to provided IPv6 addresses, connection will fail. > - if the list is not empty and it just contains IPV4 address then default kernel provided IPv6 address will be used for binding the interface. > - If the list is empty then LDAP client will continue to use the kernel provided IPv6 address. > > " > BR, > Ramakant Sharma > Technical Lead > Nokia Networks, Bangalore > > -----Original Message----- > From: Howard Chu <hyc(a)symas.com> > Sent: Thursday, September 06, 2018 9:18 PM > To: Singam, Sudhir (Nokia - IN/Bangalore) <sudhir.singam(a)nokia.com>; 'openldap-devel(a)openldap.org' <openldap-devel(a)openldap.org> > Cc: Sharma, Ramakant 2. (Nokia - IN/Bangalore) <ramakant.2.sharma(a)nokia.com> > Subject: Re: Regarding the feature to introduce new LDAP option to set source bind IP address > > Singam, Sudhir (Nokia - IN/Bangalore) wrote: >> Hi Howard, >> >> Any comments ?? > >> >> Hi, >> >> Can we go ahead and implement this ?? >> >> *Regards,* >> *Sudhir Singam* >> >> *DELIVERING BEST-IN-CLASS PLATFORM is our vision* >> >> >> _____________________________________________ >> *From:* Singam, Sudhir (Nokia - IN/Bangalore) >> *Sent:* Wednesday, August 08, 2018 8:48 AM >> *To:* _openldap-devel(a)openldap.org_ >> <mailto:openldap-devel@openldap.org> >> *Cc:* Sharma, Ramakant 2. (Nokia - IN/Bangalore) >> <_ramakant.2.sharma(a)nokia.com_ <mailto:ramakant.2.sharma@nokia.com>> >> *Subject:* Regarding the feature to introduce new LDAP option to set >> source bind IP address >> >> >> Hi, >> >> NOKIA has taken up this small feature for contribution. Previously patch was submitted via ITS#8847 but got rejected to take different approach. >> Now I have raised ITS#8893. We want to conclude on the approach before >> taking for implementation. Please kindly let us know if following approach is OK and if any comments. >> >> *Requirement:* >> >> User shall be able to set multiple IPv4/IPv6 socket bind addresses, to >> be able to route the LDAP traffic via desired network interface. Based on the target IP address type, first matching and valid source IP address will be picked for explicit binding*//**at client side*. > > Not sure I understand the value of a list of multiple addresses here. >> >> *Work items:* >> >> >> 1. *LDAP option to set the IPv4/IPv6 socket bind addresses.* >> >> /Format: space separated list of IP addresses/ >> >> New configuration option LDAP_OPT_SOCKET_BIND_ADDRESSES (0x5013) will be introduced (in ldap.h) to be used via ldap_set_option. >> >> For example, >> >> char* p = "10.24.56.34 2001:0db8:85a3:0000:0000:8a2e:0370:7334"; >> ldap_set_option(NULL, LDAP_OPT_SOCKET_BIND_ADDRESSES, p); >> >> Bind addresses can also be provided in ldap.conf file via the option >> "SOCKET_BIND_ADDRESSES", for example, >> >> SOCKET_BIND_ADDRESSES 10.24.56.45 10.24.56.46 >> 2001:0db8:85a3:0000:0000:8a2e:0370:7334 >> >> Note : >> Option set to ldap handle will override the global option. >> Setting the option multiple times will override the previous values but does not append. >> >> >> 2. *Parsing & validations* >> >> >> Space separated IP addresses will be parsed & validated. IPv4 and IPv6 addresses are stored separately for easy of access during connection. >> Basic syntax validation will be done for IPv4 or IPv6 addresses, if any error, setting of the option will fail and LDAP client will use the default IP address. >> >> "ldapoptions" structure in ldap-int.h will be modified to add new >> members "char *ldo_local_IPV4_addresses" -> to hold client local IPv4 >> bind addresses "char *ldo_local_IPV6_addresses" -> to hold client >> local IPv6 bind addresses > > Seems like these should be char* arrays, especially since we already have str2charray(). > >> Any new function /ldap_options_parseBindAddress/ () will be introduced >> in options.c to parse, validate and store the IP addresses to respective variables. This function will be similar to ldap_url_parseHosts. >> >> Memory for ldo_local_IPV4_addresses & ldo_local_IPV6_addresses is >> dynamically allocated in the form of array for easy access. If any validation failure, no new memory will be allocated and existing values will be retained. >> >> >> 3. *Using Bind IP addresses during connection* >> >> >> File:os-ip.c >> Function: ldap_connect_to_host >> - After the connection socket is created (ldap_int_socket) and before it is connected (ldap_pvt_connect). >> Check if the target address family type, *I*f it is AF_INET, IPv4 bind >> address list will be used. >> - If the list is empty and LDAP option was set successfully earlier (IPv6 was set), binding will fail and error is returned. >> - If the list is not empty and not able to bind to any of the provided IPv4 addresses, connection will fail> - If the list is empty and LDAP option setting failed earlier (during syntax validation), LDAP client will continue to use the kernel provided IPv4 address. >> If it is AF_INET6, IPv6 bind address list will be used. >> - If the list is empty and LDAP option was set successfully earlier (IPv4 was set), binding will fail and error is returned. >> - If the list is not empty and not able to bind to any of the provided IPv6 addresses, connection will fail. >> - If the list is empty and LDAP option setting failed earlier (during syntax validation), LDAP client will continue to use the kernel provided IPv6 address. > > What specific LDAP API error code will be returned in each instance? > >> >> >> >> >> *Regards,* >> *Sudhir Singam* >> >> *DELIVERING BEST-IN-CLASS PLATFORM is our vision* >> >> >> > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

NanoLog for efficient logging?
by Howard Chu 16 Sep '18

16 Sep '18

I haven't read the code or paper yet, but after a quick skim, this sounds like they're doing what we want in a logging subsystem. https://twitter.com/copyconstruct/status/1041048701723009024 Anyone care to investigate? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 1

Fifth OpenLDAP Developer Day – Call for Registration!
by Howard Chu 13 Sep '18

13 Sep '18

Together with the University of Tübingen and Symas, DAASI International invites all stakeholders to meet in Tübingen and celebrate 20 years of OpenLDAP! The 5th OpenLDAP Developer Day is a great opportunity to come together as a community and exchange ideas with developers of OpenLDAP software, directory researchers and other OpenLDAP community members interested in discussing ongoing and future development efforts. Are you a stakeholder interested to join us for the 5th OpenLDAP Developer Day? Then please register by contacting us at odd-silverjubilee(a)daasi.de before September 28th. You are invited to listen to interesting speakers and to take part in fruitful discussions. Also, if you would like to present your own topic to the community, there are still some of the limited speaker slots of 15 to 45 minutes available. Just email us at odd-silverjubilee(a)daasi.de as soon as possible, but no later than the extended deadline of September 21st. The full Call for Content is available here. The OpenLDAP Developer Day will take place at the Computing Center of the University of Tübingen (Wächterstraße 76, 72074 Tübingen). Information on how to find the location of the OpenLDAP Developer Day is available here https://daasi.de/en/company/journey-and-stay/. We are looking forward to celebrate the OpenLDAP Silver Jubilee with you! If you have any questions, please do not hesitate to contact us at odd-silverjubilee(a)daasi.de. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

TLS 1.3 and 0-RTT
by Michael Ströder 06 Sep '18

06 Sep '18

HI! Are there any plans to support TLS 1.3? The 0-RTT feature could be a significant performance gain in case LDAP applications open a new TLS connection each time they check a password with a bind request. Ciao, Michael.

2 1

Re: Regarding the feature to introduce new LDAP option to set source bind IP address
by Howard Chu 06 Sep '18

06 Sep '18

Singam, Sudhir (Nokia - IN/Bangalore) wrote: > Hi Howard, > > Any comments ?? > > Hi, > > Can we go ahead and implement this ?? > > *Regards,* > *Sudhir Singam* > > *DELIVERING BEST-IN-CLASS PLATFORM is our vision* > > > _____________________________________________ > *From:* Singam, Sudhir (Nokia - IN/Bangalore) > *Sent:* Wednesday, August 08, 2018 8:48 AM > *To:* _openldap-devel(a)openldap.org_ <mailto:openldap-devel@openldap.org> > *Cc:* Sharma, Ramakant 2. (Nokia - IN/Bangalore) <_ramakant.2.sharma(a)nokia.com_ <mailto:ramakant.2.sharma@nokia.com>> > *Subject:* Regarding the feature to introduce new LDAP option to set source bind IP address > > > Hi, > > NOKIA has taken up this small feature for contribution. Previously patch was submitted via ITS#8847 but got rejected to take different approach. > Now I have raised ITS#8893. We want to conclude on the approach before taking for implementation. Please kindly let us know if following approach is OK and if > any comments. > > *Requirement:* > > User shall be able to set multiple IPv4/IPv6 socket bind addresses, to be able to route the LDAP traffic via desired network interface. Based on the target IP > address type, first matching and valid source IP address will be picked for explicit binding*//**at client side*. Not sure I understand the value of a list of multiple addresses here. > > *Work items:* > > > 1. *LDAP option to set the IPv4/IPv6 socket bind addresses.* > > /Format: space separated list of IP addresses/ > > New configuration option LDAP_OPT_SOCKET_BIND_ADDRESSES (0x5013) will be introduced (in ldap.h) to be used via ldap_set_option. > > For example, > > char* p = 10.24.56.34 2001:0db8:85a3:0000:0000:8a2e:0370:7334; > ldap_set_option(NULL, LDAP_OPT_SOCKET_BIND_ADDRESSES, p); > > Bind addresses can also be provided in ldap.conf file via the option SOCKET_BIND_ADDRESSES, for example, > > SOCKET_BIND_ADDRESSES 10.24.56.45 10.24.56.46 2001:0db8:85a3:0000:0000:8a2e:0370:7334 > > Note : > Option set to ldap handle will override the global option. > Setting the option multiple times will override the previous values but does not append. > > > 2. *Parsing & validations* > > > Space separated IP addresses will be parsed & validated. IPv4 and IPv6 addresses are stored separately for easy of access during connection. > Basic syntax validation will be done for IPv4 or IPv6 addresses, if any error, setting of the option will fail and LDAP client will use the default IP address. > > ldapoptions structure in ldap-int.h will be modified to add new members > "char *ldo_local_IPV4_addresses" -> to hold client local IPv4 bind addresses > "char *ldo_local_IPV6_addresses" -> to hold client local IPv6 bind addresses Seems like these should be char* arrays, especially since we already have str2charray(). > Any new function /ldap_options_parseBindAddress/ () will be introduced in options.c to parse, validate and store the IP addresses to respective variables. This > function will be similar to ldap_url_parseHosts. > > Memory for ldo_local_IPV4_addresses & ldo_local_IPV6_addresses is dynamically allocated in the form of array for easy access. If any validation failure, no new > memory will be allocated and existing values will be retained. > > > 3. *Using Bind IP addresses during connection* > > > File:os-ip.c > Function: ldap_connect_to_host > - After the connection socket is created (ldap_int_socket) and before it is connected (ldap_pvt_connect). > Check if the target address family type, > *I*f it is AF_INET, IPv4 bind address list will be used. > - If the list is empty and LDAP option was set successfully earlier (IPv6 was set), binding will fail and error is returned. > - If the list is not empty and not able to bind to any of the provided IPv4 addresses, connection will fail> - If the list is empty and LDAP option setting failed earlier (during syntax validation), LDAP client will continue to use the kernel provided IPv4 address. > If it is AF_INET6, IPv6 bind address list will be used. > - If the list is empty and LDAP option was set successfully earlier (IPv4 was set), binding will fail and error is returned. > - If the list is not empty and not able to bind to any of the provided IPv6 addresses, connection will fail. > - If the list is empty and LDAP option setting failed earlier (during syntax validation), LDAP client will continue to use the kernel provided IPv6 address. What specific LDAP API error code will be returned in each instance? > > > > > *Regards,* > *Sudhir Singam* > > *DELIVERING BEST-IN-CLASS PLATFORM is our vision* > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

OpenLDAP Developer Day 2018
by Howard Chu 23 Aug '18

23 Aug '18

In case you missed it, we're holding an event to celebrate the 20th anniversary of the OpenLDAP Project this October in Germany. Talks are being solicited now. https://daasi.de/de/call-for-content_odd2018/ -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

cn=config support for non-overlay modules and naming conventions
by Quanah Gibson-Mount 02 Aug '18

02 Aug '18

The slapo-ppolicy overlay has a parameter for loading an external module for doing additional password checks. One example of this would be the LTB project's PPM (password policy module) extension. However, we currently have no method in OpenLDAP for supporting configuration for such a module via cn=config. Using this module, we can see two basic issues: a) There needs to be a way to load schema for the module for whatever its configuration items are b) There needs to be a way to use so that it can have multiple policies (similar to ppolicy) so that you can have different password checking policies. Something like: pwdCheckModule <modulepath> <policyDN>. In this way, you could have multiple password policies with different password check requirements. Additionally, we currently do not have a standard on a naming convention for manual pages, etc, for such an item. I would propose slapm-<name> (m for module), such as "slapm-ppm.5" Thoughts etc welcome. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

← Newer
1
...
9
10
11
12
13
14
15
...
142
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel