Customer Stories: The Road to Rethinking Active Directory

Rachel: Hi, and welcome to The Road to Rethinking Active Directory. I would like to thank you all for joining this unique virtual session. Today we have two companies with us that are also going to help us explain a bit The Road to Rethinking Active Directory. Let's get started.

Rachel: So, when we think of the Active Directory, we actually have a bit of a roadmap, and these four stops include things like your current Active Directory mindset, security, modern thinking, and actually some questions that help you get started on the foundation to rethinking Active Directory.

Rachel: So the first one is actually looking at what you currently have with Active Directory. So we see expectations for technology is changing. Technology is expected to be flexible, cost saving, but also help your organization have a bit of a competitive edge when looking towards the future. That's actually a lot to expect from technology these days, and we see that Active Directory really up with this. Things as simple as bring your own devices; it seems very logical, using an iPad, a MacBook or your mobile to access apps or data. We see that Active Directory isn't that flexible in this, it doesn't really help you actually catch this use case and help your organization achieve this. Also, things like user friendliness; changing a password or resetting a password, things like single sign on and multifactor authentication, these are all things that Active Directory really struggle with and can't really offer you a solution for.

Rachel: So with these modern approaches and different tools also comes new threats. Microsoft said it themselves about Active Directory, there's just so much to compromise. It's not as simple as stealing a username, password and accessing some emails. They want access to change things like GPOs, things like different computers and manage different users. All of these things come at a cost, and also a very high risk. Things like [inaudible 00:02:00] delegation or things just as simple as an admin trying to do Active Directory tasks on a computer, all of these things come with a lot of vulnerability and a lot of risk. What's scary is the risk is on you. If you're managing Active Directory and there is a new vulnerability, it's up to your organization to handle that. It's up to you to decide how this should look within your organization.

Rachel: And what happens if there is a problem? Of course it's cost and of course there's a lot of fallouts, but what's more important is the trust of your customers. So how can you ensure that that's going to be actually still standing after you have a breach or a problem? So it's not really a scare tactic, it's more of a thought process. So are you secure using Active Directory, or is it helping you maintain security? That's a very important question to ask when looking towards different approaches.

Rachel: So the other thing we're going to talk about is modern thinking. Technology, of course we talked about all those expectations of technology, it really requires a different approach. What you need to ask yourself, is Active Directory holding me back? Is it holding me back from things such as a better fit or a better architecture, even a better user experience? And what are costs like? Is there maybe a different tool you're looking at, or it could be cheaper, you can't really do that because you're still stuck with Active Directory. Don't be stuck making future choices for your organization with a legacy mindset. You want your architecture to be beneficial, to help you grow, and you want to make sure you can do that with things like single sign on, multifactor authentication. These things are more of a requirement these days. And actually using these technologies, how complex is that? Because with Active Directory you don't get that by default, you actually have to have additional tools. And with these additional tools come a lot more risk. So is it really helping you think more modern with your organization, or is it kind of hindering your outlook?

Rachel: So I put this image up here to kind of explain how companies think differently. So a lot of companies, for example ... well, let's take a user who buys a Tesla. So I love a Tesla, it's electric car, it's more efficient, there's no emissions. What you find is that a lot of people started looking for the gas caps on Teslas. So they were trying to fill up the car when they didn't know it. And we actually see the same with organizations as well. They want to become more efficient, they want to become more beneficial within the organization, more cost effective, but they still have this legacy mindset. We see that always in technology, especially being a SaaS provider, you see the changes. And a lot of companies just think that this is a big bang change and it scares them to get rid of Active Directory.

Rachel: You don't really have to go that way. What do you have to do is ask yourself, is Active Directory holding me back? Is it increasing my legacy footprint? Although you might have to depend on Active Directory now, how flexible is your landscape if you want to choose a different identity provider such as [inaudible 00:05:00] or others? Are you really having to compromise on things? These are just questions you should really ask yourself when you're rethinking Active Directory.

Rachel: So, enough of hearing me talk, let's hear from Chris Sanchez from Zoro, whose company has actually started the whole process to rethinking Active Directory.

Chris S: Thanks Rachel. Hi everyone. Again, my name is Chris Sanchez and I'm the senior manager of end user support at Zoro. Zoro is an e-commerce supplier based out of the Chicago land area. If you haven't heard of Zoro before, trust me, we're definitely working on that. Let me tell you a little bit about Zoro. vChris S: So zoro.com was launched in May of 2011 to be a supplier of maintenance, repair and operations supplies for basically organizations who were looking for one place to get everything they need to keep their business running. Back then Zoro was 20 employees working out of a warehouse and our customers could choose from around 180,000 products on our website. We still offered a physical catalog at the time and sometimes everyone had to pitch in and basically pack up and ship custom orders out of the warehouse. Since then, I would say a lot of things have changed at Zoro, especially the number of people we have working on a daily basis to keep zoro.com up and running, as you can see from the slide.

Chris S: As you can see here, we have definitely grown from those 20 people in the warehouse, and especially over the last two years Zoro has basically doubled in size to support our journey as an endless aisle supplier. Because of this sort of exceptional growth, we've been able to offer the best solutions for our customers and see increasing numbers in basically all aspects of our business, from 30,000 total new customer acquisitions per month to 1.8 million total web transactions. Our growth has really allowed us to solidify Zoro as a supplier businesses have come to know and trust where they can get everything they need to keep their business running. Now they can choose from over four million items from over 4000 of the most trusted brands. And to get to this point, to enable Zoro to grow as it has, our technology choices have really had to be made with the idea that we need to support the business at the growth and scale that we're becoming accustomed to. And that's where our journey with Okta and my journey with Zoro started.

Chris S: So where we started here as a business, Zoro really kind of was born in the Cloud, mostly. All of our internal infrastructure and website infrastructure [inaudible 00:07:35] web services. In the early days ... I mean now we're moving into Google Cloud platform, which is fun and exciting. From the internal IT side of things, that means we have no data center equipment to manage, our MDFs and IDFs are basically empty rack space, which is really weird to see, except for some networking equipment. Also we did get some help in the early days; Zoro was able to leverage a lot of existing IT processes and tools from our parent company to keep the amount of internal IT support needs basically to a minimum.

Chris S: The opportunity there though was that a number of those IT processes and tools were really fit for purpose for that much larger parent company we have, but not necessarily fit for purpose for the needs of our rapidly growing Zoro. And that's some of the reason I was brought on at the end of 2018 to help grow their internal end user support team and to really start us on this journey of transitioning Zoro over to tools and processes that made more sense for our needs and our scale. And let me tell you a little bit about what that environment looked like when I started.

Chris S: When I began, we were still leveraging, our parent company's Active Directory for directory services. Unfortunately, we didn't necessarily have any insight into the service, things like how it was configured, how it was managed. We didn't really have the ability to connect services to it. And also at the time we had a number of SaaS based tools. Our users were leveraging to get work done that weren't tied to that at all. That meant we had no way to really centrally manage those accounts, we had no centralized way for our users to access those applications. From the internal IT side, that made the onboarding and offboarding process for my team just an absolute nightmare. And there was definitely some additional risk we were carrying around securing those applications because of a lack of centralized management. It was really difficult for us to do things like tracking licenses, keeping user permissions intact. Basically, keeping the tools up to date on a day to day basis was like a full time job.

Chris S: On the end user side, which I can really relate to because I was a new hire at the time, the user experience was super segmented; having to bookmark all these new applications in the browser, remember multiple different usernames and passwords, no centralized access to these Zoro provision SaaS tools. It was frustrating and challenging, but it was also a challenge I knew that my team and I were going to have to tackle basically immediately when I started. And for Zoro, that's sort of where Okta came to the rescue for us.

Chris S: Now I know there is a lot of information on the slide, let me break it down into two parts and I'll take the time to speak about each. On the right hand side of the slide is a diagram of our proposed plan for moving away from Active Directory, as well as replacing some of our other shared services from our parent company that, again, didn't really meet Zoro's needs. On the left hand side of the slide are some improvements that we were trying to make, really both for the IT side of things and for our end users. For both parts of this slide, Okta for us was the piece that could really make this all happen at Zoro.

Chris S: Now, looking again at the diagram on the right, I mean this is actually the diagram that we showed our executive team at Zoro and our stakeholders at our parent company. We used this to show them where we thought our technology stack could or needed to go, and as you can see at the center of it, what we considered to be the foundation of making these proposed changes work was Okta for us. Our plan was to really totally embrace the Cloud like we had done with our infrastructure, remove any sort of reliance on on premise or self hosted tools, whether they were hosted by Zoro or hosted by our parent company. We were going to do things like move away from Exchange and embrace G Suite for our email and collaboration tools. We were going to implement a new HRS system and adopt HR driven IT provisioning with the help of HR as a master. We were going to replace a number of our existing shared services like our call center solution, our intranet, our project management tools, and really embrace the Cloud based equivalents of what was out there.

Chris S: And for us, Okta made this all a possibility because of really what it offered on the left side of the slide. It gave us things like a universal directory, a single source of truth we could use for our users at Zoro. It would allow my team to start automating some of the manual processes we had been doing around onboarding and offboarding, basically freeing a lot of their time up to work on support tickets and other projects that were going to help us get to our goal. I was especially excited about the prospect of having a single location to see which Zoro managed tools our individual users had access to. This would allow us to be more secure in those applications, and again, when we were doing things for compliance and audit, it would allow us to better audit those applications, especially as Zoro grew. And then, on the end user side, having a single centralized location to access everything they needed to work. I mean, that would be a game changer for everybody. It's saving them time, and on my side, saving us our support resources.

Chris S: And at that point we basically got approval to move forward with this plan, and this was at the end of 2018, beginning of 2019. And since then, here's some of the things we've been able to accomplish with the help of Okta. So far we've been able to transition all Zoro managed applications to SaaS based tools, and have been able to [inaudible 00:13:13] 50 of them behind Okta, which makes our security team super happy. By leveraging the connection between G Suite and Okta, we were able to use G Suite to feed Okta's universal directory to keep our user information as evergreen as possible. That's really nice because we can also use that up to date data to feed some other downstream applications that leverage that same user information; things like org charts, communication platforms like Slack. We've started to automate the provisioning and deprovisioning of application access for our users during the onboarding and offboarding process with the help of applications that support things like skim and just in time provisioning, things we couldn't do before. We recently enabled adaptive MFA for Okta Verify and [inaudible 00:14:01], we got to add in another layer of security around our environments. Again, trying to keep our security team as happy as possible.

Chris S: We've begun building out application personas using Okta's universal directory along with their super robust rules engine to cut down on the amount of application access requests my team receives on a daily basis. With these personas we can build out organizational, departmental, team, role-based application assignments to easily streamline the process on our end of figuring out what applications users need on day one to be able to do their job.

Chris S: And lastly, because using Okta has been such a great experience for our end users, we were easily able to build in compatibility with Okta as a prerequisite for any future software vendor requests. Basically our legal and enterprise ops teams have empowered us to help set some guard rails and basically say that if these tools are not going to be compatible with Okta, we really don't want to bring them onto Zoro, add additional tech debt. We want to be focusing on keeping the application management and user management as simple as possible through Okta.

Chris S: Now, when it comes to things like our end users, again, we're getting them trained to the idea that anything we bring on should be as seamless as it is with Okta. Anytime we roll out a new application or process, they're used to it now and they're used to it being as seamless as it was when we brought in Okta.

Chris S: Now, although we've accomplished a lot of this stuff in such a short time, we still have more on our roadmap at Zoro when it comes to Okta. We have almost completed our selection process for our new HRS master system. Because Okta has made such an impact at Zoro, we were basically able to recommend to HR that we should only be looking at tools that support Okta as HR as a master, and they were basically super happy to oblige that. One of the last remaining shared services we have from our parent company is end user device imaging and management; in order to tackle that project we knew that Okta would help us, but that we would also need some help from some of Okta's partners like JumpCloud out and [Jam 00:16:09]. We already started some work in some of those areas and are already seeing how seamless these tools work together to really aid us in completing that project.

Chris S: We also continue to mature our onboarding and offboarding automation, supporting our persona based provisioning project with the help of, again, automation and rules and some other homegrown scripts. And then lastly, we will continue to [inaudible 00:16:33] the other 50 to 75 SaaS tools we've been adding throughout the organization, securing them behind Okta, securing them in the most effective way possible, and really ensuring that our employees continue to have a great user experience that they've sort of come to know and love with Okta.

Chris S: For us, I mean it's been a short journey, but that's where we're at so far. We know we have a lot more work to do, but wouldn't be anywhere near as far as we are right now if it wasn't for the help of Okta. Now, because each customer's journey is a little different, I'm going to pass it on to Kelsey and [inaudible 00:17:06] to learn more about ThoughtWorks unique rethink AD experience and any lessons that they've learned.

Kelsey V: Thanks Chris. Hello everyone, I'm Kelsey Van Hasta speaking to you from Melbourne, Australia, and I'm joined by my colleague, [inaudible 00:17:23] who will be speaking from San Francisco, California.

Speaker 4: Hi everyone.

Kelsey V: So we have some history with Okta. Quite a lot of history, in fact. We started working with Okta back in 2013. Okta replaced an on prem identity service called CAS, and Okta MFA replaced a token based second factor service, which between them accounted for 30% of all of our help desk tickets at the time. There was initially a bit of concern about moving off prem to the Cloud, but in short, we've never looked back.

Kelsey V: The identity team of which [inaudible 00:18:07] and I are members was formed back in 2015 and its remit was to build identity as a product based around Okta SSO. The team started with just three people, two based on the West coast USA, and me, one, in Melbourne, Australia. We've grown a bit since then and we're now a cross functional product team of eight people. We build, run and support our product working remotely across 18 time zones. We look after Okta, Google Administration, SimpleMDM, 1Password, and what remains of Active Directory, as well as running and developing and maintaining the ThoughtWorks identity lifecycle service.

Kelsey V: So why did we decide to rethink AD? Well, there were three key drivers. The first was that we weren't really making use of its capabilities. More than 95% of us exclusively use Mac laptops as our primary work machine. Nearly all of our applications are SaaS based apps, we don't store data ... we store data in the Cloud, sorry, and we're all extremely mobile. The vast majority of ThoughtWorkers don't do their work from our offices.

Kelsey V: Secondly, we haven't done a great job configuring and setting up AD in the first place. It wasn't a technology we were experienced with in our early days, and so we inadvertently ended up with a complex and fragile setup. We realized early on that if we were going to continue working with AD, we needed to effectively start over from scratch, and it was at that point that we began to seriously consider whether we needed it or not at all.

Kelsey V: Finally, aside from AD, we knew that our architecture was complex. We'd had some pretty ambitious growth plans and our existing approach to managing identities was too manual, too many touch points and lots of deeply coupled systems. It really wasn't scalable and we badly needed to simplify.

Kelsey V: Once we'd made the decision that we didn't actually need AD at all, we were then free to address the problem of how do we remove it. This meant taking a look at our identity architecture and re-imagining what it might look like without AD. When we started, AD was still a source of truth for ThoughtWorks identities, and that was the thing we needed to change first. We needed to reverse the flow of information through our systems so that rather than data flowing from AD to Okta, we had data flowing from Okta to AD. Okta was going to be the source of truth for our identities, while AD, for a little while at least, was still handling authentication and doing duty as a password store.

Kelsey V: I'm now going to hand over to our tech lead, [inaudible 00:21:11], and [inaudible 00:21:10] will walk you through what we began with and where we ended up architecturally after this first step. So, [inaudible 00:21:20], over to you.

Speaker 4: Thanks a lot, Kelsey. Oh, can we go to the next slide? Yeah, thank you. So this is what architecture we have until 2015 when Active Directory was the complete master. Now, the PSHR was also software for employees and PSHR was synced with Active Directory, with a small partial script which was lying on a Windows machine. So you'll notice a yellow colored box mark as code between PSHR and Active Directory. This was actually a partial script which would, every hour, get all the active list of employees from PSHR, compared with the active users in Active Directory, and then figure out which users needs to be added or which needs to be removed.

Speaker 4: Now, since user ID was created in PSHR, if someone changes the user ID, then it would obviously create a new account in Active Directory. So someone on identity side actually had to manually go and fix the account to ensure that person doesn't lose access on Okta. Similarly, if there's any kind of convergence, let's say a contractor is converting into an employee or an employee into a contractor, then PSHR had a process where you had to first disable a contractor and then hire an employee. Now, again, if this is not done in a timely manner, the person would end up losing his or her access in Active Directory, and hence, Okta. So this script itself had a lot of manual work required even if some of the parts was automated with partial, and then Active Directory, [inaudible 00:22:48] synced with Okta and also with Google. For Google we had Google's Active Directory sync, which is known as GADS, I think it was an open source project by Google. And then, since all our data was into AD, we had to create a contact application on top of AD, which is what people used to access the company directory as to edit their old information.

Speaker 4: Can we go to the next slide, Kelsey? Thanks.

Speaker 4: So, as a first step where we had to reverse the flow between Okta and AD, it was not simply about reversing the flow, but also an opportunity for us to make good use of Okta. And while Okta the product is really good, Okta also has a developer platform side of it, which actually makes Okta much, much more powerful. So we wanted to see that by reversing the flow, can we also have some more custom automation on Okta using Okta developer platform? So the first thing here we did was, since now Okta was going to the master and the PSHR [inaudible 00:23:49] actually had to be pushed into Okta, we wanted to avoid simply comparing PSHR with Okta and then having the exact same architecture we had with Active Directory.

Speaker 4: So the first thing we did was we created a Python based [inaudible 00:24:03] around PSHR. What does [inaudible 00:24:05], instead of comparing PSHR with Okta, it would compare PSHR with itself. So basically every hour it will keep pulling a new list of accounts from PSHR, compare with the old backup, and then figure out what changes might have happened; if there are any user ID changes, if there are some other employment happen. Then that logic dealt with them [inaudible 00:24:27], which were pushed to the Kinesis stream. And this is where then we had the more [inaudible 00:24:32] architecture using some of the AWS services like Kinesis and Lambdas, but these events got pushed into Kinesis, which would then trigger a Lambda, and that will then actually create [inaudible 00:24:42] on Okta as well as Google. Now, coincidentally, at the same time, Okta enhanced their Google integration, which allowed us to push a lot of [inaudible 00:24:50] from Okta into Google. So we were able to use Okta and Google, the combination of these, as our contact application where people would edit their contact details in Okta, which gets pushed into Google and then Google becomes our company directory. And then Okta accounts were then pushed into Active Directory and Active Directory was still used for [inaudible 00:25:11] password.

Speaker 4: Back to you, Kelsey.

Kelsey V: Awesome. Thanks, [inaudible 00:25:16].

Kelsey V: So, as we've said, our shiny new architecture was still reliant on AD to handle authentication for us. The next step in our process was to move this responsibility to Okta. From a technical perspective, this was a one or two click process. The change management side of this was a different beast altogether. As a result of extensive testing, we had already worked out that there was no way for us to get all of our credentials from AD into Okta. The only way ahead was to get every one of our employees, about 5000 of them at that point in time, to reset a new password. Disabling delegated auth would result pretty much in everyone being sent a password reset link, but the challenge was that nobody could access the corporate email in order to get to their link. So we needed to ensure that every person had a specified secondary email address in Okta in order to access their resettling.

Kelsey V: This took us quite a few weeks to achieve. We were sending almost daily emails and other reminders. Finally we got to a point where we have been able to reach pretty much the majority of people, and we'd set a date to go. For various reasons we needed to move our go live date out by a couple of weeks, but eventually we all gathered together online and flicked the switch. It was a pretty nerve wracking experience, but the world didn't end and we'd recruited a team of deputies in every country to help us reset passwords, and we were very glad we did, because over the next week we dealt with a flurry of password support tickets. I estimate that about 1000 people didn't get the message and needed to have a second reset password link sent to them.

Kelsey V: We learned a few lessons along the way, and one of them was about dates. I mentioned earlier that we needed to push our go live date for a couple of unrelated reasons, so we actually went live on September the 25th. We have a 90 day password cycle, and we'd just put the whole company on the same cycle; 90 days after September the 25th. You can do the maths.

Kelsey V: But we've never looked back. Now, in 2020, we've gone from managing 42 on premise domain controllers to only eight, all but one of which are in the process of being moved to the Cloud. Provisioning new starters, de-provisioning leavers, is fully automated and no manual tasks need to be performed at all. And best of all, we're pretty free from the constraints imposed by AD. We can experiment with and adopt all the wonderful new tech that Okta makes available to us.

Kelsey V: And finally, AD is not quite dead yet. There are still two dependencies before we can actually turn it off completely, neither of which have anything to do with authentication. Our last remaining older application, PeopleSoft Finance, will solve itself as a problem by moving to AWS. And then the final dependency, our in-office wifi service, will be addressed through an integration that's being built with our AP provider, MIST, where Okta is going to be used to deliver each ThoughtWorker a pre-shared network key, which will remain valid for the life of their device.

Kelsey V: We've been able to get to do a great deal since as well. We integrated with Workday and moved to an entirely event driven system back in 2018. Our new hire setup, as I mentioned, is fully automated, and new ThoughtWorkers are now given access to limited resources and are able to set themselves up before they actually start work. We're making extensive use of groups and group rules to automate app assignments, and we've developed an integration between Okta, ServiceNow and SimpleMDM that fully automates laptop develop deployment and device management. We've fully rolled that out across the globe earlier on this year. What this has meant is in the last 18 months we've been able to further refine our architecture and make some really big changes.

Kelsey V: So I'm now going to hand back to [inaudible 00:29:49] so he can show you where we are today. Over to you, [inaudible 00:29:54].

Speaker 4: Thank you, Kelsey. So this is how our architecture looks today. So when we were discussing about 2017 architecture, I had mentioned that we wanted to make good use of Okta platform. So making Okta master actually helped us use it in a more powerful way. Here you will notice there are a few new pieces now. You will no more see PSHR because we moved our HR application to Workday. We have something called an event streaming service, which is an in-house event stream we have developed, and there are also some domains in this diagram now. There's a people domain, which is our Workday system, Jigsaw, which is our in-house staffing system, which comes under staffing domain. And then we have identity domain, which is my team's services and also Okta and Google. So the combination of Okta, Google and Identity Lifecycle Service is now what creates an Identity domain within ThoughtWorks.

Speaker 4: And now, instead of integrating Workday directly with Okta, we wanted to have more control on how a concept created on Okta ... we wanted to have our own custom pre-hire flow where if a person is yet to join the company, but is already hired, they are put into a unique pre-hire flow, they get certain access, do their training, probably some more onboarding activities, and then are automatically moved to a [inaudible 00:31:16] cycle when they actually join the company. So then, instead of integrating Workday directly, we were able to define events between these two domains. Now for us, when a person is hired in Workday, it won't be directly going into Okta. Instead, the Workday team and ThoughtWorks has created a wraparound Workday which is going to push a hire event to the company's central event system, which will be then received by the Identity Lifecycle Service.

Speaker 4: Now you'll notice here we are using [inaudible 00:31:48] step functions, which has allowed us to have some custom workloads based on the context in the event. So based on the way we are receiving events, the service is going to preprocess the event, also auto generate the user ID, where previously we had user IDs created in PSHR, now the service is going to auto-generate it and then actually create the account in Okta. Same for a lot of other changes, if there are any changes happening in Workday or our staffing applications, these are sent as events by those domains to our service, and our service then takes care of putting it into Okta.

Speaker 4: Now, as we are updating Okta, Okta also generates event hooks, which is a new service they had launched last year. So we are again using these event hooks to publish identity events back to the company's central event system so that other teams can utilize this. So we could have this unique architecture, but instead of systems talking to systems, we had domains talking to each other, and then, using Okta's platform, they were able to do some unique custom applications here. Back to you, Kelsey.

Kelsey V: Thanks [inaudible 00:32:55]. So, what's next for us? Well, we're not done yet. Not nearly. Our plans for the future include access and data governance in order to drive and support compliance. Zero trust to protect high value resources, data and accounts. Experiments, more experiments, with passwordless authentication. Experiments with differential access for different user types. And of course, working with our digital platforms team to provide secure access to APIs.

Kelsey V: So that's our story. Thank you so much, and I'll pass it back now to Rachel to wrap up.

Rachel: So I would like to thank Chris, [inaudible 00:33:35] and Kelsey for joining us and kind of sharing their story in today's sessions. It's really great to see how companies are really embracing technology and actually looking at different ways to modernize IT. So let's take some time for some Q and A. I'm actually going to hand it over to Steve Chen from product marketing who's going to handle our live Q and A session. Thank you.