Security

Hi everyone,

We would like to test an integration between a VPN gateway (Vendor1), ClearPass, and FortiGate firewalls.

The expected process is as follows:

1. User1 is authenticated and authorized on the VPN gateway and is assigned the role VPN-MARKETING (authentication is based on LDAP). There is no interaction or communication with ClearPass at this stage.
2. The VPN gateway sends an accounting request (RADIUS Accounting, UDP/1813) to ClearPass to indicate that User1 has been authenticated and assigned the role VPN-MARKETING with the IP Address: 10.10.10.10.
3. ClearPass correctly receives this information, which are also displayed in the Live Monitoring > Accounting tab.
4. ClearPass connector has been configured on the FMG and I can see on the FMG the different configured roles.
5. I created an authorization service to perform role mapping based on the accounting information. ClearPass should map the role VPN-MARKETING to CP-MARKETING (a role already created in ClearPass) and send this information to FortiManager through the Context Server integration (Fortinet Documentation).
6.  FortiManager should receive the information from the Context Server (login and logout notifications) with the following attributes: User1, 10.10.10.10, and CP-MARKETING. FortiManager should then forward this information to the FortiGate firewalls so that it can be used within firewall policies.

Service Type: RADIUS Authorization

Roles: Based on some criteria a role mapping should be done so the result should be: CP-MARKETING

Enfocement: Enforcement Policy based on an Enfocrement profile with the FMG context server configuration.

Steps 1, 2,3 and 4 are working correctly, but steps 5 and 6 are not.

I would like to know whether this design is supported and whether anyone has successfully deployed a similar solution.

Best regards,

As drawn, step 5 can't fire. ClearPass only runs service classification, role mapping and enforcement on an Access-Request. An Accounting-Request is stored and matched to an existing session, so it shows in Live Monitoring but never hits your service in Access Tracker. RADIUS Authorization is still an authorize-only Access-Request type, not an accounting trigger, so the Session Notification profile behind the FortiManager context server never runs.

Cleanest fix: point the VPN gateway's RADIUS authentication at ClearPass with your LDAP as the authentication source. Now the service does the role mapping, the enforcement profile fires, and the accounting you already have supplies the Framed-IP-Address the login notification needs.

If ClearPass can't sit in the auth path, send the accounting straight to the FortiGate. Its RSSO agent builds users from Accounting Start using User-Name, Framed-IP-Address and a group attribute (Class by default, changeable with sso-attribute), and VPN-MARKETING maps to an RSSO group in policy. ClearPass drops out of that design.

If Access Tracker does show a hit on that service, say so and I'll rethink.

------------------------------
Dustin Burns
@Worldcom Exchange, Inc.
www.wei.com

- - -
The comments I post here are my own, and not my employers
If my post was useful accept solution and/or give kudos
Personal Blog: www.networkfieldnotes.com
- - -
------------------------------

Original Message:
Sent: Sep 21, 2026 04:18 PM
From: DB86
Subject: Aruba ClearPass role mapping based on the Accounting events

As drawn, step 5 can't fire. ClearPass only runs service classification, role mapping and enforcement on an Access-Request. An Accounting-Request is stored and matched to an existing session, so it shows in Live Monitoring but never hits your service in Access Tracker. RADIUS Authorization is still an authorize-only Access-Request type, not an accounting trigger, so the Session Notification profile behind the FortiManager context server never runs.

Cleanest fix: point the VPN gateway's RADIUS authentication at ClearPass with your LDAP as the authentication source. Now the service does the role mapping, the enforcement profile fires, and the accounting you already have supplies the Framed-IP-Address the login notification needs.

If ClearPass can't sit in the auth path, send the accounting straight to the FortiGate. Its RSSO agent builds users from Accounting Start using User-Name, Framed-IP-Address and a group attribute (Class by default, changeable with sso-attribute), and VPN-MARKETING maps to an RSSO group in policy. ClearPass drops out of that design.

If Access Tracker does show a hit on that service, say so and I'll rethink.

------------------------------
Dustin Burns
@Worldcom Exchange, Inc.
www.wei.com

- - -
The comments I post here are my own, and not my employers
If my post was useful accept solution and/or give kudos
Personal Blog: www.networkfieldnotes.com
- - -
------------------------------

A radius proxy service is more along the lines of forwarding requests to another box to process authenticaiton vs what you can process on the local system. This would be most common for something like eduroam or another domain. You can proxy in either direction. With radius NAD there may be a server fail through list or server group. If you have multiple domains and clearpass can only bound to the local domain. You can forward requests to another domain. 

If you are referencing the check box "radius accounting" in a service. This would be used to send accounting packets to fortigate via RSSO. I would generally not recommend this option if you have more then 1 firewall. It will lock a clearpass service to only sending to one firewall cluster. 

proxy ie... 

Service local (contains radius:ietf:user-name "domain1.com"
Perform auth to AD / LDAP, etc. 

Service Proxy (contains radius:ietf:user-name "domain2.com"
Proxy to server x.y.y.y to perform auth

Service shortname (not belongs to radius:ietf:user-name "domain1.com, domain2.com"
Perform auth to AD / LDAP, etc. 

In this case you can create multiple services and a  proxy based on one domain. In order to classify the request properly the user will need to enter their full UPN, otherwise a shortname will default to local auth. You can re-use role mappings and enforcements where you wish. The service addition is to just handle the request slightly different.

You will not gain anything by a proxy service for your use case, and you will need to move authentication to clearpass.   Sending accounting to the FSSO collector will be your only option if you dont want to move authentication. 

Original Message:
Sent: Sep 22, 2026 09:45 AM
From: BB-08d59d
Subject: Aruba ClearPass role mapping based on the Accounting events

Hi Dustin,

Thank you for your reply and clarification.

I believe this approach may also not work if ClearPass is not involved in the authentication process, as it does not own the session itself.

If I configure a RADIUS Proxy service, ClearPass still needs specific criteria to match the service before it can forward the accounting packets to the FortiGate firewall. However, the service is matched only when ClearPass receives those criteria within the RADIUS Access-Request.

If ClearPass is not part of the authentication flow and does not establish the session, it cannot forward the related accounting messages.

What are your thoughts on this?

Best regards,

Original Message:
Sent: Sep 21, 2026 04:18 PM
From: DB86
Subject: Aruba ClearPass role mapping based on the Accounting events

As drawn, step 5 can't fire. ClearPass only runs service classification, role mapping and enforcement on an Access-Request. An Accounting-Request is stored and matched to an existing session, so it shows in Live Monitoring but never hits your service in Access Tracker. RADIUS Authorization is still an authorize-only Access-Request type, not an accounting trigger, so the Session Notification profile behind the FortiManager context server never runs.

Cleanest fix: point the VPN gateway's RADIUS authentication at ClearPass with your LDAP as the authentication source. Now the service does the role mapping, the enforcement profile fires, and the accounting you already have supplies the Framed-IP-Address the login notification needs.

If ClearPass can't sit in the auth path, send the accounting straight to the FortiGate. Its RSSO agent builds users from Accounting Start using User-Name, Framed-IP-Address and a group attribute (Class by default, changeable with sso-attribute), and VPN-MARKETING maps to an RSSO group in policy. ClearPass drops out of that design.

If Access Tracker does show a hit on that service, say so and I'll rethink.

------------------------------
Dustin Burns
@Worldcom Exchange, Inc.
www.wei.com

- - -
The comments I post here are my own, and not my employers
If my post was useful accept solution and/or give kudos
Personal Blog: www.networkfieldnotes.com
- - -
------------------------------

I second that you need to move the authentication to clearpss in order to use the clearpass connector to FMG. As to the implementation of clearpass it was not intended to use accounting like this. If you want to use accounting in custom deployments like this you can deploy freeradius and write your own logic for accounting to perform ldap lookups.  You will have to also create your own integration to FMG through API's. At that point you start to have  redundancy on repeating the same functions in multiple places. Not sure how this will justify not moving the authentication. More complexity does not always mean a better design either.  If you do decide to move the authentication just keep in mind you still will need to send accounting packets. 

To add on what Dustin said with accounting. You can use the FSSO collector to capture accounting packets or syslog packets from the firewall. From here data can be parsed, looked up on the domain, and then returned to each fortigate as fsso data. 

If you only have a single firewall cluster.  Sending accounting directly as RSSO data is applicable.  When you start to have multiple locations with firewalls then a solution like using FSSO collector or the Clearpass Connector to FMG is more applicable. I would target a method that is scaleable to the design and solution. You may want to add additional services to this for firewall policies in the future. 

Hi Justin,

Thank you! I came to the same conclusion.

Best regards.

Original Message:
Sent: Sep 22, 2026 09:33 AM
From: JK-90898a
Subject: Aruba ClearPass role mapping based on the Accounting events

I second that you need to move the authentication to clearpss in order to use the clearpass connector to FMG. As to the implementation of clearpass it was not intended to use accounting like this. If you want to use accounting in custom deployments like this you can deploy freeradius and write your own logic for accounting to perform ldap lookups.  You will have to also create your own integration to FMG through API's. At that point you start to have  redundancy on repeating the same functions in multiple places. Not sure how this will justify not moving the authentication. More complexity does not always mean a better design either.  If you do decide to move the authentication just keep in mind you still will need to send accounting packets. 

To add on what Dustin said with accounting. You can use the FSSO collector to capture accounting packets or syslog packets from the firewall. From here data can be parsed, looked up on the domain, and then returned to each fortigate as fsso data. 

If you only have a single firewall cluster.  Sending accounting directly as RSSO data is applicable.  When you start to have multiple locations with firewalls then a solution like using FSSO collector or the Clearpass Connector to FMG is more applicable. I would target a method that is scaleable to the design and solution. You may want to add additional services to this for firewall policies in the future. 

Went back and labbed this one to close the loop. ClearPass 6.11.1, with a switch sending Start, Interim and Stop.

I put a test service first in the order that matched only on Acct-Status-Type EXISTS and the NAS IP, with an enforcement profile that writes a marker on the endpoint. 28 accounting packets across 7 sessions and the marker never got written. The same profile on the service doing the authentication wrote it on the first Access-Request.

The accounting itself was stored fine and tied to the session of the service that did the auth. So Justin has it right: move the auth to ClearPass, or send the accounting straight to the FortiGate or an FSSO collector.

------------------------------
Dustin Burns
@Worldcom Exchange, Inc.
www.wei.com

- - -
The comments I post here are my own, and not my employers
If my post was useful accept solution and/or give kudos
Personal Blog: www.networkfieldnotes.com
- - -
------------------------------

Original Message:
Sent: Sep 22, 2026 09:54 AM
From: BB-08d59d
Subject: Aruba ClearPass role mapping based on the Accounting events

Hi Justin,

Thank you! I came to the same conclusion.

Best regards.

Original Message:
Sent: Sep 22, 2026 09:33 AM
From: JK-90898a
Subject: Aruba ClearPass role mapping based on the Accounting events

I second that you need to move the authentication to clearpss in order to use the clearpass connector to FMG. As to the implementation of clearpass it was not intended to use accounting like this. If you want to use accounting in custom deployments like this you can deploy freeradius and write your own logic for accounting to perform ldap lookups.  You will have to also create your own integration to FMG through API's. At that point you start to have  redundancy on repeating the same functions in multiple places. Not sure how this will justify not moving the authentication. More complexity does not always mean a better design either.  If you do decide to move the authentication just keep in mind you still will need to send accounting packets. 

To add on what Dustin said with accounting. You can use the FSSO collector to capture accounting packets or syslog packets from the firewall. From here data can be parsed, looked up on the domain, and then returned to each fortigate as fsso data. 

If you only have a single firewall cluster.  Sending accounting directly as RSSO data is applicable.  When you start to have multiple locations with firewalls then a solution like using FSSO collector or the Clearpass Connector to FMG is more applicable. I would target a method that is scaleable to the design and solution. You may want to add additional services to this for firewall policies in the future.