It is basically a terminal server, proxy, bastion or anything similar. You log in there with federated identity (for example AD) and it logs you in into target system with some shared or temporary user. Usually it also records session and does other security/compliance related things.
Examples are Delinea (former Thycotic), CyberArk, To some extent Apache Guacamole can be used as PAM.
Everything should be 'hardened'. This also means everything has to do proper authentication and authorisation, and skipping that step by letting some proxy do that just creates a bottleneck in security, reliability, availability, and performance.
It also doesn't really matter how it's done, a Kerberos Ticket, x509 client certificate, JWT or multiple credentials (i.e. username with a password and MFA token) are all plenty valid. Granted, a ticket, certificate or token allows shipping claims or attributes allows for directory-less access control, but that doesn't mean that having to do directory lookups is not feasible anymore.
Most of the other things like f5, pa, Citrix, powerbroker and bomgar are just really shoddy software that you setup to attempt to not have to bear responsibility or know what you're doing (or it's clipboard/checklist-based security...), but that just bypasses fulfilling the actual need of a good IAM and PAM implementation. None of those products do it better than what is natively supported, and they are consistently more problematic (be it performance, cost or actual security).
Thycotic had some vulnerability with a symmetric recovery key a few years ago. But comprehensive product like this or roll your own this is frequent so I'd rather do keys and certs like others suppose
a) relatively complex to set up properly if its not a Windows in AD
b) an SSO, not federated ID. Which means reasking MFA is not possible.
Isn't reasking MFA on purpose just a way to make people hate MFA? Shouldn't everything support a "Trust this device" option and then never ask again from it?
Managing access to privileged systems at scale is hard despite these tools. This isn’t a knock on the tools. It’s a people/risk problem. Eg staying on top of those recorded sessions becomes increasingly difficult over time.
The sustainable way is to work with business and compliance and remove the need for privileged access. It’s doable in many scenarios and leaves a very small “rump” of things that do need privileged access, with all the attendant overhead.
In general, challenging teams to do without privileged access and making it a “last resort” thing is a great idea, depending upon your industry / risk profile.
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.
Would you care to share how you achieve this/what does the implementation of these two look like?
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.
(But I much prefer keys/certs over passwords where possible.)