1 2 Previous Next 23 Replies Latest reply on Sep 11, 2014 8:48 PM by Bill Robinson

    extended object/script for "chage" cmd must run as root

    Vernon Whicker

      I am trying to create an extended object that runs the below CMD. The object runs correctly and returns the information for the user (root). The issue that I am having is i will need this information for many users and do not want to create an extended object for each one. When I tried putting this in a script the script will not run as a user is not root.

       

       

       

      CMD- chage -l (user)

       

      script- Lives on application server, wont run locally or when called by an extended object. Will only run via nsh when logged on as root.

      #!/bin/bash

      #

      # Name          : pwdpolicy.nsh

      # Description   : Liberty Mutual - [Linux] Print password policy for user (chage -l $user)

      # Version       : 1.0

      #

      # Who           When            What

      # ------------- --------------  -------------------------------------

      # 12 March 2014   Used for HSA-Cyberark Project to retrieve password policy for all users

      #

      #

      nexec -i -e bash

      cat /etc/passwd | while read line

      do

              user=`echo $line | awk -F: '{print $1}'`

              echo "User=$user"

              pwdchg=`chage -l $user | grep -i "Last Password Change" | sed 's/: /:/g' | awk -F: '{print $2}'`

              pwdexp=`chage -l $user | awk '/Password expires/' | sed 's/: /:/g' | awk -F: '{print $2}'`

              pwdact=`chage -l $user | grep -i "Password inactive" | sed 's/: /:/g' | awk -F: '{print $2}'`

              actexp=`chage -l $user | grep -i "Account expires" | sed 's/: /:/g' | awk -F: '{print $2}'`

              minday=`chage -l $user | grep -i "Minimum number of days" | sed 's/: /:/g' | awk -F: '{print $2}'`

              maxday=`chage -l $user | grep -i "Maximum number of days" | sed 's/: /:/g' | awk -F: '{print $2}'`

              warndy=`chage -l $user | grep -i "Number of days of warning" | sed 's/: /:/g' | awk -F: '{print $2}'`

       

       

              echo "Last Password Change=$pwdchg"

              echo "Password expires=$pwdexp"

              echo "Password inactive=$pwdact"

              echo "Account expires=$actexp"

              echo "Minimum number of days between password change=$minday"

              echo "Maximum number of days between password change=$maxday"

              echo "Number of days of warning before password expires=$warndy"

      done

      exit 0

      ~

        • 1. Re: extended object/script for "chage" cmd must run as root
          Joe Piotrowski

          To my knowledge, these are all Unix Users server objects. Why not simply use those for whatever your need is? Is this for compliance?

          • 2. Re: extended object/script for "chage" cmd must run as root
            Vernon Whicker

            Yes this is for compliance. Not sure about the server objects. The cmd is used to list/change password expiration. When I get in tomorrow I will take a look at your suggestion.

             

            Sent from my iPhone

            • 3. Re: extended object/script for "chage" cmd must run as root
              Vernon Whicker

              Hello Joe,

               

              As far as the Unix Server Object approach can you please clarify. The chage CMD uses the locked down /etc/shadow file and basically pulls out the encypted data out. If there is a way to make any scripted cmd run as "root" from any role that should fix my issue. In this case the permissions for the /etc/shadow require root access. I need the cmd to run as though I have "nexec -i -l" onto each server instead of running as the role I am executing the script as.

               

              thanks

              • 4. Re: extended object/script for "chage" cmd must run as root
                Bill Robinson

                I think what joe is saying is there is already an object in bsa that shows this info:

                 

                so instead of writing a script, you can have your compliance rule act directly on the attributes of the UnixUsers object.

                • 5. Re: extended object/script for "chage" cmd must run as root
                  Vernon Whicker

                  ok that clarifies thing...I'll validate in my environment. Thank you!

                  • 6. Re: extended object/script for "chage" cmd must run as root
                    Vernon Whicker

                    Hey Bill,

                     

                    I took a look. THe issue I have with this object is that the values appear to be different that the information that is returned with the "chage -l" CMD. The CMD is the way that our security team is managing the passwd information and they are not familar with the way the "Unix Users" information coorilates with the CMD values returned. Here you see that for the "password expires", "Password INactive" and "Account expires" have a "NEVER" Value.

                    I am making the assumption that the "Experation Date", "Inactive Limit (DAYS)", and I dont see an "Account Expires" equivilant would be the "UNIX USERS" values for the CMD Values. Our security team is setting the requirements for an automation project to manage the password via a compliance job and remediation job. The "CHAGE -l " CMD are being identified as requirements. Capture.PNG.png

                     

                    Here are the requirements for the compliance I need......In order for this to work I need to know that this data is correct from the extended object. We are looking for "NEVER" as compliant. THe "Unix Users" Values are inconsistant with the dates retrieved so I dont see that any single date for either "Password expires" or "Password inactive" through the "Unix Users" matching up with "NEVER" from the "chage -l" CMD. Can you help me understand how the "Unix Users" is pulling this data.

                     

                    Password expires : never
                    Password inactive : never
                    Minimum number of days between password change : 0
                    Maximum number of days between password change : 999989
                    disable_firstupper_lastdigit_check: enabled
                    • 7. Re: extended object/script for "chage" cmd must run as root
                      Bill Robinson

                      i think the 'expiration date' is the account expiration.  i'm not sure if we pull the passwd inactivity or expiration via unix users - it looks like no.

                       

                      if you are trying to run your original script as an extended object you need to pass in the target as an arg to use w/ the nexec and i don't think you will be able to nexec bash - that's going to start a shell.. so maybe you should try this in the nsh script instead:

                       

                      EO definition like:

                      nsh -c "/your/script.nsh" ??TARGET.NAME??

                       

                      and we can make the script a bit more efficient

                      #!/bin/nsh

                       

                      target=$1

                       

                      while read user

                      do

                      echo "User=${user}"

                      nexec -n -i -l ${target} sh -c "chage -l ${user}" | awk '{$1=$1; print}' | sed "s/ : /=/g"

                      done <<< `awk -F: '{print $1}' //${1}/etc/passwd`

                      exit 0

                       

                       

                      now, depending on how you want to do this you might want to use the ini grammar file in the EO and have the output like like

                      [username]

                      blah = blah

                       

                      that would look like this i think

                      #!/bin/nsh

                       

                      target=$1

                       

                      while read user

                      do

                      echo "[${user}]"

                      nexec -n -i -l ${target} sh -c "chage -l ${user}" | awk '{$1=$1; print}' | sed "s/:/=/g"

                      done <<< `awk -F: '{print $1}' //${1}/etc/passwd`

                      exit 0

                      • 8. Re: extended object/script for "chage" cmd must run as root
                        Joe Piotrowski

                        Our tool has to configure/manage different types of server objects from very different operating systems. So sometimes our product handles objects slightly differently.

                         

                        For example, maybe you're looking for a server object with a Disabled/Enabled state on the server, but in BSA it's coming in as a 0/1 value.

                         

                        I suggest right mouse clicking on a Unix User and selecting Add To Depot As > BLPackage. Then go open that package to see how we're handling values for that user object. Then you can determine if using server objects is the way to go (I find it much easier) versus writing scripts for everything.

                        • 9. Re: extended object/script for "chage" cmd must run as root
                          Vernon Whicker

                          thanks for the assistance guys...I have had the script set up as an EO see screenshots below...I did not have a variable for the target in the script for the nexec but the script executes and I get the permission denied seen below. I tried making some of the performace changes you suggested but didnt have initial success and got other errors (cant find cmd/dir)and just want to focus on getting the script to run as root. Bill to your point of adding the target I should just have to add the variable target=$1 and then update the cmd string to include the nexec and target variable correct. Is the thinking that this will make it run as work because we have tried to get this going several ways and the script will not run. Is it possible to get a webex with Z, Jason and I? Should we open a ticket first?

                          Capture2.PNG.pngCapture3.PNG.png

                          • 10. Re: extended object/script for "chage" cmd must run as root
                            Bill Robinson

                            the script needs to take an input of the target server name.  otherwise it's running as the unix 'bladmin' user on the appserver against the appserver probably.

                             

                            also, you have the grammar set to csv.  it should be name=value.

                            • 11. Re: extended object/script for "chage" cmd must run as root
                              Vernon Whicker

                              Z and I have tried in several ways to set a target variable. When we do this we get errors with the the EO acessing the CMD and or script file that lives on the application servers or the "remote host unknown" error.

                               

                              "/etc/blrelease/extended_objects/...." central execution set

                               

                              The grammer has been set to several different values including the (nsvp.gm)  the snip was just hapened to be that csv value.

                              • 12. Re: extended object/script for "chage" cmd must run as root
                                Bill Robinson

                                Can you try this:

                                1 - put the below into a file on the file server in 'storage/extended_objects'

                                ---

                                #!/bin/nsh

                                 

                                target=$1

                                 

                                while read user

                                do

                                echo "User=${user}"

                                nexec -n -i -l ${target} sh -c "chage -l ${user}" | awk '{$1=$1; print}' | sed "s/ : /=/g"

                                done <<< `awk -F: '{print $1}' //${1}/etc/passwd`

                                exit 0

                                ---

                                 

                                2 - create an EO called chage or whatever you want.  the EO should be:

                                - central execution

                                - command nsh -c //yourfileservername/storage/extended_objects/chage.nsh ??TARGET.NAME??

                                (use the correct NSH path to the location of the script on the file server)

                                - name = value grammar

                                 

                                3 - live browse this on a host

                                 

                                what happens in that scenario ?

                                 

                                if you get a 'remote host unknown' can you check to see if your appserver can resolve whatever ??TARGET.NAME?? is on the target you tried to browse ?

                                • 13. Re: extended object/script for "chage" cmd must run as root
                                  Vernon Whicker

                                  I will do bill ,

                                   

                                  I imported your script today but will try from scratch and create a new EO for testing. I will complete this tomorrow morning and post the results. Again thanks for the assistance.

                                   

                                  Sent from my iPhone

                                  • 14. Re: extended object/script for "chage" cmd must run as root
                                    Joe Piotrowski

                                    This took me about 5 mins to do in BSA.

                                    linuxUserTest.jpg

                                    You can use this to check for specific users with these values, or loop through all users.

                                     

                                    I didn't spend any time testing this. But this is where some values on the OS side equal one thing, but in BSA we might handle it differently. For example setting password expires to never in the OS = setting it to this 1969 date in BSA. Setting password inactive to never = -1 in BSA. The other options match up the same.

                                     

                                    You just have to look at the object properties and values in BSA to figure out how we're using them for checks and remediation.

                                    1 2 Previous Next