Security Considerations

The Kerberos authentication protocol, which is supported by Windows 2000 domain controllers and above, can only occur within a trust boundary. Kerberos authentication is the mechanism used to perform the Operations Manager agent/server mutual authentication. Agent/server mutual authentication is mandated in Operations Manager Shell for all agent/server communication.

An Operations Manager management group does have the ability to perform discovery and monitoring outside of the Kerberos trust boundary that it is in. However, because the default authentication protocol for Windows-based computers that are not joined to an Active Directory domain is NTLM, another mechanism must be used to support mutual authentication. This is done through the exchange of certificates between agents and servers.

When Operations Manager communication needs to occur across trust boundaries, such as when a server that you want to monitor lies in a different, untrusted, Active Directory domain than the management group that is performing the monitoring, certificates can be used to satisfy the mutual authentication requirement. Through manual configuration, certificates can be obtained and associated with the computers and the Operations Manager services running on them. When a service that needs to communicate with a service on a different computer starts and attempts to authenticate, the certificates will be exchanged and mutual authentication completed.

For more information about how to obtain and make use of certificates for mutual authentication, see Deploying a Gateway Server.

There are four types of Microsoft CAs:

• Enterprise root

• Enterprise subordinate

• Stand-alone root

• Stand-alone subordinate

• Both enterprise types of CAs require Active Directory Domain Services; stand-alone CAs do not. Either type of CA can issue the necessary certificates for agent/server mutual authentication across trust boundaries.

Customarily, a CA infrastructure consists of a root CA that signs its own certificates and certifies itself and one or more subordinate CAs, which are certified by the root. The subordinate CA servers are the ones that a service certificate requests, while the root is taken offline and held for safekeeping. For more information about designing certificates, see Infrastructure Planning and Design and Authentication and Data Encryption for Windows Computers.

You will use the Discovery wizard to find UNIX and Linux computers and add them to the management group as managed objects. During the Discovery wizard process, Operations Manager has the discovered UNIX and Linux computer generate a self-signed certificate which is used for mutual authentication with the management server. The certificate generation, signing and exchange process works like this when SSH discovery is enabled:

1. The Discovery Wizard process on the management server has the discovered UNIX or Linux computer generate a self-signed certificate.

2. The discovering management server issues a get certificate request to the UNIX or Linux computer.

3. The UNIX or Linux computer returns the certificate to the management server

4. The discovering management server creates a key pair and a self-signed certificate of its own. The management server only generates a key pair and a self-signed certificate when it discovers its first UNIX or Linux computer. The management server then imports its own certificate into its trusted certificate store. The discovering management server then signs the UNIX or Linux certificate with its private key. Any subsequent signing of UNIX or Linux computer certificates by the management server will reuse the management server’s private key that was generated on the first signing.

5. The discovering management server then issues a put certificate request which puts the now management server-signed certificate back onto the UNIX or Linux computer that initially generated it. The UNIX or Linux computer WSMAN communication layer is then restarted to make the new UNIX\Linux computer generated certificate active.

6. Now when the management server requests that the UNIX or Linux computer authenticate itself, the UNIX or Linux computer will provide the trusted certificate to the management server and the management server will read the signature on the certificate that it is presented with, see that it trusts this signature (because the signature is its own private key that is stored in its own trusted certificate store) and accept this certificate as proof that the UNIX OR LINUX computer is who the management server thinks it is.

7. The discovering management server will use UNIX or Linux credentials as configured in the appropriate Run As Profile to authenticate itself with the UNIX or Linux computer. See the Planning for UNIX or Linux Run As Profiles section for more details.

After the UNIX or Linux computer is being managed by the discovering management server, the management pack discoveries and workflows begin to run. These workflows require the use of credentials to complete successfully. These credentials, what objects, classes or group they will be applied to and the computers that they will be distributed to are contained in Run As Profiles. There are two Run As Profiles that are imported when the UNIX management packs are imported into your management group; they are:

• Unix Action Account profile – This Run As profile and its associated UNIX or Linux credentials are used for low security activities on the designated UNIX or Linux computers.

• Unix Privileged Account profile – This Run As profile and its associated UNIX or Linux credentials are used for activities that are protected by a higher level of security and therefore require an account that has higher privileges on the UNIX or Linux computer. This can be (but does not have to be) the root account.

You will need to configure these profiles with the appropriate UNIX or Linux computer credentials for the management pack workflows that use them to function correctly.

Operations Manager controls access to monitored groups, tasks, views, and administrative functions through the assignment of user accounts to roles. A role in Operations Manager is the combination of a profile type (operator, advanced operator, administrator) and a scope (what data the role has access to). Typically, Active Directory security groups are assigned to roles, and then individual accounts are assigned to those groups. Prior to deploying, plan out Active Directory security groups that can be added to these and any custom-created roles so that you can then add individual user accounts to the security groups.

Operations Manager provides the following role definitions out-of-the-box.

You can add Active Directory security groups or individual accounts to any of these predefined roles. If you do, those individuals will be able to exercise the given role privileges across the scoped objects.

Operations Manager also allows you to create custom roles based on the Operator, Read-Only Operator, Author, and Advanced Operator profiles. When you create the role, you can further narrow the scope of groups, tasks, and views that the role can access. For example, you can create a role entitled "Exchange Operator" and narrow the scope to only Exchange-related groups, views, and tasks. User accounts assigned to this role will only be able to run Operator-level actions on Exchange-related objects.

Individuals in your company that will interact with Operations Manager frequently, such as an Exchange administrator who has been assigned to the Exchange Operator role, need a way to discover new alerts. This can be done by either watching the Operations console for new alerts or by Operations Manager informing them about the alert via supported communications channels. Operations Manager supports notifications through e-mail, instant messaging, Short Message Service, or pager messages. Notifications on what the role needs to know go out to recipients that you specify in Operations Manager. An Operations Manager recipient is merely an object that has a valid address to receive the notification, such as an SMTP address for e-mail notifications.

Therefore, it is logical to combine role assignment with notification group membership via an e-mail-enabled security group. For example, create an Exchange Administrators security group and populate it with individuals that have the knowledge and permissions to fix things in Exchange. Assign this security group to a custom-created Exchange Administrator role so they have access to the data and are e-mail-enabled. Then, create a recipient by using the SMTP address of the e-mail-enabled security group.

At the time of deployment, you need to have the following service accounts ready. If you use domain accounts and your domain Group Policy object (GPO) has the default password expiration policy set as required, you will either have to change the passwords on the service accounts according to the schedule, or use low maintenance system accounts, or configure the accounts so that the passwords never expire.

When you deploy Operations Manager, you may need to register a Service Principal Name (SPN) in some configurations. SPNs are used by Kerberos authentication for the client to mutually authenticate with the server. For more information, see What Are Service Publication and Service Principal Names?.

When you install Operations Manager, you select an account for the System Center Configuration service and System Center Data Access service. For more information, see Deploying System Center 2012 - Operations Manager.

If you select the Local System as the System Center Data Access service account, the account can create the appropriate SPN. No additional configuration is necessary.

If you use a domain account, you must register an SPN for each management server. Use the SETSPN command line tool. For more information about running that tool, see Setspn Overview.

Register both the netbios name and fully qualified domain name of the management server, using the following syntax:

setspn –a MSOMSdkSvc/<netbios name> <DAS account domain>\<DAS account name>

setspn –a MSOMSdkSvc/<fqdn> <DAS account domain>\<DAS account name>

If you are using Network Load Balancing or using a hardware load balancer, the System Center Data Access service must run under a domain account. In addition to the setup already described, you must also register the load balanced name, using the following syntax:

setspn –a MSOMSdkSvc/<load balanced name> <DAS account domain>\<DAS account name>

Agents on monitored computers can run tasks, modules, and monitors on demand as well as in response to predefined conditions. By default, all tasks run by using the Agent Action account credentials. In some cases, the Agent Action account may have insufficient rights and privileges to run a given action on the computer. Operations Manager supports the running of tasks by agents in the context of an alternate set of credentials called a Run As Account. A Run As Account is an object that is created in Operations Manager, just like a recipient is, and maps to an Active Directory user account. A Run As Profile is then used that maps the Run As Account to a specific computer. When a rule, task, or monitor that has been associated with a Run As Profile at the development time of a management pack needs to run on the targeted computer, it does so by using the specified Run As Account.

Out-of-the-box, Operations Manager provides a number of Run As Accounts and Run As Profiles, and you can create additional ones as necessary. You may also choose to modify the Active Directory credentials that a Run As Account is associated with. This will require planning, creating, and maintaining additional Active Directory credentials for this purpose. You should treat these accounts as service accounts with respect to password expiration, Active Directory Domain Services, location, and security.

You will need to work with management pack authors as they develop requests for Run As Accounts. For more information, see the Index to Security-related Information for Operations Manager.