Since this commit in openldap: https://git.openldap.org/openldap/openldap/-/commit/735e1ab14 the freeradius ldap module fails to load. there's an error about the ldap server being busy, which is fact comes from a mishandled case of rlm_ldap_result() returning LDAP_PROC_RETRY that is handled as an error. The error message returned to the user (radiusd -X) is the same than this one: https://serverfault.com/questions/1058366/freeradius-cannot-bind-to-freeipa The problem appeared with the introduction of openldap-2.4.50 in fedora 33.
Hi, I can't reproduce this issue. The LDAP module seems to be loading and working fine on my side. I'm using: Fedora 33 freeradius 3.0.21-8.fc33 openldap 2.4.50-5.fc33 openssl 1:1.1.1l-2.fc33 Could you give more info on how you are reproducing this?
OK, I could reproduce this problem on Fedora 34 too. Here is an howto triggger it: - setup openldap server, and configure it with certificates enabled: *in /etc/openldap/slapd.d/cn=config.ldif: olcTLSCertificateFile: /etc/letsencrypt/live/xxx-0001/cert.pem olcTLSCertificateKeyFile: /etc/letsencrypt/live/xxx-0001/privkey.pem olcTLSCACertificateFile: /etc/letsencrypt/live/xxx-0001/chain.pem *set a password to the manager user in /etc/openldap/slapd.d/cn=config/olcDatabase={2}mdb.ldif, with slappasswd: olcRootPW: {SSHA}xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx - setup freeradius, with some modules enabled, including ldap: [root@vm2 etc]# ls -l /etc/raddb/mods-enabled/ total 0 lrwxrwxrwx 1 root radiusd 24 Jun 25 14:22 always -> ../mods-available/always lrwxrwxrwx 1 root radiusd 29 Jun 25 14:22 attr_filter -> ../mods-available/attr_filter lrwxrwxrwx 1 root radiusd 22 Jun 25 14:22 chap -> ../mods-available/chap lrwxrwxrwx 1 root radiusd 24 Jun 25 14:22 detail -> ../mods-available/detail lrwxrwxrwx 1 root radiusd 24 Jun 25 14:22 digest -> ../mods-available/digest lrwxrwxrwx 1 root radiusd 21 Jun 25 14:22 eap -> ../mods-available/eap lrwxrwxrwx 1 root radiusd 22 Jun 25 14:22 exec -> ../mods-available/exec lrwxrwxrwx 1 root radiusd 28 Jun 25 14:22 expiration -> ../mods-available/expiration lrwxrwxrwx 1 root radiusd 22 Jun 25 14:22 expr -> ../mods-available/expr lrwxrwxrwx 1 root radiusd 23 Jun 25 14:22 files -> ../mods-available/files lrwxrwxrwx 1 root radiusd 22 Jan 26 2014 ldap -> ../mods-available/ldap lrwxrwxrwx 1 root radiusd 27 Jun 25 14:22 logintime -> ../mods-available/logintime lrwxrwxrwx 1 root radiusd 24 Jun 25 14:22 mschap -> ../mods-available/mschap lrwxrwxrwx 1 root radiusd 21 Jun 25 14:22 pap -> ../mods-available/pap lrwxrwxrwx 1 root radiusd 28 Jun 25 14:22 preprocess -> ../mods-available/preprocess lrwxrwxrwx 1 root radiusd 25 Jun 25 14:22 radutmp -> ../mods-available/radutmp lrwxrwxrwx 1 root radiusd 23 Jun 25 14:22 realm -> ../mods-available/realm lrwxrwxrwx 1 root radiusd 22 Jun 25 14:22 unix -> ../mods-available/unix [root@vm2 mods-enabled]# ls -l /etc/raddb/sites-enabled/ total 0 lrwxrwxrwx 1 root root 26 Oct 5 21:54 default -> ../sites-available/default lrwxrwxrwx 1 root root 31 Oct 5 21:54 inner-tunnel -> ../sites-available/inner-tunnel - setup certificates for tls in /etc/raddb/cert/ : [root@vm2 certs]# make -C /etc/raddb/cert/ [root@vm2 certs]# chgrp radiusd server.pem server.key ca.pem dh - setup the ldap module : identity = 'cn=Manager,dc=my-domain,dc=com' password = the-password-previously-defined-in-openldap base_dn = 'cn=Manager,dc=my-domain,dc=com' start_tls = yes - start radiusd: [root@vm2 mods-enabled]# /usr/sbin/radiusd -d /etc/raddb/ -t -X [...] rlm_ldap (ldap): Bind with cn=Manager,dc=my-domain,dc=com to ldap://localhost:389 failed: Server is busy rlm_ldap (ldap): Opening connection failed (1) With the same openldap with reverted commit "ITS#8650 loop on incomplete TLS handshake", it works: [...] rlm_ldap (ldap): Opening additional connection (4), 1 of 28 pending slots used rlm_ldap (ldap): Connecting to ldap://localhost:389 TLS: unable to get peer certificate. rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind successful [...] You can get my openldap rpm packages with the reverted commit there: http://rpmfind.net/linux/local/fedora/34/x86_64/os/Packages/ and the source rpm: http://rpmfind.net/linux/local/fedora/34/source/SRPMS/ (I made versions for fedora 33 too).
FEDORA-2021-7a3f45cad8 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-7a3f45cad8
FEDORA-2021-7a3f45cad8 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-7a3f45cad8` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-7a3f45cad8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I still have the problem on my server, with openldap-2.4.50-5.fc33 and freeradius-3.0.21-10.fc33.x86_64: rlm_ldap (ldap): Opening additional connection (0), 1 of 32 pending slots used rlm_ldap (ldap): Connecting to ldap://ldap.example.com:389 rlm_ldap (ldap): Waiting for bind result... rlm_ldap (ldap): Bind with cn=manager,dc=example,dc=com to ldap://ldap.example.com:389 failed: Server is busy rlm_ldap (ldap): Opening connection failed (0) rlm_ldap (ldap): Removing connection pool /etc/raddb/mods-enabled/ldap[8]: Instantiation failed for module "ldap" There's still a single connection attempt: # grep connect /tmp/strace.txt | grep 389 99324 connect(3, {sa_family=AF_INET, sin_port=htons(389), sin_addr=inet_addr("x.x.x.x")}, 16) = -1 EINPROGRESS (Operation now in progress) # I'll give more feedback later.
This is the commit that should fix the issue: https://github.com/FreeRADIUS/freeradius-server/commit/21d95b268b4cf56e75064898d83123825d673818 Note that for it to work, you need to set the 'start' field in the 'pool' section of LDAP module config to 0.
FEDORA-2021-7a3f45cad8 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
I set the 'start' field to 0, but it delays the error until the first radius client tries to connect. What I observe with this commit is that the test "if (num)" that should retry to connect is false, here: https://github.com/FreeRADIUS/freeradius-server/blob/21d95b268b4cf56e75064898d83123825d673818/src/modules/rlm_ldap/ldap.c#L762 In my case, retry=true, and inst->pool->num=0 (aka num = fr_connection_pool_get_num(inst->pool), line 721)
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Bug is present in Fedora 34+. Moving BZ to F34.
FEDORA-2022-e8f860f487 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2022-e8f860f487
FEDORA-2022-e8f860f487 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-e8f860f487` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-e8f860f487 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-e8f860f487 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.