Merge pull request #93512 from MicrosoftDocs/master

10/25 AM Publish

Author: huypub

articles/active-directory/manage-apps/application-proxy-configure-cookie-settings.md

@@ -28,6 +28,18 @@ Azure Active Directory (Azure AD) has access and session cookies for accessing o
 | Use Secure Cookie | **No** | **Yes** allows Application Proxy to include the Secure flag in HTTP response headers. Secure Cookies enhances security by transmitting cookies over a TLS secured channel such as HTTPS. This prevents cookies from being observed by unauthorized parties due to the transmission of the cookie in clear text. | Use **Yes** because of the additional security benefits.|
 | Use Persistent Cookie | **No** | **Yes** allows Application Proxy to set its access cookies to not expire when the web browser is closed. The persistence lasts until the access token expires, or until the user manually deletes the persistent cookies. | Use **No** because of the security risk associated with keeping users authenticated.<br></br><br></br>We suggest only using **Yes** for older applications that can't share cookies between processes. It's better to update your application to handle sharing cookies between processes instead of using persistent cookies. For example, you might need persistent cookies to allow a user to open Office documents in explorer view from a SharePoint site. Without persistent cookies, this operation might fail if the access cookies aren't shared between the browser, the explorer process, and the Office process. |
 
+## SameSite Cookies
+Starting in version [Chrome 80](https://support.google.com/chrome/a/answer/7679408?hl=en) and eventually in browsers leveraging [Chromium](https://blog.chromium.org/2019/10/developers-get-ready-for-new.html), cookies that do not specify the [SameSite](https://web.dev/samesite-cookies-explained) attribute will be treated as if they were set to **SameSite=Lax**. The SameSite attribute declares how cookies should be restricted to a same-site context. When set to Lax, the cookie is only to sent to same-site requests or top-level navigation. However, Application Proxy requires these cookies to be preserved in the third-party context in order to keep users properly signed in during their session. Due to this, we are making updates to the Application Proxy access and session cookies to avoid adverse impact from this change. The updates include:
+
+* Setting the **SameSite** attribute to **None**- This allows Application Proxy access and sessions cookies to be properly sent in the third-party context.
+* Setting the **Use Secure Cookie** setting to use **Yes** as the default. Chrome also requires the cookies to specify the Secure flag or it will be rejected. This change will apply to all existing applications published through Application Proxy. Note that Application Proxy access cookies have always been set to Secure and only transmitted over HTTPS. This change will only apply to the session cookies.
+
+These changes to Application Proxy cookies will roll out over the course of the next several weeks before the Chrome 80 release date.
+
+Additionally, if your back-end application has cookies that need to be available in a third-party context, you must explicitly opt in by changing your application to use SameSite=None for these cookies. Application Proxy translates the Set-Cookie header to its URLS and will respect the settings for these cookies set by the back-end application.
+
+
+
 ## Set the cookie settings - Azure portal
 To set the cookie settings using the Azure portal:
 

articles/active-directory/users-groups-roles/groups-lifecycle.md

@@ -39,9 +39,19 @@ For information on how to download and install the Azure AD PowerShell cmdlets,
 
 ## Activity-based automatic renewal (preview)
 
-Group expiration policy allows you to set the expiration lifespan for selected or all Office 365 groups. After the defined group lifespan, owners are asked to renew the group if it is still needed. With Azure AD intelligence, groups also now automatically renewed based on whether they have been in recent used. This feature eliminates the need for manual action on the part of the group owners, and is based on user activity in groups across Office 365 services like Outlook, SharePoint, Teams, Yammer, and others.
+With Azure AD intelligence, groups are now automatically renewed based on whether they have been in recent used. This feature eliminates the need for manual action by group owners, because it based on user activity in groups across Office 365 services like Outlook, SharePoint, Teams, or Yammer. For example, if an owner or a group member does something like upload a document in SharePoint, visit a Teams channel, or send an email to the group in Outlook, the group is automatically renewed and the owner does not get any renewal notifications.
 
-For a real-world example: At Contoso, the administrator has configured the group lifetime to be 180 days. Megan is the owner of the Contoso Marketing Office 365 group, with Enrico and Alex as its members. Her group is set to expire in only 45 days. If an owner or a group member does anything like upload a document in SharePoint, visit a Teams channel, or send an email to the group in Outlook, the group is automatically renewed for another 180 days, and the owner Megan does not get any renewal notifications.
+### Activities that automatically renew group expiration
+
+The following user actions cause automatic group renewal:
+
+- SharePoint: View, edit, download, move, share, or upload files
+- Outlook: Join group, read/write group message from group space, Like a message (in Outlook Web Access)
+- Teams: Visit a Teams channel
+
+### Auditing and reporting
+
+Administrators can get a list of automatically renewed groups from the activity audit logs in Azure AD.
 
 ## Roles and permissions
 
@@ -54,18 +64,6 @@ User | Can renew an Office 365 group that they own<br>Can restore an Office 365
 
 For more information on permissions to restore a deleted group, see [Restore a deleted Office 365 group in Azure Active Directory](groups-restore-deleted.md).
 
-### User actions for group automatic expiration renewal
-
-The following user actions cause automatic renewal of group expiration:
-
-- SharePoint: View, edit, download, move, share, or upload files
-- Outlook: Join group, read/write group message from group space, Like a message (in Outlook Web Access)
-- Teams: Visit a Teams channels
-
-### Auditing and reporting
-
-Administrators can get a list of automatically renewed groups from the activity audit logs in Azure AD.
-
 ## Set group expiration
 
 1. Open the [Azure AD admin center](https://aad.portal.azure.com) with an account that is a global administrator in your Azure AD organization.
@@ -85,7 +83,7 @@ Administrators can get a list of automatically renewed groups from the activity
     - Save your settings when you're done by selecting **Save**.
 
 > [!NOTE]
-> When you first set up expiration, any groups that are older than the expiration interval are set to 35 days until expiration unless the group is auto-renewed or the owner renews it.
+> When you first set up expiration, any groups that are older than the expiration interval are set to 35 days until expiration unless the group is automatically renewed or the owner renews it.
 >
 > When a dynamic group is deleted and restored, it's seen as a new group and re-populated according to the rule. This process can take up to 24 hours.
 >
@@ -170,7 +168,7 @@ Here are examples of how you can use PowerShell cmdlets to configure the expirat
    ```
 
 1. Remove the existing Policy
-   Remove-AzureADMSGroupLifecyclePolicy: This cmdlet deletes the Office 365 group expiration settings but requires the policy ID. This will disable expiration for Office 365 groups.
+   Remove-AzureADMSGroupLifecyclePolicy: This cmdlet deletes the Office 365 group expiration settings but requires the policy ID. This cmdlet disables expiration for Office 365 groups.
 
    ```powershell
    Remove-AzureADMSGroupLifecyclePolicy -Id "26fcc232-d1c3-4375-b68d-15c296f1f077"

articles/aks/use-network-policies.md

@@ -65,7 +65,11 @@ To see network policies in action, let's create and then expand on a policy that
 * Allow traffic based on pod labels.
 * Allow traffic based on namespace.
 
-First, let's create an AKS cluster that supports network policy. The network policy feature can only be enabled when the cluster is created. You can't enable network policy on an existing AKS cluster.
+First, let's create an AKS cluster that supports network policy. 
+
+> [!IMPORTANT]
+>
+> The network policy feature can only be enabled when the cluster is created. You can't enable network policy on an existing AKS cluster.
 
 To use Azure Network Policy, you must use the [Azure CNI plug-in][azure-cni] and define your own virtual network and subnets. For more detailed information on how to plan out the required subnet ranges, see [configure advanced networking][use-advanced-networking]. Calico Network Policy could be used with either this same Azure CNI plug-in or with the Kubenet CNI plug-in.