If you've ever had to answer "why does this user have access to X?"
in an AD environment, you know the pain: the answer usually lives
three or four nested groups deep, and the native tools don't show
you the path.
Whohas syncs your directory into Postgres and precomputes every
effective membership with the full path. Click a user, see every
group they're in and how they got there — direct, or via which
nested chain. Same the other way: click a group, see everyone with
access through it.
One design decision worth calling out: it stores one row per
distinct path, not per (user, group) pair. If someone reaches a
group through two different chains, you see both. That matters for
audits — "revoke access" is a different task if there are multiple
paths.
Hi HN,
If you've ever had to answer "why does this user have access to X?" in an AD environment, you know the pain: the answer usually lives three or four nested groups deep, and the native tools don't show you the path.
Whohas syncs your directory into Postgres and precomputes every effective membership with the full path. Click a user, see every group they're in and how they got there — direct, or via which nested chain. Same the other way: click a group, see everyone with access through it.
One design decision worth calling out: it stores one row per distinct path, not per (user, group) pair. If someone reaches a group through two different chains, you see both. That matters for audits — "revoke access" is a different task if there are multiple paths.