Roadmap: Modernizing the Enterprise with Universal Directory
Transcript
Details
Venkatesh Gopalakrishnan: Hi everyone, this is our roadmap session on modernizing the enterprise with Universal Directory. My name is Venkatesh Gopalakrishnan, I'm the Director of Product Management here at Okta. I'm joined by Jason Orlando from News Corp, who'll be speaking a bit later in the session. Jason, would you like to say hi to our viewers today?
Jason Orlando: Hi everyone. Very nice to be here, and thank you very much Venkatesh.
Venkatesh Gopalakrishnan: Great, and just a reminder to everybody, we'll be both online during this session to answer questions in the Q&A window, so please go ahead and enter questions in there as we're going along. Quick note on the safe harbor statements, because Okta's a public company, we may make forward-looking statements during this presentation. All of them are subject to change, you can read this statement in detail at your leisure.
Venkatesh Gopalakrishnan: Quick overview of what we're going to talk about. We're going to start by explaining how we at Okta think about modernizing the enterprise directly and what it means. We'll talk a bunch about some of the recent investments we've made in Okta's Universal Directory as well as our directory integrations in the last several months, as well as some of the investments we're going to be doing in the next six to eight months as well. At that point I'm going to switch over to Jason because they've done a ton of work at News Corp about modernizing their enterprise directory, and it's a really fascinating story, before taking it back and just giving you a glimpse of the future, and how we're thinking about investing over the next several years, and wrapping it up with a few key takeaways for you.
Venkatesh Gopalakrishnan: So, with that said, let's spend a bit of time talking about modernizing the enterprise directory and how we think about it here at Okta. Now, most of you who are viewing today probably have some sort of an enterprise directory in your company. Maybe you have several of them, but in a nutshell a directory is this data store, this single place where you have users, groups, devices and resources they might need access to, all stored in a central location so that you can create a single set of access policies against it. So that your users and your employees or customers, whoever they might be, can easily access the apps they need to or the resources they need to. That's pretty much it in a very, very simplistic way.
Venkatesh Gopalakrishnan: Now, over the last 20 years or so, the enterprise directory was usually dominated by Active Directory or some LDAP directory that usually lived in a data center on-prem within a company firewall. And usually you'd find that the users were Windows domain users. Devices were domains on Windows clients or Windows servers. Applications like Exchange and SharePoint used properties and profiles in the Active Directory pretty deeply. It was used for controlling access to Wi-Fi and network access points, and another neat thing about it is you could always sync it with other downstream systems, like if you had an LDAP directory for some legacy apps, or you could sync it with cloud directories as well for the little bit of SaaS you were doing.
Venkatesh Gopalakrishnan: Now, over time as more and more apps have moved to the cloud, as more and more companies are modernizing, this kind of an architecture, and this is still a simplistic representation because many of you have probably 50-100 domains. This kind of an architecture hit the breaking point of what it was capable of doing for you. And so, as we've moved forward or as we've worked with many of you, we're finding that what most of you are looking to get to eventually is a modern cloud directory, which users are typically going to be provisioned by some HR system out there, or maybe even directly provisioned by contracting or partner companies.
Venkatesh Gopalakrishnan: Devices aren't just going to be Windows devices. A lot of people are using Android phones and Macs and iOS devices to do things that involve work. And servers probably don't live in your basement anymore. They're probably a VM living in some cloud provider like AWS or Google Cloud, and your apps are mostly SaaS. And yes, you will sync your directory with other cloud ecosystems like Azure AD and Office 365, and probably need to sync it to your on-prem AD because you'll probably still have a few Windows servers, and perhaps a few legacy apps or perhaps some LDAP apps still running on-prem.
Venkatesh Gopalakrishnan: But in general, the cloud directory is now the master, and that's the single source of truth for all your users and devices and groups and access management. And we completely realize that getting from where you are today probably, to this modern state is quite complicated, and it's different for almost every customer. It is a journey, and if we look across all our Okta customers, we find that they fall into probably four different categories.
Venkatesh Gopalakrishnan: The first is what we call status quo, where you're still pretty much in that on-prem world. Maybe you're using some SaaS apps, but you haven't really integrated it with your on-prem identity system yet. And typically, this is the state where a lot of prospective Okta customers are in.
Venkatesh Gopalakrishnan: Now, a lot of Okta customers who've been using it for a while have moved to this stage where they're using their on-prem directory as the primary directory in their organization, but have moved to using Okta for SSO to cloud apps and security policies like MFA. This is a very, very common state to be in, in this day and age.
Venkatesh Gopalakrishnan: Now, some customers, and Jason's actually one of them, and this is going to be really relevant to the story he tells, have actually switched to using Okta's Universal Directory as the primary directory in the organization, and users are going to be born in an HR system and provisioned into Okta. And while they'll still be AD and other downstream systems, objects in Okta's directory are actually being synced down to AD.
Venkatesh Gopalakrishnan: And finally, the final stage of this journey is this world where you can finally adopt a full [inaudible 00:06:24] environment without a perimeter and on-prem environment. And in fact, start retiring your legacy directories. Now, customers have gone through this journey take quite a bit of effort and time to get to this stage. We do have quite a few customers who are there, but most of them are born in the cloud. So, if you never had a lot of legacy to deal with, this is definitely the place you want to get to as soon as you can. But I suspect a lot of them are probably not watching today because this is less interesting if you're already in that state.
Venkatesh Gopalakrishnan: So, our investments in the directories area at Okta are all about helping you move down this journey, move further to the right and modernize your directory infrastructure. And we're thinking about it in two different areas. The first is about connecting to your existing directories. A lot of our investments are helping you build that bridge and get you over to the next stage of this game. And the secondary investment is around enhancements that help make Okta that modern cloud directory for you in the cloud. No matter how complex or large of an organization you are.
Venkatesh Gopalakrishnan: So, let me dig into those two areas with our investments and roadmap. Okta connecting to your existing directories, and then becoming your modern directory in the cloud. So, jumping into the first area, if you're integrating your existing directory with Okta today, chances are if you've got a lot of AD domains, you're probably using our AD agent. If you're an LDAP customer you'll be using LDAP agents. We also have a password sync agent, so generally this agent infrastructure is the basis by which we interact with your on-prem directory. So, a lot of the investments I'm talking about in the next section here are going to be about enhancements to these agents. So, I just wanted to set the stage on that.
Venkatesh Gopalakrishnan: One of the first things I'm going to talk about is you're going to notice if you're in preview right now or perhaps in one of our early sales and production that we started rolling out a new management experience for our AD agent. And there's a couple of neat things about this, particularly if you're an existing user you'll notice it. The experience is going to be a lot simpler and more intuitive, but more importantly, it's going to be just like all the other apps we have for provisioning users including LDAP. We certainly heard a lot of feedback that our AD experience was very different from everything else. So, we're updating it, we're revamping it, and I think many of you are going to like this. I certainly do.
Venkatesh Gopalakrishnan: Another thing we're going to make a lot easier in the next quota is the ability to demaster Active Directory users in bulk. Right now, if you wanted to take an Active Directory user and make him an Okta master user, it's a pretty involved process. Particularly if you have a large number of AD domains. Some of the enhancements we're going to do are going to make it a lot easier for you to search for users across multiple AD instances. Just select the ones you want, click a button and then an async job kicks off and starts demastering them and making them Okta master users. So, a pretty hands-free approach with just a few clicks. I think a lot of you who are looking to get to the third stage in the maturity curve I showed are going to really like this one.
Venkatesh Gopalakrishnan: Now, for those of you who are LDAP users. I think many of you have given us feedback that all LDAP v3 directories do not quite operate the same. And so, we've started adding support for some specific LDAP directories that perhaps have not quite followed the standard explicitly. We recently in the last six months added support for eDirectory, so customers of eDirectory can now integrate with Okta with our LDAP agent as well as Oracle's ODSEE directory. And in the next couple of months we're going to add support for Oracle Unified Directory, OUD. And so, if you're using that in your organization, you will soon be unblocked from integrating your existing directory with Okta's universal directory. Pretty excited about that one.
Venkatesh Gopalakrishnan: And throughout the course of the year, we've been making more and more enhancements to our LDAP agent. Primarily just achieve some level of feature parity from what we have with the AD agent. So, things like provisioning, admin-driven password resetting, incremental imports are all things we've had for quite a long time on our AD agent, but over the last year we've been progressively adding these kind of things to our LDAP agent as well. And then in the next few quarters we're going to add support for password policy management for LDAP servers as well. So, you'll have commonality between how you can manage password policies on LDAP as well as AD. Pretty cool stuff.
Venkatesh Gopalakrishnan: And then performance. This has been a big one for many of you. A lot of feedback on the realm of performance. One of the things we've done with LDAP particularly in the last year is make quite a bit of improvement to the performance for LDAP delegated authentication. It's now supporting 2,900 authentications per minute. That's a 600% improvement from where we were about a year ago. We're also working on right now a bunch of improvements to increase import speed. So, look forward to the ability to run parallel import streams or set it up such that it can automatically pick up after failure. We think many of you who have very large user populations are going to like that one.
Venkatesh Gopalakrishnan: So, that's the overview of all the investments we've been making in our agents. Now, let me talk about some of the investments we're going to be making in the core directory itself. Particularly for those of you who have more complex and larger organizations. So, let me level set, if you're not deeply familiar with what Universal Directory is, when I talk about Universal Directory, I'm talking about a high-scale cloud directory that has users, devices, groups and policies in it, with a bunch of interfaces which you can use to interact with it.
Venkatesh Gopalakrishnan: There's an API, an expression language as well as our LDAP interface for legacy LDAP apps. And what this thing is, is this foundational piece that pretty much is the directory for every feature we have at Okta. So, it's a pretty core component. One that we take extremely seriously for obvious reasons.
Venkatesh Gopalakrishnan: So, our ambition with Universal Directory as we make these investments is to make it that single source of truth, and get to place where instead of syncing from AD and LDAP directories into Okta, you'd be using Okta as the source of truth and syncing out to your other directories. And syncing to provision apps in the cloud, and syncing inbound from an HR system where these users are probably born.
Venkatesh Gopalakrishnan: In order to achieve some of the things we want to, we've had to spend a bit of time digging into the core UD architecture and changing some of the assumptions we made when we originally built it. One of the most important assumptions that we've removed is this architectural construct that assumes that every single object in the directory is a human user. And we made a bunch of rearchitectures that made objects more generic. So, that's why if you've looked in UD today, and you're using something like Okta Device Trust or the new Okta devices platform that's being talked about at Oktane this year, you'll notice that you can actually see devices in UD as well. And that's because we've changed the underlying structure to treat objects as generic things.
Venkatesh Gopalakrishnan: One of the nice things about this is that as we go forward it will make it a lot easier for us to add other object types very quickly and easily. At some point in the future you might be able to even define your own object types in the directory, and I'm really looking forward to that day. Now, another thing that this sort of change makes easy for us to do is a feature called user types, and I'm really happy about this one. It's in preview right now, and it's rolling out into production as GA as we speak. But what it lets you do is actually define different types of user objects in your tenant or in your organization. It's particularly handy if you have groups of users that come from different places.
Venkatesh Gopalakrishnan: A quintessential thing to do with it is to have different user types for contractors, partners, and full-time employees. But if you have different divisions in you company or maybe you merged with a few different custom other companies, where the directory structure and the attribute sets for users were completely different, this helps you actually import them into Okta, and not have to worry about the fact that you have to normalize attributes and user profiles before doing so.
Venkatesh Gopalakrishnan: So, it's pretty convenient, and then user types are also searchable. And later in the year we're actually going to make it possible for you to create access policies based on user types. So, we're really looking forward to that. I'm going to show you a little bit about how this works right now briefly. So, if you want to actually create new user types, you just go to the directory profile tab, and here I've created contractors, partners, full-time employees, and I can create a new one. We'll call it seasonal worker user type, and that's really all it takes to create a new type of user in the organization. And if I go to people now, I can actually search for all my users based on these user types. I have a couple of contractors defined, a few partners and a bunch of full-time employees.
Venkatesh Gopalakrishnan: Now, you can also change user types for users. So, in this case I'm going to select a user Chad Marshal, and we're actually going to change him from a contractor to a full-time employee. So, let's see what that looks like. Now, because profiles are different for each user type, you can actually create a mapping and do a conversion process in case you have a whole bunch of different attributes for each of these user types. But just do that mapping, click a button, and all of a sudden, Chad Marshal is now a full-time employee. And if I go to full-time employees, I can find him in here.
Venkatesh Gopalakrishnan: So, pretty neat and convenient way to do that. As I mentioned we're also working on access policies for user types. In this case I've created a policy for contractors where I have to require that every contractor signing in does an email as a second factor in order to sign into my system. So, that's something we're working on that should show up around Q4 timeframe. So, really happy about some of these developments on user types. I think it's extremely powerful. I urge you to go check it out.
Venkatesh Gopalakrishnan: Now, as we move forward, before I hand things off to Jason, I just want to touch on one little topic, which is some enhancements we're making to the LDAP interface. I know a bunch of you who are listening today are very interested in what we're doing here. For those of you who don't know about this, the LDAP interface is a great option if you're looking to migrate legacy apps that are using LDAP directory on-prem, and just have them use Okta's directory in the cloud directly through this LDAP interface. For those of you who have been looking forward to these features, we do plan to add AD and LDAP group support and expose those groups through the LDAP interface roughly around Q3 of this year.
Venkatesh Gopalakrishnan: And then we're also going to add specific sign on policies for the LDAP interface in the later part of the year. So, look forward to those. We've definitely received a lot of feedback since releasing this feature last Oktane about it, and so we are making enhancements there as well.
Venkatesh Gopalakrishnan: So, enough of this lovely list of enhancements I've been talking about. We do invest, and we continue to invest in all these areas around directories, but I think now to make things real, I'm going to switch over and have Jason tell you what they've done over at News Corp to actually take their directory infrastructure and modernize it using some of these concepts and constructs I've been talking about. So, Jason, take it away. We're definitely looking forward to hearing what you have to say.
Jason Orlando: Thanks so much, Venkatesh. So, hello everyone. I'm very grateful to be here, and it's more pleasure to share our journey as it pertains to Okta and this transformation that Venkatesh has been describing. I'm Jason Orlando, Senior Manager of Identity and Access Management teams, and the DISO team at News Corp Technology, which is part of News Corp, which is a global company I'm sure that you have heard of. These are some of the brands that are part of News Corp, and globally we have 25,000 employees spanning across 18 countries.
Jason Orlando: So, a little bit about me. I've worked at News Corp since 2004. I've been a .NET developer for the past 10 years, and mostly with creating internal corporate applications. About five years ago I moved into management supporting enterprise apps, and about three years ago, I began working on SaaS apps, including Okta and Slack. And personally, I was raised in New Jersey, have two kids. I've been on Keto for over a year, which I really enjoy, and my favorite sports are skiing, hang gliding, hiking and running, which I think is great to do especially in this current climate. So, that's me, there's my kids.
Jason Orlando: All right, brief history of Dow Jones and News Corp. So, I actually joined News Corp as part of Dow Jones. Dow Jones was then acquired in 2007 by News Corp. We began offering shared services to HQ and to a small set of other business units, and what we found at this time was that our infrastructure was highly siloed. Each BU had their own staff, their own contracts, their own infrastructure, and their own processes and standards. Despite those challenges, initial results were promising and News Corp had a strategy in mind where they wanted to identify areas of excellence across the business units, and then scale out their practices and procedures to all the rest of the BUs. That strategy was expected to improve service and also drive down costs.
Jason Orlando: So, by 2018 we find ourselves much farther along on that path. News Corp has actually taken steps to centralize the IT organizations across all those BUs and it created News Corp Technology, which is now my direct employer. Originally, we were servicing North American BUs and then just in 2019 we started servicing the rest of the globe.
Jason Orlando: So, visually, this is the problem we were trying to solve. We had customers who were in separate business units with no common identity management systems or even network connectivity, and we needed to figure out how to get these users to be able to collaborate together. And we had numerous challenges before One Okta, so notably most applications would only support a single IdP. That forces us to find a way to allow users from other Okta environments to connect to applications that we had a SAML binding to since they were not able to create their own.
Jason Orlando: Some of these applications we had no choice. They had to be centrally managed, and they had to be available to all News Corp users. The early shared apps that had this requirement were mostly apps that we had to massively deploy due to regulatory reasons. So, if you think about things like SOX, that was the primary driver for some of those early apps.
Jason Orlando: And so, how did we connect those apps early on? We used SAML Federation, but SAML Federation has a couple drawbacks. It's not that seamless. It's a bit time consuming to add users from the remote side. Some of the staff that were creating those accounts and trying to push them across our instance, they weren't in our time zone. There were significant delays sometimes in getting a user access to the applications. And then SAML federated accounts, they sit in our instance even if that user's been offboarded on the remote side.
Jason Orlando: What else? The other challenges that we had here were that sometimes the staff on the remote BU, they were not even on the same ticketing system as us. So, it was still a little bit hard to track these requests. They were all over the place. We had to largely use email, since there weren't these common platforms at the time. So, there were many challenges. Some of the other ones of note, corporate compliance standards, they were not standardized. We had no standards around sign in policies globally, for things like session length or other requirements like MFA varied by view. So, in essence, each business unit was really rolling their own.
Jason Orlando: How to fix this? We looked at three alternatives, and those were federated SAML, Org-2-Org, which is an Okta feature, and we had the option as well to consolidate to a single Okta tenant. When we looked at the positives and negatives of consolidating to a single tenant, we've really found that the advantages really outweigh the negatives. We really just saw the ease of divestiture as being the only strike against One Okta.
Jason Orlando: And then we analyzed the end-user experience, and what we saw there was that, yeah, there would be some changes for the business unit. For example, HarperCollins, they had their own Okta instance. They had their own branding on top of that instance, they had their own domain. There were going to be changes there that users would not be oblivious to. So, it was still thought to be a positive thing to centralize even in light of those changes. We think one of the more significant ones we've had to with MFA when we actually switched the user over to central Okta we'll have to configure MFA again. It's not just the fact that they're switching URLs. They do have to go through that setup process, but it seemed to be a worthy sacrifice at the time.
Jason Orlando: So, here are some of the technologies that we leveraged to accomplish our goals. Notably we were Okta's IDP Discovery, Okta Org-2-Org and Okta's APIs along with our own custom code to assist. We also leveraged Okta professional services through the initial part of the engagement, and they were quite helpful in getting us started down this path.
Jason Orlando: Here are major phases of the migration. So, we actually followed this process for each BU, we've done this several times as we migrated more and more of these Okta instances into our central Okta. The three high-level steps that we followed were, first, connect to their AD, then we adjust sign-in policies for their users. And then finally, and most importantly, we made sure that we could recreate the user experience on central Okta that's familiar to the user that's actually switching and joining the central Okta instance. We didn't want the users to have to rerequest all the applications that they had access to in the old environment all over again.
Jason Orlando: The first challenge we needed to deal with was how to allow users to continue to use SAML bound applications on their old Okta instance, while they're actually signing into the One Okta [inaudible 00:27:54]. This is needed because building the applications actually requires an action by each app admin to rebind the SAML of that application. It would be extremely difficult to coordinate this with a big bang approach without impacting business users in some way.
Jason Orlando: What are our options there? Take a long outage, potential outages over the weekend. At News Corp we have a news cycle that runs 24/7, so we have to be really conscious about minimizing any type of downtime or impact to users. We had a solution in mind here where we could leverage Okta Org-2-Org and use bookmarks on central Okta to allow the user migration to occur separately from the application migration. And this would allow the project to progress in stages that were distinct, and mostly not disruptive.
Jason Orlando: To solve these challenges, we first needed to gather data about both environments. We pulled user, group, apps and assignment data from each instance, and stored it in a SQL database using PHP script as our ETL mechanism. So, first we pulled data from the News Corp Okta instance, which was the One Okta or central Okta we call it. And then we pulled the same information from the News UK instance.
Jason Orlando: Here's the snapshot of what the environment looked when we started. So, you have News Corp Okta on the left. All these had several connections to other systems such as Workday. I'm not going to show that here, it's really not relevant. But if you look on the right you have the News UK instance which is bound to AD. There was also an Org-2-Org connection between the two Oktas that we're going to leverage later on. It's not shown here, but it was there. But that Org-2-Org connection, it doesn't allow us to see all of the users. At least we weren't pushing all users from the remote side onto central Okta. We only pushed an account that needed to [inaudible 00:30:00] on central Okta for access to a particular app, and all the rest were left off. They were only on the remote side. And we also weren't pushing the vast majority of groups from that environment.
Jason Orlando: So, to get things moving, the first thing we had to do was deploy AD agent for newscorp.okta.com, but in the News UK environment and connecting to News UK Active Directory. And this would allow News Corp Okta to read in and create all the same users and groups that were present in the remote environment. So, in other words, we now have a bunch of duplicate accounts and groups across both environments.
Jason Orlando: After importing all the users from the remote AD environment, the next task for us was to recreate the applications the users would have access to. However, as mentioned, this was challenging as rebinding SAML for several 100 apps would be a large undertaking lasting potentially weeks or months. So, to ensure that a user could continuously access their application after they were migrated into central Okta, we needed to programmatically create bookmarks which pointed at their old SAML bound apps, through the Org-2-Org connection, which was always established between the two environments. This is where we leveraged the application data we pulled earlier into the SQL database via the API.
Jason Orlando: We programmatically moved through this data, creating a bookmark that pointed at the remote destination app, and we slightly adjusted the names in some cases to just make sure that there wasn't duplication with the apps that we had locally at the time.
Jason Orlando: Here's some detail on what we created, just to think through each app. The bookmark at the bottom you'll see that it's highlighted that the relay state is what gets the user over to the remote SAML bound application. That's actually the destination that the bookmark's referring to. So, that's leveraging Org-2-Org. The user doesn't need to sign in on the remote side. They're authenticated and passed through, and then they actually show up in the app, and it's seamless to them. They won't see an Okta screen from the remote Okta instance. They'll only be on News Corp Okta, even though we're leveraging the other Okta at the same time.
Jason Orlando: So, once all the bookmarks were created, and we went through and created them all one by one using... Well, in a batch really, using a program. But once all the bookmarks were created, we just refreshed our database to get a refreshed copy of what was out there. And so, then we move on to the final step. We have users, we have groups, we have bookmarks created, and now we need to do assignments. So, to actually create the assignments, we have to figure out what people were assigned to on the remote side. So, we actually needed to know what group assignments to create, and what individual assignments to create.
Jason Orlando: So, here's us doing the mapping, and this is what it looks like in practice. So, since these environments were constantly changing, we did pull this data a couple of times, and we would audit and follow up on any gaps. We had fields to track this, and this relies mostly on VLOOKUPs. Sometimes there were things like users being offboarded or some apps being decommissioned on the remote side, we needed to just follow up with the remote Okta, and then make sure that those were expected. But it really wasn't that hard. Once we got down to understanding what this mapping was, then we could just create the assignments in bulk based on the sheet.
Jason Orlando: This diagram just gives you a quick look at the overall user migration process. The prerequisites are in gray and the actual user migrations are in blue, and the comms as well. You might notice the fact that we didn't migrate all the users at the same time. We did do this in stages because we like to do our [inaudible 00:34:20] and final approach to mitigate risk.
Jason Orlando: And here's just a glimpse of what our comms plan looks like. We use it to communicate potentially to users, and wanted to make sure that they had chronology of what was going to happen. What user experience change would be, and how to get help in case they had an issue.
Jason Orlando: So, we've recreated the assignments, and we've recreated the users and groups and everything. At this point the apps are still relying on the bookmarks, and we need to actually get them moved over. So, this begins the application migration stage. The previous setup was essentially a stopgap, and we have to now do the hard work of rebinding all those individual apps on central Okta. And the good news is we could do this in a manner that's not disruptive to users. We just pull the bookmark away, rebind the SAML and then assign that SAML bound app to the user at the same time. And we can do this late at night or... It's a very quick change to flip one app, and that was how we minimized the impact. Just do one app at a time in a time period where it's not disruptive to the users based on the apps they need.
Jason Orlando: After we'd migrated all the apps then there's one thing left to do, which is we actually have to rebind their onboarding process for Okta users. So, this actually is going to vary across BUs, so some BUs would manually create the users in AD, others would sync them from an HRMS system. But whatever it happened to be, whatever that process was and however it connected to Okta. We migrated that process over to central Okta.
Jason Orlando: So, here's what things looked like during the app migration phase. So, we have the AD in the lower right connecting to One Okta and also the News UK Okta. And once we migrate their HRMS, the News UK Okta is no longer being used. Users aren't signing into it at that point. And finally, we'd magically delete the remote Okta instance. We've got the users flowing through from their HRMS, we then push their user accounts from Okta to AD or any combination of those two, and it was one Okta instance. So, that's really success for one business unit in the project, and we just repeated that over and over.
Jason Orlando: Centralizing Okta has provided many benefits to News Corp, to both the core organization and to our business users in each business unit. As part of the centralization we were often converting gr using AD mastered groups for entitlements to using native Okta groups. And this allows us to leverage Okta rules to manage membership and the automation it provides gave their staff many access requests. [inaudible 00:37:43] it provides them access to [inaudible 00:37:46] in a much quicker manner, so that's been a big change for us.
Jason Orlando: Furthermore, by managing the application centrally, we're able to add or remove any user from any app to any connected environment from a single interface. We don't need to connect into their VPN and manipulate their AD to create a user or to assign a user to a group. It's much easier to just have one place where all this work gets done. We can manage it from a single team. So, I think thought major benefits are faster application access, better collaboration between business units, and consolidation and simplification of our environment.
Jason Orlando: Here at last is a complete picture of all of our users in central Okta broken down by business unit. It includes all consultants, employees and other accounts such as admin accounts and service accounts.
Jason Orlando: Here we have two users from two different BUs just assigned to the same application. And here we have two different sets of users from two different Active Directory groups assigned to the same application leveraging IAM processes that were already in place. Sometimes we didn't overhaul their process for providing access. Sometimes that was problematic. Here's a picture of the growth of one Okta over time at the very beginning back in 2015. You can see that there were spikes in activity as we migrated in specific business units.
Jason Orlando: The bottom line here is that we wanted to get away from the siloed model and centralize our team's processes and applications to improve efficiency. Okta really gave us a very convenient intermediate state where we were able to leverage the existing on-prem environment, while over time more and more applications are migrating to the cloud and starting to us modern provision and mechanisms such as [inaudible 00:39:58]. For those, we just moved straight to that mechanism, but for the legacy stuff, that's all supported as well because we still have the connections down to AD.
Jason Orlando: We found during this project that Okta's API was very valuable. It allowed us to manage the change at scale, and we think Okta provides a desirable future state where we might be able to fully eliminate AD, and just rely on 100% cloud-based directory. I think being realistic that's a slow transformation that's going to happen over time as we sunset some of these legacy applications that have dependencies on AD and couldn't be moved to Okta, but that's something we see as a desirable end state.
Jason Orlando: And here's just a couple of the projects ahead of us. So, consolidation of multiple user accounts. So, in the past we had duplicate accounts across two different, or even more AD domains for the same users this give them access into that environment. We'd like to consolidate those accounts into a single identity for each user. We also are scaling out leveraging Radius Okta to manage entitlement to servers using Radius. And we're solving IAM issues and rolling out more unified processes across News Corp. And finally, based on the concept of One Okta, we're now consolidating our HRMS systems into a single HRMS. So, that's actually going to be One Workday, and we're looking forward to that because now we'll have a single source of truth for all HR data across the organization.
Jason Orlando: Thank you.
Venkatesh Gopalakrishnan: Great, thanks. Thanks a ton, I mean, Jason, that's a fascinating set of information and detail about how you've modernized the directory and gotten to a place where Okta is fast becoming, if not in many cases the center of gravity in your organization.
Venkatesh Gopalakrishnan: So, I think moving on from there, I'm going to talk about some of the things we're thinking about working on at Okta in the directories area over the course of the following few users. Ultimately at the end of the day, our vision is the be what we are to Jason's organization for more and more of you out there, and our vision is to build Okta Universal Directory into that modern cloud directory that is the identity system or record for all of you.
Venkatesh Gopalakrishnan: So, in that vein, our long-term investments are really focused on dealing with more and more complexities in your organization, and making it easier for the most complex and the largest organizations in the world to be able to move to Okta. And then the flip side of that coin is to work on scale, because we recognize that complex organizations are often quite large and have many scalability problems that we're going to have to deal with as we move forward.
Venkatesh Gopalakrishnan: So, digging into those areas, when I think about the investments we're going to make in the following years around complex organizations, we definitely want to make it easier to model your orgs hierarchy and relationships in the directory. You can imagine these will be very convenient when you start using modern approval workflows for example. For example, if you needed to automate sending an approval to a manager or things like that. And we're definitely going to be investing in things like group profiles, because they just give you more attributes and more things about groups that you can search for and create, and allow you to search by organizational constructs or using groups, and delegate group administrations to individual divisions and departments or subsidiaries.
Venkatesh Gopalakrishnan: We know that's very hard to do today, several of you are working around it. Our intention is to make that a native capability for all Okta customers. And then in terms of scale, we definitely want to expand our search capabilities to be able to search against more attributes, more profiles and more group criteria, and leverage hierarchy to make searching more efficient in the directory, as well as being able to filter search results and use things like API projection because we recognize that just returning the full object isn't always the smartest idea in the world. We think we can use these kinds of concepts to reduce payload size and increase response time, and just make this thing scale a lot better for your organization.
Venkatesh Gopalakrishnan: So, I hope that gives you some of the ideas of the areas we do plan to keep working on as time goes on. To wrap things up, I would like to just give you all a few takeaways. The journey is not a flip of a switch as you know by now, both by listening to my presentation as well as Jason's story. And so, I'm going to ask all of you who are thinking about moving down this path to go and engage with your engineering teams, engage with Okta's professional services or whoever you might be using to figure out where you are in this directory modernization journey and start charting your course forward.
Venkatesh Gopalakrishnan: And then start charting your course forward. And then when you're doing that, check out some of these new features we've been working on recently and that we're rolling out into production over the next few months. Things like the LDAP directory support or performance enhancements we're making, or demastering AD users and user types for example. And then use Okta Ideas. It's a totally revamped Okta Ideas portal that you can use to give us feedback and tell us what you think we ought to be investing in to help you.
Venkatesh Gopalakrishnan: So, a quick plug there on Okta Ideas. If you haven't seen it already, go check it out. We have a PM team looking at this every day, so your feedback is really appreciated. Check it out for sure. And then we have other sessions going on at Oktane, even if they're done in the past, you should be able to see them on recording around related topics like hybrid IT and how to rethink Active Directory, so check those out for sure.
Venkatesh Gopalakrishnan: And with that said, we do recognize that it's a difficult time for many of you out there, and so, we appreciate the time that you've been able to spend with us at Oktane this year. Thanks also to for listening and stay safe wherever you are.
A modern enterprise directory is essential for organizations looking to move to the cloud. Continuing to use legacy directories to manage access in the midst of digital transformation has inherent limitations. In this session we’ll share Okta’s vision for the modern enterprise directory and provide insights into the investments we’ve made to help customers move further along in their cloud journey. We’ll also hear from a customer about concrete steps they have taken to modernize aspects of their directory infrastructure and the benefits they’ve realized from the exercise.