AuthPoint & Multiple Groups Per User
Something I find very frustrating is the fact a user can only be a member of one group within AuthPoint. This is causing administrative complexity when it comes to (for example) accessing resources such as the Access Portal (and using AuthPoint to authenticate), where there are a number of applications, and different combinations of users, using each app/set of apps:
App A
App B
App C
App D
App E
User 1
User 2
User 3
User 4
User 5
User 6
App A - All Users
App B - User 1,2,3
App C - User 4,5,6
App D - User 1,3,5
App E - User 1,2,5,6
In an ideal world (one where a certain well-known competitive product is available).. I'd just sync the equivalent AD groups into AuthPoint - regardless that a number of users belong to more than one group, and assign those groups to the Access Portal as necessary.
From what I can make out, I'd need a separate AuthPoint group for every possible combination of access - not very scalable, and complicated.
If Access Policies were done at the Resource level instead of on Groups - the whole problem goes away, if I read it right?
Cheers, James
All Fireboxes (T-Series, M-Series, FireboxV, Firebox Cloud etc.); EPDR, Advanced EPDR/Cytomic, Orion (Threat Hunting); WiFi, AuthPoint. WSC/Cloud. Management of a few hundred Fireboxes, and a few thousand EPDR endpoints. Platinum Partner. Views my own (if any!).
Comments
Hello James,
thanks for writing in the WatchGuard community.
Regarding your post, this is something that our AuthPoint team is already evaluating.
We have an internal request opened tracked under:
that could avoid the conflict to have one user on different groups at the same time.
Have a great day.
Regards,
-Daniele M.
Hi Daniele
Good news, thanks - that'll be useful..
Cheers, James
All Fireboxes (T-Series, M-Series, FireboxV, Firebox Cloud etc.); EPDR, Advanced EPDR/Cytomic, Orion (Threat Hunting); WiFi, AuthPoint. WSC/Cloud. Management of a few hundred Fireboxes, and a few thousand EPDR endpoints. Platinum Partner. Views my own (if any!).
This appears to still be a problem, or undelivered feature, over 18 months later. I just got locked out of my test server because I'm a member of both "domain admins" and "domain users". I guess the solution might be to create a new OU called Authpoint Groups to keep all of the authpoint specific groups in? This is a pretty big gotcha and, so far, the only thing uncovered during my testing of the product which gives me serious pause.
Hi @chagerhg
I'm a bit confused why you wouldn't give your "admins" at least the same access as your "users" group. Ensuring that your admins have access to whatever required resources they need should allow you to access resources as needed.
Most issues have been addressed via the AuthPoint authentication policies since that initial post:
(About AuthPoint Authentication Policies)
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/authpoint/policies_about.html
-James Carson
WatchGuard Customer Support
This is no longer an issue with the authentication policies... at least for LDAP synced accounts.
A simple user, who is member of multiple Active Directory Groups don't get applied multiple Authentication Policies correctly. Any work around to solve it?.
-Authpoint Group A. Sync with AD Group A. Members: Jim, Matheus
-Authpoint Group B. Sync with AD Group B. Members: Jim, Ana
-Authentication Policy1: let Authpoint Group A users to authenticate on RDP sessions.
-Authentication Policy2: let Authpoint Group B users to authenticate on SSH sessions using Radius.
Results:
Any help ?.
I'm seeing this issue as well.
I've been using AuthPoint for VPN MFA, but now want to also use it for another app where all VPN users may not be assigned use of this 2nd app. Or the new app user may not have VPN access permissions.
When I add another group to sync from AD, the original group membership for VPN gets removed when the user is updated with the new app permissions.
I'll put in a support ticket and hopefully come up with a solution or workaround.
Is there any update on this?
Hi @MRo
Most of the issues in this thread have been addressed. Can you be more specific about which thing you're referring to, as there are a few similar topics that were discussed.
At this current point in time, there are no plans to allow multiple groups per user.
-James Carson
WatchGuard Customer Support
Hi @james.carson,
I wanted to check if there is currently a way to assign multiple groups to a user in AuthPoint. At the moment, I can add more groups in both Active Directory (AD) and WatchGuard Cloud. Howeve when AD syncs with WatchGuard Cloud and both groups already exist there and the user is part of the groups, the user's assigned group seems to change unexpectedly in watchguard cloud.
Is there a way to manage this more effectively or is it planned that authpoint can support this?
Thank you!
Hi @MRo
At this point in time, there are no plans to allow users to be in multiple groups inside of AuthPoint.
If you're having issues with users jumping groups, I would suggest opening a support case so we can look into this. Group information comes from AD group sync -- meaning that we may be getting different answers when queries are run.
-James Carson
WatchGuard Customer Support
I struggled with this early on and got it to work by only using a single Authpoint group that contains all authpoint users (which isn't really used for anything restricted by by group) and letting all the other groups sync from Azure AD. Perhaps this screenshot might help to explain - as you can see all the group control comes from AD synced groups which has multiple/different user combinations.
Correct, if you are using LDAP/ Azure AD Synced groups you need to have an AuthPoint group to sync them to. I usually make a group called "AuthPoint-Sync" with a description "Anchor for LDAP/Azure Sync".
Then afterwards, you have to check the box in the group sync Create new synchronized groups which is what allows all of the groups from the sync to show up as a different group in WG Cloud.
I only use the AuthPoint-Sync as an anchor with NO policies assigned to it, save for maybe a "CatchAll" policy for the IDP portal for authentication testing.