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.
- 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
To test if the required ports are open:
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:
Import root certificate to Management Server certificate store
Expand certificates and right click on “Trusted Root Certification
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:
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 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:
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:
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 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
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
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:
Expand Certificates (local computer), expand Personal, expand Certificates
Right-click the certificate, point to All tasks, and then click Import
Browse and Select the copied certificate, and then click Next
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:
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:
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.
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
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.