Linux agent not running scripts in SCOM

I recently encountered a situation where an otherwise functioning SCOM agent on a Linux server would not execute shell scripts to run discoveries or monitors. The problem turned out to be an incorrect configuration in /etc/opt/microsoft/scx/conf/scxrunas.conf, which controls the execution of the following extrinsic methods:

  1. SCX_OperatingSystem.ExecuteCommand()
  2. SCX_OperatingSystem.ExecuteShellCommand()
  3. SCX_OperatingSystem.ExecuteScript()

In my situation, the configuration file contained the following, which was preventing the above methods from running with elevated privileges:

AllowRoot=false

Clearing this file and restarting the agent resolved the problem.

WordPress plug-in update failure in IIS

I encountered the following error when attempting to update a plug-in in WordPress, running on IIS:

An error occurred while updating Akismet: Could not remove the old plugin.

This appeared to be a permissions problem, but as far as I was concerned, file system permissions were correct: the application pool was configured with the identity ApplicationPoolIdentity and this account, IIS AppPool\WordPress, had been granted modify permissions in the file system. This problem was perplexing, as I could make other changes to WordPress, such as installing and deleting themes, which obviously involves writing to the file system.

The solution was to also grant the IUSR user account modify permissions in the file system.

This must mean that WordPress is be using this anonymous account for certain update actions, but not others. Sounds like a bug to me.

Service Principal Names

Overview

Service Principal Name (SPN) is a field in Active Directory (AD) against a user account that is used to store details of the services for which the account is authorised to receive delegated authentication for Kerberos authentication. It is, essentially, a mapping between user accounts and services, and is required for Kerberos authentication. For example, user account ServiceA may be authorised to run SQL Server on Server1, in which case one of the possible SPNs would be:

MSSQLSvc/Server1 Domain\ServiceA

Querying

To return the SPNs registered against a user account, use:

setspn -L {account name}

To return the details of an SPN, use:

setspn -Q {SPN}

Duplicates and manual modifications

Duplicates

An SPN registration is a one-to-one mapping from user account to service. If a duplicate exists in AD for a service, i.e. if a service is listed against more than one user account, the registration will be in error and Kerberos authentication will not function.
The current domain may be queried for duplicates by running:

setspn -X

Manual removals

Duplicates and other entries may be carefully removed using:

setspn -D {SPN} {account name}

Manual additions

When registering an SPN, ensure that an entry is added for every possible name by which the service can be accessed, such as the NetBIOS name and FQDN, and also any ports or instance names that may be used. For example, for SQL Server, all of the following are valid for a single instance and should, ideally, all be registered:

MSSQLSvc/Server1:1433 Domain\ServiceA
MSSQLSvc/Server1.domain.local:1433 Domain\ServiceA
MSSQLSvc/Server1:MSSQLSERVER Domain\ServiceA
MSSQLSvc/Server1.domain.local:MSSQLSERVER Domain\ServiceA
MSSQLSvc/Server1 Domain\ServiceA
MSSQLSvc/Server1.domain.local Domain\ServiceA

To manually add an SPN, use:

setspn -S {SPN} {account name}

NB: using -S performs a check for duplicates in the domain before creating the registration. If a duplicate is found, no modification of AD takes place.

Automatic registration

Many applications will attempt to automatically register the SPNs applicable to their service. To do so, the context under which the service executes, i.e. the user account, must have permission to modify this field in AD on its own object.

Service types

This is a non-exhaustive list of SPN service types.

Type SPN name Notes
SQL Server (OLTP) MSSQLSvc For instances with the default name, there should be three registrations for each server name by which the service will be accessed: (1) by port, (2) by instance name and (3)
without a port or instance name.

For instances with a specified name, there should be two registrations for each server name by which the service will be accessed: (1) by port and (2) by instance name.

SQL Server: SSAS MSOLAPSvc.3
SQL Server: SSRS HTTP
SCOM: RMS (emulator) and management server MSOMHSvc
SCOM: management server MSOMSdkSvc
SCOM: management server with ACS AdtServer

Remember that an entry should be added for every possible name by which a service can be accessed, such as the NetBIOS name and FQDN, and also any ports or instance names that may be used.

SNI problem: incorrect certificate issued

Server 2012 R2 has introduced SNI to IIS. Essentially, this is host headers for secure sites, and I welcome the additional feature. However, I recently encountered a problem with the default certificate that is issued by IIS, which caused some problems with the Lync 2013 client for iOS, as this doesn’t seem to support SNI.

What should happen
If present in a TLS connection request to IIS, the host header (SNI) should be examined and the appropriate certificate served to the client.
If a host header isnÔÇÖt provided, e.g. when using XP or the Lync client on iOS, a default certificate should be served by IIS, if one is present.

The problem
A default certificate is configured in IIS by creating a binding for HTTPS with no SNI entry. If the binding has an IP address specified, which I had added in order to bind it to the external NIC, this binding is used for all connections, irrespective of any other SNI bindings. This causes all sites to be served the certificate for the default binding. This is a problem.

The solution
In the default binding, remove the IP address and select All unassigned. This causes IIS to correctly issue the certificates for each specified SNI binding, and the default certificate to all other clients.