APM SSLVPN - ACL assignment fails

[jornlux]

Hello folks, first post !

We have an SSLVPN configuration where we would like to use iRules to attach prebuilt ACLs to user sessions.

The user's group memberships in Azure AD should determine which ACLs to attach. Auth and SAML response/assertions are OK, that we have found from logs.

As per the manual, this can be achieved by utilizing one of the following events: ACCESS_ACL_ALLOWED, ACCESS_ACL_DENIED.

As it seems, though, these events are never raised. For troubleshooting purposes, we have implemented basic logging for the two with the following code, but neither produce any logs anywhere.

when ACCESS_ACL_ALLOWED {
	log local0. "Raised event ACCESS_ACL_ALLOWED"
}

when ACCESS_ACL_DENIED {
	log local0. "Raised event ACCESS_ACL_DENIED"
}

Are we completely off track?

[Nikoolayy1]

Hello, You have to look at the /var/log/ltm for the logs as local0 saves to the ltm logs and local1 is for APM:

https://support.f5.com/csp/article/K13317

Also how do you sync the Azure AD groups to the F5 device as the Azure SAML does not allow groups to be shared and either the Azure AD LDAP extra feature needs to be used or the F5 needs to connect to an on-prem AD directory with Kerberos / LDAP etc?

https://community.f5.com/t5/technical-articles/azure-active-directory-and-big-ip-apm-integration/ta-...

https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/auth-ldap

You can also use the microsoft Azure AD conditional access policies with F5 APM as this a great F5 feature and intergation with Azure AD and the conditional access policies can be attached to groups:

https://www.f5.com/company/blog/zero-trust-azure-active-directory-access-big-ip-apm

https://www.f5.com/pdf/solution-profiles/f5-big-ip-and-azure-active-directory-conditional-access-sol...

https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview

Other vendors have a SCIM connector app in Azure AD to sync the Azure AD info to their systems but this is usually for cloud services and maybe F5 will add this to silverline or volterra in the future https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/sync-scim

[jornlux]

Hi @Nikoolayy1 , thanks for answering.

Logs - we've found the log locations, so that's covered. It's just that these two particular events never seem to trigger.

AAD Groups - not exactly synced, rather a list returned in the SAML response as an additional claim we've configured within the F5 AAD app - see image below.

Conditional Access - not sure if this can directly solve the issue at hand, but we'll look into that option.

[Nikoolayy1]

Have you seen this post that suggests for example "expr { [ mcget { session.saml.attr.groups } ] contains "Administrator" }"

https://community.f5.com/t5/technical-forum/saml-session-variable-and-attributes/td-p/212706?page=1

Also use the F5 APM Logging or Message box to follow your traffic to know that you are matching the correct branch in the visual policy editor and the correct groups where the ACL is attached as maybe the event is never triggered as the ACL never is attached to user traffic because wrong config or AAD groups.

https://techdocs.f5.com/en-us/bigip-15-0-0/big-ip-access-policy-manager-visual-policy-editor/access-...

F5 APM reports that may help the investigation:

https://support.f5.com/csp/article/K09102347

https://support.f5.com/csp/article/K44555523

Also check the SAML if you think that not the correct groups are returned as if the groups are not Azure native there could be issues (synced from the on prem AD to Azure):

https://support.f5.com/csp/article/K51854802

Also just  as info you are using static ACL not dynamic ACL right?

[jornlux]

Hi.

expr { [ mcget { session.saml.attr.groups } ] contains "Administrator" is a possible solution we've considered. This would however imply that we create one step in the policy editor for each group/ACL combination, and there could be quite a few along the way. Thus, we would rather use an iRule (if possible) to solve this dynamically.

The AAD group IDs returned seem correct. We've bumped up the log level for this specific access policy to debug, and can also verify these contents from active APM sessions in the GUI, or using the CLI command 'sessiondump --allkeys'.

ACLs are static, yes. These are populated automatically through the API when needed - such as when a new Azure subscription with a corresponding IP pool is created.

[Nikoolayy1]

Still if you are not triggering the ACL events it seems to me that the F5 APM thinks that there are no ACL defined as only then the ACL events are not triggered, so better debug the APM policy as I suggested and to look at the apm reports:

https://community.f5.com/t5/technical-articles/http-event-order-access-policy-manager/ta-p/287898

Outside of that you can check for ACL bugs in ihealth or the bug tracker or the F5 release notes for your version for fixes and known issues:

https://support.f5.com/csp/bug-tracker?sf189923893=1

https://support.f5.com/csp/bug-tracker?sf189923893=1