FortiAuthenticator - Wireless dot1x with remote ldap - CoA not working

[j0ma]

Hello,

I am trying to setup a FortiAuthenticator policy for Wireless dot1x. The authentication works but RADIUS attributes (vlan and ACL) is not pushed to client.

Here is what I have tested;

Added the Remote LDAP
Created a User Group which retrieves user via LDAP Filter (not via imported users).
Created a Realm for LDAP Users
Created a Policy that:
WLC as RADIUS Client
Authentication Type Password/OTP (PEAP and EAP-MSCHAPv2)
Identity Source - username@realm - Points to LDAP Realm, uses Windows AD Domain Auth and filters on the group
Authentication Factors - Password Only and Windows AD computer authentication

I have tested with User Group pointed to imported users and remote user sync rule but that does not work either.

Does anyone have any idea? I checked the debug logs but cannot find anything interested. Also we have
tested this with a local group (MAB) and it works fine.

[ebilcari]

You can refer to this article: Technical Tip: How to check and verify a RADIUS attribute that is configured in a remote group setti...

I would also suggest to start with minimum attributes, NAS devices tend to ignore all the attributes when they don't understand at least one on the list.

[j0ma]

Thanks for your response, since I tested this with MAB and local user I assume the NAS already understands the attributes. In this case I am using;

Tunnel-Type - VLAN

Tunnel-Medium-Type - IEEE-802
Tunnel-Private-Group-ID - <vlan id>

That link did not help very much though since I already did both setups and ran the debugs without seeing any attributes being sent.

[ebilcari]

I did a quick search internally and found a similar case, the group filter need to be enabled under 'Identity sources' in the RADIUS policy in order for the attributes to be sent. Can you check if this is similar to your case?

[j0ma]

Yes I have created a group filter, it looks like this

And I have two groups for test;

One which retrieves clients based on ldap filter the other one on imported users, none of them works

[ebilcari]

Ok, that part seems fine. You can also check if the user is matching the correct policy, you can try to move it on top or check the debug logs for more details.
Can you also specify which firmware version is FortiAuthenticator currently running?

[ocara]

Hello,

Could you please try moving your radius policy with "wireless_dot1x_test_grp" to the top of the policy list? I’d like to ensure that it’s not being overridden by another policy associated with the same Radius client

[j0ma]

The policy is on top of policy list! We are running version: v6.6.2, build1669 (GA).

I have checked the debug and the client hits the correct policy, here is some output from a couple of days ago;

2025-05-27T15:13:12.216785+02:00 FortiAuthenticator radiusd[13843]: (89) facauth: Found authpolicy 'Wireless_dot1x_test_policy' for client '192.168.1.10'
2025-05-27T15:13:12.216802+02:00 FortiAuthenticator radiusd[13843]: (89) facauth: Client type: external (subtype: radius)
2025-05-27T15:13:12.216805+02:00 FortiAuthenticator radiusd[13843]: (89) facauth: Input raw_username: user1 Realm: (null) username: user1
2025-05-27T15:13:12.216808+02:00 FortiAuthenticator radiusd[13843]: (89) facauth: Searching default realm as well
2025-05-27T15:13:12.216812+02:00 FortiAuthenticator radiusd[13843]: (89) facauth: Realm not specified, default goes to Windows AD, id: 1
2025-05-27T15:13:12.216818+02:00 FortiAuthenticator radiusd[13843]: (89) facauth: Loaded remote ldap (regular bind) activedir.se:389
2025-05-27T15:13:12.217053+02:00 FortiAuthenticator radiusd[13843]: (89) facauth: skip ldap user search
2025-05-27T15:13:12.217058+02:00 FortiAuthenticator radiusd[13843]: (89) facauth: User [enable fido: false, token count: 0, revoked_token_count: 0]
2025-05-27T15:13:12.217103+02:00 FortiAuthenticator radiusd[13843]: (89) facauth: Policy [fido_auth_opt: disabled, twofactor: password only, no_fido: two factor, revoked: reject]
2025-05-27T15:13:12.217107+02:00 FortiAuthenticator radiusd[13843]: (89) facauth: Decided on [is_fido: false, two_factor: password only, token_type: none]
2025-05-27T15:13:12.217325+02:00 FortiAuthenticator radiusd[13843]: (89) facauth: machine auth override: authpolicy_id 8 auth_result 0
2025-05-27T15:13:12.217506+02:00 FortiAuthenticator radiusd[13843]: (89) facauth: EAP authentication success - add configured radius attributes to response
2025-05-27T15:13:12.217657+02:00 FortiAuthenticator radiusd[13843]: (89) facauth: Updated auth log 'user1' for attempt from 192.168.1.10: 802.1x authentication successful
2025-05-27T15:13:12.217671+02:00 FortiAuthenticator radiusd[13843]: (89) facauth: User-Name: user1 (from request)
2025-05-27T15:13:12.217675+02:00 FortiAuthenticator radiusd[13843]: (89) [facauth] = ok
2025-05-27T15:13:12.217678+02:00 FortiAuthenticator radiusd[13843]: (89) } # if (Eap-Type) = ok
2025-05-27T15:13:12.217682+02:00 FortiAuthenticator radiusd[13843]: (89) [exec] = noop
2025-05-27T15:13:12.217685+02:00 FortiAuthenticator radiusd[13843]: (89) policy remove_reply_message_if_eap {
2025-05-27T15:13:12.217688+02:00 FortiAuthenticator radiusd[13843]: (89) if (&reply:EAP-Message && &reply:Reply-Message) {
2025-05-27T15:13:12.217693+02:00 FortiAuthenticator radiusd[13843]: (89) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE
2025-05-27T15:13:12.217695+02:00 FortiAuthenticator radiusd[13843]: (89) else {
2025-05-27T15:13:12.218041+02:00 FortiAuthenticator radiusd[13843]: (89) [noop] = noop
2025-05-27T15:13:12.218053+02:00 FortiAuthenticator radiusd[13843]: (89) } # else = noop
2025-05-27T15:13:12.218056+02:00 FortiAuthenticator radiusd[13843]: (89) } # policy remove_reply_message_if_eap = noop
2025-05-27T15:13:12.218059+02:00 FortiAuthenticator radiusd[13843]: (89) if (EAP-Key-Name && &reply:EAP-Session-Id) {
2025-05-27T15:13:12.218063+02:00 FortiAuthenticator radiusd[13843]: (89) if (EAP-Key-Name && &reply:EAP-Session-Id) -> FALSE
2025-05-27T15:13:12.218065+02:00 FortiAuthenticator radiusd[13843]: (89) } # post-auth = ok
2025-05-27T15:13:12.218100+02:00 FortiAuthenticator radiusd[13843]: (89) Sent Access-Accept Id 60 from <fac-ip>:1812 to 192.168.1.10:35637 length 172
2025-05-27T15:13:12.218103+02:00 FortiAuthenticator radiusd[13843]: (89) MS-MPPE-Recv-Key = <<< secret >>>
2025-05-27T15:13:12.218106+02:00 FortiAuthenticator radiusd[13843]: (89) MS-MPPE-Send-Key = <<< secret >>>
2025-05-27T15:13:12.218109+02:00 FortiAuthenticator radiusd[13843]: (89) EAP-Message = 0x03090004
2025-05-27T15:13:12.218111+02:00 FortiAuthenticator radiusd[13843]: (89) Message-Authenticator = 0x00000000000000000000000000000000
2025-05-27T15:13:12.218180+02:00 FortiAuthenticator radiusd[13843]: (89) Framed-MTU += 994
2025-05-27T15:13:12.218184+02:00 FortiAuthenticator radiusd[13843]: (89) User-Name = "user1"
2025-05-27T15:13:12.218216+02:00 FortiAuthenticator radiusd[13843]: (89) Finished request

[j0ma · Accepted solution]

I may have solved it, I will test later today and get back to you.

I had not checked "Return User Group Attributes" in the RADIUS Response tab in the Policy.

  

EDIT; 

This solved my issue. The attributes are now being sent to client.

Thanks for all your help.