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-b2c/custom-policy-developer-notes.md
+64-47Lines changed: 64 additions & 47 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@ manager: celestedg
9
9
ms.service: active-directory
10
10
ms.workload: identity
11
11
ms.topic: conceptual
12
-
ms.date: 02/12/2020
12
+
ms.date: 03/30/2020
13
13
ms.author: mimart
14
14
ms.subservice: B2C
15
15
---
@@ -55,85 +55,102 @@ Developers consuming the custom policy feature set should adhere to the followin
55
55
56
56
Custom policy/Identity Experience Framework capabilities are under constant and rapid development. The following table is an index of features and component availability.
Copy file name to clipboardExpand all lines: articles/active-directory/saas-apps/netskope-cloud-security-tutorial.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
@@ -80,7 +80,7 @@ Follow these steps to enable Azure AD SSO in the Azure portal.
80
80
1. On the **Basic SAML Configuration** section, if you wish to configure the application in **IDP** initiated mode, enter the values for the following fields:
81
81
82
82
a. In the **Identifier** text box, type a URL using the following pattern:
83
-
`Netskope_<OrgKey>`
83
+
`<OrgKey>`
84
84
85
85
b. In the **Reply URL** text box, type a URL using the following pattern:
86
86
`https://<tenant_host_name>/saml/acs`
@@ -231,4 +231,4 @@ When you click the Netskope Administrator Console tile in the Access Panel, you
231
231
232
232
-[What is conditional access in Azure Active Directory?](https://docs.microsoft.com/azure/active-directory/conditional-access/overview)
233
233
234
-
-[Try Netskope Administrator Console with Azure AD](https://aad.portal.azure.com/)
234
+
-[Try Netskope Administrator Console with Azure AD](https://aad.portal.azure.com/)
Copy file name to clipboardExpand all lines: articles/aks/private-clusters.md
+12Lines changed: 12 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -77,6 +77,18 @@ As mentioned, VNet peering is one way to access your private cluster. To use VNe
77
77
8. Select **Add**, add the virtual network of the VM, and then create the peering.
78
78
9. Go to the virtual network where you have the VM, select **Peerings**, select the AKS virtual network, and then create the peering. If the address ranges on the AKS virtual network and the VM's virtual network clash, peering fails. For more information, see [Virtual network peering][virtual-network-peering].
79
79
80
+
## Hub and spoke with custom DNS
81
+
82
+
[Hub and spoke architectures](https://docs.microsoft.com/azure/architecture/reference-architectures/hybrid-networking/hub-spoke) are commonly used to deploy networks in Azure. In many of these deployments, DNS settings in the spoke VNets are configured to reference a central DNS forwarder to allow for on-premises and Azure-based DNS resolution. When deploying an AKS cluster into such a networking environment, there are some special considerations that must be taken into account.
83
+
84
+

85
+
86
+
1. By default, when a private cluster is provisioned, a private endpoint (1) and a private DNS zone (2) are created in the cluster managed resource group. The cluster uses an A record in the private zone to resolve the IP of the private endpoint for communication to the API server.
87
+
88
+
2. The private DNS zone is linked only to the VNet that the cluster nodes are attached to (3). This means that the private endpoint can only be resolved by hosts in that linked VNet. In scenarios where no custom DNS is configured on the VNet (default), this works without issue as hosts point at 168.63.129.16 for DNS which can resolve records in the private DNS zone due to the link.
89
+
90
+
3. In scenarios where the VNet containing your cluster has custom DNS settings (4), cluster deployment fails unless the private DNS zone is linked to the VNet that contains the custom DNS resolvers (5). This link can be created manually after the private zone is created during cluster provisioning or via automation upon detection of creation of the zone using Azure Policy or other event-based deployment mechanisms (for example, Azure Event Grid and Azure Functions).
91
+
80
92
## Dependencies
81
93
82
94
* The Private Link service is supported on Standard Azure Load Balancer only. Basic Azure Load Balancer isn't supported.
0 commit comments