Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Out-of-band (offline) Ability to Respond to Requests #38

Open
dsibiski opened this issue Dec 8, 2022 · 6 comments
Open

Out-of-band (offline) Ability to Respond to Requests #38

dsibiski opened this issue Dec 8, 2022 · 6 comments

Comments

@dsibiski
Copy link
Member

dsibiski commented Dec 8, 2022

The ability to approve/deny a request for times when the computer is offline and not able to reach AE servers.

@dsibiski dsibiski converted this from a draft issue Dec 8, 2022
@pushmotion
Copy link

I would like to upvote this particular request. I have had a few times this would have been useful and saved me a trip.

@codemonkey2k5
Copy link

I also would like to upvote this. Not having this option caused a major issue just a few weeks ago.

@itsriguy12
Copy link

This is pretty much a requirement in order for us to deploy this product to any upper level management or remote users since they may not always be online.

@spraus
Copy link

spraus commented Mar 14, 2023

For what its worth this would literally sell it to my company. At this point my management will not buy in until we have some way of having an offline method of authentication. The following are suggestions my team came up with.

  • OTP that can be generated by admin and used by user or one time use in the event they are offline... This would require some kind of local cache to be held on the machine for logging purposes that would then upload next connection.
  • Local cache of existing approvals, this would likely need to be secured to ensure no user can mess with the contents... In addition like the previous option a local cache of actions would need to be kept to report back to the server.
  • A rotating (every 24 hours) password that an admin could gain access to and distribute to the user for temporary (24 hour) access to the account. This password would be changed every 24 hours automatically when online but held in stasis until back online. Same local cache for logging would be required

I hope this could give some ideas and Id love to see this happen as it would improve the ability for my company to use the software vastly.
SPraus

@dsibiski
Copy link
Member Author

@spraus Thanks for the suggestions! Much appreciated. FWIW, your suggestion of "Local cache of existing approvals" is what we do have today. Each agent keeps a local encrypted cache (in a read-only location) of its "Rules" for approvals & denials. That way, even if the agent is offline, Rules will still be applied. It is only new unknown things that would not work.

@cwildermuth
Copy link

My only issue with OTP, is that they are time based, and more and more frequently the thing that is broken causing access issues is time related. Not sure how to work around that, unless as mentioned, there is an automatically rotated admin password somehow. I'm good with a 24 hour rotation, but then you'd have to consider what to do after it's used (and how). Would a user be able to log out and then login as this user and add themselves to a local admin group? If it's a "burn on use" password, what happens if the first use doesn't fix their ability to come back online? (I'm thinking corrupted driver installs for NICs here)...you might need to use it more than once. Can it be session based? but again, what if you need a reboot?

I'd almost think you'd need automatic password rotation while online, and the "last known good" password stored in AE (or better yet, Hudu), and once a machine came back online and checked into AE, it would rotate automatically. This would mean a machine that is offline for days or weeks, would have a known good documented password, and if the machine came back online, it would automatically update (and be documented). It doesn't quite resolve the issue of a user doing whatever they want in the period the machine is offline, but hopefully your goal is to get the machine back online when it's broken.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Researching/Under Consideration
Development

No branches or pull requests

6 participants