Hi Alan, Apologies for creating confusion. Perhaps it is more of the architectural issue - we have a use case involving a FreeRADIUS deployment acting as a proxy for CHAP-based authentication and enriching the answer based on LDAP content. Use Case is: - NAS (Juniper, Fortigate, Cisco, or other devices for the device login) send a CHAP-based Access-Request to our local FreeRADIUS servers (2x) that handle local customer domain. Usernames are always the same and simple (john.doe or jdoe, not containing domains @google.com). - The proxy then should run the request to a remote central RADIUS server - Once an Access-Accept is received from the backend RADIUS server, we want the proxy to: * Perform an LDAP group lookup using the authenticated username - this is run with the LDAP search on AD. * If the user is part of a specific group, inject vendor group-related VSAs into the Access-Accept response before it’s sent back to the NAS. Key Considerations: * Central Radius servers (2x) has multiple customer domains to serve (all domains supply the same user names) and moving LDAP lookup onto it, will not work, because the reply to NAS will be domain-specific. They are running NTLM-based back-end authentication via AD * Group-based enrichment should occur after the backends' Access-Accept is received — in the post-proxy or post-auth section of the FreeRADIUS configuration, with querying for the certain group memberships in AD and then running through the case-by-case if with either adding attributes, or rejecting the user altogether with "Access denied: Unauthorized group.". I was trying to run abovementioned case via post-auth chain with specifying ldap server in mods-enabled. From what I see the initial request is being broken down and not wrapped as in EAP, so packet modification by adding VSA's are possible. etc/3.0/sites-available/default server default { listen { type = auth ipaddr = * port = 1825 limit { max_connections = 16 lifetime = 0 idle_timeout = 30 } } listen { ipaddr = * port = 1826 type = acct limit { } } authorize { preprocess auth_log pap update control { Proxy-to-Realm := "radius_server" } } authenticate { Auth-Type Proxy { } } post-auth { ldap ms_ad } } The ldap configuration is: etc/3.0/mods-enabled/ldap: ldap ms_ad { server = 'ad-server-cluster' identity = 'CN=labs,OU=Service Accounts,DC=boo,DC=nl' password = '123456789' base_dn = 'DC=boo,DC=nl' user { base_dn = "${..base_dn}" filter = "(sAMAccountName=%{%{Stripped-User-Name}:-%{User-Name}})" } group { base_dn = "${..base_dn}" filter = '(objectClass=group)' membership_attribute = 'member' } options { chase_referrals = yes rebind = yes ldap_debug = 0 timeout = 10 timelimit = 3 net_timeout = 1 idle = 60 } tls { start_tls = no } } The full post_auth was before: post-auth { ldap ms_ad if (LDAP-Group == "Radius_Admin_Group") { update reply { Juniper-Local-User-Name := "admin_role" Fortinet-Group-Name := "admin_group" # F5-LTM-User-Partition := "admin_group" } } elsif (LDAP-Group == "Radius_ReadOnly_Group") { update reply { Juniper-Local-User-Name := "read_only_role" Fortinet-Group-Name := "read_only_group" # F5-LTM-User-Partition := "read_only_group" } } elsif (LDAP-Group == "Radius_ReadWrite_Group") { update reply { Juniper-Local-User-Name := "read_write_role" Fortinet-Group-Name := "read_write_group" # F5-LTM-User-Partition := "read_write_group" } } else {       update control { Auth-Type := Reject } update reply { Reply-Message := "Access denied: Unauthorized group." } } } If in the post-auth section only ldap is specificed without ms_ad addition: * Request received and relayed to the central okay. User authentication to the central returns "Allowed" * LDAP lookup fails to execute - it just doesn't run while the sessions to the LDAP server are there (verified with the wireshark). It looks like this: root@6786e1082898:/etc/freeradius/3.0# radtest -4 generic-ms-user ************* localhost:1825 1 testing123 Sent Access-Request Id 62 from 0.0.0.0:39502 to 127.0.0.1:1825 length 101       User-Name = "generic-ms-user"       User-Password = "*************"       NAS-IP-Address = 172.17.0.6       NAS-Port = 1       Cleartext-Password = "*************" (5) Received Access-Request Id 62 from 127.0.0.1:39502 to 127.0.0.1:1825 length 101 (5) Message-Authenticator = 0xbeb95be16a0c6f207c8edc71f16955c6 (5) User-Name = "generic-ms-user" (5) User-Password = "qZakbJ8eCSRUD04bRHvyY" (5) NAS-IP-Address = 172.17.0.6 (5) NAS-Port = 1 (5) # Executing section authorize from file /etc/freeradius/3.0/sites-enabled/default (5) authorize { (5) [preprocess] = ok (5) auth_log: EXPAND /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d (5) auth_log: --> /var/log/freeradius/radacct/127.0.0.1/auth-detail-20250321 (5) auth_log: /var/log/freeradius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/auth-detail-%Y%m%d expands to /var/log/freeradius/radacct/127.0.0.1/auth-detail-20250321 (5) auth_log: EXPAND %t (5) auth_log: --> Fri Mar 21 13:59:34 2025 (5) [auth_log] = ok (5) pap: WARNING: No "known good" password found for the user. Not setting Auth-Type (5) pap: WARNING: Authentication will fail unless a "known good" password is available (5) [pap] = noop (5) update control { (5) Proxy-to-Realm := "radius_server" (5) } # update control = noop (5) } # authorize = ok (5) Starting proxy to home server 100.127.1.24 port 1823 (5) server default { (5) } (5) Proxying request to home server 100.127.1.24 port 1823 timeout 10.000000 (5) Sent Access-Request Id 61 from 0.0.0.0:46496 to 100.127.1.24:1823 length 111 (5) Message-Authenticator = 0xbeb95be16a0c6f207c8edc71f16955c6 (5) User-Name = "generic-ms-user" (5) User-Password = "*************" (5) NAS-IP-Address = 172.17.0.6 (5) NAS-Port = 1 (5) Event-Timestamp = "Mar 21 2025 13:59:34 UTC" (5) Proxy-State = 0x3632 Waking up in 0.3 seconds. Received Access-Accept Id 62 from 127.0.0.1:1825 to 127.0.0.1:39502 length 74       Message-Authenticator = 0x8670c5f2e90ac0dd8f69a64a5cb48b9d       Reply-Message = "Access denied: Unauthorized group." root@6786e1082898:/etc/freeradius/3.0# (5) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! (5) BlastRADIUS check: Received packet without Message-Authenticator from home_server radius_server1 (5) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! (5) The packet does not contain Message-Authenticator, which is a security issue (5) UPGRADE THE HOME SERVER AS YOUR NETWORK IS VULNERABLE TO THE BLASTRADIUS ATTACK. (5) Once the home server is upgraded, set "require_message_authenticator = true" for home_server radius_server1 (5) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! (5) Clearing existing &reply: attributes (5) Received Access-Accept Id 61 from 100.127.1.24:1823 to 172.17.0.6:46496 length 24 (5) Proxy-State = 0x3632 (5) server default { (5) } (5) Found Auth-Type = Accept (5) Auth-Type = Accept, accepting the user (5) # Executing section post-auth from file /etc/freeradius/3.0/sites-enabled/default (5) post-auth { (5) [ldap] = noop (5) if (&control:LDAP-Group == "Radius_Admin_Group") { (5) ERROR: Failed retrieving values required to evaluate condition (5) elsif (&control:LDAP-Group == "Radius_ReadOnly_Group") { (5) ERROR: Failed retrieving values required to evaluate condition (5) elsif (&control:LDAP-Group == "Radius_ReadWrite_Group") { (5) ERROR: Failed retrieving values required to evaluate condition (5) else { (5) update control { (5) Auth-Type := Reject (5) } # update control = noop (5) update reply { (5) Reply-Message := "Access denied: Unauthorized group." (5) } # update reply = noop (5) } # else = noop (5) } # post-auth = noop (5) Login OK: [generic-ms-user] (from client localhost port 1) (5) Sent Access-Accept Id 62 from 127.0.0.1:1825 to 127.0.0.1:39502 length 0 (5) Reply-Message := "Access denied: Unauthorized group." (5) Finished request Waking up in 4.9 seconds. If in the post-auth section has ldap ms_ad as before, the startup fails altogether with: "/etc/freeradius/3.0/sites-enabled/default[36]: Expecting section start brace '{' after "ldap ms_ad" error. Thank you in advance! Sincerely Matvey Teplov ________________________________________ From: Alan DeKok <aland@deployingradius.com> Sent: 17 March 2025 11:08 To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Cc: Matvey Teplov <matvey.teplov@nomios.nl> Subject: Re: FreeRadius ldap queries are not executed On Mar 17, 2025, at 4:44 PM, Matvey Teplov via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:

After excessive troubleshooting, I am coming to the following error: "/etc/freeradius/3.0/sites-enabled/default[43]: Expecting section start brace '{' after "ldap ms_ad" is coming up while debugging with freeradius -X. FreeRADIUS fails to parse the configuration file during startup, expecting the server definition in the post_auth, while it should use the ms_ad to refer to the module definition.

Did anyone experience this behaviour before?

Can you post the actual text that you've added to the configuration? I'm not sure I understand this issue. Either there's an error parsing the configuration files, which means the server can't run. OR there isn't an error parsing the server files, which means the server runs and produces debug output. Which is it? As for the debug output you posted, you only posted a tiny piece of it. Please post ALL of it, as suggested in ALL of the documentation. The server doesn't delete the control attributes. So if the LDAP-Group control attributes don't exist after proxying, then they didn't exist before proxying. The debug output you posted doesn't contain any information about what happened before the request was proxied. So it's impossible to tell why the LDAP-Group attributes are missing. Maybe they were never created... Alan DeKok.