3 Replies Latest reply on Nov 17, 2005 5:27 PM by Michael Mraz

    Grammar to audit / repair only one field in /etc/shadow

    Erik Johannessen

      Is it possible to write a grammar that would only update / audit the hash field of the /etc/shadow file ? I am trying to find the best way of making sure the hash value of root's password is the same on a number of solaris boxes, but the /etc/shadow grammar checks all the fields...


      Any ideas?

        • 1. Re: Grammar to audit / repair only one field in /etc/shadow

          When managing config files, we read and write the entire line based on the line's unique key/identifier. So, while you could write a grammar to read only one field from /etc/passwd, the write would blow away what's there and only write that one field to the line, which I believe would break /etc/passwd.


          So, I don't think this is possible today, but I know this is something that has been discussed for the upcoming release. I would suggest logging a request with support.

          • 2. Re: Grammar to audit / repair only one field in /etc/shadow

            I don't know if this would be possible, and it would take a LOT of overhead to set it up, but it might work in an automated fashion.


            1. Build a BLPackage to represent the "root" line in /etc/shadow. Represent each value with a server property (SHADOW_HASH, SHADOW_BLAH, etc).


            2. Build a BLCLI automated process to do the following:

            A. Loop through each server and set the properties in question by reading the existing shadow file.

            B. Set the SHADOW_HASH on all servers to the new value.

            C. Deploy the BLPackage to all servers.


            So I think you could automate it, but you'd probably be better off using a chpasswd script of some type where you generate the hash centrally and then deploy it to all servers.

            • 3. Re: Grammar to audit / repair only one field in /etc/shadow

              If you don't need the audit results, only consistency, then overwriting with the same value for the crypt string is harmless. As such a script job that uses sed or perl -pi -e 's/^root:.

              :/root:??NEWCRYPTSTRING??:/' /etc/shadow


              Yes, I know that isn't exactly right and you may need to pass the property as a parameter to an NSH script job and call perl from within that. But, you get the idea. You could even check if the value doesn't match and throw a non-zero return code for the nsh script. That would make it easier to spot hosts that got updated.