We're beginning to get a few more requests from manager-types along the lines of, 'who has access to my stuff,' and, 'how are rights set up in my shared areas?'
It's pretty easy to give them a list of which groups have rights to what directories. What isn't so easy is explaining how trustees work, inheritance, and how rights-filters (which we use in a few key areas) affect flow. Plus, NDS rights factor into this significantly and those aren't presented on the file-system.
I'm pretty sure that we'll get a request from a high level manager to develop a system that will allow managers to see who as rights to their areas. Not just groups, but a full de-referenced list of users for who has rights to a specific directory and what those rights are. We'd also have to provide a second column next to each user showing what groups they got their rights from and where said right was assigned.
In other words, a big ole mess.
There is a reason we've tried to keep the managing of rights to be as much of a black-box as possible. I fully understand how they work. But explaining that to managers would require, IIRC, Day 2 of the Certified NetWare Administrator class.
What makes it even more fun is that we use IIS for some of our web-development, and we use rights there. Rights flow on Windows is different than on NetWare. Explaining THAT will take even more happy-fun meeting time.
Tags: netware, rights
It's pretty easy to give them a list of which groups have rights to what directories. What isn't so easy is explaining how trustees work, inheritance, and how rights-filters (which we use in a few key areas) affect flow. Plus, NDS rights factor into this significantly and those aren't presented on the file-system.
I'm pretty sure that we'll get a request from a high level manager to develop a system that will allow managers to see who as rights to their areas. Not just groups, but a full de-referenced list of users for who has rights to a specific directory and what those rights are. We'd also have to provide a second column next to each user showing what groups they got their rights from and where said right was assigned.
In other words, a big ole mess.
There is a reason we've tried to keep the managing of rights to be as much of a black-box as possible. I fully understand how they work. But explaining that to managers would require, IIRC, Day 2 of the Certified NetWare Administrator class.
What makes it even more fun is that we use IIS for some of our web-development, and we use rights there. Rights flow on Windows is different than on NetWare. Explaining THAT will take even more happy-fun meeting time.
Tags: netware, rights
PERL will be your friend, should that hateful day ever occur. Novell has a whole bunch of API information and libraries for PERL, among other languages, and I'd imagine it would be the easiest way to produce that kind of list.Hey, if you develop it, post the code! ;)
I don't envy your position, but the company I work for has had the same requests in the past 6 months, prompting me to tackle that whole project in a 100% Windows environment.The best thing to do is definitely simplify things as much as possible. I don't ever have to really explain inheritance (other than to complicated application development shares) because I don't otherwise allow broken inheritance. If something needs to be different inside a share, it needs to be made into a new share.Like Novell, you can only display Windows shares open to those users by installing ABE (Access-based enumeration) on Windows 2003 SP1+ servers.I also do make sure (and this is new for our company) that all shares are given permissions by descriptive groups, so that I don't have to audit an entire file server to get permissions, I can just eyeball the Active Directory groups that person is a member of.This has been the start, and so far after all of this re-arranging of policy I can pull reports manually for those questions you ask, but eventually perhaps I can get the company to spring for something like ScriptLogic's Enterprise Security Reporter. Or scripting to regularly renew inheritance from where Windows copying breaks it (go Windows!).
We just don't share home directories. We have shared directories set up for each department. If someone asks me who has access to what, I make them sit with me to go through each parent directory that might have specific trustees on it. Generally, people might be less apt to ask those questoins if they lose their valuable time along with yours. Although, file system audits aren't the worst thing out there. I do a quit look over from time to time, but my organization is small enough that it is a viable option.But for a viable option, how about running trustbar or whatever it's called in netware 6.5? I used it to "save" the trustees for each volume when I did my NDS8.85>eDirectory8.7.3.7 this summer on my 5.1 boxes. It basically dumps out a plain text xml file of all the trustees on each volume you run it on. From there, you have easy access to the data you need. You can parse it out using whatever tool you're comfortable with. Hell, even excel might work. From there, it's a simple alt-f3 search for the requested directory name string. Easier said than done, but it might be an option.