Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into conditional-access-grant

Author: BCS2022

articles/active-directory/governance/TOC.yml

@@ -55,6 +55,8 @@
       href: manage-access-review.md
     - name: Manage users excluded from Conditional Access
       href: conditional-access-exclusion.md
+    - name: Review recommendations for access reviews
+      href: review-recommendations-access-reviews.md
   - name:  Review and remove users from external organizations
     href: access-reviews-external-users.md
 - name: How-to guides

articles/active-directory/governance/review-recommendations-access-reviews.md

@@ -0,0 +1,35 @@
+---
+title: Review recommendations for Access reviews - Azure AD
+description: Learn how to review access of group members with review recommendations in Azure Active Directory access reviews.
+services: active-directory
+author: amsliu
+manager: rkarlin
+editor: markwahl-msft
+ms.service: active-directory
+ms.workload: identity
+ms.tgt_pltfrm: na
+ms.topic: how-to
+ms.subservice: compliance
+ms.date: 8/5/2022
+ms.author: amsliu
+ms.reviewer: mwahl
+ms.collection: M365-identity-device-management
+---
+
+# Review recommendations for Access reviews 
+
+Decision makers who review users' access and perform access reviews can use system based recommendations to help them decide whether to continue their access or deny their access to resources. For more information about how to use review recommendations, see [Enable decision helpers](create-access-review.md#next-settings).
+
+## Prerequisites
+ 
+- Azure AD Premium P2
+ 
+For more information, see [License requirements](access-reviews-overview.md#license-requirements).
+
+## Inactive user recommendations
+A user is considered 'inactive' if they have not signed into the tenant within the last 30 days. This behavior is adjusted for reviews of application assignments, which checks each user's last activity in the app as opposed to the entire tenant. When inactive user recommendations are enabled for an access review, the last sign-in date for each user will be evaluated once the review starts, and any user that has not signed-in within 30 days will be given a recommended action of Deny. Additionally, when these decision helpers are enabled, reviewers will be able to see the last sign-in date for all users being reviewed. This sign-in date (as well as the resulting recommendation) is determined when the review begins and will not get updated while the review is in-progress.
+
+## Next Steps
+- [Create an access review](create-access-review.md)
+- [Review access to groups or applications](perform-access-review.md)
+

articles/load-balancer/load-balancer-floating-ip.md

@@ -28,14 +28,19 @@ If you want to reuse the backend port across multiple rules, you must enable Flo
 
 When Floating IP is enabled, Azure changes the IP address mapping to the Frontend IP address of the Load Balancer frontend instead of backend instance's IP. Without Floating IP, Azure exposes the VM instances' IP. Enabling Floating IP changes the IP address mapping to the Frontend IP of the load Balancer to allow for more flexibility. Learn more [here](load-balancer-multivip-overview.md).
 
+In the diagrams below, you see how IP address mapping works before and after enabling Floating IP:
+:::image type="content" source="media/load-balancer-floating-ip/load-balancer-floating-ip-before.png" alt-text="This diagram shows network traffic through a load balancer before Floating IP is enabled.":::
+
+:::image type="content" source="media/load-balancer-floating-ip/load-balancer-floating-ip-after.png" alt-text="This diagram shows network traffic through a load balancer after Floating IP is enabled.":::
+
 Floating IP can be configured on a Load Balancer rule via the Azure portal, REST API, CLI, PowerShell, or other client. In addition to the rule configuration, you must also configure your virtual machine's Guest OS in order to use Floating IP.
 
 ## Floating IP Guest OS configuration
 
 In order to function, the Guest OS for the virtual machine needs to be configured to receive all traffic bound for the frontend IP and port of the load balancer. To accomplish this requires:
 * a loopback network interface to be added
 * configuring the loopback with the frontend IP address of the load balancer
-* ensure the system can send/receive packets on interfaces that do not have the IP address assigned to that interface (on Windows, this requires setting interfaces to use the "weak host" model; on Linux this model is normally used by default)
+* ensure the system can send/receive packets on interfaces that don't have the IP address assigned to that interface (on Windows, this requires setting interfaces to use the "weak host" model; on Linux this model is normally used by default)
 The host firewall also needs to be open to receiving traffic on the frontend IP port.
 
 > [!NOTE]

articles/load-balancer/load-balancer-ha-ports-overview.md

@@ -40,7 +40,7 @@ For NVA HA scenarios, HA ports offer the following advantages:
 
 The following diagram presents a hub-and-spoke virtual network deployment. The spokes force-tunnel their traffic to the hub virtual network and through the NVA, before leaving the trusted space. The NVAs are behind an internal Standard Load Balancer with an HA ports configuration. All traffic can be processed and forwarded accordingly. When configured as show in the following diagram, an HA Ports load-balancing rule additionally provides flow symmetry for ingress and egress traffic.
 
-:::image type="content" source="./media/load-balancer-ha-ports-overview/nvaha.png" alt-text="Diagram of hub-and-spoke virtual network, with NVAs deployed in HA mode.":::
+:::image type="content" source="./media/load-balancer-ha-ports-overview/nvahathmb.png" alt-text="Diagram of hub-and-spoke virtual network, with NVAs deployed in HA mode." lightbox="media/load-balancer-ha-ports-overview/nvaha.png":::
 
 >[!NOTE]
 > If you are using NVAs, confirm with their providers how to best use HA ports and to learn which scenarios are supported.

articles/load-balancer/load-balancer-tcp-reset.md

@@ -16,29 +16,29 @@ ms.author: mbender
 
 # Load Balancer TCP Reset and Idle Timeout
 
-You can use [Standard Load Balancer](./load-balancer-overview.md) to create a more predictable application behavior for your scenarios by enabling TCP Reset on Idle for a given rule. Load Balancer's default behavior is to silently drop flows when the idle timeout of a flow is reached.  Enabling this feature will cause Load Balancer to send bidirectional TCP Resets (TCP RST packet) on idle timeout.  This will inform your application endpoints that the connection has timed out and is no longer usable.  Endpoints can immediately establish a new connection if needed.
+You can use [Standard Load Balancer](./load-balancer-overview.md) to create a more predictable application behavior for your scenarios by enabling TCP Reset on Idle for a given rule. Load Balancer's default behavior is to silently drop flows when the idle timeout of a flow is reached.  Enabling TCP reset will cause Load Balancer to send bidirectional TCP Resets (TCP RST packet) on idle timeout.  This will inform your application endpoints that the connection has timed out and is no longer usable.  Endpoints can immediately establish a new connection if needed.
 
-![Load Balancer TCP reset](media/load-balancer-tcp-reset/load-balancer-tcp-reset.png)
+:::image type="content" source="media/load-balancer-tcp-reset/load-balancer-tcp-reset.png" alt-text="Diagram shows default TCP reset behavior of network nodes.":::
 
 ## TCP reset
 
 You change this default behavior and enable sending TCP Resets on idle timeout on inbound NAT rules, load balancing rules, and [outbound rules](./load-balancer-outbound-connections.md#outboundrules).  When enabled per rule, Load Balancer will send bidirectional TCP Reset (TCP RST packets) to both client and server endpoints at the time of idle timeout for all matching flows.
 
 Endpoints receiving TCP RST packets close the corresponding socket immediately. This provides an immediate notification to the endpoints that the release of the connection has occurred and any future communication on the same TCP connection will fail.  Applications can purge connections when the socket closes and reestablish connections as needed without waiting for the TCP connection to eventually time out.
 
-For many scenarios, this may reduce the need to send TCP (or application layer) keepalives to refresh the idle timeout of a flow. 
+For many scenarios, TCP reset may reduce the need to send TCP (or application layer) keepalives to refresh the idle timeout of a flow. 
 
-If your idle durations exceed those of allowed by the configuration or your application shows an undesirable behavior with TCP Resets enabled, you may still need to use TCP keepalives (or application layer keepalives) to monitor the liveness of the TCP connections.  Further, keepalives can also remain useful for when the connection is proxied somewhere in the path, particularly application layer keepalives.  
+If your idle durations exceed configuration limits or your application shows an undesirable behavior with TCP Resets enabled, you may still need to use TCP keepalives, or application layer keepalives, to monitor the liveness of the TCP connections.  Further, keepalives can also remain useful for when the connection is proxied somewhere in the path, particularly application layer keepalives.  
 
-Carefully examine the entire end to end scenario to decide whether you benefit from enabling TCP Resets, adjusting the idle timeout, and if additional steps may be required to ensure the desired application behavior.
+By carefully examining the entire end to end scenario, you can determine the benefits from enabling TCP Resets and adjusting the idle timeout. Then you decide if more steps may be required to ensure the desired application behavior.
 
 ## Configurable TCP idle timeout
 
 Azure Load Balancer has the following idle timeout range:
 -  4 minutes to 100 minutes for Outbound Rules
 -  4 minutes to 30 minutes for Load Balancer rules and Inbound NAT rules
 
-By default, it is set to 4 minutes. If a period of inactivity is longer than the timeout value, there's no guarantee that the TCP or HTTP session is maintained between the client and your cloud service.
+By default, it's set to 4 minutes. If a period of inactivity is longer than the timeout value, there's no guarantee that the TCP or HTTP session is maintained between the client and your cloud service.
 
 When the connection is closed, your client application may receive the following error message: "The underlying connection was closed: A connection that was expected to be kept alive was closed by the server."
 
@@ -52,8 +52,8 @@ TCP keep-alive works for scenarios where battery life isn't a constraint. It isn
 ## Limitations
 
 - TCP reset only sent during TCP connection in ESTABLISHED state.
-- TCP idle timeout does not affect load balancing rules on UDP protocol.
-- TCP reset is not supported for ILB HA ports when a network virtual appliance is in the path. A workaround could be to use outbound rule with TCP reset from NVA.
+- TCP idle timeout doesn't affect load balancing rules on UDP protocol.
+- TCP reset isn't supported for ILB HA ports when a network virtual appliance is in the path. A workaround could be to use outbound rule with TCP reset from NVA.
 
 ## Next steps