[RADIATOR] ldap with certificate authentocation
Alfred Reibenschuh
Alfred.Reibenschuh at kyndryl.com
Mon May 16 12:29:17 UTC 2022
hello
i have the following setup
<Handler Suffix = @realm, NAS-Identifier = sshd, NAS-Port-Type = Virtual, Service-Type = Authenticate-Only>
<AuthBy LDAP2>
Identifier PROXY_realm
Host realm.example.com
Port 636
BaseDN OU=realm,DC=example,DC=com
SearchFilter (cn=%1)
ServerChecksPassword
Version 3
</AuthBy>
</Handler>
now security requires a client certificate (which i have) to authenticate the ldap connection
how would i configure the certificate for authenticating the ldap connection ?
Yours sincerely
Alfred Reibenschuh
# Network System Management Platform Lead
# Network Device Backup & Restore Process Manager
Value Transformation Services GmbH
An IBM / KYNDRYL Company
Obere Donaustrasse 95
1020 Wien
Phone: +43-1-2056320-143
Mobile: +43-664-3523820
mail: Alfred.Reibenschuh at kyndryl.com<mailto:Alfred.Reibenschuh_v-tservices at at.ibm.com>
webex: https://kyndryl.webex.com/meet/alfred.reibenschuh
Please consider the environment before printing this e-mail.
This e-mail is confidential and may also contain privileged information. If you are not the intended recipient you are not authorized to read, print, save, process or disclose this message. If you have received this message by mistake, please inform the sender immediately and delete this e-mail, its attachments and any copies.
Any use, distribution, reproduction or disclosure by any person other than the intended recipient is strictly prohibited and the person responsible may incur penalties.
Thank you!
________________________________
From: radiator <radiator-bounces at lists.open.com.au> on behalf of radiator-request at lists.open.com.au <radiator-request at lists.open.com.au>
Sent: Thursday, April 7, 2022 2:00 PM
To: radiator at lists.open.com.au <radiator at lists.open.com.au>
Subject: [EXTERNAL] radiator Digest, Vol 155, Issue 4
Send radiator mailing list submissions to
radiator at lists.open.com.au
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.open.com.au/mailman/listinfo/radiator
or, via email, send a message with subject or body 'help' to
radiator-request at lists.open.com.au
You can reach the person managing the list at
radiator-owner at lists.open.com.au
When replying, please edit your Subject line so it is more specific
than "Re: Contents of radiator digest..."
Today's Topics:
1. Re: Memory Leak on RHEL 8.5 (Heikki Vatiainen)
2. Re: Memory Leak on RHEL 8.5 (Wolfgang Breyha)
3. Re: Memory Leak on RHEL 8.5 (Wolfgang Breyha)
----------------------------------------------------------------------
Message: 1
Date: Wed, 6 Apr 2022 19:27:59 +0300
From: Heikki Vatiainen <hvn at open.com.au>
To: radiator at lists.open.com.au
Subject: Re: [RADIATOR] Memory Leak on RHEL 8.5
Message-ID: <f2e72eb1-3d39-9ec3-e9a1-ed4b4d41c5d3 at open.com.au>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 6.4.2022 14.17, Wolfgang Breyha wrote:
> That proves that Rocky/Alma are indeed "100% bug-for-bug" compatible;-)
Indeed, and fortunately adds possibility there's a way to find the
reason. Unfortunately it seems not to be that easy. I used
openssl-1.1.1k-5.el8_5.src.rpm and tried to compile a local copy. After
applying the patches and compiling with parameters from openssl.spec, I
was able to create a version that works.
Problem is that it works too well. It does not leak. Compiler flags, see
openssl version -a, match the system version and everything looks equal
(except of built date, etc. changes that are expected).
It might be that it's not a problem caused by patches the source rpm
contains, but something else. The build I did was manual done by calling
./Configure ... after patching the OpenSSL source.
Stefan suggested raising a ticket at RedHat. Even if it may not be
patches, at least we know have more information.
> As a first step I tried to reduce my test config to yours. But this raised
> some questions...
>
>>> I then start eapol_test (from wpa_supplicant RPM) with a config of
>>> network={
>>> eap=PEAP
>>> eapol_flags=0
>>> key_mgmt=IEEE8021X
>>> identity="testuser"
>>> anonymous_identity="anonymous"
>>> password="testpass"
>>> ca_cert="/etc/pki/tls/cert.pem"
>>> phase2="auth=MSCHAPV2"
>>> }
>>> in a loop and can watch radiusd eating memory.
>>
>> I used exactly the same config with my testing. I even used eapol_test that
>> comes with 'yum install wpa_supplicant', but I don't think eapol_test
>> version matters.
>
> Did you really use this unmodified and if yes, was cert.pem the system file
> our the test CA? I was not able to successfully AUTH without the test CA here.
Good catch. I did update certificates in eapol_test conf file to use
test certificates that come with Radiator:
network={
eap=PEAP
eapol_flags=0
key_mgmt=IEEE8021X
identity="testuser"
anonymous_identity="anonymous"
password="testpass"
#ca_cert="/etc/pki/tls/cert.pem"
ca_cert="demoCA/cacert.pem"
phase2="auth=MSCHAPV2"
}
File key.pem in Radiator configuration, as you correclty noted, contains
the decrypted private key from cert-srv.pem. I decrypted it to avoid
extra OpenSSL API calls that would otherwise be needed to decrypt the
key from within Radiator. In other words, the configuration shouldn't
have anything special in it.
>> ??? EAPTLS_PrivateKeyFile %D/key.pem
>
> I assumed that this is a copy of the key in crt-serv.pem without
> passphrase. Otherwise radiusd complains about the key and can't do TLS
> handshakes at all.
Yes, that's exactly correct. Here's the OpenSSL related part of Radiator
configuration (%D expands to .):
<AuthBy FILE>
Identifier AuthTEST
Filename %D/users
EAPType PEAP,MSCHAP-V2
EAPTLS_CAFile %D/demoCA/cacert.pem
EAPTLS_CertificateFile %D/cert-srv.pem
EAPTLS_PrivateKeyFile %D/key.pem
EAPTLS_CertificateType PEM
EAPTLS_MaxFragmentSize 1000
EAPTLS_SessionResumption 0
AutoMPPEKeys
</AuthBy>
Radiator and eapol_test were both run from the same directory. I also
turned off session resumption so that there's no need to maintain
session cache and Radius related context information.
> With these changes I'm able to use eapol_test successfully and the leaks
> occur fast enough. And valgrind reports a lot of leaks in SSL_context.
Is that a new location or are the reports from the same two places as
earlier?
> I'm not that experienced using valgrind and did just what most "how-to"s
> suggest;-)
>
> I'm using the RHEL8 valgrind RPM and start radiusd with:
> # valgrind --log-file=/tmp/val.log --leak-check=yes perl /opt/radiator
> /radiator/radiusd -foreground -no_pid_file -config_file leak_test.cfg
>
> Then I call eapol_test in a bash for loop 1..1000. After stopping radiusd
> val.log contains several references to SSL_, X509, ASN1_.
Hmm, multiple different places. Thanks for the quick start guide. I'll
see if I can get something useful too.
Thanks,
heikki
--
Heikki Vatiainen
OSC, makers of Radiator
Visit radiatorsoftware.com for Radiator AAA server software
------------------------------
Message: 2
Date: Thu, 7 Apr 2022 01:15:40 +0200
From: Wolfgang Breyha <radiator at blafasel.at>
To: radiator at lists.open.com.au
Subject: Re: [RADIATOR] Memory Leak on RHEL 8.5
Message-ID: <8b7953af-4f2c-9a8b-ee54-510c0308a43a at breyha.at>
Content-Type: text/plain; charset=UTF-8
Hi!
A question left from your previous answer:
Which version does el9 beta use? I see they switched to OpenSSL 3 already
searching the net, right?
On 06/04/2022 18:27, Heikki Vatiainen wrote:
> Unfortunately it seems not to be that easy. I used
> openssl-1.1.1k-5.el8_5.src.rpm and tried to compile a local copy. After
> applying the patches and compiling with parameters from openssl.spec, I was
> able to create a version that works.
>
> Problem is that it works too well. It does not leak. Compiler flags, see
> openssl version -a, match the system version and everything looks equal
> (except of built date, etc. changes that are expected).
Really? That's interesting, because meanwhile I tried the following things:
*) rebuild 1.1.1k from el8 src RPM
*) rebuild the current openssl-1.1.1n-1.fc35.src.rpm for el8
*) remove several patches from the 1.1.1n spec in steps to the point of
nearly destroying the host ending up with broken ssh/dnf due to missing
krb5_evp symbols. Luckily wget still worked with https to fetch the
original RPMS;-)
But even then ... no change in memory leaks for radiusd.
*) tried to build the rpm with all patches but with the "unhobbled" full
openssl-1.1.1n tarball.
No difference as well. It leaks.
I also tried another tool for memleak detection called memleax ...
https://github.com/WuBingzheng/memleax
... which is able to attach to a running PID. This detects the same leak as
well:
CallStack[24]: may-leak=6 (1536 bytes)
expired=6 (1536 bytes), free_expired=0 (0 bytes)
alloc=33 (8448 bytes), free=0 (0 bytes)
freed memory live time: min=0 max=0 average=0
un-freed memory live time: max=11
0x00007fbbc4301a90 libc-2.28.so __malloc()+0
0x00007fbbc211b90d libcrypto.so CRYPTO_zalloc()+13
0x00007fbbc2107ac4 libcrypto.so EVP_PKEY_meth_new()+36
0x00007fbbc154ead8 pkcs11.so
0x00007fbbc20e98e5 libcrypto.so ENGINE_get_pkey_meth()+53
0x00007fbbc2107ea5 libcrypto.so
0x00007fbbc2103544 libcrypto.so
0x00007fbbc24d7a42 libssl.so
0x00007fbbc24ca33f libssl.so
0x00007fbbc24b5c98 libssl.so SSL_do_handshake()+88
0x00007fbbc2767e84 SSLeay.so
0x00007fbbc55144b9 libperl.so Perl_pp_entersub()+505
0x00007fbbc550c325 libperl.so Perl_runops_standard()+53
0x00007fbbc548bffd libperl.so perl_run()+797
0x0000562b6f5f7eda perl
0x00007fbbc429f493 libc-2.28.so __libc_start_main()+243
0x0000562b6f5f7f1e perl
Then I used my locally built openssl 1.1.1n RPMs I use on other el8 hosts.
These use a clean openssl source without RH patches, slightly different
Configure and builds to /usr/local/openssl. I then rebuilt the Net::SSLeay
1.92 RPM I already built before with OPENSSL_PREFIX to use my custom OpenSSL.
This way I can easily switch between original and custom OpenSSL by
downgrading/updating Net::SSLeay.
And with the custom OpenSSL RPMs it seems radiusd doesn't leak. At least
valgrind/memleax do not detect the SSL_do_handshake leak and radiusd memory
footprint gets stable after the first batch of requests floating at
~110-120MB. I put this setup on one of our production hosts now to see what
happens as soon as people start connecting their WLAN devices in the morning.
> It might be that it's not a problem caused by patches the source rpm
> contains, but something else. The build I did was manual done by calling
> ./Configure ... after patching the OpenSSL source.
Hmmm, I can't confirm this since all the RPMs I used in my tests are built
on Rocky 8.5 as well. The Fedora 35 SPEC doesn't differ in any important
aspect.
I rebuilt 1.1.1k with the RHEL8 spec. So, this should be the exact same
result as your local build except the rpmbuild environment (which sets a
lot of compiler/linker defaults which you compared).
But only the version without the RH hobble/fips/patches-stuff works which
uses the same rpmbuild env and the SPEC file I use is a modification of the
original one.
So my guess for now is that the issue is caused by the patches (but not the
hobbled part). Since wide parts of the patches depend on each other I see
no easy way to pin it to one of them.
Greetings, Wolfgang
------------------------------
Message: 3
Date: Thu, 7 Apr 2022 12:57:47 +0200
From: Wolfgang Breyha <radiator at blafasel.at>
To: radiator at lists.open.com.au
Subject: Re: [RADIATOR] Memory Leak on RHEL 8.5
Message-ID: <eb208f6b-9bf0-a1fa-617c-5a6a139d2749 at breyha.at>
Content-Type: text/plain; charset=UTF-8
On 07/04/2022 01:15, Wolfgang Breyha wrote:
> And with the custom OpenSSL RPMs it seems radiusd doesn't leak. At least
> valgrind/memleax do not detect the SSL_do_handshake leak and radiusd memory
> footprint gets stable after the first batch of requests floating at
> ~110-120MB. I put this setup on one of our production hosts now to see what
> happens as soon as people start connecting their WLAN devices in the morning.
Meanwhile I can confirm that my custom RPMs do not leak and radiusd memory
usage only depends on the load it has to handle.
So I filed:
https://bugzilla.redhat.com/show_bug.cgi?id=2072962
Greetings, Wolfgang
--
Wolfgang Breyha <wbreyha at gmx.net> | https://www.blafasel.at/
Vienna University Computer Center | Austria
------------------------------
Subject: Digest Footer
_______________________________________________
radiator mailing list
radiator at lists.open.com.au
https://lists.open.com.au/mailman/listinfo/radiator
------------------------------
End of radiator Digest, Vol 155, Issue 4
****************************************
Unless stated otherwise above:
Kyndryl Austria GmbH
Sitz: Wien
Firmenbuchgericht: Handelsgericht Wien, FN 554717 k
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20220516/fe8eb2aa/attachment-0001.html>
More information about the radiator
mailing list