You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/active-directory/develop/tutorial-blazor-server.md
+3-9Lines changed: 3 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@ ms.author: henrymbugua
6
6
ms.service: active-directory
7
7
ms.subservice: develop
8
8
ms.topic: tutorial
9
-
ms.date: 12/13/2022
9
+
ms.date: 02/09/2023
10
10
ms.custom: "engagement-fy23"
11
11
ms.reviewer: janicericketts
12
12
#Customer intent: As a developer, I want to add authentication to a Blazor app.
@@ -52,13 +52,7 @@ Finally, because the app calls a protected API (in this case Microsoft Graph), i
52
52
53
53
## Create the app using the .NET CLI
54
54
55
-
Run the following command to download the templates for `Microsoft.Identity.Web`, which we'll make use of in this tutorial.
56
-
57
-
```dotnetcli
58
-
dotnet new --install Microsoft.Identity.Web.ProjectTemplates
59
-
```
60
-
61
-
Then, run the following command to create the application. Replace the placeholders in the command with the proper information from your app's overview page and execute the command in a command shell. The output location specified with the `-o|--output` option creates a project folder if it doesn't exist and becomes part of the app's name.
55
+
To create the application, run the following command. Replace the placeholders in the command with the proper information from your app's overview page and execute the command in a command shell. The output location specified with the `-o|--output` option creates a project folder if it doesn't exist and becomes part of the app's name.
Standalone managed service accounts (sMSAs) are managed domain accounts that you use to help secure one or more services that run on a server. They can't be reused across multiple servers. sMSAs provide automatic password management, simplified service principal name (SPN) management, and the ability to delegate management to other administrators.
20
+
Standalone managed service accounts (sMSAs) are managed domain accounts that help secure services running on a server. They can't be reused across multiple servers. sMSAs have automatic password management, simplified service principal name (SPN) management, and delegated management to administrators.
21
21
22
-
In Active Directory, sMSAs are tied to a specific server that runs a service. You can find these accounts listed in the Active Directory Users and Computers snap-in of the Microsoft Management Console.
22
+
In Active Directory (AD), sMSAs are tied to a server that runs a service. You can find accounts in the Active Directory Users and Computers snap-in in Microsoft Management Console.
23
23
24
-
24
+
25
25
26
-
Managed service accounts were introduced with Windows Server 2008 R2 Active Directory Schema, and they require at least Windows Server 2008 R2.
26
+
> [!NOTE]
27
+
> Managed service accounts were introduced in Windows Server 2008 R2 Active Directory Schema, and they require Windows Server 2008 R2, or a later version.
27
28
28
-
## Benefits of using sMSAs
29
+
## sMSA benefits
29
30
30
-
sMSAs offer greater security than user accounts that are used as service accounts. At the same time, to help reduce administrative overhead, they:
31
+
sMSAs have greater security than user accounts used as service accounts. They help reduce administrative overhead:
31
32
32
-
***Set strong passwords**: sMSAs use 240-byte, randomly generated complex passwords. The complexity and length of sMSA passwords minimizes the likelihood of a service getting compromised by brute force or dictionary attacks.
33
+
* Set strong passwords - sMSAs use 240 byte, randomly generated complex passwords
34
+
* The complexity minimizes the likelihood of compromise by brute force or dictionary attacks
35
+
* Cycle passwords regularly - Windows changes the sMSA password every 30 days.
36
+
* Service and domain administrators don’t need to schedule password changes or manage the associated downtime
37
+
* Simplify SPN management - SPNs are updated if the domain functional level is Windows Server 2008 R2. The SPN is updated when you:
38
+
* Rename the host computer account
39
+
* Change the host computer domain name server (DNS) name
40
+
* Use PowerShell to add or remove other sam-accountname or dns-hostname parameters
41
+
* See, [Set-ADServiceAccount](/powershell/module/activedirectory/set-adserviceaccount)
33
42
34
-
***Cycle passwords regularly**: Windows automatically changes the sMSA password every 30 days. Service and domain administrators don’t need to schedule password changes or manage the associated downtime.
43
+
## Using sMSAs
35
44
36
-
***Simplify SPN management**: Service principal names are automatically updated if the domain functional level is Windows Server 2008 R2. For instance, the service principal name is automatically updated when you:
37
-
* Rename the host computer account.
38
-
* Change the domain name server (DNS) name of the host computer.
39
-
* Add or remove other sam-accountname or dns-hostname parameters by using [PowerShell](/powershell/module/activedirectory/set-adserviceaccount).
40
-
41
-
## When to use sMSAs
42
-
43
-
sMSAs can simplify management and security tasks. Use sMSAs when you have one or more services deployed to a single server and you can't use a group managed service account (gMSA).
45
+
Use sMSAs to simplify management and security tasks. sMSAs are useful when services are deployed to a server and you can't use a group managed service account (gMSA).
44
46
45
47
> [!NOTE]
46
-
> Although you can use sMSAs for more than one service, we recommend that each service have its own identity for auditing purposes.
48
+
> You can use sMSAs for more than one service, but it's recommended that each service has an identity for auditing.
47
49
48
-
If the creator of the software can’t tell you whether it can use an MSA, you must test your application. To do so, create a test environment and ensure that it can access all required resources. For more information, see [Create and install an sMSA](/archive/blogs/askds/managed-service-accounts-understanding-implementing-best-practices-and-troubleshooting).
50
+
If the software creator can’t tell you if the application uses an MSA, test the application. Create a test environment and ensure it accesses required resources.
49
51
50
-
### Assess the security posture of sMSAs
52
+
Learn more: [Managed Service Accounts: Understanding, Implementing, Best Practices, and Troubleshooting](/archive/blogs/askds/managed-service-accounts-understanding-implementing-best-practices-and-troubleshooting)
51
53
52
-
sMSAs are inherently more secure than standard user accounts, which require ongoing password management. However, it's important to consider sMSAs’ scope of access as part of their overall security posture.
54
+
### Assess sMSA security posture
53
55
54
-
To see how to mitigate potential security issues posed by sMSAs, refer to the following table:
56
+
Consider the sMSA scope of access as part of the security posture. To mitigate potential security issues, see the following table:
55
57
56
58
| Security issue| Mitigation |
57
59
| - | - |
58
-
| sMSA is a member of privileged groups. | <li>Remove the sMSA from elevated privileged groups, such as Domain Admins.<li>Use the *least privileged* model, and grant the sMSA only the rights and permissions it requires to run its services.<li>If you're unsure of the required permissions, consult the service creator. |
59
-
| sMSA has read/write access to sensitive resources. | <li>Audit access to sensitive resources.<li>Archive audit logs to a Security Information and Event Management (SIEM) program, such as Azure Log Analytics or Microsoft Sentinel, for analysis.<li>Remediate resource permissions if an undesirable level of access is detected. |
60
-
| By default, the sMSA password rollover frequency is 30 days. | You can use group policy to tune the duration, depending on enterprise security requirements. To set the password expiration duration, use the following path:<br>*Computer Configuration\Policies\Windows Settings\Security Settings\Security Options*. For domain member, use **Maximum machine account password age**. |
61
-
|||
62
-
60
+
| sMSA is a member of privileged groups | - Remove the sMSA from elevated privileged groups, such as Domain Admins</br> - Use the least-privileged model </br> - Grant the sMSA rights and permissions to run its services</br> - If you're unsure about permissions, consult the service creator|
61
+
| sMSA has read/write access to sensitive resources | - Audit access to sensitive resources</br> - Archive audit logs to a security information and event management (SIEM) program, such as Azure Log Analytics or Microsoft Sentinel </br> - Remediate resource permissions if an undesirable access is detected |
62
+
| By default, the sMSA password rollover frequency is 30 days | Use group policy to tune the duration, depending on enterprise security requirements. To set the password expiration duration, go to:<br>Computer Configuration>Policies>Windows Settings>Security Settings>Security Options. For domain member, use **Maximum machine account password age**. |
63
63
64
-
65
-
### Challenges with sMSAs
66
-
67
-
The challenges associated with sMSAs are as follows:
64
+
### sMSA challenges
65
+
66
+
Use the following table to associate challenges with mitigations.
68
67
69
68
| Challenge| Mitigation |
70
69
| - | - |
71
-
| sMSAs can be used on a single server only. | Use a gMSA if you need to use the account across servers. |
72
-
| sMSAs can't be used across domains. | Use a gMSA if you need to use the account across domains. |
73
-
| Not all applications support sMSAs. | Use a gMSA if possible. Otherwise, use a standard user account or a computer account, as recommended by the application creator. |
74
-
|||
75
-
70
+
| sMSAs are on a single server | Use a gMSA to use the account across servers |
71
+
| sMSAs can't be used across domains | Use a gMSA to use the account across domains |
72
+
| Not all applications support sMSAs| Use a gMSA, if possible. Otherwise, use a standard user account or a computer account, as recommended by the creator|
76
73
77
74
## Find sMSAs
78
75
79
-
On any domain controller, run DSA.msc, and then expand the managed service accounts container to view all sMSAs.
76
+
On a domain controller, run DSA.msc, and then expand the managed service accounts container to view all sMSAs.
80
77
81
78
To return all sMSAs and gMSAs in the Active Directory domain, run the following PowerShell command:
82
79
83
80
`Get-ADServiceAccount -Filter *`
84
81
85
-
To return only sMSAs in the Active Directory domain, run the following command:
82
+
To return sMSAs in the Active Directory domain, run the following command:
86
83
87
84
`Get-ADServiceAccount -Filter * | where { $_.objectClass -eq "msDS-ManagedServiceAccount" }`
88
85
89
86
## Manage sMSAs
90
87
91
-
To manage your sMSAs, you can use the following Active Directory PowerShell cmdlets:
88
+
To manage your sMSAs, you can use the following AD PowerShell cmdlets:
92
89
93
90
`Get-ADServiceAccount`
94
91
`Install-ADServiceAccount`
@@ -100,16 +97,17 @@ To manage your sMSAs, you can use the following Active Directory PowerShell cmdl
100
97
101
98
## Move to sMSAs
102
99
103
-
If an application service supports sMSAs but not gMSAs, and you're currently using a user account or computer account for the security context, [Create and install an sMSA](/archive/blogs/askds/managed-service-accounts-understanding-implementing-best-practices-and-troubleshooting) on the server.
100
+
If an application service supports sMSAs, but not gMSAs, and you're using a user account or computer account for the security context, see</br>
101
+
[Managed Service Accounts: Understanding, Implementing, Best Practices, and Troubleshooting](/archive/blogs/askds/managed-service-accounts-understanding-implementing-best-practices-and-troubleshooting).
104
102
105
-
Ideally, you would move resources to Azure and use Azure Managed Identities or service principals.
103
+
If possible, move resources to Azure and use Azure managed identities, or service principals.
106
104
107
105
## Next steps
108
106
109
-
To learn more about securing service accounts, see the following articles:
107
+
To learn more about securing service accounts, see:
110
108
111
-
*[Introduction to on-premises service accounts](service-accounts-on-premises.md)
109
+
*[Securing on-premises service accounts](service-accounts-on-premises.md)
112
110
*[Secure group managed service accounts](service-accounts-group-managed.md)
Copy file name to clipboardExpand all lines: articles/app-service/networking/private-endpoint.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ description: Connect privately to an App Service apps using Azure private endpoi
4
4
author: madsd
5
5
ms.assetid: 2dceac28-1ba6-4904-a15d-9e91d5ee162c
6
6
ms.topic: article
7
-
ms.date: 01/30/2023
7
+
ms.date: 02/09/2023
8
8
ms.author: madsd
9
9
---
10
10
@@ -27,7 +27,7 @@ A private endpoint is a special network interface (NIC) for your App Service app
27
27
When you create a private endpoint for your app, it provides secure connectivity between clients on your private network and your app. The private endpoint is assigned an IP Address from the IP address range of your virtual network.
28
28
The connection between the private endpoint and the app uses a secure [Private Link](../../private-link/private-link-overview.md). Private endpoint is only used for incoming traffic to your app. Outgoing traffic won't use this private endpoint. You can inject outgoing traffic to your network in a different subnet through the [virtual network integration feature](../overview-vnet-integration.md).
29
29
30
-
Each slot of an app is configured separately. You can plug up to 100 private endpoints per slot. You can't share a private endpoint between slots.
30
+
Each slot of an app is configured separately. You can plug up to 100 private endpoints per slot. You can't share a private endpoint between slots. The sub-resource name of a slot will be `sites-<slot-name>`.
31
31
32
32
The subnet where you plug the private endpoint can have other resources in it, you don't need a dedicated empty subnet.
33
33
You can also deploy the private endpoint in a different region than your app.
Copy file name to clipboardExpand all lines: articles/azure-vmware/includes/dhcp-dns-in-azure-vmware-solution-description.md
+4-1Lines changed: 4 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,7 +3,7 @@ title: DHCP and DNS in Azure VMware Solution description
3
3
description: Azure VMware Solution DHCP and DNS description.
4
4
ms.topic: include
5
5
ms.service: azure-vmware
6
-
ms.date: 05/28/2021
6
+
ms.date: 2/9/2023
7
7
author: suzizuber
8
8
ms.author: v-szuber
9
9
---
@@ -13,3 +13,6 @@ ms.author: v-szuber
13
13
Applications and workloads running in a private cloud environment require name resolution and DHCP services for lookup and IP address assignments. A proper DHCP and DNS infrastructure are required to provide these services. You can configure a virtual machine to provide these services in your private cloud environment.
14
14
15
15
Use the DHCP service built-in to NSX or use a local DHCP server in the private cloud instead of routing broadcast DHCP traffic over the WAN back to on-premises.
16
+
17
+
> [!IMPORTANT]
18
+
> If you advertise a default route to the Azure VMware Solution, then you must allow the DNS forwarder to reach the configured DNS servers and they must support public name resolution.
0 commit comments