Monitoring non-domain servers using SCOM

Monitoring non-domain servers using SCOM

  • Comments 2
  • Likes

The below article is obtained from: http://pkjayan.wordpress.com/2010/05/17/agent-managed-non-trusted-servers-without-gateway/. The text in green color is my own comment. The scenario is not using any gateway server.

Preparation:

- make sure the wkg-srv has the domain suffix, that means FQDN is wkg-srv.mycompany.com.vn. also a DNS entry for wkg-srv is needed

Monitoring non-trusted servers using SCOM-Step by step

In this scenario, monitoring of a remote, untrusted workgroup or environment isolated from any Active Directory domain is desired. Certificate authentication will be required between the management server and agent-managed workgroup servers, which will authenticate and communicate directly to the management server.

Five steps to complete

  1. Open TCP ports 5723 and 5724 both ways from the target server to the MS server.
  2. Prepare certificates need to be installed
  3. Run the momcertimport on all management servers after the certs have been installed.
  4. Manual install of agents and run the momcertimport on servers to be monitored
  5. Approve agents in SCOM console

Testing Ports

To test if the required ports are open:

Log on to the target serverFrom a command prompt typeTelnet <Management Server> 5723 If you get a cursor at the top left corner then the port is openAny other errors indicate that the port is still closed.

Do the same from the management server back to the non-trusted server

Certificates need to be installed

Retrieve and install the Root CA certificate

Download root certificate from the Root Certificate Authority server:

Logon on the Management ServerOpen a web Brower and navigate to http://<certificateserver>/certsrv Click on Download a CA certificate, certificate chain, Download CA Certificate chainClick on save.Save to a location of your choice. The default file name is certnew.p7b.

Import root certificate to Management Server certificate store

Open run and type MMC Click on file, add/remove snap-inClick on Add and select Certificates, and click on add again.Select computer account and say finishClose the window and say okto the add remove window.

Expand certificates and right click on “Trusted Root Certification

Authorities

Click on all tasks, Import

When the wizard opens navigate to the downloaded cert is

certnew.p7b . (change the file type to PKCS #7 to select the cert file)

Accept the defaults and finish

Perform the above steps on all Management Servers.

Copy the downloaded root certificate to non-trusted servers and import the same using above steps.

Create and Export Custom OpsMgr Certificate

Do this on the certificate server (at least on Windows Server 2008 Enterprise, or Windows 2008 R2 Standard) Create certificate template for custom OpsMgr Certificate:

Click Start, click Run, type mmc, and then press Enter.On the File menu, click Add/Remove Snap-in.Click Add.Under Add Standalone Snap-in, click Certificate templates, and then click Add.Click Certification Authority, and then click Add.


In my case, the certificate server is running Windows Server 2008 Enterprise (not R2!)

In the Certification Authority snap-in, select the Local computer (the computer this console is running on) option.

Click Finish.

Click Close, and then click OK.

In the Certification Authority snap-in, verify that the Certificate Templates snap-in and the Certification Authority snap-in appear.

Click Certificate Templates.

In the details pane, right-click Computer, and then click Duplicate Template. You will be presented with 2 options, just choose Windows 2003 Server, Enterprise Edition

On the General tab, change the template name to OpsMgr2007.

Verify that the validity period meets your organization’s requirements.

Click the Request Handling tab, and then click Allow private key to be exported.

Click the Subject name tab, and then click Supply in the Request option.

Click the Security tab.

Grant Enroll and Auto enroll permissions for the following groups in all domains:

Authenticated users

Domain Admins

Domain Computers

Enterprise Admins

Click Apply, and then click OK.

To verify the settings, expand Certificate Templates.

In the details pane, right-click the template that you configured, click Properties, verify your settings, and then click OK.

Expand Certification Authority (local), and then expand your certification authority.

In the console tree, right-click Certificate Templates, point to New, and then click Certificate Template to Issue.

Select the new template, and then click OK.

Verify that the new template appears in the details pane, and then verify that the Server Authentication entry and the Client Authentication entry appear under Intended Purpose.

Close the snap-in.

Click Start, click Run, type gpupdate /force and then press Enter.

Click Start, click Run, type http://<certificateserver>/certsrv in the Open field, and then press ENTER.

If you are prompted, enter the domain administrator account name and the password.

On the Certificate Services Web page, click Request a certificate under Select a task.

Click Advanced certificate request.

Click Create and submit a request to this CA.

In the Certificate template list, verify that your new certificate template appears. In my case, I have to restart the certificate server for that new template to appear.


On the management server, use the Certificates MMC (not the web UI) to request 02 certificates of the newly duplicate template for FQDN of the management server as well as the non-domain server, then export to 2 files named RMS.cfx and WKG-SRV.pfx to be used with MOMImport utility later.

Submit the certificate request to the certification authority server:

Click Start, click Run, type http://<certificateserver>/certsrv in the Open field, and then press ENTER. .On the Certificate Services Web page, click Request a certificate under Select a task. Click Advanced certificate requestClick Create and submit a request to this CAIn the Certificate Template field, select OpsMgr2007

In the Name field, type the FQDN of the Root Management Server

Select the Mark key as exportable check box. When you are using the Web certificate request UI, you must also check the Store the certificate in the local computer certificate store box  (In my Web certificate enrollment UI, there is no such checkbox, so I have to use Certificate MMC: navigate to Local Computer/Personal and choose to Request a Certificate, then fill the FQDN in the Common Name and Display Name fields, that means the Web UI cannot be used)
Click Submit to submit your request to the certification authority server, and then follow the instructions that appear on the screen

Depending on the security configuration on the CA, you have to wait for an administrator to manually approve the request. It is not guaranteed that the CA can be downloaded immediately

Once the certificate is issued, Export the certificate for further configuration

Click Start, click Run, type mmc, and then press Enter

On the File menu, click Add/Remove Snap-in

Click Add

Click Certificates, and then click Add

Select Computer account, and then click Finish

Select Local computer, click Finish, click Close to close the snap-in list, and then click OK to close the Add/remove snap-in window

Expand Certificates (local computer), expand Personal, expand Certificates, and then select a suitable certificate

Right-click the certificate, point to All tasks, and then click Export

Click Next

Select Yes, export private key, and then click Next

Use the default setting for the file format

Type a password for the file

Type a file name, and then click Next. For example, type C:RMS.pfx

Click Finish


Also on the management server, export the certificate of the non-domain server to a file named WKG-SRV.pfx then copy to the non-domain server.

Repeat the above step on all the non-trusted servers. Since the non-trusted servers are not part of the same domain as the CA, create the certificate on a different server and export it to a USB drive or other storage device. Then manually copy it to the gateway server and import it.

The below import step on the management server may not be needed since we are using two separate certificates for the management server and non-domain server???.

Install and configure the Custom OpsMgr Certificate on Management server

Import the custom certificate to local store:

Click Start, click Run, type mmc, and then press EnterOn the File menu, click Add/Remove Snap-inClick AddClick Certificates, and then click AddSelect Computer account, and then click Finish

Select Local computer, click Finish, click Close to close the snap-in list, and then click OK to close the Add/remove snap-in window

Expand Certificates (local computer), expand Personal, expand Certificates

Right-click the certificate, point to All tasks, and then click Import

Click Next

Browse and Select the copied certificate, and then click Next

Use the default setting for the file format

Type a password for the file

Check off Mark this key as exportable

Click next, make sure the certificate store is personal, click next and finish


On the management server, use MOMCertImport utility to import the RMS.cfx (a password is needed)

Import the custom certificate to Operations Manager on Management server:

Run the momcertimport utilityUse the same pfx certificate (the custom OpsMgr certificate) that created in previous step. This tool writes the certificate serial number to the registry. This also helps OpsMgr components find the proper certificate for authenticating easily.The momcertimport utility is on the install cd under supporttoolsi386Copy momcertimport.exe and the pfs certificate into the same folderOpen a command prompt, navigate to the folder with both files and type the following command

C:>MOMCertImport.exe certfilename.pfx

Do this on all SCOM management servers. Root Management Server, Management Servers.

Repeat the following step on the workgroup (non-trusted) computers

Install and configure the Custom OpsMgr Certificate issued by CA for non-trusterd server

Install the agent on the workgroup computer:

Run the MOMAgent.msi file.On the Welcome screen, click Next.When you are prompted for a folder destination for the software, accept the default location, click Next.When you are prompted to configure the management group information, Type the management group name, the management server name, and the port, and then click Next.Accept the default settings, and then click Next.

Verify that all information that you have entered is correct, and then click Install to start the installation.

When the installation is complete, click Finish.

On the non-domain server, use MOMCertImport utility to import the WKG-SRV.cfx (a password is needed)

After agent installation, Import the custom certificate to Operations Manager:

Run the momcertimport utility

Use the same pfx certificate (the custom OpsMgr certificate) that created in previous step. This tool writes the certificate serial number to the registry. This also helps OpsMgr components find the proper certificate for authenticating easily.

The momcertimport utility is on the install cd under supporttoolsi386

Copy momcertimport.exe and the pfs certificate into the same folder

Open a command prompt, navigate to the folder with both files and type the following command

C:>MOMCertImport.exe certfilename.pfx (Custom OpsMgr Certificate issued by CA for non-trusterd server)

Restart the OpsMgr Health service. On SCOM 2007 R2, the new names are "System Center Data Access/Management and Management Configuration"

Wait for the management server to see the manual installation and to request approval. This should take some time (five to ten minutes).

When you are prompted, approve the agent. The non-trusted server agent can now communicate with the Management server.

 
 
* How to Obtain a Certificate Using Windows Server 2008 Stand-Alone CA in Operations Manager 2007 http://technet.microsoft.com/en-us/library/dd362655.aspx

* Step by Step for using Certificates to communicate between agents and the OpsMgr 2007 server It has some extra steps for creating the RunAs account
 
 
I have given a step by step walkthrough of a windows 2008 Stand-alone CA here. It will take some time to download as the graphics need tuning but it fits in with the documention steps above. The one Alex suggests also covers this. If the agent can't directly access the certificate server then you'll need to add a few steps (which I have tried to highlight in bold below).

The high-level process to obtain a certificate from a stand-alone certification authority (CA) is as follows:

1. Download the Trusted Root (CA) certificate – do this from a machine that has access to the certificate server and then copy to the workgroup machine.

2. Import the Trusted Root (CA) certificate to the workgroup machine.

-------

3. Create a setup information file to use with the CertReq command-line utility –do this on the workgroup machine.

4. Create a request file – do this on the workgroup machine and then copy file to a server that has access to the certificate server

5. Submit a request to the CA using the request file from a server that has access to the certificate server

6. Approve the pending certificate request – from the certificate server

7. Retrieve the certificate from the CA – from a machine that has access to the certificate server and then copy certificate to workgroup computer

8. Import the certificate into the certificate store on the workgrou computer

9. Import the certificate into Operations Manager using MOMCertImport – on workgroup computer.

10. And then install the agent and approve install from opsmgr console

Cheers/ Graham

===========================================================

 

 
Comments
  • Can you setup non domain agents using standard certificates issued by Verisign or another provider if you do not want to setup a CA server on your domain?

  • Dear Nikolai, I think the best practice for PKI design in general is to have a private certificate server for internal authentication tasks such as non-domain SCOM agents, etc... and the Verisign certificate should be used for external communication such as email digital signature, etc... This is what Microsoft corporation is doing with its own PKI right now.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment