CheckRights

The script is meant to automate the process for an Administrator to check if a user has explicit rights assigned to a file or Directory across several OES2Linux servers. There are 2 versions of the script PLEASE READ the information at the bottom regarding the 2 versions.

The Practical purpose of it is to accommodate scenarios where a user is terminated or for whatever reason is not allowed file access, however his userID has to remain somewhere in the tree for X time period. The fact that his object still resides in the tree means that his right assignments are all still active.

This script will allow you to find their file access across multiple servers and volumes.

How it works

The script goes through 2 stages:

1 - By gathering all the trustee info from the selected servers and combining them into one XML file
2 - By running an XSLT stylesheet against the XML file and parsing out the user in question

Prerequisites:

- Must be run on a Linux platform... SLED, SLES, OES2, OPenSuse.
- xsltproc installed
- ncpmount installed (required for NCPmount version)
- sshpass (search for it on Google, required for the SSH version)

The top two utilities were installed by default on the Linux platforms I tested.
You can check for the above 2 programs by simply typing them in. You should get a help screen from both.
The third utility "sshpass" I found for my distribution (SuSe) from a google search

Caveats:

- This will only work against OES2Linux NSS volumes

- User names used for querying can not have spaces in them. For example:
--- .test1.homeoffice.corp : Good
--- .test1. home office.corp : Fail

- If the file name or Directory contains an "&" the report will show the name of the file/directory as AMP. Example file called test&1 will be shown as testAMP1

To Run:

- Expand all the files into one Directory
- Create a mount directory (only needed for the ncpmount version)
- Make sure the "checkrights2.sh" script is executable
- You need to run as root or equivalent as the script calls xsltproc which can't be run by normal users
- The stylesheet, the input file, both need to be in the same directory where you run checkrights2.sh from
- The outputs will be put into the same directory
- User syntax and file names are all case sensitive

When you run the script you have the option of gathering the trustee report or running a query against the trustee report for a particular user.

Gathering the Report:

You will need to setup an input file with the names of the servers and volumes you need to check. This is probably the most cumbersome piece of the process. I included an example one. The format of the input file is critical...

Servername:Volume:Resolvable DNS name or IP address

*** Note *** you can not have any lines that are just spaces including the last line. In other words each line must be a valid entry

***Note*** The Volume name must be in uppercase

Once the report is gathered you can use it multiple times to run queries against it

Querying the Report

You will need to know the name of the report run in the previous step
As well as the user you are searching for. The user is in format:
.user.ou1.ou2.O
The user name is case sensitive, has a leading Dot, and can not have any spaces in the name.

Potential Issues

- if your input file has incorrect data, the script will try and connect to the server noted in the input file and fail, it will then simply move on to the next and you will
see the failure on the screen

- Entering the user for the query is challenging at times. It has to be exactly as it is in the report file. Sometimes to make it easy I'll just open the report file with a text editor and search out the user, then copy and paste it into the response. That way I'm guaranteed of the format and the script can then successfully search the entire report.

The Two Versions

I have 2 versions of this utility. One uses an "ncpmount" mechanism to gather the info using an eDirectory admin. The other uses a SSH mechanism using a Linux Admin.

The prefered version is the SSH version, however this requires a Linux Admin user and some environments will not allow eDirectory Adminstrators to have that info.

If using the ncpmount version PLEASE NOTE , there is a possibility (via an uneducated user) of causing data loss. If the script is forcibly stopped part way through and the ncpmount to the volume was not "unmounted" an uneducated user may see the mount point and try and remove it... ie "rm -r mountpoint". This will effectively delete the volume data. The safe way is to perform a manual "ncpumount mountpoint"

The SSH version will not have this issue


Final Notes

I hope you find this tool useful. I've been asked many times for this functionality and I believe this at least full fills it somewhat.

To Download Goto --> http://ginohm.webs.com