By Rajat Bhargava Posted April 4, 2013
I came from a small company that got, well, not large, but got medium. There were a lot of growing pains, of course – including suddenly needing a lot of servers. Maybe more than you’d expect.
In the engineering department, we had a few dozen people that needed access to various servers… and they were various. Everyone had their personal machine, mostly Macs and Linux per individual taste and geek-cred, with a Windows machine thrown in just to be contrarian. On top of that developers would have a handful of virtualized Unix instances for their own use. Each tester had a dozen machines in a hodgepodge of virtualized and “in-the-cloud”, a mixture of all the flavors of Unix and the savoriness of Macs and the bitter taste of the Windows operating systems back through XP. There was even a smattering of physical boxes that collected dust under desks and occasionally blew hot air, but mostly were ignored until their fans went out and they cried out in panic.
All of these machines, this zoo of flightless Macs and lumbering herds of Unix boxes and cloven-hooved Microsoft machines, all of them required a way to log in. That’s about the only commonality you could define, perhaps. To use them, you needed to identify yourself. And the identities needed to be managed. But how, really, do you do that? Windows machines worship at the temple of Active Directory – and perhaps if you have one domain and one group of homogenous users that’s relatively easy-if-not-cheap. But we were not an all-Windows group, not even close, and the Windows machines themselves were of different sects and belonged to different domains over which a set of AD warlords watched over their personal fiefdoms of 2-5 members for testing and whatnot. And then there are the Macs in their scattered groups and their single owners. And don’t forget the Unix boxes, which could be hobbled and hammered into taking the Active Directory yoke, but that naturally want to know you personally – want to hold your public key or be able to verify your password.
And what of the remote computers? Those at AWS, Rackspace, ViaWest, or SoftLayer, or at your developer’s home, or at some hotel at a conference, or at your East Coast satellite office? Where is their access managed? Extended domains, tenuous connections to the AD overlord ruling like King George through fiat and fear? Individual management on the back of the IT team?
It’s not to say that it can’t be done. We know it can be, it IS done, through the diligence of a highly competent and trained group that oversees all of it, checking the connectivity and answering the questions about VPN and resetting lost passwords and following cables under desks. Adding groups and permissions, and revoking when someone quits, and telling a new user how to connect to AD on their Mac (don’t forget admin rights…) and managing public keys for the Unix servers and let’s not even get started on strong authentication and tokens and RSA servers and such. Server access management is a core part of the IT group’s job – one of the main things they do and that they spend the most time on. These are solved problems.
It’s not that it can’t be done. It’s just… why can’t it be simple?