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
1. Every two minutes, the password hash synchronization agent on the AD Connect server requests stored password hashes (the unicodePwd attribute) from a DC. This request is via the standard [MS-DRSR](https://msdn.microsoft.com/library/cc228086.aspx) replication protocol used to synchronize data between DCs. The service account must have Replicate Directory Changes and Replicate Directory Changes All AD permissions (granted by default on installation) to obtain the password hashes.
50
50
2. Before sending, the DC encrypts the MD4 password hash by using a key that is a [MD5](https://www.rfc-editor.org/rfc/rfc1321.txt) hash of the RPC session key and a salt. It then sends the result to the password hash synchronization agent over RPC. The DC also passes the salt to the synchronization agent by using the DC replication protocol, so the agent will be able to decrypt the envelope.
51
-
3.After the password hash synchronization agent has the encrypted envelope, it uses [MD5CryptoServiceProvider](https://msdn.microsoft.com/library/System.Security.Cryptography.MD5CryptoServiceProvider.aspx) and the salt to generate a key to decrypt the received data back to its original MD4 format. The password hash synchronization agent never has access to the clear text password. The password hash synchronization agent’s use of MD5 is strictly for replication protocol compatibility with the DC, and it is only used on premises between the DC and the password hash synchronization agent.
52
-
4.The password hash synchronization agent expands the 16-byte binary password hash to 64 bytes by first converting the hash to a 32-byte hexadecimal string, then converting this string back into binary with UTF-16 encoding.
53
-
5.The password hash synchronization agent adds a per user salt, consisting of a 10-byte length salt, to the 64-byte binary to further protect the original hash.
54
-
6.The password hash synchronization agent then combines the MD4 hash plus the per user salt, and inputs it into the [PBKDF2](https://www.ietf.org/rfc/rfc2898.txt) function. 1000 iterations of the [HMAC-SHA256](https://msdn.microsoft.com/library/system.security.cryptography.hmacsha256.aspx) keyed hashing algorithm are used.
55
-
7.The password hash synchronization agent takes the resulting 32-byte hash, concatenates both the per user salt and the number of SHA256 iterations to it (for use by Azure AD), then transmits the string from Azure AD Connect to Azure AD over SSL.</br>
56
-
8.When a user attempts to sign in to Azure AD and enters their password, the password is run through the same MD4+salt+PBKDF2+HMAC-SHA256 process. If the resulting hash matches the hash stored in Azure AD, the user has entered the correct password and is authenticated.
51
+
3.After the password hash synchronization agent has the encrypted envelope, it uses [MD5CryptoServiceProvider](https://msdn.microsoft.com/library/System.Security.Cryptography.MD5CryptoServiceProvider.aspx) and the salt to generate a key to decrypt the received data back to its original MD4 format. The password hash synchronization agent never has access to the clear text password. The password hash synchronization agent’s use of MD5 is strictly for replication protocol compatibility with the DC, and it is only used on premises between the DC and the password hash synchronization agent.
52
+
4.The password hash synchronization agent expands the 16-byte binary password hash to 64 bytes by first converting the hash to a 32-byte hexadecimal string, then converting this string back into binary with UTF-16 encoding.
53
+
5.The password hash synchronization agent adds a per user salt, consisting of a 10-byte length salt, to the 64-byte binary to further protect the original hash.
54
+
6.The password hash synchronization agent then combines the MD4 hash plus the per user salt, and inputs it into the [PBKDF2](https://www.ietf.org/rfc/rfc2898.txt) function. 1000 iterations of the [HMAC-SHA256](https://msdn.microsoft.com/library/system.security.cryptography.hmacsha256.aspx) keyed hashing algorithm are used.
55
+
7.The password hash synchronization agent takes the resulting 32-byte hash, concatenates both the per user salt and the number of SHA256 iterations to it (for use by Azure AD), then transmits the string from Azure AD Connect to Azure AD over SSL.</br>
56
+
8.When a user attempts to sign in to Azure AD and enters their password, the password is run through the same MD4+salt+PBKDF2+HMAC-SHA256 process. If the resulting hash matches the hash stored in Azure AD, the user has entered the correct password and is authenticated.
57
57
58
-
>[!Note]
59
-
>The original MD4 hash is not transmitted to Azure AD. Instead, the SHA256 hash of the original MD4 hash is transmitted. As a result, if the hash stored in Azure AD is obtained, it cannot be used in an on-premises pass-the-hash attack.
58
+
>[!NOTE]
59
+
>The original MD4 hash is not transmitted to Azure AD. Instead, the SHA256 hash of the original MD4 hash is transmitted. As a result, if the hash stored in Azure AD is obtained, it cannot be used in an on-premises pass-the-hash attack.
60
60
61
61
### Security considerations
62
+
62
63
When synchronizing passwords, the plain-text version of your password is not exposed to the password hash synchronization feature, to Azure AD, or any of the associated services.
63
64
64
65
User authentication takes place against Azure AD rather than against the organization's own Active Directory instance. The SHA256 password data stored in Azure AD--a hash of the original MD4 hash--is more secure than what is stored in Active Directory. Further, because this SHA256 hash cannot be decrypted, it cannot be brought back to the organization's Active Directory environment and presented as a valid user password in a pass-the-hash attack.
65
66
66
67
### Password policy considerations
68
+
67
69
There are two types of password policies that are affected by enabling password hash synchronization:
68
70
69
71
* Password complexity policy
70
72
* Password expiration policy
71
73
72
-
#### Password complexity policy
74
+
#### Password complexity policy
75
+
73
76
When password hash synchronization is enabled, the password complexity policies in your on-premises Active Directory instance override complexity policies in the cloud for synchronized users. You can use all of the valid passwords from your on-premises Active Directory instance to access Azure AD services.
74
77
75
78
> [!NOTE]
76
79
> Passwords for users that are created directly in the cloud are still subject to password policies as defined in the cloud.
77
80
78
-
#### Password expiration policy
79
-
If a user is in the scope of password hash synchronization, the cloud account password is set to *Never Expire*.
81
+
#### Password expiration policy
82
+
83
+
If a user is in the scope of password hash synchronization, by default the cloud account password is set to *Never Expire*.
80
84
81
85
You can continue to sign in to your cloud services by using a synchronized password that is expired in your on-premises environment. Your cloud password is updated the next time you change the password in the on-premises environment.
82
86
87
+
##### Public preview of the *EnforceCloudPasswordPolicyForPasswordSyncedUsers* feature
88
+
89
+
If there are synchronized users that only interact with Azure AD integrated services and must also comply with a password expiration policy, you can force them to comply with your Azure AD password expiration policy by enabling the *EnforceCloudPasswordPolicyForPasswordSyncedUsers* feature.
90
+
91
+
When *EnforceCloudPasswordPolicyForPasswordSyncedUsers* is disabled (which is the default setting), Azure AD Connect sets the PasswordPolicies attribute of synchronized users to "DisablePasswordExpiration". This is done every time a user's password is synchronized and instructs Azure AD to ignore the cloud password expiration policy for that user. You can check the value of the attribute using the Azure AD PowerShell module with the following command:
Once enabled, Azure AD does not go to each synchronized user to remove the `DisablePasswordExpiration` value from the PasswordPolicies attribute. Instead, the value is set to `None` during the next password sync for each user when they next change their password in on-premises AD.
101
+
102
+
It is recommended to enable EnforceCloudPasswordPolicyForPasswordSyncedUsers, prior to enabling password hash sync, so that the initial sync of password hashes does not add the `DisablePasswordExpiration` value to the PasswordPolicies attribute for the users.
103
+
104
+
The default Azure AD password policy requires users to change their passwords every 90 days. If your policy in AD is also 90 days, the two policies should match. However, if the AD policy is not 90 days, you can update the Azure AD password policy to match by using the Set-MsolPasswordPolicy PowerShell command.
105
+
106
+
Azure AD supports a separate password expiration policy per registered domain.
107
+
108
+
Caveat: If there are synchronized accounts that need to have non-expiring passwords in Azure AD, you must explicitly add the `DisablePasswordExpiration` value to the PasswordPolicies attribute of the user object in Azure AD. You can do this by running the following command.
#### Public Preview of synchronizing temporary passwords and "Force Password on Next Logon"
116
+
117
+
It is typical to force a user to change their password during their first logon, especially after an admin password reset occurs. It is commonly known as setting a "temporary" password and is completed by checking the "User must change password at next logon" flag on a user object in Active Directory (AD).
118
+
119
+
The temporary password functionality helps to ensure that the transfer of ownership of the credential is completed on first use, to minimize the duration of time in which more than one individual has knowledge of that credential.
120
+
121
+
To support temporary passwords in Azure AD for synchronized users, you can enable the *ForcePasswordResetOnLogonFeature* feature, by running the following command on your Azure AD Connect server, replacing <AADConnectorName> with the connector name specific to your environment:
You can use the following command to determine the connector name:
126
+
127
+
`(Get-ADSyncConnector | where{$_.ListName -eq "Windows Azure Active Directory (Microsoft)"}).Name`
128
+
129
+
Caveat: Forcing a user to change their password on next logon requires a password change at the same time. AD Connect will not pick up the force password change flag by itself, it is supplemental to the detected password change that occurs during password hash sync.
130
+
131
+
> [!CAUTION]
132
+
> If you do not enable Self-service Password Reset (SSPR) in Azure AD users will have a confusing experience when they reset their password in Azure AD and then attempt to sign in in Active Directory with the new password, as the new password isn’t valid in Active Directory. You should only use this feature when SSPR and Password Writeback is enabled on the tenant.
133
+
134
+
> [!NOTE]
135
+
> This feature is in Public Preview right now.
136
+
83
137
#### Account expiration
138
+
84
139
If your organization uses the accountExpires attribute as part of user account management, this attribute is not synchronized to Azure AD. As a result, an expired Active Directory account in an environment configured for password hash synchronization will still be active in Azure AD. We recommend that if the account is expired, a workflow action should trigger a PowerShell script that disables the user's Azure AD account (use the [Set-AzureADUser](https://docs.microsoft.com/powershell/module/azuread/set-azureaduser?view=azureadps-2.0) cmdlet). Conversely, when the account is turned on, the Azure AD instance should be turned on.
85
140
86
141
### Overwrite synchronized passwords
142
+
87
143
An administrator can manually reset your password by using Windows PowerShell.
88
144
89
145
In this case, the new password overrides your synchronized password, and all password policies defined in the cloud are applied to the new password.
Copy file name to clipboardExpand all lines: articles/aks/use-multiple-node-pools.md
+10-9Lines changed: 10 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -31,7 +31,7 @@ You need the Azure CLI version 2.0.61 or later installed and configured. Run `az
31
31
32
32
### Install aks-preview CLI extension
33
33
34
-
To use multiple node pools, you need the *aks-preview* CLI extension version 0.4.12 or higher. Install the *aks-preview* Azure CLI extension using the [az extension add][az-extension-add] command, then check for any available updates using the [az extension update][az-extension-update] command::
34
+
To use multiple node pools, you need the *aks-preview* CLI extension version 0.4.16 or higher. Install the *aks-preview* Azure CLI extension using the [az extension add][az-extension-add] command, then check for any available updates using the [az extension update][az-extension-update] command::
35
35
36
36
```azurecli-interactive
37
37
# Install the aks-preview extension
@@ -174,7 +174,9 @@ $ az aks nodepool list --resource-group myResourceGroup --cluster-name myAKSClus
174
174
> [!NOTE]
175
175
> Upgrade and scale operations on a cluster or node pool cannot occur simultaneously, if attempted an error will be returned. Instead, each operation type must complete on the target resource prior to the next request on that same resource. Read more about this on our [troubleshooting guide](https://aka.ms/aks-pending-upgrade).
176
176
177
-
When your AKS cluster was initially created in the first step, a `--kubernetes-version` of *1.13.10* was specified. This set the Kubernetes version for both the control plane and the default node pool. The commands in this section explain how to upgrade a single specific node pool. The relationship between upgrading the Kubernetes version of the control plane and the node pool are explained in the [section below](#upgrade-a-cluster-control-plane-with-multiple-node-pools).
177
+
When your AKS cluster was initially created in the first step, a `--kubernetes-version` of *1.13.10* was specified. This set the Kubernetes version for both the control plane and the default node pool. The commands in this section explain how to upgrade a single specific node pool.
178
+
179
+
The relationship between upgrading the Kubernetes version of the control plane and the node pool are explained in the [section below](#upgrade-a-cluster-control-plane-with-multiple-node-pools).
178
180
179
181
> [!NOTE]
180
182
> The node pool OS image version is tied to the Kubernetes version of the cluster. You will only get OS image upgrades, following a cluster upgrade.
@@ -190,9 +192,6 @@ az aks nodepool upgrade \
190
192
--no-wait
191
193
```
192
194
193
-
> [!Tip]
194
-
> To upgrade the control plane to *1.14.6*, run `az aks upgrade -k 1.14.6`. Learn more about [control plane upgrades with multiple node pools here](#upgrade-a-cluster-control-plane-with-multiple-node-pools).
195
-
196
195
List the status of your node pools again using the [az aks node pool list][az-aks-nodepool-list] command. The following example shows that *mynodepool* is in the *Upgrading* state to *1.13.10*:
197
196
198
197
```console
@@ -228,7 +227,7 @@ $ az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster
228
227
229
228
It takes a few minutes to upgrade the nodes to the specified version.
230
229
231
-
As a best practice, you should upgrade all node pools in an AKS cluster to the same Kubernetes version. The ability to upgrade individual node pools lets you perform a rolling upgrade and schedule pods between node pools to maintain application uptime within the above constraints mentioned.
230
+
As a best practice, you should upgrade all node pools in an AKS cluster to the same Kubernetes version. The default behavior of `az aks upgrade` is to upgrade all node pools together with the control plane to achieve this alignment. The ability to upgrade individual node pools lets you perform a rolling upgrade and schedule pods between node pools to maintain application uptime within the above constraints mentioned.
232
231
233
232
## Upgrade a cluster control plane with multiple node pools
234
233
@@ -239,11 +238,13 @@ As a best practice, you should upgrade all node pools in an AKS cluster to the s
239
238
> * The node pool version may be one minor version less than the control plane version.
240
239
> * The node pool version may be any patch version as long as the other two constraints are followed.
241
240
242
-
An AKS cluster has two cluster resource objects. The first is a control plane Kubernetes version. The second is an agent pool with a Kubernetes version. A control plane maps to one or many node pools and each has their own Kubernetes version. The behavior for an upgrade operation depends on which resource is targeted and what version of the underlying API is called.
241
+
An AKS cluster has two cluster resource objects with Kubernetes versions associated. The first is a control plane Kubernetes version. The second is an agent pool with a Kubernetes version. A control plane maps to one or many node pools. The behavior of an upgrade operation depends on which Azure CLI command is used.
243
242
244
243
1. Upgrading the control plane requires using `az aks upgrade`
245
-
* This will upgrade all node pools in the cluster as well
246
-
1. Upgrading with `az aks nodepool upgrade`
244
+
* This will upgrade the control plane version and all node pools in the cluster
245
+
* By passing `az aks upgrade` with the `--control-plane-only` flag you will only upgrade the cluster control plane and none of the associated node pools
246
+
* The `--control-plane-only` flag is available in **AKS-preview extension v0.4.16** or higher
247
+
1. Upgrading individual node pools requires using `az aks nodepool upgrade`
247
248
* This will upgrade only the target node pool with the specified Kubernetes version
248
249
249
250
The relationship between Kubernetes versions held by node pools must also follow a set of rules.
Copy file name to clipboardExpand all lines: articles/app-service/containers/tutorial-python-postgresql-app.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
@@ -32,7 +32,7 @@ In this tutorial, you learn how to:
32
32
> [!NOTE]
33
33
> Before creating an Azure Database for PostgreSQL, please check [which compute generation is available in your region](https://docs.microsoft.com/azure/postgresql/concepts-pricing-tiers#compute-generations-and-vcores).
34
34
35
-
You can follow the steps in this article on macOS. Linux and Windows instructions are the same in most cases, but the differences are not detailed in this tutorial.
35
+
You can follow the steps in this article on macOS, Linux and Windows instructions are the same in most cases, but the differences are not detailed in this tutorial.
0 commit comments