Skip to content

Commit d857a02

Browse files
v-dirichardsv-dirichards
authored
Merge pull request #276458 from PriskeyJeronika-MS/release-scommi
moving SCOM MI docs to new home
2 parents bd3945a + 34b58a4 commit d857a02

20 files changed

+773
-0
lines changed

‎articles/azure-monitor/scom-manage-instance/configure-network-firewall.md

Lines changed: 107 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,107 @@
1+
---
2+
ms.assetid:
3+
title: Configure the network firewall for Azure Monitor SCOM Managed Instance
4+
description: This article describes how to configure the network firewall.
5+
author: PriskeyJeronika-MS
6+
ms.author: v-gjeronika
7+
manager: jsuri
8+
ms.date: 05/22/2024
9+
ms.service: azure-monitor
10+
ms.subservice: operations-manager-managed-instance
11+
ms.topic: how-to
12+
---
13+
14+
# Configure the network firewall for Azure Monitor SCOM Managed Instance
15+
16+
This article describes how to configure the network firewall and Azure network security group (NSG) rules.
17+
18+
> [!NOTE]
19+
> To learn about the Azure Monitor SCOM Managed Instance architecture, see [Azure Monitor SCOM Managed Instance](overview.md).
20+
21+
## Network prerequisites
22+
23+
This section discusses network prerequisites with three network model examples.
24+
25+
### Establish direct connectivity (line of sight) between your domain controller and the Azure network
26+
27+
Ensure that there's direct network connectivity (line of sight) between the network of your desired domain controller and the Azure subnet (virtual network) where you want to deploy an instance of SCOM Managed Instance. Ensure that there's direct network connectivity (line of sight) between the workloads/agents and the Azure subnet in which the SCOM Managed Instance is deployed.
28+
29+
Direct connectivity is required so that all your following resources can communicate with each other over the network:
30+
31+
- Domain controller
32+
- Agents
33+
- System Center Operations Manager components, such as the Operations console
34+
- SCOM Managed Instance components, such as management servers
35+
36+
The following three distinct network models are visually represented to create the SCOM Managed Instance.
37+
38+
#### Network model 1: The domain controller is located on-premises
39+
40+
In this model, the desired domain controller is located within your on-premises network. You must establish an Azure ExpressRoute connection between your on-premises network and the Azure subnet used for the SCOM Managed Instance.
41+
42+
If your domain controller and other component are on-premises, you must establish the line of sight through ExpressRoute or a virtual private network (VPN). For more information, see [ExpressRoute documentation](/azure/expressroute/) and [Azure VPN Gateway documentation](/azure/vpn-gateway/).
43+
44+
The following network model shows where the desired domain controller is situated within the on-premises network. A direct connection exists (via ExpressRoute or VPN) between the on-premises network and the Azure subnet that's used for SCOM Managed Instance creation.
45+
46+
:::image type="Network model 1" source="media/configure-network-firewall/network-model-1-inline.png" alt-text="Screenshot that shows the network model 1 with the domain controller located on-premises." lightbox="media/configure-network-firewall/network-model-1-expanded.png":::
47+
48+
#### Network model 2: The domain controller is hosted in Azure
49+
50+
In this configuration, the designated domain controller is hosted in Azure, and you must establish an ExpressRoute or VPN connection between your on-premises network and the Azure subnet. It's used for the SCOM Managed Instance creation and the Azure subnet that's used for the designated domain controller. For more information, see [ExpressRoute](/azure/expressroute/) and [VPN Gateway](/azure/vpn-gateway/).
51+
52+
In this model, the desired domain controller remains integrated into your on-premises domain forest. However, you chose to create a dedicated Active Directory controller in Azure to support Azure resources that rely on the on-premises Active Directory infrastructure.
53+
54+
:::image type="Network model 2" source="media/configure-network-firewall/network-model-2-inline.png" alt-text="Screenshot that shows the network model 2 with the domain controller hosted in Azure." lightbox="media/configure-network-firewall/network-model-2-expanded.png":::
55+
56+
### Network model 3: The domain controller and SCOM Managed Instances are in Azure virtual networks
57+
58+
In this model, both the desired domain controller and the SCOM Managed Instances are placed in separate and dedicated virtual networks in Azure.
59+
60+
If the domain controller you want and all other components are in the same virtual network of Azure (a conventional active domain controller) with no presence on-premises, you already have a line of sight between all your components.
61+
62+
If the domain controller you want and all other components are in different virtual networks of Azure (a conventional active domain controller) with no presence on-premises, you need to do virtual network peering between all the virtual networks that are in your network. For more information, see [Virtual network peering in Azure](/azure/virtual-network/virtual-network-peering-overview).
63+
64+
:::image type="Network model 3" source="media/configure-network-firewall/network-model-3-inline.png" alt-text="Screenshot that shows the network model 3 with the domain controller and SCOM Managed Instances in Azure virtual networks." lightbox="media/configure-network-firewall/network-model-3-expanded.png":::
65+
66+
Take care of the following issues for all three networking models mentioned earlier:
67+
68+
1. Ensure that the SCOM Managed Instance subnet can establish connectivity to the designated domain controller configured for Azure or SCOM Managed Instance. Also, ensure that domain name resolution within the SCOM Managed Instance subnet lists the designated domain controller as the top entry among the resolved domain controllers to avoid network latency or performance and firewall issues.
69+
70+
1. The following ports on the designated domain controller and Domain Name System (DNS) must be accessible from the SCOM Managed Instance subnet:
71+
- TCP port 389 or 636 for LDAP
72+
- TCP port 3268 or 3269 for global catalog
73+
- TCP and UDP port 88 for Kerberos
74+
- TCP and UDP port 53 for DNS
75+
- TCP 9389 for Active Directory web service
76+
- TCP 445 for SMB
77+
- TCP 135 for RPC
78+
79+
The internal firewall rules and NSG must allow communication from the SCOM Managed Instance virtual network and the designated domain controller/DNS for all the ports listed earlier.
80+
81+
1. The Azure SQL Managed Instance virtual network and SCOM Managed Instance must be peered to establish connectivity. Specifically, the port 1433 (private port) or 3342 (public port) must be reachable from the SCOM Managed Instance to the SQL managed instance. Configure the NSG rules and firewall rules on both virtual networks to allow ports 1433 and 3342.
82+
83+
1. Allow communication on ports 5723, 5724, and 443 from the machine being monitored to SCOM Managed Instance.
84+
85+
- If the machine is on-premises, set up the NSG rules and firewall rules on the SCOM Managed Instance subnet and on the on-premises network where the monitored machine is located to ensure specified essential ports (5723, 5724, and 443) are reachable from the monitored machine to the SCOM Managed Instance subnet.
86+
87+
- If the machine is in Azure, set up the NSG rules and firewall rules on the SCOM Managed Instance virtual network and on the virtual network where the monitored machine is located to ensure specified essential ports (5723, 5724, and 443) are reachable from the monitored machine to the SCOM Managed Instance subnet.
88+
89+
## Firewall requirements
90+
91+
To function properly, SCOM Managed Instance must have access to the following port number and URLs. Configure the NSG and firewall rules to allow this communication.
92+
93+
|Resource|Port|Direction|Service Tags|Purpose|
94+
|---|---|---|---|---|
95+
|*.blob.core.windows.net|443|Outbound|Storage|Azure Storage|
96+
|management.azure.com|443|Outbound|AzureResourceManager|Azure Resource Manager|
97+
|gcs.prod.monitoring.core.windows.net <br/> *.prod.warm.ingest.monitor.core.windows.net|443|Outbound|AzureMonitor|SCOM MI Logs|
98+
|*.prod.microsoftmetrics.com <br/> *.prod.hot.ingest.monitor.core.windows.net <br/> *.prod.hot.ingestion.msftcloudes.com|443|Outbound|AzureMonitor|SCOM MI Metrics|
99+
|*.workloadnexus.azure.com|443|Outbound| |Nexus Service|
100+
|*.azuremonitor-scommiconnect.azure.com|443|Outbound| |Bridge Service|
101+
102+
> [!IMPORTANT]
103+
> To minimize the need for extensive communication with both your Active Directory admin and the network admin, see [Self-verification](self-verification-steps.md). The article outlines the procedures that the Active Directory admin and the network admin use to validate their configuration changes and ensure their successful implementation. This process reduces unnecessary back-and-forth interactions from the Operations Manager admin to the Active Directory admin and the network admin. This configuration saves time for the admins.
104+
105+
## Next steps
106+
107+
- [Verify Azure and internal GPO policies](verify-azure-internal-group-policy-object-policies.md)

‎articles/azure-monitor/scom-manage-instance/create-group-managed-service-account.md

Lines changed: 80 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,80 @@
1+
---
2+
ms.assetid:
3+
title: Create a computer group and group-managed service account for Azure Monitor SCOM Managed Instance
4+
description: This article describes how to create a group-managed service account, computer group, and domain user account in on-premises Active Directory.
5+
author: PriskeyJeronika-MS
6+
ms.author: v-gjeronika
7+
manager: jsuri
8+
ms.date: 05/22/2024
9+
ms.service: azure-monitor
10+
ms.subservice: operations-manager-managed-instance
11+
ms.topic: how-to
12+
---
13+
14+
# Create a computer group and group-managed service account for Azure Monitor SCOM Managed Instance
15+
16+
This article describes how to create a group-managed service account (gMSA) account, computer group, and domain user account in on-premises Active Directory.
17+
18+
> [!NOTE]
19+
> To learn about the Azure Monitor SCOM Managed Instance architecture, see [Azure Monitor SCOM Managed Instance](overview.md).
20+
21+
## Active Directory prerequisites
22+
23+
To perform Active Directory operations, install the **RSAT: Active Directory Domain Services and Lightweight Directory Tools** feature. Then install the **Active Directory Users and Computers** tool. You can install this tool on any machine that has domain connectivity. You must sign in to this tool with admin permissions to perform all Active Directory operations.
24+
25+
### Configure a domain account in Active Directory
26+
27+
Create a domain account in your Active Directory instance. The domain account is a typical Active Directory account. (It can be a nonadmin account.) You use this account to add the System Center Operations Manager management servers to your existing domain.
28+
29+
:::image type="Active directory users" source="media/create-gmsa-account/active-directory-users.png" alt-text="Screenshot that shows Active Directory users.":::
30+
31+
Ensure that this account has the [permissions](/windows/security/threat-protection/security-policy-settings/add-workstations-to-domain) to join other servers to your domain. You can use an existing domain account if it has these permissions.
32+
33+
You use the configured domain account in later steps to create an instance of SCOM Managed Instance and subsequent steps.
34+
35+
### Create and configure a computer group
36+
37+
Create a computer group in your Active Directory instance. For more information, see [Create a group account in Active Directory](/windows/security/threat-protection/windows-firewall/create-a-group-account-in-active-directory). All the management servers that you create will be a part of this group so that all the members of the group can retrieve gMSA credentials. (You create these credentials in later steps.) The group name can't contain spaces and must have alphabet characters only.
38+
39+
:::image type="Active directory computers" source="media/create-gmsa-account/active-directory-computers.png" alt-text="Screenshot that shows Active Directory computers.":::
40+
41+
To manage this computer group, provide permissions to the domain account that you created.
42+
43+
1. Select the group properties, and then select **Managed By**.
44+
1. For **Name**, enter the name of the domain account.
45+
1. Select the **Manager can update membership list** checkbox.
46+
47+
:::image type="Server group properties" source="media/create-gmsa-account/server-group-properties.png" alt-text="Screenshot that shows server group properties.":::
48+
49+
### Create and configure a gMSA account
50+
51+
Create a gMSA to run the management server services and to authenticate the services. Use the following PowerShell command to create a gMSA service account. The DNS host name can also be used to configure the static IP and associate the same DNS name to the static IP as in [step 8](create-static-ip.md).
52+
53+
```powershell
54+
New-ADServiceAccount ContosogMSA -DNSHostName "ContosoLB.aquiladom.com" -PrincipalsAllowedToRetrieveManagedPassword "ContosoServerGroup" -KerberosEncryptionType AES128, AES256 -ServicePrincipalNames MSOMHSvc/ContosoLB.aquiladom.com, MSOMHSvc/ContosoLB, MSOMSdkSvc/ContosoLB.aquiladom.com, MSOMSdkSvc/ContosoLB
55+
```
56+
57+
In that command:
58+
59+
- `ContosogMSA` is the gMSA name.
60+
- `ContosoLB.aquiladom.com` is the DNS name for the load balancer. Use the same DNS name to create the static IP and associate the same DNS name to the static IP as in [step 8](create-static-ip.md).
61+
- `ContosoServerGroup` is the computer group created in Active Directory (specified previously).
62+
- `MSOMHSvc/ContosoLB.aquiladom.com`, `SMSOMHSvc/ContosoLB`, `MSOMSdkSvc/ContosoLB.aquiladom.com`, and `MSOMSdkSvc/ContosoLB` are service principal names.
63+
64+
> [!NOTE]
65+
> If the gMSA name is longer than 14 characters, ensure that you set `SamAccountName` at less than 15 characters, including the `$` sign.
66+
67+
If the root key isn't effective, use the following command:
68+
69+
```powershell
70+
Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))
71+
```
72+
73+
Ensure that the created gMSA account is a local admin account. If there are any Group Policy Object policies on the local admins at the Active Directory level, ensure that they have the gMSA account as the local admin.
74+
75+
> [!IMPORTANT]
76+
> To minimize the need for extensive communication with both your Active Directory admin and the network admin, see [Self-verification](self-verification-steps.md). The article outlines the procedures that the Active Directory admin and network admin use to validate their configuration changes and ensure their successful implementation. This process reduces unnecessary back-and-forth interactions from the Operations Manager admin to the Active Directory admin and the network admin. This configuration saves time for the admins.
77+
78+
## Next steps
79+
80+
[Store domain credentials in Azure Key Vault](store-domain-credentials-key-vault.md)

0 commit comments

Comments
 (0)