Unique Keys per Organization | Voters

Unique Keys per Organization

under review

Cameron Granger

Ability to have unique keys per organization (similar in length/uniqueness to account keys) that can then be disabled in the event that a customer departs and the Huntress Account holder needs to disable the account.

If you give this an upvote, do us a favor and submit your use case! This will help us get things moving.

April 30, 2021

Sibe Pronounced Ceebeh Klomp

This is a must have for us as an MSSP.

Hunter Mays

This is very important. Having to reset the account key to prevent old clients from being able to reinstall is more work since it impacts all current clients. In my experience, the organization key can just be made up during the installation and Huntress will then create a new organization for that key. This has created a bit of a headache for us even during normal installation since some mistypes have created random organizations that are difficult to track down the device's owner.

Eric Henry

marked this post as

under review

Blaine Kahle

This, or the ability to block an organization from being recreated and agents registered under it. We frequently get billed for agents that re-register even after the customer has departed, for a variety of reasons (device offline for weeks, GPO not purged, etc.).

After the client is gone, we don't have any ability to remediate this other than send uninstall from Huntress, as we no longer control the environment. And if a GPO reinstalls, we're at the mercy of the client/new MSP to remove that GPO.

Bill Shoener

I believe this to be a super important addition. We have cases where offboarded clients fail to remove huntress deployment scripts from their RMM tools, causing agents to reregister with old org ids. Having unique registration keys would allow us to revoke access without needing to redistribute installers to the rest of our clients.

Bob Michie

Im looking to rollout huntress to a community of users were each person is limited to enrolling a limited number of seats. Ideally i would like to limit the number of systems individually per tenant. Having single use keys that deployed to a specific tenant would be ideal

Jason Cuplin

This would be a great addition as some clients are a co-managed IT relationship where actual deployment is done through existing client infrastructure and account key is exposed in some way (i.e. powershell script / GPO deployment)

Rob Fiedorowicz

This could also allow for some unique future customization on a per client basis. For example, custom insights and reporting based on compliance requirements only for customer (x,y,z) being pulled through api using their client id key :)