Oktane18: Future of Directories -- Architecting for the Cloud

Sai Maddali: Great how's everyone doing today? Welcome to Oktane 2018. This is a big room. Initially I think they must have thought I'm going to talk about Bitcoin mining but we're going to talk about directories. And I don't think there's any other room in the entire world that actually cares about directories so y'all are the coolest group I know. So welcome, and I'm really excited to talk to you guys about our directories and directories roadmap today. And I also have a PAC session with Mike. Going to talk about how he moved to the Cloud and his experience with Okta. Our forward looking statement. So, in the next 40 minutes I'm going to first cover the evolution of a directory, the past, where we are today in the present, and then move on into the future of what we're going to build, how Okta looks at directories, our vision for the world of directories. So as I got started with this presentation a couple of weeks ago I was really curious what Google said about directories cause I live in my own world of what directories are but then I really wanted to see what Google said. So I said, "Hey Google what's a directory?" And Google said something you would expect, right? That it's a book or an entity listing other identifying information about other entities like name, email address, telephone numbers, etc.

And that's how a directory has been for most of history, right? A couple of decades ago when telephone became a thing a directory was the Yellow Pages. Like a simple phone directory that listed out everything about people, organizations, etc., so on and so forth. But when the internet became a thing a directory was something even simpler. It was just a simple key value store that showed everyone within an IRC chat room, for example, right? But over the years as more companies started to adopt internet and computers the real need for a directory service came along and then that's when the X500 data model was proposed. Right?

It was great because it had a good structure for how you can model out hierarchies and org structures. So it was a really good model but there were a lot of implementations for the next decade and nothing really stuck until LDAP came along in 1998 and we still use LDAP today. Right? So we know how that is.  But LDAP was great for its time, right? Because it was read optimized, it had a really good hierarchical structure, and it really provided a great model for you to build out identity in your org. And then right after LDAP was introduced a lot of companies set out on the race to build a productized version of a directory. Netscape was in this race, Microsoft was in this race. Microsoft having the foothold it had in a lot of organizations was very successful with active directory as we know. But something else happened around the same time and that was Web 2.0 and the dot com bubble. Right? Which fundamentally changed the way we consume and deliver software and digital experiences. But it also brought along a lot of challenges with it. One of them was access. So one of the big things that happened around this time was federation, how do we do federated identity, federated access? That started off as Samwell 1.0 in the early 2000's, evolved into Samwell 2.0, and today we're in the world of open ID connect. 

And then one of the things that also happened is the way we deliver software with SaaS, right? And we still live in that world today and we're still going through that transformation. So, it fundamentally changed the way how we look at experiences, how we build experiences for people. As a matter of fact two years ago IDG did a survey where they surveyed 60 executives and asked them, "Hey what are your top digital business priorities?" Not a lot of surprises here, right? Introducing new customer experiences, employee experiences, we know them like including mobile agility.  But what's more curious to me are the first three. Introducing new customer experiences, improving employee experiences, right, and these are all about how do you build and deliver great user experience. Right? And that's what we deeply care about here at Okta, right? Because great user experience isn't just about making things look pretty, it's how can you make things simple? It's about how you can take your 20 to 30 years of complexity and push that into the Cloud and deliver great experiences. Right?

It's about something as simple as a password reset just works. Or something as simple as me being able to create an account on a mobile ap. I can do that within 10 seconds and not have to go through 30 different floats. Right? And we do that at Okta by connecting everything and that's what we think of as a directory. It's the core of how you can deliver a lot of experiences whether you're in an MMA scenario and you have hundreds of domains in AD or multiple ADVAP Servers. You can drop in simple lightweight agents and pull that data into Okta. Or even if you're building a customer application and you're using SQL server or DB, whether that's on-prem in AWS, you can just pull that data into Okta. Same with partners. If you have third party IDPs like Ping or One Login.  Or HR systems. And you can create a digital identity with these within Okta and push that out into various systems. APIs, applications, other services, etc. But we didn't get here overnight, right? Okta started off as a very simple sync agent. You guys must have heard Todd talk about how Okta started off as a company that wanted to enable any company to use any technology. Right? So that's what Okta was. It was simple sync agent that you dropped onto your active directory and we pulled in basic user scheme and groups.

But as we talked to more customers, saw more complex environments the need for a real directory came along and that's how we build UD four years ago. Right? UD had a more defined schema and you could manipulate data using a special language, push this data out into various applications using ON and the deep integrations we have. But as we sat in more conversations, looked at more complex use cases that wasn't enough because a lot of what you can do in UD today is defined by a schema that we define for you. It's a little tight, right? So that really brought up a need for something more open. And so, a lot of what I'm going to be talking about today is how we're investing in making Okta a directory platform so that you can throw whatever you need to edit, and it'll morph to your own needs. New data types, custom schemas, so on and so forth. Whether you're building customer identity, employee identity, whatever that is. Right?

And building something like this isn't easy either, right? You need a lot of discipline and a guiding philosophy that'll take you through making good decisions. So there's three main things that we really care about and the first one is scale. Always on is the mantra that we live by within Okta. As a matter of fact a third of all the testing that we do is about scale and performance. Which is why product launches may take a little longer cause we deeply care about how will this scale to hundreds of thousands of users.  And the other is integrations. All the data that's in Okta is yours. How you bring it up, how you bring it into Okta, and how you push it out is what we care about and it's about making that easier. How you do that, that's up to you.  And the next thing is about flexibility.  This goes back to the story of how Okta's trying to become a platform, right? So that you can throw whatever your schema, your data types are at it and Okta should be able to handle that.  And so, on that note we're going to cover three main topics today. The first one's going to be integrations. Again that deals with how you bring data into Okta and how you push that out. And the other one is UD as a master. What are we doing so that you can use Universal Directory as your main source of truth? And then customer identity, what are we building so you can build applications for your end users, consumers, B to B, whatever that is? How many of you use desktop SSO here today? That's a lot of you guys. Wow. For those of you that don't know, desktop SSO is a flow where you log into an on -prem domain join machine and you go to the browser and go to myorg.okta.com and Okta will automatically log you in using multi-factor authentication.

Now for those of you that use desktop SSO how many of you are excited to get rid of your IWA agents, so you don't have to do any maintenance? Wow so quite a few of you guys. So this feature will essentially enable you to get rid of your any IWA agents and move that entirely to the Cloud so you don't have to maintain any servers on your own but still deliver a great desktop single sign on experience for your employees.  This is in Beta today, it's slated to go into EA in like a month and a half so if you're interested come talk to me after and we can get you set up.

Next, I'm going to be talking about how we are improving our AD agents. And one of the first things is going to be how are we improving our onboarding flows. Today if you're using HR as a master or using AD as a source of truth how you onboard a new user is not the best experience. So we're investing in ways in how we can improve that experience specifically around how do you deliver a password to the end user. Whether that's through an activation link, or whether that's through getting a unique password to the end user, or whether that's through something like employee/manager relationships. 

And headless agent installations. Today if you have hundreds of domains in hundreds of forests and you're trying to deploy the active directory agents across all these domains it's a manual and a lengthy process. So it's very time consuming. And we're investing in tools to improve this process so that if you have hundreds of domains it's easier to install these across all of your domains and forests. 

And on the same note we're also investing in a lot of tools to make automated agent upgrades easier. We have quite a few customers today that still have agents from 2014 and 2015 I think. And that's primarily because they have hundreds of domains and it's really hard to update all of them. And so we're investing in tools that will make this process more streamlined. 

And on the LDAP agent side a lot of you guys asked about Group Push. And this is especially useful if you still have legacy applications or legacy servers on -prem that depend a lot on groups to do authorization. So, this is one of the things that we're going to invest on later this year, or next year depending on how many customers need this. And the other one similar to the AD agent is automated agent upgrades for the LDAP interface.  And similarly, we're also going to invest a lot of time into understanding how we can improve the agent architecture to make it easy for you guys to deploy it. Whether that's LDAP or on -prem provisioning agent to fit your custom own needs for databases or other servers that you might be using. How many of you guys know what hybrid AD join, or AD join here is? A few of you guys here. Now how many of you guys are full in on Windows X tab things like Windows Hello? That's a couple of you guys too. So, hybrid AD join is a functionality where you have an on -prem domain joined Windows machine and you want to register that as your AD service to enable things like Windows Hello and contextual device access. And if you're using Okta as your federation provider Okta needs to take care of submitting these device claims from the on prem AD into universal AD. And that's one of the things that we're currently building today.

And next I'm going to talk about UD as a master, what are we doing so that you can use UD as your main source of truth? One of the first things that we built earlier this year is LDAP interface. Did any of you guys were in the Beta for LDAP interface? A couple names, cool. So LDAP interface really gives you the ability ... it exposes our UD as an LDAP server. So, if you have any on -prem applications or things like WiFi or any other VPNs you can connect that natively to Okta to do things like simple bind and simple authorization.

By simple I really mean that if you have complex authorization needs to say only users in group A, B, and C can access this application. The LDAP interface can't do that today. That's going to be one of the first things that we'll be building over the next few months is introducing the ability to do complex searches this way you can use that for more complex authorization needs.

And on top of that we're going to build custom LDAP views and schemas. So, if you have LDAP servers with custom schema that you have on -prem that you've been using for a lot of years with this functionality you can define what that schema is within Okta natively and move all these identities into UD.  And on top of that we're also going to build posic schema. And that really gives you the ability to log into your Linux servers or MacBooks. So, if you have Linux or any MacBook’s on your premises and you want to use Okta to log in to keep that password in sync you should be able to do that with posics.

And CSV as a master is also one of the things that we're going to introduce soon. As a matter of fact that's one of the things that we're working on. If you have your HR team that usually takes care of onboarding all they can do is export a CSV and import that into Okta and Okta will take care of pulling those identities and then you can do the rest of what you want to do with all those identities. And the next is linked objects. This is one of my favorite feature because Okta couldn't do that until now. As a matter of fact we're building this out. With this functionality you can actually pull object relationships from various sources like AD or Work Day, and then provision that out into various systems like G Suite. And if you're building a customer application, for example, if you're building a banking or healthcare application you can model out employee/employer relationships, you can model out family relationships, you can model out doctor/patient relationships with these objects. Where you can create two objects, create a link, and then link them. Create a link in policy, things like that. And the next is UD sensitive attributes. Today you can create multiple attributes within universal directory but there's no way to mark them as sensitive. And sensitive is anything that's not logged or searched. You can't search it or log it. Right? And the only user that can see that data is an owner of that data or someone like a super admin. A good example is social security number. You can pull that from sources like Work Day or HR and mark it as sensitive via SAML and you can't search it and we won't log it either.  Soon you'll be able to do this natively within Okta where you can create an attribute and mark it as sensitive both via the API and the GUI. 

And on customer identity we're going to build a lotta things around group profiles. So today let’s say you're building an application and you're using groups or rule-based access control to do authorization within your application. There's not really a good model to do that because when you create a group all you can do is assign a name and a description to it. But soon you'll be able to add attributes and then use those attributes within your ID token and enforce whatever authorization control that you guys want to enforce. And like I mentioned there's a lot we're building around how can we make universal directory into a flexible, neat platform that you can throw whatever you need to at it so that it can morph to your own needs. So one of the first things that we released earlier this year is Enum support. So you can now define an attribute and then make it an enumerator and define what the valid values are for that. So, let’s say you want to collect tee shirt sizes from an application you're building. You can say tee shirt size and you can define what the valid values like small, medium, large, extra-large are and Okta will take care of how that's displayed to the user and how that's enforced.

And the next thing is we finally don't have first and last name requirements. Are you guys excited? Woo hoo. All right. So now you can actually create someone like Baby Groot with an Okta, right? Cause traditionally you couldn't create ... for example if you had services you couldn't create that cause we required first and last name. So we're moving to this model where it's becoming more generic for a user type, a device type, a service type, whatever that looks like.  And one of the next things we're going to build is any attribute as log in. Today we have a log in field but you can only really map email to that. And you can't use any other attributes to build or authenticate a user name. So if you're building an application where you want to enforce telephone number as a main log in attribute you can soon do that. Telephone number, account number, whatever attribute that you want to use within your D.  And we're also going to build the functionality to have unique attributes within Okta. So today if you want to have a unique attribute within UD, something like account number, social security number, to make sure that it's not replicated you have to build a lot of that logic yourself. But soon you can define an attribute and then say, "Hey this is a unique attribute." And Okta will do all the heavy lifting of how we can enforce that within Okta.  So, as you can see a lot of what we're going to build is to make sure-

Sai Maddali: So, as you can see, a lot of what we're going to build is to enable you guys to build good experiences for your end users, without having to think about, "What directory should I use? What logic should I implement in my application?" Whether you're building an application for your customers, or whether you're trying to search for employees, that's a model we're moving towards. And a lot of what I talked about here is also how Mike Anderson from CROSSMARK, envisioned for his own organization. So, I want to invite him on the stage to talk about how implemented Okta at CROSSMARK and his experience with moving to the cloud.  So, one cool thing about Mike, is a couple of months ago, I was running the LDAP interface beta, and I was trying to get on a call with them to see what their use cases are. And turns out, on the call, was this guy named Mike Anderson who was the CIO of this 40 thousand person company. And I was blown away because he was so in the details about what he wanted to implement within his own company. So, you're going to hear from the man himself. Thank you. 

Mike Anderson: Thanks a lot. Appreciate it. 

So first, I'll give a little background. How many people have heard of CROSSMARK before? Yeah, it's usual. One or two people. So, just for those that aren't familiar, I think it'll help in giving context. We are a multi-national company. We've got about 30 thousand employees. If you look at our website it would say that we provide outsourced services to the retail and consumer goods market.  What that means to most people, and the way I correlate that is, if you go to Sam's Club, and you get a food sample, the person's that handing you that sample is our employee. If you see people in a Walgreens or a CVS, or Rite Aid, and they're not wearing a badge from one of those retailers, and they're doing things at the shelf, that's a CROSSMARK employee. If you go to Firestone 500 series or indie car race and you go to the fan experience, those are our employees putting the fan experience on.  We're all about creating these connections in the market directly with shoppers and consumers. The challenge it brings that, from a CROSSMARK standpoint, is we look a lot like a professional services company, from the way the technology we have to deploy to our people. But at the same time, we have the turnover rates you would see in retail. And so if you look at a lot of retailers, there's higher turnover rates because you're paying, you have a lot of part-time employees, and with that becomes a lot of onboarding and offboarding. 

When you think about CROSSMARK, we've got over 30 thousand people. We hire on an annualized basis, over 20 thousand people. Every year we're having to onboard and offboard 20 thousand people into the company as we think about our part-time work force. And that's common with any retailer. But then you bring the application portfolio and the application stack like you'd have in a professional services world, and it brings in more complications. And so, for us, identity and provisioning is core to what we're trying to do. A few of the business problem we were trying to solve when we went down this path. First off, I came in five years ago. We did the assessment of where are things at. At the time, we were largely, build it here, it's got to be built in Microsoft, and it's got to run in our data center. And we basically said, "That's not the path we want to go." And so, we embarked on a cloud strategy that we unfolded over the following three years. And as we sit right now, we're about a year away from having all of our applications in the cloud.  As part of that process, we wanted to get our directory in the cloud as well. So when we looked at our expense, we were spending a lot of money on our Microsoft Enterprise Agreement. As many of you are probably familiar with that if you work in the Microsoft licensing side. And with that, you have Core CAL licensing you have to get for all those people, if you're on Active Directory. And so, as we looked at that we said, "We got to get that directory out of our data center and into the cloud somewhere, so that we're not having to pay for Core CALs for all of our field people that have this high turnover rate." Because a lot of times, we're over paying for the software we needed underneath an enterprise agreement. And so, that was part and parcel to that process.

I already mentioned the onboarding and off boarding, as you can imagine, provisioning all those applications, getting people into apps as quickly as possible, most people that work a 12 to 15 dollar an hour job, if they don't get hours immediately, they go find another 12 to 15 hour job. And so, that cost that we sunk into drug screens, and background checks, and recruiting, gets thrown out the window, and we start over again hiring someone in that same market. So, it's critical that people get access to applications as quick as possible.  And then the fourth one is we've seen, if you think about our workforce, we're not dealing with the most sophisticated workforce in some cases. And we have a very diverse work force. And with all the phishing attacks and things like that, that have come across over the last couple of years, we wanted to make sure that we had multi-factor authentication and something that was very easy for our people to adopt and use. That was the other business problem we were trying to solve, is how do we address those four key areas? Why did we select Okta? A little history. We actually had gone down a path, when I first came in we were a big Microsoft shop and so, we went down the path with Active Directory, Azure AD Premium, and we implemented that. And we had some challenges there, and so we went back, and retooled and looked at Okta. 

And the reasons we ended up going with Okta as our partner on this, the first one was we wanted to be able to migrate our workforce to a new system without having to do a mass password reset. If I go have to reset passwords for 40 thousand part-time employees, some of which don't log in every week, it's going to create a surge in help desk calls, and my cost is going to go through the roof. And so, we wanted the ability to be able to switch providers of authentication without having to do a mass-password reset. And that was one of the things we were able to do with Okta. And I'll talk about how we did that in a minute. The other piece was around the application provisioning for all those cloud based applications, and all the applications we had on prem as well. We really liked it was a cloud based application for that, versus having to deploy on premise applications to be able to provision could applications, which was what we were looking at in the previous scenario. The next one was around a lot of the geospatial data. That's something that we actually found that we liked as we got into it. And that was, as we started looking at where phishing attacks were coming from, we were able to quickly identify anomalies and behavior for people. If we saw someone logging in to Okta from Russia, we knew, "You know, we don't have any employees in Russia. There's probably something going on there we need to look into." And so, as we would have people that tried to get into our environment, we were able to use Okta to actually go figure out exactly where they went and what they did, from an authentication standpoint. And so, that was a key thing we liked as well. And then it was just from an industry standpoint, there was other players out there that are smaller, that tried to do a directory only, there were other single sign on providers that were out there. But when we looked at the ecosystem that was there with Okta, it really brought a lot to us. Because even in the Microsoft landscape, a lot of times Microsoft would say, "We can do single sign on and samba with anybody, but for provisioning, we don't have a lot of deep provisioning relationships. So, if you can help us broker the conversation with ISB, we'll get that set up for you." And that wasn't in a position that we wanted to be in when we were constantly having to bring our software partners to Microsoft. We wanted a partner that already had a broad network. 

That was one of the things we liked. And in the spirit of being agile, we liked the fact that you had releases coming every week. I joked at lunch today that I actually read the release notes each week and then send them to my team and say to my team, "Hey, when are we going to use this or that, or things?" I'm sure they love those e-mails. The other thing that I always look at too, is when you have a partner in any IT function, is are they a partner or are a vendor? And the difference between those two of those to me is, when you have a problem, your partner is in the foxhole with you. And in any IT relationship with any vendor you never, it's never going to be perfect. You're always going to have issues you run into, everybody's environment's different. One of the things that I really like about Okta during our implementation process is we ran into issues but they were right there with their engineering support to help us work through those and solve those problems. And those are some of the key things that I like and why we picked Okta as our partner. So this is my ill-fated attempt at an architecture slide. So our previous architecture, pretty similar, we had our HR system, we had a bunch of shoestring spaghetti code that actually provisioned people into Active Directory. It was there before. I think when I came in I asked, "How do we make changes to it?" And they said, "I don't know, we don't have the source code to that. The person that wrote that 10 years ago is no longer around and we can't find him." So that, well that's a problem.

We had ADFS going to Azure AD, that was implemented largely around our Office 365 migration that we did back in 2014. Then we had our traditional on premise and custom maps that were wired into Active Directory and then as we went down the Azure AD path before, we had some provisioning for things like Salesforce, Box, obviously Office 365, SuccessFactors. A lot of those were very much provisioning only, it wasn't really the deep permission sets and provisioning you'd want from the application side. And then in this little red box over here, like Jira. Where they didn't support Azure AD, you could do Active Directory on premise, but we weren't going to run Jira on premise. So it didn't really make a lot of sense for us to go down that path. So we had these, kind of orphan systems out there, from an IT standpoint, all of our roadmaps and releases and everything else are in Jira, it's not something that I want people that leave to have access to. And so that created some challenges as well. And a lot of manual process. The other note I would make is, if I looked at our system admin time and where we spent time, we spent a ton of time troubleshooting Active Directory issues because of the collision we'd get around all the new, we'd have the same person with the same name in 15 different markets. And trying to manage folder structures and move people around, and do things to make sure you could navigate Active Directory, we had too many resources up against that. With our new architecture, we basically take our HR data and we actually feed it into what we call PeopleHub which is actually our Salesforce instance for our business to employee applications. I've made a play to get a workday environment set up inside CROSSMARK and it didn't go all the way I wanted it to as far as getting that, and so I said, "Okay, we'll just use Salesforce and build our own single pointed truth for all of our employee data."

That's what we did with PeopleHub. In our process today, data comes from HR, goes into our Salesforce alert where we built up custom objects that model all the user data so that we can lock down the permissions. That feeds directly into Okta and then Okta actually writes back and creates the user account in that same Salesforce instance from the back end from a provisioning standpoint. Now all of our applications are provisioned through Okta. We still have Active Directory, which I've listed up here because we do have some legacy on -prem Apps that we have to use Active Directory for. And that's where we've been looking at using UD as an LDAB is actually to use to authenticate against those applications. Some are straight authentication which is pretty straightforward, some of those are reliant on the group structure so some of the dynamic group searching and some of the wild card searches and things like that, that we'll need that will come later with Okta, we'll have those. So again, back to that whole point of being a good partner is, we talked to someone like Sy about what we're doing, they're listening to our feedback and incorporating that in. So I'd encourage you, when you work with Okta, talk to the product teams and share your feedback because they do actually take those and put them into the product. I'll talk a little bit about our implementation, which is probably the coolest part of the story. We signed our contract in December of 2016. We had a hard date coming up in June of 17. And that was when our Microsoft EA was renewing. We wanted to get everybody off of the EA by June of 2017. If you think about trying to cut over seamlessly 30 thousand people from running in a Microsoft world to now running in a largely non-Microsoft world, that was a big endeavor. We had, not only this process in Okta going on, but we also changed out our expense system that our employees used, we changed out our entire internet, we shifted the entire organization to Box for enterprise file storage, we replaced SharePoint. We called this whole thing our PeopleHub Initiative. And Okta was just part of that whole piece. And we had basically six months to pull off the entire project.

We signed the contract in December. In early February, we started implementation. By April, we had single sign on set up and we had a process set up where we were capturing the passwords of the people as they logged in.  We ran a contest for our part-time employees to just log in and set some of their recovery passwords, and things like that, recovery information. We gave away televisions and things like that because it drove support costs down by them putting that information in. We embraced the change management process throughout because you can imagine doing that much in six months, you don't just do a big bang and say, "Guess what? Your system's all changed!" We actually employed a lot of change: management methodologies, and marketing methodologies, things like drip marketing campaigns to our people to tell them the things we were doing. So we went live with SSO in April. At that point, Active Directory was still our master, and then in mid-June we actually cut Active Directory off as our master and made Universal Director our master for all of our employees. So now, we just provision Active Directory for people who need access to those on prem applications or things that require it.

Looking at the process, the full from what I would say, contract signing to you go live was six months, for 30 thousand employees. That was a pretty big feat that we pulled off in that process. One of the things that I'm really excited about is that when we did that process, we rolled out a knowledge base for our employees. We've had some in the past that were failed attempts, but we rolled out a new knowledge base and we saw our help desk calls go down from about 10 thousand calls in a month to about six thousand inbound calls a month to our help desk through that whole initiative and process. It's not like we rolled this out and all of a sudden help desk calls spiked up, we actually saw a lot of improvement there. Now our core project team was five people that worked on the identity and provision piece, so it wasn't a large team that was working on this project. So we were able to get a lot done with a small number of people. A lot of times when you have smaller teams, you can be more nimble. You can be quicker because you don't get caught up in all the red tape and meetings around trying to make decisions with too many people. So we were able to move very quickly on that side. The next thing is some of the benefits we got from this. We actually cut our Microsoft spend in half. We were spending close to four million dollars a year. We cut that to less than two million. Most of that moved into an Azure consumption model, so we have the ability to sort of leverage that up and down.  All of our Office 365 that we continue to have for our people that needed e-mail. Because a lot of our part-time employees, they had a CROSSMARK employee alias, but it just relayed to their personal e-mail account. Because we found that people didn't like to read and open a second e-mail account when they worked part time, because generally they had more than one part-time job, so they were looking at ... they didn't want to go into those e-mails, and so a lot of times, our communications went on deaf ears. If it went into their Gmail account, their yahoo, whatever they used for personal e-mail, we had a lot better read rate. We actually reduced that expense and we took our EA from about four million to about 400 thousand dollars a year. Just to give you an idea. And so we talked to Gartner about this and said, "This is what we're looking to do, who else has done this?" And they said, "Nobody, can we do a case study when you're done?" 

We actually were able to get off that, what do you call it, the Enterprise Agreement Love Boat, we got off the Love Boat and pulled it to shore. All we have left in our EA is really our virtualized private cloud that runs in our data center today. The first year I was at CROSSMARK, we took all of our data center, we virtualized our entire data center which was about a thousand servers. And we brought that into a VMware, VMC Cisco environment. And so, because we did that, not knowing at the time you have to have software assurance in order to continue running a virtualized private cloud, so that's really all we have left in that process. The other piece is that we improved that speed of employee onboarding, right? Before it may have taken a day or two to get all of their applications provision. Now within minutes or hours, people have all their applications provisioned that they need access to. So the entire process is automated. And when people leave, the entire off boarding process is automated as well. Because when you think about a cloud strategy, and you think about software as a service and you're paying for things like Box and Salesforce, if you don't have good de-provisioning and good clean up processes, your licensing costs can start to explode. That's a key thing that we needed to automate, and which we did. And then there was a lot of those manual processes. We cut down a lot of what I call the running of IT expense. It's part of this whole cloud transformation, that Okta's a part of. We've cut down a lot of those manual process that we had before, kind of that running of IT and we were able to re-portion ...

Mike Anderson: ... that we had before. Kind of that running of IT and we were able to reposition and reallocate our dollars towards innovation and growth in our business. And so what that's done for us this year, is we're doing a lot around things like artificial intelligence and things like machine learning and things that really drive innovation and drive revenue in our company, and that's because we got rid of a lot of those manual processes that we've come to love and loathe as it relates to some of the on-premise infrastructure like Active Directory. So a few recommendations. First, make sure you send your people to Okta Training. We had some really smart people that just got into it and said, "This is really easy. This is intuitive, I'll just start doing stuff." Well we had to undo some of those things, so I definitely say send people to the Okta Training before you just jump in and start working in the environment. That was definitely a lesson we learned quickly. The second is engage the Okta product leadership. So we work through our customer success manager; we reach directly out to product leadership to ask questions. I think we were the first company to actually get raise limits on some of the rules because we had people with the same job code in different divisions. They had different application provisioning sets, and it created a lot of complexity in provisioning rules. And so we worked with the product leadership on that, and they now added new features in to help us in that process. This is one that sounds easy, but it's really hard, and anybody that's worked with HR data can appreciate. Start with clean people data. If you got really bad people dokta rata coming from your HR system, it makes provisioning and provisioning rules and all those things a lot harder. So, the key thing is make sure you've got good clean structured HR data coming out so that you're not battling against that at the same time you're trying to make this migration.

Another one is make sure you think about your groups. A lot of times you get into this and you think, "Well this is how we did it before, so this is how we should do it in the future," and when you do this, you really should think about your group structures and say, "Do I really need all those same groups that I had in active directory? Or can I think about things differently, so think about your group strategy and don't just replicate what you had before, think about new ways you can do things. And that ties hand-in-glove into understanding what are the different application profiles, so we did, we went through this process, we listed out every single application the user used, and we looked at all the different job classes and job codes, and all the different divisions that those people were in, and created a 3-dimensional matrix of all the different applications people would need, and that helped us map out our profiles and groups, and that's what fed into our provisioning process when we setup the applications, and often, our team will actually go and refer back to that matrix to say, "Is it running like it's supposed to?" So it actually helped us when we looked at test cases when we did QA, we were actually able to go refer back to the matrix and say, "Did the person get provisioned with the right applications, with the right security based on that matrix?" So that was a key piece. 

The other thing is stay on top of the releases, one of the benefits of working with a cloud partner, someone like Okta, Salesforce Box, and of those companies, is they're constantly releasing new capabilities and functionality, so you have the opportunity to take big steps forward. SO the whole LDAP is a ... Okta is an LDAP, is something we're really excited about because it allows up to take that final step of fully shutting down active directory in our environment. There are some applications that you always have to look at and say, "Well if we're going to sunset that application in a short time frame, then the juice probably isn't worth the squeeze." So definitely do that ROY analysis on it, but what we look at is, it's going to help us really get rid of what's left of that on premise active directory environment that we've got. And so what's on tap for us next is replacing Active Directory, that's where we're up next with Okta, so we're excited about working through this process and the new releases. We were part of the Beta with the LDAP piece, and we had some good success there and they were able to incorporate some of the feedback we gave, and so we're excited about the roadmap. So hopefully that was helpful, it was a fast, furious journey. I would be lying if I said there weren't some long weekends that the team worked during that process. But overall, we had a really good experience with our user population. We rolled out multi-factor authentication to our entire workforce and our call volumes were minuscule. It was such a simple process. We used SMS and google authenticator for our workup population and it went seamless, and we had very, very low call volume. We had the call center staffed up expecting a lot of calls, what we got was completely the opposite. And so that was a great experience for us, as well. So with that I think we'll go to QA, are you coming back up here?

Sai Maddali: I think we have some more time for questions and answers.

Mike Anderson: And questions? I know we have about seven or eight more minutes.

Sai Maddali: I think they're bringing over you the mic.

Speaker 2: You had a slide that talked about working with the product team, I believe, as one of your points of interest.

Mike Anderson: Mm-hmm (affirmative). 

Speaker 2: Okay. So you have 30,000 employees?

Mike Anderson: Correct.

Speaker 2: We have like 200, so how are we going to work with the product and ... Also, related to that, how much professional service is involved in this project? Or did you do it all yourself?

Mike Anderson: No we did ... that's a good question. We used Okta professional services in this process. It wasn't a bunch. You know, it wasn't more than six figures, I think it was probably around $50,000 worth of professional services, I consider that a small number with the size of organization we have, and it's all relative to that standpoint. As far as product teams, the good opportunity and the reason ... what's nice about events like this, is you have product leadership that's here and this is a great way, if you don't normally get that ear, to get that ear. What I found in my experience even working at smaller companies, if you even send emails off to product managers and say, "This is what I'm trying to do," I've never had a product manager respond back to me and say they weren't interested in my feedback. So what I encourage you to do is get as many business cards as you can and meet as many people as you can when you're here, and then leverage that when you go back. I've been at smaller companies before, and that's what I had to do because we were forced to, so good question. Anything else?

Sai Maddali: We have a question back there.

Speaker 3: Yes, can you talk more about the changes that were made by Okta to accommodate the duplicate name issue?

Sai Maddali: The what issue?

Speaker 3: The duplicate name issue. You mentioned that you had employees with the same name and that you had Okta make some changes to allow for that?

Mike Anderson: Yeah, so it wasn't Okta that made changes. When we did our process for Active Directory, you can pick what you're going to use as your unique identifier and how it builds it. And the way it was architected fifteen years ago, the company wasn't as big at the time and hadn't made as many acquisitions. It was all based off of first name and last name. And so that created a lot of object collision, so we had to go back in and manually update those names inside Active Directory. When we went to Okta we built our own process inside of our people hub where we actually created the email address someone would use, and we used that email as the unique identifier inside of Okta so we didn't have that issue.

Speaker 3: Okay, thanks.

Mike Anderson: Yup.

Speaker 4: Can you hear me?

Mike Anderson: Yup.

Speaker 4: Could you just elaborate a little more about your level 1, level 2, and level 3 support? When you said that you had five engineers working on this stuff, right? 

Mike Anderson: As far as like ... if I understand your question, you're talking about host-go-live?

Speaker 4: Host-go-live kind of support, yeah.

Mike Anderson: On our staff we actually have two system engineers that are cross-trained that support the entire environment today. We moved a lot of our staff that was doing what I consider running of IT, we went and found partners we could work with to help take on some of those functions because they were very black and white, we could write runbooks around it so we did, as far as our service test goes. So we were able to push a lot of the mundane tasks like that and repetitive tasks to a partner, and so our engineers are really focused on provisioning and new applications. So, a new application comes on, how do we onboard that application? As well as maintaining the rules and things inside of Okta. Does that answer your question? Okay.

Speaker 5: So you're trying to get rid of Active Directory. What do you see as some of your big challenges to try to get rid of it completely?

Mike Anderson: The first one is going to be the Office 365 one Okta solved for me for the way you can now provision directly into ... you know, add your ID. Because that's a requirement in order for you to use Office 365. We're looking at a project right now, we're evaluating G-Suite as an alternative, so that may be something that helps alleviate part of that altogether. The bigger issues going to be some of our legacy applications that we got today that rely on Active Directory and all the groups inside of that to create the profiles and security. SO that's the one that's going to be the biggest left. Two of the applications we have in that area, one of them we're going to be sun setting at the end of this year and the other we're going to sunset in August of 2019. So those two I feel pretty about. I don't want to invest a lot of time and energy to change things because one thing is I've reduced me ... I don't have a lot of support calls that come in for those because generally the rule in IT is if you don't change things, they don't break. When you introduce change, things break. So, I'm not going to try to introduce change into something that's not, not breaking on those two. The third one we have what I consider our most legacy, we have a progress-based application that's out there today and uses Active Directory, but it's really only using the LDAP authentication component. It's not leveraging groups, so that's one that we'll do as one of our first hits is to take that on, and we actually have a team in the Philippines that does ... a couple of hundred people in our business team that are in the Philippines that access that application and so the ability to be able to transverse ... go all the way to our data center to be able to get to that application and move that out to the cloud ... what we're doing with Okta will help us do that. Did I answer your question? Alright.

Sai Maddali: There's a question up here.

Speaker 6: Yeah, so we did something similar, but we had some challenges with the sophisticated user base in terms of their ability to leverage newer factors, like with MFA. Are you seeing any of that, so someone's in a Costco and they're working on something and they need to log into an app and maybe they're not that tech savvy, so have you experienced that in your deployment? Any creative ideas there?

Mike Anderson: So what we did with ours, in our MFA implementation is we decided to do a device-based MFA instead of an every login MFA. So what we did is we profiled our application, so some applications we require MFA every time. So if it's benefits enrollment, if it's your paycheck stub, HR-related data, you have to authenticate every time for those. But for the normal applications, "Hey, I need to get to Box," as long as you've authenticated that device once with multi-factor, then we allow you to continue to access it. So anytime you access from a new app or a new device, then it's going to make you do the authentication one time and from then on, as long as you're using that same app on the same device, you've won't have to go through the MFA again. Implementing that approach helped us reduce a lot of the friction that you're talking about in the store. Because people don't generally look up their paycheck stub or change their benefits from the Costco, they do that from home, on their home computer where their phone is generally in their pocket and they're right there working through that process. But we did actually, when we went through the process, all of the apps our employees use were built for mobile first as we went through our modernization, so a lot of our employee base, especially the younger generation, they don't want to carry a laptop anymore, they want it all on their phones. So we built all of our applications for mobile first so people could maintain all those things directly on their device.

Sai Maddali: I think we have time for one more question.

Speaker 7: Hi there. Yeah you said that you have a custom Sales Force that's feeding into Okta, then you also said that the Universal Directory is your master, is it not ... I may be just misunderstanding something here, but is UD really the master there? Or is that the Salesforce?

Mike Anderson: Okta is our master as far as the authentication and provisioning. Sales Force, my business challenge I had there around people, and I spoke about this at Dream Forces last year. I had, and this is not uncommon, I had a core HR system, I had a talent management system, I had in the ... we had another system that was outside of the ... we didn't have one talent management suite, I had one application tracking an onboarding system, I had another system for learning management with some Success Factors. Isums was the other one here. We also had Loss in our HR system. So I didn't have one single point of truth in our HR information, which is why I wanted to go down a work day path, but given where things are at, I didn't get the support I needed from a board standpoint to go to that path, so I said, "How do we solve this problem a different way?" So what we did is we built a structure inside of Sales Force to model, and modeled all the data around an employee, and we built our own custom object so we could lock down the security and encrypt things like social security number, birth dates, things like that, that are PI related. What that does, is it takes the data, consolidates it in one place, then creates the profile in Okta that then uses to provision all the applications.

Sai Maddali: I think that's all the time we have for questions. If you guys have any more questions, we'll hang around. Feel free to come talk to us. On that note, I highly recommend going to these sessions, Roadmap for Access Management is in this room in 15 minutes, and then there's also Bringing it All Together, how you can integrate HR and directories all together into your cloud, that's also happening at 3:45 today. Then if you guys are interested in learning about the LDAP interface, we have a lab tomorrow, so I highly recommend that one. But thank you for taking the time, don't forget to fill out the survey, thanks for coming.

Mike Anderson: Thanks, everybody.