openldap-technical

openldap-technical@openldap.org

9897 discussions

openldap proxy with uid/gid lookup cache
by vadud3＠gmail.com 27 Jan '19

27 Jan '19

How do I include uid/gid lookup caching to my openldap proxy server? $ cat slapd.conf ### Schema includes ########################################################### include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema ## Module paths ############################################################## modulepath /usr/lib64/openldap/ moduleload back_ldap # Main settings ############################################################### pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args sizelimit unlimited TLSCertificateFile /root/data/certs/ldap.crt TLSCertificateKeyFile /root/data/certs/ldap.key ### Database definition (Proxy to AD) ######################################### database ldap readonly yes protocol-version 3 rebind-as-user yes uri "ldaps://ldap.example.com:1636" suffix "ou=People,dc=example,dc=net" ### Logging ################################################################### loglevel 0 (ignore the other similar email with no subjects.. apologize) -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

3 3

Copying SSHA userPassword from Oracle to OpenLDAP
by Nicholas Carl 23 Jan '19

23 Jan '19

Currently doing a targeted sync of userPassword field from one LDAP to another following this process. 1) Query using ldapsearch and grab userPassword field. 2) Deode string using base64 –d 3) Import resultant encrypted password into other ldap using ldapmodify. This process worked when the password decoded into {crypt} format, but after they upgraded and changed to {SSHA} format passwords, it no longer works. Also confirmed with Oracle LDAP admins that the decode matches our {SSHA} string. *Is there some additional configuration information I need to request from the oracle LDAP server administrators for server or client config in openldap?* # Querying other LDAP server $ ldapsearch -h oracleServer -D - -w - -b - "uid=-" | grep ^userPassword userPassword:: e1NTSEF9S3hNQVVoRGY0Y0ZMVXdVREZQb1VDMFNvRFdRb0c2TnNLRTVZUWc9PQ= $ ldapsearch -h oracleServer -D - -w - -b - "uid=-" | grep ^userPassword | base64 -d {SSHA}KxMAUhDf4cFLUwUDFPoUC0SoDWQoG6NsKE5YQg==base64: invalid input ## After importing decrypted into new server, the encrypted string matches. $ ldapsearch -h openLDAPServer -D - -w - "uid=-" | grep ^userPassword userPassword:: e1NTSEF9S3hNQVVoRGY0Y0ZMVXdVREZQb1VDMFNvRFdRb0c2TnNLRTVZUWc9PQ=

6 6

uniqueness on multiple attributes
by A. Schulze 21 Jan '19

21 Jan '19

Hello, my goal it to extend a uniqueness configuration. I do already enforce uniqueness of mail addresses: slapd.conf: moduleload unique.la overlay unique unique_uri ldap:///dc=basedn?mail?sub? that works. Now also address rewriting data should be migrated LDAP. Rewriting addresses are stored in the attribute "mailalternateaddress" Requirement: no address may occur twice no matter if stored as "mail" or "mailalternateaddress" Logical it's something like unique_uri (ldap:///dc=basedn?mail?sub?) OR (ldap:///dc=basedn?mail?sub?) Now I fail to correctly translate that to a valid configuration. https://www.openldap.org/software/man.cgi?query=slapo-unique say "unique_uri <[strict ][ignore ]URI[URI...]...>" with a formal definition of URI "ldap:///[base dn]?[attributes...]?scope[?filter]" It also say "Multiple URIs may be specified within a domain, allowing complex selections of objects." As the manpage doesn't give an example I tried: unique_uri ldap:///dc=ldap?mailalternateaddress?sub ldap:///dc=ldap?mail?sub slapd logs 5c445384 /etc/openldap/slapd.conf: line 149 (unique_uri ldap:///dc=ldap?mailalternateaddress?sub ldap:///dc=ldap?mail?sub) -> slapd starts but uniqueness is not enforced So I tried multiple versions: To make it readable: uri1=ldap:///dc=ldap?mailalternateaddress?sub uri2=ldap:///dc=ldap?mail?sub unique_uri uri1 uri2 unique_uri uri1uri2 unique_uri uri1,uri2 unique_uri uri1, uri2 unique_uri "uri1 uri2" unique_uri "uri1""uri2" unique_uri "uri1","uri2" unique_uri "uri1", "uri2" Mostly slapd failed to start with an error "invalid ldap urilist" If slapd started, the uniqueness wasn't enforced One version (unique_uri "uri1 uri2") result in slapd consume 100% cpu time. Anybody have a hint how to enforce uniqueness on multiple attributes? Andreas

2 3

lastbind module and missing forwarding updates
by David Magda 17 Jan '19

17 Jan '19

Hello, So I'm looking at the code for the /lastbind/ module, and I see the following: > "MAY ( olcLastBindPrecision $ olcLastBindForwardUpdates) )", https://github.com/openldap/openldap/blob/master/contrib/slapd-modules/last… However, when selecting various tagged releases (OPENLDAP_REL_ENG_2_4_[37-47]) I do not see the code. It was committed in October 2013: https://github.com/openldap/openldap/commit/44e9bda0e42f40e0baf0a2c0ef733eb… This would have been around the time of 2.4.37, but I don't see ITS#7721 mentioned in the release notes anywhere either, only ITS#772{0,2,3,5}: https://www.openldap.org/software/release/changes.html Is there a reason why this commit is in "master", but never made it to any official release? Regards, David

2 3

Shared memory error after reboot
by Marc Roos 17 Jan '19

17 Jan '19

I am getting this error after (re)booting, if I restart slapd it is gone. I guess I can ignore this message because slapd will recover from this eventually? Or do I need to give it a restart every time? After reboot: jan 16 14:57:19 mail04 slapd[3283]: @(#) $OpenLDAP: slapd 2.4.44 (Oct 30 2018 23:14:27) $#012#011mockbuild@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap -2.4.44/openldap-2.4.44/servers/slapd Jan 16 14:57:19 mail04 slapd[3283]: syncrepl rid=504 searchbase="dc=backoffice,dc=local": no retry defined, using default Jan 16 14:57:19 mail04 slapd[3285]: bdb(dc=backoffice,dc=local): BDB0118 shmat: id 884736: unable to attach to shared system memory region: Invalid argument Jan 16 14:57:19 mail04 slapd[3285]: hdb_db_open: database "dc=backoffice,dc=local": shared memory env open failed, assuming stale env. Jan 16 14:57:19 mail04 slapd[3285]: slapd starting Jan 16 14:57:20 mail04 slapd[3285]: do_syncrep2: rid=504 LDAP_RES_INTERMEDIATE - REFRESH_DELETE After restart: Jan 16 14:58:59 mail04 slapd[3285]: daemon: shutdown requested and initiated. Jan 16 14:58:59 mail04 slapd[3285]: slapd shutdown: waiting for 1 operations/tasks to finish Jan 16 14:58:59 mail04 slapd[3285]: slapd stopped. Jan 16 14:58:59 mail04 slapd[3402]: @(#) $OpenLDAP: slapd 2.4.44 (Oct 30 2018 23:14:27) $#012#011mockbuild@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap -2.4.44/openldap-2.4.44/servers/slapd Jan 16 14:58:59 mail04 slapd[3402]: syncrepl rid=504 searchbase="dc=backoffice,dc=local": no retry defined, using default Jan 16 14:58:59 mail04 slapd[3404]: slapd starting Jan 16 14:58:59 mail04 slapd[3404]: do_syncrep2: rid=504 LDAP_RES_INTERMEDIATE - REFRESH_DELETE openldap-2.4.44-20.el7.x86_64 openldap-clients-2.4.44-20.el7.x86_64 Linux mail04 3.10.0-957.1.3.el7.x86_64 #1 SMP Thu Nov 29 14:49:43 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux CentOS Linux release 7.6.1810 (Core)

4 5

RE: Shared memory error after reboot
by Marc Roos 16 Jan '19

16 Jan '19

>> >> >> I am getting this error after (re)booting, if I restart slapd it is >> gone. I guess I can ignore this message because slapd will recover from >> this eventually? Or do I need to give it a restart every time? >> >> >> After reboot: >> >> jan 16 14:57:19 mail04 slapd[3283]: @(#) $OpenLDAP: slapd 2.4.44 (Oct 30 >> 2018 23:14:27) >> $#012#011mockbuild@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap >> -2.4.44/openldap-2.4.44/servers/slapd >> Jan 16 14:57:19 mail04 slapd[3283]: syncrepl rid=504 >> searchbase="dc=backoffice,dc=local": no retry defined, using default >> Jan 16 14:57:19 mail04 slapd[3285]: bdb(dc=backoffice,dc=local): BDB0118 >> shmat: id 884736: unable to attach to shared system memory region: >> Invalid argument > >It means: > >a) You're using shared memory regions with a BDB backend >b) That slapd is not cleanly shut down on a reboot. It sounds like perhaps >you have a broken init system. > >I would note that BDB based backends are deprecated. It's advised to use >back-mdb instead. I just did a service slapd stop before a reboot, gives the same. What does Slapd do when "assuming stale env.". Tries it to recover? Jan 16 17:41:47 mail04 slapd[3404]: slapd stopped. ... ... ... Jan 16 17:42:18 mail04 slapd[3286]: @(#) $OpenLDAP: slapd 2.4.44 (Oct 30 2018 23:14:27) $#012#011mockbuild@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap -2.4.44/openldap-2.4.44/servers/slapd Jan 16 17:42:18 mail04 slapd[3286]: syncrepl rid=504 searchbase="dc=backoffice,dc=local": no retry defined, using default Jan 16 17:42:18 mail04 slapd[3288]: bdb(dc=backoffice,dc=local): BDB0118 shmat: id 0: unable to attach to shared system memory region: Invalid argument Jan 16 17:42:18 mail04 slapd[3288]: hdb_db_open: database "dc=backoffice,dc=local": shared memory env open failed, assuming stale env. Jan 16 17:42:18 mail04 slapd[3288]: slapd starting Jan 16 17:42:18 mail04 slapd[3288]: do_syncrep2: rid=504 LDAP_RES_INTERMEDIATE - REFRESH_DELETE

1 0

OpenLDAP Proxy - user authentification problem
by Martin Toth 12 Jan '19

12 Jan '19

Hi all, I am trying to configure OpenLDAP proxy to proxy searches to my 2 (two) different AD servers. I am testing/trying to login as domain user to application that is configured to verify users against this proxy. Context is : - allowed app users from AD1 will be placed to "AllowAPP group" on AD1 - i.e. - CN=AllowAPP,OU=Groups,OU=Something,DC=domain,DC=xy - allowed app users from AD2 will be placed to "AllowAPP group" on AD2 - i.e. - CN=Allow,OU=App,OU=Group,DC=domain2,DC=local - these two groups are be placed in different OUs on both ADs (Active Directories) so special rewriting have to be done on both URIs Problem is that I don't know how to correctly authentificate users. App configuration is that it will allow login only to user which is member of CN=AllowAPP,OU=Groups,DC=grouped,DC=all "virtual” group. All working fine when I am searching group membership of users with ldapsearch. I can find members of both groups by searching virtual group mentioned upper. I suspect there is problem with passing user credentials to one of AD servers that I am proxying to. I am using sAMAccountName as user login. This is debug search base when I am trying to login from app : SRCH base="dc=grouped,dc=all" scope=2 deref=2 filter="(?SAMACCOUNTNAME=test.user)” This is error produced while I am trying to login as user : meta_back_search[0] match="" err=1 (Operations error) text="000004DC: LdapErr: DSID-0C09075A, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1". Am I doing something wrong? Can you advise? I am probably missing something that refers to validating users credentials.. Thanks, BR, Martin This is my configuration so far : database meta suffix "dc=grouped,dc=all” rootdn "cn=admin,dc=grouped,dc=all” rootpw "password” readonly yes lastmod off uri ldap://AD1/dc=grouped,dc=all suffixmassage "dc=grouped,dc=all" "dc=domain,dc=xy" idassert-bind bindmethod=simple binddn="CN=bind,CN=Users,dc=domain,dc=xy" credentials="password" mode=none flags=non-prescriptive rewriteEngine on chase-referrals yes rewriteContext default rewriteContext searchBase rewriteRule "CN=AllowAPP,OU=Groups,DC=grouped,DC=all$" "CN=AllowAPP,OU=Groups,OU=Something,DC=domain,DC=xy" "@" uri ldap://AD2/dc=grouped,dc=all suffixmassage "dc=grouped,dc=all" "dc=domain2,dc=local" idassert-bind bindmethod=simple binddn="CN=binduser,CN=Users,dc=domain2,dc=local" credentials=“password" mode=none flags=non-prescriptive rewriteEngine on chase-referrals yes rewriteContext default rewriteContext searchBase rewriteRule "CN=AllowAPP,OU=Groups,DC=grouped,DC=all$" "CN=Allow,OU=App,OU=Group,DC=domain2,DC=local" "@"

1 0

Switch OpenLDAP backend database from HDB to MDB
by SHarbich＠t-online.de 12 Jan '19

12 Jan '19

Hello my dears, I have a question about my approach. I want to migrate the backend database of my OpenLDAP server from HDB to MDB. I would do this as follows: Backup my LDAP nice slapcat -n 0 > ${BACKUP_PATH}/config.ldif nice slapcat -n 1 > ${BACKUP_PATH}/meinedomain.local.ldif cp -rp /var/lib/ldap /var/lib/ldap.bak cp -rp /etc/ldap/slapd.d /etc/ldap/slapd.d.bak Modify entries in these two dates with a text editor from hdb to mdb. Stop the OpenLDAP service sudo systemctl stop sldap.service Delete the directories of the LDAP tree rm -r /var/lib/ldap /etc/ldap/slapd.d Rebuild the LDAP database sudo dpkg-reconfigure slapd In the options select the database MDB and leave everything else as before. Then restore the LDAP tree. sudo slapadd -F /etc/ldap/slapd.d -n 0 -l ${BACKUP_PATH}/config.ldif sudo slapadd -F /etc/ldap/slapd.d -n 1 -l ${BACKUP_PATH}/meinedomain.local.ldif Restart the OpenLDAP service sudo systemctl restart slapd.service That should have been my opinion. Can you think of something else I have to pay attention to? Greetings from Stefan Harbich

2 1

Add supportedExtensions to LDAP proxy
by Philip Brusten 11 Jan '19

11 Jan '19

Hi We have set up an LDAP proxy (slapd-ldap) in front of a NetIQ eDirectory. The LDAP-client which connects to the proxy uses an extended operation, but the request fails because the proxy is not aware of this extension: do_extended: unsupported operation "2.16.840.1.113719.1.39.42.100.... RESULT tag=120 err=2 text=unsupported extended operation # ldapsearch -H ldaps://proxy:port -b '' -s base -D <snip> -W -LLL supportedExtension Enter LDAP Password: dn: supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.1.8 Whereas the NetIQ eDirectory back-end supports lots of custom NetIQ extensions: # ldapsearch -H ldaps://backend:port -b '' -s base -D <snip> -W -LLL supportedExtension Enter LDAP Password: dn: supportedExtension: 2.16.840.1.113719.1.39.42.100.1 supportedExtension: 2.16.840.1.113719.1.39.42.100.3 supportedExtension: 2.16.840.1.113719.1.39.42.100.5 supportedExtension: 2.16.840.1.113719.1.39.42.100.7 supportedExtension: 2.16.840.1.113719.1.39.42.100.9 supportedExtension: 2.16.840.1.113719.1.39.42.100.11 supportedExtension: 2.16.840.1.113719.1.39.42.100.13 supportedExtension: 2.16.840.1.113719.1.39.42.100.15 supportedExtension: 2.16.840.1.113719.1.39.42.100.17 supportedExtension: 2.16.840.1.113719.1.39.42.100.19 supportedExtension: 2.16.840.1.113719.1.39.42.100.21 supportedExtension: 2.16.840.1.113719.1.39.42.100.23 supportedExtension: 2.16.840.1.113719.1.39.42.100.25 supportedExtension: 2.16.840.1.113719.1.39.42.100.27 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 2.16.840.1.113719.1.39.42.100.29 supportedExtension: 2.16.840.1.113719.1.14.100.1 supportedExtension: 2.16.840.1.113719.1.14.100.3 supportedExtension: 2.16.840.1.113719.1.14.100.5 supportedExtension: 2.16.840.1.113719.1.14.100.7 supportedExtension: 2.16.840.1.113719.1.14.100.9 supportedExtension: 2.16.840.1.113719.1.14.100.11 supportedExtension: 2.16.840.1.113719.1.14.100.13 supportedExtension: 2.16.840.1.113719.1.14.100.15 supportedExtension: 2.16.840.1.113719.1.14.100.17 supportedExtension: 2.16.840.1.113719.1.14.100.21 supportedExtension: 2.16.840.1.113719.1.14.100.23 supportedExtension: 2.16.840.1.113719.1.14.100.25 supportedExtension: 2.16.840.1.113719.1.14.100.27 supportedExtension: 2.16.840.1.113719.1.14.100.29 supportedExtension: 2.16.840.1.113719.1.14.100.31 supportedExtension: 2.16.840.1.113719.1.14.100.33 supportedExtension: 2.16.840.1.113719.1.14.100.35 supportedExtension: 2.16.840.1.113719.1.14.100.37 supportedExtension: 2.16.840.1.113719.1.14.100.39 supportedExtension: 2.16.840.1.113719.1.14.100.41 supportedExtension: 2.16.840.1.113719.1.14.100.43 supportedExtension: 2.16.840.1.113719.1.14.100.45 supportedExtension: 2.16.840.1.113719.1.14.100.47 supportedExtension: 2.16.840.1.113719.1.14.100.49 supportedExtension: 2.16.840.1.113719.1.14.100.51 supportedExtension: 2.16.840.1.113719.1.14.100.53 supportedExtension: 2.16.840.1.113719.1.14.100.55 supportedExtension: 2.16.840.1.113719.1.14.100.57 supportedExtension: 2.16.840.1.113719.1.14.100.59 supportedExtension: 2.16.840.1.113719.1.14.100.61 supportedExtension: 2.16.840.1.113719.1.14.100.63 supportedExtension: 2.16.840.1.113719.1.14.100.65 supportedExtension: 2.16.840.1.113719.1.14.100.67 supportedExtension: 2.16.840.1.113719.1.14.100.69 supportedExtension: 2.16.840.1.113719.1.14.100.71 supportedExtension: 2.16.840.1.113719.1.14.100.73 supportedExtension: 2.16.840.1.113719.1.14.100.75 supportedExtension: 2.16.840.1.113719.1.14.100.77 supportedExtension: 2.16.840.1.113719.1.14.100.79 supportedExtension: 2.16.840.1.113719.1.14.100.81 supportedExtension: 2.16.840.1.113719.1.14.100.19 supportedExtension: 2.16.840.1.113719.1.14.100.83 supportedExtension: 2.16.840.1.113719.1.14.100.85 supportedExtension: 2.16.840.1.113719.1.14.100.87 supportedExtension: 2.16.840.1.113719.1.14.100.89 supportedExtension: 2.16.840.1.113719.1.14.100.91 supportedExtension: 2.16.840.1.113719.1.14.100.93 supportedExtension: 2.16.840.1.113719.1.148.100.1 supportedExtension: 2.16.840.1.113719.1.148.100.3 supportedExtension: 2.16.840.1.113719.1.148.100.5 supportedExtension: 2.16.840.1.113719.1.148.100.7 supportedExtension: 2.16.840.1.113719.1.148.100.9 supportedExtension: 2.16.840.1.113719.1.148.100.11 supportedExtension: 2.16.840.1.113719.1.148.100.13 supportedExtension: 2.16.840.1.113719.1.148.100.15 supportedExtension: 2.16.840.1.113719.1.148.100.17 supportedExtension: 2.16.840.1.113719.1.27.100.1 supportedExtension: 2.16.840.1.113719.1.27.100.3 supportedExtension: 2.16.840.1.113719.1.27.100.5 supportedExtension: 2.16.840.1.113719.1.27.100.7 supportedExtension: 2.16.840.1.113719.1.27.100.11 supportedExtension: 2.16.840.1.113719.1.27.100.13 supportedExtension: 2.16.840.1.113719.1.27.100.15 supportedExtension: 2.16.840.1.113719.1.27.100.17 supportedExtension: 2.16.840.1.113719.1.27.100.19 supportedExtension: 2.16.840.1.113719.1.27.100.21 supportedExtension: 2.16.840.1.113719.1.27.100.23 supportedExtension: 2.16.840.1.113719.1.27.100.25 supportedExtension: 2.16.840.1.113719.1.27.100.27 supportedExtension: 2.16.840.1.113719.1.27.100.29 supportedExtension: 2.16.840.1.113719.1.27.100.31 supportedExtension: 2.16.840.1.113719.1.27.100.33 supportedExtension: 2.16.840.1.113719.1.27.100.35 supportedExtension: 2.16.840.1.113719.1.27.100.37 supportedExtension: 2.16.840.1.113719.1.27.100.39 supportedExtension: 2.16.840.1.113719.1.27.100.41 supportedExtension: 2.16.840.1.113719.1.27.100.96 supportedExtension: 2.16.840.1.113719.1.27.100.98 supportedExtension: 2.16.840.1.113719.1.27.100.101 supportedExtension: 2.16.840.1.113719.1.27.100.103 supportedExtension: 2.16.840.1.113719.1.142.100.1 supportedExtension: 2.16.840.1.113719.1.142.100.4 supportedExtension: 2.16.840.1.113719.1.142.100.6 supportedExtension: 2.16.840.1.113719.1.27.100.9 supportedExtension: 2.16.840.1.113719.1.27.100.43 supportedExtension: 2.16.840.1.113719.1.27.100.45 supportedExtension: 2.16.840.1.113719.1.27.100.47 supportedExtension: 2.16.840.1.113719.1.27.100.49 supportedExtension: 2.16.840.1.113719.1.27.100.51 supportedExtension: 2.16.840.1.113719.1.27.100.53 supportedExtension: 2.16.840.1.113719.1.27.100.55 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 2.16.840.1.113719.1.27.100.79 supportedExtension: 2.16.840.1.113719.1.27.100.84 supportedExtension: 2.16.840.1.113719.1.27.103.1 supportedExtension: 2.16.840.1.113719.1.27.103.2 Is there a way to allow these extensions on the proxy? Thx, Philip

3 7

dynlist and entryUUID
by Jon C Kidder 10 Jan '19

10 Jan '19

I have a very rigid LDAP client and I need to present the entryUUID as both entryUUID and nsUniqueID in the user records. I have chosen to do this with the dynlist overlay rather than build a process to replicate the data. I've had the overlay deployed for quite some time and have several dynamically generated attributes. However, I'm finding that this doesn't work with entryUUID? Here's the relevant configuration: dn: olcOverlay={0}dynlist,olcDatabase={2}mdb,cn=config olcDlAttrSet: {4}aepAuxUser nsUniqueIDURL nsUniqueID nsUniqueID:entryUUID dn: uid=TestEmployee,ou=Employees,ou=Users,dc=global,dc=aep,dc=com nsUniqueIDURL: ldap:///uid= TestEmployee,ou=Employees,ou=Users,dc=global,dc=aep,dc=com?entryUUID?base?(objectClass=*) When I execute a search on the above user DN the nsUniqueID attribute doesn't appear but all of my other dynamic attributes do appear and have correct values. I have modified both of the above entries replacing entryUUID with any number of attributes and nsUniqueID will suddenly appear as expected and contain the value of the attribute chosen. I can't get this to work using entryUUID. I have not tried it with other operational attributes yet. Is this because the overlay doesn’t work with operational attributes? Is this a bug? JON C KIDDER | MIDDLEWARE ADMINISTRATOR LEAD JCKIDDER(a)AEP.COM | D:614.716.4970 1 RIVERSIDE PLAZA, COLUMBUS, OH 43215

3 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