Discovery Job for Linux

[Azkabahn]

Hi,

 

i am using discovery job for windows machines which are joined to AD. Now, I want to use discovery job for linux machines as well. The issue is that linux servers are not joined in the domain, although they use AD authentication. What would be the workarounds or suggestion how to import and update regularly hosts in passwordstate.

[support]

Hi Andreas,

 

I think you a referring to a Host Discovery Job here, as opposed to an account discovery job for local Linux accounts - is that correct?

If so, Linux Hosts can still be added to AD without being joined to the domain, or if you store this data somewhere else, then you could import new host records via our API. Hopefully one of these options would help?

Regards

Click Studios

[Azkabahn]

Hi,

 

i have figured it out. Our own script automatically will add hosts to PasswordState via API. Another questions, I have successfully added several hosts, account discovery works fine as well. Now, is there a way to assign a default password reset script instead of clicking on each discovered account and selecting which script to use?

 

 

[support]

Hi Andreas,

If you are using our Account Discovery Jobs for Linux accounts (or any type of Job), then it should automatically assign a Reset Script and Account Heartbeat script at the time off adding records into Passwordstate.

 

Are you using these, or are you using your own API script to add passwords records - if so, you need to specify which scripts to be used in your API call.

 

Regards

Click Studios

[support]

Hi Andreas,

 

To follow up on this, "ScriptID" and "ValidationScriptID" are the two options to set in your script to assign a Reset or Heartbeat script.  The values of these can be found in Passwordstate Administration under Powershell scripts, and you'll need to toggle the Web API ID 's as per below two screenshots:

 

 

 

[Azkabahn]

HI,

 

it's a bit confusing, but let me start from scratch:

• I add Linux host via PasswordState API
• As an account discovery job, I select "Linux and Mac Accounts Discovery Job"
• I configure that job to discover only "root" account
• I run the script and it successfully adds the record into "Linux Account" password list.
• In "Password Reset Scripts" section I have added my own script with the name "Change root pass Linux"

Now, the issue is that I have a record in my PasswordList, but the assigned password reset script is not my own script. Where and how I could automatically assign that? I know it's possible to update that using bulk update functionality, but perhaps there is an automatic way for that. 

[support]

Hi Andrius,

 

Thanks for the clarification, and it is your last point which explains the situation. Unfortunately you cannot specify which Reset Script is pre-selected when using our Account Discovery Jobs.

Is there an issue with our default Linux Reset script that we could possibly help with? If you need to use your own for some reason, you can use the 'Bulk Update Password Reset' options from the List Administrators Actions dropdown list on your Password List.

Regards

Click Studios

[Azkabahn]

I see. Would you mind sharing what is the reason for not allowing to pre-select reset script? 

I will get back with the details why the inbuilt script did not work.

[support]

Hi Andrius,

 

The only reason we do't have a feature for this, is because we've never had any requests for it - as far as we can tell, our default script is sufficient.

 

Let us know if there's anything we can do to our default script which would help - keeping in mind that we cannot break any existing functionality, or add anything specific for your environment which other customers can not use.

Regards

Click Studios

[Azkabahn]

Probably because it is not widely used for *NIX.

 

Main issue is in logic when changing password for root with privileged account:

  

	#If we are using a Privileged Account credential to reset the root account (because you are not allows to SSH in with root), then the reset command needs to pass the old password value for root instead.
				#This would only be required if the Sudoers file has been modified with following command - Defaults:<username> rootpw, where Username is the Privileged Account Credential being used to reset the root account.
				if ($UserName -eq 'root') {
					$ResetCmd = "echo -e $'$OldPassword\n$NewPassword\n$NewPassword' | sudo -S passwd $UserName"
				}	
				else {
					$ResetCmd = "echo -e $'$PrivilegedAccountPassword\n$NewPassword\n$NewPassword' | sudo -S passwd $UserName"
				}								

 

As you can see it will "drop in" first if statement, because user is root (however who's password has to be changed, not account that is used to connect)

So in this statement it will do "sudo" and provide "old password" (root) and sudo on Linux is not expecting this, it is asking for privileged user password (it has sudo rights, but it needs his password)

Basically it would work if it would be in "else" clause, or first "if" would have "$ResetCmd = "echo -e $'$PrivilegedAccountPassword\n$NewPassword\n$NewPassword' | sudo -S passwd $UserName""

 

You do not need old password of root if you have privileged account that is allowed to sudo

 

Regards,

 

Algirdas

               

[support]

Hi Algirdas,

 

Thanks for the detail, and we understand how this can be an issue for you. From a programmatic perspective, it's difficult for us to provide one script to cater for the many ways all the different Linux distros can be configured.

 

We'll do some more testing to see if our logic is correct here, but we have worked with a couple of other customers in developing these scripts as well - and from their perspective it was working for them.

Regards

Click Studios 

[Azkabahn]

Hello,

 

This is why we asked for option to select which script to use. This option would let us use modified script that suits our needs.

Anyway, thank you for your help. We'll be waiting for your reply.

[support]

Possibly we can add this as a feature request for you for a future build.

 

For now, you can modify the default script, which lives in the folder /setup/scripts, and then you would have to restore this 'Default' script from within the Administration area. You you just need to review our changelog for each release to see if we update this script or not, as it will override any of your changes if we do - and then you an just apply them again post upgrade.

Regards

Click Studios

[Azkabahn]

Thanks for this workaround. We have been looking too far for such issue

 

Also, it would be great if you will consider this to add as a feature request.

[support]

Hello,

 

I just thought of something else you can do instead. If you look in the DiscoveryJobs table, you will see the ScriptID field - this is the default script we assign to newly discovered accounts. So in the Admin area you can lookup the ID for your custom script, and than manually modify this field in the DiscoveryJobs table.

Regards

Click Studios

[Azkabahn]

Hi,

 

when you say "DiscoveryJobs table" this has to be changed in the MS SQL database?

[support]

Yes, that's correct.

[Sarge]

On 3/7/2018 at 7:45 AM, support said:

I just thought of something else you can do instead. If you look in the DiscoveryJobs table, you will see the ScriptID field - this is the default script we assign to newly discovered accounts. So in the Admin area you can lookup the ID for your custom script, and than manually modify this field in the DiscoveryJobs table.

 

I could be wrong, but a quick scan of the Web API documentation, I believe you should be able to do this via that method as well, Azkabahn, as there is a ScriptID parameter.
I could be wrong because I just did a Ctrl+F for ScriptID without actually reading anything though.

 

Quote

  # PowerShell Request

    #JSON data for the object
    $jsonData = '
    {
        "DependencyType":"Windows Service",
        "DependencyName":"ustom Windows Service",
        "HostName":"win2k12server78.domain.local",
        "PasswordID":"1874",
        "ScriptID":"17",
        "APIKey":"<apikey>"
    }
    '
    $PasswordstateUrl = 'https://passwordstate/api/dependencies'
    $result = Invoke-Restmethod -Method Post -Uri $PasswordstateUrl -ContentType "application/json" -Body $jsonData

 

On 3/6/2018 at 8:05 PM, Azkabahn said:

As you can see it will "drop in" first if statement, because user is root (however who's password has to be changed, not account that is used to connect)

So in this statement it will do "sudo" and provide "old password" (root) and sudo on Linux is not expecting this, it is asking for privileged user password (it has sudo rights, but it needs his password)

Basically it would work if it would be in "else" clause, or first "if" would have "$ResetCmd = "echo -e $'$PrivilegedAccountPassword\n$NewPassword\n$NewPassword' | sudo -S passwd $UserName""

 

I'm not following what the issue with the reset script is you're encountering?

Generally speaking, most environments you can't SSH with root users, so you have to connect with a priv account, and pass the required passwords down the pipeline to sudo and passwd.

I have password resets working for our root users and for our IPA based priv account, so I'm happy to help you get it working if I can.

[support]

Thanks for your offer on the help Sarge.

 

Azkabahn, Sarge was one of the customers who helped us develop this script.

 

Regards

Click Studios

[Buckit]

On 3/11/2018 at 2:44 AM, Sarge said:

I'm not following what the issue with the reset script is you're encountering?

Generally speaking, most environments you can't SSH with root users, so you have to connect with a priv account, and pass the required passwords down the pipeline to sudo and passwd.

 

It's seems that Az has the same issue with SUDO that I was struggling with weeks ago. The constant struggle between PasswordState's demand that SUDO rules are given the "rootpw" flag, versus default behaviour of SUDO to ask a user's own password, versus the various SUDO-calls in the Linux password-reset script.

 

My case made things even more interesting because I'm using SUDO-rules stored in AD/LDAP, which has different possibilities from having SUDO-rules in /etc/sudoers.

[support]

Hey everyone,

 

Happy to announce we've released Build 8284 today, which allows you choose any reset script in the system you choose, for local accounts.  Hopefully this will help everyone who have different Linux configurations.

 

Regards,

Support

[Azkabahn]

Hi,

 

great news, thanks for that!

[support]