Proxying an insecure LDAP and authenticate using another
by Kevin Olbrich
Hi!
I have a case where I got access to a read-only LDAP that has no
authentication (everything is public). It is located in a secure and
trusted environment.
Now I want to expose the directory to another network and like to add
authentication but can not add it to the source (proprietary
software).
I need to proxy this server and authenticate the users using active directory.
I know how to proxy AD including passthrough authentication but can I
proxy another directory and authenticate using another? If yes, how?
Thank you very much.
Kind regards
Kevin Olbrich
1 year, 3 months
Re: Pass-through
by Stéphane Veyret
Could it be that the SASL global configuration (also given in first
message) is wrong? I only set those 2 options:
olcSaslHost: localhost
olcSaslSecProps: none
1 year, 3 months
Re: Error: Could not locate TLS/SSL package
by Jeffrey Walton
On Wed, Aug 17, 2022 at 12:16 PM Quanah Gibson-Mount
<quanah(a)fast-mail.org> wrote:
>
> --On Wednesday, August 17, 2022 2:11 PM +0530 Vijay Maidarkar
> <vmaidarkar(a)gmail.com> wrote:
>
> Hi, please keep replies on the list.
> > Find below answers.
> >
> > Where is it installed?
> > $ which openssl
> >
> > /usr/local/bin/openssl
> >
> > $ ldd /usr/local/bin/openssl
> > linux-vdso.so.1 => (0x00007fff931e6000)
> > libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007f7f7a570000)
> > libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f7f7a087000)
> > libdl.so.2 => /lib64/libdl.so.2 (0x00007f7f79e83000)
> > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7f79c67000)
> > libc.so.6 => /lib64/libc.so.6 (0x00007f7f79899000)
> > /lib64/ld-linux-x86-64.so.2 (0x00007f7f7a802000)
> >
> > How was it installed?
> > I've downloaded the archive & done compilation from below cmds.
> >
> > $ ./config
> > $ make
> > $ make install
There are other options you should be using for OpenSSL. At minimum,
you probably want enable-ec_nistp_64_gcc_128 on x86_64. Also see
https://wiki.openssl.org/index.php/Compilation_and_Installation#Configure...
.
> So, you built it yourself so there will be no development package. I'm not
> sure why you built such an ancient version of OpenSSL (you listed OpenSSL
> 1.1.1g when 1.1.1q is the most recent), since it's vulnerable to multiple
> critical CVEs.
>
> I'd strongly advise using the packages from EPEL if you insist on staying
> on CentOS7 (which is near end of life).
>
> If you are going to use your own OpenSSL build, I can't emphasize enough
> the importance of using a current release. Since you're doing this in an
> unpackaged way, maintenance is going to be a nightmare.
>
> Since you've built it yourself into its own location, you have to tell the
> configure script where to find the development headers, like:
>
> CPPFLAGS="/usr/local/include" LDFLAGS="-L/usr/local/lib
> -Wl,-rpath,/usr/local/lib" ./configure ...
+1 for the RPATH.
Linux (and other OSes) have a (mis)feature of building against one
version of a library, and runtime linking against another version of
the library. Be sure to specify the RPATH to avoid the bug.
(If you want to see the effects of linking against the wrong library
at runtime, see
https://www.openwall.com/lists/oss-security/2020/07/20/1).
Nowadays on Linux you should specify a RUNPATH, not a RPATH. The
RUNPATH allows LD_LIBRARY overrides to search paths. It is recommended
by the folks who write the runtime loaders. The options you need are:
* -Wl,-rpath,<lib path> (enables RPATH)
* -Wl,--enable-new-dtags (enables RUNPATH)
Jeff
1 year, 3 months
Re: Error: Could not locate TLS/SSL package
by Quanah Gibson-Mount
--On Wednesday, August 17, 2022 2:11 PM +0530 Vijay Maidarkar
<vmaidarkar(a)gmail.com> wrote:
>
>
>
>
> Hi Quanah,
Hi, please keep replies on the list.
> Find below answers.
>
> Where is it installed?
> $ which openssl
>
> /usr/local/bin/openssl
>
> $ ldd /usr/local/bin/openssl
> linux-vdso.so.1 => (0x00007fff931e6000)
> libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007f7f7a570000)
> libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f7f7a087000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00007f7f79e83000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7f79c67000)
> libc.so.6 => /lib64/libc.so.6 (0x00007f7f79899000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f7f7a802000)
>
> How was it installed?
> I've downloaded the archive & done compilation from below cmds.
>
> $ ./config
> $ make
> $ make install
So, you built it yourself so there will be no development package. I'm not
sure why you built such an ancient version of OpenSSL (you listed OpenSSL
1.1.1g when 1.1.1q is the most recent), since it's vulnerable to multiple
critical CVEs.
I'd strongly advise using the packages from EPEL if you insist on staying
on CentOS7 (which is near end of life).
If you are going to use your own OpenSSL build, I can't emphasize enough
the importance of using a current release. Since you're doing this in an
unpackaged way, maintenance is going to be a nightmare.
Since you've built it yourself into its own location, you have to tell the
configure script where to find the development headers, like:
CPPFLAGS="/usr/local/include" LDFLAGS="-L/usr/local/lib
-Wl,-rpath,/usr/local/lib" ./configure ...
However, I would again strongly advise you not go the route of building the
software yourself unless you're going to do it in a packaged way (I.e. make
RPMs) so that you can upgrade whenever there's a new vulnerability.
Even more, I'd strongly advise just using the pre-built packages provided
by either Symas (Which offers current builds of both OpenLDAP 2.5 and
OpenLDAP 2.6 + supporting libraries) or the LTB project.
<https://repo.symas.com/>
<https://ltb-project.org/>
Regards,
Quanah
1 year, 3 months
Error: Could not locate TLS/SSL package
by vmaidarkar＠gmail.com
Hi Team,
I'm compiling OpenLDAP 2.5.13 on CentOS 7 & OpenSSL 1.1.1g is already installed & below is the command.
./configure --prefix=/opt/deployment/openldap_v13 --sysconfdir=/opt/deployment/openldap_v13/etc --localstatedir=/opt/deployment/openldap_v13/var --libexecdir=/opt/deployment/openldap_v13/libexec --enable-overlays=mod --enable-modules --enable-accesslog --enable-auditlog --enable-collect --enable-memberof --enable-syncprov --with-tls=openssl --enable-dynamic --enable-crypt --enable-slapd --enable-rlookups --disable-perl --enable-ppolicy --enable-backends=mod --disable-ndb --disable-sql --disable-shell --disable-bdb --disable-hdb
I'm getting the below error of OpenSSL.
checking for openssl/ssl.h... yes
checking for SSL_export_keying_material_early in -lssl... no
configure: error: Could not locate TLS/SSL package
Could you please suggest how to fix this issue.
Thanks,
Vijay
1 year, 3 months
Unable to connect to 636 secure port using LDAP library
by BANDANI MAHARANA
Hi Team,
I am trying to connect to an Active directory server using 636 port for
secure connection. I am using the openldap library to establish the
connection.
Implementation is completed for insecure connection using 389 port. Below
is the code snippet I am using to establish the connection with ldap server
in 636 port.
LDAP * ldap_handler;
int return_value = ldap_initialize(ldap_handler, "ldaps://
TestServer.mylab.com:636"); //server url
if (return_value == LDAP_SUCCESS) {
cout<<"LDAP initialized successfully"; // this is successful
for me
} else {
cout<<"LDAP initialization failed";
}
int return_value = ldap_set_option(*ldap_handler,
LDAP_OPT_PROTOCOL_VERSION, LDAP_VERSION3);
if(return_value == LDAP_SUCCESS) {
cout<<"success"; // this is successful for me
} else {
cout<<"failed";
}
const char * CACERT_FILE_PATH = "certificate/mylab-TESTSERVER-CA.cer";
//certificate path
int return_value1 = ldap_set_option(*ldap_handler,
LDAP_OPT_X_TLS_CACERTFILE, CACERT_FILE_PATH);
if (return_value1 == LDAP_SUCCESS) {
} else {
// its failing here with error -1, and error string "Can't contact to LDAP
server"
}
int return_value = ldap_simple_bind_s(*ldap_handler, "mylab\administrator",
""pwd@1234");
if (return_value == LDAP_SUCCESS) {
//success
} else {
// its failing here with error -1, and error string "Can't contact to LDAP
server"
}
I have verified the same thing is working when connecting to 389 port.
Could you please suggest how to make this work for secure ldap connection
over ssl? Please provide some examples or references. It will be helpful
for me.
Thanks & Regards,
Bandani
1 year, 3 months
LDAP Failure: {'desc': "Can't contact LDAP server}
by Shaheena Kazi
Hello,
I am using Debian 11.
Openldap : 2.4.57+dfsg-3+deb11u1
python3-ldap : 3.2.0-4+b3
python3-ldap3: 2.8.1-1
TLS - 1.3
Openssl - 1.1.1n-0+deb11u3
I am try to set a new connect and then import files using below commands:
ldapcon = ldap.initialize('ldap://localhost')
ldapcon.set_option(ldap.OPT_PROTOCOL_VERSION, ldap.VERSION3)
ldapcon.set_option(ldap.OPT_X_TLS_REQUIRE_CERT, ldap.OPT_X_TLS_NEVER)
ldapcon.set_option(ldap.OPT_X_TLS_NEWCTX, 0)
dn_to_add = 'cn=test.user,ou=people,dc=framework,dc=protegrity,dc=com'
modlist_to_add = [('uid', [b'test.user']), ('objectclass',
[b'inetOrgPerson', b'posixAccount', b'top']), ('uidnumber', [b'1003']),
('gidnumber', [b'100']), ('homedirectory', [b'/home/test.user']),
('userpassword', [b'qwer1234']), ('givenname', [b'test']), ('sn',
[b'user']), ('displayname', [b'test user']), ('loginshell',
[b'/usr/local/sbin/manager']), ('cn', [b'test.user']), ('description',
[b'testing']), ('pwdreset', [b'TRUE'])]
*********
But when I run this - ldapcon.add_s(dn_to_add, modlist_to_add)
The slapd service crashes and I get below error
LDAP Failure: {'desc': "Can't contact LDAP server}
ldap.CONFIDENTIALITY_REQUIRED: {'desc': 'Confidentiality required', 'info':
'TLS confidentiality required'}
Can u guys help me here as in what am I missing on and why the add_s is
causing my slapd to crash
Regards,
Shaheena K
1 year, 3 months
symas pacakages on Debian
by Ulf Volmer
Hello,
I'm running symas OpenLDA on Debian 11. Today we got an upgrade, which
make the server unable to start:
apt show symas-openldap-server
Package: symas-openldap-server
Version: 2.6.3-1bullseye1
sudo systemctl status slapd
● symas-openldap-server.service - Symas OpenLDAP Server Daemon
Loaded: loaded (/etc/systemd/system/symas-openldap-server.service;
enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/symas-openldap-server.service.d
└─override.conf
/run/systemd/system/service.d
└─zzz-lxc-service.conf
Active: failed (Result: exit-code) since Fri 2022-08-05 13:20:57
CEST; 8min ago
Docs: man:slapd
man:slapd-config
man:slapd-mdb
Process: 536 ExecStart=/opt/symas/lib/slapd -d 0 -h ${SLAPD_URLS}
$SLAPD_OPTIONS (code=exited, status=254)
Main PID: 536 (code=exited, status=254)
CPU: 13ms
Aug 05 13:20:57 ldap3.lan.u-v.de systemd[1]: Starting Symas OpenLDAP
Server Daemon...
Aug 05 13:20:57 ldap3.lan.u-v.de slapd[536]: ldap_int_sasl_init: SASL
library version mismatch: expected 2.1.28, got 2.1.27
Aug 05 13:20:57 ldap3.lan.u-v.de systemd[1]:
symas-openldap-server.service: Main process exited, code=exited,
status=254/n/a
Aug 05 13:20:57 ldap3.lan.u-v.de systemd[1]:
symas-openldap-server.service: Failed with result 'exit-code'.
Aug 05 13:20:57 ldap3.lan.u-v.de systemd[1]: Failed to start Symas
OpenLDAP Server Daemon.
dpkg -l|grep sasl
ii gsasl-common 1.10.0-4+deb11u1 all
GNU SASL platform independent files
ii libgsasl7:amd64 1.10.0-4+deb11u1
amd64 GNU SASL library
ii libsasl2-2:amd64 2.1.27+dfsg-2.1+deb11u1
amd64 Cyrus SASL - authentication abstraction library
ii libsasl2-modules:amd64 2.1.27+dfsg-2.1+deb11u1
amd64 Cyrus SASL - pluggable authentication modules
ii libsasl2-modules-db:amd64 2.1.27+dfsg-2.1+deb11u1
amd64 Cyrus SASL - pluggable authentication modules (DB)
ii libsasl2-modules-gssapi-mit:amd64 2.1.27+dfsg-2.1+deb11u1
amd64 Cyrus SASL - pluggable authentication modules (GSSAPI)
rc sasl2-bin 2.1.27+dfsg-2.1+deb11u1
amd64 Cyrus SASL - administration programs for SASL users database
ii symas-cyrus-sasl-lib 2.1.27-4bullseye1
amd64 Cyrus-SASL Libraries
Any help is appreciated.
Best regards
Ulf
1 year, 3 months
OpenLDAP on Debian 11: missing TLS ciphers?
by Jochen Keutel
Hello,
we installed the standard OpenLDAP package on Debian 11. Checking the
TLS ciphers offered by the server we could see that all six Camellia
ciphers are gone (128 and 256, for TLS 1.0, 1.1, 1.2) compared with the
standard OpenLDAP package on Debian 9.
Is this special to the Debian package? Or: Has Gnutls changed something?
We did run into this issue because some special devices (e.G. Cisco
Prime Collaboration Assurance) cannot connect to the new OpenLDAP
server. The server logfile states: TLS handshake: negotiation failure.
It's not yet clear whether they really can "speak" only Camellia ...
Regards
Jochen.
1 year, 3 months
Severe Performance Problems with dynlist on OpenLDAP 2.5+
by Bradley T Gill
We have been struggling with an upgrade of OpenLDAP 2.4.x to any version after 2.5. Our upgrade process was installing the binaries, removing our ppolicy schema and doing a slapcat of the old database and a slapadd to the new version. After doing so, response time shows a noticeable delay using an ldapsearch, the header on the response will pause long enough to read it before we get the result. This delay is causing the server to hang during heavy use and eventually crash. Through a lot of trouble shooting / trial and error, I have found that the cause is our dynlist definitions/usage. When they are removed, response time goes back to normal and there is a memory leak that stops. I can add the pertinent parts of the cn=config if needed. The question for now is has anyone else seen and hopefully resolved this issue or just know what changed for dynlist in 2.5 that might be effecting us?
Thanks,
Bradley Gill CISSP, CCSP
1 year, 3 months
