One of our co-founders was working as a UNIX/Linux engineer for a large startup in California in the early 2000's, when a tech executive at the firm suggested interfacing all of the firm's Linux and UNIX servers into the company's new Active Directory tree. This turned out to take a significant amount of time, but it eventually seemed to work well for the password-based authentication prevalent at the time.
Several of the company's web servers, which were running Windows, were compromised in an attack a few weeks later. (During this time, Windows servers were being compromised on a nearly weekly basis.) Although the attackers were unable to break into the Active Directory server itself, they had manually created local Administrator accounts on the Windows web servers they'd gained access to.
The attackers proceeded to DDoS the Active Directory server from the very servers that the Active Directory server was serving connections for. The AD server choked. The Windows team couldn't even get into it without driving to the datacenter and unplugging it from the internal network.
Meanwhile, it was impossible to log into the Linux and UNIX servers because of their dependence on a centralized server, not only for authorization, but even simple authentication.
A decade later, nothing had changed: the problems with centralizing authentication and passwords continued, but now there was a new problem: the Cloud. And SSH had a trick up its sleeve to remove passwords and dramatically improve security: keys! But SSH keys languished in relative obscurity, hampered by manual and inscrutable CLI management tools.
The Cloud enabled servers and containers to be created on the fly in response to demand, and that meant that even cached credentials would often be non-existent in server whose lifespan was now measured in hours instead of years.

Even worse, it increasingly became obvious that connecting your AD server, which often contains the "keys to the kingdom" and doesn't encrypt any of its stored data, to any external network was an increasingly bad idea.

In 2011, the first version of Userify was quietly launched and subsequently deployed across the entire Cloud of a major financial firm. At that early stage, it was little more than a simple shell script connected to a web dashboard.
In 2015, Userify launched the first auto-deployment tools for the open-source Userify shim, allowing the agent to be deployed anywhere in seconds. Since then, we've added custom integration support with third-party LDAP and AD servers, while still maintaining that legendary Userify reliability, even if the third-party or even Userify itself is down or disconnected.
Today, Userify has evolved into a powerful tool for self-service management of SSH keys, sudo roles, and user accounts across multiple clouds, projects, and auto-scaling groups, with new support for integration into Ansible, Chef, Terraform, Puppet, and CloudFormation.
Userify offers multiple Userify Editions covering every conceivable scenario, from managed SaaS in our Userify Cloud to our on-premise Userify Express and Enterprise designed for deployment in AWS, Google Cloud, and Azure.

Try out either our Cloud edition, or set up a proof-of-concept or pilot program in your company of either Userify Express or Userify Enterprise today.