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/azure-monitor.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
@@ -11,12 +11,12 @@ ms.workload: identity
11
11
ms.topic: conceptual
12
12
ms.author: marsma
13
13
ms.subservice: B2C
14
-
ms.date: 02/03/2020
14
+
ms.date: 02/05/2020
15
15
---
16
16
17
17
# Monitor Azure AD B2C with Azure Monitor
18
18
19
-
Use Azure Monitor to route Azure Active Directory B2C (Azure AD B2C) usage activity events to different monitoring solutions. You can retain the logs for long-term use or integrate with third-party security information and event management (SIEM) tools to gain insights into your environment.
19
+
Use Azure Monitor to route Azure Active Directory B2C (Azure AD B2C) sign-in and [auditing](view-audit-logs.md) logs to different monitoring solutions. You can retain the logs for long-term use or integrate with third-party security information and event management (SIEM) tools to gain insights into your environment.
| OutputClaim | The name of the localized string | string | List of claim types that is produced after this claims transformation has been invoked. |
368
+
369
+
To use the GetLocalizedStringsTransformation claims transformation:
370
+
371
+
1. Define a [localization string](localization.md) and associate it with a [self-asserted-technical-profile](self-asserted-technical-profile.md).
372
+
1. The `ElementType` of the `LocalizedString` element must set to `GetLocalizedStringsTransformationClaimType`.
373
+
1. The `StringId` is a unique identifier that you define, and use it later in your claims transformation.
374
+
1. In the claims transformation specify the list of claims to be set with the localized string. The `ClaimTypeReferenceId` is a reference to a ClaimType already defined in the ClaimsSchema section in the policy. The `TransformationClaimType` is the name of the localized string as defined in the `StringId` of the `LocalizedString` element.
375
+
1. In a [self-asserted technical profile](self-asserted-technical-profile.md), or a [display control](display-controls.md) input or output claims transformation, make a reference to your claims transformation.
376
+
377
+
The following example looks up the email subject, body, your code message, and the signature of the email, from localized strings. These claims later used by custom email verification template.
378
+
379
+
Define localized strings for English (default) and Spanish.
<LocalizedStringElementType="GetLocalizedStringsTransformationClaimType"StringId="email_subject">Código de verificación del correo electrónico de la cuenta de Contoso</LocalizedString>
399
+
<LocalizedStringElementType="GetLocalizedStringsTransformationClaimType"StringId="email_message">Gracias por comprobar la cuenta de </LocalizedString>
Copy file name to clipboardExpand all lines: articles/active-directory/saas-apps/github-provisioning-tutorial.md
+2-1Lines changed: 2 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,6 +29,7 @@ The scenario outlined in this tutorial assumes that you already have the followi
29
29
* An Azure Active directory tenant
30
30
* A GitHub organization created in [GitHub Enterprise Cloud](https://help.github.com/articles/github-s-products/#github-enterprise), which requires the [GitHub Enterprise billing plan](https://help.github.com/articles/github-s-billing-plans/#billing-plans-for-organizations)
31
31
* A user account in GitHub with Admin permissions to the organization
32
+
* Ensure that OAuth access has been provided for your organization as described [here](https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/approving-oauth-apps-for-your-organization)
32
33
33
34
> [!NOTE]
34
35
> The Azure AD provisioning integration relies on the [GitHub SCIM API](https://developer.github.com/v3/scim/), which is available to [GitHub Enterprise Cloud](https://help.github.com/articles/github-s-products/#github-enterprise) customers on the [GitHub Enterprise billing plan](https://help.github.com/articles/github-s-billing-plans/#billing-plans-for-organizations).
@@ -66,7 +67,7 @@ This section guides you through connecting your Azure AD to GitHub's user accoun
5. Under the **Admin Credentials** section, click **Authorize**. This operation opens a GitHub authorization dialog in a new browser window.
70
+
5. Under the **Admin Credentials** section, click **Authorize**. This operation opens a GitHub authorization dialog in a new browser window. Note that you need to ensure you are approved to authorize access. Follow the directions described [here](https://help.github.com/github/setting-up-and-managing-organizations-and-teams/approving-oauth-apps-for-your-organization).
70
71
71
72
6. In the new window, sign into GitHub using your Admin account. In the resulting authorization dialog, select the GitHub team that you want to enable provisioning for, and then select **Authorize**. Once completed, return to the Azure portal to complete the provisioning configuration.
5. Under the **Admin Credentials** section, enter the admin username and admin password of your Samanage account. Examples of these values are:
100
+
5. Under the **Admin Credentials** section, input your Samanage **Tenant URL**and **Secret Token**. Click **Test Connection** to ensure Azure AD can connect to Samanage. If the connection fails, ensure your Samanage account has Admin permissions and try again.
101
101
102
-
* In the **Admin Username** box, fill in the username of the admin account on your Samanage tenant. An example is [email protected].
102
+
103
103
104
-
* In the **Admin Password** box, fill in the password of the admin account that corresponds to the admin username.
105
-
106
-
6. After you fill in the boxes shown in Step 5, select **Test Connection** to make sure that Azure AD can connect to Samanage. If the connection fails, make sure that your Samanage account has admin permissions and try again.
107
-
108
-
109
-
110
-
7. In the **Notification Email** box, enter the email address of the person or group to receive the provisioning error notifications. Select the **Send an email notification when a failure occurs** check box.
104
+
6. In the **Notification Email** box, enter the email address of the person or group to receive the provisioning error notifications. Select the **Send an email notification when a failure occurs** check box.
9. Under the **Mappings** section, select **Synchronize Azure Active Directory Users to Samanage**.
110
+
8. Under the **Mappings** section, select **Synchronize Azure Active Directory Users to Samanage**.
117
111
118
112
119
113
120
-
10. Review the user attributes that are synchronized from Azure AD to Samanage in the **Attribute Mappings** section. The attributes selected as **Matching** properties are used to match the user accounts in Samanage for update operations. To save any changes, select **Save**.
114
+
9. Review the user attributes that are synchronized from Azure AD to Samanage in the **Attribute Mappings** section. The attributes selected as **Matching** properties are used to match the user accounts in Samanage for update operations. To save any changes, select **Save**.
121
115
122
116
123
117
124
-
11. To enable group mappings, under the **Mappings** section, select **Synchronize Azure Active Directory Groups to Samanage**.
118
+
10. To enable group mappings, under the **Mappings** section, select **Synchronize Azure Active Directory Groups to Samanage**.
125
119
126
120
127
121
128
-
12. Set **Enabled** to **Yes** to synchronize groups. Review the group attributes that are synchronized from Azure AD to Samanage in the **Attribute Mappings** section. The attributes selected as **Matching** properties are used to match the user accounts in Samanage for update operations. To save any changes, select **Save**.
122
+
11. Set **Enabled** to **Yes** to synchronize groups. Review the group attributes that are synchronized from Azure AD to Samanage in the **Attribute Mappings** section. The attributes selected as **Matching** properties are used to match the user accounts in Samanage for update operations. To save any changes, select **Save**.
129
123
130
124
131
125
132
-
13. To configure scoping filters, follow the instructions in the [scoping filter tutorial](../manage-apps/define-conditional-rules-for-provisioning-user-accounts.md).
126
+
12. To configure scoping filters, follow the instructions in the [scoping filter tutorial](../manage-apps/define-conditional-rules-for-provisioning-user-accounts.md).
133
127
134
-
14. To enable the Azure AD provisioning service for Samanage, in the **Settings** section, change **Provisioning Status** to **On**.
128
+
13. To enable the Azure AD provisioning service for Samanage, in the **Settings** section, change **Provisioning Status** to **On**.
15. Define the users or groups that you want to provision to Samanage. In the **Settings** section, select the values you want in **Scope**. When you select the **Sync all users and groups** option, consider the limitations as described in the following section "Connector limitations."
132
+
14. Define the users or groups that you want to provision to Samanage. In the **Settings** section, select the values you want in **Scope**. When you select the **Sync all users and groups** option, consider the limitations as described in the following section "Connector limitations."
Copy file name to clipboardExpand all lines: articles/aks/concepts-network.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -113,8 +113,8 @@ Regardless of the network model you use, both kubenet and Azure CNI can be deplo
113
113
114
114
Although capabilities like service endpoints or UDRs are supported with both kubenet and Azure CNI, the [support policies for AKS][support-policies] define what changes you can make. For example:
115
115
116
-
* If you manually create the virtual network resources for an AKS cluster, you are supported when configuring your own UDRs or service endpoints.
117
-
* If the Azure platform automatically creates the virtual network resources for your AKS cluster, it is not supported to manually change those AKS-managed resources to configure your own UDRs or service endpoints.
116
+
* If you manually create the virtual network resources for an AKS cluster, you're supported when configuring your own UDRs or service endpoints.
117
+
* If the Azure platform automatically creates the virtual network resources for your AKS cluster, it isn't supported to manually change those AKS-managed resources to configure your own UDRs or service endpoints.
118
118
119
119
## Ingress controllers
120
120
@@ -128,7 +128,7 @@ In AKS, you can create an Ingress resource using something like NGINX, or use th
128
128
129
129
Another common feature of Ingress is SSL/TLS termination. On large web applications accessed via HTTPS, the TLS termination can be handled by the Ingress resource rather than within the application itself. To provide automatic TLS certification generation and configuration, you can configure the Ingress resource to use providers such as Let's Encrypt. For more information on configuring an NGINX Ingress controller with Let's Encrypt, see [Ingress and TLS][aks-ingress-tls].
130
130
131
-
You can also configure your ingress controller to preserve the client source IP on requests to containers in your AKS cluster. When a client's request is routed to a container in your AKS cluster via your ingress controller, the original source IP of that request will not be available to the target container. When you enable *client source IP preservation*, the source IP for the client is available in the request header under *X-Forwarded-For*. If you are using client source IP preservation on your ingress controller, you cannot use SSL pass-through. Client source IP preservation and SSL pass-through can be used with other services, such as the *LoadBalancer* type.
131
+
You can also configure your ingress controller to preserve the client source IP on requests to containers in your AKS cluster. When a client's request is routed to a container in your AKS cluster via your ingress controller, the original source IP of that request won't be available to the target container. When you enable *client source IP preservation*, the source IP for the client is available in the request header under *X-Forwarded-For*. If you're using client source IP preservation on your ingress controller, you can't use SSL pass-through. Client source IP preservation and SSL pass-through can be used with other services, such as the *LoadBalancer* type.
0 commit comments