OpsMgr security account rights mapping - what accounts need what privileges?

kevinhol — Wed, 16 Apr 2008 01:14:00 GMT

Do you ever wish you had a list of the rights needed to install OpsMgr on each server role? Or what each service account needs for steady state? Or how about ongoing support... for your Admin group - to have enough rights in SQL to support OpsMgr?

I have created a spreadsheet of the typical security accounts, and what rights they need on each server role, or database.

Attachment is below:

System Center Operations Manager SDK service failed to register an SPN

kevinhol — Fri, 14 Dec 2007 01:52:00 GMT

System Center Operations Manager SDK service failed to register an SPN

Have you seen this event in your RMS OpsMgr event logs?

Event Type: Warning

Event Source: OpsMgr SDK Service

Event Category: None

Event ID: 26371

Date: 12/13/2007

Time: 2:58:24 PM

User: N/A

Computer: RMSCOMPUTER

Description:

The System Center Operations Manager SDK service failed to register an SPN. A domain admin needs to add MSOMSdkSvc/rmscomputer and MSOMSdkSvc/rmscomputer.domain.com to the servicePrincipalName of DOMAIN\sdkaccount

This seems to appear in the RC1-SP1 build of OpsMgr.

Every time the SDK service starts, it tries to update the SPN’s on the AD account that the SDK service runs under. It fails, because by default, a user cannot update its own SPNs. Therefore we see this error logged.

If the SDK account is a domain admin – it does not fail – because a domain admin would have the necessary rights. Obviously – we don’t want the SDK account being a domain admin…. That isn’t required nor is it a best practice.

Therefore – to resolve this error, we need to allow the SDK service account rights to update the SPN. The easiest way, is to go to the user account object for the SDK account in AD – and grant SELF to have full control.

A better, more granular way – is to only grant SELF the right of modifying the SPN:

Run ADSIEdit as a domain admin.
Find the SDK domain account, right click, properties.
Select the Security tab, click Advanced.
Click Add. Type “SELF” in the object box. Click OK.
Select the Properties Tab.
Scroll down and check the “Allow” box for “Read servicePrincipalName” and “Write servicePrincipalName”
Click OK. Click OK. Click OK.
Restart your SDK service – if AD has replicated from where you made the change – all should be resolved.

To check SPN's:

The following command will show all the HealthService SPN's in the domain:

Ldifde -f c:\ldifde.txt -t 3268 -d DC=DOMAIN,DC=COM -r "(serviceprincipalname=MSOMHSvc/*)" -l serviceprincipalname -p subtree

To view SPN's for a specific server:

"setspn -L servername"

Kevin Holman's OpsMgr Blog : security

OpsMgr security account rights mapping - what accounts need what privileges?

System Center Operations Manager SDK service failed to register an SPN

System Center Operations Manager SDK service failed to register an SPN

Have you seen this event in your RMS OpsMgr event logs?