Adding host via api and account discovery

[Azkabahn]

Hello,

 

We are adding Linux hosts via API, however I have couple of concerns.

 

Why passwordstate doesn't use "IP" field in host object ? It is trying to use "Hostname" when connecting to discover accounts.

Maybe with windows is less likely to have hostname without fqdn, however often linux systems does have hostname that can not be resolved, more reliable way would be to use its IP instead of hostname, don't you think so ?

Also, It is strange why after account discovery, password is being created with "HostName" or "UserName" variables only, host has field "Title" but no way to use it during discovery.

tldr:

1. Can passwordstate use IP(internal/external) field for communication with hosts instead of "HostName"?

2. Can passwordstate inherit more variables, so I would be able to specify "Title" from Host object to be inserted into password object upon discovery

3. Is there any way that I could trigger account discovery(password change) immediately after host is added ? With current setup, it is not enough to run it once a day (new host will hang there with "default" password and no records of accounts on that server until Discovery job will start.

 

 

[support]

Hi Azkabahn,

 

When adding host records into Passwordstate, either through the UI or the API, you have the option of specifying either the actual Host Name, or IP Address in the Host Name field. So if you specify the IP Address in here, the account discoveries, password resets and account heartbeats will use the IP Address to connect to the machine.

 

With our Account Discovery Jobs, you can trigger a reset at the time of discovery - there is a option on the Discovery Job for this. If added Host records through the API, you would need to write your own scripts to trigger account resets at the same time.

 

We hope this helps.

Regards

Click Studios

[Azkabahn]

Well, doesn't look like this, If I add Hostname instead of IP, heartbeat fails instantly.

 

And this is how host definition looks like

 

And trying to discover accounts results in:

 

 

p.s Discovery script uses exact variable:

        $success = $ssh.Connect($HostName, $Port)

 

Sorry if I'm not right, Powershell isn't my thing

 

 

[Azkabahn]

And if possible, could you explain a bit more about this.

9 hours ago, support said:

If added Host records through the API, you would need to write your own scripts to trigger account resets at the same time.

 

AFAIK, there is not such thing implemented in API calls, so somehow I should track/catch events on passwordstate itself ? Any example how it can be done ?

 

[support]

Hello,

 

For your host record, do you have a functioning DNS record for that Host Name - if not, you will need one for the Heartbeats to work? The IP Address fields you see on this screen are for documentation purposes only.

 

For the API, you're correct that there is no one API call which will do what you want. You will need multiple API calls i.e. chain each of the 3 API Calls below into one API script:

 

• Add a Host Record
• Add a password record linked to the Host above - and make sure all the options/fields are specified where the password record is enabled for resets
• Then perform a password reset on the record i.e. update the password

 

If you develop a script with all these 3 calls, then it will give you what you need. We also have PowerShell example scripts for all of these in our API documentation page.

 

Regards

Click Studios

[Azkabahn]

1 hour ago, support said:

For your host record, do you have a functioning DNS record for that Host Name - if not, you will need one for the Heartbeats to work? The IP Address fields you see on this screen are for documentation purposes only.

 

This is what I was asking, It was strange for me to have IP field and would be not able to use it, sure we have DNS records, however it is not most reliable thing when you are managing thousands of hosts. If I understood you right, there is no way to use that field, only fqdn (hostname) that can be resolved ?

1 hour ago, support said:

if you develop a script with all these 3 calls, then it will give you what you need. We also have PowerShell example scripts for all of these in our API documentation page.

I see, idea was not to give "Host/client" any access to password lists, only it should be able to create host object. It will not be the case I guess.. Thanks for the suggestions, will try to figure it out somehow

[support]

Hi,

 

If you want, you can also put the IP Address in the Host Name field - sorry, this was what I was trying to communicate initially.

Regards

Click Studios

[Azkabahn]

30 minutes ago, support said:

Hi,

 

If you want, you can also put the IP Address in the Host Name field - sorry, this was what I was trying to communicate initially.

Regards

Click Studios

 

Sure, I know, I have done this before, however then I have issue that discovered account is saved with "IP" as Hostname/Title which is not that cool also, I mean usually users will search for a password using hostname of machine.

So basically there would be 2 solutions for this issue.

1. Make it possible for Discovery job to use "Internal/external IP" field on account discovery (I guess not gonna happen )

2. Make Discovery Job "append" Title field from host to password object (so you would be able to search for a password using hostname OR IP address)

[Azkabahn]

Just a quick thought, we are fine even if "HostName" will be added in password notes, that works too (since password state will be able to find that particular password using hostname and/or IP)

[support]

Hello Azkabahn,

 

Thanks for the detail, but at this stage we have no plans to change this functionality. All we can suggest is your look into your DNS issues so that you can rely on it, and use a proper Host Name instead of an IP Address.

Regards

Click Studios

[Sarge]

20 hours ago, Azkabahn said:

Sure, I know, I have done this before, however then I have issue that discovered account is saved with "IP" as Hostname/Title which is not that cool also, I mean usually users will search for a password using hostname of machine.

 

Simple solution, add a custom field to your password list and populate it with the hostname via API. Your script could easily perform a reverse lookup on the IP of the host record, then populate the custom field with your hostname.

However you should be doing everything via FQDNs anyway. Having poorly functioning DNS in an environment is not good, regardless of OS platform. I'd be looking to fix DNS.

[Azkabahn]

Just now, Sarge said:

Simple solution, add a custom field to your password list and populate it with the hostname via API.

Thanks for a suggestion, but I'm not allowing "client" to access passwords, it is only able to add himself to Hosts

Probably I'll need to live with searching by IP at least for some time,  keep in mind that any field that is inherited from Host ---> password would be appreciated in future releases