openldap-technical

openldap-technical@openldap.org

9 participants
9868 discussions

Spurious Start TLS failed errors on proxyed bind OpenLDAP 2.4.40
by Janne Peltonen 29 Jan '19

29 Jan '19

Hi! We've got a proxy OpenLDAP setup using the "ldap" proxy database (the newer "meta" backend had some issues, so I couldn't use that one). Most of the time, the proxy bind goes OK, but sometimes, the connection goes like this (proxy log, using ldaps): --clip-- Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 fd=96 ACCEPT from IP=128.214.54.152:36460 (IP=0.0.0.0:636) Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 fd=96 TLS established tls_ssf=256 ssf=256 Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 op=0 BIND dn="<removed>" method=128 Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 op=0 RESULT tag=97 err=52 text=Start TLS failed Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 fd=96 closed (connection lost) --clip-- On the backend, this appears to be the case that a new connection kind of overruns the old one; see what happens with connection 6983: --clip-- Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 fd=23 ACCEPT from IP=128.214.222.155:46144 (IP=0.0.0.0:389) Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 fd=41 ACCEPT from IP=128.214.222.155:46146 (IP=0.0.0.0:389) Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 op=0 STARTTLS Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 op=1 UNBIND Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 fd=23 closed Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=0 STARTTLS Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=0 RESULT oid= err=0 text= Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 fd=41 TLS established tls_ssf=256 ssf=256 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=1 BIND dn="<removed>" method=128 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=1 BIND dn="<removed>" mech=SIMPLE ssf=0 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=1 RESULT tag=97 err=0 text= [SRCH and result lines] Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=3 UNBIND Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 fd=41 closed --clip-- This doesn't seem to have any correlation to the amount of binds of server load, at least that I'm aware - and anyway, the servers are nowhere near at capacity - we only get ~2 binds per second. Normal connection would look like this: --clip-- Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 fd=159 ACCEPT from IP=128.214.54.152:36362 (IP=0.0.0.0:636) Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 fd=159 TLS established tls_ssf=256 ssf=256 Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 op=0 BIND dn="<removed>" method=128 Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 op=0 BIND dn="<removed>" mech=SIMPLE ssf=0 Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 op=0 RESULT tag=97 err=0 text= [SRCH and SEARCH RESULT lines] Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7650 op=219 UNBIND Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7650 fd=159 closed --clip-- So this far, it looks as if the problem was that if we accept a second connection for the same client before the proxy has had time to do a bind (or indeed, a STARTTLS for the bind) on the backend for the second connection. But we seem to be getting spurious Start TLS failed messages also without any competing connections. Here's one using ldap+STARTTLS but no other ACCEPTs anywhere near: --clip-- Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 fd=62 ACCEPT from IP=128.214.173.135:43148 (IP=0.0.0.0:389) Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=0 STARTTLS Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=0 RESULT oid= err=0 text= Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 fd=62 TLS established tls_ssf=256 ssf=256 Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=1 BIND dn="ou=shibboleth,ou=login,dc=helsinki,dc=fi" method=128 Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=1 RESULT tag=97 err=52 text=Start TLS failed Jan 17 17:46:22 ldap-r-1 slapd[28738]: conn=529684 fd=62 closed (connection lost) --clip-- on the proxy, and backend: --clip-- Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 fd=92 ACCEPT from IP=128.214.222.155:48996 (IP=0.0.0.0:389) Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 op=0 STARTTLS Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 op=0 RESULT oid= err=0 text= Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 fd=92 closed (TLS negotiation failure) --clip-- Succesful ldap+starttls connection on proxy: --clip-- Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 fd=54 ACCEPT from IP=128.214.173.137:48700 (IP=0.0.0.0:389) Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=0 STARTTLS Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=0 RESULT oid= err=0 text= Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 fd=54 TLS established tls_ssf=256 ssf=256 Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=1 BIND dn="<removed>" method=128 Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=1 BIND dn="<removed>" mech=SIMPLE ssf=0 Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=1 RESULT tag=97 err=0 text= [SRCH and SEARCH RESULT lines] Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=3 UNBIND Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 fd=54 closed --clip-- Any ideas what could be causing these? It's a bit hard to pinpoint the problem, since it happens so rarely - we seem to get a couple dozen of these every hour to around 16 000 succesful binds, not really depending on system load. This is RHEL 7 and OpenLDAP 2.4.40. It may be the case that the same DN binding very often increases the probability of a Start TLS failed error, which I guess would be the first case (a new ACCEPT + BIND for a DN too soon after the previous one). But as I said, these seem to also sometimes appear even without any other connections being opened at the same time. (Although there might be some old connections open for the same DN.) --Janne Peltonen University of Helsinki

5 11

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

28 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical