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/cloud-infrastructure-entitlement-management/onboard-aws.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,7 +17,7 @@ ms.author: jfields
17
17
This article describes how to onboard an Amazon Web Services (AWS) account on Permissions Management.
18
18
19
19
> [!NOTE]
20
-
> A *global administrator* or *super admin* (an admin for all authorization system types) can perform the tasks in this article after the global administrator has initially completed the steps provided in [Enable Permissions Management on your Azure Active Directory tenant](onboard-enable-tenant.md).
20
+
> A *global administrator* or *root user* (an admin for all authorization system types) can perform the tasks in this article after the global administrator has initially completed the steps provided in [Enable Permissions Management on your Azure Active Directory tenant](onboard-enable-tenant.md).
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/aks/learn/quick-windows-container-deploy-powershell.md
+14Lines changed: 14 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -125,6 +125,20 @@ creating a node pool to run Windows Server containers, the default value for `-V
125
125
[restricted VM sizes][restricted-vm-sizes]. The minimum recommended size is **Standard_D2s_v3**. The
126
126
previous command also uses the default subnet in the default vnet created when running `New-AzAksCluster`.
127
127
128
+
## Add a Windows Server 2019 or Windows Server 2022 node pool
129
+
130
+
AKS supports Windows Server 2019 and 2022 node pools. For Kubernetes version 1.25.0 and higher, Windows Server 2022 is the default operating system. For earlier Kubernetes versions, Windows Server 2019 is the default OS. To use Windows Server 2019, you need to specify the following parameters:
131
+
-**osType** set the value to `Windows`
132
+
-**osSKU** set the value to `Windows2019`
133
+
134
+
> [!NOTE]
135
+
> OsSKU requires PowerShell Az module version "9.2.0" or higher.
136
+
> Windows Server 2022 requires Kubernetes version "1.23.0" or higher.
137
+
138
+
```azurepowershell-interactive
139
+
New-AzAksNodePool -ResourceGroupName myResourceGroup -ClusterName myAKSCluster -VmSetType VirtualMachineScaleSets -OsType Windows -OsSKU Windows2019 Windows -Name npwin
140
+
```
141
+
128
142
## Connect to the cluster
129
143
130
144
To manage a Kubernetes cluster, you use [kubectl][kubectl], the Kubernetes command-line client. If
Copy file name to clipboardExpand all lines: articles/api-management/export-api-power-platform.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
@@ -37,7 +37,7 @@ This article walks through the steps in the Azure portal to create a custom Powe
37
37
38
38
:::image type="content" source="media/export-api-power-platform/create-custom-connector.png" alt-text="Create custom connector to API in API Management":::
39
39
40
-
Once the connector is created, navigate to your [Power Apps](https://make.powerapps.com) or [Power Automate](https://flow.microsoft.com) environment. You will see the API listed under **Data > Custom Connectors**.
40
+
Once the connector is created, navigate to your [Power Apps](https://make.powerapps.com) or [Power Automate](https://make.powerautomate.com) environment. You will see the API listed under **Data > Custom Connectors**.
41
41
42
42
:::image type="content" source="media/export-api-power-platform/custom-connector-power-app.png" alt-text="Custom connector in Power Platform":::
43
43
@@ -49,7 +49,7 @@ You can manage your custom connector in your Power Apps or Power Platform enviro
49
49
1. Select the pencil (Edit) icon to edit and test the custom connector.
50
50
51
51
> [!NOTE]
52
-
> To call the API from the Power Apps test console, you need to add the `https://flow.microsoft.com` URL as an origin to the [CORS policy](cors-policy.md) in your API Management instance.
52
+
> To call the API from the Power Apps test console, you need to add the `https://make.powerautomate.com` URL as an origin to the [CORS policy](cors-policy.md) in your API Management instance.
@@ -61,7 +61,9 @@ The certificate for custom domain suffix must be stored in an Azure Key Vault. A
61
61
62
62
:::image type="content" source="./media/custom-domain-suffix/key-vault-networking.png" alt-text="Screenshot of a sample networking page for key vault to allow custom domain suffix feature.":::
63
63
64
-
Your certificate must be a wildcard certificate for the selected custom domain name. For example, *internal-contoso.com* would need a certificate covering **.internal-contoso.com*. If the certificate used custom domain suffix contains a Subject Alternate Name (SAN) entry for scm, for example **.scm.internal-contoso.com*, the scm site will also available using the custom domain suffix.
64
+
Your certificate must be a wildcard certificate for the selected custom domain name. For example, *internal-contoso.com* would need a certificate covering **.internal-contoso.com*. If the certificate used by the custom domain suffix contains a Subject Alternate Name (SAN) entry for scm, for example **.scm.internal-contoso.com*, the scm site will also available using the custom domain suffix.
65
+
66
+
If you rotate your certificate in Azure Key Vault, the App Service Environment will pick up the change within 24 hours.
0 commit comments