Oktane18: Customer Zero -- Okta on Okta
Stephanie D: Hi Everyone. Thank you for being here. I'm thrilled to have everyone here for the second Okta on Okta customer zero presentation.
I had the pleasure of speaking up here last year, and so I'm thrilled to be here again and have many familiar faces, and some new ones too.
My name is Stephanie Dwight. I'm the senior manager of IT business systems.
Mick Johnson: I'm Mick Johnson, manager of the Okta on Okta program.
Stephanie D: Alright awesome. So let's get started. Just going to jump right into it.
So today what we're going to talk to you about is Okta's enhanced employee journey. And so really what that means is we're going to talk to you about all the way from a new hire to a job change, to actually onboarding, and to basically the retirement / termination process.
So some things to note about this slide in particular is we've got ... the big numbers or the big topics that we're going to talk about today. And then some of the little pit stops along the road are just topics that we are going to address at our booth after, over in the expo center. Password policies, adaptive FMA, and so forth, just come join us after the presentation, and we'd love to talk to you about it in more detail.
So to set a little bit context for you all in the room, we ... Mick and I run the Okta on Okta program within, so really what that means is how do we, as customers, as an IT internal department, actually deploy Okta internally?
So what I'm going to talk to you about first of all, is our partnership with Workday. So in order for us to truly leverage automating all of our ... basically our HR policies, our employee identity, we've leveraged all ... basically all of the big changes that happen within Workday.
So the business process enhancements that I'm going to talk through today are our hire business process, our job change business process, and our termination process.
So within our hire process, we are automatically assigning provisioning groups. And so through real-time sync, and throughs scheduled imports, we're able to actually pull in new employees automatically and put them into provisioning groups that automatically goes into Okta and automatically provision applications to our new hires.
And so each one of these segments I'm going to pull in throughout the journey that I'm going to take you through today. And we're going to discuss how it benefits Okta internally. SO hopefully you can learn a little bit from us, and maybe bring that back to your company and see how it would benefit you as well.
So let's get started. So this is Jimmy, right? You're going to hear a lot about Jimmy. You're probably going to be sick of hearing the name Jimmy. But Jimmy is a new hire at Okta. He's a pre-hire, and there are some main things that we know about Jimmy. Some main key attributes. We know that he's going to start ... he's going to be in IT. We know that he's going to be an IT engineer. He's going to be the newest member of the team. And we also know that he is a full time employee in San Francisco.
Some other fun things that we learned about Jimmy through the interview process is that he likes sushi, long walks on the beach, but that's not going to really dictate his provisioning of applications.
So to get started with Jimmy, he's a pre-hire, so he has not started at Okta yet. And so I'm going to walk you through really kind of what that means, by using Workday as a master internally at Okta.
So we ... basically gather as an HRAS team, gather all the requirements of all the documentation of the new hire, and put it into Workday. And so these are kind of the key attributes that we really focus on at Okta, and many of these attributes actually drive provisioning of applications for us.
So just to highlight a couple, is cost center and employee type. So as I showed you before, Jimmy's in the IT cost center, the IT department. And he's also a full time employee. So when we use those two attributes in conjunction in our new hire process within Workday, we're able to decide real time, based off of sub processes that we have within that higher business process, what type of provisioning group that Jimmy should be in.
So we know he's a full time employee. We know that he's in IT, which is awesome, so we automatically add him into the provisioning group of IT, which then through real time sync or scheduled imports, we have both, we put him into Okta.
So seamlessly, all of the attribute data is, as you can see here, it's identical to what's in Workday to what's in Okta. So we have his true identity in Okta.
So from there, we take these provisioning groups, and at Okta, we have about 55 different provisioning groups. And we tag applications, or assign applications, to those provisioning groups.
So when Jimmy starts in IT, he automatically is going to get his birthright applications, which I'll walk you through in a moment, and in addition, he's going to get the set of applications that were assigned to his provisioning group.
So as you see here, it's just one flow motion. Seamless, really. We take the attribute information, automatically goes into Okta, so our IT department can automatically be productive and cut down time, because they have all of that new hire information already in Okta. They don't have to toggle between Workday or Okta, it's just all there.
So what does our application assignment really look like? So these are just some examples I'm going to walk you through, but they're real examples of what we use at Okta. At Okta, we have something called birthright applications. And some of you may or may not know what that means, but to Okta, that means as a full time employee starting at Okta, no matter where you are in the world, no matter where you sit, no matter what team you're a part of, you get about 26 applications on your first day of work.
So through our birthright applications, that's kind of our foundation of applications that you get. In addition to that, these are just four kind of ... our provisioning group cost center applications. So like I was talking about earlier, because Jimmy's in IT, he's going to get a certain set of applications.
So, if you start in sales, you'll see here we get Salesforce, we have LearnCore, Clarity, and DocuSign. So for each one of our provisioning groups, we automatically are assigning these applications.
In addition to the cost center applications that are in the provisioning groups, we also have geo-based locations. So, since Jimmy's in San Francisco, he's automatically going to get Munchery and Plansource, and Navi, and payroll at ADP, which is going to be different than an employee starting in Australia, for example.
So you can see here, I mean this is really just an example of the applications, but you can see this is a lot of information. And so by being able to kind of cut down on provisioning skim-enabled applications, we are able to not only make sure that employees on their first day of work, they have the correct applications. I don't know about you guys in the room, but when you start at a job, the worst thing is ... is like you don't even know where you're sitting. Mind you, where your manager is, who your team is. And to be able to not have to chase down IT to make sure that you have access to an application that you need to do that day, to jump right into your roles and responsibilities, it's really key.
So having this real time sync of employee attribute information, and putting our employees in those provisioning groups, really enhances not only the employee's journey their first day, but also cuts down on the time and the tickets for our IT team. And not only first day of work, like the last thing that we want to worry about is having an upset employee on their first day. So this has really kind of just totally changed the employee's experience from right when they start.
So I talked you through kind of the benefits of the provisioning groups. As you can see, it's big for us. And automatically provisioning applications, I mean, through all this it's all seamless. And the amazing thing about provisioning groups is you know that your entire team has the same provisioning group. Which means you have the same applications. So it's just constantly the exact same. What's in Workday is also what's in Okta. And so we're able to really just make this more efficient, and more productive as a whole at Okta.
So I walked you through kind of the pre-hire process. So really, now what we're going to transition into is what happens now, Jimmy has set foot first day at Okta. And so Mick here is going to talk to you about what it's like to get connected on your first day at work.
Mick Johnson: Thank you, Stephanie.
Hello? So here at Okta, we want to provide our employees with a unified login experience. And what does that mean? That means we want to use your Okta identity to connect you to everything. Your applications, your devices, and your networks.
So let's talk about how Jimmy's going to get connected at Okta.
So it's Jimmy's first day at work, he's just been given his shiny new MacBook Pro, and he's attending new hire orientation. And he's going to have a unique experience, because he's going to be actually activating his Okta account at the Apple login screen. And actually the screen you're looking at right now is the Apple login screen, and thanks to a little piece of software called Nomad, we're able to activate their account right from this screen and you can customize and brand the Apple login screen however you see fit.
So what Jimmy's going to do, he's going to go click the little question mark button. He'll see the Okta login window or he'll enter his Okta username and temporary password. Once he's done this, he'll be asked to register for MFA. So he'll go ahead and set up Okta verify. And once he's done that, he'll change that temporary password to a more permanent one. And his Okta account is now activated.
So he's back at the login screen. He signs in with his new credentials. And now he's prompted for FMA the first time he logs in, because what Nomad is doing is going and looking at our Okta tenant, and making sure that this user exists and the credentials that he just sent were correct. And Nomad goes ahead and uses just in time user creation to actually create a local user account on that machine.
So within the last two minutes, we activated an Okta account, and we signed into our laptop using our Okta credentials.
So now that Jimmy's logged into his laptop, let's see about getting him connected to the wireless network.
So last year at Oktane we announced a new feature called the Okta LDAP Interface. And so that, coupled with [free radius 00:12:38] server allows us to bring 8021X authentication to our network. And for those of you that aren't network engineers, that means we're able to sign into the wireless network just using our Okta credentials.
So what it looks like for Jimmy, he finds the access point he wants to connect to, he sends his Okta credentials over, that get passed the Palo Alto, over to the free radius server, and then finally down to the L-Dap Interface.
If the credentials are correct, the L-Dap binging will complete. That gets passed back over to the Palo Alto firewall, down to the wireless access point, and the Jimmy's on the network. And I know there's a lot going on the screen, but the one thing to keep in mind is the only thing that Jimmy had to do was enter his Okta credentials to connect to the wireless network.
So we've now used our Okta identity to sign into our laptop and into the wireless network. So what happens if we need to connect to the corporate network remotely?
Well thanks to our partnership with Palo Alto Networks, we're able to use global protect paired with our Okta identity and adaptive FMA to connect to any devices remotely. And so there aren't many uses that we have for VPN connections because we use mostly cloud-based software, but there's always going to be devices that live on premise that will always need management, support, and maintenance, such as firewalls, AV equipment, switches, things like that.
So why do we want to use a unified login experience? Well on the laptop side of things, I don't know about your IT shop, but we get a lot of password reset requests. So if we can narrow down the number of accounts that our employees need to use, it's a huge win for us. It really streamlined that whole onboarding experience. I mean you saw in less than 90 seconds, we activated our Okta account, and we were about to log into our laptop using our Okta credentials.
And it helps out whoever's managing Okta on the IT side of things, because you get to centralize your password complexity policies, and just use Okta for that.
For the wireless network, we were able to control our network access control with universal directory, we get a lot more visibility into our network, and we get to know who's connecting to what, so we get a lot more accountability of the devices that are on our network.
And for the VPN, there's no need to have these local accounts anymore. We get to use our Okta identity with adaptive FMA, and it just prevents these credential-based attacks and we're able to ... once you've set up the configuration on the Palo Alto firewall and in Okta, it's as simple as assigning a [chicklet 00:15:21] to an Okta user.
So now that I've talked about a unified login experience, I'm going to hand it back over to Stephanie to let her talk to you about what it looks like to change your job role at Okta.
Stephanie D: Give me that? Oh. Wait now I'm on. Thanks. OK, cool. Alright. I can always yell, but maybe not for the next 30 minutes.
OK, so back to Jimmy. So Jimmy has now decided that IT is hard work. I mean for everyone in this room, it's a lot.
Stephanie D: Hard work, I mean, for everyone in this room, it's a lot. The sales guys look like a lot more fun, right? They're out, they're wining and dining clients, they're never really in the office. So Jimmy is going to go and be in sales, so he's gone through the whole motion and now we're now transitioning him over into ... I don't know about you guys, but actually our sales guys don't wear ties but this is pretty accurate. So his new department is sales. He's going to be an account executive, but he's going to stay as a full-time employee in San Francisco, so those are going to stay consistent.
So through a process what happens is right off the bat ... so in order for us to actually make that transition of an employee the manager has to put it through workday for routing of approval. So what happens is, is Jimmy's manager goes into Workday, submits the request, changes the cost center, which then so happens to mean, okay, so Workday now is knowing, through the job change process, that Jimmy is now in a new department. So what does that mean? That means that Jimmy now needs to be added to a new provisioning group in order for him to get the correct applications that he needs to be in sales now.
You'll see here is Jimmy's in two provisioning groups, and so that's on purpose. And why is purpose? So the reason why we put him in two provisioning groups, keep both of those provision groups there, is because right when he makes that transition, that doesn't necessarily mean he should totally change, lose all of his access to his IT applications and just run right into sales. I mean, in a perfect world that would be nice, right? All the sudden you could just drop your responsibilities and run into your new role. But that's not how a real world is.
So what we have is we've got something built out in our job change process, which is a step delay. For any of your Workday users in the room, as you would know, but if you don't know what a stepped delay is, is the system automatically knows after the effective date that there's a point in time that you can trigger an alert, a task, whatever that may be. And so what we have as a step delay to alert our HR team to say, "Hey, it's been 30 days, so it's probably time for us to remove Jimmy from that IT provisioning group and keep him into sales."
But if we back up just a bit, with both of those provisioning groups or just one, real time sync and our scheduled imports are, once again just like our pre hire process, are shooting over into Okta. The integration fires off and goes right into Okta. So it's real time. It's accurate. Anytime our IT team goes into Okta and they're like, "Well, Jimmy's in two provisioning groups," that is just going to be the exact same thing. If you go into Workday Jimmy's also in two provisioning groups. The moment that's removed, Jimmy and Okta is only going to have one. So he would just have his sales applications.
Like I said earlier, when Jimmy started in Okta he got a certain set of applications along with his birthright applications. Now that Jimmy's in sales he has his birthright applications. They stay consistent. But now he gets a sales applications because he's in a whole new provisioning group. The benefits here ... I mean, I'm sure you can, if you're an Okta user or a Workday user, just in it in general, the automatic provisioning of these applications and the automatic sync, the real time sync, or even scheduled imports if you run that, were able to make that employee on that day more productive, because they don't have to go through the hassle of emailing the IT team to make sure they have the right applications. The manager's not having to go back and forth to make sure the applications are right there.
Also, it's not just about making our employees more productive from the outside, but it's also about making our IT team more productive. We have so much going on that the huge benefit is if we can just automate some of these processes it truly just cuts down on so much time that we spend every single day doing what could be called tedious tasks of assigning applications to the employees on a ticket to ticket basis. Not only does it make us more productive and more efficient internally, but it also makes us more secure and compliant, so it doesn't matter if we're all. We're all in the same, under the same roof. We're all in Okta. There's certain things that employees should not have access to, so being able to depends on removing provisioning groups and assigning new provisioning groups also makes us just more secure in general.
And through our audit logs our system logs and Okta, you're able to pull up the system log and see exactly when that workday integration was sent over into Okta, and in addition exactly what applications were removed from that user's profile. So when we've got our auditors in house, we're able to just pull it up and it matches exactly what's in Workday as well, because we're able to actually pull that job history and say, "Okay, this is what changed. We added a provisioning group. Okay, let's go into Okta." That was also automatic. We removed certain applications and added a provisioning group.
So as a whole it's just a benefit. It just keeps us consistent from the hire process to the job change process. So now that Jimmy has kind of been a doctor for a few years, right? We've walked you through his pre hire process, what it's like, his first day of work, when he changed from IT to sales, and now maybe potentially Okta has actually outgrown Jimmy. It's time for Jimmy to move on. The company's decided this, maybe he was best in IT. Maybe you shouldn't have made that transition. So what does that look like for us?
So talk to you about the hire business process in Workday, the job change process in Workday and how it impacts Okta and how we move all the information, all the attributes over into Okta, all of our identity. Now let's talk about the actual offboarding process. So, HR business partner goes in to Workday and submits the termination business process. So they have two options then: what type of termination is this going to be? So is an involuntary term or is it a voluntary termination?
I'm going to talk to you through our involuntary termination piece. Before we actually deployed this what the business process looked like, it was very similar. We had our HR team submit the process, it was approved, and then they would just have like a to do task sitting in their Workday inbox. Press submit when the HR business partner was ready to offboard that employee and emails would go off and sent to our IT escalations team.
But what happens if their IT is all in an all hands and no one's gotten that escalation right away and there's a five minute delay, ten minute delay? Where our IT team's pretty sharp, so I wouldn't imagine any more of a delay there. But what happens there? You still have that account that's active for that involuntary termination, and we have to wait for IT to actually suspend or deactivate those accounts. Through this new process what we've done is we've actually built out the real-time sync functionality to kick off when our HR business partner's actually ready to deactivate our employee, say before the exit meeting. They just click submit and through real time sync it automatically suspends accounts. It doesn't deactivate. So for all you ought to admins in the room, we put it into a suspense state.
A couple of reasons here, we don't want to deactivate the accounts because we want to make sure we transition all the information, like from Box or so forth, those accounts over into the manager before we totally activate their accounts. Also, we're all human. Just in case somebody actually clicks that submit when they shouldn't have the worst case situation would be all those accounts are deactivated. So through this we can just put it in suspended state and make sure that we transitioned everything thoroughly and we're ready to actually deactivate those accounts.
So, in addition to our involuntary termination, which is automatic, our voluntary termination which does not have to be as strict, just like right then and there were cutting, were deactivated everything. So, what we have is through our scheduled imports, which is different than the real-time sync, our scheduled imports will pick up that employee that has decided to leave Okta and will suspend their accounts at midnight at the end of the day.
So, this is our end to end flow of our termination process. I mean, big wins here. Not only ... it truly just kind of bridges the gap of HR and IT and it makes us all one process. All one team. Having HR have the power to actually suspend accounts is big and it's serious. But, if they have the power to actually offboard somebody, they should also be the owner of actually suspending those accounts as well.
So through them actually owning this, it does make us more secure and compliant, and it makes us more secure because we're not firing off notifications and emails to everyone and accidentally that pops up on your screen. HR can just keep that sensitive situation really contained. And also we can suspend. So the moment somebody is exited out the building, they're able to just, they're not, they're not able to get in Okta. We've suspended them. So as you know ... I mean, the huge benefit here is they can't go in and see any of our now internal information.
So, our termination process, to be honest, it's kind of taken quite a bit of time to get here. The real reason is, is you can see how many teams I've talked about that this impacts. It's not about just turning on a business process at Okta. We're not a huge company, but we're not a small company either, and we have to get all the players to adopt the process internally. So we're here and we've gotten the hire process, the job change process, and our termination process as automated right now as we can, which is great.
So in a nutshell, you've learned really our big wins, our big processes that we do at Okta really. So, walked you through Jimmy's entire employment, and we would love for you to come join us at our booth, and if there's any piece of this process, no matter if it's an HR process related question, back to the networking side of getting started getting connected with Nick or just any of these other stops on the road that we haven't had time to discuss today. We would love for you to come by our booth--we're there all day--and see your smiling faces and chat with you about how you guys can better use Okta.
So thank you so much for being here, and have great afternoon.
Speaker 2: Hi, we're going to open it up. I have Mic here that I can hand off for questions. I just wanted to remind you that we did put surveys out, so you should have these little cards, I'd be greatly helpful to us if you could just check off some boxes, give us your feedback and let us know if this was valuable. So questions?
Mick Johnson: Hi. We actually in a similar journey as well too. I have a question regarding how do you guys actually handle naming conventions and also duplicates during the onboarding process?
Stephanie D: So are you talking about like um, if we have to Jimmy Smith's starting?
Mick Johnson: Correct.
Stephanie D: So we have the account rules set up in Workday actually where in the account rule section it will take the first name, last name, and if there are duplicates we'll get alerted of the duplicates and add their middle initial. Does that make sense?
But to be frank, we're not a 50000 person company, right? Fortunately we haven't had to go through that entire process yet, but we do have a couple name redundancies, and we just add in their middle initial and workday takes care of that for us.
Mick Johnson: One last question. Do you guys have a requirement to offboard individual at a specific time in the local time zone? Or you just take the work day 12:00 PM termination.
Stephanie D: It is their local time zone. Yeah. And I do know, which I don't know if I should say this, there is a new feature that is potentially coming out-
Speaker 3: [crosstalk 00:30:50] When she comes to the presentation at 3:45.
Stephanie D: Awesome. Okay. So it's going to be, and I mean you could also help me speak to this. It's going to be a time based termination times, so based off of local time. I know in the past it's Pacific Time, right? Which is kind of crazy, but now we're able to configure it based off local time. Yup. 3:45 Orville's talking, right? Yeah. That would be a great session to be at.
Speaker 4: Hi, how are you? We have a similar life cycle there, and the only thing that we are not doing is making people log into their laptop with their Okta accounts and there's a reason for that, because right now they have their very complex password for Okta saved in a password manager, and having them log into the laptop with the Okta account will mean making them to use very simple passwords. So I don't know if you ever think about this problem, if solved it or have some other solutions for that.
Speaker 2: For you.
Stephanie D: The question was, just to restate the question, the question is: have we worried about you don't allow people-
Stephanie D: Restate the question, the question is, have we worried about- you don't allow people to login to your laptop yet?
Speaker 4: Yes, that's because we acquire very complex passwords for Okta, and we don't want to scale down that policy, so if we enabled people to choose their passwords because they need to use them for their laptops, they will choose very simple ones. Right now, there are a lot of other means and we don't care because the only thing we secure is the access to production environment. But if we connect that to the laptops, they get access to everything, with very simple passwords.
Mick Johnson: You can set strict password complexity policies in Okta, and those policies will get pushed down to the laptop. It will be the same username and password. That's just how that works. Some people think that sharing those might be insecure, but I think it's great for a unified login experience.
Speaker 4: They won't remember complex passwords. So you see the flaw there. You solved the problem of giving them access to everything in a very simple way with a unique login, but on the other side, you would get people come to your help desk and say, I don't remember the password to my laptop.
Speaker 5: You're suggesting that their password is too hard to type?
Speaker 4: Well that depends what kind of complexity you require. Right now, we have quite tight one.
Stephanie D: We can get more detail with that, just come by our booth and we'll talk you through that whole process. That might be easier for us to understand the whole flow. Definitely stop by right after this, or after, and we'll talk you through that whole process.
Speaker 5: Thank you.
Stephanie D: Yeah, of course! I can't see.
Speaker 6: On your Mac set up with Nomad, once they initially register and go through the MFA experience and get the local account built on the Mac, do they need to continue to perform MFA after that, or is the Mac being managed and that's a compliant device, and so that's one factor- [crosstalk 00:34:13]
You can choose to always have MFA to login, but that is going to require that machine to always be online. For just the activation and user creation on the device, that MFA would only be prompted that first time, just when it checks against the Okta tenant to make sure that user actually exists and the credentials were valid.
Speaker 6: Okay, thanks.
Speaker 7: What about a Windows environment? We have shift work, do you guys have Windows in your environment, and what do you do to authenticate users to Windows 10 devices?
Mick Johnson: We have about 90% of our employees are Mac users, 10% are Windows users. We don't have active directory, we currently use an end-point manager called SaltStack to help with the endpoint management of those devices. Does that answer your question?
Speaker 7: How do you manage the log-ins?
Mick Johnson: The log-ins are all local accounts.
Speaker 7: Is there a Window’s Nomad integration?
Stephanie D: The question was, there was no- [crosstalk 00:35:25]
Mick Johnson: I don't believe there is a Windows Nomad integration yet.
Speaker 8: I just wanted to confirm, you guys are using DSSO, I imagine? The Desktop Single Sign-On? That's what that was.
Mick Johnson: Nomad has a functionality for that. What I just showed you was just the user account creation and there's an agent that will also run on the machine as well to keep your Octa password in sync with your keychain. We have not enabled similar to our Windows via desktop SSO feature on Nomad.
Stephanie D: So many questions.
Speaker 9: Just a quick question on how you go about suspending accounts. Obviously suspending is very different from deactivating in Octa. When you suspend in Octa, it doesn't really affect the other apps, as far as my understanding of it works. An example that we have to deal with a lot is, a user didn't quite follow our travel policy and their laptop logs in from China, then I have to go through and suspend their Octa account, disable their AD, and do a bunch of other stuff. Do you guys have a suggested workflow for that, or how do you handle something like that?
Stephanie D: You got that?
Mick Johnson: You can set sign-on policies through a strict logging into Octa from certain high-risk countries if you want, or you can as granular as you want with geographic sign-on policies.
Speaker 9: Right, but it doesn't stop them from going into Gmail for example and logging in, unless I manually go in and suspend their account.
Mick Johnson: I see. We haven't run into that problem, so I don't really have a great answer for you.
Speaker 9: Fair enough.
Stephanie D: We can help solution that potentially, in a little while. We can talk you through the options that we could probably give you. Give to some other people in the room too.
Speaker 10: So now that you've implemented your program, if you could look back at something you encountered that, had you known then what you know now, what would that be that would have either saved a lot of time during the implementation or maybe a lot of frustration.
Stephanie D: My side, and I say my side because I really manage People-IT, I started in HR at Octa, and ran with Workday. I would say, truly understanding how it impacts the entire organization, it sounds easy, I would say, to go out and just work with your IT team to decide what departments need what applications for example. But once we started digging in, I had to go out to all the department heads and actually truly figure out either what we're doing really well today in IT for application assignments from that list. And then what additional applications those teams are really needing.
Getting in ahead of it there, and start your research earlier on, on, "Okay, who do I need to talk to?" Who's either been here the longest that actually understands what applications are needed for the department, or just get ahead of it and start to map out a matrix of where all your applications are where are all the main licenses, and if you do have those attributes in Octa also figure out what cost centers the employees are mostly using those applications. That would be very helpful. It's more just adoption of the business and getting everyone to understand what the end goal is.
Yeah, anything for you?
Mick Johnson: I think communication to teams that are affected by any feature enablement, just to ensure everyone knows it's coming, understands how it's going to work, how it's going to impact them. I think it's really maintaining a good line of communication to the company.
Speaker 11: Hello, could you please tell me how do you handle a situation when on the first day of employment the new hire just decided to use his display name against the legal name? We have a lot of situations like that.
Stephanie D: So his preferred name? It's not the easiest process but what we do is we require from recruiting to ask what their preferred name is. We get ahead of it from a recruiting perspective and in HR. Our HR operations team makes sure that we have, if your name is Robert, but you really winna go by Rob, we know that right away. Otherwise, it is kind of a little bit of a headache, because then we have to redo the accounts, with the new account names.
Mick Johnson: There're certain applications where, like [Amex 00:40:51] where you have to send the legal first name, so what we do is we push that attribute from Workday into Octa and use a custom username to use that legal first name instead of the chosen one.
Speaker 12: Hi, thanks for showing us everything you do in Octa. I'm just curious, with the offboarding, if you do the suspension what do you do with all the running sessions on devices, like Gmail, Outlook, everything is still running. You can suspend the user, but you'll still have active sessions and active apps. And if you want to have a denial of access for that user how do you run on that?
Mick Johnson: Because you can suspend future access, but existing sessions will still be there, so you'd have to go into each service provider application and actually kill the-
Stephanie D: Session.
Mick Johnson: Kill the session in there.
Stephanie D: And really, the suspend state is just like a preliminary protocol. The team gets alerted, especially if it's in escalation. The team does get alerted, it's just one of those in addition to making sure the IT team is on top of suspending and deactivating the accounts, we suspend just to make sure we can cut off any potential. Then they do all the background work after that.
Speaker 12: So there's still a list of items to do even though you suspend.
Stephanie D: Yes.
Speaker 12: All right.
Stephanie D: That's correct.
Speaker 13: Do you ever restore, from a suspend?
Stephanie D: We haven't had that yet, thankfully. I'm sure that's coming.
Speaker 14: Quick question on your 802.1x deployment, are you guys distributing certificates when you initially deploy? Or you just using-
Mick Johnson: Yes. We use Jamf to distribute the ready certificate to the machines.
Speaker 14: But you're not using individual computer certificates?
Mick Johnson: No.
Speaker 15: I have a quick question about the provisioning workflow. I understand having provisioning groups that people fit into neat buckets, however I've never worked at a company where that is actually true. There's always one-offs, ad hoc assignments, how do you manage that?
Stephanie D: We haven't gotten super complex yet, that is definitely on the roadmap. Basically to take role-based and marry that with the group rules that we can do in Octa as well, so in addition kind of hit that like 80% of applications and buckets per se right? Then use the group rules in Octa to pick off the smaller subset to groups but when it comes to one-offs, that would go through our normal process of actually submitting an IT ticket. Right? This is just truly just to get rid of anything that we don't have to manually do, so we can spend time on those one-offs.
Speaker 16: I have a quick simple question about new hires. How do you give new hires their temporary password when they login for the very first time? How do you securely give them that information before they reset it to their new password?
Mick Johnson: During a new hire orientation, we get all the new hires on Monday morning, are in a room together, otherwise if it's a remote employee someone from our service desk team will reach out to that employee.
Stephanie D: We don't send it. We send it to their personal email address that is given to us, given to recruiting and given to our HR operations team. Those accounts are not activated until they're either on the phone or in the room of the day that they started Octa. Nothing before, we don't allow any users to get in the system before their first day of work.
Speaker 17: And that's going to be it. We are out of time. But thank you everybody for coming. Reminder if you can leave surveys in the back, that would be very helpful. Thanks guys!
Mick Johnson: Thank you everyone!
We're not salespeople or product managers, we're the team that is using Okta to make Okta better. In this session, Okta experts tell stories around our HRIS as a Master solution and explain how to use new features, such as LDAP as a Service. This IT professional-to-IT professional discussion will teach viewers how to implement and benefit from these solutions.
Mick Johnson, Manager, Okta on Okta, Okta
Stephanie Dwight, Senior Manager, IT Business Systems, Okta