Frank, try the following configuration:
Leave 'users' blank.
<appserver dns name> ro
The exports file will then allow only the application server to access that box, but will give on real privileges, as it will only have read-only access. Users.local will allow RBACAdmins:RBACAdmin to push ACLs to the box once the box is added to the proper resource profiles. For added security, you may want to add a line into the 'users' file: nouser. This ensures that no one will be able to access the server unless their name is in the users or users.local files. Of course, your exports settings already take care of this, but this is extra secure. The nouser line will be over-written when pushing ACLs, but will be appened to the bottom of the new users file.
cheers Brad, I'll give this a go.
As a best practice, I like to create a reference version of the following files and copy them into the rsc directory after installing the agent:
- users.local (different for Windows & Unix)
After the server has been fully added to BladeLogic (properties & resource profiles) and ACLs have been pushed. I like to run a "Harden BladeLogic" job that copies new exports, secure and users.local to the server.
So once you pushed the ACL's isn't this enough to harden your agent? What else does the 'Harden BladeLogic' bit do?
It pushes a new exports and users.local Those files are not covered by ACL pushes... Only the users file is pushed during ACLs.
ok, so the users file has the latest ACL information but I thought the 'users' file overode whatever settings are defined in the 'users.local' and 'exports' files?
I take it from what you imply that there are still some security vunerabilites outstanding if the other two files remain in a certain state.
What I've done recently to make it slightly easier to manage my exports and users.local files is create NSH scripts that perform an echo to update them. For example, instead of peforming a new file deploy each time I make a make a modification to either one of these files, I go into my NSH Script and modify what is being echoed.
echo "* ro" > /usr/lib/rsc/exports
echo "RBACAdmins: /usr/lib/rsc/users.local
In our current environment we have a role configured to maintain these scripts, and that role shares the NSH script job to another role responsible for maintaining environment consistancy.
The users file does not override users.local and exports. It complements them.
Think of the exports file as the gatekeeper. It summarily allows/disallows users access to the system based merely on the hostname of the originating computer. If you are clear proxying through the application server while in NSH, then the exports file need only have the application server as the allowable hostname (plus any individual exceptions). This is more secure and makes for simpler handling.
The users and users.local file complement one another. The main difference is that users.local does not get overridden by an ACL push. As to which one takes precendence, I am not entirely sure. Aside from RBACAdmins:RBACAdmin in the users.local files, some BL administrators like to keep their own username as they access the box from NSH, just to ensure that they have continued access in the event that something may clear their ACLs.
Good explanation Brad.
I just wanted to add that users.local always takes precedence over the users file.
So would if fair to assume this is a secure configuration to leave on all agents distributed thought a server estate?
Users.local's information contained therefore allows RBACADMins to overide the READ-ONLY access specified in the exports file?