SCOM MS TLS1.2 drivers

SCOM MS TLS1.2 drivers
SCOM MS TLS1.2 drivers

Courtesy of Brook Hudson, who provided clarification for encrypting SCOM data –

Question – Can we update the OLE DB Driver from 18.6.5 to 18.6.7 and the ODBC driver from 17.10.3 to 17.10.5.1 without breaking anything?

 

This configuration applies to SCOM2016 forward –

MS OLE DB Driver 18.6.7: https://go.microsoft.com/fwlink/?linkid=2242656

ODBC Driver 17.10.5.1: https://go.microsoft.com/fwlink/?linkid=2249004

 

 

I did NOT have success with this for SCOM2019 and SCOM2022 –

If the SQL endpoint is secured with encryption, then the following drivers can be used.

MS OLE DB Driver 19.3.2: https://aka.ms/downloadmsoledbsql

ODBC Driver 18.3.2.1: https://aka.ms/downloadmsodbcsql

If you want to use these newer drivers then SQL encryption is required, more information about enabling SQL Encryption: Configure SQL Server Database Engine for encryption – SQL Server | Microsoft Learnhttps://learn.microsoft.com/en-us/sql/database-engine/configure-windows/configure-sql-server-encryption?view=sql-server-ver15

 

The SQL team noted that the newer versions are defaulting Encrypt to be Yes/Mandatory. That is why the new drivers were having an issue. Setting up a certificate in the SQL endpoint would have allowed the connection to work:

Enable encrypted connections – SQL Server | Microsoft Docs

Certificate Management (SQL Server Configuration Manager) – SQL Server | Microsoft Docs

OLE DB Driver 19.0 for SQL Server Released – Microsoft Tech Community

ODBC Driver 18.0 for SQL Server Released – Microsoft Tech Community

 

IMPORTANT:

Update: Hotfixes released for ODBC and OLE DB drivers for SQL Server – Microsoft Community Hub

 

Delete PKI certificates

Don't you wish this were the certificates we worked with!
Don’t you wish this were the certificates we worked with!

 

Man, I wish I had a few of these certificates in my PKI infrastructure (portfolio)!  Ever need to identify an expired certificate, and or delete the certificate?  Depending on UAC, AppLocker, and other settings, the delete portion may require server logon.

 

 

Identify an expired certificate

Few ways to identify an expired certificate on servers.

Via RDP session to server

RDP to server, open MMC > Add Plug In > Certificates > for Computer

RDP to server, MMC, Certificates Plug In, Computer, expand certificate store to find expired certificate.
RDP to server, MMC, Certificates Plug In, Computer, expand certificate store to find expired certificate.

 

Via PowerShell

GCI Cert:\LocalMachine\*

The certificate store file path will vary the above command.

NOTE the SuperUser blog post will help decipher the folder name

 

Via ‘smart’ PowerShell across multiple machines

Courtesy of Vance Cozier!

“server1”,”server2″| % {invoke-command $_ -scriptblock {$env:ComputerName; GCI Cert:\LocalMachine\* }}

 

Via Monitoring for expired certificates

Using SCOM Certificate Monitoring or PKI monitoring management packs

Identify Expired certificates

Console navigation steps:

From SCOM console > Monitoring Tab

Expand PKI folder > Expand Certificates and CRLs folder

Click on ‘Certificates – Expired’ state view

SCOM Expired PKI certificates state view.
SCOM Expired PKI certificates state view.

 

Did you know

Run PowerShell commands from Holman’s SCOM Management pack (blog)- github download

Run PowerShell from Monitoring tool

From SCOM console > Monitoring Tab > SCOM Management folder > SCOM Agents

Highlight agent(s)

From Tasks Pane > click on ‘Execute any PowerShell’ task

SCOM Management pack, SCOM Agents, highlight agent(s), click on Task Pane > Execute any PowerShell task.
SCOM Management pack, SCOM Agents, highlight agent(s), click on Task Pane > Execute any PowerShell task.

On the pop-up window, click Override

Adjust timeout to 70 (seconds)

Override command line

Run the following commands (various Certificate store examples provided for removing expired certificates)

Personal Certificates folder

Get-ChildItem Cert:\LocalMachine\My | ? { (( $_.Subject -like “*GlobalSign*” ) -OR ( $_.Issuer -like “*GlobalSign*” )) -and $_.NotAfter -lt (get-date) } | fl Subject,Issuer

Trusted Root folder

Get-ChildItem Cert:\LocalMachine\Root | ? { ( $_.Subject -like “*GlobalSign*” ) -OR ( $_.Issuer -like “*GlobalSign*” ) } | fl  Subject,Issuer

Third Party Root

Get-ChildItem Cert:\LocalMachine\AuthRoot | ? { (( $_.Subject -like “*GlobalSign*” ) -OR ( $_.Issuer -like “*GlobalSign*” )) -and $_.NotAfter -lt (get-date) } | fl Subject,Issuer

Run PowerShell task.
Run PowerShell task.

Click OK button to close Overrides window

Click OK to run task

View task output

PS C:\Users\admin> Get-ChildItem Cert:\LocalMachine\Root | ? { ( $_.Subject -like “*GlobalSign*” ) -OR ( $_.Issuer

like “*GlobalSign*” ) } | fl Subject,Issuer

 

Subject : CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE

Issuer  : CN=GlobalSign Root CA, OU=Root CA, O=GlobalSign nv-sa, C=BE

Subject : CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA – R2

Issuer  : CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA – R2

 

 

Once task completes, go back to the Certificates state view > highlight the certificate > Click the Rediscover Certificates task

SCOM PKI Certificate state view
SCOM PKI Certificate state view

 

 

 

Delete PKI certificates

After identifying correct certificate and folder in question that requires deletion:

    1. Verify backup of certificate
    2. Test delete via PowerShell window from SCOM

Get-ChildItem Cert:\LocalMachine\AuthRoot | ? { ( $_.Subject -like “*GlobalSign*” ) -OR ( $_.Isser -like “*GlobalSign*” ) } | Remove-Item -DeleteKey

  1. Verify Task output shows certificate deleted
  2. Refresh MMC GUI > Certificates plug in, and folder to verify certificate deleted
  3. Go back to SCOM Console Monitoring Tab
  4. Expand PKI folder
  5. Expand Certificates and CRLs folder
  6. Click on Certificates – Expired state view
  7. In Tasks pane on right, click on Rediscover certificates task, Click OK to run
  8. Open Health Explorer and reset monitor to clear alert

Alternatively, leverage PowerShell reset logic on SCOM MS, use blog

 

 

Documentation

SCOM Certificate monitoring TechCommunity blog https://techcommunity.microsoft.com/t5/system-center-blog/scom-management-pack-for-certificate-monitoring/ba-p/3619299

Download SCOM Certificate monitoring pack https://www.microsoft.com/en-us/download/details.aspx?id=104858

Long-standing PKI certificate pack and blog https://blog.topqore.com/new-version-pki-certificates-monitoring-pack-for-scom/

Identify certificate stores to windows folders https://superuser.com/questions/217719/what-are-the-windows-system-certificate-stores

STIG finding V-69223 https://www.stigviewer.com/stig/zos_tss/2016-06-30/finding/V-69223

ADCS Addendum packs

ADCS 'gift' certificate - don't we all wish!
ADCS ‘gift’ certificate – don’t we all wish!

If only certificates were all gift certificates!  The ‘ADCS Addendum packs’ disables noisy rules, adds OCSP seed, OCSP responder and OCSP group (classes).  Recovery and service monitoring and nCipher event are the main highlights reducing alerts for ADCS 2012,2012R2,2016+.  My thanks to Bob Williams CSA, for the assist!

 

Quick Download(s)

2012  HTTPS://GITHUB.COM/THEKEVINJUSTIN/ADCS2012QAddendum

2012R2 HTTPS://GITHUB.COM/THEKEVINJUSTIN/ADCS2012R2ADDENDUM/

2016+ https://github.com/theKevinJustin/ADCS2016-Addendum

 

Overview of addendum capabilities

Remember the why addendum packs for guiding purpose, transform!

The ADCS Addendum packs discover OCSP (seed class), and OCSP responder registry keys installed on monitored servers.

OCSP seed class
OCSP seed class

Group discovery tailors OCSP classes, for subscription or alert tuning.

OCSP server group can be used for subscription, or alert tuning (depending on class targets)
OCSP server group can be used for subscription, or alert tuning (depending on class targets)

Monitors and service recoveries keep OCSP services monitored, and only alert when manual intervention is required.

OCSP service, certsvc monitors and service recovery automations built in
OCSP service, certsvc monitors and service recovery automations built in

 

 

Tailoring the pack(s) to your environment

First, you must have at least ONE (1) set of ADCS Active Directory Certificate Services management packs so the ‘ADCS Addendum pack’ will load.  The three versions currently supported have addendums, hopefully 2012,2012R2 are planned to be decommissioned in the short term.

Second, if you don’t have OCSP in your environment, download, and then import into your environment –

ELSE

Update the ‘OCSP Responder’ server name(s) for the group regular expressions.

 

Update the ‘OCSP Responder’ server name(s) for the group regular expressions.

In your favorite XML editor (mine is Notepad++), open the addendum pack(s), and find/replace for the following strings:

CAServer##

CERTIFICATESERVERS##

 

Save pack

Import and enjoy!

 

Documentation

ADCS 2016+ version agnostic pack download

ADCS 2012/2012R2 management packs download

Azure UNIX server SCOM agent setup errors with OEL v7.x

 

Ran into some customers with UNIX agent problems, including Azure Oracle Enterprise Linux servers with SCOM agents.

 

 

 

 

 

Basically this error means

  1. Fully-qualified domain name cannot be determined from the UNIX or Linux host itself
  2. The FQDN known to the UNIX/Linux host does not match the FQDN used by the management server to reach the host

 

 

Full error message text

 

Agent verification failed. Error detail: The server certificate on the destination computer (agentname.contoso.net:1270) has the following errors:

The SSL certificate could not be checked for revocation. The server used to check for revocation might be unreachable.

The SSL certificate is signed by an unknown certificate authority.

It is possible that:

  1. The destination certificate is signed by another certificate authority not trusted by the management server.
  2. The destination has an invalid certificate, e.g., its common name (CN) does not match the fully qualified domain name (FQDN) used for the connection.  The FQDN used for the connection is: agentname.contoso.net.
  3. The servers in the resource pool have not been configured to trust certificates signed by other servers in the pool.

 

The server certificate on the destination computer (agentname.contoso.net:1270) has the following errors:

The SSL certificate could not be checked for revocation. The server used to check for revocation might be unreachable.

The SSL certificate is signed by an unknown certificate authority.

It is possible that:

  1. The destination certificate is signed by another certificate authority not trusted by the management server.
  2. The destination has an invalid certificate, e.g., its common name (CN) does not match the fully qualified domain name (FQDN) used for the connection.  The FQDN used for the connection is: agentname.contoso.net.
  3. The servers in the resource pool have not been configured to trust certificates signed by other servers in the pool.

 

 

 

 

Troubleshooting links

Old TechNet article for SCOM 2007R2

Docs site – link for 1801 – Steps haven’t changed, and IMHO, docs site is better documented

 

 

Here are some commands to help troubleshoot UNIX agent

ScxAdmin

 

Check UNIX Agent status

scxadmin -status

 

Example Output

$ scxadmin -status

scxcimserver: is running

scxcimprovagt: 2 instances running

 

 

 

Set Unix agent to START verbose logging

scxadmin -log-set all verbose

 

 

 

Restart Health Service & tail scx log

scxadmin -restart

cd /var/opt/microsoft/scx/log

tail -f scx.log

 

 

To correct a SCOM agent getting a SSL certificate error:

From the Docs site, the SCXsslConfig “tool is useful in correcting issues in which the fully-qualified domain name cannot be determined from the UNIX or Linux host itself, or the FQDN known to the UNIX/Linux host does not match the FQDN used by the management server to reach the host.”

 

As root:

1.             Get the exact hostname of the server with the hostname command  

2.             Stop the SCOM agent – /opt/microsoft/scx/bin/tools/scxadmin -stop  

3.             Rebuild the cert  – /opt/microsoft/scx/bin/tools/scxsslconfig -v -f -h HOSTNAME -d <FQDN_Here>  

4.             Start the SCOM agent – /opt/microsoft/scx/bin/tools/scxadmin -start 

 

 

 

 

 

 

Additional Configuration topics from the docs site

Configuring SSL Ciphers link

Specifying an alternate Temporary Path for scripts link

Universal Linux – Operating System Name/Version link

 

 

Other document links

Holman SCOM 2012R2 Deploying Unix agents

Holman SCOM 2016 Monitor Unix/Linux

Adding agents via PowerShell