Meet Your Okta Identity Experts

Hi everyone, I'm Raj Nagalingam, Senior Services Architect, part of Customer First organization. I have 15 plus years of experience in Identity and Access Management, worked with various verticals including finance, government, and technology companies, and have been with Okta for two years and six months. One of my favorite deployment experiences was with a customer who had acquired three companies and had three different identity systems. The biggest challenge we had here was getting many people talking about the design options: how we consolidate all the identities, enabling a single source of truth, enabling single sign-on for all the on-prem apps. The biggest challenge was combining all the different MFA's to Okta Verify. We did through a phased approach and deployed it successfully.

Sure, thanks. Hi everybody, my name is Chirag Shah, I'm a Services Architect based on the East Coast in Washington DC area. I've been in the IAM security space for over 15, 16 years now, and I've been with Okta just over a year and a half. I've become part of their Professional Services division and have already worked through numerous customers. And of course, given the area I am in, a lot of government agencies as well. One of my favorite experiences has been taking a customer from ground zero all the way through the actual design and implementation of Okta and the various components of our ecosystem, and taking them into production live within 90 days. And then the biggest compliment was the customer was very keen and championed us by giving their experience at Oktane 19 this year, so that was great to hear. And the final compliment was they came back and got onto more projects which we are working with them right now. So all in all a great commercial for Okta as a product and kudos from the client.

Yes, first of all thanks for inviting me today. I appreciate being here and being a part of this. My name is Rick Zimbelman, I'm a Senior Engagement Manager with Okta Global Services. I've been an identity and governance professional for about 16 years now. I've worked for many of the vendors that are out there in the marketplace as well as a couple partners and a GSI over those years. I've been with Okta just coming up on four years in October and I can't wait for the next four years. It's been a nice ride and I'm looking forward to the rest. One of the stories I like to tell is when I first started at Okta, I came in as an architect and we were doing a deployment for a top 10 oil and gas company, which turned out to be a customer I had not had a good experience with at my previous employer. So needless to say, when I walked in the room it was kind of a shock and everybody was surprised that I was there. The positive side is we went in and we laid out a plan and deployed Okta, and we were done within about 90 days. We had them up and running and it was a complete reversal of what we had been through before. So I always kind of like to use that story as a compare and contrast.

Sure. So just like you said, there's a couple of questions in there for the listeners. What I'd like to start with first is, apart from convention, if you asked me a few years ago, everybody who was pretty much saying one of the de facto standards was people used to use a lot of RSA SecurID tokens, the hard tokens which you may or may not have seen, and then things started moving into MFA using phone and your one-time password and SMS etc. Well lately there's been some new standards like FIDO, also referred to as FIDO2, Universal Two-Factor or U2F, which have come into the market. And these basically are of course a much more secure way of enforcing MFA. They basically strengthen the two-factor authentication using specialized USB or NFC devices. That's the core concept of it, and it's of course much more secure than what nowadays is normal where you're using your phone for a one-time password or via SMS. And it's even been stated by NIST that SMS is bound to be hacked given the way hackers have been able to impersonate and get phone information switched. Whereas the MFA devices which are based on U2F and FIDO2, they basically are based on encryption technology. They use crypto keys for handshake and it's much more secure and not something that can be hacked away easily. So having said that, we have seen a lot of adoption especially by companies where IT administrators who are dealing with maintaining servers, back-end servers, Linux, Windows, we're seeing a lot of those just because it's a very sensitive topic, that's where the meat is for any company, that's where the data is. So we are beginning to see factors like Okta Verify, Okta Verify is certified for both U2F, FIDO2, YubiKey, and Windows Hello factors being used frequently. And if I'm not wrong, I think Raj, you've worked with a few customers in the past and maybe you can share some of those experiences as well.

Yes Chirag, I did work with multiple implementations particularly on adaptive MFA and MFA. I was super excited about the YubiKey or the non-phone factor. I started my first project at Okta deploying YubiKey in an enterprise, and we had a very excellent deployment strategy to roll out the two-factor using a phased approach and three steps for success. I did talk about this deployment strategy at Oktane 2015 and a lot of customers were excited to follow the same secret sauce that we did for one of the enterprise customers. I really want to share this today with everyone. It's a very simple step to deploy YubiKey for your enterprise. The first and foremost step is to obtain the YubiKey token from Yubico, which is obvious. The step two is perform the enrollment process where you register your YubiKeys with Okta, all the users will do that. And the third and final step is the enforcement part of it where a policy will be configured so when a user logs in they will be asked for the credential. All these steps involve a lot of communication, so when it comes to MFA or adaptive MFA, you have to make sure you are communicating to the customer to perform the enrollment and enforcement. We do provide the end-user communication toolkit which all our customers use for making this a successful project.

Sure. I just want to say in very simple words, it is what it sounds like: the method of authentication without the pain of having to remember passwords in that flow. A few years ago at Oktane I was talking about how we can kill passwords and it's coming true. The interesting part of this is that a lot of people get confused with passwordless and the delivery of passwordless. Generally speaking in the industry, a passwordless authentication platform ranges from email, magic link, factor sequencing, WebAuthn, and also we have the existing concept of device trust, desktop single sign-on which we already have many customers adopting. It is a broad concept made of many individual features. So the password platform which all our customers are familiar with today is desktop single sign-on, and I also work with that. It's also kind of a passwordless. To give you a distinct example: how this technology is adopted, for example mobile devices, you have an iPhone enabled with a button where you use your fingerprint, you get into all these applications. For Mac you have Touch ID, you do your fingerprinting, it uses WebAuthn. So if the button is not supported then you have an alternate password resolution, use your Okta credentials. The next thing we talk about when it comes to passwordless is cost benefits. Particularly on the password side, from the IT perspective they have cost related to password reset, the IT and ops have to manage that. When you remove the password totally, you get a bigger benefit, and also removing the password hassle. We're all kind of password creatures, you don't have any passwords when users are using it.

Sure. Well I think the really exciting part is we are moving forward right now with our factor sequencing for our authentication. Password is one of those factors, so it doesn't really go away. It's still available if it's required by regulation, law, or something. But you may have applications where you have to have a password, applications where you don't, so you can apply that when and where you need it. And of course we have complexity rules for the passwords that would continue to be enforced as they are today. I think a good example of that might be that if you're on network with your company and you log into your system, you might only need to touch a YubiKey or put in an Okta Verify to get on. And then when you hit an application that is governed or is regulated, you might get asked for a password at that point as a second factor. If you're off network, you may have to do more than that including the Verify, maybe the password, and something else to get in the application. So it's really the factor sequencing that's taking us to that next level where we can pick and choose how we authenticate to the applications, and then using our adaptive policies when and where those policies are applied.

Thanks Rick. This is about a new customer in a highly regulated environment that I'm going to talk about. Their passwordless to be implemented to avoid issues related to password breaches. The use case is unique in a way that employees will be using different factors when they log in to apps from outside their network. When I say that, the user logging in from Starbucks or outside the network, they will be prompted with Okta Verify or YubiKey instead of password to log in. In the same way, when the users are accessing the same app internally, they will see the desktop single sign-on where they are providing their desktop credential and they are not getting a prompt, which allows the user to seamlessly log in without a password.

So first off, the Server RDP MFA component, which is recently named as the Credential Service Provider for Windows. This is just for the listeners so that if they want to look up some information on that. While it may show up as anything for RDP Okta, I think the recent name change just so that it doesn't throw people off. There's a good amount of documentation which would really help out as well. Now as far as the main question goes, what's the best way to roll it out and what are some of the common issues. So the first part is easy pretty much. This is again an Okta product feature, it's an agent-based component, and as far as the permissions, the administrative rights are set correctly, you should be able to install this very quickly without any hassle. It should be as seamless as most of the other Okta components are. So that's the easy part. Now the common issues part. We've seen a few common issues related to when we are rolling this out. Let me walk through some of them. Number one is even in the day of automated deployments and releases, it's actually careless deployment practice that can hamper the rollout of this kind of feature because this MFA and essentially lock out the user. So what we're talking about is the user population. In essence what you're trying to do is enable MFA for users who want to access the back-end storage, Linux, Windows, etc., in this case Windows. One of the first requirements is that these users need to be already enrolled with certain MFA factors. This component does not allow inline MFA registration. What that means is if you've never enrolled into an MFA factor through Okta, or maybe your policy had no necessity for you to be enrolled in Okta, and now suddenly you're an IT server admin and the policy has been turned on on this Credential Service Provider, boom, you're not able to get in there just because it doesn't recognize the fact that you're not enrolled in MFA and that capability is not there. So that's something to take care of. What that means is you want to ensure that the user population you are about to go live with, they have already gone through some sort of MFA registration and the factors which they have are all supported by the policy you're about to turn on for this feature set. So that's one of the issues we've seen. Another common issue we've seen with this is the configuration is set up in such a way that when I'm logging in, it's my regular credentials, whether I'm logging into my AD credentials or Okta credentials, those are being used to authenticate in the back-end to the local server which we're trying to protect. Well you have to remember, the Credential Service Provider is not here for authentication purposes but it's more for MFA enforcement. People may say, wait a minute, that doesn't sound right because AD is of course used as an authentication mechanism. As far as this component is concerned, its prime value is about providing MFA and not authentication. So you may have a separate set of local server credentials, those need to be matched, and they basically are configured at first. So it's not like when you're sitting there trying to find out those credentials. So that's one common issue we've seen, just ensure that your server credentials are actually the ones which are set up rather than your regular login credentials. Another aspect which of course is communicated upfront to clients is that based on the way the Windows RDP protocol is, it doesn't support the more advanced MFA protocols or standards like U2F. So it basically doesn't support Windows Hello factor or YubiKey factor. I'm not sure if that's a feature set that may come later on, but for now that's not something which is supported. So those are some of the key aspects and common issues which we've come across, and I hope that helps.

Well, following up on what Chirag said, as you can hear it can be fairly complex to put this in place. So planning and testing are critical to the success. It isn't just rolling it out and here you go. You need to plan, make sure all the dependencies are in place, make sure that you've engaged software teams to deploy these agents to the number of systems, and then follow up with testing and piloting this and being sure that it's working before you roll it out. I think a best practice from my perspective would be to have customers start with a small number of systems, a small number of users, practice and test, getting the software out, the configurations right, having those users authenticate and use the MFA and validating that it's all working along the way before rolling out for the larger general population. So I really think that just tails onto what Chirag was talking about.

Sure. So first off, Advanced Server Access is pretty much a brand-new product being unveiled. I think it was announced at Oktane 19 and it's now ready. We have customers which are beginning to deploy this. This product essentially was built for server security, or to strengthen server security I would say. It's basically built to scale for protecting your critical server infrastructure. And to date, usually server protection has always been about the ID rather than the actual server. Now as far as Advanced Server Access goes, this pretty much opens up and gives a much more comprehensive coverage to the whole aspect of protecting servers by adding, again we would be leveraging a lot of other features in this, but what it brings to the table is not just single-handed credential protection but brings the whole aspect of identity access management, lifecycle management, role-based access policies which will be applicable now. As far as best practices, just deploying this product, we've seen that places where there is a lot of servers based off a lot of SSH keys floating around and environments are out of control, or in some cases very greenfield environments especially when you're moving to cloud, new cloud environments or cloud infrastructure that is AWS, GCP etc., using ASA itself is a best practice in its own just because of the fact that it removes those dependencies and the mess with using SSH keys. ASA is based on the concept of using a formal credential mechanism and what that ultimately means is short-lived certificate exchange that happens, or PKI keys, and basically this is a true zero-trust solution. This is not something where with my SSH keys stolen somebody could try and impersonate me and then get into the server. It's not like that. These are based on on-the-spot one-time access where every time I'm logging in it's a new set of public-private key pairs which are generated and that's how the handshake is taking place. So even if somebody got hold of my initial credential they wouldn't be able to go far because those things are also very limited as far as session-wise reference. So I know it's getting a bit technical but that's the power of this, it's pretty awesome. Moving on to another best practice: given that Advanced Server Access was initially a product which Okta acquired and now it's fully integrated with Okta, the true best practice comes when you start doing centralized management of users and groups of these server administrator accounts which you need to use. So now you can just manage the whole lifecycle of those users and the groups, whether these servers belong to my Finance group, these servers belong to my Engineering group, etc., you can manage all of that through the more familiar Okta interface which everybody is so used to, and it's seamless. Correct.

Particularly hearing, I would start with how Okta is born in the cloud and primarily Okta supports modern methods of authentication. We started with single sign-on, MFA, adaptive MFA. We always have challenges when getting into the legacy systems. We primarily work with third-party vendors to enable the legacy system to integrate with our Okta identity. Primarily when it comes to legacy systems, they don't follow these standards, they are header-based authentication. So the good news is, until now we worked with all these third-party vendors. Now we have a new product, the Access Gateway, which is connecting your hybrid environment, on-prem and cloud, solution with legacy systems, as well as it can also work with your custom-built systems, connect with your identity cloud. So I'm very happy we are going into a full circle, not only supporting the cloud, we are getting into legacy systems. It's taking a lot of enterprise to move away from legacy, we are closing that gap.

Well, I couldn't completely agree with what Raj was speaking about. I love the fact we're adding products and expanding our footprint at Okta, adding these things to the arsenal because one of the number-one issues when you go into customers and we start to talk about implementation is, yes great for all my cloud applications, but how are you going to handle my on-premise, my old legacy applications? And until now we didn't really have solutions that were ours. We'd work with third-party vendors or custom solutions, and that was really a turn-off to customers. That meant they either had to buy additional product licenses or they had to pay for someone to develop custom code, then own it, maintain it, and keep it running for the long term. So it really wasn't a great story. With the Okta Access Gateway and Advanced Server Access, we can now move into these on-prem situations and we can just meld those into Okta. We can use all of the same authentication, the same identities, all of the same MFA policies, login policies, and just apply them. That's a really powerful story for the customers to be able to say wow, I can do this all in one product now. I don't have to go buy all these separate pieces and try to cobble them together. To me that's the future of identity. The past is the custom, the bespoke, where you've got ten different solutions and try to make them work together. So at a high level I think that's really the exciting part.

I can take this one. Okay, I think really the transition from Azure Active Directory sync, we're really talking about Office 365. That's the primary use case here. What we're finding with Office 365 is we have a very full-featured set of functionality in Okta where we can handle everything from the single sign-on, MFA, to lifecycle management. But it's a process, not an event, to get there. Typically a customer migrating from an on-premise exchange system that they've had for years, there's a lot of dependencies, there's a lot of objects in those servers that Okta doesn't have access to. So there's a lot of careful planning to get to the lifecycle especially, and be able to move that data around and manage it effectively. For most customers, the path forward for a cloud-enabled customer that's fully into Office 365, we can give them the full feature set and move from the Azure Active Directory sync, which they likely aren't using at that point anyway if they're fully cloud-enabled. They're more on Azure AD. We can take out the ADFS and apply all of the Okta features and functions to that. For the older companies, the brick and mortars that have been around for years, their exchange systems could be 20 years old and have things in there that it's going to take them years to get migrated off of, and they may never. So we look at doing single sign-on, multi-factor, and license management at that level and returning them some real quick value in Okta. And the option is always there to move to the lifecycle if they get to that point, but they're not forced to do that. They can maintain their business and their things without interruption.

I couldn't agree more with what Rick just said. One of the things which we always experience whenever we head out to clients is, especially it's like, okay yeah we have Office 365, I can provision everything into it, right? And that's how when we start doing some of these discovery sessions that we understand, we get to know that number one they're in a hybrid scenario, things which break a little bit through maybe old exchange servers which are not at all compliant to deal with today's modern authentication patterns, those kind of things. It's almost like things come out of the woodwork. What would seem like the ideal picture which the customer is thinking of, and we can definitely get there, it's just there are steps involved in this. So the scenario which the customer is looking for is: my users in AD, we are provisioning them into Okta, they get flowed into Office 365, and you know, you're ready to go. Well, so pretty much what Rick said, and some additional points are: you want to make sure that number one, if you have a lot of on-prem components related to your Office infrastructure, that needs to be migrated over or moved over. We're talking things like mailboxes, exchange servers, your calendars, objects, etc., all that which is on-prem and you may be using part of that here using things like Microsoft DirSync to sync your user objects and their information from on-prem onto Office 365. That needs to become a completely cloud footprint first. So that's one of the key tasks involved in getting you to that end-state vision. Then other things which will start coming into place, people tend to be using a lot of legacy clients. So let's start out with Outlook 2010. I mean we've seen a lot of those where people are still using old VB scripts to drive some of the aspects of Office 365. So while that's all good for operating in that little world, what happens is if you try to bring that to today's world, things like MFA or integration with other cloud services becomes very difficult because that's not supported. So there needs to be a plan where the clients need to upgrade, or in some cases basically just revamp their clients to more latest and greatest versions of Office 365. Last but not least, I would mention that you want to remember that Office 365 is what we call a big-bang application. So as and when the customers who are used to accessing their email systems or other components of Office 365, when the switchover happens from say, when you start authenticating to Okta and your lifecycle management also happens to Okta, there is a minor change in experience involved. However, by doing upfront communication, we've alluded to end-user adoption toolkits, how-to videos, tips and guides, that definitely helps in the overall migration from on-prem to a completely cloud solution. So hope that helps.