cancel
Showing results for 
Search instead for 
Did you mean: 
urvashi
Bronze I
Bronze I

This is an edited transcript of the 04.05.24 IT Hour

Overview

  • Derek Johnson and Tom Bridge from the Product Management team join us to talk about and demo the Temporary Elevated Device Privileges feature. 
  • Derek also talks about future plans around this feature and answers questions from the audience.

Transcript

Introduction 

Derek: Today I’m going to talk about temporary elevated device privileges. This is another kind of key component that we felt is going to add a tremendous amount of value to our customers in the way they want to manage their security posture related to elevated privileges on devices for users. 

Problem Statement: 

  • More IT Admins are enhancing their security posture by removing elevated privileges on devices. 
  • They want an easy way to still provide elevated privileges on an as-needed basis that automatically expires after a defined period of time. 

It can’t be overly difficult so we tried to focus on those two things. You could do this in JumpCloud before we introduced this capability, it was just a manual process. You had the ability to elevate privilege for a user that was bound to a device, across any OS family but when that work was finished the admin had to remember to go in and remove it. So this is making it much easier for you; to have a way where you can set a time and forget it and move on to the next task and be confident that the privilege will be revoked once that time period runs out. 

Temporary Elevated Device Privileges: Key Capabilities 

  • Manage User Privileges - Ability to set an individual user’s privilege on a device for a selected period of time
  • Automate User Privilege Expiration - Elevated privilege on a device will automatically expire and return to the previous setting without the admin taking additional (manual) steps 
  • Data Insight Events: Data or events are generated when the privilege is elevated, used, automatically expired, and returned to its previous state. 

Walkthrough

Derek: I’m logged into the Admin Portal as a regular admin. Tom will be playing the role of Sam, he’s a Mac user extraordinaire. I’ll be Derek the IT Admin. As you can see in the admin portal, there’s a user here called Sam. He has access to several devices. Sam is going to share his screen. 

Tom/Sam: Let’s say I’m an engineer and I need some tools to do my job. Like I need the ability for the terminal to access the entire disk, or I need the ability to install BBEdit and things along those lines. Derek, as you know, I really want to install BBEdit but I’m not an admin so I can’t do that. Or I want to go into System Preferences, into Privacy and Security, and I want to go into Full Disk Access and hit Terminal, but I’m not an admin. Can you make me an admin? I really need to do these things so I can do my job. 

Derek: How long do you think you need for this, Sam? 

Tom/Sam: A couple of minutes would be fine. 

Derek: So I’m back in the Admin portal and looking at Sam’s device. I go into the edit icon where it says “No elevated permissions”. Up pops this modal that says “No Elevated Permissions”, “Administrator/Sudo Access” and “Passwordless sudo”. I’m going to click on “Administrator/Sudo Access”. Same said he needed a couple of minutes so I’m going to give Sam 10 minutes. 

Note that we have to allow up to 10 minutes for this change to take effect. This mainly happens on the revocation side. The grant side should be instantaneous but we put this wording here just to give you a heads up that the change may take some time to take place. So I’m going to click Apply and always remember to Save the user, otherwise it doesn’t work. Let’s go back and take a look at Sam real quick. You notice it now says “Administrator/Sudo Access” and it also has the remaining time left. Another way to find the remaining time is if I click on the edit icon again, if I wanted to change it, you’ll notice that this “10 minutes remaining” is here as well. I’m passing it back over to Sam and he’s going to show you all the cool admin things he can do. 

Tom/Sam: I really need to sudo into my terminal session so that I can do some stuff. Sweet, I’ve got “root” that I didn’t have before. I can install my application, which I wasn’t able to do before. And then I can give myself Full Disk Access for my terminal. Hey Derek, I think I’ve done what I need to do. Are you cool or do you want to revoke my permissions

Derek: You know what man, I’m doing 15 other things at this point as a very busy admin and I gave you 10 minutes. I trust that you’re not going to do anything else within that 10 minutes so I’m going to let it expire on its own. 

But let’s say I did want to go ahead and cancel it. Back in the Admin Portal I go back to devices. Notice it says 8 minutes left. If I wanted to cancel it I would just click on “No Elevated Permissions” and click Apply and then Save. Now when I go back to the device you’ll see that it says “No Elevated Permissions”. But let’s say that I had given Sam a permanent elevated privilege. This is what we already had in JumpCloud. It was binary. Either you give it to him permanently or you take it away. So I’m going to apply that here. 

If I wanted to change Sam’s privilege to something other than permanent I would have to first remove it completely and then apply a time period. I want you to know about that flow change. From the backend perspective, if there’s permanent access, you need to remove it first and then set it on a temporary basis. Same thing with “Passwordless Sudo”. 

Another thing I wanted to share is that you can get to this from the Devices page. I’ve been showing you everything from the user’s page.If I go to the devices page and look for the device we were talking about earlier, you’ll see that I’m on the Device Details page. I can click on the user’s tab and get to Sam this way and perform the same task. 

If I go to Directory Insights you can see the events here. There’s user_admin_granted and user_admin_revoked, and you can see the expiration time stamp and see that it was a temporary change.  Can you do this by API? Yes, absolutely. 

Future Vision - Request/Approval Flow

Derek: I also want to show you a little bit about where we’re going with this, because if you think about this use case, it’s a very tiny portion of a much larger use case which is around self serve and request approval. So the vision is “As an organization, I want my users to easily get access to the resources they need” but I want all this to happen within the context of JumpCloud and I want to be able to track it within the context of JumpCloud. 

So I’m a user, and I need to request something, access to a resource. That resource could be an application, another device that I don’t have access to, it could be RADIUS, or a different resource altogether. I might need to request access or a role change to something I already have access to, which could be a permission change. 

So based on being able to request something, we want to be able to configure a route for that request to occur based on who I am, my identity and what I’m requesting. I want a configurable flow that’s automated to the right person to make that decision or for it to be completely automated based on who I am and what I’ve asked for. So if it’s auto approval, it would automatically go through. If it requires an approval, I would have an IT Admin or a delegate be able to approve that. 

We know that we need an end product approval queue in order to achieve that. These are things that don’t exist today within JumpCloud. The ability to request something, approve something, and have an automated action taken. Eventually we’ll get to a place where it’s up to you, the admin, to decide if you want your users to self-serve into temporary elevated privileges on a Just-In-Time as-needed basis or do you require an approval to take place? The same thing could apply to access to other resources or changes that need to occur in your environment. 

The other thing that we want to do is we want to make it better for the user. So think about this poor user who right now we're relying upon you, the admin, to tell them that they have this elevated privilege. We also want to start working on how we notify the user within their session that they have this elevated privilege and specifically how much time they have left and then when it goes away. There's some great, great examples that are already out there that we can emulate and so we're, we're, we're actively looking at those as well from an improvement standpoint. 

I think Admin By Request does a good job of this  where they have like this little timer and it's right there on the bottom. And it's really easy for the user to know, “Hey, I was granted 15 minutes” and then “I've got my 15 minutes and then I can close it out too.” They can just hit stop and it removes the privilege. It revokes it back down. It makes you very aware as a user. And so. That's something that we're looking at that we potentially want to incorporate. 

We're also going to be in a position later this year where we can build more alerting and notification capabilities around events like this. Where let's say you've got a series or you've got several admins and you want to alert everyone, or you want something to go into a Slack channel, you want it to go into your ticketing system every time that someone is granted an elevation. 

But again, I go back to the bigger use case of request approval. What I really want is to give you the ability to track it all the way through. And you can have as much granularity as you want within that process, and events are going to be triggered at every step of the way. And when we go down this alerting and notification path to be able to give you the configurability to put alerts around those different events.

We’re not going to have all of this in 2024 but I want you all to understand that this is just the beginning of the journey down this path. In the latter half of 2024, you’ll see us start to execute these things. 

Q&A

Q: Is there a way to restrict this to certain admins? 

A: There’s no restriction at the admin level yet. The manager role should have the ability to do this and the Help Desk role will have the ability to do this in the second half of the year. One of the things we’re going to revisit is scopes, in terms of roles within the Admin Portal. So you’ll see some changes that give more configurability.

Q: What sort of logging is available?

A: Right now the only logging that’s available is the logs associated with the grand and revocation events. Directory Insights events give you a time frame and the execution path. So for example, when you’re using the log command for MacOS, (you can use this command directly from JumpCloud), you can just say “show me the system log from that 10 minute period” So you can see that Full Disk Access was granted and that BBEdit was installed. 

That’s how we’re approaching it today. It’s not the only way to approach the problem and we’d love to see feature requests for more information about all of these things from the platform. We’re considering ingesting other logs into the JumpCloud view, we just haven’t gone there yet. So if that’s something you feel strongly about, please submit a feature request and we’ll go from there. 

Q: So when you give someone admin, it’s kind of carte blanche?

A: Yes it is. That’s where we’re limited by the operating systems that we’re working with for the moment. One of the things we’ve seen in the market is the ability to grant admin access to run a particular application, that way it’s not carte blanche, it’s only within the context of the task at hand. For most of our customers, we believe that the existing approach is the right approach. But if you feel differently and want to be able to see that level of granularity, please submit a feature request because that’ll help us make some of those decisions. 

Q: The documentation mentions that the user has to log out, or their elevation persists?

A: Windows always presents us with fun little challenges within the environment. And what we found in our testing is extremely inconsistent. And that goes for both the grant and the revocation. On the grant, if the user doesn't log out and log back in, we've noticed that there's some things that they should be able to do with the admin role that they've been granted, but they can't. When they log out and they log back in, they have the full admin suite. On the revocation side, there's things that they can still do, but in order for the change to completely take place, they have to log out and log back in. Now, all of that said, we want to go explore this further. We think that there is a way that we can find to be able to make it to where this log out and log back in is not necessary.

And this is only for Windows devices. So I would encourage you to test and and see what your experience is. But our official recommendation is that in order for the change to completely take place, you need to log out and log back in. 

Q: What prevents a rogue app from emulating requests? In the self serve flow in the future?

A: We would make that completely configurable to the admin. We're not going to go create a self-serve capability and force it upon the customers. You're going to opt into that. And so if you want there to be an approval process and you want a more secure environment, we're always going to enable that.

We've just seen lots of customers say, “Hey, I trust my users. I make them sign a disclosure. I don't want to manage them going in and out of elevated privileges”. And maybe it's only for certain users and we want to give you that configurability as well. Let's say you're an engineer, and that's your role. If you're in the engineering group,  we want to let you self-serve in and out of an elevated privilege because we trust you as an engineer, but we don't want to leave it open all the time. So we're going to be mindful of that from a configurability perspective. But we do hear enough from customers that they want a self-serve capability. They at least want the option of a self-serve capability. 

On the backend the answer is, you're not gonna have access to any of the right keys to do this action on the device itself. That Agent to JumpCloud channel is heavily secured, and so the only other way to make those requests is either from the JumpCloud API which requires an API key.

Q: From a compliance perspective it would be easier for certain companies to just turn this off completely. Would that be possible? 

A: It’s something we can think about, so you could submit a feature request for that. 

Q: Can you see the time remaining on the home screen? 

A: No, you can’t see it from the home screen. The privilege is provided to a specific user, not the device itself for every user. So that’s one of the reasons you have to go to the user who has it elevated. It’s difficult to show it at a higher level now. That said, we’re exploring better ways to give you visualizations of who has these temporary elevated privileges. 

Version history
Last update:
‎04-30-2024 08:11 AM
Updated by:
Contributors