...

rlm_ldap (ldap): Connecting to ldaps://dc1.testuni.it:636 rlm_ldap (ldap): Bind with CN=reader-freeradius,OU=ServiceUsers,OU=ServicePeople,DC=testuni,DC=it to ldaps://dc1.testuni.it:636 failed: Can't contact LDAP server

This error is "can't contact", not "LDAP server rejected the authentication".

Something is blocking the network connection between FreeRADIUS and the LDAP server. Find out what that is, and fix it.

The LDAP server receives TCP and TLS1.2 exchange packets with the freeradius server. The last packet label, from the LDAP server is : ..."636 → 44698 [RST, ACK] Seq=2280 Ack=726 Win=0 Len=0" I can't see a network or firewall problem.

...

I tried to bind, manually, using the general command: ldapsearch -D ${identity} -w ${password} -H ${server} -b 'CN=user,${base_dn}' and it worked.

Does it use the same port?

ldapsearch uses the 636 port, rlm_ldap reports using the 636 port They both exchange packets with the LDAP server on that port.

...

In mods-available/ldap, at line 77, I read the suggestion: ldapsearch -D ${identity} -w ${password} -h ${server} -b 'CN=user,${base_dn}' ...

Ask the people who wrote ldapsearch.

Checked: "-h" does not exist in ldapsearch 2.5.13 Weeks ago, other tests with an older ldapsearch (and older debian), using "-h" and port 389, were not relevant, because our LDAP server rejects non-secure LDAP connections. Could this be the issue? Does rlm_ldap need port 389 to accept/reply I-dont-know-what before using 636? https://wiki.freeradius.org/modules/rlm_ldap#errors-with-ldap-over-tls-conne... suggests to check for: "... probably using a version of libldap that has been built with NSS ..." I'm not using Red Hat, should I check as well? (using Debian11.5, $OpenLDAP: ldapsearch 2.5.13+dfsg-5) Pietro

Il 13/09/2023 13:45 CEST Alan DeKok <aland@deployingradius.com> ha scritto: The rlm_ldap module talks to the LDAP server via libldap. i.e. FreeRADIUS asks libldap to contact, the LDAP server, and libldap says "no".

Thanks Alan, your explaination led me to: "... ldapsearch is linked to GnuTLS and not OpenSSL..." (reference: https://kb.checkmk.com/pages/viewpage.action?pageId=17471579)

One thing which might help is to read mods-available/ldap, and look at the "ldap_debug" flag. Thanks, good clue! The full libldap debug revealed some unexpected errors and this one led me to the solution (or at least to a workaround): ...TLS: peer cert untrusted or revoked (0x42)

What I'm guessing is: 1- ldapsearch uses the debian certificates store, then it finds our internal CA root Certificate there, and it can trust the LDAP Server Certificate 2- libldap does not use the system certificates Store by default (does freeradius let set/send any parameter to overcome this behaviour?). The workaround I applied: expliciting, in mods-enabled/ldap, tls section: ca_file = /usr/share/ca-certificates/mozilla/ADCArootCert.crt My question: Given that the tls section states: "# The StartTLS operation is supposed to be used with normal ldap connections instead of using ldaps (port 636) connections", BUT I'm using LDAPS, should I fear random, unforeseeable behaviour from freeradius? Hm... rethinking it, if the "behaviour" comes from libldap it's possible that you are not able to know it for sure.

...

Checked: "-h" does not exist in ldapsearch 2.5.13

Well, we didn't write ldapsearch, and they don't notify us when their tools change. Of course, please just take my note as a suggestion to improve the documentation.

Thanks again, Pietro.

Hello to you, my freeradius 3.2.1 is already auth/authorizing through Active Directory and I'm trying to add a second auth/autz source (google) to the configuration. I'm using the google-related freeradius templates. I'm following the google documentation: https://support.google.com/a/answer/9089736?hl=en&ref_topic=9173976&sjid#zip... but I'm finding something that don't match with the rlm_pap official documentation. Actually, I'm not able to authenticate. In particular, the google documentation reports: /etc/freeradius/3.0/sites-available/default -> authorize ... if (User-Password) { update control { Auth-Type := ldap } } ... BUT in an older post I read that you have to set Cleartext-Password (see: https://freeradius-users.freeradius.narkive.com/jbibA0Uf/pap-warning-authent...). Moreover, in the rlm_pap docs, I don't see User-Password as an Attribute. Should I avoid the google how-to? I chose it because it seemed a clear step-by-step procedure to follow, but if it contains mistakes I'll abandon it. Does anyone know another tutorial for such a configuration? I'd also need to understand what should I add in the "inner" config. Thanks again for your support, Pietro.

On Nov 23, 2023, at 6:49 AM, Pietro N. via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:

Hello to you, my freeradius 3.2.1 is already auth/authorizing through Active Directory and I'm trying to add a second auth/autz source (google) to the configuration.

I'm using the google-related freeradius templates. I'm following the google documentation: https://support.google.com/a/answer/9089736?hl=en&ref_topic=9173976&sjid#zip...

That documentation is garbage. Ignore it. I've submitted requests for them to fix it. But they're Google, and they know better than the FreeRADIUS developers.

but I'm finding something that don't match with the rlm_pap official documentation. Actually, I'm not able to authenticate.

That's a good hint that the documentation is wrong.

In particular, the google documentation reports: /etc/freeradius/3.0/sites-available/default -> authorize ... if (User-Password) { update control { Auth-Type := ldap } }

That sets Auth-Type for the *outer* session. i.e. TTLS. You need to set it for the *inner* session. i.e. in the inner-tunnel virtual server.

BUT in an older post I read that you have to set Cleartext-Password (see: https://freeradius-users.freeradius.narkive.com/jbibA0Uf/pap-warning-authent...).

There is no magic "set this and it works". The better approach is to understand how the pieces interact. Cleartext-Password is the *correct* password for the user. If the server is given Cleartext-Password by some configuration (LDAP, SQL, or "update" section), then the PAP module can compare User-Password to Cleartext-Password, and authenticate the user. Or the MS-CHAP module can take Cleartext-Password, do the MS-CHAP calculations, and compare that to the MS-CHAP data sent by the user.

Moreover, in the rlm_pap docs, I don't see User-Password as an Attribute.

The PAP module checks the User-Password against Cleartext-Password, or Crypt-Password, or

Should I avoid the google how-to? I chose it because it seemed a clear step-by-step procedure to follow, but if it contains mistakes I'll abandon it.

It's wrong. It might work sometimes, but it completely miu

Does anyone know another tutorial for such a configuration? I'd also need to understand what should I add in the "inner" config.

It depends on what you want to do... TTLS+PAP to Google LDAP? Configure the LDAP module to point to google. Make the inner-tunnel use LDAP for authentication. Alan DeKok.

On 12/10/2023 10:35, Pietro N. via Freeradius-Users wrote:

Our freeradius 3.2.1 for Eduroam (Radius2) receives requests from users in Active Directory (for example, SSID=staff-AD). We already have a primary Radius server (Radius1, different system) which usually handles the students' and staff requests (for example: SSID=students), which credentials are stored into the internal database.

OK... I think. So radius2 receives requests when a user connects to the "staff-AD" SSID, and radius1 receives requests when connecting to the "students" SSID?

How can I forward the requests arriving to freeradius from students (who tried to use SSID=staff-AD, being rejected by AD), forwarding them to Radius1? How can I forward the requests arriving to freeradius from SSID=students, forwarding them to Radius1?

You need to do a few things - configure radius1 as a client on radius2, and vice-versa - configure proxy.conf on radius1 to add an entry for radius2, and vice-versa - work out when a request should be proxied and set Proxy-To-Realm, either with unlang or by calling the realm module.

When I think "forward" I guess use "proxy.conf" but when I think about authorization (rejected by AD) I guess I should act elsewhere (default?).

You don't proxy after you have a failed authentication. You need to work out if proxying is required beforehand. Many sites will have different username (or realm) formats which can be used. Alternatively you can look the user up in a database (such as LDAP if you are using AD). Simple example for radius1, add a clients.conf entry: client radius2 { ipaddr = 10.0.0.2 secret = longsecretfromradius2 } and a proxy.conf entry realm radius2 { authhost = 10.0.0.2:1812 secret = longsecretfromradius1 } then in sites-available/default add something to the authorize{} section to proxy if needed split_username_nai if (&Stripped-User-Domain && &Stripped-User-Domain == "students.example.it") { update control { &Proxy-To-Realm := "radius1" } } Add similar, but opposite, to radius2. Be careful to get the logic correct so you don't create loops. That example looks at the realm, but you can use any tests to determine whether to set Proxy-To-Realm or not. -- Matthew