Jump to content

Discovery Job for Linux


Azkabahn

Recommended Posts

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

 

psreset4.png

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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:

 

2018-03-06_11-18-23.png

 

2018-03-06_11-18-08.png

 

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

               

Link to comment
Share on other sites

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 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...