Getting ready to buy some licenses and dump our infrastructure and customer network devices into Unimus so I thought I'd post a wish list based on our trial of it so far.
Credentials
-A way to edit the password of an existing credential for when device credentials are changed. If we simply added a new one with a new password and rediscovered the old credentials would sit unused indefinitely.
-A way to identify a single credential in a possibly large list of credentials to find out which one to change when device credentials are updated. Many will have the same name. A description field is a start but some credentials will be used for more than a single device.
-It seems keeping credentials not assigned to a specific device helps scale the setup however with a large set of credentials it seems discovering devices could yield a lot of auth failures on devices that could result in a lot of failed attempt logging at a minimum or user lockout worst case.
Web view of a device config rather than just a txt download - a view kind of like the search results or the Diff view but from a specific device backup.
Device backups in svn/cvs/git style - do a diff and only retain the backup when changes occur so that there isn't a backup every day that is an exact copy of the day before. Helps highlight and record changes for change management.
Remove show password ability on local user accounts. Sort of makes sense for device credentials but not for logins used by network administrators.
API for adding credentials/devices and backup schedules, viewing configs.
To a lesser extent:
Dont require user/pass for outbound smtp for situations where local internal SMTP without user auth is used.
LDAP/AD auth for UI access.
Secret Server integration - Password and other secrets management system by Thycotic. Credentials stored in the Secret Server db and integration allows for a select from credentials found in the SS system.
-brady
[Implemented] Feature Request list
Hi
Thanks for the list of requests!
Feedback like this is really important to us, so we keep the development on track with user-wanted features.
Here is a little info about each of the items, I added ticket numbers where appropriate, so people can track the progress if they are interested
All devices using the old credential will automatically re-discover on the next scheduled job.
(or you can force a re-discovery automatically)
If you choose to leave the old credential in the system, you can see its usage count, as well as on which devices it's still being used.
We are not against adding 'Edit' for credentials, but when a credential is edited, re-discovery would still need to be ran on all devices using it, to validate if it's still valid for the devices after it's been changed.
Do you have any suggestions how this could comfortably be done?
For example, just add credentials and import 200 devices from .csv (or sync from NMS), and everything will just work.
Credential-to-device binding was requested multiple times, so we have plans to implement it:
https://tracker.unimus.net/browse/UN-251
https://tracker.unimus.net/browse/UN-234
https://tracker.unimus.net/browse/UN-33
https://tracker.unimus.net/browse/UN-252
In fact, they are hashed in the DB, so there is no way to show them in clear-text even if we wanted to.
Only option is to reset a users password.
https://tracker.unimus.net/browse/UN-243
We should have a public beta build which will contain the API sometimes next week:
https://tracker.unimus.net/browse/UN-253
https://tracker.unimus.net/browse/UN-136
To whoever got all the way to the end of this wall-of-text - you deserve a virtual high-five!
Thanks for the list of requests!
Feedback like this is really important to us, so we keep the development on track with user-wanted features.
Here is a little info about each of the items, I added ticket numbers where appropriate, so people can track the progress if they are interested
The intention is that if you are phasing out a credential, you can add a new one, and delete the old one.A way to edit the password of an existing credential for when device credentials are changed. If we simply added a new one with a new password and rediscovered the old credentials would sit unused indefinitely.
All devices using the old credential will automatically re-discover on the next scheduled job.
(or you can force a re-discovery automatically)
If you choose to leave the old credential in the system, you can see its usage count, as well as on which devices it's still being used.
We are not against adding 'Edit' for credentials, but when a credential is edited, re-discovery would still need to be ran on all devices using it, to validate if it's still valid for the devices after it's been changed.
Search currently works just on username, so identifying a particular username/password pair in case of many same passwords will require some clicking.A way to identify a single credential in a possibly large list of credentials to find out which one to change when device credentials are updated. Many will have the same name. A description field is a start but some credentials will be used for more than a single device.
Do you have any suggestions how this could comfortably be done?
Credential auto-discovery is meant to automate and speed things up.It seems keeping credentials not assigned to a specific device helps scale the setup however with a large set of credentials it seems discovering devices could yield a lot of auth failures on devices that could result in a lot of failed attempt logging at a minimum or user lockout worst case.
For example, just add credentials and import 200 devices from .csv (or sync from NMS), and everything will just work.
Credential-to-device binding was requested multiple times, so we have plans to implement it:
https://tracker.unimus.net/browse/UN-251
This is planned for development soon:Web view of a device config rather than just a txt download - a view kind of like the search results or the Diff view but from a specific device backup.
https://tracker.unimus.net/browse/UN-234
This is planned, and needed for notifications on config change (which are also planned):Device backups in svn/cvs/git style - do a diff and only retain the backup when changes occur so that there isn't a backup every day that is an exact copy of the day before. Helps highlight and record changes for change management.
https://tracker.unimus.net/browse/UN-33
https://tracker.unimus.net/browse/UN-252
This one I don't understand - it is not possible to show user password.Remove show password ability on local user accounts. Sort of makes sense for device credentials but not for logins used by network administrators.
In fact, they are hashed in the DB, so there is no way to show them in clear-text even if we wanted to.
Only option is to reset a users password.
In development right now:API for adding credentials/devices and backup schedules, viewing configs.
https://tracker.unimus.net/browse/UN-243
We should have a public beta build which will contain the API sometimes next week:
This is quite easy, I made a ticket. We will try to fit it somewhere in-between bigger features:Dont require user/pass for outbound smtp for situations where local internal SMTP without user auth is used.
https://tracker.unimus.net/browse/UN-253
This is planned before the end of the year:LDAP/AD auth for UI access.
https://tracker.unimus.net/browse/UN-136
To whoever got all the way to the end of this wall-of-text - you deserve a virtual high-five!
-
- Posts: 3
- Joined: Thu Oct 12, 2017 6:04 am
Thanks for the quick reply. It's great to see that you've already been thinking about most of the list.
The user accounts and show password - I was mistaken - there was a show password button when adding the user so I was thinking that would hold true like the regular credentials - but there is no way to see the password after the account is created as you stated so that is great.
For the device credentials everything you explained on how they work makes sense and we can just adjust our operations accordingly and with the device displaying which credentials it is using I thing this will provide what we need.
The user accounts and show password - I was mistaken - there was a show password button when adding the user so I was thinking that would hold true like the regular credentials - but there is no way to see the password after the account is created as you stated so that is great.
For the device credentials everything you explained on how they work makes sense and we can just adjust our operations accordingly and with the device displaying which credentials it is using I thing this will provide what we need.