Imagining a world without Active Directory
What is AD?
If you live in my world of Tech, Microsoft’s Active Directory (AD) is the cornerstone which underpins your entire Windows Estate. For those of you lucky souls not in the know it’s a place where user accounts, computer accounts, server accounts, user groups, device groups and policies live. We use it in order to access networks (wired and wireless), assign permissions to access share drives or Linux Groups. It stores encryption keys for devices. Without it you can’t connect to the office network, and there may be software or servers you can’t get access to. When it works I sleep like an old dog after a long walk in the countryside, when it doesn’t I develop a thousand yard stare.
Previously on…
When we started 2020 we had some fairly low-level objectives to look into, mainly a world where we needed to lose AD. The reasons for having AD are slowly diminishing. Our tech is changing and evolving. For example, people now enjoy Google Drive with a hefty wedge of storage as an alternative to traditional file shares, and that doesn’t require AD Credentials to access.
If I’m being honest, I thought that we’d already put some of our legacy issues to bed by migrating services into AWS, but as some are still AD Dependent, we’re having to re-think those as well.
The issue
If I told you that thinking about a world without AD was a priority for us this year I’d be lying through my teeth. Then something happened in Wuhan and it’s completely changing the way we think about everything. AD is regarded now, for us anyway, as something of a legacy luxury. It’s not that AD is bad, but the problem is the lack of a constant connection to it for around 90% of our End Users, because only 10% of them will be connecting in our corporate network via VPN on a regular basis. In real terms this is something like 1300 Windows Devices that don’t talk to AD on a regular basis.
A world without AD?
That’s not to say that I can’t imagine a world without AD. When I first came into IT in 1999 Active Directory didn’t even exist. The company I used to work for used something called Novell Netware which was once a big hitter in the IAM, Server OS and Network Management world. At its zenith it controlled 63% of the market. Their technology helped move IT in general away from Mainframe Computing and towards Local Area Networks.
Gradually though, Novell lost ground to Microsoft and even at one stage they were even forced to make a Novell Client for Windows, such was their admission of defeat. Ever since about 2000 my life has had AD in it, and no I am not Judge Dredd.
But a world without AD? Basically it meant that we have to start thinking about AD a lot more, and more importantly, how we were going to bypass it if most machines can’t contact it. In the short to medium term we needed a way for machines to live and thrive without it. In the longer term we really need to forget it even exists.
The Cold Facts
We have around 1500 Active Windows devices (not including our Server Estate) at the FT and these machines, when connected to the FT’s Internal network, talk to AD constantly for things like…
- Network Authentication, wired or wireless
- File Shares and Printers
- Permissions on hosted applications (Citrix etc)
- User Policies
- Password Expiry Policies
- FT Logon Disclaimers
- Screensaver lock out times
- Computer Policies
- Network Time Syncing
- Software Installation Restrictions
- Operating System Activation via a VAMT Server
- Client Management (SCCM)
- Windows Patching
- Application Installation
- Application Scoping for Self Service
- Application Removal
- Lifecycle Maintenance
All of these things are done silently in the background each and every time an employee connects to the FT’s Internal Network. It makes things run smoothly and keeps me sane.
In the current world, very few machines enjoy this luxury and it poses us some annoying interesting challenges
For challenging times, make it Suntory times…
The current situation means that we certainly can’t take AD for granted anymore, especially constant access to it. Everyone now works from home with dogs, cats, kids and dinosaurs who are fought to the death during Google Hangouts by wilful 3 year olds, schooled on a semi-dangerous diet of Neo-Liberal parents, Anzac Biscuits and Tekken.
Not everyone connects in via VPN. The FT has a limit of 500 concurrent connections and we estimate that only 10% of Windows users connect via VPN at any given time.
From mid March this year pressing and immediate challenges we had were…
- How do you enforce policies? Once everyone was working from home, we changed some policies as they seemed to be far more relevant when people where in the office — but to do that, we needed to be able to apply the changes:
- Screensaver lockout was extended from 5 minutes to 20 minutes
- User password expiry policy was extended from 90 days to 180 days
- Setting time on machines without them getting the time from on site domain controllers
- How do you install new software?
- How do you re-invent software installs that reference internal servers or are scoped via AD User groups?
- How can you work without VPN?
- How do we patch machines off the network?
- How can we do this without the luxury of local distribution caches?
- What else to do we need to consider?
- What automated maintenance tasks need to be reviewed and modified? For example SCCM itself, being a server, still talks to AD regularly and imports computer objects from. It also deletes inactive ones. What makes an active device an inactive one, you ask? 90 days of not talking to AD.
We are luckier than most companies that at the FT we have spent good money on a couple of good Client Management Tools. We have SCCM for Windows and JamF for Macs.
We also have a public facing SCCM Management Server (which we thankfully fixed with Microsoft’s help in Mid March) as well which lets us serve and control the flow of Microsoft Updates (the part that was broken) and software installations without the need for computers to connect to our internal network. Did we ever think it was capable of serving up to 1300 Windows machines? No.
Ordinarily we’d package up updates and Software in the traditional manner. To an extent we still do but now we don’t send this out to all distribution points to save on bandwidth.
The biggest issue we really faced was how we deliver policies to our computers. In the end the broken SCCM Internet Facing server pointed us in the right direction as it was still serving Software Updates. We created registry modifications and packaged them as Applications which were then delivered in SCCM and scoped to a Device Collection of machines that don’t connect to the FT via VPN subnets. We’ve learned to love SCCM a little bit more since lockdown. We’ve even become much better at creating SQL Queries.
Future Times
So what does the future hold for AD at the Financial Times? It’s obviously still going to be around in some form as the FT still runs many services that are dependent on AD, that aren’t dying off anytime soon, or where the end user has to be in a particular group in order to use applications hosted on internal servers and/or in the Cloud. But we need to plan for Remote Working as the new norm. This includes reviewing recently migrated services which have been “Clouded” but still have that all important link back to AD.
We want to swap Microsoft SCCM for Microsoft Intune (as it can host machine and user policies) and Microsoft Autopilot (so we can host our OS Builds in the cloud and configure laptops just from entering a user name and password). That needs a directory service in the Cloud so that might well be Okta. For magazine file shares we’d be looking at Adobe Cloud rather than the current proposed solution of EC2 and EBS in AWS. There will come a time when FT employees will be logging into their Mac or Windows device with an Okta logon prompt.
That’s where we’re heading eventually. It might take a tactical hybrid solution implementation along the way, but we’ll get there.
