Jump to content

Feature request: One-to-many (1:N) relations for accounts-to-hosts


Recommended Posts

Good morning everyone :)


The past two weeks we've discussed this a bit, so I thought I'd make it a real feature suggestion. I would very much like the possibility to define one-to-many relationships for accounts to hosts (1:N).


The biggest use case I can think of for this, is Linux privileged user accounts in Linux/Unix environments where a centralized IAM-platform is not available. For example, a network with many IoT devices which allow SSH for management functions, but which cannot integrate with AD or LDAP. In such a case it would be a great hassle to define privileged accounts on a 1:1 basis.


If I would be able to define one Linux account, with a strong SSH keypair (or a frequently rotating strong password), that is to be used on the relevant systems as the designated privileged user, that would be ever-so-helpful. #RunOnSentence.


Link to comment
Share on other sites

Hi Buckit,


Thanks for your request. At this stage we're not sure this is something we would like to implement, as it goes against best practice fur using unique passwords across your hosts. It would also required a complete redesign of our Password Reset Engine, Account Heartbeats, Remote Site Locations, Reporting, API, etc, etc.


Click Studios

Link to comment
Share on other sites

Thank you very much @support, for your patience with me. I honestly think we don't pay you guys enough to deal with the amount of shite I send your way. 


You are of course utterly correct. Thank you for snapping me out of my stuck-thinking: I was in some recursive loop, not properly thinking about how to tackle my current problem, also because I was avoiding something specific. As you say, the only right solution here would be to make use of the API by building a script to tackle the situation.


New IoT device? Run the script which:

  1. Defines the host,
  2. Defines the privileged password object,
  3. Defines the privileged account and the 
  4. Defines the other password object(s) and ties them to the C privileged account. 

The downside to this is that you'll get a wild-growth of priv.accounts.


The reason I kept avoiding this solution, is because it means I have to write a lot of Powershell code. Why? Because I'm stubborn. I don't want to make a one-off script that works for one specific solution, with hardcoded script IDs and other hardcoded settings. No, Mr Smug here wants to make everything a lookup through the API :o There's a Powershell module out there already, but it uses API keys instead of kerbauth which we prefer right now. 


But yeah. You're right. I'll get over myself and start tackling this problem the right way. That module needed to be written anyway and I'm postponing the inevitable. It ain't gonna write itself. ;) 

Link to comment
Share on other sites

In one type of system yes and that's how we'll setup that sub-set, although they have another problem entirely which will need more scripting to solve :(


Other types of devices have both root and "normal" users with root not being able to login. Of course we could forego changing the root password, but that would leave the console open. So in those cases we'll need that script I described (or we open root up for SSH, but naahhh).

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...