Showing posts with label kerberos. Show all posts
Showing posts with label kerberos. Show all posts

Thursday, July 20, 2023

New-SCOMManagementGroupConnection failing due to insufficient permissions

Error: Could not connect to SCOM zone in another domain using credentials of the same domain. even though bidirectional trust was present.

If the sdk service is running under local system account.

 

Error during powershell connection to scom zone.

 

PS C:\> New-SCOMManagementGroupConnection -ComputerName SCOMMG2.consoso.com
New-SCOMManagementGroupConnection : The user does not have sufficient permission to perform the operation.
At line:1 char:1
+ New-SCOMManagementGroupConnection -ComputerName SCOMMG2.ms-Contoso ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (Microsoft.Syste...nnectionCommand:NewSCManagementGroupConnectionComma
   nd) [New-SCManagementGroupConnection], UnauthorizedAccessEnterpriseManagementException
    + FullyQualifiedErrorId : ExecutionError,Microsoft.SystemCenter.Core.Commands.NewSCManagementGroupConnectionComman

 

Event id 4 generated in System Log.

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server SCOMMG2$. The target name used was MSOMSdkSvc/SCOMMG2.consoso.com. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (CONSOSO.COM) is different from the client domain (CONTOSO.AL.GOV), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

 Verified that the id had permissions to SCOM zone.

The Scom SDK service was running under local system account. The spn for sdk service was not registered in AD. Verified by setspn -L SCOMMG2.

Event id 26371 generated in Operations manager log.

 

Date and Time:

7/15/2023 1:15:28 AM

Log Name:

Operations Manager

Source:

OpsMgr SDK Service

Event Number:

26371

Level:

2

Logging Computer:

SCOMMG1.contoso.com

User:

N/A

Description:

The System Center Data Access service failed to register an SPN. A domain admin needs to add MSOMSdkSvc/SCOMMG1 and MSOMSdkSvc/SCOMMG1.contoso.com to the servicePrincipalName of CN=SCOMMG1,OU=Server Accounts,OU=Prod,OU=Contoso Servers,DC=-Contoso,DC=COM

Event Data:

< DataItem type =" System.XmlData " time =" 2023-07-15T01:15:28.0000000-05:00 " sourceHealthServiceId =" 2765519A-33B2-441C-F345-0FF0CEB2E109 " >

< EventData >

  < Data > SCOMMG1 </ Data >

  < Data > SCOMMG1.contoso.com </ Data >

  < Data > CN=SCOMMG1,OU=Server Accounts,OU=Prod,OU=Contoso Servers,DC=-Contoso,DC=COM </ Data >

  </ EventData >

  </ DataItem >

Solution:

·         Open ADSIDEDIT. Find the server object open properties  and grant SELF read write access in security tab.

·         Registered spn for the sdk and all management server computer accounts using.

Setspn.exe -S MSOMSdkSvc/SCOMMG1 SCOMMG1

Setspn.exe -S MSOMSdkSvc/SCOMMG2 SCOMMG2

 

Connection was successful in powershell.