psilva
 
Posts:81
 |
| 03/23/2006 2:46 AM |
|
Hello,
CA has the idea that who manages NSM is a System administrator, this is not always the case.
I need to know in detail what Rights and permissions in the OS and SQL a user(s) will have to have to install and remotly manage NSM.
Regards
Pedro |
|
|
|
chris.poole
Posts:54
|
| 03/24/2006 6:03 PM |
|
| Pedro, you need to detail exactly what you mean by manage... I have it configured so that help desk and systems admins can log into NSM but not delete objects or change map settings. If this is what you are after, you simply need to create an SQL user with read only rights tne install the client and select the CORe and when requested for the database info, enter then read only user info. Hope this helps. |
|
|
|
psilva
Posts:81
|
| 03/27/2006 10:35 AM |
|
| Thanks . Regarding SO user do you know why caunint must be a local admin account ? What specific previleges does the user needs. CA only says that it must be a local admin acount..... |
|
|
|
chris.poole
Posts:54
|
| 03/28/2006 10:01 AM |
|
| What do you mean by "SO user"? (sorry I may be dense this morning...) |
|
|
|
psilva
Posts:81
|
| 03/28/2006 10:29 AM |
|
| Sorry.. OS ,.operative System user |
|
|
|
chris.poole
Posts:54
|
| 03/28/2006 10:53 AM |
|
Caunint is only installed on DSM/WV servers and is required to have administrative rights to maintain and control the Unicenter services. If a DSM/WV servier is being built, I would assume a Systems Administrator level user in the Unicenter Group is building the DSM.
Past experience has given me the opinion that normal SA's are better off NEVER touching my DSM's. The product is too complicated, they don't know and really do not want to learn it. Besides, one aspect of this product is to supervise your Administrators, if they fight about giving you access, it is a good bet they are doing things (non standard) that they do not want discovered. May upset a few SA's here, sorry, But 10 years with this product has shown that it is not loved or wanted by most SA's... |
|
|
|
psilva
Posts:81
|
| 03/29/2006 2:45 AM |
|
You are so right. But that's what we are trying to change. We have to work and get along with SA's. If they own the machine, and the responsability of the HW, backups, Oper. System and SQL is theirs, we have aggree that it's normal that they don't want you to have admin rights over it. We are trying to see if this scenario is possible and not utopic.
If you install NSM and you don't really know why you need a local admin account (caunint) this is bad. You can have service accounts and no be a local admin. We need to have this access and permissions in detail.
I'm getting the idea that I looking for the impossible.....lol.
|
|
|
|
chris.poole
Posts:54
|
| 03/29/2006 10:26 AM |
|
Here are all the reasons why that I can find or think of... I hope this helps...
Commands executed at the Unicenter Console are run under the user that starts the "CA-Unicenter" service. By default, this user is called "caunint".
The caunint account needs to be a member of the Administrators' group and have the following privileges:
Act as part of the operating system
Replace a process level token
Log on as a batch job
Log on as a service
Increase quotas
If you use remote monitoring then:
a. CA Remote Monitoring service should be started with a single
Domain Administrator account, which validates on all servers
you want to monitor.
b. The administrative account must have local administrative access
to the resource and, therefore, must be a part of the local
systems administrator group or Domain Active Directory equivalent.
c. If different accounts or domains are required, then additional
agents should be installed.
d. The logon account for the service should be specified as
Domain\Userid\.
e. The service must have "Logon as a service" rights (or the system
will log an event log error upon starting and will not run).
By default, caunint is the user that starts Remote Monitoring.
Since caunint it is not a domain admin account, consider using
caunint as a domain account.
Then finally, the info from the manual "Inside Event Management and Alert Management" page 72:
Users Authorized to Run Commands
You can specify the users and user groups in your enterprise who can enter
Event Management commands, acknowledge held messages, and reply to held
messages when Security Management is not active. Use the environment
variable CA_OPR_AUTH_LIST. This variable is ignored when Security
Management is active.
Note: Because of security concerns, you may want to limit the users who can
run commands on Event Managers and Agents to the administrator ID.
When specifying users and groups, consider the following information:
To set this variable, use the following tools:
– Windows: Configuration GUI or cautenv utility
Note: You can see the current settings for all environment variables
by entering "cautenv dumpini."
– UNIX/Linux: $CAIGLBL0000/opr/config/node/actnode.prf file
– Any operating system: Unicenter Configuration Manager product
The original user is the one who installed the product, usually
Administrator@localcomputer.
By default, commands are executed by the Enterprise Management user
account caunint, which is created at installation. This user must have
permission to run commands locally and remotely.
If any users or groups already had permission, you must reenter them if
using cautenv. Any previous list is replaced, not appended.
Separate users and groups with commas and no spaces.
If you do not include a node name with a user or group, permission is
given for all nodes. (Specify node names like this: User03@node09.)
You can use wildcards in the names of users, groups, and nodes. Use * to
indicate zero or more characters, and ? to indicate one character.
To identify a user group, precede it with an ampersand, for example,
&Administrators.
To give CA_OPR_AUTH_LIST no value, enter NULLSTRING. This gives
everyone permission to run commands.
What does all this mean? CAUNINT must be an Administrative acount in order to start and stop services, a domain or local account on each server in order to remotely monitor or start/stop services and must be a domain admin account inorder to Execute M/A Actions on local or remote servers... |
|
|
|
psilva
Posts:81
|
| 03/30/2006 7:39 AM |
|
Thanks a million. That's a lot of usefull info.
What about cadb userid (CAI_DBUID).
To change this user what do I have to do ? Besides setting in EM settings for the new user and password , and grant dbo access to the new user in SQL NSM Databases?
I already tested and add permission issues with severity propagation that cannot connect to repository....
|
|
|
|
psilva
Posts:81
|
| 03/31/2006 2:53 AM |
|
After NMS 3.0 0211 installation the following users are created .
In SQL :
Cadb
Tng
Tngsa
Tngdev01\Tndusers - Windows Group
In Windows
User Caunint - local administrator
Tndusers - Windows Group (created empty)
SeverityPropagation - local administrator - Distributed COM configurations object for CA-Unicenter NSM
As far as SQL users can't find in CA documentation which process use this users and credentials. For cadb I only found what I posted before.
For Tng and Tngsa I found nothing.
|
|
|
|
psilva
Posts:81
|
| 04/28/2006 7:44 AM |
|
Can we change the password credentials for users TNGSA, TNG, CADB (for this one change also EM settings CAI_DBUID) without having security issues afterwards? Notice that these users are created during NSM installation?
Does anyone knows the password for the user SeverityPpropagation ? Also created during NSM installation?
Thanks |
|
|
|
chris.poole
Posts:54
|
| 05/02/2006 9:44 AM |
|
| It should not be an issue, as long as you change it in all required locations. As for SeverityPropagation it is a system generated password, check with CA on this one. |
|
|
|
psilva
Posts:81
|
| 05/26/2006 7:32 AM |
|
I'm trying to restrict operating system access credentials and I'm getting the following return code while executing the cmd awservice status. I'm only a power user in windows2000 server .
unable to open SC Manager for "awservices" service - Access is denied. (0x5)
What rights must I have to execute this cmd?
Thanks
Pedro |
|
|
|
chris.poole
Posts:54
|
| 05/26/2006 12:23 PM |
|
You seem to be trying to lock yourself out of using this application!!! The big thing to remember here is that these apps monitor the OS, interact with the OS and it should be assumed that to do this THEY ARE PART OF THE OS... Sorry, I have to fight over this all the time as it does not seem to be clear to your average Security Admin...
0x5 is access denied. If the opnum 0xF fails with 0x5, the user does not have permissions to the service control manager. This can be corrected by modifying the permissions with the “sc sdset SCMANAGER” command, or by giving Read and Write permissions to the user accounts that have permission to run awservices and SC in group policy.
|
|
|
|
psilva
Posts:81
|
| 05/29/2006 4:45 AM |
|
The problem is that I'm not the server owner so my access will have to be restricted. I'll try to change permissions policy.
Thanks
|
|
|
|