[yetanotherloss]

I've been moving away from this model towards user-asssociated VPNs or (inverse) captive portals.

Used Powerbroker and cyberark for a long time and while they're good at stated purpose the integration with more flexible and modern auth systems has had a lot of friction.

The particular regulatory area I work in is also just a non-starter for federated AAA from outside the regulated systems which colors my opinion though.

Combined with command restrictions in openssh and sudo etc you end up with several wholly disjoint attack surfaces, decent logging, and granular user restrictions.

[unixhero]

>I've been moving away from this model towards user-asssociated VPNs or (inverse) captive portals.

Would you care to share how you achieve this/what does the implementation of these two look like?

[yetanotherloss]

The terminology varies by vendors but essentially there are authentication portals that users will log into and receive auth tickets. These are forwarded to network gateways, usually encrypted in a vpn tunnel, that allow traffic based on user RBAC, sometimes region or time, etc.

Captive portals are web auth pages for use cases the more structured method doesn't work for. They were envisioned as making you sign in hotel wifi and such but work in the other direction as well by forcing a web user login before allowing traffic from a host for some period of time.