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
#Customer intent: As an application developer, I want to learn how my Windows Presentation Foundation (WPF) application can get an access token and call an API that's protected by the Microsoft identity platform.
15
15
---
16
-
17
-
# Quickstart: Acquire a token and call the Microsoft Graph API from a Windows desktop app
16
+
# Quickstart: Sign in users and call Microsoft Graph in a Windows desktop app
18
17
19
18
> [!div renderon="docs"]
20
19
> Welcome! This probably isn't the page you were expecting. While we work on a fix, this link should take you to the right article:
> ## Quickstart: Acquire a token and call the Microsoft Graph API from a Windows desktop application
27
+
>
28
28
> In this quickstart, you download and run a code sample that demonstrates how a Windows Presentation Foundation (WPF) application can sign in users and get an access token to call the Microsoft Graph API.
29
29
>
30
30
> See [How the sample works](#how-the-sample-works) for an illustration.
Group managed service accounts (gMSAs) are managed domain accounts that you use to help secure services. gMSAs can run on a single server or on a server farm, such as systems behind a network load balancing or Internet Information Services (IIS) server. After you configure your services to use a gMSA principal, password management for that account is handled by the Windows operating system.
19
+
Group managed service accounts (gMSAs) are domain accounts to help secure services. gMSAs can run on one server, or in a server farm, such as systems behind a network load balancing or Internet Information Services (IIS) server. After you configure your services to use a gMSA principal, account password management is handled by the Windows operating system (OS).
21
20
22
-
## Benefits of using gMSAs
21
+
## Benefits of gMSAs
23
22
24
-
gMSAs offer a single identity solution with greater security. At the same time, to help reduce administrative overhead, they:
23
+
gMSAs are an identity solution with greater security that help reduce administrative overhead:
25
24
26
-
***Set strong passwords**: gMSAs use 240-byte, randomly generated complex passwords. The complexity and length of gMSA passwords minimizes the likelihood of a service getting compromised by brute force or dictionary attacks.
25
+
***Set strong passwords** - 240-byte, randomly generated passwords: the complexity and length of gMSA passwords minimizes the likelihood of compromise by brute force or dictionary attacks
26
+
***Cycle passwords regularly** - password management goes to the Windows OS, which changes the password every 30 days. Service and domain administrators don't need to schedule password changes, or manage service outages.
27
+
***Support deployment to server farms** - deploy gMSAs to multiple servers to support load balanced solutions where multiple hosts run the same service
28
+
***Support simplified service principal name (SPN) management** - set up an SPN with PowerShell, when you create an account.
29
+
* In addition, services that support automatic SPN registrations might do so against the gMSA, if the gMSA permissions are set correctly.
27
30
28
-
***Cycle passwords regularly**: gMSAs shift password management to the Windows operating system, which changes the password every 30 days. Service and domain administrators no longer need to schedule password changes or manage service outages to help keep service accounts secure.
31
+
## Using gMSAs
29
32
30
-
***Support deployment to server farms**: The ability to deploy gMSAs to multiple servers allows for the support of load balanced solutions where multiple hosts run the same service.
31
-
32
-
***Support simplified service principal name (SPN) management**: You can set up an SPN by using PowerShell when you create an account. In addition, services that support automatic SPN registrations might do so against the gMSA, provided that the gMSA permissions are correctly set.
33
-
34
-
## When to use gMSAs
35
-
36
-
Use gMSAs as the preferred account type for on-premises services unless a service, such as Failover Clustering, doesn't support it.
33
+
Use gMSAs as the account type for on-premises services unless a service, such as failover clustering, doesn't support it.
37
34
38
35
> [!IMPORTANT]
39
-
> You must test your service with gMSAs before you deploy it into production. To do so, set up a test environment to ensure that the application can use the gMSA, and then access the resources it needs to access. For more information, see [Support for group managed service accounts](/system-center/scom/support-group-managed-service-accounts).
40
-
36
+
> Test your service with gMSAs before it goes to production. Set up a test environment to ensure the application uses the gMSA, then accesses resources. For more information, see [Support for group managed service accounts](/system-center/scom/support-group-managed-service-accounts?view=sc-om-2022&preserve-view=true).
41
37
42
-
If a service doesn't support the use of gMSAs, your next best option is to use a standalone managed service account (sMSA). An sMSA provides the same functionality as a gMSA, but it's intended for deployment on a single server only.
38
+
If a service doesn't support gMSAs, you can use a standalone managed service account (sMSA). An sMSA has the same functionality, but is intended for deployment on a single server.
43
39
44
-
If you can't use a gMSA or sMSA that's supported by your service, you must configure the service to run as a standard user account. Service and domain administrators are required to observe strong password management processes to help keep the account secure.
40
+
If you can't use a gMSA or sMSA supported by your service, configure the service to run as a standard user account. Service and domain administrators are required to observe strong password management processes to help keep the account secure.
45
41
46
-
## Assess the security posture of gMSAs
42
+
## Assess gSMA security posture
47
43
48
-
gMSA accounts are inherently more secure than standard user accounts, which require ongoing password management. However, it's important to consider a gMSA's scope of access as you look at its overall security posture.
49
-
50
-
Potential security issues and mitigations for using gMSAs are shown in the following table:
44
+
gMSAs are more secure than standard user accounts, which require ongoing password management. However, consider gMSA scope of access in relation to security posture. Potential security issues and mitigations for using gMSAs are shown in the following table:
51
45
52
46
| Security issue| Mitigation |
53
47
| - | - |
54
-
| gMSA is a member of privileged groups. | <li>Review your group memberships. To do so, you create a PowerShell script to enumerate all group memberships. You can then filter a resultant CSV file by the names of your gMSA files.<li>Remove the gMSA from privileged groups.<li>Grant the gMSA only the rights and permissions it requires to run its service (consult with your service vendor).
55
-
| gMSA has read/write access to sensitive resources. | <li>Audit access to sensitive resources.<li>Archive audit logs to a SIEM, such as Azure Log Analytics or Microsoft Sentinel, for analysis.<li>Remove unnecessary resource permissions if you detect an undesirable level of access. |
56
-
|||
48
+
| gMSA is a member of privileged groups | <li>Review your group memberships. Create a PowerShell script to enumerate group memberships. Filter the resultant CSV file by gMSA file names.<li>Remove the gMSA from privileged groups.<li>Grant the gMSA rights and permissions it requires to run its service. See your service vendor.
49
+
| gMSA has read/write access to sensitive resources | <li>Audit access to sensitive resources.<li>Archive audit logs to a SIEM, such as Azure Log Analytics or Microsoft Sentinel, for analysis.<li>Remove unnecessary resource permissions if there's an unnecessary access level. |
57
50
58
51
59
52
## Find gMSAs
60
53
61
-
Your organization might already have created gMSAs. To retrieve these accounts, run the following PowerShell cmdlets:
54
+
Your organization might have gMSAs. To retrieve these accounts, run the following PowerShell cmdlets:
62
55
63
56
```powershell
64
57
Get-ADServiceAccount
@@ -70,19 +63,19 @@ Test-ADServiceAccount
70
63
Uninstall-ADServiceAccount
71
64
```
72
65
73
-
74
-
To work effectively, gMSAs must be in the Managed Service Accounts AD container.
75
-
66
+
### Managed Service Accounts container
76
67
77
-
68
+
To work effectively, gMSAs must be in the Managed Service Accounts container.
69
+
70
+
78
71
79
-
To find service MSAs that might not be in the list, run the following commands:
72
+
To find service MSAs not in the list, run the following commands:
80
73
81
74
```powershell
82
75
83
76
Get-ADServiceAccount -Filter *
84
77
85
-
# This PowerShell cmdlet will return all managed service accounts (both gMSAs and sMSAs). An administrator can differentiate between the two by examining the ObjectClass attribute on returned accounts.
78
+
# This PowerShell cmdlet returns managed service accounts (gMSAs and sMSAs). Differentiate by examining the ObjectClass attribute on returned accounts.
86
79
87
80
# For gMSA accounts, ObjectClass = msDS-GroupManagedServiceAccount
To manage gMSA accounts, you can use the following Active Directory PowerShell cmdlets:
91
+
To manage gMSAs, use the following Active Directory PowerShell cmdlets:
99
92
100
93
`Get-ADServiceAccount`
101
94
@@ -112,33 +105,32 @@ To manage gMSA accounts, you can use the following Active Directory PowerShell c
112
105
`Uninstall-ADServiceAccount`
113
106
114
107
> [!NOTE]
115
-
> Beginning with Windows Server 2012, the *-ADServiceAccount cmdlets work with gMSAs by default. For more information about using the preceding cmdlets, see[Get started with group managed service accounts](/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts).
108
+
> In Windows Server 2012, and later versions, the *-ADServiceAccount cmdlets work with gMSAs. Learn more:[Get started with group managed service accounts](/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts).
116
109
117
110
## Move to a gMSA
118
-
gMSA accounts are the most secure type of service account for on-premises needs. If you can move to one, you should. Additionally, consider moving your services to Azure and your service accounts to Azure Active Directory. To move to a gMSA account, do the following:
119
-
120
-
1. Ensure that the [Key Distribution Service (KDS) root key](/windows-server/security/group-managed-service-accounts/create-the-key-distribution-services-kds-root-key) is deployed in the forest. This is a one-time operation.
121
111
122
-
1.[Create a new gMSA](/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts).
112
+
gMSAs are a secure service account type for on-premises. It's recommended you use gMSAs, if possible. In addition, consider moving your services to Azure and your service accounts to Azure Active Directory.
113
+
114
+
To move to a gMSA:
123
115
124
-
1. Install the new gMSA on each host that runs the service.
116
+
1. Ensure the [Key Distribution Service (KDS) root key](/windows-server/security/group-managed-service-accounts/create-the-key-distribution-services-kds-root-key) is deployed in the forest. This is a one-time operation.
117
+
2.[Create a new gMSA](/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts).
118
+
3. Install the new gMSA on hosts that run the service.
119
+
125
120
> [!NOTE]
126
-
> For more information about creating and installing a gMSA on a host, prior to configuring your service to use the gMSA, see [Get started with group managed service accounts](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj128431(v=ws.11)).
127
-
128
-
1. Change your service identity to gMSA, and specify a blank password.
129
-
130
-
1. Validate that your service is working under the new gMSA identity.
131
-
132
-
1. Delete the old service account identity.
121
+
> Before configuring your service to use the gMSA, see [Get started with group managed service accounts](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj128431(v=ws.11)).
133
122
134
-
123
+
4. Change your service identity to gMSA.
124
+
5. Specify a blank password.
125
+
6. Validate your service is working under the new gMSA identity.
126
+
7. Delete the old service account identity.
135
127
136
128
## Next steps
137
129
138
130
To learn more about securing service accounts, see the following articles:
139
131
140
132
*[Introduction to on-premises service accounts](service-accounts-on-premises.md)
141
133
*[Secure standalone managed service accounts](service-accounts-standalone-managed.md)
|[Azure AD Authentication Library (ADAL)](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-september-2022-train/ba-p/2967454)|Retirement|Jun 30, 2023|
36
+
|[Azure AD Graph API](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-september-2022-train/ba-p/2967454)|Deprecation|Jun 30, 2023|
37
+
|[Azure AD PowerShell and MSOnline PowerShell](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-september-2022-train/ba-p/2967454)|Deprecation|Jun 30, 2023|
38
+
|[Azure AD MFA Server](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-september-2022-train/ba-p/2967454)|Retirement|Sep 30, 2024|
39
+
40
+
\* The legacy license management API and PowerShell cmdlets will not work for **new tenants** created after Nov 1, 2022.
39
41
40
42
41
43
> [!IMPORTANT]
@@ -58,8 +60,6 @@ Use the definitions in this section help clarify the state, availability, and su
58
60
### Terminology
59
61
60
62
***End-of-life** - engineering investments have ended, and the feature is unavailable to any customer
61
-
***Current tenant change date** - the change date goes into effect for tenants created before the new tenant change date
62
-
***New tenant change date** - the change date goes into effect for tenants created after the change date
63
63
64
64
## Next steps
65
65
[What's new in Azure Active Directory?](../../active-directory/fundamentals/whats-new.md)
0 commit comments