I hope there is not similar feature request, I could not find it. Maybe it would be useful to others too, that have "mass binding" requests.
What we "need" is ability to reorder priority of credentials used. If I understood, during discovery they are used from top to bottom and first one working is used for that device. Problem we have is with "read only" credentials that older ones are used and migrating to new ones is harder since we have weird case where we have 2 different central AAA servers with slightly different configuration. So we need to bind per device. Seems like simple feature to implement if not mistaken, since other places you have "reordering possible".
Thanks in forward
Device credentials priority
I would like to add this feature request.
Why Unimus needs to test all the credentials when the device has been discovered before?
Would it be possible to soft-bind the credentials that worked at initial discovery to device. That way you do not need to the bruteforce with all the known credentials to the devices. If the soft-binded credential does not work anymore then maybe try all the credentials?
The current discovery process is firing always up so many SIEM alerts and we end-up manually binding credentials to each device. This is tedious.
Why Unimus needs to test all the credentials when the device has been discovered before?
Would it be possible to soft-bind the credentials that worked at initial discovery to device. That way you do not need to the bruteforce with all the known credentials to the devices. If the soft-binded credential does not work anymore then maybe try all the credentials?
The current discovery process is firing always up so many SIEM alerts and we end-up manually binding credentials to each device. This is tedious.
This is something I have brought to the developers.
I am hoping we can get some updates on this in the next release. I will try to give some more updates on this tomorrow when I have a chance to go over our timeline with the devs and the various tickets involved.
I am hoping we can get some updates on this in the next release. I will try to give some more updates on this tomorrow when I have a chance to go over our timeline with the devs and the various tickets involved.
We have started refinement and preparation work on this, but it won't be in 2.10. All dev effort is currently going into SSO (OpenID/OIDC/SAML) and MCP (Model Context Protocol). Those are the highest currently-requested features, so we are prioritizing those, and they are aimed at 2.11.
As for Credential handling - it might not look like it, but it's actually a significant amount of work. We need to refactor how Unimus deals with credentials for devices in the GUI, on the DB layer, how requests are sent to Core (embedded or remote), implement logic to detect credential-based failures and re-trigger a job with the full credential list, changes to the API, etc.
But good news is that if we are already refactoring the codebase, there are multiple features we are looking at. Current list is:
- Allow Credentials to be marked not to be used for Discovery, allowing bind-only credentials that will never be exposed to devices
- Allow per-Zone binding of Credentials, so you can separate which credentials belong to which Zones (MSP use-cases)
- Allow automatic binding of Credentials from Discovery results
- Allow automatic binding of CLI Mode Change passwords from Discovery results
- Re-trigger full Discovery if auto-bound credentials are incorrect
To do all of this, we first need to refactor multiple parts of the backend codebase. We are planning to start refactoring after 2.11. This is a requirement to be able to support these features. To be completely transparent - we think we can deliver this in Q1 2027, not earlier. It really is quite a lot of work.
As for Credential handling - it might not look like it, but it's actually a significant amount of work. We need to refactor how Unimus deals with credentials for devices in the GUI, on the DB layer, how requests are sent to Core (embedded or remote), implement logic to detect credential-based failures and re-trigger a job with the full credential list, changes to the API, etc.
But good news is that if we are already refactoring the codebase, there are multiple features we are looking at. Current list is:
- Allow Credentials to be marked not to be used for Discovery, allowing bind-only credentials that will never be exposed to devices
- Allow per-Zone binding of Credentials, so you can separate which credentials belong to which Zones (MSP use-cases)
- Allow automatic binding of Credentials from Discovery results
- Allow automatic binding of CLI Mode Change passwords from Discovery results
- Re-trigger full Discovery if auto-bound credentials are incorrect
To do all of this, we first need to refactor multiple parts of the backend codebase. We are planning to start refactoring after 2.11. This is a requirement to be able to support these features. To be completely transparent - we think we can deliver this in Q1 2027, not earlier. It really is quite a lot of work.