Closed AndreaCuneo closed 3 years ago
Oh, good catch!
Adding OAuth2-Group
could work but you will run into the problem that when changes to the users group membership are made they will never make it back into that cache.
If you (or someone else) do not beat me to it, I'll look at updating the usage of the Perl module later this week to only skip the authentication step and not the setting of group memberships; there is a sync'd list of groups maintained by the Perl module I'll tickle out.
Checking the Perl module, looks it's actually already done. See https://github.com/jimdigriz/freeradius-oauth2-perl/blob/8ffda3af53384be26a145b6cd9a317d1f803acd3/main.pm#L337
The issue was that I assumed that the Auth-Type would have been OAuth2, but actually, in case of Cached is not. I changed my post-auth policy to not check the Auth-Type and is working like a charm! Thanks for pointing me out.
This is how to forward OAuth2 groups to PFSense in the format PFSense expect.
post-auth {
...
oauth2
if (&OAuth2-Group) {
update reply {
Class := "%{echo:/bin/sh -c 'echo \"%{OAuth2-Group[*]}\" | tr , \\;'}"
}
}
}
Glad you figured it out. Thanks
I'm integrating AzureAD via Radius in PFSense as authentication mechanism for VPNs and PFsense too.
In the latter case, user groups can be mapped to PFSense groups via Class attribute, and I've managed to forward OAuth2-Groups. But when using Cache (2nd login) the OAuth2-Groups is not available and thus no decisions can be made.
Current workaround is to disable password cache, but I'd like to use that feature.
The change should be trivial by adding reply:OAuth2-Group to cache policy. If it is correct, I can provide a PR.