Updates from: 04/29/2021 03:09:18
Service Microsoft Docs article Related commit history on GitHub Change details
active-directory-b2c Add Api Connector https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/add-api-connector.md
Previously updated : 03/24/2021 Last updated : 04/28/2021
+zone_pivot_groups: b2c-policy-type
-# Add an API connector to a sign-up user flow (preview)
+# Add an API connector to a sign-up user flow
+
+As a developer or IT administrator, you can use API connectors to integrate your sign-up user flows with REST APIs to customize the sign-up experience and integrate with external systems. At the end of this walkthrough, you'll be able to create an Azure AD B2C user flow that interacts with [REST API services](api-connectors-overview.md).
++
+In this scenario, the REST API validates whether email address' domain is fabrikam.com, or fabricam.com. The user-provided job title is greater than five characters.
> [!IMPORTANT] > API connectors for sign-up is a public preview feature of Azure AD B2C. For more information about previews, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
-To use an [API connector](api-connectors-overview.md), you first create the API connector and then enable it in a user flow.
++
+In this scenario, we'll add the ability for users to enter a loyalty number into the Azure AD B2C sign-up page. The REST API validates whether the combination of email and loyalty number is mapped to a promotional code. If the REST API finds a promotional code for this user, it will be returned to Azure AD B2C. Finally, the promotional code will be inserted into the token claims for the application to consume.
+
+You can also design the interaction as an orchestration step. This is suitable when the REST API will not be validating data on screen, and always return claims. For more information, see [Walkthrough: Integrate REST API claims exchanges in your Azure AD B2C user journey as an orchestration step](custom-policy-rest-api-claims-exchange.md).
++
+## Prerequisites
++ ## Create an API connector
+To use an [API connector](api-connectors-overview.md), you first create the API connector and then enable it in a user flow.
+ 1. Sign in to the [Azure portal](https://portal.azure.com/). 2. Under **Azure services**, select **Azure AD B2C**. 4. Select **API connectors (Preview)**, and then select **New API connector**.
HTTP basic authentication is defined in [RFC 2617](https://tools.ietf.org/html/r
> [!IMPORTANT] > This functionality is in preview and is provided without a service-level agreement. For more information, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).
-Client certificate authentication is a mutual certificate-based authentication method where the client provides a client certificate to the server to prove its identity. In this case, Azure AD B2C will use the certificate that you upload as part of the API connector configuration. This happens as a part of the SSL handshake. Your API service can then limit access to only services that have proper certificates. The client certificate is an PKCS12 (PFX) X.509 digital certificate. In production environments, it should be signed by a certificate authority.
+Client certificate authentication is a mutual certificate-based authentication method where the client provides a client certificate to the server to prove its identity. In this case, Azure AD B2C will use the certificate that you upload as part of the API connector configuration. This happens as a part of the TLS/SSL handshake. Your API service can then limit access to only services that have proper certificates. The client certificate is a PKCS12 (PFX) X.509 digital certificate. In production environments, it should be signed by a certificate authority.
To create a certificate, you can use [Azure Key Vault](../key-vault/certificates/create-certificate.md), which has options for self-signed certificates and integrations with certificate issuer providers for signed certificates. Recommended settings include: - **Subject**: `CN=<yourapiname>.<tenantname>.onmicrosoft.com`
To create a certificate, you can use [Azure Key Vault](../key-vault/certificates
You can then [export the certificate](../key-vault/certificates/how-to-export-certificate.md). You can alternatively use PowerShell's [New-SelfSignedCertificate cmdlet](../active-directory-b2c/secure-rest-api.md#prepare-a-self-signed-certificate-optional) to generate a self-signed certificate.
-After you have a certificate, you can then upload it as part of the API connector configuration. Note that password is only required for certificate files protected by a password.
+After you have a certificate, you can then upload it as part of the API connector configuration. Note, the password is only required for certificate files protected by a password.
Your API must implement the authorization based on sent client certificates in order to protect the API endpoints. For Azure App Service and Azure Functions, see [configure TLS mutual authentication](../app-service/app-service-web-configure-tls-mutual-auth.md) to learn how to enable and *validate the certificate from your API code*. You can also use Azure API Management to [check client certificate properties]( ../api-management/api-management-howto-mutual-certificates-for-clients.md) against desired values using policy expressions.
-It's recommended you set reminder alerts for when your certificate will expire. You will need to generate a new certificate and repeat the steps above. Your API service can temporarily continue to accept old and new certificates while the new certificate is deployed. To upload a new certificate to an existing API connector, select the API connector under **API connectors** and click on **Upload new certificate**. The most recently uploaded certificate which is not expired and is past the start date will automatically be used by Azure Active Directory.
+It's recommended you set reminder alerts for when your certificate will expire. You will need to generate a new certificate and repeat the steps above. Your API service can temporarily continue to accept old and new certificates while the new certificate is deployed. To upload a new certificate to an existing API connector, select the API connector under **API connectors** and click on **Upload new certificate**. The most recently uploaded certificate, which is not expired and is past the start date will automatically be used by Azure Active Directory.
### API Key+ Some services use an "API key" mechanism to obfuscate access to your HTTP endpoints during development. For [Azure Functions](../azure-functions/functions-bindings-http-webhook-trigger.md#authorization-keys), you can accomplish this by including the `code` as a query parameter in the **Endpoint URL**. For example, `https://contoso.azurewebsites.net/api/endpoint`<b>`?code=0123456789`</b>). This is not a mechanism that should be used alone in production. Therefore, configuration for basic or certificate authentication is always required. If you do not wish to implement any authentication method (not recommended) for development purposes, you can choose basic authentication and use temporary values for `username` and `password` that your API can disregard while you implement the authorization in your API.
Content-type: application/json
} ```
-The exact claims sent to the API depends on which information is provided by the identity provider. 'email' is always sent.
+The exact claims sent to the API depend on the information is provided by the identity provider. 'email' is always sent.
### Expected response types from the web API at this step
Content-type: application/json
"ui_locales":"en-US" } ```
-The exact claims sent to the API depends on which information is collected from the user or is provided by the identity provider.
+
+The claims that send to the API depend on the information is collected from the user or is provided by the identity provider.
### Expected response types from the web API at this step
Content-type: application/json
![Example validation page](./media/add-api-connector/validation-error-postal-code.png) +++
+## Prepare a REST API endpoint
+
+For this walkthrough, you should have a REST API that validates whether an email address is registered in your back-end system with a loyalty ID. If registered, the REST API should return a registration promotion code, which the customer can use to buy goods within your application. Otherwise, the REST API should return an HTTP 409 error message: "Loyalty ID '{loyalty ID}' is not associated with '{email}' email address.".
+
+The following JSON code illustrates the data Azure AD B2C will send to your REST API endpoint.
+
+```json
+{
+ "email": "User email address",
+ "language": "Current UI language",
+ "loyaltyId": "User loyalty ID"
+}
+```
+
+Once your REST API validates the data, it must return an HTTP 200 (Ok), with the following JSON data:
+
+```json
+{
+ "promoCode": "24534"
+}
+```
+
+If the validation failed, the REST API must return an HTTP 409 (Conflict), with the `userMessage` JSON element. The IEF expects the `userMessage` claim that the REST API returns. This claim will be presented as a string to the user if the validation fails.
+
+```json
+{
+ "version": "1.0.1",
+ "status": 409,
+ "userMessage": "LoyaltyId ID '1234' is not associated with 'david@contoso.com' email address."
+}
+```
+
+The setup of the REST API endpoint is outside the scope of this article. We have created an [Azure Functions](../azure-functions/functions-reference.md) sample. You can access the complete Azure function code at [GitHub](https://github.com/azure-ad-b2c/rest-api/tree/master/source-code/azure-function).
+
+## Define claims
+
+A claim provides temporary storage of data during an Azure AD B2C policy execution. You can declare claims within the [claims schema](claimsschema.md) section.
+
+1. Open the extensions file of your policy. For example, <em>`SocialAndLocalAccounts/`**`TrustFrameworkExtensions.xml`**</em>.
+1. Search for the [BuildingBlocks](buildingblocks.md) element. If the element doesn't exist, add it.
+1. Locate the [ClaimsSchema](claimsschema.md) element. If the element doesn't exist, add it.
+1. Add the following claims to the **ClaimsSchema** element.
+
+```xml
+<ClaimType Id="loyaltyId">
+ <DisplayName>Your loyalty ID</DisplayName>
+ <DataType>string</DataType>
+ <UserInputType>TextBox</UserInputType>
+</ClaimType>
+<ClaimType Id="promoCode">
+ <DisplayName>Your promo code</DisplayName>
+ <DataType>string</DataType>
+ <UserInputType>Paragraph</UserInputType>
+</ClaimType>
+ <ClaimType Id="userLanguage">
+ <DisplayName>User UI language (used by REST API to return localized error messages)</DisplayName>
+ <DataType>string</DataType>
+</ClaimType>
+```
+
+## Add the RESTful API technical profile
+
+A [Restful technical profile](restful-technical-profile.md) provides support for interfacing to your own RESTful service. Azure AD B2C sends data to the RESTful service in an `InputClaims` collection and receives data back in an `OutputClaims` collection. Find the **ClaimsProviders** element and add a new claims provider as follows:
+
+```xml
+<ClaimsProvider>
+ <DisplayName>REST APIs</DisplayName>
+ <TechnicalProfiles>
+ <TechnicalProfile Id="REST-ValidateProfile">
+ <DisplayName>Check loyaltyId Azure Function web hook</DisplayName>
+ <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
+ <Metadata>
+ <!-- Set the ServiceUrl with your own REST API endpoint -->
+ <Item Key="ServiceUrl">https://your-account.azurewebsites.net/api/ValidateProfile?code=your-code</Item>
+ <Item Key="SendClaimsIn">Body</Item>
+ <!-- Set AuthenticationType to Basic or ClientCertificate in production environments -->
+ <Item Key="AuthenticationType">None</Item>
+ <!-- REMOVE the following line in production environments -->
+ <Item Key="AllowInsecureAuthInProduction">true</Item>
+ </Metadata>
+ <InputClaims>
+ <!-- Claims sent to your REST API -->
+ <InputClaim ClaimTypeReferenceId="loyaltyId" />
+ <InputClaim ClaimTypeReferenceId="email" />
+ <InputClaim ClaimTypeReferenceId="userLanguage" PartnerClaimType="lang" DefaultValue="{Culture:LCID}" AlwaysUseDefaultValue="true" />
+ </InputClaims>
+ <OutputClaims>
+ <!-- Claims parsed from your REST API -->
+ <OutputClaim ClaimTypeReferenceId="promoCode" />
+ </OutputClaims>
+ <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
+ </TechnicalProfile>
+ </TechnicalProfiles>
+</ClaimsProvider>
+```
+
+In this example, the `userLanguage` will be sent to the REST service as `lang` within the JSON payload. The value of the `userLanguage` claim contains the current user language ID. For more information, see [claim resolver](claim-resolver-overview.md).
+
+### Configure the RESTful API technical profile
+
+After you deploy your REST API, set the metadata of the `REST-ValidateProfile` technical profile to reflect your own REST API, including:
+
+- **ServiceUrl**. Set the URL of the REST API endpoint.
+- **SendClaimsIn**. Specify how the input claims are sent to the RESTful claims provider.
+- **AuthenticationType**. Set the type of authentication being performed by the RESTful claims provider.
+- **AllowInsecureAuthInProduction**. In a production environment, make sure to set this metadata to `true`
+
+See the [RESTful technical profile metadata](restful-technical-profile.md#metadata) for more configurations.
+
+The comments above `AuthenticationType` and `AllowInsecureAuthInProduction` specify changes you should make when you move to a production environment. To learn how to secure your RESTful APIs for production, see [Secure RESTful API](secure-rest-api.md).
+
+## Validate the user input
+
+To obtain the user's loyalty number during sign-up, you must allow the user to enter this data on the screen. Add the **loyaltyId** output claim to the sign-up page by adding it to the existing sign-up technical profile section's `OutputClaims` element. Specify the entire list of output claims to control the order the claims are presented on the screen.
+
+Add the validation technical profile reference to the sign-up technical profile, which calls the `REST-ValidateProfile`. The new validation technical profile will be added to the top of the `<ValidationTechnicalProfiles>` collection defined in the base policy. This behavior means that only after successful validation, Azure AD B2C moves on to create the account in the directory.
+
+1. Find the **ClaimsProviders** element. Add a new claims provider as follows:
+
+ ```xml
+ <ClaimsProvider>
+ <DisplayName>Local Account</DisplayName>
+ <TechnicalProfiles>
+ <TechnicalProfile Id="LocalAccountSignUpWithLogonEmail">
+ <OutputClaims>
+ <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="Verified.Email" Required="true"/>
+ <OutputClaim ClaimTypeReferenceId="newPassword" Required="true"/>
+ <OutputClaim ClaimTypeReferenceId="reenterPassword" Required="true"/>
+ <OutputClaim ClaimTypeReferenceId="displayName"/>
+ <OutputClaim ClaimTypeReferenceId="givenName"/>
+ <OutputClaim ClaimTypeReferenceId="surName"/>
+ <!-- Required to present the text box to collect the data from the user -->
+ <OutputClaim ClaimTypeReferenceId="loyaltyId"/>
+ <!-- Required to pass the promoCode returned from "REST-ValidateProfile"
+ to subsequent orchestration steps and token issuance-->
+ <OutputClaim ClaimTypeReferenceId="promoCode" />
+ </OutputClaims>
+ <ValidationTechnicalProfiles>
+ <ValidationTechnicalProfile ReferenceId="REST-ValidateProfile" />
+ </ValidationTechnicalProfiles>
+ </TechnicalProfile>
+ </TechnicalProfiles>
+ </ClaimsProvider>
+ <ClaimsProvider>
+ <DisplayName>Self Asserted</DisplayName>
+ <TechnicalProfiles>
+ <TechnicalProfile Id="SelfAsserted-Social">
+ <InputClaims>
+ <InputClaim ClaimTypeReferenceId="email" />
+ </InputClaims>
+ <OutputClaims>
+ <OutputClaim ClaimTypeReferenceId="email" />
+ <OutputClaim ClaimTypeReferenceId="displayName"/>
+ <OutputClaim ClaimTypeReferenceId="givenName"/>
+ <OutputClaim ClaimTypeReferenceId="surname"/>
+ <!-- Required to present the text box to collect the data from the user -->
+ <OutputClaim ClaimTypeReferenceId="loyaltyId"/>
+ <!-- Required to pass the promoCode returned from "REST-ValidateProfile"
+ to subsequent orchestration steps and token issuance-->
+ <OutputClaim ClaimTypeReferenceId="promoCode" />
+ </OutputClaims>
+ <ValidationTechnicalProfiles>
+ <ValidationTechnicalProfile ReferenceId="REST-ValidateProfile"/>
+ </ValidationTechnicalProfiles>
+ </TechnicalProfile>
+ </TechnicalProfiles>
+ </ClaimsProvider>
+ ```
+
+## Include a claim in the token
+
+To return the promo code claim back to the relying party application, add an output claim to the <em>`SocialAndLocalAccounts/`**`SignUpOrSignIn.xml`**</em> file. The output claim will allow the claim to be added into the token after a successful user journey, and will be sent to the application. Modify the technical profile element within the relying party section to add the `promoCode` as an output claim.
+
+```xml
+<RelyingParty>
+ <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
+ <TechnicalProfile Id="PolicyProfile">
+ <DisplayName>PolicyProfile</DisplayName>
+ <Protocol Name="OpenIdConnect" />
+ <OutputClaims>
+ <OutputClaim ClaimTypeReferenceId="displayName" />
+ <OutputClaim ClaimTypeReferenceId="givenName" />
+ <OutputClaim ClaimTypeReferenceId="surname" />
+ <OutputClaim ClaimTypeReferenceId="email" />
+ <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
+ <OutputClaim ClaimTypeReferenceId="identityProvider" />
+ <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
+ <OutputClaim ClaimTypeReferenceId="promoCode" DefaultValue="" />
+ </OutputClaims>
+ <SubjectNamingInfo ClaimType="sub" />
+ </TechnicalProfile>
+</RelyingParty>
+```
+
+## Test the custom policy
+
+1. Sign in to the [Azure portal](https://portal.azure.com).
+1. Make sure you're using the directory that contains your Azure AD tenant by selecting the **Directory + subscription** filter in the top menu and choosing the directory that contains your Azure AD tenant.
+1. Choose **All services** in the top-left corner of the Azure portal, and then search for and select **App registrations**.
+1. Select **Identity Experience Framework**.
+1. Select **Upload Custom Policy**, and then upload the policy files that you changed: *TrustFrameworkExtensions.xml*, and *SignUpOrSignin.xml*.
+1. Select the sign-up or sign-in policy that you uploaded, and click the **Run now** button.
+1. You should be able to sign up using an email address.
+1. Click on the **Sign-up now** link.
+1. In the **Your loyalty ID**, type 1234, and click **Continue**. At this point, you should get a validation error message.
+1. Change to another value and click **Continue**.
+1. The token sent back to your application includes the `promoCode` claim.
+
+```json
+{
+ "typ": "JWT",
+ "alg": "RS256",
+ "kid": "X5eXk4xyojNFum1kl2Ytv8dlNP4-c57dO6QGTVBwaNk"
+}.{
+ "exp": 1584295703,
+ "nbf": 1584292103,
+ "ver": "1.0",
+ "iss": "https://contoso.b2clogin.com/f06c2fe8-709f-4030-85dc-38a4bfd9e82d/v2.0/",
+ "aud": "e1d2612f-c2bc-4599-8e7b-d874eaca1ee1",
+ "acr": "b2c_1a_signup_signin",
+ "nonce": "defaultNonce",
+ "iat": 1584292103,
+ "auth_time": 1584292103,
+ "name": "Emily Smith",
+ "email": "emily@outlook.com",
+ "given_name": "Emily",
+ "family_name": "Smith",
+ "promoCode": "84362"
+ ...
+}
+```
++ ## Best practices and how to troubleshoot ### Using serverless cloud functions
-Serverless functions, like HTTP triggers in Azure Functions, provide a simple way create API endpoints to use with the API connector. You can use the serverless cloud function to, [for example](code-samples.md#api-connectors), perform validation logic and limit sign-ups to specific email domains. The serverless cloud function can also call and invoke other web APIs, user stores, and other cloud services for more complex scenarios.
+
+Serverless functions, like HTTP triggers in Azure Functions, provide a way create API endpoints to use with the API connector. You can use the serverless cloud function to, [for example](code-samples.md#api-connectors), perform validation logic and limit sign-ups to specific email domains. The serverless cloud function can also call and invoke other web APIs, user stores, and other cloud services for more complex scenarios.
### Best practices Ensure that:
Ensure that:
* The **Endpoint URL** of the API connector points to the correct API endpoint. * Your API explicitly checks for null values of received claims. * Your API responds as quickly as possible to ensure a fluid user experience.
- * If using a serverless function or scalable web service, use a hosting plan that keeps the API "awake" or "warm." in production. For Azure Functions, its recommended to use the [Premium plan](../azure-functions/functions-scale.md)
+ * If using a serverless function or scalable web service, use a hosting plan that keeps the API "awake" or "warm." in production. For Azure Functions, it's recommended to use the [Premium plan](../azure-functions/functions-scale.md)
- ### Use logging+ In general, it's helpful to use the logging tools enabled by your web API service, like [Application insights](../azure-functions/functions-monitoring.md), to monitor your API for unexpected error codes, exceptions, and poor performance. * Monitor for HTTP status codes that aren't HTTP 200 or 400. * A 401 or 403 HTTP status code typically indicates there's an issue with your authentication. Double-check your API's authentication layer and the corresponding configuration in the API connector.
-* Use more aggressive levels of logging (e.g. "trace" or "debug") in development if needed.
+* Use more aggressive levels of logging (for example "trace" or "debug") in development if needed.
* Monitor your API for long response times. ## Next steps++ - Get started with our [samples](code-samples.md#api-connectors).
+- [Secure your API Connector](secure-rest-api.md)
+++
+- [Walkthrough: Integrate REST API claims exchanges in your Azure AD B2C user journey as an orchestration step](custom-policy-rest-api-claims-exchange.md)
+- [Secure your API Connector](secure-rest-api.md)
+- [Reference: RESTful technical profile](restful-technical-profile.md)
+
active-directory-b2c Api Connectors Overview https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/api-connectors-overview.md
Design your REST API service and its underlying components (such as the database
See the following articles for examples of using a RESTful technical profile: -- [Walkthrough: Integrate REST API claims exchanges in your Azure AD B2C user journey as validation of user input](custom-policy-rest-api-claims-validation.md)-- [Walkthrough: Add REST API claims exchanges to custom policies in Azure Active Directory B2C](custom-policy-rest-api-claims-validation.md)
+- [Walkthrough: Add an API connector to a sign-up user flow](add-api-connector.md)
+- [Walkthrough: Add REST API claims exchanges to custom policies in Azure Active Directory B2C](custom-policy-rest-api-claims-exchange.md)
- [Secure your REST API services](secure-rest-api.md) - [Reference: RESTful technical profile](restful-technical-profile.md)
active-directory-b2c Custom Policy Rest Api Claims Exchange https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/custom-policy-rest-api-claims-exchange.md
Previously updated : 10/15/2020 Last updated : 04/28/2021
+zone_pivot_groups: b2c-policy-type
# Walkthrough: Add REST API claims exchanges to custom policies in Azure Active Directory B2C ++++ Azure Active Directory B2C (Azure AD B2C) enables identity developers to integrate an interaction with a RESTful API in a user journey. At the end of this walkthrough, you'll be able to create an Azure AD B2C user journey that interacts with [RESTful services](api-connectors-overview.md). In this scenario, we enrich the user's token data by integrating with a corporate line-of-business workflow. During sign-up or sign-in with local or federated account, Azure AD B2C invokes a REST API to get the user's extended profile data from a remote data source. In this sample, Azure AD B2C sends the user's unique identifier, the objectId. The REST API then returns the user's account balance (a random number). Use this sample as a starting point to integrate with your own CRM system, marketing database, or any line-of-business workflow.
-You can also design the interaction as a validation technical profile. This is suitable when the REST API will be validating data on screen and returning claims. For more information, see [Walkthrough: Integrate REST API claims exchanges in your Azure AD B2C user journey to validate user input](custom-policy-rest-api-claims-validation.md).
+You can also design the interaction as a validation technical profile. This is suitable when the REST API will be validating data on screen and returning claims. For more information, see [Walkthrough: Add an API connector to a sign-up user flow](add-api-connector.md).
## Prerequisites
To learn how to secure your APIs, see the following articles:
- [Walkthrough: Integrate REST API claims exchanges in your Azure AD B2C user journey as an orchestration step](custom-policy-rest-api-claims-exchange.md) - [Secure your RESTful API](secure-rest-api.md)-- [Reference: RESTful technical profile](restful-technical-profile.md)
+- [Reference: RESTful technical profile](restful-technical-profile.md)
+
active-directory-b2c Custom Policy Rest Api Claims Validation https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/custom-policy-rest-api-claims-validation.md
- Title: REST API claims exchanges as validation-
-description: A walkthrough for creating an Azure AD B2C user journey that interacts with RESTful services.
------- Previously updated : 10/15/2020----
-# Walkthrough: Integrate REST API claims exchanges in your Azure AD B2C user journey to validate user input
--
-The Identity Experience Framework (IEF) that underpins Azure Active Directory B2C (Azure AD B2C) enables identity developers to integrate an interaction with a RESTful API in a user journey. At the end of this walkthrough, you'll be able to create an Azure AD B2C user journey that interacts with [RESTful services](api-connectors-overview.md) to validate user input.
-
-In this scenario, we'll add the ability for users to enter a loyalty number into the Azure AD B2C sign-up page. We'll validate whether this combination of email and loyalty number is mapped to a promotional code by sending this data to a REST API. If the REST API finds a promotional code for this user, it will be returned to Azure AD B2C. Finally, the promotional code will be inserted into the token claims for the application to consume.
-
-You can also design the interaction as an orchestration step. This is suitable when the REST API will not be validating data on screen, and always return claims. For more information, see [Walkthrough: Integrate REST API claims exchanges in your Azure AD B2C user journey as an orchestration step](custom-policy-rest-api-claims-exchange.md).
-
-## Prerequisites
--- Complete the steps in [Get started with custom policies](tutorial-create-user-flows.md?pivots=b2c-custom-policy). You should have a working custom policy for sign-up and sign-in with local accounts.-- Learn how to [Integrate REST API claims exchanges in your Azure AD B2C custom policy](api-connectors-overview.md).-
-## Prepare a REST API endpoint
-
-For this walkthrough, you should have a REST API that validates whether an email address is registered in your back-end system with a loyalty ID. If registered, the REST API should return a registration promotion code, which the customer can use to buy goods within your application. Otherwise, the REST API should return an HTTP 409 error message: "Loyalty ID '{loyalty ID}' is not associated with '{email}' email address.".
-
-The following JSON code illustrates the data Azure AD B2C will send to your REST API endpoint.
-
-```json
-{
- "email": "User email address",
- "language": "Current UI language",
- "loyaltyId": "User loyalty ID"
-}
-```
-
-Once your REST API validates the data, it must return an HTTP 200 (Ok), with the following JSON data:
-
-```json
-{
- "promoCode": "24534"
-}
-```
-
-If the validation failed, the REST API must return an HTTP 409 (Conflict), with the `userMessage` JSON element. The IEF expects the `userMessage` claim that the REST API returns. This claim will be presented as a string to the user if the validation fails.
-
-```json
-{
- "version": "1.0.1",
- "status": 409,
- "userMessage": "LoyaltyId ID '1234' is not associated with 'david@contoso.com' email address."
-}
-```
-
-The setup of the REST API endpoint is outside the scope of this article. We have created an [Azure Functions](../azure-functions/functions-reference.md) sample. You can access the complete Azure function code at [GitHub](https://github.com/azure-ad-b2c/rest-api/tree/master/source-code/azure-function).
-
-## Define claims
-
-A claim provides temporary storage of data during an Azure AD B2C policy execution. You can declare claims within the [claims schema](claimsschema.md) section.
-
-1. Open the extensions file of your policy. For example, <em>`SocialAndLocalAccounts/`**`TrustFrameworkExtensions.xml`**</em>.
-1. Search for the [BuildingBlocks](buildingblocks.md) element. If the element doesn't exist, add it.
-1. Locate the [ClaimsSchema](claimsschema.md) element. If the element doesn't exist, add it.
-1. Add the following claims to the **ClaimsSchema** element.
-
-```xml
-<ClaimType Id="loyaltyId">
- <DisplayName>Your loyalty ID</DisplayName>
- <DataType>string</DataType>
- <UserInputType>TextBox</UserInputType>
-</ClaimType>
-<ClaimType Id="promoCode">
- <DisplayName>Your promo code</DisplayName>
- <DataType>string</DataType>
- <UserInputType>Paragraph</UserInputType>
-</ClaimType>
- <ClaimType Id="userLanguage">
- <DisplayName>User UI language (used by REST API to return localized error messages)</DisplayName>
- <DataType>string</DataType>
-</ClaimType>
-```
-
-## Add the RESTful API technical profile
-
-A [Restful technical profile](restful-technical-profile.md) provides support for interfacing to your own RESTful service. Azure AD B2C sends data to the RESTful service in an `InputClaims` collection and receives data back in an `OutputClaims` collection. Find the **ClaimsProviders** element and add a new claims provider as follows:
-
-```xml
-<ClaimsProvider>
- <DisplayName>REST APIs</DisplayName>
- <TechnicalProfiles>
- <TechnicalProfile Id="REST-ValidateProfile">
- <DisplayName>Check loyaltyId Azure Function web hook</DisplayName>
- <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
- <Metadata>
- <!-- Set the ServiceUrl with your own REST API endpoint -->
- <Item Key="ServiceUrl">https://your-account.azurewebsites.net/api/ValidateProfile?code=your-code</Item>
- <Item Key="SendClaimsIn">Body</Item>
- <!-- Set AuthenticationType to Basic or ClientCertificate in production environments -->
- <Item Key="AuthenticationType">None</Item>
- <!-- REMOVE the following line in production environments -->
- <Item Key="AllowInsecureAuthInProduction">true</Item>
- </Metadata>
- <InputClaims>
- <!-- Claims sent to your REST API -->
- <InputClaim ClaimTypeReferenceId="loyaltyId" />
- <InputClaim ClaimTypeReferenceId="email" />
- <InputClaim ClaimTypeReferenceId="userLanguage" PartnerClaimType="lang" DefaultValue="{Culture:LCID}" AlwaysUseDefaultValue="true" />
- </InputClaims>
- <OutputClaims>
- <!-- Claims parsed from your REST API -->
- <OutputClaim ClaimTypeReferenceId="promoCode" />
- </OutputClaims>
- <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
- </TechnicalProfile>
- </TechnicalProfiles>
-</ClaimsProvider>
-```
-
-In this example, the `userLanguage` will be sent to the REST service as `lang` within the JSON payload. The value of the `userLanguage` claim contains the current user language ID. For more information, see [claim resolver](claim-resolver-overview.md).
-
-### Configure the RESTful API technical profile
-
-After you deploy your REST API, set the metadata of the `REST-ValidateProfile` technical profile to reflect your own REST API, including:
--- **ServiceUrl**. Set the URL of the REST API endpoint.-- **SendClaimsIn**. Specify how the input claims are sent to the RESTful claims provider.-- **AuthenticationType**. Set the type of authentication being performed by the RESTful claims provider. -- **AllowInsecureAuthInProduction**. In a production environment, make sure to set this metadata to `true`
-
-See the [RESTful technical profile metadata](restful-technical-profile.md#metadata) for more configurations.
-
-The comments above `AuthenticationType` and `AllowInsecureAuthInProduction` specify changes you should make when you move to a production environment. To learn how to secure your RESTful APIs for production, see [Secure RESTful API](secure-rest-api.md).
-
-## Validate the user input
-
-To obtain the user's loyalty number during sign-up, you must allow the user to enter this data on the screen. Add the **loyaltyId** output claim to the sign-up page by adding it to the existing sign-up technical profile section's `OutputClaims` element. Specify the entire list of output claims to control the order the claims are presented on the screen.
-
-Add the validation technical profile reference to the sign-up technical profile, which calls the `REST-ValidateProfile`. The new validation technical profile will be added to the top of the `<ValidationTechnicalProfiles>` collection defined in the base policy. This behavior means that only after successful validation, Azure AD B2C moves on to create the account in the directory.
-
-1. Find the **ClaimsProviders** element. Add a new claims provider as follows:
-
- ```xml
- <ClaimsProvider>
- <DisplayName>Local Account</DisplayName>
- <TechnicalProfiles>
- <TechnicalProfile Id="LocalAccountSignUpWithLogonEmail">
- <OutputClaims>
- <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="Verified.Email" Required="true"/>
- <OutputClaim ClaimTypeReferenceId="newPassword" Required="true"/>
- <OutputClaim ClaimTypeReferenceId="reenterPassword" Required="true"/>
- <OutputClaim ClaimTypeReferenceId="displayName"/>
- <OutputClaim ClaimTypeReferenceId="givenName"/>
- <OutputClaim ClaimTypeReferenceId="surName"/>
- <!-- Required to present the text box to collect the data from the user -->
- <OutputClaim ClaimTypeReferenceId="loyaltyId"/>
- <!-- Required to pass the promoCode returned from "REST-ValidateProfile"
- to subsequent orchestration steps and token issuance-->
- <OutputClaim ClaimTypeReferenceId="promoCode" />
- </OutputClaims>
- <ValidationTechnicalProfiles>
- <ValidationTechnicalProfile ReferenceId="REST-ValidateProfile" />
- </ValidationTechnicalProfiles>
- </TechnicalProfile>
- </TechnicalProfiles>
- </ClaimsProvider>
- <ClaimsProvider>
- <DisplayName>Self Asserted</DisplayName>
- <TechnicalProfiles>
- <TechnicalProfile Id="SelfAsserted-Social">
- <InputClaims>
- <InputClaim ClaimTypeReferenceId="email" />
- </InputClaims>
- <OutputClaims>
- <OutputClaim ClaimTypeReferenceId="email" />
- <OutputClaim ClaimTypeReferenceId="displayName"/>
- <OutputClaim ClaimTypeReferenceId="givenName"/>
- <OutputClaim ClaimTypeReferenceId="surname"/>
- <!-- Required to present the text box to collect the data from the user -->
- <OutputClaim ClaimTypeReferenceId="loyaltyId"/>
- <!-- Required to pass the promoCode returned from "REST-ValidateProfile"
- to subsequent orchestration steps and token issuance-->
- <OutputClaim ClaimTypeReferenceId="promoCode" />
- </OutputClaims>
- <ValidationTechnicalProfiles>
- <ValidationTechnicalProfile ReferenceId="REST-ValidateProfile"/>
- </ValidationTechnicalProfiles>
- </TechnicalProfile>
- </TechnicalProfiles>
- </ClaimsProvider>
- ```
-
-## Include a claim in the token
-
-To return the promo code claim back to the relying party application, add an output claim to the <em>`SocialAndLocalAccounts/`**`SignUpOrSignIn.xml`**</em> file. The output claim will allow the claim to be added into the token after a successful user journey, and will be sent to the application. Modify the technical profile element within the relying party section to add the `promoCode` as an output claim.
-
-```xml
-<RelyingParty>
- <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
- <TechnicalProfile Id="PolicyProfile">
- <DisplayName>PolicyProfile</DisplayName>
- <Protocol Name="OpenIdConnect" />
- <OutputClaims>
- <OutputClaim ClaimTypeReferenceId="displayName" />
- <OutputClaim ClaimTypeReferenceId="givenName" />
- <OutputClaim ClaimTypeReferenceId="surname" />
- <OutputClaim ClaimTypeReferenceId="email" />
- <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
- <OutputClaim ClaimTypeReferenceId="identityProvider" />
- <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
- <OutputClaim ClaimTypeReferenceId="promoCode" DefaultValue="" />
- </OutputClaims>
- <SubjectNamingInfo ClaimType="sub" />
- </TechnicalProfile>
-</RelyingParty>
-```
-
-## Test the custom policy
-
-1. Sign in to the [Azure portal](https://portal.azure.com).
-1. Make sure you're using the directory that contains your Azure AD tenant by selecting the **Directory + subscription** filter in the top menu and choosing the directory that contains your Azure AD tenant.
-1. Choose **All services** in the top-left corner of the Azure portal, and then search for and select **App registrations**.
-1. Select **Identity Experience Framework**.
-1. Select **Upload Custom Policy**, and then upload the policy files that you changed: *TrustFrameworkExtensions.xml*, and *SignUpOrSignin.xml*.
-1. Select the sign-up or sign-in policy that you uploaded, and click the **Run now** button.
-1. You should be able to sign up using an email address.
-1. Click on the **Sign-up now** link.
-1. In the **Your loyalty ID**, type 1234, and click **Continue**. At this point, you should get a validation error message.
-1. Change to another value and click **Continue**.
-1. The token sent back to your application includes the `promoCode` claim.
-
-```json
-{
- "typ": "JWT",
- "alg": "RS256",
- "kid": "X5eXk4xyojNFum1kl2Ytv8dlNP4-c57dO6QGTVBwaNk"
-}.{
- "exp": 1584295703,
- "nbf": 1584292103,
- "ver": "1.0",
- "iss": "https://contoso.b2clogin.com/f06c2fe8-709f-4030-85dc-38a4bfd9e82d/v2.0/",
- "aud": "e1d2612f-c2bc-4599-8e7b-d874eaca1ee1",
- "acr": "b2c_1a_signup_signin",
- "nonce": "defaultNonce",
- "iat": 1584292103,
- "auth_time": 1584292103,
- "name": "Emily Smith",
- "email": "emily@outlook.com",
- "given_name": "Emily",
- "family_name": "Smith",
- "promoCode": "84362"
- ...
-}
-```
-
-## Next steps
-
-To learn how to secure your APIs, see the following articles:
--- [Walkthrough: Integrate REST API claims exchanges in your Azure AD B2C user journey as an orchestration step](custom-policy-rest-api-claims-exchange.md)-- [Secure your RESTful API](secure-rest-api.md)-- [Reference: RESTful technical profile](restful-technical-profile.md)
active-directory-b2c Partner Cloudflare https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/partner-cloudflare.md
Previously updated : 02/24/2021 Last updated : 04/24/2021
active-directory-b2c Partner Dynamics 365 Fraud Protection https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/partner-dynamics-365-fraud-protection.md
Configure the application settings in the [App service in Azure](../app-service/
| Application settings | Source | Notes | | :-- | :| :--|
-|FraudProtectionSettings:InstanceId | Microsoft DFP Configuration | |
-|FraudProtectionSettings:DeviceFingerprintingCustomerId | Your Microsoft device fingerprinting customer ID | |
+| FraudProtectionSettings:InstanceId | Microsoft DFP Configuration | |
+| FraudProtectionSettings:DeviceFingerprintingCustomerId | Your Microsoft device fingerprinting customer ID | |
| FraudProtectionSettings:ApiBaseUrl | Your Base URL from Microsoft DFP Portal | Remove '-int' to call the production API instead|
-| TokenProviderConfig: Resource | Your Base URL - `https://api.dfp.dynamics-int.com` | Remove '-int' to call the production API instead|
-| TokenProviderConfig:ClientId |Your Fraud Protection merchant Azure AD client app ID | |
-| TokenProviderConfig:Authority | https://login.microsoftonline.com/<directory_ID> | Your Fraud Protection merchant Azure AD tenant authority |
-| TokenProviderConfig:CertificateThumbprint* | The thumbprint of the certificate to use to authenticate against your merchant Azure AD client app |
-| TokenProviderConfig:ClientSecret* | The secret for your merchant Azure AD client app | Recommended to use a secrets manager |
+| FraudProtectionSettings:TokenProviderConfig:Resource | Your Base URL - `https://api.dfp.dynamics-int.com` | Remove '-int' to call the production API instead|
+| FraudProtectionSettings:TokenProviderConfig:ClientId |Your Fraud Protection merchant Azure AD client app ID | |
+| FraudProtectionSettings:TokenProviderConfig:Authority | https://login.microsoftonline.com/<directory_ID> | Your Fraud Protection merchant Azure AD tenant authority |
+| FraudProtectionSettings:TokenProviderConfig:CertificateThumbprint* | The thumbprint of the certificate to use to authenticate against your merchant Azure AD client app |
+| FraudProtectionSettings:TokenProviderConfig:ClientSecret* | The secret for your merchant Azure AD client app | Recommended to use a secrets manager |
*Only set 1 of the 2 marked parameters depending on if you authenticate with a certificate or a secret such as a password.
active-directory-b2c Predicates https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/predicates.md
The IsLengthRange method checks whether the length of a string claim value is wi
| Maximum | Yes | The maximum number of characters that can be entered. | | Minimum | Yes | The minimum number of characters that must be entered. | - The following example shows a IsLengthRange method with the parameters `Minimum` and `Maximum` that specify the length range of the string: ```xml
The **PredicateReference** element contains the following attributes:
| | -- | -- | | Id | Yes | An identifier that's used for the predicate validation. | - ## Configure password complexity With **Predicates** and **PredicateValidationsInput** you can control the complexity requirements for passwords provided by a user when creating an account. By default, Azure AD B2C uses strong passwords. Azure AD B2C also supports configuration options to control the complexity of passwords that customers can use. You can define password complexity by using these predicate elements:
In your claim type, add **PredicateValidationReference** element and specify the
<UserInputType>DateTimeDropdown</UserInputType> <PredicateValidationReference Id="CustomDateRange" /> </ClaimType>
- ```
+```
## Next steps -- Learn how to [Configure password complexity using custom policies in Azure Active Directory B2C](password-complexity.md) using predicate validations.
+- Learn how to [Configure password complexity using custom policies in Azure Active Directory B2C](password-complexity.md) using predicate validations.
active-directory-b2c Restful Technical Profile https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/restful-technical-profile.md
public class ResponseContent
See the following articles for examples of using a RESTful technical profile: - [Integrate REST API claims exchanges in your Azure AD B2C custom policy](api-connectors-overview.md)-- [Walkthrough: Integrate REST API claims exchanges in your Azure AD B2C user journey as validation of user input](custom-policy-rest-api-claims-validation.md)-- [Walkthrough: Add REST API claims exchanges to custom policies in Azure Active Directory B2C](custom-policy-rest-api-claims-validation.md)
+- [Walkthrough: Add an API connector to a sign-up user flow](add-api-connector.md)
+- [Walkthrough: Add REST API claims exchanges to custom policies in Azure Active Directory B2C](custom-policy-rest-api-claims-exchange.md)
- [Secure your REST API services](secure-rest-api.md)
active-directory-b2c Secure Rest Api https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/secure-rest-api.md
Previously updated : 04/21/2021 Last updated : 04/28/2021
+zone_pivot_groups: b2c-policy-type
-# Secure your RESTful services
+# Secure your API Connector
-When integrating a REST API within an Azure AD B2C user journey, you must protect your REST API endpoint with authentication. This ensures that only services that have proper credentials, such as Azure AD B2C, can make calls to your REST API endpoint.
-
-Learn how to integrate a REST API within your Azure AD B2C user journey in the [validate user input](custom-policy-rest-api-claims-validation.md) and [Add REST API claims exchanges to custom policies](custom-policy-rest-api-claims-exchange.md) articles.
-
-This article will explore how to secure your REST API with either HTTP basic, client certificate or OAuth2 authentication.
+When integrating a REST API within an Azure AD B2C user flow, you must protect your REST API endpoint with authentication. The REST API authentication ensures that only services that have proper credentials, such as Azure AD B2C, can make calls to your endpoint. This article will explore how to secure REST API.
## Prerequisites
-Complete the steps in one of the following 'How to' guides:
--- [Integrate REST API claims exchanges in your Azure AD B2C user journey to validate user input](custom-policy-rest-api-claims-validation.md).-- [Add REST API claims exchanges to custom policies](custom-policy-rest-api-claims-exchange.md)
+Complete the steps in the [Walkthrough: Add an API connector to a sign-up user flow](add-api-connector.md) guide.
## HTTP basic authentication HTTP basic authentication is defined in [RFC 2617](https://tools.ietf.org/html/rfc2617). Basic authentication works as follows: Azure AD B2C sends an HTTP request with the client credentials in the Authorization header. The credentials are formatted as the base64-encoded string "name:password". +
+To configure an API Connector with HTTP basic authentication, follow these steps:
+
+1. Sign in to the [Azure portal](https://portal.azure.com/).
+1. Under **Azure services**, select **Azure AD B2C**.
+1. Select **API connectors (Preview)**, and then select the **API Connector** you want to configure.
+1. For the **Authentication type**, select **Basic**.
+1. Provide the **Username**, and **Password** of your REST API endpoint.
+1. Select **Save**.
+++ ### Add REST API username and password policy keys To configure a REST API technical profile with HTTP basic authentication, create the following cryptographic keys to store the username and password:
After creating the necessary keys, configure your REST API technical profile met
</CryptographicKeys> ```
-The following is an example of a RESTful technical profile configured with HTTP basic authentication:
+The following XML snippet is an example of a RESTful technical profile configured with HTTP basic authentication:
```xml <ClaimsProvider>
The following is an example of a RESTful technical profile configured with HTTP
</TechnicalProfiles> </ClaimsProvider> ``` ## HTTPS client certificate authentication
Client certificate authentication is a mutual certificate-based authentication,
### Prepare a self-signed certificate (optional)
-For non-production environments, if you don't already have a certificate, you can use a self-signed certificate. On Windows, you can use PowerShell's [New-SelfSignedCertificate](/powershell/module/pki/new-selfsignedcertificate) cmdlet to generate a certificate.
-
-1. Execute this PowerShell command to generate a self-signed certificate. Modify the `-Subject` argument as appropriate for your application and Azure AD B2C tenant name. You can also adjust the `-NotAfter` date to specify a different expiration for the certificate.
- ```powershell
- New-SelfSignedCertificate `
- -KeyExportPolicy Exportable `
- -Subject "CN=yourappname.yourtenant.onmicrosoft.com" `
- -KeyAlgorithm RSA `
- -KeyLength 2048 `
- -KeyUsage DigitalSignature `
- -NotAfter (Get-Date).AddMonths(12) `
- -CertStoreLocation "Cert:\CurrentUser\My"
- ```
-1. Open **Manage user certificates** > **Current User** > **Personal** > **Certificates** > *yourappname.yourtenant.onmicrosoft.com*.
-1. Select the certificate > **Action** > **All Tasks** > **Export**.
-1. Select **Yes** > **Next** > **Yes, export the private key** > **Next**.
-1. Accept the defaults for **Export File Format**.
-1. Provide a password for the certificate.
++
+### Configure your API Connector
+
+To configure an API Connector with client certificate authentication, follow these steps:
+
+1. Sign in to the [Azure portal](https://portal.azure.com/).
+1. Under **Azure services**, select **Azure AD B2C**.
+1. Select **API connectors (Preview)**, and then select the **API Connector** you want to configure.
+1. For the **Authentication type**, select **Certificate**.
+1. In the **Upload certificate** box, select your certificate's .pfx file with a private key.
+1. In the **Enter Password** box, type the certificate's password.
+1. Select **Save**.
++ ### Add a client certificate policy key
After creating the necessary key, configure your REST API technical profile meta
</CryptographicKeys> ```
-The following is an example of a RESTful technical profile configured with an HTTP client certificate:
+The following XML snippet is an example of a RESTful technical profile configured with an HTTP client certificate:
```xml <ClaimsProvider>
After creating the necessary key, configure your REST API technical profile meta
</CryptographicKeys> ```
-The following is an example of a RESTful technical profile configured with bearer token authentication:
+The following XML snippet is an example of a RESTful technical profile configured with bearer token authentication:
```xml <ClaimsProvider>
After creating the necessary key, configure your REST API technical profile meta
The **Id** of the cryptographic key defines the HTTP header. In this example, the API key is sent as **x-functions-key**.
-The following is an example of a RESTful technical profile configured to call an Azure Function with API key authentication:
+The following XML snippet is an example of a RESTful technical profile configured to call an Azure Function with API key authentication:
```xml <ClaimsProvider>
The following is an example of a RESTful technical profile configured to call an
## Next steps -- Learn more about the [Restful technical profile](restful-technical-profile.md) element in the IEF reference.
+- Learn more about the [Restful technical profile](restful-technical-profile.md) element in the custom policy reference.
+
active-directory-b2c User Profile Attributes https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-b2c/user-profile-attributes.md
Title: User profile attributes in Azure Active Directory B2C
-description: Learn about the user resource type attributes that are supported by the Azure AD B2C directory user profile. Find out about built-in attributes, extensions, and how attributes map to Microsoft Graph.
+description: Learn about the user resource type attributes that are supported by the Azure AD B2C directory user profile. Find out about built-in attributes, extensions, and how attributes map to Microsoft Graph.
# User profile attributes
-Your Azure Active Directory (Azure AD) B2C directory user profile comes with a built-in set of attributes, such as given name, surname, city, postal code, and phone number. You can extend the user profile with your own application data without requiring an external data store.
+Your Azure Active Directory (Azure AD) B2C directory user profile comes with a built-in set of attributes, such as given name, surname, city, postal code, and phone number. You can extend the user profile with your own application data without requiring an external data store.
Most of the attributes that can be used with Azure AD B2C user profiles are also supported by Microsoft Graph. This article describes supported Azure AD B2C user profile attributes. It also notes those attributes that are not supported by Microsoft Graph, as well as Microsoft Graph attributes that should not be used with Azure AD B2C.
A customer account, which could be a consumer, partner, or citizen, can be assoc
- **Local** identity - The username and password are stored locally in the Azure AD B2C directory. We often refer to these identities as "local accounts." - **Federated** identity - Also known as a *social* or *enterprise* accounts, the identity of the user is managed by a federated identity provider like Facebook, Microsoft, ADFS, or Salesforce.
-A user with a customer account can sign in with multiple identities. For example, username, email, employee ID, government ID, and others. A single account can have multiple identities, both local and social, with the same password.
+A user with a customer account can sign in with multiple identities. For example, username, email, employee ID, government ID, and others. A single account can have multiple identities, both local and social, with the same password.
In the Microsoft Graph API, both local and federated identities are stored in the user `identities` attribute, which is of type [objectIdentity](/graph/api/resources/objectidentity). The `identities` collection represents a set of identities used to sign in to a user account. This collection enables the user to sign in to the user account with any of its associated identities. The identities attribute can contain up to ten [objectIdentity](/graph/api/resources/objectidentity) objects. Each object contains the following properties:
In the Microsoft Graph API, both local and federated identities are stored in th
|issuer|string|Specifies the issuer of the identity. For local accounts (where **signInType** is not `federated`), this property is the local B2C tenant default domain name, for example `contoso.onmicrosoft.com`. For social identity (where **signInType** is `federated`) the value is the name of the issuer, for example `facebook.com`| |issuerAssignedId|string|Specifies the unique identifier assigned to the user by the issuer. The combination of **issuer** and **issuerAssignedId** must be unique within your tenant. For local account, when **signInType** is set to `emailAddress` or `userName`, it represents the sign-in name for the user.<br>When **signInType** is set to: <ul><li>`emailAddress` (or starts with `emailAddress` like `emailAddress1`) **issuerAssignedId** must be a valid email address</li><li>`userName` (or any other value), **issuerAssignedId** must be a valid [local part of an email address](https://tools.ietf.org/html/rfc3696#section-3)</li><li>`federated`, **issuerAssignedId** represents the federated account unique identifier</li></ul>|
-The following **Identities** attribute, with a local account identity with a sign-in name, an email address as sign-in, and with a social identity.
-
- ```json
- "identities": [
- {
- "signInType": "userName",
- "issuer": "contoso.onmicrosoft.com",
- "issuerAssignedId": "johnsmith"
- },
- {
- "signInType": "emailAddress",
- "issuer": "contoso.onmicrosoft.com",
- "issuerAssignedId": "jsmith@yahoo.com"
- },
- {
- "signInType": "federated",
- "issuer": "facebook.com",
- "issuerAssignedId": "5eecb0cd"
- }
- ]
- ```
-
-For federated identities, depending on the identity provider, the **issuerAssignedId** is a unique value for a given user per application or development account. Configure the Azure AD B2C policy with the same application ID that was previously assigned by the social provider or another application within the same development account.
+The following **Identities** attribute, with a local account identity with a sign-in name, an email address as sign-in, and with a social identity.
+
+```json
+"identities": [
+ {
+ "signInType": "userName",
+ "issuer": "contoso.onmicrosoft.com",
+ "issuerAssignedId": "johnsmith"
+ },
+ {
+ "signInType": "emailAddress",
+ "issuer": "contoso.onmicrosoft.com",
+ "issuerAssignedId": "jsmith@yahoo.com"
+ },
+ {
+ "signInType": "federated",
+ "issuer": "facebook.com",
+ "issuerAssignedId": "5eecb0cd"
+ }
+]
+```
+
+For federated identities, depending on the identity provider, the **issuerAssignedId** is a unique value for a given user per application or development account. Configure the Azure AD B2C policy with the same application ID that was previously assigned by the social provider or another application within the same development account.
## Password profile property
active-directory-domain-services Deploy Azure App Proxy https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-domain-services/deploy-azure-app-proxy.md
If you deploy multiple Azure AD Application Proxy connectors, you must configure
## Next steps
-With the Azure AD Application Proxy integrated with Azure AD DS, publish applications for users to access. For more information, see [publish applications using Azure AD Application Proxy](../active-directory/manage-apps/application-proxy-add-on-premises-application.md).
+With the Azure AD Application Proxy integrated with Azure AD DS, publish applications for users to access. For more information, see [publish applications using Azure AD Application Proxy](../active-directory/app-proxy/application-proxy-add-on-premises-application.md).
<!-- INTERNAL LINKS --> [create-azure-ad-tenant]: ../active-directory/fundamentals/sign-up-organization.md
active-directory-domain-services Overview https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-domain-services/overview.md
Previously updated : 01/20/2021 Last updated : 04/28/2021
Azure AD DS replicates identity information from Azure AD, so it works with Azur
* If you have an existing on-premises AD DS environment, you can synchronize user account information to provide a consistent identity for users. To learn more, see [How objects and credentials are synchronized in a managed domain][synchronization]. * For cloud-only environments, you don't need a traditional on-premises AD DS environment to use the centralized identity services of Azure AD DS.
-You can expand a managed domain to have more than one replica set per Azure AD tenant. Replica sets can be added to any peered virtual network in any Azure region that supports Azure AD DS. Additional replica sets in different Azure regions provide geographical disaster recovery for legacy applications if an Azure region goes offline. Replica sets are currently in preview. For more information, see [Replica sets concepts and features for managed domains][concepts-replica-sets].
+You can expand a managed domain to have more than one replica set per Azure AD tenant. Replica sets can be added to any peered virtual network in any Azure region that supports Azure AD DS. Additional replica sets in different Azure regions provide geographical disaster recovery for legacy applications if an Azure region goes offline. For more information, see [Replica sets concepts and features for managed domains][concepts-replica-sets].
-The following video provides an overview of how Azure AD DS integrates with your applications and workloads to provide identity services in the cloud:
+Take a look at this video about how Azure AD DS integrates with your applications and workloads to provide identity services in the cloud:
<br />
active-directory-domain-services Policy Reference https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory-domain-services/policy-reference.md
Title: Built-in policy definitions for Azure Active Directory Domain Services description: Lists Azure Policy built-in policy definitions for Azure Active Directory Domain Services. These built-in policy definitions provide common approaches to managing your Azure resources. Previously updated : 04/22/2021 Last updated : 04/28/2021
active-directory Plan Cloud Hr Provision https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-provisioning/plan-cloud-hr-provision.md
We recommend the following production configuration:
The cloud HR app to Active Directory user provisioning solution requires that you deploy one or more Azure AD Connect provisioning agents on servers that run Windows 2012 R2 or greater. The servers must have a minimum of 4-GB RAM and .NET 4.7.1+ runtime. Ensure that the host server has network access to the target Active Directory domain.
-To prepare the on-premises environment, the Azure AD Connect provisioning agent configuration wizard registers the agent with your Azure AD tenant, [opens ports](../manage-apps/application-proxy-add-on-premises-application.md#open-ports), [allows access to URLs](../manage-apps/application-proxy-add-on-premises-application.md#allow-access-to-urls), and supports [outbound HTTPS proxy configuration](../saas-apps/workday-inbound-tutorial.md#how-do-i-configure-the-provisioning-agent-to-use-a-proxy-server-for-outbound-http-communication).
+To prepare the on-premises environment, the Azure AD Connect provisioning agent configuration wizard registers the agent with your Azure AD tenant, [opens ports](../app-proxy/application-proxy-add-on-premises-application.md#open-ports), [allows access to URLs](../app-proxy/application-proxy-add-on-premises-application.md#allow-access-to-urls), and supports [outbound HTTPS proxy configuration](../saas-apps/workday-inbound-tutorial.md#how-do-i-configure-the-provisioning-agent-to-use-a-proxy-server-for-outbound-http-communication).
The provisioning agent uses a service account to communicate with the Active Directory domains. Before you install the agent, create a service account in Active Directory Users and Computers that meets the following requirements:
active-directory Use Scim To Provision Users And Groups https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-provisioning/use-scim-to-provision-users-and-groups.md
Previously updated : 04/12/2021 Last updated : 04/28/2021
Use the general guidelines when implementing a SCIM endpoint to ensure compatibi
* The entitlements attribute is not supported. * Support HTTPS on your SCIM endpoint. * [Schema discovery](#schema-discovery)
- * Schema discovery is not currently supported on the custom application, but it is being used on certain gallery applications. Going forward, schema discovery will be used as the primary method to add additional attributes to a connector.
+ * Schema discovery is not currently supported on the custom application, but it is being used on certain gallery applications. Going forward, schema discovery will be used as the sole method to add additional attributes to an existing connector.
* If a value is not present, do not send null values. * Property values should be camel cased (e.g. readWrite). * Must return a list response.
+ * The /schemas request will be made by the Azure AD SCIM client every time someone saves the provisioning configuration in the Azure Portal or every time a user lands on the edit provisioning page in the Azure Portal. Any additional attributes discovered will be surfaced to customers in the attribute mappings under the target attribute list. Schema discovery only leads to additional target attributes being added. It will not result in attributes being removed.
### User provisioning and deprovisioning
active-directory Active Directory App Proxy Protect Ndes https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/active-directory-app-proxy-protect-ndes.md
+
+ Title: Integrate with Azure Active Directory Application Proxy on an NDES server
+description: Guidance on deploying an Azure Active Directory Application Proxy to protect your NDES server.
+++++++ Last updated : 04/27/2021+++
+# Integrate with Azure Active Directory Application Proxy on a Network Device Enrollment Service (NDES) server
+
+Azure Active Directory (AD) Application Proxy lets you publish applications inside your network. These applications are ones such as SharePoint sites, Microsoft Outlook Web App, and other web applications. It also provides secure access to users outside your network via Azure.
+
+If you're new to Azure AD Application Proxy and want to learn more, see [Remote access to on-premises applications through Azure AD Application Proxy](application-proxy.md).
+
+Azure AD Application Proxy is built on Azure. It gives you a massive amount of network bandwidth and server infrastructure for better protection against distributed denial-of-service (DDOS) attacks and superb availability. Furthermore, there's no need to open external firewall ports to your on-premises network and no DMZ server is required. All traffic is originated inbound. For a complete list of outbound ports, see [Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory](./application-proxy-add-on-premises-application.md#prepare-your-on-premises-environment).
+
+> Azure AD Application Proxy is a feature that is available only if you are using the Premium or Basic editions of Azure Active Directory. For more information, see [Azure Active Directory pricing](https://azure.microsoft.com/pricing/details/active-directory/).
+> If you have Enterprise Mobility Suite (EMS) licenses, you are eligible to use this solution.
+> The Azure AD Application Proxy connector only installs on Windows Server 2012 R2 or later. This is also a requirement of the NDES server.
+
+## Install and register the connector on the NDES server
+
+1. Sign in to the [Azure portal](https://portal.azure.com/) as an application administrator of the directory that uses Application Proxy. For example, if the tenant domain is contoso.com, the admin should be admin@contoso.com or any other admin alias on that domain.
+1. Select your username in the upper-right corner. Verify you're signed in to a directory that uses Application Proxy. If you need to change directories, select **Switch directory** and choose a directory that uses Application Proxy.
+1. In left navigation panel, select **Azure Active Directory**.
+1. Under **Manage**, select **Application proxy**.
+1. Select **Download connector service**.
+
+ ![Download connector service to see the Terms of Service](./media/active-directory-app-proxy-protect-ndes/application-proxy-download-connector-service.png)
+
+1. Read the Terms of Service. When you're ready, select **Accept terms & Download**.
+1. Copy the Azure AD Application Proxy connector setup file to your NDES server.
+ > You can install the connector on any server within your corporate network with access to NDES. You don't have to install it on the NDES server itself.
+1. Run the setup file, such as *AADApplicationProxyConnectorInstaller.exe*. Accept the software license terms.
+1. During the install, you're prompted to register the connector with the Application Proxy in your Azure AD directory.
+ * Provide the credentials for a global or application administrator in your Azure AD directory. The Azure AD global or application administrator credentials may be different from your Azure credentials in the portal.
+
+ > [!NOTE]
+ > The global or application administrator account used to register the connector must belong to the same directory where you enable the Application Proxy service.
+ >
+ > For example, if the Azure AD domain is *contoso.com*, the global/application administrator should be `admin@contoso.com` or another valid alias on that domain.
+
+ * If Internet Explorer Enhanced Security Configuration is turned on for the server where you install the connector, the registration screen might be blocked. To allow access, follow the instructions in the error message, or turn off Internet Explorer Enhanced Security during the install process.
+ * If connector registration fails, see [Troubleshoot Application Proxy](application-proxy-troubleshoot.md).
+1. At the end of the setup, a note is shown for environments with an outbound proxy. To configure the Azure AD Application Proxy connector to work through the outbound proxy, run the provided script, such as `C:\Program Files\Microsoft AAD App Proxy connector\ConfigureOutBoundProxy.ps1`.
+1. On the Application proxy page in the Azure portal, the new connector is listed with a status of *Active*, as shown in the following example:
+
+ ![The new Azure AD Application Proxy connector shown as active in the Azure portal](./media/active-directory-app-proxy-protect-ndes/connected-app-proxy.png)
+
+ > [!NOTE]
+ > To provide high availability for applications authenticating through the Azure AD Application Proxy, you can install connectors on multiple VMs. Repeat the same steps listed in the previous section to install the connector on other servers joined to the Azure AD DS managed domain.
+
+1. After successful installation, go back to the Azure portal.
+
+1. Select **Enterprise applications**.
+
+ ![ensure that you're engaging the right stakeholders](./media/active-directory-app-proxy-protect-ndes/azure-active-directory-enterprise-applications.png)
+
+1. Select **+New Application**, and then select **On-premises application**.
+
+1. On the **Add your own on-premises application**, configure the following fields:
+
+ * **Name**: Enter a name for the application.
+ * **Internal Url**: Enter the internal URL/FQDN of your NDES server on which you installed the connector.
+ * **Pre Authentication**: Select **Passthrough**. ItΓÇÖs not possible to use any form of pre-authentication. The protocol used for Certificate Requests (SCEP) doesn't provide such option.
+ * Copy the provided **External URL** to your clipboard.
+
+1. Select **+Add** to save your application.
+
+1. Test whether you can access your NDES server via the Azure AD Application proxy by pasting the link you copied in step 15 into a browser. You should see a default IIS welcome page.
+
+1. As a final test, add the *mscep.dll* path to the existing URL you pasted in the previous step:
+
+ https://scep-test93635307549127448334.msappproxy.net/certsrv/mscep/mscep.dll
+
+1. You should see an **HTTP Error 403 ΓÇô Forbidden** response.
+
+1. Change the NDES URL provided (via Microsoft Intune) to devices. This change could either be in Microsoft Endpoint Configuration Manager or the Microsoft Endpoint Manager admin center.
+
+ * For Configuration Manager, go to the certificate registration point and adjust the URL. This URL is what devices call out to and present their challenge.
+ * For Intune standalone, either edit or create a new SCEP policy and add the new URL.
+
+## Next steps
+
+With the Azure AD Application Proxy integrated with NDES, publish applications for users to access. For more information, see [publish applications using Azure AD Application Proxy](./application-proxy-add-on-premises-application.md).
active-directory Application Proxy Add On Premises Application https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-add-on-premises-application.md
+
+ Title: Tutorial - Add an on-premises app - Application Proxy in Azure Active Directory
+description: Azure Active Directory (Azure AD) has an Application Proxy service that enables users to access on-premises applications by signing in with their Azure AD account. This tutorial shows you how to prepare your environment for use with Application Proxy. Then, it uses the Azure portal to add an on-premises application to your Azure AD tenant.
+++++++ Last updated : 02/17/2021+++++
+# Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory
+
+Azure Active Directory (Azure AD) has an Application Proxy service that enables users to access on-premises applications by signing in with their Azure AD account. To learn more about Application Proxy, see [What is App Proxy?](what-is-application-proxy.md). This tutorial prepares your environment for use with Application Proxy. Once your environment is ready, you'll use the Azure portal to add an on-premises application to your Azure AD tenant.
++
+Before you get started, make sure you are familiar with app management and **Single Sign-On (SSO)** concepts. Check out the following links:
+- [Quickstart Series on App Management in Azure AD](../manage-apps/view-applications-portal.md)
+- [What is Single Sign-On (SSO)?](../manage-apps/what-is-single-sign-on.md)
+
+Connectors are a key part of Application Proxy. To learn more about connectors, see [Understand Azure AD Application Proxy connectors](application-proxy-connectors.md).
+
+This tutorial:
+
+> [!div class="checklist"]
+> * Opens ports for outbound traffic and allows access to specific URLs
+> * Installs the connector on your Windows server, and registers it with Application Proxy
+> * Verifies the connector installed and registered correctly
+> * Adds an on-premises application to your Azure AD tenant
+> * Verifies a test user can sign on to the application by using an Azure AD account
+
+## Prerequisites
+
+To add an on-premises application to Azure AD, you need:
+
+* A [Microsoft Azure AD premium subscription](https://azure.microsoft.com/pricing/details/active-directory)
+* An application administrator account
+* User identities must be synchronized from an on-premises directory or created directly within your Azure AD tenants. Identity synchronization allows Azure AD to pre-authenticate users before granting them access to App Proxy published applications and to have the necessary user identifier information to perform single sign-on (SSO).
+
+### Windows server
+
+To use Application Proxy, you need a Windows server running Windows Server 2012 R2 or later. You'll install the Application Proxy connector on the server. This connector server needs to connect to the Application Proxy services in Azure, and the on-premises applications that you plan to publish.
+
+For high availability in your production environment, we recommend having more than one Windows server. For this tutorial, one Windows server is sufficient.
+
+> [!IMPORTANT]
+> If you are installing the connector on Windows Server 2019, you must disable HTTP2 protocol support in the WinHttp component for Kerberos Constrained Delegation to properly work. This is disabled by default in earlier versions of supported operating systems. Adding the following registry key and restarting the server disables it on Windows Server 2019. Note that this is a machine-wide registry key.
+>
+> ```
+> Windows Registry Editor Version 5.00
+>
+> [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
+> "EnableDefaultHTTP2"=dword:00000000
+> ```
+>
+> The key can be set via PowerShell with the following command.
+> ```
+> Set-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp\' -Name EnableDefaultHTTP2 -Value 0
+> ```
+
+#### Recommendations for the connector server
+
+1. Physically locate the connector server close to the application servers to optimize performance between the connector and the application. For more information, see [Optimize traffic flow with Azure Active Directory Application Proxy](application-proxy-network-topology.md).
+1. The connector server and the web applications servers should belong to the same Active Directory domain or span trusting domains. Having the servers in the same domain or trusting domains is a requirement for using single sign-on (SSO) with Integrated Windows Authentication (IWA) and Kerberos Constrained Delegation (KCD). If the connector server and web application servers are in different Active Directory domains, you need to use resource-based delegation for single sign-on. For more information, see [KCD for single sign-on with Application Proxy](../manage-apps/application-proxy-configure-single-sign-on-with-kcd.md).
+
+> [!WARNING]
+> If you've deployed Azure AD Password Protection Proxy, do not install Azure AD Application Proxy and Azure AD Password Protection Proxy together on the same machine. Azure AD Application Proxy and Azure AD Password Protection Proxy install different versions of the Azure AD Connect Agent Updater service. These different versions are incompatible when installed together on the same machine.
+
+#### TLS requirements
+
+The Windows connector server needs to have TLS 1.2 enabled before you install the Application Proxy connector.
+
+To enable TLS 1.2:
+
+1. Set the following registry keys:
+
+ ```
+ Windows Registry Editor Version 5.00
+
+ [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]
+ [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
+ "DisabledByDefault"=dword:00000000
+ "Enabled"=dword:00000001
+ [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
+ "DisabledByDefault"=dword:00000000
+ "Enabled"=dword:00000001
+ [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
+ "SchUseStrongCrypto"=dword:00000001
+ ```
+
+1. Restart the server.
+
+> [!Note]
+> Microsoft is updating Azure services to use TLS certificates from a different set of Root Certificate Authorities (CAs). This change is being made because the current CA certificates do not comply with one of the C) for more information.
+
+## Prepare your on-premises environment
+
+Start by enabling communication to Azure data centers to prepare your environment for Azure AD Application Proxy. If there's a firewall in the path, make sure it's open. An open firewall allows the connector to make HTTPS (TCP) requests to the Application Proxy.
+
+> [!IMPORTANT]
+> If you are installing the connector for Azure Government cloud follow the [pre-requisites](../hybrid/reference-connect-government-cloud.md#allow-access-to-urls) and [installation steps](../hybrid/reference-connect-government-cloud.md#install-the-agent-for-the-azure-government-cloud). This requires enabling access to a different set of URLs and an additional parameter to run the installation.
+
+### Open ports
+
+Open the following ports to **outbound** traffic.
+
+| Port number | How it's used |
+| -- | |
+| 80 | Downloading certificate revocation lists (CRLs) while validating the TLS/SSL certificate |
+| 443 | All outbound communication with the Application Proxy service |
+
+If your firewall enforces traffic according to originating users, also open ports 80 and 443 for traffic from Windows services that run as a Network Service.
+
+### Allow access to URLs
+
+Allow access to the following URLs:
+
+| URL | Port | How it's used |
+| | | |
+| &ast;.msappproxy.net<br>&ast;.servicebus.windows.net | 443/HTTPS | Communication between the connector and the Application Proxy cloud service |
+| crl3.digicert.com<br>crl4.digicert.com<br>ocsp.digicert.com<br>crl.microsoft.com<br>oneocsp.microsoft.com<br>ocsp.msocsp.com<br> | 80/HTTP | The connector uses these URLs to verify certificates. |
+| login.windows.net<br>secure.aadcdn.microsoftonline-p.com<br>&ast;.microsoftonline.com<br>&ast;.microsoftonline-p.com<br>&ast;.msauth.net<br>&ast;.msauthimages.net<br>&ast;.msecnd.net<br>&ast;.msftauth.net<br>&ast;.msftauthimages.net<br>&ast;.phonefactor.net<br>enterpriseregistration.windows.net<br>management.azure.com<br>policykeyservice.dc.ad.msft.net<br>ctldl.windowsupdate.com<br>www.microsoft.com/pkiops | 443/HTTPS | The connector uses these URLs during the registration process. |
+| ctldl.windowsupdate.com | 80/HTTP | The connector uses this URL during the registration process. |
+
+You can allow connections to &ast;.msappproxy.net, &ast;.servicebus.windows.net, and other URLs above if your firewall or proxy lets you configure access rules based on domain suffixes. If not, you need to allow access to the [Azure IP ranges and Service Tags - Public Cloud](https://www.microsoft.com/download/details.aspx?id=56519). The IP ranges are updated each week.
+
+### DNS name resolution for Azure AD Application Proxy endpoints
+
+Public DNS records for Azure AD Application Proxy endpoints are chained CNAME records pointing to an A record. This ensures fault tolerance and flexibility. ItΓÇÖs guaranteed that the Azure AD Application Proxy Connector always accesses hostnames with the domain suffixes _*.msappproxy.net_ or _*.servicebus.windows.net_. However, during the name resolution the CNAME records might contain DNS records with different hostnames and suffixes. Due to this, you must ensure that the device (depending on your setup - connector server, firewall, outbound proxy) can resolve all the records in the chain and allows connection to the resolved IP addresses. Since the DNS records in the chain might be changed from time to time, we cannot provide you with any list DNS records.
+
+## Install and register a connector
+
+To use Application Proxy, install a connector on each Windows server you're using with the Application Proxy service. The connector is an agent that manages the outbound connection from the on-premises application servers to Application Proxy in Azure AD. You can install a connector on servers that also have other authentication agents installed such as Azure AD Connect.
++
+To install the connector:
+
+1. Sign in to the [Azure portal](https://portal.azure.com/) as an application administrator of the directory that uses Application Proxy. For example, if the tenant domain is contoso.com, the admin should be admin@contoso.com or any other admin alias on that domain.
+1. Select your username in the upper-right corner. Verify you're signed in to a directory that uses Application Proxy. If you need to change directories, select **Switch directory** and choose a directory that uses Application Proxy.
+1. In left navigation panel, select **Azure Active Directory**.
+1. Under **Manage**, select **Application proxy**.
+1. Select **Download connector service**.
+
+ ![Download connector service to see the Terms of Service](./media/application-proxy-add-on-premises-application/application-proxy-download-connector-service.png)
+
+1. Read the Terms of Service. When you're ready, select **Accept terms & Download**.
+1. At the bottom of the window, select **Run** to install the connector. An install wizard opens.
+1. Follow the instructions in the wizard to install the service. When you're prompted to register the connector with the Application Proxy for your Azure AD tenant, provide your application administrator credentials.
+
+ - For Internet Explorer (IE), if **IE Enhanced Security Configuration** is set to **On**, you may not see the registration screen. To get access, follow the instructions in the error message. Make sure that **Internet Explorer Enhanced Security Configuration** is set to **Off**.
+
+### General remarks
+
+If you've previously installed a connector, reinstall to get the latest version. To see information about previously released versions and what changes they include, see [Application Proxy: Version Release History](../manage-apps/application-proxy-release-version-history.md).
+
+If you choose to have more than one Windows server for your on-premises applications, you'll need to install and register the connector on each server. You can organize the connectors into connector groups. For more information, see [Connector groups](../manage-apps/application-proxy-connector-groups.md).
+
+If you have installed connectors in different regions, you can optimize traffic by selecting the closest Application Proxy cloud service region to use with each connector group, see [Optimize traffic flow with Azure Active Directory Application Proxy](application-proxy-network-topology.md)
+
+If your organization uses proxy servers to connect to the internet, you need to configure them for Application Proxy. For more information, see [Work with existing on-premises proxy servers](../manage-apps/application-proxy-configure-connectors-with-proxy-servers.md).
+
+For information about connectors, capacity planning, and how they stay up-to-date, see [Understand Azure AD Application Proxy connectors](application-proxy-connectors.md).
+
+## Verify the connector installed and registered correctly
+
+You can use the Azure portal or your Windows server to confirm that a new connector installed correctly.
+
+### Verify the installation through Azure portal
+
+To confirm the connector installed and registered correctly:
+
+1. Sign in to your tenant directory in the [Azure portal](https://portal.azure.com).
+1. In the left navigation panel, select **Azure Active Directory**, and then select **Application Proxy** under the **Manage** section. All of your connectors and connector groups appear on this page.
+1. View a connector to verify its details. The connectors should be expanded by default. If the connector you want to view isn't expanded, expand the connector to view the details. An active green label indicates that your connector can connect to the service. However, even though the label is green, a network issue could still block the connector from receiving messages.
+
+ ![Azure AD Application Proxy Connectors](./media/application-proxy-add-on-premises-application/app-proxy-connectors.png)
+
+For more help with installing a connector, see [Problem installing the Application Proxy Connector](../manage-apps/application-proxy-connector-installation-problem.md).
+
+### Verify the installation through your Windows server
+
+To confirm the connector installed and registered correctly:
+
+1. Open the Windows Services Manager by clicking the **Windows** key and entering *services.msc*.
+1. Check to see if the status for the following two services is **Running**.
+ - **Microsoft AAD Application Proxy Connector** enables connectivity.
+ - **Microsoft AAD Application Proxy Connector Updater** is an automated update service. The updater checks for new versions of the connector and updates the connector as needed.
+
+ ![App Proxy Connector services - screenshot](./media/application-proxy-add-on-premises-application/app_proxy_services.png)
+
+1. If the status for the services isn't **Running**, right-click to select each service and choose **Start**.
+
+## Add an on-premises app to Azure AD
+
+Now that you've prepared your environment and installed a connector, you're ready to add on-premises applications to Azure AD.
+
+1. Sign in as an administrator in the [Azure portal](https://portal.azure.com/).
+2. In the left navigation panel, select **Azure Active Directory**.
+3. Select **Enterprise applications**, and then select **New application**.
+4. Select **Add an on-premises application** button which appears about halfway down the page in the **On-premises applications** section. Alternatively, you can select **Create your own application** at the top of the page and then select **Configure Application Proxy for secure remote access to an on-premise application**.
+5. In the **Add your own on-premises application** section, provide the following information about your application:
+
+ | Field | Description |
+ | : | :-- |
+ | **Name** | The name of the application that will appear on My Apps and in the Azure portal. |
+ | **Internal URL** | The URL for accessing the application from inside your private network. You can provide a specific path on the backend server to publish, while the rest of the server is unpublished. In this way, you can publish different sites on the same server as different apps, and give each one its own name and access rules.<br><br>If you publish a path, make sure that it includes all the necessary images, scripts, and style sheets for your application. For example, if your app is at https:\//yourapp/app and uses images located at https:\//yourapp/media, then you should publish https:\//yourapp/ as the path. This internal URL doesn't have to be the landing page your users see. For more information, see [Set a custom home page for published apps](application-proxy-configure-custom-home-page.md). |
+ | **External URL** | The address for users to access the app from outside your network. If you don't want to use the default Application Proxy domain, read about [custom domains in Azure AD Application Proxy](../manage-apps/application-proxy-configure-custom-domain.md). |
+ | **Pre Authentication** | How Application Proxy verifies users before giving them access to your application.<br><br>**Azure Active Directory** - Application Proxy redirects users to sign in with Azure AD, which authenticates their permissions for the directory and application. We recommend keeping this option as the default so that you can take advantage of Azure AD security features like Conditional Access and Multi-Factor Authentication. **Azure Active Directory** is required for monitoring the application with Microsoft Cloud Application Security.<br><br>**Passthrough** - Users don't have to authenticate against Azure AD to access the application. You can still set up authentication requirements on the backend. |
+ | **Connector Group** | Connectors process the remote access to your application, and connector groups help you organize connectors and apps by region, network, or purpose. If you don't have any connector groups created yet, your app is assigned to **Default**.<br><br>If your application uses WebSockets to connect, all connectors in the group must be version 1.5.612.0 or later. |
+
+6. If necessary, configure **Additional settings**. For most applications, you should keep these settings in their default states.
+
+ | Field | Description |
+ | : | :-- |
+ | **Backend Application Timeout** | Set this value to **Long** only if your application is slow to authenticate and connect. At default, the backend application timeout has a length of 85 seconds. When set to long, the backend timeout is increased to 180 seconds. |
+ | **Use HTTP-Only Cookie** | Set this value to **Yes** to have Application Proxy cookies include the HTTPOnly flag in the HTTP response header. If using Remote Desktop Services, set this value to **No**. |
+ | **Use Secure Cookie**| Set this value to **Yes** to transmit cookies over a secure channel such as an encrypted HTTPS request.
+ | **Use Persistent Cookie**| Keep this value set to **No**. Only use this setting for applications that can't share cookies between processes. For more information about cookie settings, see [Cookie settings for accessing on-premises applications in Azure Active Directory](../manage-apps/application-proxy-configure-cookie-settings.md).
+ | **Translate URLs in Headers** | Keep this value as **Yes** unless your application required the original host header in the authentication request. |
+ | **Translate URLs in Application Body** | Keep this value as **No** unless you have hardcoded HTML links to other on-premises applications and don't use custom domains. For more information, see [Link translation with Application Proxy](../manage-apps/application-proxy-configure-hard-coded-link-translation.md).<br><br>Set this value to **Yes** if you plan to monitor this application with Microsoft Cloud App Security (MCAS). For more information, see [Configure real-time application access monitoring with Microsoft Cloud App Security and Azure Active Directory](../manage-apps/application-proxy-integrate-with-microsoft-cloud-application-security.md). |
+
+7. Select **Add**.
+
+## Test the application
+
+You're ready to test the application is added correctly. In the following steps, you'll add a user account to the application, and try signing in.
+
+### Add a user for testing
+
+Before adding a user to the application, verify the user account already has permissions to access the application from inside the corporate network.
+
+To add a test user:
+
+1. Select **Enterprise applications**, and then select the application you want to test.
+2. Select **Getting started**, and then select **Assign a user for testing**.
+3. Under **Users and groups**, select **Add user**.
+4. Under **Add assignment**, select **Users and groups**. The **User and groups** section appears.
+5. Choose the account you want to add.
+6. Choose **Select**, and then select **Assign**.
+
+### Test the sign-on
+
+To test the sign-on to the application:
+
+1. From the application you want to test, select **Application Proxy**.
+2. At the top of the page, select **Test Application** to run a test on the application and check for any configuration issues.
+3. Make sure to first launch the application to test signing into the application, then download the diagnostic report to review the resolution guidance for any detected issues.
+
+For troubleshooting, see [Troubleshoot Application Proxy problems and error messages](../manage-apps/application-proxy-troubleshoot.md).
+
+## Clean up resources
+
+When no longer needed, delete the resources you created in this tutorial.
+
+## Next steps
+
+In this tutorial, you prepared your on-premises environment to work with Application Proxy, and then installed and registered the Application Proxy connector. Next, you added an application to your Azure AD tenant. You verified that a user can sign on to the application by using an Azure AD account.
+
+You did these things:
+> [!div class="checklist"]
+> * Opened ports for outbound traffic and allowed access to specific URLs
+> * Installed the connector on your Windows server, and registered it with Application Proxy
+> * Verified the connector installed and registered correctly
+> * Added an on-premises application to your Azure AD tenant
+> * Verified a test user can sign on to the application by using an Azure AD account
+
+You're ready to configure the application for single sign-on. Use the following link to choose a single sign-on method and to find single sign-on tutorials.
+
+> [!div class="nextstepaction"]
+> [Configure single sign-on](../manage-apps/sso-options.md#choosing-a-single-sign-on-method)
active-directory Application Proxy Back End Kerberos Constrained Delegation How To https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-back-end-kerberos-constrained-delegation-how-to.md
+
+ Title: Troubleshoot Kerberos constrained delegation - App Proxy
+description: Troubleshoot Kerberos Constrained Delegation configurations for Application Proxy
+++++++ Last updated : 04/27/2021++++
+# Troubleshoot Kerberos constrained delegation configurations for Application Proxy
+
+The methods available for achieving SSO to published applications can vary from one application to another. One option that Azure Active Directory (Azure AD) Application Proxy offers by default is Kerberos constrained delegation (KCD). You can configure a connector, for your users, to run constrained Kerberos authentication to back-end applications.
+
+The procedure for enabling KCD is straightforward. It requires no more than a general understanding of the various components and authentication flow that support SSO. But sometimes, KCD SSO doesnΓÇÖt function as expected. You need good sources of information to troubleshoot these scenarios.
+
+This article provides a single point of reference that helps troubleshoot and self-remediate some of the most common issues. It also covers diagnosis of more complex implementation problems.
+
+This article makes the following assumptions:
+
+- Deployment of Azure AD Application Proxy per [Get started with Application Proxy](application-proxy-add-on-premises-application.md) and general access to non-KCD applications work as expected.
+- The published target application is based on Internet Information Services (IIS) and the Microsoft implementation of Kerberos.
+- The server and application hosts reside in a single Azure Active Directory domain. For detailed information on cross-domain and forest scenarios, see the [KCD white paper](https://aka.ms/KCDPaper).
+- The subject application is published in an Azure tenant with pre-authentication enabled. Users are expected to authenticate to Azure via forms-based authentication. Rich client authentication scenarios aren't covered by this article. They might be added at some point in the future.
+
+## Prerequisites
+
+Azure AD Application Proxy can be deployed into many types of infrastructures or environments. The architectures vary from organization to organization. The most common causes of KCD-related issues aren't the environments. Simple misconfigurations or general mistakes cause most issues.
+
+For this reason, it's best to make sure you've met all the prerequisites in [Using KCD SSO with the Application Proxy](application-proxy-configure-single-sign-on-with-kcd.md) before you start troubleshooting. Note the section on configuring Kerberos constrained delegation on 2012R2. This process employs a different approach to configuring KCD on previous versions of Windows. Also, be mindful of these considerations:
+
+- It's not uncommon for a domain member server to open a secure channel dialog with a specific domain controller (DC). Then the server might move to another dialog at any given time. So connector hosts aren't restricted to communication with only specific local site DCs.
+- Cross-domain scenarios rely on referrals that direct a connector host to DCs that might be outside of the local network perimeter. In these cases, it's equally important to also send traffic onward to DCs that represent other respective domains. If not, delegation fails.
+- Where possible, avoid placing any active IPS or IDS devices between connector hosts and DCs. These devices are sometimes too intrusive and interfere with core RPC traffic.
+
+Test delegation in simple scenarios. The more variables you introduce, the more you might have to contend with. To save time, limit your testing to a single connector. Add additional connectors after the issue has been resolved.
+
+Some environmental factors might also contribute to an issue. To avoid these factors, minimize architecture as much as possible during testing. For example, misconfigured internal firewall ACLs are common. If possible, send all traffic from a connector straight through to the DCs and back-end application.
+
+The best place to position connectors is as close as possible to their targets. A firewall that sits inline when testing adds unnecessary complexity and can prolong your investigations.
+
+What shows a KCD problem? There are several common indications that KCD SSO is failing. The first signs of an issue appear in the browser.
+
+![Screenshot that shows an example of an incorrect K C D configuration error, with the error "Incorrect Kerberos constrained delegation..." highlighted.](./media/application-proxy-back-end-kerberos-constrained-delegation-how-to/graphic1.png)
+
+![Example: Authorization failed because of missing permissions](./media/application-proxy-back-end-kerberos-constrained-delegation-how-to/graphic2.png)
+
+Both of these images show the same symptom: SSO failure. User access to the application is denied.
+
+## Troubleshooting
+
+How you troubleshoot depends on the issue and the symptoms you observe. Before you go any farther, explore the following articles. They provide useful troubleshooting information:
+
+- [Troubleshoot Application Proxy problems and error messages](application-proxy-troubleshoot.md)
+- [Kerberos errors and symptoms](application-proxy-troubleshoot.md#kerberos-errors)
+- [Working with SSO when on-premises and cloud identities aren't identical](application-proxy-configure-single-sign-on-with-kcd.md#working-with-different-on-premises-and-cloud-identities)
+
+If you got to this point, then your main issue exists. To start, separate the flow into the following three stages that you can troubleshoot.
+
+### Client pre-authentication
+
+The external user authenticating to Azure via a browser. The ability to pre-authenticate to Azure is necessary for KCD SSO to function. Test and address this ability if there are any issues. The pre-authentication stage isn't related to KCD or the published application. It's easy to correct any discrepancies by sanity checking that the subject account exists in Azure. Also check that it's not disabled or blocked. The error response in the browser is descriptive enough to explain the cause. If you're uncertain, check other Microsoft troubleshooting articles to verify.
+
+### Delegation service
+
+The Azure Proxy connector that gets a Kerberos service ticket for users from a Kerberos Key Distribution Center (KCD).
+
+The external communications between the client and the Azure front end have no bearing on KCD. These communications only make sure that KCD works. The Azure Proxy service is provided a valid user ID that is used to get a Kerberos ticket. Without this ID, KCD isn't possible and fails.
+
+As mentioned previously, the browser error messages provides some good clues about why things fail. Make sure to note down the activity ID and timestamp in the response. This information helps you correlate the behavior to actual events in the Azure Proxy event log.
+
+![Example: Incorrect KCD configuration error](./media/application-proxy-back-end-kerberos-constrained-delegation-how-to/graphic3.png)
+
+The corresponding entries seen in the event log show as events 13019 or 12027. Find the connector event logs in **Applications and Services Logs** &gt; **Microsoft** &gt; **AadApplicationProxy** &gt; **Connector** &gt; **Admin**.
+
+![Event 13019 from Application Proxy event log](./media/application-proxy-back-end-kerberos-constrained-delegation-how-to/graphic4.png)
+
+![Event 12027 from Application Proxy event log](./media/application-proxy-back-end-kerberos-constrained-delegation-how-to/graphic5.png)
+
+1. Use an **A** record in your internal DNS for the applicationΓÇÖs address, not a **CName**.
+1. Reconfirm that the connector host has been granted the right to delegate to the designated target accountΓÇÖs SPN. Reconfirm that **Use any authentication protocol** is selected. For more information, see the [SSO configuration article](application-proxy-configure-single-sign-on-with-kcd.md).
+1. Verify that there's only one instance of the SPN in existence in Azure AD. Issue `setspn -x` from a command prompt on any domain member host.
+1. Check that a domain policy is enforced that limits the [maximum size of issued Kerberos tokens](/archive/blogs/askds/maxtokensize-and-windows-8-and-windows-server-2012). This policy stops the connector from getting a token if it's found to be excessive.
+
+A network trace that captures the exchanges between the connector host and a domain KDC is the next best step to get more low-level detail on the issues. For more information, see the [deep dive Troubleshoot paper](https://aka.ms/proxytshootpaper).
+
+If ticketing looks good, you see an event in the logs stating that authentication failed because the application returned a 401. This event indicates that the target application rejected your ticket. Go to the next stage.
+
+### Target application
+
+The consumer of the Kerberos ticket provided by the connector. At this stage, expect the connector to have sent a Kerberos service ticket to the back end. This ticket is a header in the first application request.
+
+1. By using the applicationΓÇÖs internal URL defined in the portal, validate that the application is accessible directly from the browser on the connector host. Then you can sign in successfully. Details can be found on the connector **Troubleshoot** page.
+1. Still on the connector host, confirm that the authentication between the browser and the application uses Kerberos. Take one of the following actions:
+1. Run DevTools (**F12**) in Internet Explorer, or use [Fiddler](https://blogs.msdn.microsoft.com/crminthefield/2012/10/10/using-fiddler-to-check-for-kerberos-auth/) from the connector host. Go to the application by using the internal URL. Inspect the offered WWW authorization headers returned in the response from the application to make sure that either negotiate or Kerberos is present.
+
+ - The next Kerberos blob that is returned in the response from the browser to the application starts with **YII**. These letters tell you that Kerberos is running. Microsoft NT LAN Manager (NTLM), on the other hand, always starts with **TlRMTVNTUAAB**, which reads NTLM Security Support Provider (NTLMSSP) when decoded from Base64. If you see **TlRMTVNTUAAB** at the start of the blob, Kerberos is not available. If you donΓÇÖt see **TlRMTVNTUAAB**, Kerberos is likely available.
+
+ > [!NOTE]
+ > If you use Fiddler, this method requires that you temporarily disable extended protection on the applicationΓÇÖs configuration in IIS.
+
+ ![Browser network inspection window](./media/application-proxy-back-end-kerberos-constrained-delegation-how-to/graphic6.png)
+
+ - The blob in this figure doesn't start with **TIRMTVNTUAAB**. So in this example, Kerberos is available, and the Kerberos blob doesnΓÇÖt start with **YII**.
+
+1. Temporarily remove NTLM from the providers list on the IIS site. Access the app directly from Internet Explorer on the connector host. NTLM is no longer in the providers list. You can access the application by using Kerberos only. If access fails, there might be a problem with the applicationΓÇÖs configuration. Kerberos authentication isn't functioning.
+
+ - If Kerberos isn't available, check the applicationΓÇÖs authentication settings in IIS. Make sure **Negotiate** is listed at the top, with NTLM just beneath it. If you see **Not Negotiate**, **Kerberos or Negotiate**, or **PKU2U**, continue only if Kerberos is functional.
+
+ ![Windows authentication providers](./media/application-proxy-back-end-kerberos-constrained-delegation-how-to/graphic7.png)
+
+ - With Kerberos and NTLM in place, temporarily disable pre-authentication for the application in the portal. Try to access it from the internet by using the external URL. You're prompted to authenticate. You're able to do so with the same account used in the previous step. If not, there's a problem with the back-end application, not KCD.
+ - Re-enable pre-authentication in the portal. Authenticate through Azure by attempting to connect to the application via its external URL. If SSO fails, you see a forbidden error message in the browser and event 13022 in the log:
+
+ *Microsoft AAD Application Proxy Connector cannot authenticate the user because the backend server responds to Kerberos authentication attempts with an HTTP 401 error.*
+
+ ![Shows HTTTP 401 forbidden error](./media/application-proxy-back-end-kerberos-constrained-delegation-how-to/graphic8.png)
+
+ - Check the IIS application. Make sure that the configured application pool and the SPN are configured to use the same account in Azure AD. Navigate in IIS as shown in the following illustration:
+
+ ![IIS application configuration window](./media/application-proxy-back-end-kerberos-constrained-delegation-how-to/graphic9.png)
+
+ After you know the identity, make sure this account is configured with the SPN in question. An example is `setspn ΓÇôq http/spn.wacketywack.com`. Enter the following text in a command prompt:
+
+ ![Shows the SetSPN command window](./media/application-proxy-back-end-kerberos-constrained-delegation-how-to/graphic10.png)
+
+ - Check the SPN defined against the applicationΓÇÖs settings in the portal. Make sure that the same SPN configured against the target Azure AD account is used by the applicationΓÇÖs app pool.
+
+ ![SPN configuration in the Azure portal](./media/application-proxy-back-end-kerberos-constrained-delegation-how-to/graphic11.png)
+
+ - Go into IIS and select the **Configuration Editor** option for the application. Navigate to **system.webServer/security/authentication/windowsAuthentication**. Make sure the value **UseAppPoolCredentials** is **True**.
+
+ ![IIS configuration app pools credential option](./media/application-proxy-back-end-kerberos-constrained-delegation-how-to/graphic12.png)
+
+ Change this value to **True**. Remove all cached Kerberos tickets from the back-end server by running the following command:
+
+ ```powershell
+ Get-WmiObject Win32_LogonSession | Where-Object {$_.AuthenticationPackage -ne 'NTLM'} | ForEach-Object {klist.exe purge -li ([Convert]::ToString($_.LogonId, 16))}
+ ```
+
+For more information, see [Purge the Kerberos client ticket cache for all sessions](https://gallery.technet.microsoft.com/scriptcenter/Purge-the-Kerberos-client-b56987bf).
+
+If you leave Kernel mode enabled, it improves the performance of Kerberos operations. But it also causes the ticket for the requested service to be decrypted by using the machine account. This account is also called the Local system. Set this value to **True** to break KCD when the application is hosted across more than one server in a farm.
+
+- As an additional check, disable **Extended** protection too. In some scenarios, **Extended** protection broke KCD when it was enabled in specific configurations. In those cases, an application was published as a subfolder of the default website. This application is configured for anonymous authentication only. All the dialogs are grayed out, which suggests child objects wouldn't inherit any active settings. We recommend that you test, but donΓÇÖt forget to restore this value to **enabled**, where possible.
+
+ This additional check puts you on track to use your published application. You can spin up additional connectors that are also configured to delegate. For more information, read the more in-depth technical walk-through, [Troubleshooting the Azure AD Application Proxy](https://aka.ms/proxytshootpaper).
+
+If you still can't make progress, Microsoft support can assist you. Create a support ticket directly within the portal. An engineer will contact you.
+
+## Other scenarios
+
+- Azure Application Proxy requests a Kerberos ticket before sending its request to an application. Some third-party applications don't like this method of authenticating. These applications expect the more conventional negotiations to take place. The first request is anonymous, which allows the application to respond with the authentication types that it supports through a 401. This type of Kerberos negotiation can be enabled using the steps outlined in this document: [Kerberos Constrained Delegation for single sign-on](application-proxy-configure-single-sign-on-with-kcd.md).
+- Multi-hop authentication is commonly used in scenarios where an application is tiered, with a back end and front end, where both require authentication, such as SQL Server Reporting Services. For more details, see [How to configure Kerberos Constrained Delegation for Web Enrollment proxy pages](/troubleshoot/windows-server/identity/configure-kerberos-constrained-delegation).
+
+## Next steps
+
+[Configure KCD on a managed domain](../../active-directory-domain-services/deploy-kcd.md).
active-directory Application Proxy Config How To https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-config-how-to.md
+
+ Title: How to configure an Azure Active Directory Application Proxy application
+description: Learn how to create and configure an Azure Active Directory Application Proxy application in a few simple steps
+++++++ Last updated : 04/27/2021++++
+# How to configure an Application Proxy application
+
+This article helps you to understand how to configure an Application Proxy application within Azure AD to expose your on-premises applications to the cloud.
+
+## Recommended documents
+
+To learn about the initial configurations and creation of an Application Proxy application through the Admin Portal, follow the [Publish applications using Azure AD Application Proxy](application-proxy-add-on-premises-application.md).
+
+For details on configuring Connectors, see [Enable Application Proxy in the Azure portal](application-proxy-add-on-premises-application.md).
+
+For information on uploading certificates and using custom domains, see [Working with custom domains in Azure AD Application Proxy](application-proxy-configure-custom-domain.md).
+
+## Create the Application/Setting the URLs
+
+If you are following the steps in the [Publish applications using Azure AD Application Proxy](application-proxy-add-on-premises-application.md) documentation and are getting an error creating the application, see the error details for information and suggestions for how to fix the application. Most error messages include a suggested fix. To avoid common errors, verify:
+
+- You are an administrator with permission to create an Application Proxy application
+- The internal URL is unique
+- The external URL is unique
+- The URLs start with http or https, and end with a ΓÇ£/ΓÇ¥
+- The URL should be a domain name, not an IP address
+
+The error message should display in the top-right corner when you create the application. You can also select the notification icon to see the error messages.
+
+![Shows where to find the Notification prompt in the Azure portal](./media/application-proxy-config-how-to/error-message.png)
+
+## Configure connectors/connector groups
+
+If you are having difficulty configuring your application because of warning about the connectors and connector groups, see instructions on enabling Application Proxy for details on how to download connectors. If you want to learn more about connectors, see the [connectors documentation](application-proxy-connectors.md).
+
+If your connectors are inactive, this means that they are unable to reach the service. This is often because all the required ports are not open. To see a list of required ports, see the pre-requisites section of the enabling Application Proxy documentation.
+
+## Upload certificates for custom domains
+
+Custom Domains allow you to specify the domain of your external URLs. To use custom domains, you need to upload the certificate for that domain. For information on using custom domains and certificates, see [Working with custom domains in Azure AD Application Proxy](application-proxy-configure-custom-domain.md).
+
+If you are encountering issues uploading your certificate, look for the error messages in the portal for additional information on the problem with the certificate. Common certificate problems include:
+
+- Expired certificate
+- Certificate is self-signed
+- Certificate is missing the private key
+
+The error message display in the top-right corner as you try to upload the certificate. You can also select the notification icon to see the error messages.
+
+## Next steps
+
+[Publish applications using Azure AD Application Proxy](application-proxy-add-on-premises-application.md)
active-directory Application Proxy Config Problem https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-config-problem.md
+
+ Title: Problem creating an Azure Active Directory Application Proxy application
+description: How to troubleshoot issues creating Application Proxy applications in the Azure Active Directory Admin portal
+++++++ Last updated : 04/27/2021++++
+# Problem creating an Application Proxy application
+
+Below are some of the common issues people face when creating a new application proxy application.
+
+## Recommended documents
+
+To learn more about creating an Application Proxy application through the Admin Portal, see [Publish applications using Azure AD Application Proxy](application-proxy-add-on-premises-application.md).
+
+If you are following the steps in that document and are getting an error creating the application, see the error details for information and suggestions for how to fix the application. Most error messages include a suggested fix.
+
+## Specific things to check
+
+To avoid common errors, verify:
+
+- You are an administrator with permission to create an Application Proxy application
+
+- The internal URL is unique
+
+- The external URL is unique
+
+- The URLs start with http or https, and end with a ΓÇ£/ΓÇ¥
+
+- The URL should be a domain name and not an IP address
+
+The error message should display in the top right corner when you create the application. You can also select the notification icon to see the error messages.
+
+ ![Notification prompt](./media/application-proxy-config-problem/error-message.png)
+
+## Next steps
+[Enable Application Proxy in the Azure portal](application-proxy-add-on-premises-application.md)
active-directory Application Proxy Config Sso How To https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-config-sso-how-to.md
+
+ Title: Understand single sign-on with an on-premises app using Application Proxy
+description: Understand single sign-on with an on-premises app using Application Proxy.
+++++++ Last updated : 04/27/2021++++
+# How to configure single sign-on to an Application Proxy application
+
+Single sign-on (SSO) allows your users to access an application without authenticating multiple times. It allows the single authentication to occur in the cloud, against Azure Active Directory, and allows the service or Connector to impersonate the user to complete any additional authentication challenges from the application.
+
+## How to configure single-sign on
+To configure SSO, first make sure that your application is configured for Pre-Authentication through Azure Active Directory. To do this configuration, go to **Azure Active Directory** -&gt; **Enterprise Applications** -&gt; **All Applications** -&gt; Your application **-&gt; Application Proxy**. On this page, you see the ΓÇ£Pre AuthenticationΓÇ¥ field, and make sure that is set to ΓÇ£Azure Active Directory.
+
+For more information on the Pre-Authentication methods, see step 4 of the [app publishing document](application-proxy-add-on-premises-application.md).
+
+ ![Pre-authentication method in Azure portal](./media/application-proxy-config-sso-how-to/app-proxy.png)
+
+## Configuring single sign-on modes for Application Proxy Applications
+Configure the specific type of single sign-on. The sign-on methods are classified based on what type of authentication the backend application uses. App Proxy applications support three types of sign-on:
+
+- **Password-based Sign-On**: Password-based sign-on can be used for any application that uses username and password fields to sign on. Configuration steps are in [Configure password Single sign-on for an Azure AD gallery application](../manage-apps/configure-password-single-sign-on-non-gallery-applications.md).
+
+- **Integrated Windows Authentication**: For applications using Integrated Windows Authentication (IWA), single sign-on is enabled through Kerberos Constrained Delegation (KCD). This method gives Application Proxy Connectors permission in Active Directory to impersonate users, and to send and receive tokens on their behalf. Details on configuring KCD can be found in the [Single Sign-On with KCD documentation](application-proxy-configure-single-sign-on-with-kcd.md).
+
+- **Header-based Sign-On**: Header-based sign-on is used to provide single sign-on capabilities using HTTP headers. To learn more, see [Header-based single sign-on](application-proxy-configure-single-sign-on-with-headers.md).
+
+- **SAML single sign-on**: With SAML single sign-on, Azure AD authenticates to the application by using the user's Azure AD account. Azure AD communicates the sign-on information to the application through a connection protocol. With SAML-based single sign-on, you can map users to specific application roles based on rules you define in your SAML claims. For information about setting up SAML single sign-on, see [SAML for single sign-on with Application Proxy](application-proxy-configure-single-sign-on-on-premises-apps.md).
+
+Each of these options can be found by going to your application in ΓÇ£Enterprise ApplicationsΓÇ¥, and opening the **Single Sign-On** page on the left menu. Note that if your application was created in the old portal, you may not see all these options.
+
+On this page, you also see one additional Sign-On option: Linked Sign-On. This option is also supported by Application Proxy. However, this option does not add single sign-on to the application. That said the application may already have single sign-on implemented using another service such as Active Directory Federation Services.
+
+This option allows an admin to create a link to an application that users first land on when accessing the application. For example, if there is an application that is configured to authenticate users using Active Directory Federation Services 2.0, an administrator can use the ΓÇ£Linked Sign-OnΓÇ¥ option to create a link to it on My Apps.
+
+## Next steps
+- [Password vaulting for single sign-on with Application Proxy](application-proxy-configure-single-sign-on-password-vaulting.md)
+- [Kerberos Constrained Delegation for single sign-on with Application Proxy](application-proxy-configure-single-sign-on-with-kcd.md)
+- [Header-based authentication for single sign-on with Application Proxy](application-proxy-configure-single-sign-on-with-headers.md)
+- [SAML for single sign-on with Application Proxy](application-proxy-configure-single-sign-on-on-premises-apps.md).
active-directory Application Proxy Configure Connectors With Proxy Servers https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-configure-connectors-with-proxy-servers.md
+
+ Title: Work with existing on-premises proxy servers and Azure Active Directory
+description: Covers how to work with existing on-premises proxy servers with Azure Active Directory.
+++++++ Last updated : 04/27/2021++++
+# Work with existing on-premises proxy servers
+
+This article explains how to configure Azure Active Directory (Azure AD) Application Proxy connectors to work with outbound proxy servers. It is intended for customers with network environments that have existing proxies.
+
+We start by looking at these main deployment scenarios:
+
+* Configure connectors to bypass your on-premises outbound proxies.
+* Configure connectors to use an outbound proxy to access Azure AD Application Proxy.
+* Configure using a proxy between the connector and backend application.
+
+For more information about how connectors work, see [Understand Azure AD Application Proxy connectors](application-proxy-connectors.md).
+
+## Bypass outbound proxies
+
+Connectors have underlying OS components that make outbound requests. These components automatically attempt to locate a proxy server on the network using Web Proxy Auto-Discovery (WPAD).
+
+The OS components attempt to locate a proxy server by carrying out a DNS lookup for wpad.domainsuffix. If the lookup resolves in DNS, an HTTP request is then made to the IP address for wpad.dat. This request becomes the proxy configuration script in your environment. The connector uses this script to select an outbound proxy server. However, connector traffic might still not go through, because of additional configuration settings needed on the proxy.
+
+You can configure the connector to bypass your on-premises proxy to ensure that it uses direct connectivity to the Azure services. We recommend this approach, as long as your network policy allows for it, because it means that you have one less configuration to maintain.
+
+To disable outbound proxy usage for the connector, edit the C:\Program Files\Microsoft AAD App Proxy Connector\ApplicationProxyConnectorService.exe.config file and add the *system.net* section shown in this code sample:
+
+```xml
+<?xml version="1.0" encoding="utf-8" ?>
+<configuration>
+ <system.net>
+ <defaultProxy enabled="false"></defaultProxy>
+ </system.net>
+ <runtime>
+ <gcServer enabled="true"/>
+ </runtime>
+ <appSettings>
+ <add key="TraceFilename" value="AadAppProxyConnector.log" />
+ </appSettings>
+</configuration>
+```
+
+To ensure that the Connector Updater service also bypasses the proxy, make a similar change to the ApplicationProxyConnectorUpdaterService.exe.config file. This file is located at C:\Program Files\Microsoft AAD App Proxy Connector Updater.
+
+Be sure to make copies of the original files, in case you need to revert to the default .config files.
+
+## Use the outbound proxy server
+
+Some environments require all outbound traffic to go through an outbound proxy, without exception. As a result, bypassing the proxy is not an option.
+
+You can configure the connector traffic to go through the outbound proxy, as shown in the following diagram:
+
+ ![Configuring connector traffic to go through an outbound proxy to Azure AD Application Proxy](./media/application-proxy-configure-connectors-with-proxy-servers/configure-proxy-settings.png)
+
+As a result of having only outbound traffic, there's no need to configure inbound access through your firewalls.
+
+> [!NOTE]
+> Application Proxy does not support authentication to other proxies. The connector/updater network service accounts should be able to connect to the proxy without being challenged for authentication.
+
+### Step 1: Configure the connector and related services to go through the outbound proxy
+
+If WPAD is enabled in the environment and configured appropriately, the connector automatically discovers the outbound proxy server and attempt to use it. However, you can explicitly configure the connector to go through an outbound proxy.
+
+To do so, edit the C:\Program Files\Microsoft AAD App Proxy Connector\ApplicationProxyConnectorService.exe.config file, and add the *system.net* section shown in this code sample. Change *proxyserver:8080* to reflect your local proxy server name or IP address, and the port that it's listening on. The value must have the prefix http:// even if you are using an IP address.
+
+```xml
+<?xml version="1.0" encoding="utf-8" ?>
+<configuration>
+ <system.net>
+ <defaultProxy>
+ <proxy proxyaddress="http://proxyserver:8080" bypassonlocal="True" usesystemdefault="True"/>
+ </defaultProxy>
+ </system.net>
+ <runtime>
+ <gcServer enabled="true"/>
+ </runtime>
+ <appSettings>
+ <add key="TraceFilename" value="AadAppProxyConnector.log" />
+ </appSettings>
+</configuration>
+```
+
+Next, configure the Connector Updater service to use the proxy by making a similar change to the C:\Program Files\Microsoft AAD App Proxy Connector Updater\ApplicationProxyConnectorUpdaterService.exe.config file.
+
+> [!NOTE]
+> The Connector service evaluates the **defaultProxy** configuration for usage in `%SystemRoot%\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config`, if the **defaultProxy** is not configured (by default) in ApplicationProxyConnectorService.exe.config. The same applies to the Connector Updater service (ApplicationProxyConnectorUpdaterService.exe.config) too.
+
+### Step 2: Configure the proxy to allow traffic from the connector and related services to flow through
+
+There are four aspects to consider at the outbound proxy:
+
+* Proxy outbound rules
+* Proxy authentication
+* Proxy ports
+* TLS inspection
+
+#### Proxy outbound rules
+
+Allow access to the following URLs:
+
+| URL | Port | How it's used |
+| | | |
+| &ast;.msappproxy.net<br>&ast;.servicebus.windows.net | 443/HTTPS | Communication between the connector and the Application Proxy cloud service |
+| crl3.digicert.com<br>crl4.digicert.com<br>ocsp.digicert.com<br>crl.microsoft.com<br>oneocsp.microsoft.com<br>ocsp.msocsp.com<br> | 80/HTTP | The connector uses these URLs to verify certificates. |
+| login.windows.net<br>secure.aadcdn.microsoftonline-p.com<br>&ast;.microsoftonline.com<br>&ast;.microsoftonline-p.com<br>&ast;.msauth.net<br>&ast;.msauthimages.net<br>&ast;.msecnd.net<br>&ast;.msftauth.net<br>&ast;.msftauthimages.net<br>&ast;.phonefactor.net<br>enterpriseregistration.windows.net<br>management.azure.com<br>policykeyservice.dc.ad.msft.net<br>ctldl.windowsupdate.com | 443/HTTPS | The connector uses these URLs during the registration process. |
+| ctldl.windowsupdate.com | 80/HTTP | The connector uses this URL during the registration process. |
+
+If your firewall or proxy allows you to configure DNS allow lists, you can allow connections to \*.msappproxy.net and \*.servicebus.windows.net.
+
+If you can't allow connectivity by FQDN and need to specify IP ranges instead, use these options:
+
+* Allow the connector outbound access to all destinations.
+* Allow the connector outbound access to all of the Azure datacenter IP ranges. The challenge with using the list of Azure datacenter IP ranges is that it's updated weekly. You need to put a process in place to ensure that your access rules are updated accordingly. Only using a subset of the IP addresses may cause your configuration to break. To download the latest Azure Data Center IP ranges, navigate to [https://download.microsoft.com](https://download.microsoft.com) and search for "Azure IP Ranges and Service Tags". Be sure to select the relevant cloud. For example, the public cloud IP ranges can be found with "Azure IP Ranges and Service Tags ΓÇô Public Cloud". The US Government cloud can be found by searching for "Azure IP Ranges and Service Tags ΓÇô US Government Cloud".
+
+#### Proxy authentication
+
+Proxy authentication is not currently supported. Our current recommendation is to allow the connector anonymous access to the Internet destinations.
+
+#### Proxy ports
+
+The connector makes outbound TLS-based connections by using the CONNECT method. This method essentially sets up a tunnel through the outbound proxy. Configure the proxy server to allow tunneling to ports 443 and 80.
+
+> [!NOTE]
+> When Service Bus runs over HTTPS, it uses port 443. However, by default, Service Bus attempts direct TCP connections and falls back to HTTPS only if direct connectivity fails.
+
+#### TLS inspection
+
+Do not use TLS inspection for the connector traffic, because it causes problems for the connector traffic. The connector uses a certificate to authenticate to the Application Proxy service, and that certificate can be lost during TLS inspection.
+
+## Configure using a proxy between the connector and backend application
+Using a forward proxy for the communication towards the backend application might be a special requirement in some environments.
+To enable this, please follow the next steps:
+
+### Step 1: Add the required registry value to the server
+1. To enable using the default proxy add the following registry value (DWORD)
+`UseDefaultProxyForBackendRequests = 1` to the Connector configuration registry key located in "HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft AAD App Proxy Connector".
+
+### Step 2: Configure the proxy server manually using netsh command
+1. Enable the group policy Make proxy settings per-machine. This is found in: Computer Configuration\Policies\Administrative Templates\Windows Components\Internet Explorer. This needs to be set rather than having this policy set to per-user.
+2. Run `gpupdate /force` on the server or reboot the server to ensure it uses the updated group policy settings.
+3. Launch an elevated command prompt with admin rights and enter `control inetcpl.cpl`.
+4. Configure the required proxy settings.
+
+These settings make the connector use the same forward proxy for the communication to Azure and to the backend application. If the connector to Azure communication requires no forward proxy or a different forward proxy, you can set this up with modifying the file ApplicationProxyConnectorService.exe.config as described in the sections Bypass outbound proxies or Use the outbound proxy server.
+
+> [!NOTE]
+> There are various ways to configure the internet proxy in the operating system. Proxy settings configured via NETSH WINHTTP (run `NETSH WINHTTP SHOW PROXY` to verify) override the proxy settings you configured in Step 2.
+
+The connector updater service will use the machine proxy as well. This behavior can be changed by modifying the file ApplicationProxyConnectorUpdaterService.exe.config.
+
+## Troubleshoot connector proxy problems and service connectivity issues
+
+Now you should see all traffic flowing through the proxy. If you have problems, the following troubleshooting information should help.
+
+The best way to identify and troubleshoot connector connectivity issues is to take a network capture while starting the connector service. Here are some quick tips on capturing and filtering network traces.
+
+You can use the monitoring tool of your choice. For the purposes of this article, we used Microsoft Message Analyzer.
+
+> [!NOTE]
+> [Microsoft Message Analyzer (MMA) was retired](/openspecs/blog/ms-winintbloglp/dd98b93c-0a75-4eb0-b92e-e760c502394f) and its download packages removed from microsoft.com sites on November 25 2019. There is currently no Microsoft replacement for Microsoft Message Analyzer in development at this time. For similar functionality, please consider using a 3rd party network protocol analyzer tool such as Wireshark.
+
+The following examples are specific to Message Analyzer, but the principles can be applied to any analysis tool.
+
+### Take a capture of connector traffic
+
+For initial troubleshooting, perform the following steps:
+
+1. From services.msc, stop the Azure AD Application Proxy Connector service.
+
+ ![Azure AD Application Proxy Connector service in services.msc](./media/application-proxy-configure-connectors-with-proxy-servers/services-local.png)
+
+1. Run Message Analyzer as an administrator.
+1. Select **Start local trace**.
+1. Start the Azure AD Application Proxy Connector service.
+1. Stop the network capture.
+
+ ![Screenshot shows the Stop network capture button](./media/application-proxy-configure-connectors-with-proxy-servers/stop-trace.png)
+
+### Check if the connector traffic bypasses outbound proxies
+
+If you configured your Application Proxy connector to bypass the proxy servers and connect directly to the Application Proxy service, you want to look in the network capture for failed TCP connection attempts.
+
+Use the Message Analyzer filter to identify these attempts. Enter `property.TCPSynRetransmit` in the filter box and select **Apply**.
+
+A SYN packet is the first packet sent to establish a TCP connection. If this packet doesnΓÇÖt return a response, the SYN is reattempted. You can use the preceding filter to see any retransmitted SYNs. Then, you can check whether these SYNs correspond to any connector-related traffic.
+
+If you expect the connector to make direct connections to the Azure services, SynRetransmit responses on port 443 are an indication that you have a network or firewall problem.
+
+### Check if the connector traffic uses outbound proxies
+
+If you configured your Application Proxy connector traffic to go through the proxy servers, you want to look for failed https connections to your proxy.
+
+To filter the network capture for these connection attempts, enter `(https.Request or https.Response) and tcp.port==8080` in the Message Analyzer filter, replacing 8080 with your proxy service port. Select **Apply** to see the filter results.
+
+The preceding filter shows just the HTTPs requests and responses to/from the proxy port. You're looking for the CONNECT requests that show communication with the proxy server. Upon success, you get an HTTP OK (200) response.
+
+If you see other response codes, such as 407 or 502, that means that the proxy is requiring authentication or not allowing the traffic for some other reason. At this point, you engage your proxy server support team.
+
+## Next steps
+
+* [Understand Azure AD Application Proxy connectors](application-proxy-connectors.md)
+* If you have problems with connector connectivity issues, ask your question in the [Microsoft Q&A question page for Azure Active Directory](/answers/topics/azure-active-directory.html) or create a ticket with our support team.
active-directory Application Proxy Configure Custom Domain https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-configure-custom-domain.md
+
+ Title: Custom domains in Azure Active Directory Application Proxy
+description: Configure and manage custom domains in Azure Active Directory Application Proxy.
+++++++ Last updated : 10/24/2019++++
+# Configure custom domains with Azure AD Application Proxy
+
+When you publish an application through Azure Active Directory Application Proxy, you create an external URL for your users. This URL gets the default domain *yourtenant.msappproxy.net*. For example, if you publish an app named *Expenses* in your tenant named *Contoso*, the external URL is *https:\//expenses-contoso.msappproxy.net*. If you want to use your own domain name instead of *msappproxy.net*, you can configure a custom domain for your application.
+
+## Benefits of custom domains
+
+It's a good idea to set up custom domains for your apps whenever possible. Some reasons to use custom domains include:
+
+- Links between apps work even outside the corporate network. Without a custom domain, if your app has hard-coded internal links to targets outside the Application Proxy, and the links aren't externally resolvable, they will break. When your internal and external URLs are the same, you avoid this problem. If you're not able to use custom domains, see [Redirect hardcoded links for apps published with Azure AD Application Proxy](./application-proxy-configure-hard-coded-link-translation.md) for other ways to address this issue.
+
+- Your users will have an easier experience, because they can get to the app with the same URL from inside or outside your network. They donΓÇÖt need to learn different internal and external URLs, or track their current location.
+
+- You can control your branding and create the URLs you want. A custom domain can help build your users' confidence, because users see and use a familiar name instead of *msappproxy.net*.
+
+- Some configurations will only work with custom domains. For example, you need custom domains for apps that use Security Assertion Markup Language (SAML), such as when youΓÇÖre using Active Directory Federation Services (AD FS) but are unable to use WS-Federation. For more information, see [Work with claims-aware apps in Application Proxy](application-proxy-configure-for-claims-aware-applications.md).
+
+If you're not able to make the internal and external URLs match, it's not as important to use custom domains, but you can still take advantage of the other benefits.
+
+## DNS configuration options
+
+There are several options for setting up your DNS configuration, depending on your requirements:
+
+### Same internal and external URL, different internal and external behavior
+
+If you don't want your internal users to be directed through the Application Proxy, you can set up a *split-brain DNS*. A split DNS infrastructure directs internal hosts to an internal domain name server, and external hosts to an external domain name server, for name resolution.
+
+![Split-brain DNS](./media/application-proxy-configure-custom-domain/split-brain-dns.png)
+
+### Different internal and external URLs
+
+If the internal and external URLs are different, you don't need to configure split-brain behavior, because user routing is determined by the URL. In this case, you change only the external DNS, and route the external URL to the Application Proxy endpoint.
+
+When you select a custom domain for an external URL, an information bar shows the CNAME entry you need to add to the external DNS provider. You can always see this information by going to the app's **Application proxy** page.
+
+## Set up and use custom domains
+
+To configure an on-premises app to use a custom domain, you need a verified Azure Active Directory custom domain, a PFX certificate for the custom domain, and an on-premises app to configure.
+
+### Create and verify a custom domain
+
+To create and verify a custom domain:
+
+1. In Azure Active Directory, select **Custom domain names** in the left navigation, and then select **Add custom domain**.
+1. Enter your custom domain name and select **Add Domain**.
+1. On the domain page, copy the TXT record information for your domain.
+1. Go to your domain registrar and create a new TXT record for your domain, based on your copied DNS information.
+1. After you register the domain, on the domain's page in Azure Active Directory, select **Verify**. Once the domain status is **Verified**, you can use the domain across all your Azure AD configurations, including Application Proxy.
+
+For more detailed instructions, see [Add your custom domain name using the Azure Active Directory portal](../fundamentals/add-custom-domain.md).
+
+### Configure an app to use a custom domain
+
+To publish your app through Application Proxy with a custom domain:
+
+1. For a new app, in Azure Active Directory, select **Enterprise applications** in the left navigation. Select **New application**. In the **On-premises applications** section, select **Add an on-premises application**.
+
+ For an app already in **Enterprise applications**, select it from the list, and then select **Application proxy** in the left navigation.
+
+2. On the Application Proxy settings page, enter a **Name** if you're adding your own on-premises application.
+
+3. In the **Internal Url** field, enter the internal URL for your app.
+
+4. In the **External Url** field, drop down the list and select the custom domain you want to use.
+
+5. Select **Add**.
+
+ ![Select custom domain](./media/application-proxy-configure-custom-domain/application-proxy.png)
+
+6. If the domain already has a certificate, the **Certificate** field displays the certificate information. Otherwise, select the **Certificate** field.
+
+ ![Click to upload a certificate](./media/application-proxy-configure-custom-domain/certificate.png)
+
+7. On the **SSL certificate** page, browse to and select your PFX certificate file. Enter the password for the certificate, and select **Upload Certificate**. For more information about certificates, see the [Certificates for custom domains](#certificates-for-custom-domains) section. If the certificate is not valid or there is a problem with the password you will see an error message. The [Application Proxy FAQ](application-proxy-faq.yml#application-configuration) contains some troubleshooting steps you can try.
+
+ ![Upload Certificate](./media/application-proxy-configure-custom-domain/ssl-certificate.png)
+
+ > [!TIP]
+ > A custom domain only needs its certificate uploaded once. After that, the uploaded certificate is applied automatically when you use the custom domain for other apps.
+
+8. If you added a certificate, on the **Application proxy** page, select **Save**.
+
+9. In the information bar on the **Application proxy** page, note the CNAME entry you need to add to your DNS zone.
+
+ ![Add CNAME DNS entry](./media/application-proxy-configure-custom-domain/dns-info.png)
+
+10. Follow the instructions at [Manage DNS records and record sets by using the Azure portal](../../dns/dns-operations-recordsets-portal.md) to add a DNS record that redirects the new external URL to the *msappproxy.net* domain.
+
+11. To check that the DNS record is configured correctly, use the [nslookup](https://social.technet.microsoft.com/wiki/contents/articles/29184.nslookup-for-beginners.aspx) command to confirm that your external URL is reachable and the *msapproxy.net* domain appears as an alias.
+
+Your application is now set up to use the custom domain. Be sure to assign users to your application before you test or release it.
+
+To change the domain for an app, select a different domain from the dropdown list in **External URL** on the app's **Application proxy** page. Upload a certificate for the updated domain, if necessary, and update the DNS record. If you don't see the custom domain you want in the dropdown list in **External URL**, it might not be verified.
+
+For more detailed instructions for Application Proxy, see [Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory](application-proxy-add-on-premises-application.md).
+
+## Certificates for custom domains
+
+A certificate creates the secure TLS connection for your custom domain.
+
+### Certificate formats
+
+You must use a PFX certificate, to ensure all required intermediate certificates are included. The certificate must include the private key.
+
+Most common certificate signature methods are supported such as Subject Alternative Name (SAN).
+
+You can use wildcard certificates as long as the wildcard matches the external URL. You must use wildcard certificates for [wildcard applications](application-proxy-wildcard.md). If you want to use the certificate to also access subdomains, you must add the subdomain wildcards as subject alternative names in the same certificate. For example, a certificate for *\*.adventure-works.com* won't work for *\*.apps.adventure-works.com* unless you add *\*.apps.adventure-works.com* as a subject alternative name.
+
+You can use certificates issued by your own public key infrastructure (PKI) if the certificate chain is installed on your client devices. Intune can deploy these certificates to managed devices. For non-managed devices, you must manually install these certificates.
+
+We do not recommend using a private root CA since the private root CA would also need to be pushed to client machines, which may introduce many challenges.
+
+### Certificate management
+
+All certificate management is through the individual application pages. Go to the application's **Application proxy** page to access the **Certificate** field.
+
+Once a certificate is uploaded for an application it will also be automatically applied to **new** apps configured that use the same certificate. You will need to re-upload the certificate for existing apps in your tenant.
+
+When a certificate expires, you get a warning telling you to upload another certificate. If the certificate is revoked, your users may see a security warning when accessing the app. To update the certificate for an app, navigate to the **Application proxy** page for the app, select **Certificate**, and upload a new certificate. If the old certificate isn't being used by other apps, it's deleted automatically.
+
+## Next steps
+
+* [Enable single sign-on](application-proxy-configure-single-sign-on-with-kcd.md) to your published apps with Azure AD authentication.
+* [Conditional Access](../conditional-access/concept-conditional-access-cloud-apps.md) for your published cloud apps.
active-directory Application Proxy Configure Custom Home Page https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-configure-custom-home-page.md
+
+ Title: Custom home page for published apps - Azure Active Directory Application Proxy
+description: Covers the basics about Azure Active Directory Application Proxy connectors
+++++++ Last updated : 04/27/2021+++
+# Set a custom home page for published apps by using Azure Active Directory Application Proxy
+
+This article discusses how to configure an app to direct a user to a custom home page. When you publish an app with Application Proxy, you set an internal URL, but sometimes that's not the page a user should see first. Set a custom home page so that a user gets the right page when they access the app. A user will see the custom home page that you set, regardless of whether they access the app from the Azure Active Directory My Apps or the Microsoft 365 app launcher.
+
+When a user launches the app, they're directed by default to the root domain URL for the published app. The landing page is typically set as the home page URL. Use the Azure AD PowerShell module to define a custom home page URL when you want an app user to land on a specific page within the app.
+
+Here's one scenario that explains why your company would set a custom home page:
+
+- Inside your corporate network, a user goes to `https://ExpenseApp/login/login.aspx` to sign in and access your app.
+- Because you have other assets (such as images) that Application Proxy needs to access at the top level of the folder structure, you publish the app with `https://ExpenseApp` as the internal URL.
+- The default external URL is `https://ExpenseApp-contoso.msappproxy.net`, which doesn't take an external user to the sign-in page.
+- You want to set `https://ExpenseApp-contoso.msappproxy.net/login/login.aspx` as the home page URL instead, so an external user sees the sign-in page first.
+
+> [!NOTE]
+> When you give users access to published apps, the apps are displayed in [My Apps](../user-help/my-apps-portal-end-user-access.md) and the [Office 365 app launcher](https://www.microsoft.com/microsoft-365/blog/2016/09/27/introducing-the-new-office-365-app-launcher/).
+
+## Before you start
+
+Before you set the home page URL, keep in mind the following requirements:
+
+- The path that you specify must be a subdomain path of the root domain URL.
+
+ For example, if the root-domain URL is `https://apps.contoso.com/app1/`, the home page URL that you configure must start with `https://apps.contoso.com/app1/`.
+
+- If you make a change to the published app, the change might reset the value of the home page URL. When you update the app in the future, you should recheck and, if necessary, update the home page URL.
+
+You can set the home page URL either through the Azure portal or by using PowerShell.
+
+## Change the home page in the Azure portal
+
+To change the home page URL of your app through the Azure AD portal, follow these steps:
+
+1. Sign in to the [Azure portal](https://portal.azure.com/) as an administrator.
+1. Select **Azure Active Directory**, and then **App registrations**. The list of registered apps appears.
+1. Choose your app from the list. A page showing the details of the registered app appears.
+1. Under **Manage**, select **Branding**.
+1. Update the **Home page URL** with your new path.
+
+ ![Branding page for a registered app showing the Home Page URL field](media/application-proxy-configure-custom-home-page/app-proxy-app-branding.png)
+
+1. Select **Save**.
+
+## Change the home page with PowerShell
+
+To configure the home page of an app using PowerShell, you need to:
+
+1. Install the Azure AD PowerShell module.
+1. Find the ObjectId value of the app.
+1. Update the app's home page URL using PowerShell commands.
+
+### Install the Azure AD PowerShell module
+
+Before you define a custom home page URL by using PowerShell, install the Azure AD PowerShell module. You can download the package from the [PowerShell Gallery](https://www.powershellgallery.com/packages/AzureAD/2.0.2.16), which uses the Graph API endpoint.
+
+To install the package, follow these steps:
+
+1. Open a standard PowerShell window, and then run the following command:
+
+ ```powershell
+ Install-Module -Name AzureAD
+ ```
+
+ If you're running the command as a non-admin, use the `-scope currentuser` option.
+
+1. During the installation, select **Y** to install two packages from Nuget.org. Both packages are required.
+
+### Find the ObjectId of the app
+
+You get the ObjectId of the app by searching for the app by its display name or home page.
+
+1. In the same PowerShell window, import the Azure AD module.
+
+ ```powershell
+ Import-Module AzureAD
+ ```
+
+1. Sign in to the Azure AD module as the tenant administrator.
+
+ ```powershell
+ Connect-AzureAD
+ ```
+
+1. Find the app. This example uses PowerShell to find the ObjectId by searching for the app with a display name of `SharePoint`.
+
+ ```powershell
+ Get-AzureADApplication | Where-Object { $_.DisplayName -eq "SharePoint" } | Format-List DisplayName, Homepage, ObjectId
+ ```
+
+ You should get a result that's similar to the one shown here. Copy the ObjectId GUID to use in the next section.
+
+ ```console
+ DisplayName : SharePoint
+ Homepage    : https://sharepoint-iddemo.msappproxy.net/
+ ObjectId    : 8af89bfa-eac6-40b0-8a13-c2c4e3ee22a4
+ ```
+
+ Alternatively, you could just pull the list of all apps, search the list for the app with a specific display name or home page, and copy the app's ObjectId once the app is found.
+
+ ```powershell
+ Get-AzureADApplication | Format-List DisplayName, Homepage, ObjectId
+ ```
+
+### Update the home page URL
+
+Create the home page URL, and update your app with that value. Continue using the same PowerShell window, or if you're using a new PowerShell window, sign in to the Azure AD module again using `Connect-AzureAD`. Then follow these steps:
+
+1. Create a variable to hold the ObjectId value you copied in the previous section. (Replace the ObjectId value used for in this SharePoint example with your app's ObjectId value.)
+
+ ```powershell
+ $objguid = "8af89bfa-eac6-40b0-8a13-c2c4e3ee22a4"
+ ```
+
+1. Confirm that you have the correct app by running the following command. The output should be identical to the output you saw in the previous section ([Find the ObjectId of the app](#find-the-objectid-of-the-app)).
+
+ ```powershell
+ Get-AzureADApplication -ObjectId $objguid | Format-List DisplayName, Homepage, ObjectId
+ ```
+
+1. Create a blank application object to hold the changes that you want to make.
+
+ ```powershell
+ $appnew = New-Object "Microsoft.Open.AzureAD.Model.Application"
+ ```
+
+1. Set the home page URL to the value that you want. The value must be a subdomain path of the published app. For example, if you change the home page URL from `https://sharepoint-iddemo.msappproxy.net/` to `https://sharepoint-iddemo.msappproxy.net/hybrid/`, app users go directly to the custom home page.
+
+ ```powershell
+ $homepage = "https://sharepoint-iddemo.msappproxy.net/hybrid/"
+ ```
+
+1. Make the update of the home page.
+
+ ```powershell
+ Set-AzureADApplication -ObjectId $objguid -Homepage $homepage
+ ```
+
+1. To confirm that the change was successful, run the following command from step 2 again.
+
+ ```powershell
+ Get-AzureADApplication -ObjectId $objguid | Format-List DisplayName, Homepage, ObjectId
+ ```
+
+ For our example, the output should now appear as follows:
+
+ ```console
+ DisplayName : SharePoint
+ Homepage    : https://sharepoint-iddemo.msappproxy.net/hybrid/
+ ObjectId    : 8af89bfa-eac6-40b0-8a13-c2c4e3ee22a4
+ ```
+
+1. Restart the app to confirm that the home page appears as the first screen, as expected.
+
+> [!NOTE]
+> Any changes that you make to the app might reset the home page URL. If your home page URL resets, repeat the steps in this section to set it back.
+
+## Next steps
+
+- [Enable remote access to SharePoint with Azure AD Application Proxy](../manage-apps/application-proxy-integrate-with-sharepoint-server.md)
+- [Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory](application-proxy-add-on-premises-application.md)
active-directory Application Proxy Configure For Claims Aware Applications https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-configure-for-claims-aware-applications.md
+
+ Title: Claims-aware apps - Azure Active Directory Application Proxy
+description: How to publish on-premises ASP.NET applications that accept AD FS claims for secure remote access by your users.
+++++++ Last updated : 04/27/2021++++
+# Working with claims-aware apps in Application Proxy
+[Claims-aware apps](/previous-versions/windows/desktop/legacy/bb736227(v=vs.85)) perform a redirection to the Security Token Service (STS). The STS requests credentials from the user in exchange for a token and then redirects the user to the application. There are a few ways to enable Application Proxy to work with these redirects. Use this article to configure your deployment for claims-aware apps.
+
+## Prerequisites
+Make sure that the STS that the claims-aware app redirects to is available outside of your on-premises network. You can make the STS available by exposing it through a proxy or by allowing outside connections.
+
+## Publish your application
+
+1. Publish your application according to the instructions described in [Publish applications with Application Proxy](../app-proxy/application-proxy-add-on-premises-application.md).
+2. Navigate to the application page in the portal and select **Single sign-on**.
+3. If you chose **Azure Active Directory** as your **Preauthentication Method**, select **Azure AD single sign-on disabled** as your **Internal Authentication Method**. If you chose **Passthrough** as your **Preauthentication Method**, you don't need to change anything.
+
+## Configure ADFS
+
+You can configure ADFS for claims-aware apps in one of two ways. The first is by using custom domains. The second is with WS-Federation.
+
+### Option 1: Custom domains
+
+If all the internal URLs for your applications are fully qualified domain names (FQDNs), then you can configure [custom domains](application-proxy-configure-custom-domain.md) for your applications. Use the custom domains to create external URLs that are the same as the internal URLs. When your external URLs match your internal URLs, then the STS redirections work whether your users are on-premises or remote.
+
+### Option 2: WS-Federation
+
+1. Open ADFS Management.
+2. Go to **Relying Party Trusts**, right-click on the app you are publishing with Application Proxy, and choose **Properties**.
+
+ ![Relying Party Trusts right-click on app name - screenshot](./media/application-proxy-configure-for-claims-aware-applications/appproxyrelyingpartytrust.png)
+
+3. On the **Endpoints** tab, under **Endpoint type**, select **WS-Federation**.
+4. Under **Trusted URL**, enter the URL you entered in the Application Proxy under **External URL** and click **OK**.
+
+ ![Add an Endpoint - set Trusted URL value - screenshot](./media/application-proxy-configure-for-claims-aware-applications/appproxyendpointtrustedurl.png)
+
+## Next steps
+* [Enable native client apps to interact with proxy applications](application-proxy-configure-native-client-application.md)
active-directory Application Proxy Configure Hard Coded Link Translation https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-configure-hard-coded-link-translation.md
+
+ Title: Translate links and URLs Azure Active Directory Application Proxy
+description: Learn how to redirect hard-coded links for apps published with Azure Active Directory Application Proxy.
+++++++ Last updated : 04/27/2021++++
+# Redirect hard-coded links for apps published with Azure Active Directory Application Proxy
+
+Azure AD Application Proxy makes your on-premises apps available to users who are remote or on their own devices. Some apps, however, were developed with local links embedded in the HTML. These links don't work correctly when the app is used remotely. When you have several on-premises applications point to each other, your users expect the links to keep working when they're not at the office.
+
+The best way to make sure that links work the same both inside and outside of your corporate network is to configure the external URLs of your apps to be the same as their internal URLs. Use [custom domains](application-proxy-configure-custom-domain.md) to configure your external URLs to have your corporate domain name instead of the default application proxy domain.
++
+If you can't use custom domains in your tenant, there are several other options for providing this functionality. All of these are also compatible with custom domains and each other, so you can configure custom domains and other solutions if needed.
+
+> [!NOTE]
+> Link translation is not supported for hard-coded internal URLs generated through JavaScript.
+
+**Option 1: Use Microsoft Edge** ΓÇô This solution is only applicable if you plan to recommend or require that users access the application through the Microsoft Edge browser. It will handle all published URLs.
+
+**Option 2: Use the MyApps Extension** ΓÇô This solution requires users to install a client-side browser extension, but it will handle all published URLs and works with most popular browsers.
+
+**Option 3: Use the link translation setting** ΓÇô This is an admin side setting that is invisible to users. However, it will handle URLs only in HTML and CSS.
+
+These three features keep your links working no matter where your users are. When you have apps that point directly to internal endpoints or ports, you can map these internal URLs to the published external Application Proxy URLs.
+
+
+> [!NOTE]
+> The last option is only for tenants that, for whatever reason, can't use custom domains to have the same internal and external URLs for their apps. Before you enable this feature, see if [custom domains in Azure AD Application Proxy](application-proxy-configure-custom-domain.md) can work for you.
+>
+> Or, if the application you need to configure with link translation is SharePoint, see [Configure alternate access mappings for SharePoint 2013](/SharePoint/administration/configure-alternate-access-mappings) for another approach to mapping links.
+
+
+### Option 1: Microsoft Edge Integration
+
+You can use Microsoft Edge to further protect your application and content. To use this solution, you need to require/recommend users access the application through Microsoft Edge. All internal URLs published with Application Proxy will be recognized by Edge and redirected to the corresponding external URL. This ensures that all the hard-coded internal URLs work, and if a user goes to the browser and directly types the internal URL, it works even if the user is remote.
+
+To learn more, including how to configure this option, please see the [Manage web access by using Edge for iOS and Android with Microsoft Intune](/mem/intune/apps/manage-microsoft-edge) documentation.
+
+### Option 2: MyApps Browser Extension
+
+With the MyApps Browser Extension, all internal URLs published with Application Proxy are recognized by the extension and redirected to the corresponding external URL. This ensures that all the hard-coded internal URLs work, and if a user goes to the browser's address bar and directly types the internal URL, it works even if the user is remote.
+
+To use this feature, the user needs to download the extension and be logged in. There is no other configuration needed for admins or the users.
+
+To learn more, including how to configure this option, please see the [MyApps Browser Extension](../user-help/my-apps-portal-end-user-access.md#download-and-install-the-my-apps-secure-sign-in-extension) documentation.
+
+> [!NOTE]
+> The MyApps Browser Extension does not support link translation for wildcard URLs.
+
+### Option 3: Link Translation Setting
+
+When link translation is enabled, the Application Proxy service searches through HTML and CSS for published internal links and translates them so that your users get an uninterrupted experience. Using the MyApps Browser Extension is preferred to the Link Translation Setting since it gives a more performant experience to users.
+
+> [!NOTE]
+> If you are using option 2 or 3, only one of these should be enabled at a time.
+
+## How link translation works
+
+After authentication, when the proxy server passes the application data to the user, Application Proxy scans the application for hard-coded links and replaces them with their respective, published external URLs.
+
+Application Proxy assumes that applications are encoded in UTF-8. If that's not the case, specify the encoding type in an HTTP response header, like `Content-Type:text/html;charset=utf-8`.
+
+### Which links are affected?
+
+The link translation feature only looks for links that are in code tags in the body of an app. Application Proxy has a separate feature for translating cookies or URLs in headers.
+
+There are two common types of internal links in on-premises applications:
+
+- **Relative internal links** that point to a shared resource in a local file structure like `/claims/claims.html`. These links automatically work in apps that are published through Application Proxy, and continue to work with or without link translation.
+- **Hard-coded internal links** to other on-premises apps like `http://expenses` or published files like `http://expenses/logo.jpg`. The link translation feature works on hard-coded internal links, and changes them to point to the external URLs that remote users need to go through.
+
+The complete list of attributes in HTML code tags that Application Proxy supports link translation for include:
+* a (href)
+* audio (src)
+* base (href)
+* button (formaction)
+* div (data-background, style, data-src)
+* embed (src)
+* form (action)
+* frame (src)
+* head (profile)
+* html (manifest)
+* iframe (longdesc, src)
+* img (longdesc, src)
+* input (formaction, src, value)
+* link (href)
+* menuitem (icon)
+* meta (content)
+* object (archive, data, codebase)
+* script (src)
+* source (src)
+* track (src)
+* video (src, poster)
+
+Additionally, within CSS the URL attribute is also translated.
+
+### How do apps link to each other?
+
+Link translation is enabled for each application, so that you have control over the user experience at the per-app level. Turn on link translation for an app when you want the links *from* that app to be translated, not links *to* that app.
+
+For example, suppose that you have three applications published through Application Proxy that all link to each other: Benefits, Expenses, and Travel. There's a fourth app, Feedback, that isn't published through Application Proxy.
+
+When you enable link translation for the Benefits app, the links to Expenses and Travel are redirected to the external URLs for those apps, but the link to Feedback is not redirected because there is no external URL. Links from Expenses and Travel back to Benefits don't work, because link translation has not been enabled for those two apps.
+
+![Links from Benefits to other apps when link translation is enabled](./media/application-proxy-configure-hard-coded-link-translation/one_app.png)
+
+### Which links aren't translated?
+
+To improve performance and security, some links aren't translated:
+
+- Links not inside of code tags.
+- Links not in HTML or CSS.
+- Links in URL-encoded format.
+- Internal links opened from other programs. Links sent through email or instant message, or included in other documents, won't be translated. The users need to know to go to the external URL.
+
+If you need to support one of these two scenarios, use the same internal and external URLs instead of link translation.
+
+## Enable link translation
+
+Getting started with link translation is as easy as clicking a button:
+
+1. Sign in to the [Azure portal](https://portal.azure.com) as an administrator.
+2. Go to **Azure Active Directory** > **Enterprise applications** > **All applications** > select the app you want to manage > **Application proxy**.
+3. Turn **Translate URLs in application body** to **Yes**.
+
+ ![Select Yes to translate URLs in application body](./media/application-proxy-configure-hard-coded-link-translation/select_yes.png)
+4. Select **Save** to apply your changes.
+
+Now, when your users access this application, the proxy will automatically scan for internal URLs that have been published through Application Proxy on your tenant.
+
+## Send feedback
+
+We want your help to make this feature work for all your apps. We search over 30 tags in HTML and CSS. If you have an example of generated links that aren't being translated, send a code snippet to [Application Proxy Feedback](mailto:aadapfeedback@microsoft.com).
+
+## Next steps
+[Use custom domains with Azure AD Application Proxy](application-proxy-configure-custom-domain.md) to have the same internal and external URL
+
+[Configure alternate access mappings for SharePoint 2013](/SharePoint/administration/configure-alternate-access-mappings)
active-directory Application Proxy Configure Native Client Application https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-configure-native-client-application.md
+
+ Title: Publish native client apps - Azure Active Directory
+description: Covers how to enable native client apps to communicate with Azure Active Directory Application Proxy Connector to provide secure remote access to your on-premises apps.
+++++++ Last updated : 04/27/2021++++
+# How to enable native client applications to interact with proxy applications
+
+You can use Azure Active Directory (Azure AD) Application Proxy to publish web apps, but it also can be used to publish native client applications that are configured with the Microsoft Authentication Library (MSAL). Native client applications differ from web apps because they're installed on a device, while web apps are accessed through a browser.
+
+To support native client applications, Application Proxy accepts Azure AD-issued tokens that are sent in the header. The Application Proxy service does the authentication for the users. This solution doesn't use application tokens for authentication.
+
+![Relationship between end users, Azure AD, and published applications](./media/application-proxy-configure-native-client-application/richclientflow.png)
+
+To publish native applications, use the Microsoft Authentication Library, which takes care of authentication and supports many client environments. Application Proxy fits into the [Desktop app that calls a web API on behalf of a signed-in user](../develop/authentication-flows-app-scenarios.md#desktop-app-that-calls-a-web-api-on-behalf-of-a-signed-in-user) scenario.
+
+This article walks you through the four steps to publish a native application with Application Proxy and the Azure AD Authentication Library.
+
+## Step 1: Publish your proxy application
+
+Publish your proxy application as you would any other application and assign users to access your application. For more information, see [Publish applications with Application Proxy](../app-proxy/application-proxy-add-on-premises-application.md).
+
+## Step 2: Register your native application
+
+You now need to register your application in Azure AD, as follows:
+
+1. Sign in to the [Azure Active Directory portal](https://aad.portal.azure.com/). The **Dashboard** for the **Azure Active Directory admin center** appears.
+1. In the sidebar, select **Azure Active Directory**. The **Azure Active Directory** overview page appears.
+1. In the Azure AD overview sidebar, select **App registrations**. The list of all app registrations appears.
+1. Select **New registration**. The **Register an application** page appears.
+
+ ![Create a new app registration in the Azure portal](./media/application-proxy-configure-native-client-application/create.png)
+
+1. In the **Name** heading, specify a user-facing display name for your application.
+1. Under the **Supported account types** heading, select an access level using these guidelines:
+
+ - To target only accounts that are internal to your organization, select **Accounts in this organizational directory only**.
+ - To target only business or educational customers, select **Accounts in any organizational directory**.
+ - To target the widest set of Microsoft identities, select **Accounts in any organizational directory and personal Microsoft accounts**.
+1. Under **Redirect URI**, select **Public client (mobile & desktop)**, and then type the redirect URI `https://login.microsoftonline.com/common/oauth2/nativeclient` for your application.
+1. Select and read the **Microsoft Platform Policies**, and then select **Register**. An overview page for the new application registration is created and displayed.
+
+For more detailed information about creating a new application registration, see [Integrating applications with Azure Active Directory](../develop/quickstart-register-app.md).
+
+## Step 3: Grant access to your proxy application
+
+Now that you've registered your native application, you can give it access to other applications in your directory, in this case to access the proxy application. To enable the native application to be exposed to the proxy application:
+
+1. In the sidebar of the new application registration page, select **API permissions**. The **API permissions** page for the new application registration appears.
+1. Select **Add a permission**. The **Request API permissions** page appears.
+1. Under the **Select an API** setting, select **APIs my organization uses**. A list appears, containing the applications in your directory that expose APIs.
+1. Type in the search box or scroll to find the proxy application that you published in [Step 1: Publish your proxy application](#step-1-publish-your-proxy-application), and then select the proxy application.
+1. In the **What type of permissions does your application require?** heading, select the permission type. If your native application needs to access the proxy application API as the signed-in user, choose **Delegated permissions**.
+1. In the **Select permissions** heading, select the desired permission, and select **Add permissions**. The **API permissions** page for your native application now shows the proxy application and permission API that you added.
+
+## Step 4: Add the Microsoft Authentication Library to your code (.NET C# sample)
+
+Edit the native application code in the authentication context of the Microsoft Authentication Library (MSAL) to include the following text:
+
+```
+// Acquire Access Token from AAD for Proxy Application
+IPublicClientApplication clientApp = PublicClientApplicationBuilder
+.Create(<App ID of the Native app>)
+.WithDefaultRedirectUri() // will automatically use the default Uri for native app
+.WithAuthority("https://login.microsoftonline.com/{<Tenant ID>}")
+.Build();
+
+AuthenticationResult authResult = null;
+var accounts = await clientApp.GetAccountsAsync();
+IAccount account = accounts.FirstOrDefault();
+
+IEnumerable<string> scopes = new string[] {"<Scope>"};
+
+try
+ {
+ authResult = await clientApp.AcquireTokenSilent(scopes, account).ExecuteAsync();
+ }
+ catch (MsalUiRequiredException ex)
+ {
+ authResult = await clientApp.AcquireTokenInteractive(scopes).ExecuteAsync();
+ }
+
+if (authResult != null)
+ {
+ //Use the Access Token to access the Proxy Application
+
+ HttpClient httpClient = new HttpClient();
+ HttpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", authResult.AccessToken);
+ HttpResponseMessage response = await httpClient.GetAsync("<Proxy App Url>");
+ }
+```
+
+The required info in the sample code can be found in the Azure AD portal, as follows:
+
+| Info required | How to find it in the Azure AD portal |
+| | |
+| \<Tenant ID> | **Azure Active Directory** > **Properties** > **Directory ID** |
+| \<App ID of the Native app> | **Application registration** > *your native application* > **Overview** > **Application ID** |
+| \<Scope> | **Application registration** > *your native application* > **API permissions** > Click on the Permission API (user_impersonation) > A panel with the caption **user_impersonation** appears on the right hand side. > The scope is the URL in the edit box.
+| \<Proxy App Url> | the External Url and path to the API
+
+After you edit the MSAL code with these parameters, your users can authenticate to native client applications even when they are outside of the corporate network.
+
+## Next steps
+
+For more information about the native application flow, see [Native apps in Azure Active Directory](../azuread-dev/native-app.md).
+
+Learn about setting up [Single sign-on to applications in Azure Active Directory](../manage-apps/sso-options.md#choosing-a-single-sign-on-method).
active-directory Application Proxy Configure Single Sign On On Premises Apps https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-configure-single-sign-on-on-premises-apps.md
+
+ Title: SAML single sign-on for on-premises apps with Azure Active Directory Application Proxy
+description: Learn how to provide single sign-on for on-premises applications that are secured with SAML authentication. Provide remote access to on-premises apps with Application Proxy.
+++++++ Last updated : 04/27/2021++++
+# SAML single sign-on for on-premises applications with Application Proxy
+
+You can provide single sign-on (SSO) to on-premises applications that are secured with SAML authentication and provide remote access to these applications through Application Proxy. With SAML single sign-on, Azure Active Directory (Azure AD) authenticates to the application by using the user's Azure AD account. Azure AD communicates the sign-on information to the application through a connection protocol. You can also map users to specific application roles based on rules you define in your SAML claims. By enabling Application Proxy in addition to SAML SSO, your users will have external access to the application and a seamless SSO experience.
+
+The applications must be able to consume SAML tokens issued by **Azure Active Directory**.
+This configuration doesn't apply to applications using an on-premises identity provider. For these scenarios, we recommend reviewing [Resources for migrating applications to Azure AD](../manage-apps/migration-resources.md).
+
+SAML SSO with Application Proxy also works with the SAML token encryption feature. For more info, see [Configure Azure AD SAML token encryption](../manage-apps/howto-saml-token-encryption.md).
+
+The protocol diagrams below describe the single sign-on sequence for both a service provider-initiated (SP-initiated) flow and an identity provider-initiated (IdP-initiated) flow. Application Proxy works with SAML SSO by caching the SAML request and response to and from the on-premises application.
+
+ ![Diagram shows interactions of Application, Application Proxy, Client, and Azure A D for S P-Initiated single sign-on.](./media/application-proxy-configure-single-sign-on-on-premises-apps/saml-sp-initiated-flow.png)
+
+ ![Diagram shows interactions of Application, Application Proxy, Client, and Azure A D for I d P-Initiated single sign-on.](./media/application-proxy-configure-single-sign-on-on-premises-apps/saml-idp-initiated-flow.png)
+
+## Create an application and set up SAML SSO
+
+1. In the Azure portal, select **Azure Active Directory > Enterprise applications** and select **New application**.
+
+2. Enter the display name for your new application, select **Integrate any other application you don't find in the gallery**, then select **Create**.
+
+3. On the app's **Overview** page, select **Single sign-on**.
+
+4. Select **SAML** as the single sign-on method.
+
+5. First set up SAML SSO to work while on the corporate network, see the basic SAML configuration section of [Configure SAML-based single sign-on](../manage-apps/configure-saml-single-sign-on.md) to configure SAML-based authentication for the application.
+
+6. Add at least one user to the application and make sure the test account has access to the application. While connected to the corporate network, use the test account to see if you have single sign-on to the application.
+
+ > [!NOTE]
+ > After you set up Application Proxy, you'll come back and update the SAML **Reply URL**.
+
+## Publish the on-premises application with Application Proxy
+
+Before you can provide SSO for on-premises applications, you need to enable Application Proxy and install a connector. See the tutorial [Add an on-premises application for remote access through Application Proxy in Azure AD](application-proxy-add-on-premises-application.md) to learn how to prepare your on-premises environment, install and register a connector, and test the connector. Then follow these steps to publish your new application with Application Proxy. For other settings not mentioned below, refer to the [Add an on-premises app to Azure AD](application-proxy-add-on-premises-application.md#add-an-on-premises-app-to-azure-ad) section in the tutorial.
+
+1. With the application still open in the Azure portal, select **Application Proxy**. Provide the **Internal URL** for the application. If you're using a custom domain, you also need to upload the TLS/SSL certificate for your application.
+ > [!NOTE]
+ > As a best practice, use custom domains whenever possible for an optimized user experience. Learn more about [Working with custom domains in Azure AD Application Proxy](application-proxy-configure-custom-domain.md).
+
+2. Select **Azure Active Directory** as the **Pre Authentication** method for your application.
+
+3. Copy the **External URL** for the application. You'll need this URL to complete the SAML configuration.
+
+4. Using the test account, try to open the application with the **External URL** to validate that Application Proxy is set up correctly. If there are issues, see [Troubleshoot Application Proxy problems and error messages](application-proxy-troubleshoot.md).
+
+## Update the SAML configuration
+
+1. With the application still open in the Azure portal, select **Single sign-on**.
+
+2. In the **Set up Single Sign-On with SAML** page, go to the **Basic SAML Configuration** heading and select its **Edit** icon (a pencil). Make sure the **External URL** you configured in Application Proxy is populated in the **Identifier**, **Reply URL**, and **Logout URL** fields. These URLs are required for Application Proxy to work correctly.
+
+3. Edit the **Reply URL** configured earlier so that its domain reachable on the internet via Application Proxy. For example, if your **External URL** is `https://contosotravel-f128.msappproxy.net` and the original **Reply URL** was `https://contosotravel.com/acs`, you'll need to update the original **Reply URL** to `https://contosotravel-f128.msappproxy.net/acs`.
+
+ ![Enter basic SAML configuration data](./media/application-proxy-configure-single-sign-on-on-premises-apps/basic-saml-configuration.png)
++
+4. Select the checkbox next to the updated **Reply URL** to mark it as the default.
+
+ * After marking the required **Reply URL** as default, you can also delete the previously configured **Reply URL** that used the internal URL.
+
+ * For an SP-initiated flow, make sure the back-end application specifies the correct **Reply URL** or Assertion Consumer Service URL for receiving the authentication token.
+
+ > [!NOTE]
+ > If the back-end application expects the **Reply URL** to be the Internal URL, you'll need to either use [custom domains](application-proxy-configure-custom-domain.md) to have matching internal and external URLS or install the My Apps secure sign-in extension on users' devices. This extension will automatically redirect to the appropriate Application Proxy Service. To install the extension, see [My Apps secure sign-in extension](../user-help/my-apps-portal-end-user-access.md#download-and-install-the-my-apps-secure-sign-in-extension).
+
+## Test your app
+
+When you've completed all these steps, your app should be up and running. To test the app:
+
+1. Open a browser and navigate to the **External URL** that you created when you published the app.
+1. Sign in with the test account that you assigned to the app. You should be able to load the application and have SSO into the application.
+
+## Next steps
+
+- [How does Azure AD Application Proxy provide single sign-on?](../manage-apps/what-is-single-sign-on.md)
+- [Troubleshoot Application Proxy](application-proxy-troubleshoot.md)
active-directory Application Proxy Configure Single Sign On Password Vaulting https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-configure-single-sign-on-password-vaulting.md
+
+ Title: Single sign-on to apps with Azure Active Directory Application Proxy
+description: Turn on single sign-on for your published on-premises applications with Azure Active Directory Application Proxy in the Azure portal.
+++++++ Last updated : 04/27/2021++++
+# Password vaulting for single sign-on with Application Proxy
+
+Azure Active Directory Application Proxy helps you improve productivity by publishing on-premises applications so that remote employees can securely access them, too. In the Azure portal, you can also set up single sign-on (SSO) to these apps. Your users only need to authenticate with Azure AD, and they can access your enterprise application without having to sign in again.
+
+Application Proxy supports several [single sign-on modes](../manage-apps/sso-options.md#choosing-a-single-sign-on-method). Password-based sign-on is intended for applications that use a username/password combination for authentication. When you configure password-based sign-on for your application, your users have to sign in to the on-premises application once. After that, Azure Active Directory stores the sign-in information and automatically provides it to the application when your users access it remotely.
+
+You should already have published and tested your app with Application Proxy. If not, follow the steps in [Publish applications using Azure AD Application Proxy](application-proxy-add-on-premises-application.md) then come back here.
+
+## Set up password vaulting for your application
+
+1. Sign in to the [Azure portal](https://portal.azure.com) as an administrator.
+1. Select **Azure Active Directory** > **Enterprise applications** > **All applications**.
+1. From the list, select the app that you want to set up with SSO.
+1. Select **Application Proxy**.
+1. Change the **Pre Authentication type** to **Passthrough** and select **Save**. Later you can switch back to **Azure Active Directory** type again!
+1. Select **Single sign-on**.
+
+ ![Select Single sign-on from the app's overview page](./media/application-proxy-configure-single-sign-on-password-vaulting/select-sso.png)
+
+1. For the SSO mode, choose **Password-based Sign-on**.
+1. For the Sign-on URL, enter the URL for the page where users enter their username and password to sign in to your app outside of the corporate network. This may be the External URL that you created when you published the app through Application Proxy.
+
+ ![Choose password-based Sign-on and enter your URL](./media/application-proxy-configure-single-sign-on-password-vaulting/password-sso.png)
+
+1. Select **Save**.
+1. Select **Application Proxy**.
+1. Change the **Pre Authentication type** to **Azure Active Directory** and select **Save**.
+1. Select **Users and Groups**.
+1. Assign users to the application with selecting **Add user**.
+1. If you want to predefine credentials for a user, check the box front of the user name and select **Update credentials**.
+1. Select **Azure Active Directory** > **App registrations** > **All applications**.
+1. From the list, select the app that you configured with Password SSO.
+1. Select **Branding**.
+1. Update the **Home page URL** with the **Sign on URL** from the Password SSO page and select **Save**.
+++
+<!-- Need to repro?
+7. The page should tell you that a sign-in form was successfully detected at the provided URL. If it doesn't, select **Configure [your app name] Password Single Sign-on Settings** and choose **Manually detect sign-in fields**. Follow the instructions to point out where the sign-in credentials go.
+-->
+
+## Test your app
+
+Go to the My Apps portal. Sign in with your credentials (or the credentials for a test account that you set up with access). Once you signed in successfully, click on the icon of the app. This might trigger the installation of the My Apps Secure Sign-in browser extension. If your user had predefined credentials the authentication to the app should happen automatically, otherwise you must specify the user name or password for the first time.
+
+## Next steps
+
+- Read about other ways to implement [Single sign-on](../manage-apps/what-is-single-sign-on.md)
+- Learn about [Security considerations for accessing apps remotely with Azure AD Application Proxy](application-proxy-security.md)
active-directory Application Proxy Configure Single Sign On With Headers https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-configure-single-sign-on-with-headers.md
+
+ Title: Header-based single sign-on for on-premises apps with Azure AD App Proxy
+description: Learn how to provide single sign-on for on-premises applications that are secured with header-based authentication.
+++++++ Last updated : 02/22/2021++++
+# Header-based single sign-on for on-premises apps with Azure AD App Proxy
+
+Azure Active Directory (Azure AD) Application Proxy natively supports single sign-on access to applications that use headers for authentication. You can configure header values required by your application in Azure AD. The header values will be sent down to the application via Application Proxy. Some benefits to using native support for header-based authentication with Application Proxy include:
+
+* **Simplify providing remote access to your on-premises apps** - App Proxy allows you to simplify your existing remote access architecture. You can replace VPN access to these apps. You can also remove dependencies on on-premises identity solutions for authentication. Your users won't notice anything different when they sign in to use your corporate applications. They can still work from anywhere on any device.
+
+* **No additional software or changes to your apps** - You can use your existing Application Proxy connectors and it doesn't require any additional software to be installed.
+
+* **Wide list of attributes and transformations available** - All header values available are based on standard claims that are issued by Azure AD. All attributes and transformations available for [configuring claims for SAML or OIDC applications](../develop/active-directory-saml-claims-customization.md#attributes) are also available to be used as header values.
+
+## Pre-requisites
+Before you get started with single sign-on for header-based authentication apps, make sure your environment is ready with the following settings and configurations:
+- You need to enable Application Proxy and install a connector that has line of site to your applications. See the tutorial [Add an on-premises application for remote access through Application Proxy](application-proxy-add-on-premises-application.md#add-an-on-premises-app-to-azure-ad) to learn how to prepare your on-premises environment, install and register a connector, and test the connector.
+
+## Supported capabilities
+
+The following table lists common capabilities required for header-based authentication applications that are supported with Application Proxy.
+
+|Requirement |Description|
+|-|--|
+|Federated SSO |In pre-authenticated mode, all applications are protected with Azure AD authentication and enable users to have single sign-on. |
+|Remote access |Application Proxy enables remote access to the app. Users can access the application from the internet on any browser using the External URL. Application Proxy is not intended for corporate access use. |
+|Header-based integration |Application Proxy does the SSO integration with Azure AD and then passes identity or other application data as HTTP headers to the application. |
+|Application authorization |Common policies can be specified based on the application being accessed, the userΓÇÖs group membership and other policies. In Azure AD, policies are implemented using [conditional access](../conditional-access/overview.md). Application authorization policies only apply to the initial authentication request. |
+|Step-up authentication |Policies can be defined to force added authentication, for example, to gain access to sensitive resources. |
+|Fine grained authorization |Provides access control at the URL level. Added policies can be enforced based on the URL being accessed. The internal URL configured for the app, defines the scope of app that the policy is applied to. The policy configured for the most granular path is enforced. |
+
+> [!NOTE]
+> This article features connecting header-based authentication applications to Azure AD using Application Proxy and is the recommended pattern. As an alternative, there is also an integration pattern that uses PingAccess with Azure AD to enable header-based authentication. For more details, see [Header-based authentication for single sign-on with Application Proxy and PingAccess](../manage-apps/application-proxy-ping-access-publishing-guide.md).
+
+## How it works
++
+1. The Admin customizes the attribute mappings required by the application in the Azure AD portal.
+2. When a user accesses the app, Application Proxy ensures the user is authenticated by Azure AD
+3. The Application Proxy cloud service is aware of the attributes required. So the service fetches the corresponding claims from the ID token received during authentication. The service then translates the values into the required HTTP headers as part of the request to the Connector.
+4. The request is then passed along to the Connector, which is then passed to the backend application.
+5. The application receives the headers and can use these headers as needed.
+
+## Publish the application with Application Proxy
+
+1. Publish your application according to the instructions described inΓÇ»[Publish applications with Application Proxy](application-proxy-add-on-premises-application.md#add-an-on-premises-app-to-azure-ad).
+ - The Internal URL value determines the scope of the application. If you configure Internal URL value at the root path of the application, then all sub paths underneath the root will receive the same header configuration and other application configuration.
+ - Create a new application to set a different header configuration or user assignment for a more granular path than the application you configured. In the new application, configure the internal URL with the specific path you require and then configure the specific headers needed for this URL. Application Proxy will always match your configuration settings to the most granular path set for an application.
+
+2. Select **Azure Active Directory** as the **pre-authentication method**.
+3. Assign a test user by navigating to **Users and groups** and assigning the appropriate users and groups.
+4. Open a browser and navigate to the **External URL** from the Application Proxy settings.
+5. Verify that you can connect to the application. Even though you can connect, you can't access the app yet since the headers aren't configured.
+
+## Configure single sign-on
+Before you get started with single sign-on for header-based applications, you should have already installed an Application Proxy connector and the connector can access the target applications. If not, follow the steps in [Tutorial: Azure AD Application Proxy](application-proxy-add-on-premises-application.md) then come back here.
+
+1. After your application appears in the list of enterprise applications, select it, and selectΓÇ»**Single sign-on**.
+2. Set the single sign-on mode to **Header-based**.
+3. In Basic Configuration, **Azure Active Directory**, will be selected as the default.
+4. Select the edit pencil, in Headers to configure headers to send to the application.
+5. Select **Add new header**. Provide a **Name** for the header and select either **Attribute** or **Transformation** and select from the drop-down which header your application needs.
+ - To learn more about the list of attribute available, see [Claims Customizations- Attributes](../develop/active-directory-saml-claims-customization.md#attributes).
+ - To learn more about the list of transformation available, see [Claims Customizations- Claim Transformations](../develop/active-directory-saml-claims-customization.md#claim-transformations).
+ - You may also add a **Group Header**, to send all the groups a user is part of, or the groups assigned to the application as a header. To learn more about configuring groups as a value see: [Configure group claims for applications](../hybrid/how-to-connect-fed-group-claims.md#add-group-claims-to-tokens-for-saml-applications-using-sso-configuration).
+6. Select Save.
+
+## Test your app
+
+When you've completed all these steps, your app should be running and available. To test the app:
+1. Open a new browser or private browser window to make sure previously cached headers are cleared. Then navigate to the **External URL** from the Application Proxy settings.
+2. Sign in with the test account that you assigned to the app. If you can load and sign into the application using SSO, then you're good!
+
+## Considerations
+
+- Application Proxy is used to provide remote access to apps on-premises or on private cloud. Application Proxy is not recommended to handle traffic originating internally from the corporate network.
+- Access to header-based authentication applications should be restricted to only traffic from the connector or other permitted header-based authentication solution. This is commonly done through restricting network access to the application using a firewall or IP restriction on the application server.
+
+## Next steps
+
+- [What is single sign-on?](../manage-apps/what-is-single-sign-on.md)
+- [What is application proxy?](what-is-application-proxy.md)
+- [Quickstart Series on Application Management](../manage-apps/view-applications-portal.md)
active-directory Application Proxy Configure Single Sign On With Kcd https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-configure-single-sign-on-with-kcd.md
+
+ Title: Kerberos-based single sign-on (SSO) in Azure Active Directory with Application Proxy
+description: Covers how to provide single sign-on using Azure Active Directory Application Proxy.
+++++++ Last updated : 04/27/2021+++++
+# Kerberos Constrained Delegation for single sign-on (SSO) to your apps with Application Proxy
+
+You can provide single sign-on for on-premises applications published through Application Proxy that are secured with Integrated Windows Authentication. These applications require a Kerberos ticket for access. Application Proxy uses Kerberos Constrained Delegation (KCD) to support these applications.
+
+You can enable single sign-on to your applications using Integrated Windows Authentication (IWA) by giving Application Proxy connectors permission in Active Directory to impersonate users. The connectors use this permission to send and receive tokens on their behalf.
+
+## How single sign-on with KCD works
+This diagram explains the flow when a user attempts to access an on premises application that uses IWA.
+
+![Microsoft AAD authentication flow diagram](./media/application-proxy-configure-single-sign-on-with-kcd/authdiagram.png)
+
+1. The user enters the URL to access the on premises application through Application Proxy.
+2. Application Proxy redirects the request to Azure AD authentication services to preauthenticate. At this point, Azure AD applies any applicable authentication and authorization policies, such as multifactor authentication. If the user is validated, Azure AD creates a token and sends it to the user.
+3. The user passes the token to Application Proxy.
+4. Application Proxy validates the token and retrieves the User Principal Name (UPN) from it, and then the Connector pulls the UPN, and the Service Principal Name (SPN) through a dually authenticated secure channel.
+5. The Connector performs Kerberos Constrained Delegation (KCD) negotiation with the on premises AD, impersonating the user to get a Kerberos token to the application.
+6. Active Directory sends the Kerberos token for the application to the Connector.
+7. The Connector sends the original request to the application server, using the Kerberos token it received from AD.
+8. The application sends the response to the Connector, which is then returned to the Application Proxy service and finally to the user.
+
+## Prerequisites
+Before you get started with single sign-on for IWA applications, make sure your environment is ready with the following settings and configurations:
+
+* Your apps, like SharePoint Web apps, are set to use Integrated Windows Authentication. For more information, see [Enable Support for Kerberos Authentication](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd759186(v=ws.11)), or for SharePoint see [Plan for Kerberos authentication in SharePoint 2013](/SharePoint/security-for-sharepoint-server/kerberos-authentication-planning).
+* All your apps have [Service Principal Names](https://social.technet.microsoft.com/wiki/contents/articles/717.service-principal-names-spns-setspn-syntax-setspn-exe.aspx).
+* The server running the Connector and the server running the app are domain joined and part of the same domain or trusting domains. For more information on domain join, see [Join a Computer to a Domain](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dd807102(v=ws.11)).
+* The server running the Connector has access to read the TokenGroupsGlobalAndUniversal attribute for users. This default setting might have been impacted by security hardening the environment.
+
+### Configure Active Directory
+The Active Directory configuration varies, depending on whether your Application Proxy connector and the application server are in the same domain or not.
+
+#### Connector and application server in the same domain
+1. In Active Directory, go to **Tools** > **Users and Computers**.
+2. Select the server running the connector.
+3. Right-click and select **Properties** > **Delegation**.
+4. Select **Trust this computer for delegation to specified services only**.
+5. Select **Use any authentication protocol**.
+6. Under **Services to which this account can present delegated credentials** add the value for the SPN identity of the application server. This enables the Application Proxy Connector to impersonate users in AD against the applications defined in the list.
+
+ ![Connector-SVR Properties window screenshot](./media/application-proxy-configure-single-sign-on-with-kcd/properties.jpg)
+
+#### Connector and application server in different domains
+1. For a list of prerequisites for working with KCD across domains, see [Kerberos Constrained Delegation across domains](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831477(v=ws.11)).
+2. Use the `principalsallowedtodelegateto` property of the service account (computer or dedicated domain user account) of the web application to enable Kerberos authentication delegation from the Application Proxy (connector). The application server is running in the context of `webserviceaccount` and the delegating server is `connectorcomputeraccount`. Run the commands below on a Domain Controller (running Windows Server 2012 R2 or later) in the domain of `webserviceaccount`. Use flat names (non UPN) for both accounts.
+
+ If the `webserviceaccount` is a computer account, use these commands:
+
+ ```powershell
+ $connector= Get-ADComputer -Identity connectorcomputeraccount -server dc.connectordomain.com
+
+ Set-ADComputer -Identity webserviceaccount -PrincipalsAllowedToDelegateToAccount $connector
+
+ Get-ADComputer webserviceaccount -Properties PrincipalsAllowedToDelegateToAccount
+ ```
+
+ If the `webserviceaccount` is a user account, use these commands:
+
+ ```powershell
+ $connector= Get-ADComputer -Identity connectorcomputeraccount -server dc.connectordomain.com
+
+ Set-ADUser -Identity webserviceaccount -PrincipalsAllowedToDelegateToAccount $connector
+
+ Get-ADUser webserviceaccount -Properties PrincipalsAllowedToDelegateToAccount
+ ```
+
+## Configure single sign-on
+1. Publish your application according to the instructions described in [Publish applications with Application Proxy](../app-proxy/application-proxy-add-on-premises-application.md). Make sure to select **Azure Active Directory** as the **Preauthentication Method**.
+2. After your application appears in the list of enterprise applications, select it and click **Single sign-on**.
+3. Set the single sign-on mode to **Integrated Windows Authentication**.
+4. Enter the **Internal Application SPN** of the application server. In this example, the SPN for our published application is http/www.contoso.com. This SPN needs to be in the list of services to which the connector can present delegated credentials.
+5. Choose the **Delegated Login Identity** for the connector to use on behalf of your users. For more information, see [Working with different on-premises and cloud identities](#working-with-different-on-premises-and-cloud-identities)
+
+ ![Advanced Application Configuration](./media/application-proxy-configure-single-sign-on-with-kcd/cwap_auth2.png)
+
+## SSO for non-Windows apps
+
+The Kerberos delegation flow in Azure AD Application Proxy starts when Azure AD authenticates the user in the cloud. Once the request arrives on-premises, the Azure AD Application Proxy connector issues a Kerberos ticket on behalf of the user by interacting with the local Active Directory. This process is referred to as Kerberos Constrained Delegation (KCD).
+
+In the next phase, a request is sent to the backend application with this Kerberos ticket.
+
+There are several mechanisms that define how to send the Kerberos ticket in such requests. Most non-Windows servers expect to receive it in form of SPNEGO token. This mechanism is supported on Azure AD Application Proxy, but is disabled by default. A connector can be configured for SPNEGO or standard Kerberos token, but not both.
+
+If you configure a connector machine for SPNEGO, make sure that all other connectors in that Connector group are also configured with SPNEGO. Applications expecting standard Kerberos token should be routed through other connectors that are not configured for SPNEGO. Some web applications accept both formats without requiring any change in configuration.
+
+
+To enable SPNEGO:
+
+1. Open a command prompt that runs as administrator.
+2. From the command prompt, run the following commands on the connector servers that need SPNEGO.
+
+ ```
+ REG ADD "HKLM\SOFTWARE\Microsoft\Microsoft AAD App Proxy Connector" /v UseSpnegoAuthentication /t REG_DWORD /d 1
+ net stop WAPCSvc & net start WAPCSvc
+ ```
+
+Non-Windows apps typically user usernames or SAM account names instead of domain email addresses. If that situation applies to your applications, you need to configure the delegated login identity field to connect your cloud identities to your application identities.
+
+## Working with different on-premises and cloud identities
+Application Proxy assumes that users have exactly the same identity in the cloud and on-premises. But in some environments, due to corporate policies or application dependencies, organizations might have to use alternate IDs for sign-in. In such cases, you can still use KCD for single sign-on. Configure a **Delegated login identity** for each application to specify which identity should be used when performing single sign-on.
+
+This capability allows many organizations that have different on-premises and cloud identities to have SSO from the cloud to on-premises apps without requiring the users to enter different usernames and passwords. This includes organizations that:
+
+* Have multiple domains internally (joe@us.contoso.com, joe@eu.contoso.com) and a single domain in the cloud (joe@contoso.com).
+* Have non-routable domain name internally (joe@contoso.usa) and a legal one in the cloud.
+* Do not use domain names internally (joe)
+* Use different aliases on premises and in the cloud. For example, joe-johns@contoso.com vs. joej@contoso.com
+
+With Application Proxy, you can select which identity to use to obtain the Kerberos ticket. This setting is per application. Some of these options are suitable for systems that do not accept email address format, others are designed for alternative login.
+
+![Delegated login identity parameter screenshot](./media/application-proxy-configure-single-sign-on-with-kcd/app_proxy_sso_diff_id_upn.png)
+
+If delegated login identity is used, the value might not be unique across all the domains or forests in your organization. You can avoid this issue by publishing these applications twice using two different Connector groups. Since each application has a different user audience, you can join its Connectors to a different domain.
+
+If **On-premises SAM account name** is used for the logon identity, the computer hosting the connector must be added to the domain in which the user account is located.
+
+### Configure SSO for different identities
+1. Configure Azure AD Connect settings so the main identity is the email address (mail). This is done as part of the customize process, by changing the **User Principal Name** field in the sync settings. These settings also determine how users log in to Office365, Windows10 devices, and other applications that use Azure AD as their identity store.
+ ![Identifying users screenshot - User Principal Name dropdown](./media/application-proxy-configure-single-sign-on-with-kcd/app_proxy_sso_diff_id_connect_settings.png)
+2. In the Application Configuration settings for the application you would like to modify, select the **Delegated Login Identity** to be used:
+
+ * User Principal Name (for example, joe@contoso.com)
+ * Alternate User Principal Name (for example, joed@contoso.local)
+ * Username part of User Principal Name (for example, joe)
+ * Username part of Alternate User Principal Name (for example, joed)
+ * On-premises SAM account name (depends on the domain controller configuration)
+
+### Troubleshooting SSO for different identities
+If there is an error in the SSO process, it appears in the connector machine event log as explained in [Troubleshooting](application-proxy-back-end-kerberos-constrained-delegation-how-to.md).
+But, in some cases, the request is successfully sent to the backend application while this application replies in various other HTTP responses. Troubleshooting these cases should start by examining event number 24029 on the connector machine in the Application Proxy session event log. The user identity that was used for delegation appears in the ΓÇ£userΓÇ¥ field within the event details. To turn on session log, select **Show analytic and debug logs** in the event viewer view menu.
+
+## Next steps
+
+* [How to configure an Application Proxy application to use Kerberos Constrained Delegation](application-proxy-back-end-kerberos-constrained-delegation-how-to.md)
+* [Troubleshoot issues you're having with Application Proxy](application-proxy-troubleshoot.md)
active-directory Application Proxy Connectivity No Working Connector https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-connectivity-no-working-connector.md
+
+ Title: No working connector group found for an Azure Active Directory Application Proxy app
+description: Address problems you might encounter when there is no working Connector in a Connector Group for your application with the Azure Active Directory Application Proxy
+++++++ Last updated : 04/27/2021++++
+# No working connector group found for an Application Proxy application
+
+This article helps to resolve the common issues faced when there is not a connector detected for an Application Proxy application integrated with Azure Active Directory.
+
+## Overview of steps
+If there is no working Connector in a Connector Group for your application, there are a few ways to resolve the problem:
+
+- If you have no connectors in the group, you can:
+
+ - Download a new Connector on the right on premises server, and assign it to this group
+
+ - Move an active Connector into the group
+
+- If you have no active connectors in the group, you can:
+
+ - Identify the reason your Connector is inactive and resolve
+
+ - Move an active Connector into the group
+
+To figure out the issue, open the ΓÇ£Application ProxyΓÇ¥ menu in your Application, and look at the Connector Group warning message. If there are no connectors in the group, the warning message specifies the group needs at least one Connector. If you have no active Connectors, the warning message explains that. It is common to have inactive Connectors.
+
+ ![Connector group selection in Azure portal](./media/application-proxy-connectivity-no-working-connector/no-active-connector.png)
+
+For details on each of these options, see the corresponding section below. The instructions assume that you are starting from the Connector management page. If you are looking at the error message above, you can go to this page by clicking on the warning message. You can also get to the page by going to **Azure Active Directory**, clicking on **Enterprise Applications**, then **Application Proxy.**
+
+ ![Connector group management in Azure portal](./media/application-proxy-connectivity-no-working-connector/app-proxy.png)
+
+## Download a new Connector
+
+To download a new Connector, use the ΓÇ£Download ConnectorΓÇ¥ button at the top of the page.
+
+Install the connector on a machine with direct line of sight to the backend application. Typically, the connector is installed on the same server as the application. After downloading, the Connector should appear in this menu. click the Connector, and use the ΓÇ£Connector GroupΓÇ¥ drop-down to make sure it belongs to the right group. Save the change.
+
+ ![Download the connector from the Azure portal](./media/application-proxy-connectivity-no-working-connector/download-connector.png)
+
+## Move an Active Connector
+
+If you have an active Connector that should belong to the group and has line of sight to the target backend application, you can move the Connector into the assigned group. To do so, click the Connector. In the ΓÇ£Connector GroupΓÇ¥ field, use the drop-down to select the correct group, and click Save.
+
+## Resolve an inactive Connector
+
+If the only Connectors in the group are inactive, they are likely on a machine that does not have all the necessary ports unblocked.
+
+see the ports Troubleshoot document for details on investigating this problem.
+
+## Next steps
+[Understand Azure AD Application Proxy connectors](application-proxy-connectors.md)
++
active-directory Application Proxy Connector Groups https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-connector-groups.md
+
+ Title: Publish apps on separate networks via connector groups - Azure Active Directory
+description: Covers how to create and manage groups of connectors in Azure Active Directory Application Proxy.
+++++++ Last updated : 04/27/2021++++
+# Publish applications on separate networks and locations using connector groups
+
+Customers utilize Azure AD's Application Proxy for more scenarios and applications. So we've made App Proxy even more flexible by enabling more topologies. You can create Application Proxy connector groups so that you can assign specific connectors to serve specific applications. This capability gives you more control and ways to optimize your Application Proxy deployment.
+
+Each Application Proxy connector is assigned to a connector group. All the connectors that belong to the same connector group act as a separate unit for high-availability and load balancing. All connectors belong to a connector group. If you don't create groups, then all your connectors are in a default group. Your admin can create new groups and assign connectors to them in the Azure portal.
+
+All applications are assigned to a connector group. If you don't create groups, then all your applications are assigned to a default group. But if you organize your connectors into groups, you can set each application to work with a specific connector group. In this case, only the connectors in that group serve the application upon request. This feature is useful if your applications are hosted in different locations. You can create connector groups based on location, so that applications are always served by connectors that are physically close to them.
+
+> [!TIP]
+> If you have a large Application Proxy deployment, don't assign any applications to the default connector group. That way, new connectors don't receive any live traffic until you assign them to an active connector group. This configuration also enables you to put connectors in an idle mode by moving them back to the default group, so that you can perform maintenance without impacting your users.
+
+## Prerequisites
+
+To group your connectors, you have to make sure you [installed multiple connectors](application-proxy-add-on-premises-application.md). When you install a new connector, it automatically joins the **Default** connector group.
+
+## Create connector groups
+
+Use these steps to create as many connector groups as you want.
+
+1. Sign in to the [Azure portal](https://portal.azure.com).
+1. Select **Azure Active Directory** > **Enterprise applications** > **Application proxy**.
+1. Select **New connector group**. The New Connector Group blade appears.
+
+ ![Shows the screen to select a new connector group](./media/application-proxy-connector-groups/new-group.png)
+
+1. Give your new connector group a name, then use the dropdown menu to select which connectors belong in this group.
+1. Select **Save**.
+
+## Assign applications to your connector groups
+
+Use these steps for each application that you've published with Application Proxy. You can assign an application to a connector group when you first publish it, or you can use these steps to change the assignment whenever you want.
+
+1. From the management dashboard for your directory, select **Enterprise applications** > **All applications** > the application you want to assign to a connector group > **Application Proxy**.
+1. Use the **Connector Group** dropdown menu to select the group you want the application to use.
+1. Select **Save** to apply the change.
+
+## Use cases for connector groups
+
+Connector groups are useful for various scenarios, including:
+
+### Sites with multiple interconnected datacenters
+
+Many organizations have a number of interconnected datacenters. In this case, you want to keep as much traffic within the datacenter as possible because cross-datacenter links are expensive and slow. You can deploy connectors in each datacenter to serve only the applications that reside within the datacenter. This approach minimizes cross-datacenter links and provides an entirely transparent experience to your users.
+
+### Applications installed on isolated networks
+
+Applications can be hosted in networks that are not part of the main corporate network. You can use connector groups to install dedicated connectors on isolated networks to also isolate applications to the network. This usually happens when a third-party vendor maintains a specific application for your organization.
+
+Connector groups allow you to install dedicated connectors for those networks that publish only specific applications, making it easier and more secure to outsource application management to third-party vendors.
+
+### Applications installed on IaaS
+
+For applications installed on IaaS for cloud access, connector groups provide a common service to secure the access to all the apps. Connector groups don't create additional dependency on your corporate network, or fragment the app experience. Connectors can be installed on every cloud datacenter and serve only applications that reside in that network. You can install several connectors to achieve high availability.
+
+Take as an example an organization that has several virtual machines connected to their own IaaS hosted virtual network. To allow employees to use these applications, these private networks are connected to the corporate network using site-to-site VPN. This provides a good experience for employees that are located on-premises. But, it may not be ideal for remote employees, because it requires additional on-premises infrastructure to route access, as you can see in the diagram below:
+
+![Diagram that illustrates the Azure AD IaaS network](./media/application-proxy-connector-groups/application-proxy-iaas-network.png)
+
+With Azure AD Application Proxy connector groups, you can enable a common service to secure the access to all applications without creating additional dependency on your corporate network:
+
+![Azure AD IaaS Multiple Cloud Vendors](./media/application-proxy-connector-groups/application-proxy-multiple-cloud-vendors.png)
+
+### Multi-forest ΓÇô different connector groups for each forest
+
+Most customers who have deployed Application Proxy are using its single-sign-on (SSO) capabilities by performing Kerberos Constrained Delegation (KCD). To achieve this, the connectorΓÇÖs machines need to be joined to a domain that can delegate the users toward the application. KCD supports cross-forest capabilities. But for companies who have distinct multi-forest environments with no trust between them, a single connector cannot be used for all forests.
+
+In this case, specific connectors can be deployed per forest, and set to serve applications that were published to serve only the users of that specific forest. Each connector group represents a different forest. While the tenant and most of the experience is unified for all forests, users can be assigned to their forest applications using Azure AD groups.
+
+### Disaster Recovery sites
+
+There are two different approaches you can take with a disaster recovery (DR) site, depending on how your sites are implemented:
+
+* If your DR site is built in active-active mode where it is exactly like the main site and has the same networking and AD settings, you can create the connectors on the DR site in the same connector group as the main site. This enables Azure AD to detect failovers for you.
+* If your DR site is separate from the main site, you can create a different connector group in the DR site, and either 1) have backup applications or 2) manually divert the existing application to the DR connector group as needed.
+
+### Serve multiple companies from a single tenant
+
+There are many different ways to implement a model in which a single service provider deploys and maintains Azure AD related services for multiple companies. Connector groups help the admin segregate the connectors and applications into different groups. One way, which is suitable for small companies, is to have a single Azure AD tenant while the different companies have their own domain name and networks. This is also true for M&A scenarios and situations where a single IT division serves several companies for regulatory or business reasons.
+
+## Sample configurations
+
+Some examples that you can implement, include the following connector groups.
+
+### Default configuration ΓÇô no use for connector groups
+
+If you donΓÇÖt use connector groups, your configuration would look like this:
+
+![Example Azure AD No Connector Groups](./media/application-proxy-connector-groups/application-proxy-sample-config-1.png)
+
+This configuration is sufficient for small deployments and tests. It will also work well if your organization has a flat network topology.
+
+### Default configuration and an isolated network
+
+This configuration is an evolution of the default one, in which there is a specific app that runs in an isolated network such as IaaS virtual network:
+
+![Example Azure AD No Connector Groups and an isolated network](./media/application-proxy-connector-groups/application-proxy-sample-config-2.png)
+
+### Recommended configuration ΓÇô several specific groups and a default group for idle
+
+The recommended configuration for large and complex organizations is to have the default connector group as a group that doesnΓÇÖt serve any applications and is used for idle or newly installed connectors. All applications are served using customized connector groups. This enables all the complexity of the scenarios described above.
+
+In the example below, the company has two datacenters, A and B, with two connectors that serve each site. Each site has different applications that run on it.
+
+![Example of company with 2 datacenters and 2 connectors](./media/application-proxy-connector-groups/application-proxy-sample-config-3.png)
+
+## Next steps
+
+[Understand Azure AD Application Proxy connectors](application-proxy-connectors.md)
+[Enable single-sign on](../manage-apps/what-is-single-sign-on.md)
active-directory Application Proxy Connector Installation Problem https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-connector-installation-problem.md
+
+ Title: Problem installing the Azure Active Directory Application Proxy Agent Connector
+description: How to troubleshoot issues you might face when installing the Application Proxy Agent Connector for Azure Active Directory.
+++++++ Last updated : 04/27/2021++++
+# Problem installing the Application Proxy Agent Connector
+
+Microsoft Azure Active Directory Application Proxy Connector is an internal domain component that uses outbound connections to establish the connectivity from the cloud available endpoint to the internal domain.
+
+## General Problem Areas with Connector installation
+
+When the installation of a connector fails, the root cause is usually one of the following areas. **As a precursor to any troubleshooting, be sure to reboot the connector.**
+
+1. **Connectivity** ΓÇô to complete a successful installation, the new connector needs to register and establish future trust properties. This is done by connecting to the Azure Active Directory Application Proxy cloud service.
+
+2. **Trust Establishment** ΓÇô the new connector creates a self-signed cert and registers to the cloud service.
+
+3. **Authentication of the admin** ΓÇô during installation, the user must provide admin credentials to complete the Connector installation.
+
+> [!NOTE]
+> The Connector installation logs can be found in the %TEMP% folder and can help provide additional information on what is causing an installation failure.
+
+## Verify connectivity to the Cloud Application Proxy service and Microsoft Login page
+
+**Objective:** Verify that the connector machine can connect to the Application Proxy registration endpoint as well as Microsoft login page.
+
+1. On the connector server, run a port test by using [telnet](/windows-server/administration/windows-commands/telnet) or other port testing tool to verify that ports 443 and 80 are open.
+
+2. If any of those ports is not successful, verify that the Firewall or backend proxy has access to the required domains and ports see, [Prepare your on-premises environment](application-proxy-add-on-premises-application.md#prepare-your-on-premises-environment).
+
+3. Open a browser (separate tab) and go to the following web page: `https://login.microsoftonline.com`, make sure that you can login to that page.
+
+## Verify Machine and backend components support for Application Proxy trust certificate
+
+**Objective:** Verify that the connector machine, backend proxy and firewall can support the certificate created by the connector for future trust and that the certificate is valid.
+
+>[!NOTE]
+>The connector tries to create a SHA512 cert that is supported by TLS1.2. If the machine or the backend firewall and proxy does not support TLS1.2, the installation fails.
+>
+>
+
+**Review the pre-requisites required:**
+
+1. Verify the machine supports TLS1.2 ΓÇô All Windows versions after 2012 R2 should support TLS 1.2. If your connector machine is from a version of 2012 R2 or prior, make sure that the following KBs are installed on the machine: <https://support.microsoft.com/help/2973337/sha512-is-disabled-in-windows-when-you-use-tls-1.2>
+
+2. Contact your network admin and ask to verify that the backend proxy and firewall do not block SHA512 for outgoing traffic.
+
+**To verify the client certificate:**
+
+Verify the thumbprint of the current client certificate. The certificate store can be found in `%ProgramData%\microsoft\Microsoft AAD Application Proxy Connector\Config\TrustSettings.xml`.
+
+```
+<?xml version="1.0" encoding="utf-8"?>
+<ConnectorTrustSettingsFile xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+ <CloudProxyTrust>
+ <Thumbprint>4905CC64B2D81BBED60962ECC5DCF63F643CCD55</Thumbprint>
+ <IsInUserStore>false</IsInUserStore>
+ </CloudProxyTrust>
+</ConnectorTrustSettingsFile>
+```
+
+The possible **IsInUserStore** values are **true** and **false**. A value of **true** means the automatically renewed certificate is stored in the personal container in the user certificate store of the Network Service. A value of **false** means the client certificate was created during the installation or registration initiated by Register-AppProxyConnector command and it is stored in the personal container in the certificate store of the local machine.
+
+If the value is **true**, follow these steps to verify the certificate:
+1. Download [PsTools.zip](/sysinternals/downloads/pstools)
+2. Extract [PsExec](/sysinternals/downloads/psexec) from the package and run **psexec -i -u "nt authority\network service" cmd.exe** from an elevated command prompt.
+3. Run **certmgr.msc** in the newly appeared command prompt
+4. In the management console expand the Personal container and click on Certificates
+5. Locate the certificate issued by **connectorregistrationca.msappproxy.net**
+
+If the value is **false**, follow these steps to verify the certificate:
+1. Run **certlm.msc**
+2. In the management console expand the Personal container and click on Certificates
+3. Locate the certificate issued by **connectorregistrationca.msappproxy.net**
+
+**To renew the client certificate:**
+
+If a connector is not connected to the service for several months, its certificates may be outdated. The failure of the certificate renewal leads to an expired certificate. This makes the connector service to stop working. The event 1000 is recorded in the admin log of the connector:
+
+"Connector re-registration failed: The Connector trust certificate expired. Run the PowerShell cmdlet Register-AppProxyConnector on the computer on which the Connector is running to re-register your Connector."
+
+In this case, uninstall and reinstall the connector to trigger registration or you can run the following PowerShell commands:
+
+```
+Import-module AppProxyPSModule
+Register-AppProxyConnector
+```
+
+To learn more about the Register-AppProxyConnector command, please see [Create an unattended installation script for the Azure AD Application Proxy connector](./application-proxy-register-connector-powershell.md)
+
+## Verify admin is used to install the connector
+
+**Objective:** Verify that the user who tries to install the connector is an administrator with correct credentials. Currently, the user must be at least an application administrator for the installation to succeed.
+
+**To verify the credentials are correct:**
+
+Connect to `https://login.microsoftonline.com` and use the same credentials. Make sure the login is successful. You can check the user role by going to **Azure Active Directory** -&gt; **Users and Groups** -&gt; **All Users**.
+
+Select your user account, then "Directory Role" in the resulting menu. Verify that the selected role is "Application Administrator". If you are unable to access any of the pages along these steps, you do not have the required role.
+
+## Next steps
+[Understand Azure AD Application Proxy connectors](application-proxy-connectors.md)
active-directory Application Proxy Connectors https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-connectors.md
+
+ Title: Understand Azure Active Directory Application Proxy connectors
+description: Learn about the Azure Active Directory Application Proxy connectors.
+++++++ Last updated : 04/27/2021++++
+# Understand Azure AD Application Proxy connectors
+
+Connectors are what make Azure AD Application Proxy possible. They're simple, easy to deploy and maintain, and super powerful. This article discusses what connectors are, how they work, and some suggestions for how to optimize your deployment.
+
+## What is an Application Proxy connector?
+
+Connectors are lightweight agents that sit on-premises and facilitate the outbound connection to the Application Proxy service. Connectors must be installed on a Windows Server that has access to the backend application. You can organize connectors into connector groups, with each group handling traffic to specific applications. For more information on Application proxy and a diagrammatic representation of application proxy architecture see [Using Azure AD Application Proxy to publish on-premises apps for remote users](what-is-application-proxy.md#application-proxy-connectors)
+
+## Requirements and deployment
+
+To deploy Application Proxy successfully, you need at least one connector, but we recommend two or more for greater resiliency. Install the connector on a machine running Windows Server 2012 R2 or later. The connector needs to communicate with the Application Proxy service and the on-premises applications that you publish.
+
+### Windows server
+You need a server running Windows Server 2012 R2 or later on which you can install the Application Proxy connector. The server needs to connect to the Application Proxy services in Azure, and the on-premises applications that you're publishing.
+
+The windows server needs to have TLS 1.2 enabled before you install the Application Proxy connector. To enable TLS 1.2 on the server:
+
+1. Set the following registry keys:
+
+ ```
+ [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]
+ [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001
+ [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server] "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001
+ [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319] "SchUseStrongCrypto"=dword:00000001
+ ```
+
+1. Restart the server
+
+For more information about the network requirements for the connector server, see [Get started with Application Proxy and install a connector](application-proxy-add-on-premises-application.md).
+
+## Maintenance
+
+The connectors and the service take care of all the high availability tasks. They can be added or removed dynamically. Each time a new request arrives it is routed to one of the connectors that is currently available. If a connector is temporarily not available, it doesn't respond to this traffic.
+
+The connectors are stateless and have no configuration data on the machine. The only data they store is the settings for connecting the service and its authentication certificate. When they connect to the service, they pull all the required configuration data and refresh it every couple of minutes.
+
+Connectors also poll the server to find out whether there is a newer version of the connector. If one is found, the connectors update themselves.
+
+You can monitor your connectors from the machine they are running on, using either the event log and performance counters. Or you can view their status from the Application Proxy page of the Azure portal:
+
+![Example: Azure AD Application Proxy connectors](./media/application-proxy-connectors/app-proxy-connectors.png)
+
+You don't have to manually delete connectors that are unused. When a connector is running, it remains active as it connects to the service. Unused connectors are tagged as _inactive_ and are removed after 10 days of inactivity. If you do want to uninstall a connector, though, uninstall both the Connector service and the Updater service from the server. Restart your computer to fully remove the service.
+
+## Automatic updates
+
+Azure AD provides automatic updates for all the connectors that you deploy. As long as the Application Proxy Connector Updater service is running, your connectors [update with the latest major connector release](application-proxy-faq.yml#why-is-my-connector-still-using-an-older-version-and-not-auto-upgraded-to-latest-version-) automatically. If you donΓÇÖt see the Connector Updater service on your server, you need to [reinstall your connector](application-proxy-add-on-premises-application.md) to get any updates.
+
+If you don't want to wait for an automatic update to come to your connector, you can do a manual upgrade. Go to the [connector download page](https://download.msappproxy.net/subscription/d3c8b69d-6bf7-42be-a529-3fe9c2e70c90/connector/download) on the server where your connector is located and select **Download**. This process kicks off an upgrade for the local connector.
+
+For tenants with multiple connectors, the automatic updates target one connector at a time in each group to prevent downtime in your environment.
+
+You may experience downtime when your connector updates if:
+
+- You only have one connector we recommend you install a second connector and [create a connector group](application-proxy-connector-groups.md). This will avoid downtime and provide higher availability.
+- A connector was in the middle of a transaction when the update began. Although the initial transaction is lost, your browser should automatically retry the operation or you can refresh your page. When the request is resent, the traffic is routed to a backup connector.
+
+To see information about previously released versions and what changes they include, see [Application Proxy- Version Release History](../manage-apps/application-proxy-release-version-history.md).
+
+## Creating connector groups
+
+Connector groups enable you to assign specific connectors to serve specific applications. You can group many connectors together, and then assign each application to a group.
+
+Connector groups make it easier to manage large deployments. They also improve latency for tenants that have applications hosted in different regions, because you can create location-based connector groups to serve only local applications.
+
+To learn more about connector groups, see [Publish applications on separate networks and locations using connector groups](application-proxy-connector-groups.md).
+
+## Capacity planning
+
+It is important to make sure you have planned enough capacity between connectors to handle the expected traffic volume. We recommend that each connector group has at least two connectors to provide high availability and scale. Having three connectors is optimal in case you may need to service a machine at any point.
+
+In general, the more users you have, the larger a machine you'll need. Below is a table giving an outline of the volume and expected latency different machines can handle. Note it is all based on expected Transactions Per Second (TPS) rather than by user since usage patterns vary and can't be used to predict load. There will also be some differences based on the size of the responses and the backend application response time - larger response sizes and slower response times will result in a lower Max TPS. We also recommend having additional machines so that the distributed load across the machines always provides ample buffer. The extra capacity will ensure that you have high availability and resiliency.
+
+|Cores|RAM|Expected Latency (MS)-P99|Max TPS|
+| -- | -- | -- | -- |
+|2|8|325|586|
+|4|16|320|1150|
+|8|32|270|1190|
+|16|64|245|1200*|
+
+\* This machine used a custom setting to raise some of the default connection limits beyond .NET recommended settings. We recommend running a test with the default settings before contacting support to get this limit changed for your tenant.
+
+> [!NOTE]
+> There is not much difference in the maximum TPS between 4, 8, and 16 core machines. The main difference between those is in the expected latency.
+>
+> This table also focuses on the expected performance of a connector based on the type of machine it is installed on. This is separate from the Application Proxy service's throttling limits, see [Service limits and restrictions](../enterprise-users/directory-service-limits-restrictions.md).
+
+## Security and networking
+
+Connectors can be installed anywhere on the network that allows them to send requests to the Application Proxy service. What's important is that the computer running the connector also has access to your apps. You can install connectors inside of your corporate network or on a virtual machine that runs in the cloud. Connectors can run within a perimeter network, also known as a demilitarized zone (DMZ), but it's not necessary because all traffic is outbound so your network stays secure.
+
+Connectors only send outbound requests. The outbound traffic is sent to the Application Proxy service and to the published applications. You don't have to open inbound ports because traffic flows both ways once a session is established. You also don't have to configure inbound access through your firewalls.
+
+For more information about configuring outbound firewall rules, see [Work with existing on-premises proxy servers](../manage-apps/application-proxy-configure-connectors-with-proxy-servers.md).
+
+## Performance and scalability
+
+Scale for the Application Proxy service is transparent, but scale is a factor for connectors. You need to have enough connectors to handle peak traffic. Since connectors are stateless, they aren't affected by the number of users or sessions. Instead, they respond to the number of requests and their payload size. With standard web traffic, an average machine can handle a couple thousand requests per second. The specific capacity depends on the exact machine characteristics.
+
+The connector performance is bound by CPU and networking. CPU performance is needed for TLS encryption and decryption, while networking is important to get fast connectivity to the applications and the online service in Azure.
+
+In contrast, memory is less of an issue for connectors. The online service takes care of much of the processing and all unauthenticated traffic. Everything that can be done in the cloud is done in the cloud.
+
+If for any reason that connector or machine becomes unavailable, the traffic will start going to another connector in the group. This resiliency is also why we recommend having multiple connectors.
+
+Another factor that affects performance is the quality of the networking between the connectors, including:
+
+- **The online service**: Slow or high-latency connections to the Application Proxy service in Azure influence the connector performance. For the best performance, connect your organization to Azure with Express Route. Otherwise, have your networking team ensure that connections to Azure are handled as efficiently as possible.
+- **The backend applications**: In some cases, there are additional proxies between the connector and the backend applications that can slow or prevent connections. To troubleshoot this scenario, open a browser from the connector server and try to access the application. If you run the connectors in Azure but the applications are on-premises, the experience might not be what your users expect.
+- **The domain controllers**: If the connectors perform single sign-on (SSO) using Kerberos Constrained Delegation, they contact the domain controllers before sending the request to the backend. The connectors have a cache of Kerberos tickets, but in a busy environment the responsiveness of the domain controllers can affect performance. This issue is more common for connectors that run in Azure but communicate with domain controllers that are on-premises.
+
+For more information about optimizing your network, see [Network topology considerations when using Azure Active Directory Application Proxy](application-proxy-network-topology.md).
+
+## Domain joining
+
+Connectors can run on a machine that is not domain-joined. However, if you want single sign-on (SSO) to applications that use Integrated Windows Authentication (IWA), you need a domain-joined machine. In this case, the connector machines must be joined to a domain that can perform [Kerberos](https://web.mit.edu/kerberos) Constrained Delegation on behalf of the users for the published applications.
+
+Connectors can also be joined to domains in forests that have a partial trust, or to read-only domain controllers.
+
+## Connector deployments on hardened environments
+
+Usually, connector deployment is straightforward and requires no special configuration. However, there are some unique conditions that should be considered:
+
+- Organizations that limit the outbound traffic must [open required ports](application-proxy-add-on-premises-application.md#prepare-your-on-premises-environment).
+- FIPS-compliant machines might be required to change their configuration to allow the connector processes to generate and store a certificate.
+- Organizations that lock down their environment based on the processes that issue the networking requests have to make sure that both connector services are enabled to access all required ports and IPs.
+- In some cases, outbound forward proxies may break the two-way certificate authentication and cause the communication to fail.
+
+## Connector authentication
+
+To provide a secure service, connectors have to authenticate toward the service, and the service has to authenticate toward the connector. This authentication is done using client and server certificates when the connectors initiate the connection. This way the administratorΓÇÖs username and password are not stored on the connector machine.
+
+The certificates used are specific to the Application Proxy service. They get created during the initial registration and are automatically renewed by the connectors every couple of months.
+
+After the first successful certificate renewal the Azure AD Application Proxy Connector service (Network Service) has no permission to remove the old certificate from the local machine store. If the certificate has expired or it won't be used by the service anymore, you can delete it safely.
+
+To avoid problems with the certificate renewal, ensure that the network communication from the connector towards the [documented destinations](./application-proxy-add-on-premises-application.md#prepare-your-on-premises-environment) is enabled.
+
+If a connector is not connected to the service for several months, its certificates may be outdated. In this case, uninstall and reinstall the connector to trigger registration. You can run the following PowerShell commands:
+
+```
+Import-module AppProxyPSModule
+Register-AppProxyConnector -EnvironmentName "AzureCloud"
+```
+
+For government, use `-EnvironmentName "AzureUSGovernment"`. For more details, see [Install Agent for the Azure Government Cloud](../hybrid/reference-connect-government-cloud.md#install-the-agent-for-the-azure-government-cloud).
+
+To learn more about how to verify the certificate and troubleshoot problems see [Verify Machine and backend components support for Application Proxy trust certificate](../manage-apps/application-proxy-connector-installation-problem.md#verify-machine-and-backend-components-support-for-application-proxy-trust-certificate).
+
+## Under the hood
+
+Connectors are based on Windows Server Web Application Proxy, so they have most of the same management tools including Windows Event Logs
+
+![Manage event logs with the Event Viewer](./media/application-proxy-connectors/event-view-window.png)
+
+and Windows performance counters.
+
+![Add counters to the connector with the Performance Monitor](./media/application-proxy-connectors/performance-monitor.png)
+
+The connectors have both **Admin** and **Session** logs. The **Admin** log includes key events and their errors. The **Session** log includes all the transactions and their processing details.
+
+To see the logs, open **Event Viewer** and go to **Applications and Services Logs** > **Microsoft** > **AadApplicationProxy** > **Connector**. To make the **Session** log visible, on the **View** menu, select **Show Analytic and Debug Logs**. The **Session** log is typically used for troubleshooting, and it's disabled by default. Enable it to start collecting events and disable it when it's no longer needed.
+
+You can examine the state of the service in the Services window. The connector is made up of two Windows
+
+ ![Example: Services window showing Azure AD services local](./media/application-proxy-connectors/aad-connector-services.png)
+
+## Next steps
+
+- [Publish applications on separate networks and locations using connector groups](application-proxy-connector-groups.md)
+- [Work with existing on-premises proxy servers](../manage-apps/application-proxy-configure-connectors-with-proxy-servers.md)
+- [Troubleshoot Application Proxy and connector errors](../manage-apps/application-proxy-troubleshoot.md)
+- [How to silently install the Azure AD Application Proxy Connector](../manage-apps/application-proxy-register-connector-powershell.md)
active-directory Application Proxy Debug Apps https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-debug-apps.md
+
+ Title: Debug Application Proxy applications - Azure Active Directory
+description: Debug issues with Azure Active Directory (Azure AD) Application Proxy applications.
+++++++ Last updated : 04/27/2021++++
+# Debug Application Proxy application issues
+
+This article helps you troubleshoot issues with Azure Active Directory (Azure AD) Application Proxy applications. If you're using the Application Proxy service for remote access to an on-premises web application, but you're having trouble connecting to the application, use this flowchart to debug application issues.
+
+## Before you begin
+
+When troubleshooting Application Proxy issues, we recommend you start with the connectors. First, follow the troubleshooting flow in [Debug Application Proxy Connector issues](application-proxy-debug-connectors.md) to make sure Application Proxy connectors are configured correctly. If you're still having issues, return to this article to troubleshoot the application.
+
+For more information about Application Proxy, see:
+
+- [Remote access to on-premises applications through Application Proxy](application-proxy.md)
+- [Application Proxy connectors](application-proxy-connectors.md)
+- [Install and register a connector](application-proxy-add-on-premises-application.md)
+- [Troubleshoot Application Proxy problems and error messages](application-proxy-troubleshoot.md)
+
+## Flowchart for application issues
+
+This flowchart walks you through the steps for debugging some of the more common issues with connecting to the application. For details about each step, see the table following the flowchart.
+
+![Flowchart showing steps for debugging an application](media/application-proxy-debug-apps/application-proxy-apps-debugging-flowchart.png)
+
+| Step | Action | Description |
+||||
+|1 | Open a browser, access the app, and enter your credentials | Try using your credentials to sign in to the app, and check for any user-related errors, like [This corporate app can't be accessed](application-proxy-sign-in-bad-gateway-timeout-error.md). |
+|2 | Verify user assignment to the app | Make sure your user account has permission to access the app from inside the corporate network, and then test signing in to the app by following the steps in [Test the application](application-proxy-add-on-premises-application.md#test-the-application). If sign-in issues persist, see [How to troubleshoot sign-in errors](../reports-monitoring/concept-provisioning-logs.md?context=azure/active-directory/manage-apps/context/manage-apps-context). |
+|3 | Open a browser and try to access the app | If an error appears immediately, check to see that Application Proxy is configured correctly. For details about specific error messages, see [Troubleshoot Application Proxy problems and error messages](application-proxy-troubleshoot.md). |
+|4 | Check your custom domain setup or troubleshoot the error | If the page doesn't display at all, make sure your custom domain is configured correctly by reviewing [Working with custom domains](application-proxy-configure-custom-domain.md).<br></br>If the page doesn't load and an error message appears, troubleshoot the error by referring to [Troubleshoot Application Proxy problems and error messages](application-proxy-troubleshoot.md). <br></br>If it takes longer than 20 seconds for an error message to appear, there could be connectivity issue. Go to the [Debug Application Proxy connectors](application-proxy-debug-connectors.md) troubleshooting article. |
+|5 | If issues persist, go to connector debugging | There could be a connectivity issue between the proxy and the connector or between the connector and the back end. Go to the [Debug Application Proxy connectors](application-proxy-debug-connectors.md) troubleshooting article. |
+|6 | Publish all resources, check browser developer tools, and fix links | Make sure the publishing path includes all the necessary images, scripts, and style sheets for your application. For details, see [Add an on-premises app to Azure AD](application-proxy-add-on-premises-application.md#add-an-on-premises-app-to-azure-ad). <br></br>Use the browser's developer tools (F12 tools in Internet Explorer or Microsoft Edge) and check for publishing issues as described in [Application page does not display correctly](application-proxy-page-appearance-broken-problem.md). <br></br>Review options for resolving broken links in [Links on the page don't work](application-proxy-page-links-broken-problem.md). |
+|7 | Check for network latency | If the page loads slowly, learn about ways to minimize network latency in [Considerations for reducing latency](application-proxy-network-topology.md#considerations-for-reducing-latency). |
+|8 | See additional troubleshooting help | If issues persist, find additional troubleshooting articles in the [Application Proxy troubleshooting documentation](application-proxy-troubleshoot.md). |
+
+## Next steps
++
+* [Publish applications on separate networks and locations using connector groups](application-proxy-connector-groups.md)
+* [Work with existing on-premises proxy servers](application-proxy-configure-connectors-with-proxy-servers.md)
+* [Troubleshoot Application Proxy and connector errors](application-proxy-troubleshoot.md)
+* [How to silently install the Azure AD Application Proxy Connector](application-proxy-register-connector-powershell.md)
active-directory Application Proxy Debug Connectors https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-debug-connectors.md
+
+ Title: Debug Application Proxy connectors - Azure Active Directory
+description: Debug issues with Azure Active Directory (Azure AD) Application Proxy connectors.
+++++++ Last updated : 04/27/2021++++
+# Debug Application Proxy connector issues
+
+This article helps you troubleshoot issues with Azure Active Directory (Azure AD) Application Proxy connectors. If you're using the Application Proxy service for remote access to an on-premises web application, but you're having trouble connecting to the application, use this flowchart to debug connector issues.
+
+## Before you begin
+
+This article assumes you have installed the Application Proxy connector and are having an issue. When troubleshooting Application Proxy issues, we recommend you start with this troubleshooting flow to determine if Application Proxy connectors are configured correctly. If you're still having trouble connecting to the application, follow the troubleshooting flow in [Debug Application Proxy application issues](application-proxy-debug-apps.md).
++
+For more information about Application Proxy and using its connectors, see:
+
+- [Remote access to on-premises applications through Application Proxy](application-proxy.md)
+- [Application Proxy connectors](application-proxy-connectors.md)
+- [Install and register a connector](application-proxy-add-on-premises-application.md)
+- [Troubleshoot Application Proxy problems and error messages](application-proxy-troubleshoot.md)
+
+## Flowchart for connector issues
+
+This flowchart walks you through the steps for debugging some of the more common connector issues. For details about each step, see the table following the flowchart.
+
+![Flowchart showing steps for debugging a connector](media/application-proxy-debug-connectors/application-proxy-connector-debugging-flowchart.png)
+
+| Step | Action | Description |
+||||
+|1 | Find the connector group assigned to the app | You probably have a connector installed on multiple servers, in which case the connectors should be [assigned to connector groups](application-proxy-connector-groups.md#assign-applications-to-your-connector-groups). To learn more about connector groups, see [Publish applications on separate networks and locations using connector groups](application-proxy-connector-groups.md). |
+|2 | Install the connector and assign a group | If you don't have a connector installed, see [Install and register a connector](application-proxy-add-on-premises-application.md#install-and-register-a-connector).<br></br> If you are having issues installing the connector, see [Problem installing the Connector](application-proxy-connector-installation-problem.md).<br></br> If the connector isn't assigned to a group, see [Assign the connector to a group](application-proxy-connector-groups.md#create-connector-groups).<br></br>If the application isn't assigned to a connector group, see [Assign the application to a connector group](application-proxy-connector-groups.md#assign-applications-to-your-connector-groups).|
+|3 | Run a port test on the connector server | On the connector server, run a port test by using [telnet](/windows-server/administration/windows-commands/telnet) or other port testing tool to check if ports [443 and 80 are open](application-proxy-add-on-premises-application.md#open-ports).|
+|4 | Configure the domains and ports | [Make sure that your domains and ports are configured correctly](application-proxy-add-on-premises-application.md#prepare-your-on-premises-environment) For the connector to work properly, there are certain ports that must be open and URLs that your server must be able to access. |
+|5 | Check if a back-end proxy is in use | Check to see if the connectors are using back-end proxy servers or bypassing them. For details, see [Troubleshoot connector proxy problems and service connectivity issues](application-proxy-configure-connectors-with-proxy-servers.md#troubleshoot-connector-proxy-problems-and-service-connectivity-issues). |
+|6 | Update the connector and updater to use the back-end proxy | If a back-end proxy is in use, you'll want to make sure the connector is using the same proxy. For details about troubleshooting and configuring connectors to work with proxy servers, see [Work with existing on-premises proxy servers](application-proxy-configure-connectors-with-proxy-servers.md). |
+|7 | Load the app's internal URL on the connector server | On the connector server, load the app's internal URL. |
+|8 | Check internal network connectivity | There's a connectivity issue in your internal network that this debugging flow is unable to diagnose. The application must be accessible internally for the connectors to work. You can enable and view connector event logs as described in [Application Proxy connectors](application-proxy-connectors.md#under-the-hood). |
+|9 | Lengthen the time-out value on the back end | In the **Additional Settings** for your application, change the **Backend Application Timeout** setting to **Long**. See [Add an on-premises app to Azure AD](application-proxy-add-on-premises-application.md#add-an-on-premises-app-to-azure-ad). |
+|10 | If issues persist, target specific flow issues, review app and SSO debugging flows | Use the [Debug Application Proxy application issues](application-proxy-debug-apps.md) troubleshooting flow. |
+
+## Next steps
++
+* [Publish applications on separate networks and locations using connector groups](application-proxy-connector-groups.md)
+* [Work with existing on-premises proxy servers](application-proxy-configure-connectors-with-proxy-servers.md)
+* [Troubleshoot Application Proxy and connector errors](application-proxy-troubleshoot.md)
+* [How to silently install the Azure AD Application Proxy Connector](application-proxy-register-connector-powershell.md)
active-directory Application Proxy Deployment Plan https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-deployment-plan.md
+
+ Title: Plan an Azure Active Directory Application Proxy Deployment
+description: An end-to-end guide for planning the deployment of Application proxy within your organization
+++++++ Last updated : 04/27/2021+++
+# Plan an Azure AD Application Proxy deployment
+
+Azure Active Directory (Azure AD) Application Proxy is a secure and cost-effective remote access solution for on-premises applications. It provides an immediate transition path for ΓÇ£Cloud FirstΓÇ¥ organizations to manage access to legacy on-premises applications that arenΓÇÖt yet capable of using modern protocols. For additional introductory information, see [What is Application Proxy](./application-proxy.md).
+
+Application Proxy is recommended for giving remote users access to internal resources. Application Proxy replaces the need for a VPN or reverse proxy for these remote access use cases. It is not intended for users who are on the corporate network. These users who use Application Proxy for intranet access may experience undesirable performance issues.
+
+This article includes the resources you need to plan, operate, and manage Azure AD Application Proxy.
+
+## Plan your implementation
+
+The following section provides a broad view of the key planning elements that will set you up for an efficient deployment experience.
+
+### Prerequisites
+
+You need to meet the following prerequisites before beginning your implementation. You can see more information on setting up your environment, including these prerequisites, in this [tutorial](application-proxy-add-on-premises-application.md).
+
+* **Connectors**: Connectors are lightweight agents that you can deploy onto:
+ * Physical hardware on-premises
+ * A VM hosted within any hypervisor solution
+ * A VM hosted in Azure to enable outbound connection to the Application Proxy service.
+
+* See [Understand Azure AD App Proxy Connectors](application-proxy-connectors.md) for a more detailed overview.
+
+ * Connector machines must [be enabled for TLS 1.2](application-proxy-add-on-premises-application.md) before installing the connectors.
+
+ * If possible, deploy connectors in the [same network](application-proxy-network-topology.md) and segment as the back-end web application servers. It's best to deploy connectors after you complete a discovery of applications.
+ * We recommend that each connector group has at least two connectors to provide high availability and scale. Having three connectors is optimal in case you may need to service a machine at any point. Review the [connector capacity table](./application-proxy-connectors.md#capacity-planning) to help with deciding what type of machine to install connectors on. The larger the machine the more buffer and performant the connector will be.
+
+* **Network access settings**: Azure AD Application Proxy connectors [connect to Azure via HTTPS (TCP Port 443) and HTTP (TCP Port 80)](application-proxy-add-on-premises-application.md).
+
+ * Terminating connector TLS traffic isn't supported and will prevent connectors from establishing a secure channel with their respective Azure App Proxy endpoints.
+
+ * Avoid all forms of inline inspection on outbound TLS communications between connectors and Azure. Internal inspection between a connector and backend applications is possible, but could degrade the user experience, and as such, isn't recommended.
+
+ * Load balancing of the connectors themselves is also not supported, or even necessary.
+
+### Important considerations before configuring Azure AD Application Proxy
+
+The following core requirements must be met in order to configure and implement Azure AD Application Proxy.
+
+* **Azure onboarding**: Before deploying application proxy, user identities must be synchronized from an on-premises directory or created directly within your Azure AD tenants. Identity synchronization allows Azure AD to pre-authenticate users before granting them access to App Proxy published applications and to have the necessary user identifier information to perform single sign-on (SSO).
+
+* **Conditional Access requirements**: We do not recommend using Application Proxy for intranet access because this adds latency that will impact users. We recommend using Application Proxy with pre-authentication and Conditional Access policies for remote access from the internet. An approach to provide Conditional Access for intranet use is to modernize applications so they can directly authenticate with AAD. Refer to [Resources for migrating applications to AAD](../manage-apps/migration-resources.md) for more information.
+
+* **Service limits**: To protect against overconsumption of resources by individual tenants there are throttling limits set per application and tenant. To see these limits refer to [Azure AD service limits and restrictions](../enterprise-users/directory-service-limits-restrictions.md). These throttling limits are based on a benchmark far above typical usage volume and provides ample buffer for a majority of deployments.
+
+* **Public certificate**: If you are using custom domain names, you must procure a TLS/SSL certificate. Depending on your organizational requirements, getting a certificate can take some time and we recommend beginning the process as early as possible. Azure Application Proxy supports standard, [wildcard](application-proxy-wildcard.md), or SAN-based certificates. For more details see [Configure custom domains with Azure AD Application Proxy](application-proxy-configure-custom-domain.md).
+
+* **Domain requirements**: Single sign-on to your published applications using Kerberos Constrained Delegation (KCD) requires that the server running the Connector and the server running the app are domain joined and part of the same domain or trusting domains.
+For detailed information on the topic, see [KCD for single sign-on](application-proxy-configure-single-sign-on-with-kcd.md) with Application Proxy. The connector service runs in the context of the local system and should not be configured to use a custom identity.
+
+* **DNS records for URLs**
+
+ * Before using custom domains in Application Proxy you must create a CNAME record in public DNS, allowing clients to resolve the custom defined external URL to the pre-defined Application Proxy address. Failing to create a CNAME record for an application that uses a custom domain will prevent remote users from connecting to the application. Steps required to add CNAME records can vary from DNS provider to provider, so learn how to [manage DNS records and record sets by using the Azure portal](../../dns/dns-operations-recordsets-portal.md).
+
+ * Similarly, connector hosts must be able to resolve the internal URL of applications being published.
+
+* **Administrative rights and roles**
+
+ * **Connector installation** requires local admin rights to the Windows server that it's being installed on. It also requires a minimum of an *Application Administrator* role to authenticate and register the connector instance to your Azure AD tenant.
+
+ * **Application publishing and administration** require the *Application Administrator* role. Application Administrators can manage all applications in the directory including registrations, SSO settings, user and group assignments and licensing, Application Proxy settings, and consent. It doesn't grant the ability to manage Conditional Access. The *Cloud Application Administrator* role has all the abilities of the Application Administrator, except that it does not allow management of Application Proxy settings.
+
+* **Licensing**: Application Proxy is available through an Azure AD Premium subscription. Refer to the [Azure Active Directory Pricing page](https://azure.microsoft.com/pricing/details/active-directory/) for a full list of licensing options and features.
+
+### Application Discovery
+
+Compile an inventory of all in-scope applications that are being published via Application Proxy by collecting the following information:
+
+| Information Type| Information to collect |
+|||
+| Service Type| For example: SharePoint, SAP, CRM, Custom Web Application, API |
+| Application platform | For example: Windows IIS, Apache on Linux, Tomcat, NGINX |
+| Domain membership| Web serverΓÇÖs fully qualified domain name (FQDN) |
+| Application location | Where the web server or farm is located in your infrastructure |
+| Internal access | The exact URL used when accessing the application internally. <br> If a farm, what type of load balancing is in use? <br> Whether the application draws content from sources other than itself.<br> Determine if the application operates over WebSockets. |
+| External access | The vendor solution that the application is already exposed to externally. <br> The URL you want to use for external access. If SharePoint, ensure Alternate Access Mappings are configured per [this guidance](/SharePoint/administration/configure-alternate-access-mappings). If not, you will need to define external URLs. |
+| Public certificate | If using a custom domain, procure a certificate with a corresponding subject name. if a certificate exists note the serial number and location from where it can be obtained. |
+| Authentication type| The type of authentication supported by the application support such as Basic, Windows Integration Authentication, forms-based, header-based, and claims. <br>If the application is configured to run under a specific domain account, note the Fully Qualified Domain Name (FQDN) of the service account.<br> If SAML-based, the identifier and reply URLs. <br> If header-based, the vendor solution and specific requirement for handling authentication type. |
+| Connector group name | The logical name for the group of connectors that will be designated to provide the conduit and SSO to this backend application. |
+| Users/Groups access | The users or user groups that will be granted external access to the application. |
+| Additional requirements | Note any additional remote access or security requirements that should be factored into publishing the application. |
+
+You can download this [application inventory spreadsheet](https://aka.ms/appdiscovery) to inventory your apps.
+
+### Define organizational requirements
+
+The following are areas for which you should define your organizationΓÇÖs business requirements. Each area contains examples of requirements
+
+ **Access**
+
+* Remote users with domain joined or Azure AD joined devices users can access published applications securely with seamless single sign-on (SSO).
+
+* Remote users with approved personal devices can securely access published applications provided they are enrolled in MFA and have registered the Microsoft Authenticator app on their mobile phone as an authentication method.
+
+**Governance**
+
+* Administrators can define and monitor the lifecycle of user assignments to applications published through Application Proxy.
+
+**Security**
+
+* Only users assigned to applications via group membership or individually can access those applications.
+
+**Performance**
+
+* There is no degradation of application performance compared to accessing application from the internal network.
+
+**User Experience**
+
+* Users are aware of how to access their applications by using familiar company URLs on any device platform.
+
+**Auditing**
+* Administrators are able to audit user access activity.
++
+### Best practices for a pilot
+
+Determine the amount of time and effort needed to fully commission a single application for remote access with Single sign-on (SSO). Do so by running a pilot that considers its initial discovery, publishing, and general testing. Using a simple IIS-based web application that is already preconfigured for Integrated Windows Authentication (IWA) would help establish a baseline, as this setup requires minimal effort to successfully pilot remote access and SSO.
+
+The following design elements should increase the success of your pilot implementation directly in a production tenant.
+
+**Connector management**:
+
+* Connectors play a key role in providing the on-premises conduit to your applications. Using the **Default** connector group is adequate for initial pilot testing of published applications before commissioning them into production. Successfully tested applications can then be moved to production connector groups.
+
+**Application management**:
+
+* Your workforce is most likely to remember an external URL is familiar and relevant. Avoid publishing your application using our pre-defined msappproxy.net or onmicrosoft.com suffixes. Instead, provide a familiar top-level verified domain, prefixed with a logical hostname such as *intranet.<customers_domain>.com*.
+
+* Restrict visibility of the pilot applicationΓÇÖs icon to a pilot group by hiding its launch icon form the Azure MyApps portal. When ready for production you can scope the app to its respective targeted audience, either in the same pre-production tenant, or by also publishing the application in your production tenant.
+
+**Single sign-on settings**:
+Some SSO settings have specific dependencies that can take time to set up, so avoid change control delays by ensuring dependencies are addressed ahead of time. This includes domain joining connector hosts to perform SSO using Kerberos Constrained Delegation (KCD) and taking care of other time-consuming activities. For example, Setting up a PING Access instance, if needing header-based SSO.
+
+**TLS Between Connector Host and Target Application**: Security is paramount, so TLS between the connector host and target applications should always be used. Particularly if the web application is configured for forms-based authentication (FBA), as user credentials are then effectively transmitted in clear text.
+
+**Implement incrementally and test each step**.
+Conduct basic functional testing after publishing an application to ensure that all user and business requirements are met by following the directions below:
+
+1. Test and validate general access to the web application with pre-authentication disabled.
+2. If successful enable pre-authentication and assign users and groups. Test and validate access.
+3. Then add the SSO method for your application and test again to validate access.
+4. Apply Conditional Access and MFA policies as required. Test and validate access.
+
+**Troubleshooting Tools**: When troubleshooting, always start by validating access to the published application from the browser on the connector host, and confirm that the application functions as expected. The simpler your setup, the easier to determine root cause, so consider trying to reproduce issues with a minimal configuration such as using only a single connector and no SSO. In some cases, web debugging tools such as TelerikΓÇÖs Fiddler can prove indispensable to troubleshoot access or content issues in applications accessed through a proxy. Fiddler can also act as a proxy to help trace and debug traffic for mobile platforms such as iOS and Android, and virtually anything that can be configured to route via a proxy. See the [troubleshooting guide](application-proxy-troubleshoot.md) for more information.
+
+## Implement Your Solution
+
+### Deploy Application Proxy
+
+The steps to deploy your Application Proxy are covered in this [tutorial for adding an on-premises application for remote access](application-proxy-add-on-premises-application.md). If the installation isn't successful, select **Troubleshoot Application Proxy** in the portal or use the troubleshooting guide [for Problems with installing the Application Proxy Agent Connector](application-proxy-connector-installation-problem.md).
+
+### Publish applications via Application Proxy
+
+Publishing applications assumes that you have satisfied all the pre-requisites and that you have several connectors showing as registered and active in the Application Proxy page.
+
+You can also publish applications by using [PowerShell](/powershell/module/azuread/?view=azureadps-2.0-preview&preserve-view=true).
+
+Below are some best practices to follow when publishing an application:
+
+* **Use Connector Groups**: Assign a connector group that has been designated for publishing each respective application. We recommend that each connector group has at least two connectors to provide high availability and scale. Having three connectors is optimal in case you may need to service a machine at any point. Additionally, see [Publish applications on separate networks and locations using connector groups](application-proxy-connector-groups.md) to see how you can also use connector groups to segment your connectors by network or location.
+
+* **Set Backend Application Timeout**: This setting is useful in scenarios where the application might require more than 75 seconds to process a client transaction. For example when a client sends a query to a web application that acts as a front end to a database. The front end sends this query to its back-end database server and waits for a response, but by the time it receives a response, the client side of the conversation times out. Setting the timeout to Long provides 180 seconds for longer transactions to complete.
+
+* **Use Appropriate Cookie Types**
+
+ * **HTTP-Only Cookie**: Provides additional security by having Application Proxy include the HTTPOnly flag in set-cookie HTTP response headers. This setting helps to mitigate exploits such as cross-site scripting (XSS). Leave this set to No for clients/user agents that do require access to the session cookie. For example, RDP/MTSC client connecting to a Remote Desktop Gateway published via App Proxy.
+
+ * **Secure Cookie**: When a cookie is set with the Secure attribute, the user agent (Client-side app) will only include the cookie in HTTP requests if the request is transmitted over a TLS secured channel. This helps mitigate the risk of a cookie being compromised over clear text channels, so should be enabled.
+
+ * **Persistent Cookie**: Allows the Application Proxy session cookie to persist between browser closures by remaining valid until it either expires or is deleted. Used for scenarios where a rich application such as office accesses a document within a published web application, without the user being re-prompted for authentication. Enable with caution however, as persistent cookies can ultimately leave a service at risk of unauthorized access, if not used in conjunction with other compensating controls. This setting should only be used 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 this setting.
+
+* **Translate URLs in Headers**: You enable this for scenarios where internal DNS cannot be configured to match the organizationΓÇÖs public namespace(a.k.a Split DNS). Unless your application requires the original host header in the client request, leave this value set to Yes. The alternative is to have the connector use the FQDN in the internal URL for routing of the actual traffic, and the FQDN in the external URL, as the host-header. In most cases this alternative should allow the application to function as normal, when accessed remotely, but your users lose the benefits of having a matching inside & outside URL.
+
+* **Translate URLs in Application Body**: Turn on Application Body link translation for an app when you want the links from that app to be translated in responses back to the client. If enabled, this function provides a best effort attempt at translating all internal links that App Proxy finds in HTML and CSS responses being returned to clients. It is useful when publishing apps that contain either hard-coded absolute or NetBIOS shortname links in the content, or apps with content that links to other on-premises applications.
+
+For scenarios where a published app links to other published apps, enable link translation for each application so that you have control over the user experience at the per-app level.
+
+For example, suppose that you have three applications published through Application Proxy that all link to each other: Benefits, Expenses, and Travel, plus a fourth app, Feedback, that isn't published through Application Proxy.
+
+![Picture 1](media/App-proxy-deployment-plan/link-translation.png)
+
+When you enable link translation for the Benefits app, the links to Expenses and Travel are redirected to the external URLs for those apps, so that users accessing the applications from outside the corporate network can access them. Links from Expenses and Travel back to Benefits don't work because link translation hasn't been enabled for those two apps. The link to Feedback isn't redirected because there's no external URL, so users using the Benefits app won't be able to access the feedback app from outside the corporate network. See detailed information on [link translation and other redirect options](application-proxy-configure-hard-coded-link-translation.md).
+
+### Access your application
+
+Several options exist for managing access to App Proxy published resources, so choose the most appropriate for your given scenario and scalability needs. Common approaches include: using on-premises groups that are being synced via Azure AD Connect, creating Dynamic Groups in Azure AD based on user attributes, using self-service groups that are managed by a resource owner, or a combination of all of these. See the linked resources for the benefits of each.
+
+The most straight forward way of assigning users access to an application is going into the **Users and Groups** options from the left-hand pane of your published application and directly assigning groups or individuals.
+
+![Picture 24](media/App-proxy-deployment-plan/add-user.png)
+
+You can also allow users to self-service access to your application by assigning a group that they aren't currently a member of and configuring the self-serve options.
+
+![Picture 25](media/App-proxy-deployment-plan/allow-access.png)
+
+If enabled, users will then be able to log into the MyApps portal and request access, and either be auto approved and added to the already permitted self-service group, or need approval from a designated approver.
+
+Guest users can also be [invited to access internal applications published via Application Proxy through Azure AD B2B](../external-identities/add-users-information-worker.md).
+
+For on premises applications that are normally accessible anonymously, requiring no authentication, you may prefer to disable the option located in the applicationΓÇÖs **Properties**.
+
+![Picture 26](media/App-proxy-deployment-plan/assignment-required.png)
++
+Leaving this option set to No allows users to access the on-premises application via Azure AD App Proxy without permissions, so use with caution.
+
+Once your application is published, it should be accessible by typing its external URL in a browser or by its icon at [https://myapps.microsoft.com](https://myapps.microsoft.com/).
+
+### Enable pre-authentication
+
+Verify that your application is accessible through Application Proxy accessing it via the external URL.
+
+1. Navigate to **Azure Active Directory** > **Enterprise applications** > **All applications** and choose the app you want to manage.
+
+2. Select **Application Proxy**.
+
+3. In the **Pre-Authentication** field, use the dropdown list to select **Azure Active Directory**, and select **Save**.
+
+With pre-authentication enabled, Azure AD will challenge users first for authentication and if single sign-on is configured then the back-end application will also verify the user before access to the application is granted. Changing the pre-authentication mode from Passthrough to Azure AD also configures the external URL with HTTPS, so any application initially configured for HTTP will now be secured with HTTPS.
+
+### Enable Single Sign-On
+
+SSO provides the best possible user experience and security because users only need to sign in once when accessing Azure AD. Once a user has pre-authenticated, SSO is performed by the Application Proxy connector authenticating to the on-premises application, on behalf of the user. The backend application processes the login as if it were the user themselves.
+
+Choosing the **Passthrough** option allows users to access the published application without ever having to authenticate to Azure AD.
+
+Performing SSO is only possible if Azure AD can identify the user requesting access to a resource, so your application must be configured to pre-authenticate users with Azure AD upon access for SSO to function, otherwise the SSO options will be disabled.
+
+Read [Single sign-on to applications in Azure AD](../manage-apps/what-is-single-sign-on.md) to help you choose the most appropriate SSO method when configuring your applications.
+
+### Working with other types of applications
+
+Azure AD Application Proxy can also support applications that have been developed to use the [Microsoft Authentication Library (MSAL)](../develop/v2-overview.md). It supports native client apps by consuming Azure AD issued tokens received in the header information of client request to perform pre-authentication on behalf of the users.
+
+Read [publishing native and mobile client apps](./application-proxy-configure-native-client-application.md) and [claims-based applications](./application-proxy-configure-for-claims-aware-applications.md) to learn about available configurations of Application Proxy.
+
+### Use Conditional Access to strengthen security
+
+Application security requires an advanced set of security capabilities that can protect from and respond to complex threats on-premises and in the cloud. Attackers most often gain corporate network access through weak, default, or stolen user credentials. Microsoft identity-driven security reduces use of stolen credentials by managing and protecting both privileged and non-privileged identities.
+
+The following capabilities can be used to support Azure AD Application Proxy:
+
+* User and location-based Conditional Access: Keep sensitive data protected by limiting user access based on geo-location or an IP address with [location-based Conditional Access policies](../conditional-access/location-condition.md).
+
+* Device-based Conditional Access: Ensure only enrolled, approved, and compliant devices can access corporate data with [device-based Conditional Access](../conditional-access/require-managed-devices.md).
+
+* Application-based Conditional Access: Work doesn't have to stop when a user isn't on the corporate network. [Secure access to corporate cloud and on-premises apps](../conditional-access/app-based-conditional-access.md) and maintain control with Conditional Access.
+
+* Risk-based Conditional Access: Protect your data from malicious hackers with a [risk-based Conditional Access policy](https://www.microsoft.com/cloud-platform/conditional-access) that can be applied to all apps and all users, whether on-premises or in the cloud.
+
+* Azure AD My Apps: With your Application Proxy service deployed, and applications securely published, offer your users a simple hub to discover and access all their applications. Increase productivity with self-service capabilities, such as the ability to request access to new apps and groups or manage access to these resources on behalf of others, through [My Apps](https://aka.ms/AccessPanelDPDownload).
+
+## Manage your implementation
+
+### Required roles
+
+Microsoft advocates the principle of granting the least possible privilege to perform needed tasks with Azure AD. [Review the different Azure roles that are available](../roles/permissions-reference.md) and choose the right one to address the needs of each persona. Some roles may need to be applied temporarily and removed after the deployment is completed.
+
+| Business role| Business tasks| Azure AD roles |
+||||
+| Help desk admin | Typically limited to qualifying end user reported issues and performing limited tasks such as changing usersΓÇÖ passwords, invalidating refresh tokens, and monitoring service health. | Helpdesk Administrator |
+| Identity admin| Read Azure AD sign in reports and audit logs to debug App Proxy related issues.| Security reader |
+| Application owner| Create and manage all aspects of enterprise applications, application registrations, and application proxy settings.| Application Admin |
+| Infrastructure admin | Certificate Rollover Owner | Application Admin |
+
+Minimizing the number of people who have access to secure information or resources will help in reducing the chance of a malicious actor obtaining unauthorized access, or an authorized user inadvertently impacting a sensitive resource.
+
+However, users still need to carry out day to day privileged operations, so enforcing just-in-time (JIT) based [Privileged Identity Management](../privileged-identity-management/pim-configure.md) policies to provide on-demand privileged access to Azure resources and Azure AD is our recommended approach towards effectively managing administrative access and auditing.
+
+### Reporting and monitoring
+
+Azure AD provides additional insights into your organizationΓÇÖs application usage and operational health through [audit logs and reports](../reports-monitoring/concept-provisioning-logs.md?context=azure/active-directory/manage-apps/context/manage-apps-context). Application Proxy also makes it very easy to monitor connectors from the Azure AD portal and Windows Event Logs.
+
+#### Application audit logs
+
+These logs provide detailed information about logins to applications configured with Application Proxy and the device and the user accessing the application. [Audit logs](../reports-monitoring/concept-provisioning-logs.md?context=azure/active-directory/manage-apps/context/manage-apps-context) are located in the Azure portal and in [Audit API](/graph/api/resources/directoryaudit) for export. Additionally, [usage and insights reports](../reports-monitoring/concept-usage-insights-report.md?context=azure/active-directory/manage-apps/context/manage-apps-context) are also available for your application.
+
+#### Application Proxy Connector monitoring
+
+The connectors and the service take care of all the high availability tasks. You can monitor the status of your connectors from the Application Proxy page in the Azure AD Portal. For more information about connector maintainence see [Understand Azure AD Application Proxy Connectors](./application-proxy-connectors.md#maintenance).
+
+![Example: Azure AD Application Proxy connectors](./media/application-proxy-connectors/app-proxy-connectors.png)
+
+#### Windows event logs and performance counters
+
+Connectors have both admin and session logs. The admin logs include key events and their errors. The session logs include all the transactions and their processing details. Logs and counters are located in Windows Event Logs for more information see [Understand Azure AD Application Proxy Connectors](./application-proxy-connectors.md#under-the-hood). Follow this [tutorial to configure event log data sources in Azure Monitor](../../azure-monitor/agents/data-sources-windows-events.md).
+
+### Troubleshooting guide and steps
+
+Learn more about common issues and how to resolve them with our guide to [troubleshooting](application-proxy-troubleshoot.md) error messages.
+
+The following articles cover common scenarios that can also be used to create troubleshooting guides for your support organization.
+
+* [Problem displaying app page](application-proxy-page-appearance-broken-problem.md)
+* [Application load is too long](application-proxy-page-load-speed-problem.md)
+* [Links on application page not working](application-proxy-page-links-broken-problem.md)
+* [What ports to open for my app](application-proxy-add-on-premises-application.md)
+* [No working connector in a connector group for my app](application-proxy-connectivity-no-working-connector.md)
+* [Configure in admin portal](application-proxy-config-how-to.md)
+* [Configure single sign-on to my app](application-proxy-config-sso-how-to.md)
+* [Problem creating an app in admin portal](application-proxy-config-problem.md)
+* [Configure Kerberos Constrained Delegation](application-proxy-back-end-kerberos-constrained-delegation-how-to.md)
+* [Configure with PingAccess](../manage-apps/application-proxy-ping-access-publishing-guide.md)
+* [Can't Access this Corporate Application error](application-proxy-sign-in-bad-gateway-timeout-error.md)
+* [Problem installing the Application Proxy Agent Connector](application-proxy-connector-installation-problem.md)
+* [Sign-in problem](application-sign-in-problem-on-premises-application-proxy.md)
active-directory Application Proxy High Availability Load Balancing https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-high-availability-load-balancing.md
+
+ Title: High availability and load balancing - Azure AD Application Proxy
+description: How traffic distribution works with your Application Proxy deployment. Includes tips for how to optimize connector performance and use load balancing for back-end servers.
+
+documentationcenter: ''
+++++
+ na
+ms.devlang: na
+ Last updated : 10/08/2019++++++
+# High availability and load balancing of your Application Proxy connectors and applications
+
+This article explains how traffic distribution works with your Application Proxy deployment. We'll discuss:
+
+- How traffic is distributed among users and connectors, along with tips for optimizing connector performance
+
+- How traffic flows between connectors and back-end app servers, with recommendations for load balancing among multiple back-end servers
+
+## Traffic distribution across connectors
+
+Connectors establish their connections based on principles for high availability. There's no guarantee that traffic will always be evenly distributed across connectors and there is no session affinity. However, usage varies and requests are randomly sent to Application Proxy service instances. As a result, traffic is typically distributed almost evenly across the connectors. The diagram and steps below illustrate how connections are established between users and connectors.
+
+![Diagram showing connections between users and connectors](media/application-proxy-high-availability-load-balancing/application-proxy-connections.png)
+
+1. A user on a client device tries to access an on-premises application published through Application Proxy.
+2. The request goes through an Azure Load Balancer to determine which Application Proxy service instance should take the request. Per region, there are tens of instances available to accept the request. This method helps to evenly distribute the traffic across the service instances.
+3. The request is sent to [Service Bus](../../service-bus-messaging/index.yml).
+4. Service Bus signals to an available connector. The connector then picks up the request from Service Bus.
+ - In step 2, requests go to different Application Proxy service instances, so connections are more likely to be made with different connectors. As a result, connectors are almost evenly used within the group.
+5. The connector passes the request to the applicationΓÇÖs back-end server. Then the application sends the response back to the connector.
+6. The connector completes the response by opening an outbound connection to the service instance from where the request came. Then this connection is immediately closed. By default, each connector is limited to 200 concurrent outbound connections.
+7. The response is then passed back to the client from the service instance.
+8. Subsequent requests from the same connection repeat the steps above.
+
+An application often has many resources and opens multiple connections when it's loaded. Each connection goes through the steps above to become allocated to a service instance, select a new available connector if the connection has not yet previously paired with a connector.
++
+## Best practices for high availability of connectors
+
+- Because of the way traffic is distributed among connectors for high availability, it's essential to always have at least two connectors in a connector group. Three connectors are preferred to provide additional buffer among connectors. To determine the correct number of connectors you needed, follow capacity planning documentation.
+
+- Place connectors on different outbound connections to avoid a single point of failure. If connectors use the same outbound connection, a network problem with the connection may impact all connectors using it.
+
+- Avoid forcing connectors to restart when connected to production applications. Doing so could negatively impact the distribution of traffic across connectors. Restarting connectors causes more connectors to be unavailable and forces connections to the remaining available connector. The result is an uneven use of the connectors initially.
+
+- Avoid all forms of inline inspection on outbound TLS communications between connectors and Azure. This type of inline inspection causes degradation to the communication flow.
+
+- Make sure to keep automatic updates running for your connectors. If the Application Proxy Connector Updater service is running, your connectors update automatically and receive the latest upgraded. If you donΓÇÖt see the Connector Updater service on your server, you need to reinstall your connector to get any updates.
+
+## Traffic flow between connectors and back-end application servers
+
+Another key area where high availability is a factor is the connection between connectors and the back-end servers. When an application is published through Azure AD Application Proxy, traffic from the users to the applications flows through three hops:
+
+1. The user connects to the Azure AD Application Proxy service public endpoint on Azure. The connection is established between the originating client IP address (public) of the client and the IP address of the Application Proxy endpoint.
+2. The Application Proxy connector pulls the HTTP request of the client from the Application Proxy Service.
+3. The Application Proxy connector connects to the target application. The connector uses its own IP address for establishing the connection.
+
+![Diagram of user connecting to an application via Application Proxy](media/application-proxy-high-availability-load-balancing/application-proxy-three-hops.png)
+
+### X-Forwarded-For header field considerations
+In some situations (like auditing, load balancing etc.), sharing the originating IP address of the external client with the on-premises environment is a requirement. To address the requirement, Azure AD Application Proxy connector adds the X-Forwarded-For header field with the originating client IP address (public) to the HTTP request. The appropriate network device (load balancer, firewall) or the web server or back-end application can then read and use the information.
+
+## Best practices for load balancing among multiple app servers
+When the connector group that's assigned to the Application Proxy application has two or more connectors, and youΓÇÖre running the back-end web application on multiple servers (server farm),
+a good load-balancing strategy is required. A good strategy ensures that servers pick up client requests evenly and prevents over- or under-utilization of servers in the server farm.
+### Scenario 1: Back-end application does not require session persistence
+The simplest scenario is where the back-end web application doesnΓÇÖt require session stickiness (session persistence). Any request from the user can be handled by any back-end application instance in the server farm. You can use a layer 4 load balancer and configure it with no affinity. Some options include Microsoft Network Load Balancing and Azure Load Balancer or a load balancer from another vendor. Alternatively, round-robin DNS can be configured.
+### Scenario 2: Back-end application requires session persistence
+In this scenario, the back-end web application requires session stickiness (session persistence) during the authenticated session. All requests from the user must be handled by the back-end application instance that runs on the same server in the server farm.
+This scenario can be more complicated because the client usually establishes multiple connections to the Application Proxy service. Requests over different connections might arrive at different connectors and servers in the farm. Because each connector uses its own IP address for this communication, the load balancer can't ensure session stickiness based on the IP address of the connectors. Source IP Affinity can't be used either.
+Here are some options for scenario 2:
+
+- Option 1: Base the session persistence on a session cookie set by the load balancer. This option is recommended because it allows the load to be spread more evenly among the back-end servers. It requires a layer 7 load balancer with this capability and that can handle the HTTP traffic and terminate the TLS connection. You can use Azure Application Gateway (Session Affinity) or a load balancer from another vendor.
+
+- Option 2: Base the session persistence on the X-Forwarded-For header field. This option requires a layer 7 load balancer with this capability and that can handle the HTTP traffic and terminate the TLS connection.
+
+- Option 3: Configure the back-end application to not require session persistence.
+
+Refer to your software vendor's documentation to understand the load-balancing requirements of the back-end application.
+
+## Next steps
+
+- [Enable Application Proxy](application-proxy-add-on-premises-application.md)
+- [Enable single-sign on](application-proxy-configure-single-sign-on-with-kcd.md)
+- [Enable Conditional Access](../manage-apps/application-proxy-integrate-with-sharepoint-server.md)
+- [Troubleshoot issues you're having with Application Proxy](application-proxy-troubleshoot.md)
+- [Learn how Azure AD architecture supports high availability](../fundamentals/active-directory-architecture.md)
active-directory Application Proxy Integrate With Remote Desktop Services https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-integrate-with-remote-desktop-services.md
+
+ Title: Publish Remote Desktop with Azure Active Directory Application Proxy
+description: Covers how to configure App Proxy with Remote Desktop Services (RDS)
+++++++ Last updated : 04/27/2021++++
+# Publish Remote Desktop with Azure Active Directory Application Proxy
+
+Remote Desktop Service and Azure AD Application Proxy work together to improve the productivity of workers who are away from the corporate network.
+
+The intended audience for this article is:
+- Current Application Proxy customers who want to offer more applications to their end users by publishing on-premises applications through Remote Desktop Services.
+- Current Remote Desktop Services customers who want to reduce the attack surface of their deployment by using Azure AD Application Proxy. This scenario gives a set of two-step verification and Conditional Access controls to RDS.
+
+## How Application Proxy fits in the standard RDS deployment
+
+A standard RDS deployment includes various Remote Desktop role services running on Windows Server. Looking at the [Remote Desktop Services architecture](/windows-server/remote/remote-desktop-services/Desktop-hosting-logical-architecture), there are multiple deployment options. Unlike other RDS deployment options, the [RDS deployment with Azure AD Application Proxy](/windows-server/remote/remote-desktop-services/Desktop-hosting-logical-architecture) (shown in the following diagram) has a permanent outbound connection from the server running the connector service. Other deployments leave open inbound connections through a load balancer.
+
+![Application Proxy sits between the RDS VM and the public internet](./media/application-proxy-integrate-with-remote-desktop-services/rds-with-app-proxy.png)
+
+In an RDS deployment, the RD Web role and the RD Gateway role run on Internet-facing machines. These endpoints are exposed for the following reasons:
+- RD Web provides the user a public endpoint to sign in and view the various on-premises applications and desktops they can access. Upon selecting a resource, an RDP connection is created using the native app on the OS.
+- RD Gateway comes into the picture once a user launches the RDP connection. The RD Gateway handles encrypted RDP traffic coming over the internet and translates it to the on-premises server that the user is connecting to. In this scenario, the traffic the RD Gateway is receiving comes from the Azure AD Application Proxy.
+
+>[!TIP]
+>If you haven't deployed RDS before, or want more information before you begin, learn how to [seamlessly deploy RDS with Azure Resource Manager and Azure Marketplace](/windows-server/remote/remote-desktop-services/rds-in-azure).
+
+## Requirements
+
+- Both the RD Web and RD Gateway endpoints must be located on the same machine, and with a common root. RD Web and RD Gateway are published as a single application with Application Proxy so that you can have a single sign-on experience between the two applications.
+- You should already have [deployed RDS](/windows-server/remote/remote-desktop-services/rds-in-azure), and [enabled Application Proxy](../app-proxy/application-proxy-add-on-premises-application.md). Ensure you have satisfied the pre-requisites to enable Application Proxy, such as installing the connector, opening required ports and URLS, and enabling TLS 1.2 on the server.
+- Your end users must use a compatible browser to connect to RD Web or the RD Web client. For more details see [Support for client configurations](#support-for-other-client-configurations).
+- When publishing RD Web, it is recommended to use the same internal and external FQDN. If the internal and external FQDNs are different then you should disable Request Header Translation to avoid the client receiving invalid links.
+- If you are using RD Web on Internet Explorer, you will need to enable the RDS ActiveX add-on.
+- If you are using the RD Web client, you will need to use the Application Proxy [connector version 1.5.1975 or later](./application-proxy-release-version-history.md).
+- For the Azure AD pre-authentication flow, users can only connect to resources published to them in the **RemoteApp and Desktops** pane. Users can't connect to a desktop using the **Connect to a remote PC** pane.
+- If you are using Windows Server 2019, you may need to disable HTTP2 protocol. For more information, see [Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory](../app-proxy/application-proxy-add-on-premises-application.md).
+
+## Deploy the joint RDS and Application Proxy scenario
+
+After setting up RDS and Azure AD Application Proxy for your environment, follow the steps to combine the two solutions. These steps walk through publishing the two web-facing RDS endpoints (RD Web and RD Gateway) as applications, and then directing traffic on your RDS to go through Application Proxy.
+
+### Publish the RD host endpoint
+
+1. [Publish a new Application Proxy application](../app-proxy/application-proxy-add-on-premises-application.md) with the following values:
+ - Internal URL: `https://<rdhost>.com/`, where `<rdhost>` is the common root that RD Web and RD Gateway share.
+ - External URL: This field is automatically populated based on the name of the application, but you can modify it. Your users will go to this URL when they access RDS.
+ - Preauthentication method: Azure Active Directory
+ - Translate URL headers: No
+2. Assign users to the published RD application. Make sure they all have access to RDS, too.
+3. Leave the single sign-on method for the application as **Azure AD single sign-on disabled**.
+
+ >[!Note]
+ >Your users are asked to authenticate once to Azure AD and once to RD Web, but they have single sign-on to RD Gateway.
+
+4. Select **Azure Active Directory**, and then **App Registrations**. Choose your app from the list.
+5. Under **Manage**, select **Branding**.
+6. Update the **Home page URL** field to point to your RD Web endpoint (like `https://<rdhost>.com/RDWeb`).
+
+### Direct RDS traffic to Application Proxy
+
+Connect to the RDS deployment as an administrator and change the RD Gateway server name for the deployment. This configuration ensures that connections go through the Azure AD Application Proxy service.
+
+1. Connect to the RDS server running the RD Connection Broker role.
+2. Launch **Server Manager**.
+3. Select **Remote Desktop Services** from the pane on the left.
+4. Select **Overview**.
+5. In the Deployment Overview section, select the drop-down menu and choose **Edit deployment properties**.
+6. In the RD Gateway tab, change the **Server name** field to the External URL that you set for the RD host endpoint in Application Proxy.
+7. Change the **Logon method** field to **Password Authentication**.
+
+ ![Deployment Properties screen on RDS](./media/application-proxy-integrate-with-remote-desktop-services/rds-deployment-properties.png)
+
+8. Run this command for each collection. Replace *\<yourcollectionname\>* and *\<proxyfrontendurl\>* with your own information. This command enables single sign-on between RD Web and RD Gateway, and optimizes performance:
+
+ ```
+ Set-RDSessionCollectionConfiguration -CollectionName "<yourcollectionname>" -CustomRdpProperty "pre-authentication server address:s:<proxyfrontendurl>`nrequire pre-authentication:i:1"
+ ```
+
+ **For example:**
+ ```
+ Set-RDSessionCollectionConfiguration -CollectionName "QuickSessionCollection" -CustomRdpProperty "pre-authentication server address:s:https://remotedesktoptest-aadapdemo.msappproxy.net/`nrequire pre-authentication:i:1"
+ ```
+ >[!NOTE]
+ >The above command uses a backtick in "`nrequire".
+
+9. To verify the modification of the custom RDP properties as well as view the RDP file contents that will be downloaded from RDWeb for this collection, run the following command:
+ ```
+ (get-wmiobject -Namespace root\cimv2\terminalservices -Class Win32_RDCentralPublishedRemoteDesktop).RDPFileContents
+ ```
+
+Now that you've configured Remote Desktop, Azure AD Application Proxy has taken over as the internet-facing component of RDS. You can remove the other public internet-facing endpoints on your RD Web and RD Gateway machines.
+
+### Enable the RD Web Client
+If you also want users to be able to use the RD Web Client follow steps at [Set up the Remote Desktop web client for your users](/windows-server/remote/remote-desktop-services/clients/remote-desktop-web-client-admin) to enable this.
+
+The Remote Desktop web client lets users access your organization's Remote Desktop infrastructure through a HTML5-compatible web browser such as Microsoft Edge, Internet Explorer 11, Google Chrome, Safari, or Mozilla Firefox (v55.0 and later).
+
+## Test the scenario
+
+Test the scenario with Internet Explorer on a Windows 7 or 10 computer.
+
+1. Go to the external URL you set up, or find your application in the [MyApps panel](https://myapps.microsoft.com).
+2. You are asked to authenticate to Azure Active Directory. Use an account that you assigned to the application.
+3. You are asked to authenticate to RD Web.
+4. Once your RDS authentication succeeds, you can select the desktop or application you want, and start working.
+
+## Support for other client configurations
+
+The configuration outlined in this article is for access to RDS via RD Web or the RD Web Client. If you need to, however, you can support other operating systems or browsers. The difference is in the authentication method that you use.
+
+| Authentication method | Supported client configuration |
+| | |
+| Pre-authentication | RD Web- Windows 7/10 using Internet Explorer* or [Edge Chromium IE mode](/deployedge/edge-ie-mode) + RDS ActiveX add-on |
+| Pre-authentication | RD Web Client- HTML5-compatible web browser such as Microsoft Edge, Internet Explorer 11, Google Chrome, Safari, or Mozilla Firefox (v55.0 and later) |
+| Passthrough | Any other operating system that supports the Microsoft Remote Desktop application |
+
+*Edge Chromium IE mode is required when the My Apps portal is used for accessing the Remote Desktop app.
+
+The pre-authentication flow offers more security benefits than the passthrough flow. With pre-authentication you can use Azure AD authentication features like single sign-on, Conditional Access, and two-step verification for your on-premises resources. You also ensure that only authenticated traffic reaches your network.
+
+To use passthrough authentication, there are just two modifications to the steps listed in this article:
+1. In [Publish the RD host endpoint](#publish-the-rd-host-endpoint) step 1, set the Preauthentication method to **Passthrough**.
+2. In [Direct RDS traffic to Application Proxy](#direct-rds-traffic-to-application-proxy), skip step 8 entirely.
+
+## Next steps
+- [Enable remote access to SharePoint with Azure AD Application Proxy](application-proxy-integrate-with-sharepoint-server.md)
+- [Security considerations for accessing apps remotely by using Azure AD Application Proxy](application-proxy-security.md)
+- [Best practices for load balancing multiple app servers](application-proxy-high-availability-load-balancing.md#best-practices-for-load-balancing-among-multiple-app-servers)
active-directory Application Proxy Integrate With Sharepoint Server Saml https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-integrate-with-sharepoint-server-saml.md
+
+ Title: Publish on premises SharePoint with Azure Active Directory Application Proxy
+description: Covers the basics about how to integrate an on-premises SharePoint server with Azure Active Directory Application Proxy for SAML.
+++++++ Last updated : 04/27/2021++++
+# Integrate Azure Active Directory Application Proxy with SharePoint (SAML)
+
+This step-by-step guide explains how to secure the access to the [Azure Active Directory integrated on-premises Sharepoint (SAML)](../saas-apps/sharepoint-on-premises-tutorial.md) using Azure AD Application Proxy, where users in your organization (Azure AD, B2B) connect to Sharepoint through the Internet.
+
+> [!NOTE]
+> If you're new to Azure AD Application Proxy and want to learn more, see [Remote access to on-premises applications through Azure AD Application Proxy](./application-proxy.md).
+
+There are three primary advantages of this setup:
+
+- Azure AD Application Proxy ensures that authenticated traffic can reach your internal network and the Sharepoint server.
+- Your users can access the Sharepoint sites as usual without using VPN.
+- You can control the access by user assignment on Azure AD Application Proxy level and you can increase the security with Azure AD features like Conditional Access and Multi-Factor Authentication (MFA).
+
+This process requires two Enterprise Applications. One is a SharePoint on-premises instance that you publish from the gallery to your list of managed SaaS apps. The second is an on-premises application (non-gallery application) you'll use to publish the first Enterprise Gallery Application.
+
+## Prerequisites
+
+To complete this configuration, you need the following resources:
+ - A SharePoint 2013 farm or newer. The Sharepoint farm must be [integrated with Azure AD](../saas-apps/sharepoint-on-premises-tutorial.md).
+ - An Azure AD tenant with a plan that includes Application Proxy. Learn more about [Azure AD plans and pricing](https://azure.microsoft.com/pricing/details/active-directory/).
+ - A [custom, verified domain](../fundamentals/add-custom-domain.md) in the Azure AD tenant. The verified domain must match the SharePoint URL suffix.
+ - An SSL certificate is required. See the details in [custom domain publishing](./application-proxy-configure-custom-domain.md).
+ - On-premises Active Directory users must be synchronized with Azure AD Connect, and must be configure to [sign in to Azure](../hybrid/plan-connect-user-signin.md).
+ - For cloud-only and B2B guest users, you need to [grant access to a guest account to SharePoint on-premises in the Azure portal](../saas-apps/sharepoint-on-premises-tutorial.md#grant-access-to-a-guest-account-to-sharepoint-on-premises-in-the-azure-portal).
+ - An Application Proxy connector installed and running on a machine within the corporate domain.
++
+## Step 1: Integrate SharePoint on-premises with Azure AD
+
+1. Configure the SharePoint on-premises app. For more information, see [Tutorial: Azure Active Directory single sign-on integration with SharePoint on-premises](../saas-apps/sharepoint-on-premises-tutorial.md).
+2. Validate the configuration before moving to the next step. To validate, try to access the SharePoint on-premises from the internal network and confirm it's accessible internally.
++
+## Step 2: Publish the Sharepoint on-premises application with Application Proxy
+
+In this step, you create an application in your Azure AD tenant that uses Application Proxy. You set the external URL and specify the internal URL, both of which are used later in SharePoint.
+
+> [!NOTE]
+> The Internal and External URLs must match the **Sign on URL** in the SAML Based Application configuration in Step 1.
+
+ ![Screenshot that shows the Sign on URL value.](./media/application-proxy-integrate-with-sharepoint-server/sso-url-saml.png)
++
+ 1. Create a new Azure AD Application Proxy application with custom domain. For step-by-step instructions, see [Custom domains in Azure AD Application Proxy](./application-proxy-configure-custom-domain.md).
+
+ - Internal URL: 'https://portal.contoso.com/'
+ - External URL: 'https://portal.contoso.com/'
+ - Pre-Authentication: Azure Active Directory
+ - Translate URLs in Headers: No
+ - Translate URLs in Application Body: No
+
+ ![Screenshot that shows the options you use to create the app.](./media/application-proxy-integrate-with-sharepoint-server/create-application-azure-active-directory.png)
+
+2. Assign the [same groups](../saas-apps/sharepoint-on-premises-tutorial.md#create-an-azure-ad-security-group-in-the-azure-portal) you assigned to the on-premises SharePoint Gallery Application.
+
+3. Finally, go to the **Properties** section and set **Visible to users?** to **No**. This option ensures that only the icon of the first application appears on the My Apps Portal (https://myapplications.microsoft.com).
+
+ ![Screenshot that shows where to set the Visible to users? option.](./media/application-proxy-integrate-with-sharepoint-server/configure-properties.png)
+
+## Step 3: Test your application
+
+Using a browser from a computer on an external network, navigate to the link that you configured during the publish step. Make sure you can sign in with the test account that you set up.
active-directory Application Proxy Integrate With Sharepoint Server https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-integrate-with-sharepoint-server.md
+
+ Title: Enable remote access to SharePoint - Azure Active Directory Application Proxy
+description: Covers the basics about how to integrate an on-premises SharePoint server with Azure Active Directory Application Proxy.
+++++++ Last updated : 04/27/2021++++
+# Enable remote access to SharePoint with Azure Active Directory Application Proxy
+
+This step-by-step guide explains how to integrate an on-premises SharePoint farm with Azure Active Directory (Azure AD) Application Proxy.
+
+## Prerequisites
+
+To perform the configuration, you need the following resources:
+- A SharePoint 2013 farm or newer.
+- An Azure AD tenant with a plan that includes Application Proxy. Learn more about [Azure AD plans and pricing](https://azure.microsoft.com/pricing/details/active-directory/).
+- A [custom, verified domain](../fundamentals/add-custom-domain.md) in the Azure AD tenant.
+- On-premises Active Directory synchronized with Azure AD Connect, through which users can [sign in to Azure](../hybrid/plan-connect-user-signin.md).
+- An Application Proxy connector installed and running on a machine within the corporate domain.
+
+Configuring SharePoint with Application Proxy requires two URLs:
+- An external URL, visible to end-users and determined in Azure AD. This URL can use a custom domain. Learn more about [working with custom domains in Azure AD Application Proxy](application-proxy-configure-custom-domain.md).
+- An internal URL, known only within the corporate domain and never used directly.
+
+> [!IMPORTANT]
+> To make sure the links are mapped correctly, follow these recommendations for the internal URL:
+> - Use HTTPS.
+> - Don't use custom ports.
+> - In the corporate Domain Name System (DNS), create a host (A) to point to the SharePoint WFE (or load balancer), and not an alias (CName).
+
+This article uses the following values:
+- Internal URL: `https://sharepoint`
+- External URL: `https://spsites-demo1984.msappproxy.net/`
+- Application pool account for the SharePoint web application: `Contoso\spapppool`
+
+## Step 1: Configure an application in Azure AD that uses Application Proxy
+
+In this step, you create an application in your Azure Active Directory tenant that uses Application Proxy. You set the external URL and specify the internal URL, both of which are used later in SharePoint.
+
+1. Create the app as described with the following settings. For step-by-step instructions, see [Publishing applications using Azure AD Application Proxy](../app-proxy/application-proxy-add-on-premises-application.md#add-an-on-premises-app-to-azure-ad).
+ * **Internal URL**: SharePoint internal URL that will be set later in SharePoint, such as `https://sharepoint`.
+ * **Pre-Authentication**: Azure Active Directory
+ * **Translate URLs in Headers**: No
+ * **Translate URLs in Application Body**: No
+
+ ![Publish SharePoint as application](./media/application-proxy-integrate-with-sharepoint-server/publish-app.png)
+
+1. After your app is published, follow these steps to configure the single sign-on settings:
+
+ 1. On the application page in the portal, select **Single sign-on**.
+ 1. For **Single Sign-on Mode**, select **Integrated Windows Authentication**.
+ 1. Set **Internal Application SPN** to the value you set earlier. For this example, the value is `HTTP/sharepoint`.
+ 1. Under **Delegated Login Identity**, select the most suitable option for your Active Directory forest configuration. For example if you have a single Active Directory domain in your forest, select **On-premises SAM account name** (as shown in the following screenshot). But if your users aren't in the same domain as SharePoint and the Application Proxy Connector servers, select **On-premises user principal name** (not shown in the screenshot).
+
+ ![Configure Integrated Windows Authentication for SSO](./media/application-proxy-integrate-with-sharepoint-server/configure-iwa.png)
+
+1. To finish setting up your application, go to the **Users and groups** section and assign users to access this application.
+
+## Step 2: Configure the SharePoint web application
+
+The SharePoint web application must be configured with Kerberos and the appropriate alternate access mappings to work correctly with Azure AD Application Proxy. There are two possible options:
+
+- Create a new web application and use only the Default zone. This is the preferred option, as it offers the best experience with SharePoint (for example, the links in the email alerts generated by SharePoint always point to the Default zone).
+- Extend an existing web application to configure Kerberos in a non-default zone.
+
+> [!IMPORTANT]
+> Regardless of the zone that's used, the application pool account of the SharePoint web application must be a domain account for Kerberos to work correctly.
+
+### Provision the SharePoint web application
+
+- If you create a new web application and use only the Default zone (preferred option):
+
+ 1. Start the **SharePoint Management Shell** and run the following script:
+
+ ```powershell
+ # This script creates a web application and configures the Default zone with the internal/external URL needed to work with Azure AD Application Proxy
+ # Edit variables below to fit your environment. Note that the managed account must exist and it must be a domain account
+ $internalUrl = "https://sharepoint"
+ $externalUrl = "https://spsites-demo1984.msappproxy.net/"
+ $applicationPoolManagedAccount = "Contoso\spapppool"
+
+ $winAp = New-SPAuthenticationProvider -UseWindowsIntegratedAuthentication -DisableKerberos:$false
+ $wa = New-SPWebApplication -Name "SharePoint - AAD Proxy" -Port 443 -SecureSocketsLayer -URL $externalUrl -ApplicationPool "SharePoint - AAD Proxy" -ApplicationPoolAccount (Get-SPManagedAccount $applicationPoolManagedAccount) -AuthenticationProvider $winAp
+ New-SPAlternateURL -Url $internalUrl -WebApplication $wa -Zone Default -Internal
+ ```
+
+ 2. Open the **SharePoint Central Administration** site.
+ 1. Under **System Settings**, select **Configure Alternate Access Mappings**. The **Alternate Access Mapping Collection** box opens.
+ 1. Filter the display with the new web application and confirm that you see something like this:
+
+ ![Alternate Access Mappings of web application](./media/application-proxy-integrate-with-sharepoint-server/new-webapp-aam.png)
+
+- If you extend an existing web application to a new zone (in case you can't use the Default zone):
+
+ 1. Start the SharePoint Management Shell and run the following script:
+
+ ```powershell
+ # This script extends an existing web application to Internet zone with the internal/external URL needed to work with Azure AD Application Proxy
+ # Edit variables below to fit your environment
+ $webAppUrl = "http://spsites/"
+ $internalUrl = "https://sharepoint"
+ $externalUrl = "https://spsites-demo1984.msappproxy.net/"
+
+ $winAp = New-SPAuthenticationProvider -UseWindowsIntegratedAuthentication -DisableKerberos:$false
+ $wa = Get-SPWebApplication $webAppUrl
+ New-SPWebApplicationExtension -Name "SharePoint - AAD Proxy" -Identity $wa -SecureSocketsLayer -Zone Extranet -Url $externalUrl -AuthenticationProvider $winAp
+ New-SPAlternateURL -Url $internalUrl -WebApplication $wa -Zone Extranet -Internal
+ ```
+
+ 2. Open the **SharePoint Central Administration** site.
+ 1. Under **System Settings**, select **Configure Alternate Access Mappings**. The **Alternate Access Mapping Collection** box opens.
+ 1. Filter the display with the web application that was extended and confirm that you see something like this:
+
+ ![Alternate Access Mappings of extended application](./media/application-proxy-integrate-with-sharepoint-server/extend-webapp-aam.png)
+
+### Make sure the SharePoint web application is running under a domain account
+
+To identify the account running the application pool of the SharePoint web application and to make sure it's a domain account, follow these steps:
+
+1. Open the **SharePoint Central Administration** site.
+1. Go to **Security** and select **Configure service accounts**.
+1. Select **Web Application Pool - YourWebApplicationName**.
+
+ ![Choices for configuring a service account](./media/application-proxy-integrate-with-sharepoint-server/service-web-application.png)
+
+1. Confirm that **Select an account for this component** returns a domain account, and remember it, since it will be needed in the next step.
+
+### Make sure that an HTTPS certificate is configured for the IIS site of the Extranet zone
+
+Because the Internal URL uses HTTPS protocol (`https://SharePoint/`), a certificate must be set on the Internet Information Services (IIS) site.
+
+1. Open the Windows PowerShell console.
+1. Run the following script to generate a self-signed certificate and add it to the computer's MY store:
+
+ ```powershell
+ # Replace "SharePoint" with the actual hostname of the Internal URL of your Azure AD proxy application
+ New-SelfSignedCertificate -DnsName "SharePoint" -CertStoreLocation "cert:\LocalMachine\My"
+ ```
+
+ > [!IMPORTANT]
+ > Self-signed certificates are suitable only for test purposes. In production environments, we strongly recommend that you use certificates issued by a certificate authority instead.
+
+1. Open the Internet Information Services Manager console.
+1. Expand the server in the tree view, expand **Sites**, select the **SharePoint - AAD Proxy** site, and select **Bindings**.
+1. Select **https binding** and then select **Edit**.
+1. In the TLS/SSL certificate field, choose **SharePoint** certificate and then select **OK**.
+
+You can now access the SharePoint site externally through Azure AD Application Proxy.
+
+## Step 3: Configure Kerberos Constrained Delegation
+
+Users will initially authenticate in Azure AD and then to SharePoint by using Kerberos through the Azure AD Proxy connector. To allow the connector to obtain a Kerberos token on behalf of the Azure AD user, you must configure Kerberos Constrained Delegation (KCD) with protocol transition. To learn more about KCD, see [Kerberos Constrained Delegation overview](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj553400(v=ws.11)).
+
+### Set the SPN for the SharePoint service account
+
+In this article, the internal URL is `https://sharepoint`, and so the service principal name (SPN) is `HTTP/sharepoint`. You must replace those values with the values that correspond to your environment.
+To register SPN `HTTP/sharepoint` for the SharePoint application pool account `Contoso\spapppool`, run the following command from a command prompt, as an administrator of the domain:
+
+`setspn -S HTTP/sharepoint Contoso\spapppool`
+
+The `Setspn` command searches for the SPN before it adds it. If the SPN already exists, you see a **Duplicate SPN Value** error. In that case, consider removing the existing SPN if it's not set under the correct application pool account. You can verify that the SPN was added successfully by running the `Setspn` command with the -L option. To learn more about this command, see [Setspn](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/cc731241(v=ws.11)).
+
+### Make sure the connector is trusted for delegation to the SPN that was added to the SharePoint application pool account
+
+Configure the KCD so that the Azure AD Application Proxy service can delegate user identities to the SharePoint application pool account. Configure KCD by enabling the Application Proxy connector to retrieve Kerberos tickets for your users who have been authenticated in Azure AD. Then, that server passes the context to the target application (SharePoint in this case).
+
+To configure the KCD, follow these steps for each connector machine:
+
+1. Sign in to a domain controller as a domain administrator, and then open Active Directory Users and Computers.
+1. Find the computer running the Azure AD Proxy connector. In this example, it's the SharePoint server itself.
+1. Double-click the computer, and then select the **Delegation** tab.
+1. Make sure the delegation options are set to **Trust this computer for delegation to the specified services only**. Then, select **Use any authentication protocol**.
+1. Select the **Add** button, select **Users or Computers**, and locate the SharePoint application pool account. For example: `Contoso\spapppool`.
+1. In the list of SPNs, select the one that you created earlier for the service account.
+1. Select **OK** and then select **OK** again to save your changes.
+
+ ![Delegation settings](./media/application-proxy-integrate-with-sharepoint-server/delegation-box2.png)
+
+You're now ready to sign in to SharePoint by using the external URL and to authenticate with Azure.
+
+## Troubleshoot sign-in errors
+
+If sign-in to the site isn't working, you can get more information about the issue in the Connector logs: From the machine running the connector, open the event viewer, go to **Applications and Services Logs** > **Microsoft** > **AadApplicationProxy** > **Connector**, and inspect the **Admin** log.
+
+## Next steps
+
+* [Working with custom domains in Azure AD Application Proxy](application-proxy-configure-custom-domain.md)
+* [Understand Azure AD Application Proxy connectors](application-proxy-connectors.md)
active-directory Application Proxy Network Topology https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-network-topology.md
+
+ Title: Network topology considerations for Azure Active Directory Application Proxy
+description: Covers network topology considerations when using Azure Active Directory Application Proxy.
+++++++ Last updated : 04/27/2021++++
+# Optimize traffic flow with Azure Active Directory Application Proxy
+
+This article explains how to optimize traffic flow and network topology considerations when using Azure Active Directory (Azure AD) Application Proxy for publishing and accessing your applications remotely.
+
+## Traffic flow
+
+When an application is published through Azure AD Application Proxy, traffic from the users to the applications flows through three connections:
+
+1. The user connects to the Azure AD Application Proxy service public endpoint on Azure
+1. The Application Proxy service connects to the Application Proxy connector
+1. The Application Proxy connector connects to the target application
++
+## Optimize connector groups to use closest Application Proxy cloud service (Preview)
+
+When you sign up for an Azure AD tenant, the region of your tenant is determined by the country/region you specify. When you enable Application Proxy, the **default** Application Proxy cloud service instances for your tenant are chosen in the same region as your Azure AD tenant, or the closest region to it.
+
+For example, if your Azure AD tenant's country or region is the United Kingdom, all your Application Proxy connectors at **default** will be assigned to use service instances in European data centers. When your users access published applications, their traffic goes through the Application Proxy cloud service instances in this location.
+
+If you have connectors installed in regions different from your default region, it may be beneficial to change which region your connector group is optimized for to improve performance accessing these applications. Once a region is specified for a connector group it will connect to Application Proxy cloud services in the designated region.
+
+In order to optimize the traffic flow and reduce latency to a connector group assign the connector group to the closest region. To assign a region:
+
+> [!IMPORTANT]
+> Connectors must be using at least version 1.5.1975.0 to use this capability.
+
+1. Sign in to the [Azure portal](https://portal.azure.com/) as an application administrator of the directory that uses Application Proxy. For example, if the tenant domain is contoso.com, the admin should be admin@contoso.com or any other admin alias on that domain.
+1. Select your username in the upper-right corner. Verify you're signed in to a directory that uses Application Proxy. If you need to change directories, select **Switch directory** and choose a directory that uses Application Proxy.
+1. In left navigation panel, select **Azure Active Directory**.
+1. Under **Manage**, select **Application proxy**.
+1. Select **New Connector Group**, provide a **Name** for the connector group.
+1. Next, under **Advanced Settings** and select the drop down under Optimize for a specific region and select the region closest to the connectors.
+1. Select **Create**.
+
+ :::image type="content" source="./media/application-proxy-network-topology/geo-routing.png" alt-text="Configure a new connector group." lightbox="./media/application-proxy-network-topology/geo-routing.png":::
+
+1. Once the new connector group is created, you can select which connectors to assign to this connector group.
+ - You can only move connectors to your connector group if it is in a connector group using the default region. The best approach is to always start with your connectors placed in the ΓÇ£Default groupΓÇ¥ and then move it to the appropriate connector group.
+ - You can only change the region of a connector group if there are **no** connectors assigned to it or apps assigned to it.
+1. Next assign the connector group to your applications. When accessing the apps, traffic should now go to the Application Proxy cloud service in the region the connector group is optimized for.
+
+## Considerations for reducing latency
+
+All proxy solutions introduce latency into your network connection. No matter which proxy or VPN solution you choose as your remote access solution, it always includes a set of servers enabling the connection to inside your corporate network.
+
+Organizations typically include server endpoints in their perimeter network. With Azure AD Application Proxy, however, traffic flows through the proxy service in the cloud while the connectors reside on your corporate network. No perimeter network is required.
+
+The next sections contain additional suggestions to help you reduce latency even further.
+
+### Connector placement
+
+Application Proxy chooses the location of instances for you, based on your tenant location. However, you get to decide where to install the connector, giving you the power to define the latency characteristics of your network traffic.
+
+When setting up the Application Proxy service, ask the following questions:
+
+- Where is the app located?
+- Where are most users who access the app located?
+- Where is the Application Proxy instance located?
+- Do you already have a dedicated network connection to Azure datacenters set up, like Azure ExpressRoute or a similar VPN?
+
+The connector has to communicate with both Azure and your applications (steps 2 and 3 in the Traffic flow diagram), so the placement of the connector affects the latency of those two connections. When evaluating the placement of the connector, keep in mind the following points:
+
+- If you want to use Kerberos constrained delegation (KCD) for single sign-on, then the connector needs a line of sight to a datacenter. Additionally, the connector server needs to be domain joined.
+- When in doubt, install the connector closer to the application.
+
+### General approach to minimize latency
+
+You can minimize the latency of the end-to-end traffic by optimizing each network connection. Each connection can be optimized by:
+
+- Reducing the distance between the two ends of the hop.
+- Choosing the right network to traverse. For example, traversing a private network rather than the public Internet may be faster, due to dedicated links.
+
+If you have a dedicated VPN or ExpressRoute link between Azure and your corporate network, you may want to use that.
+
+## Focus your optimization strategy
+
+There's little that you can do to control the connection between your users and the Application Proxy service. Users may access your apps from a home network, a coffee shop, or a different country/region. Instead, you can optimize the connections from the Application Proxy service to the Application Proxy connectors to the apps. Consider incorporating the following patterns in your environment.
+
+### Pattern 1: Put the connector close to the application
+
+Place the connector close to the target application in the customer network. This configuration minimizes step 3 in the topography diagram, because the connector and application are close.
+
+If your connector needs a line of sight to the domain controller, then this pattern is advantageous. Most of our customers use this pattern, because it works well for most scenarios. This pattern can also be combined with pattern 2 to optimize traffic between the service and the connector.
+
+### Pattern 2: Take advantage of ExpressRoute with Microsoft peering
+
+If you have ExpressRoute set up with Microsoft peering, you can use the faster ExpressRoute connection for traffic between Application Proxy and the connector. The connector is still on your network, close to the app.
+
+### Pattern 3: Take advantage of ExpressRoute with private peering
+
+If you have a dedicated VPN or ExpressRoute set up with private peering between Azure and your corporate network, you have another option. In this configuration, the virtual network in Azure is typically considered as an extension of the corporate network. So you can install the connector in the Azure datacenter, and still satisfy the low latency requirements of the connector-to-app connection.
+
+Latency is not compromised because traffic is flowing over a dedicated connection. You also get improved Application Proxy service-to-connector latency because the connector is installed in an Azure datacenter close to your Azure AD tenant location.
++
+### Other approaches
+
+Although the focus of this article is connector placement, you can also change the placement of the application to get better latency characteristics.
+
+Increasingly, organizations are moving their networks into hosted environments. This enables them to place their apps in a hosted environment that is also part of their corporate network, and still be within the domain. In this case, the patterns discussed in the preceding sections can be applied to the new application location. If you're considering this option, see [Azure AD Domain Services](../../active-directory-domain-services/overview.md).
+
+Additionally, consider organizing your connectors using [connector groups](application-proxy-connector-groups.md) to target apps that are in different locations and networks.
+
+## Common use cases
+
+In this section, we walk through a few common scenarios. Assume that the Azure AD tenant (and therefore proxy service endpoint) is located in the United States (US). The considerations discussed in these use cases also apply to other regions around the globe.
+
+For these scenarios, we call each connection a "hop" and number them for easier discussion:
+
+- **Hop 1**: User to the Application Proxy service
+- **Hop 2**: Application Proxy service to the Application Proxy connector
+- **Hop 3**: Application Proxy connector to the target application
+
+### Use case 1
+
+**Scenario:** The app is in an organization's network in the US, with users in the same region. No ExpressRoute or VPN exists between the Azure datacenter and the corporate network.
+
+**Recommendation:** Follow pattern 1, explained in the previous section. For improved latency, consider using ExpressRoute, if needed.
+
+This is a simple pattern. You optimize hop 3 by placing the connector near the app. This is also a natural choice, because the connector typically is installed with line of sight to the app and to the datacenter to perform KCD operations.
++
+### Use case 2
+
+**Scenario:** The app is in an organization's network in the US, with users spread out globally. No ExpressRoute or VPN exists between the Azure datacenter and the corporate network.
+
+**Recommendation:** Follow pattern 1, explained in the previous section.
+
+Again, the common pattern is to optimize hop 3, where you place the connector near the app. Hop 3 is not typically expensive, if it is all within the same region. However, hop 1 can be more expensive depending on where the user is, because users across the world must access the Application Proxy instance in the US. It's worth noting that any proxy solution has similar characteristics regarding users being spread out globally.
++
+### Use case 3
+
+**Scenario:** The app is in an organization's network in the US. ExpressRoute with Microsoft peering exists between Azure and the corporate network.
+
+**Recommendation:** Follow patterns 1 and 2, explained in the previous section.
+
+First, place the connector as close as possible to the app. Then, the system automatically uses ExpressRoute for hop 2.
+
+If the ExpressRoute link is using Microsoft peering, the traffic between the proxy and the connector flows over that link. Hop 2 has optimized latency.
++
+### Use case 4
+
+**Scenario:** The app is in an organization's network in the US. ExpressRoute with private peering exists between Azure and the corporate network.
+
+**Recommendation:** Follow pattern 3, explained in the previous section.
+
+Place the connector in the Azure datacenter that is connected to the corporate network through ExpressRoute private peering.
+
+The connector can be placed in the Azure datacenter. Since the connector still has a line of sight to the application and the datacenter through the private network, hop 3 remains optimized. In addition, hop 2 is optimized further.
++
+### Use case 5
+
+**Scenario:** The app is in an organization's network in Europe, default tenant region is US, with most users in the Europe.
+
+**Recommendation:** Place the connector near the app. Update the connector group so it is optimized to use Europe Application Proxy service instances. For steps see, [Optimize connector groups to use closest Application Proxy cloud service](application-proxy-network-topology.md#optimize-connector-groups-to-use-closest-application-proxy-cloud-service-preview).
+
+Because Europe users are accessing an Application Proxy instance that happens to be in the same region, hop 1 is not expensive. Hop 3 is optimized. Consider using ExpressRoute to optimize hop 2.
+
+### Use case 6
+
+**Scenario:** The app is in an organization's network in Europe, default tenant region is US, with most users in the US.
+
+**Recommendation:** Place the connector near the app. Update the connector group so it is optimized to use Europe Application Proxy service instances. For steps see, [Optimize connector groups to use closest Application Proxy cloud service](application-proxy-network-topology.md#optimize-connector-groups-to-use-closest-application-proxy-cloud-service-preview). Hop 1 can be more expensive since all US users must access the Application Proxy instance in Europe.
+
+You can also consider using one other variant in this situation. If most users in the organization are in the US, then chances are that your network extends to the US as well. Place the connector in the US, continue to use the default US region for your connector groups, and use the dedicated internal corporate network line to the application in Europe. This way hops 2 and 3 are optimized.
++
+## Next steps
+
+- [Enable Application Proxy](application-proxy-add-on-premises-application.md)
+- [Enable single-sign on](application-proxy-configure-single-sign-on-with-kcd.md)
+- [Enable Conditional Access](../manage-apps/application-proxy-integrate-with-sharepoint-server.md)
+- [Troubleshoot issues you're having with Application Proxy](application-proxy-troubleshoot.md)
active-directory Application Proxy Page Appearance Broken Problem https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-page-appearance-broken-problem.md
+
+ Title: App page doesn't display correctly for Application Proxy app
+description: Guidance when the page isnΓÇÖt displaying correctly in an Application Proxy Application you have integrated with Azure Active Directory
+++++++ Last updated : 04/27/2021++++
+# Application page does not display correctly for an Application Proxy application
+
+This article helps you troubleshoot issues with Azure Active Directory Application Proxy applications when you navigate to the page, but something on the page doesn't look correct.
+
+## Overview
+When you publish an Application Proxy app, only pages under your root are accessible when accessing the application. If the page isnΓÇÖt displaying correctly, the root internal URL used for the application may be missing some page resources. To resolve, make sure you have published *all* the resources for the page as part of your application.
+
+You can verify if missing resources is the issue by opening your network tracker (such as Fiddler, or F12 tools in Internet Explorer/Microsoft Edge), loading the page, and looking for 404 errors. That indicates the pages currently cannot be found and that you need to publish them.
+
+As an example of this case, assume you have published an expenses application using the internal URL `http://myapps/expenses`, but the app uses the stylesheet `http://myapps/style.css`. In this case, the stylesheet is not published in your application, so loading the expenses app throw a 404 error while trying to load style.css. In this example, the problem is resolved by publishing the application with an internal URL `http://myapp/`.
+
+## Problems with publishing as one application
+
+If it is not possible to publish all resources within the same application, you need to publish multiple applications and enable links between them.
+
+To do so, we recommend using the [custom domains](application-proxy-configure-custom-domain.md) solution. However, this solution requires that you own the certificate for your domain and your applications use fully qualified domain names (FQDNs). For other options, see the [troubleshoot broken links documentation](application-proxy-page-links-broken-problem.md).
+
+## Next steps
+[Publish applications using Azure AD Application Proxy](../app-proxy/application-proxy-add-on-premises-application.md)
active-directory Application Proxy Page Links Broken Problem https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-page-links-broken-problem.md
+
+ Title: Links on the page don't work for an Azure Active Directory Application Proxy application
+description: How to troubleshoot issues with broken links on Application Proxy applications you have integrated with Azure Active Directory
+++++++ Last updated : 04/27/2021++++
+# Links on the page don't work for an Application Proxy application
+
+This article helps you troubleshoot why links on your Azure Active Directory Application Proxy application don't work correctly.
+
+## Overview
+After publishing an Application Proxy app, the only links that work by default in the application are links to destinations contained within the published root URL. The links within the applications arenΓÇÖt working, the internal URL for the application probably does not include all the destinations of links within the application.
+
+**Why does this happen?** When clicking a link in an application, Application Proxy tries to resolve the URL as either an internal URL within the same application, or as an externally available URL. If the link points to an internal URL that is not within the same application, it does not belong to either of these buckets and result in a not found error.
+
+## Ways you can resolve broken links
+
+There are three ways to resolve this issue. The choices below are in listed in increasing complexity.
+
+1. Make sure the internal URL is a root that contains all the relevant links for the application. This allows all links to be resolved as content published within the same application.
+
+ If you change the internal URL but donΓÇÖt want to change the landing page for users, change the Home page URL to the previously published internal URL. This can be done by going to ΓÇ£Azure Active DirectoryΓÇ¥ -&gt; App Registrations -&gt; select the application -&gt; Branding. In the branding section, you see the field ΓÇ£Home Page URLΓÇ¥, which you can adjust to be the desired landing page. If you are still using the legacy App registrations experience the properties tab would show the "Home Page URL" details.
+
+ > [!IMPORTANT]
+ > In order to make the above changes you require rights to modify application objects in Azure AD.The user needs to be assigned [Application Administrator](../roles/delegate-app-roles.md#assign-built-in-application-admin-roles) role which grants application modificaion rights in Azure AD to the user.
+ >
+
+2. If your applications use fully qualified domain names (FQDNs), use [custom domains](application-proxy-configure-custom-domain.md) to publish your applications. This feature allows the same URL to be used both internally and externally.
+
+ This option ensures that the links in your application are externally accessible through Application Proxy since the links within the application to internal URLs are also recognized externally. All links still need to belong to a published application. However, with this option the links do not need to belong to the same application and can belong to multiple applications.
+
+3. If neither of these options are feasible, there are multiple options for enabling inline link translation. These options include using the Intune Managed Browser, My Apps extension, or using the link translation setting on your application. To learn more about each of these options and how to enable them, see [Redirect hardcoded links for apps published with Azure AD Application Proxy](application-proxy-configure-hard-coded-link-translation.md).
+
+## Next steps
+[Work with existing on-premises proxy servers](application-proxy-configure-connectors-with-proxy-servers.md)
+
active-directory Application Proxy Page Load Speed Problem https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-page-load-speed-problem.md
+
+ Title: An Azure Active Directory Application Proxy application takes too long to load
+description: Troubleshoot page load performance issues with Azure Active Directory Application Proxy
+++++++ Last updated : 07/11/2017++++
+# An Application Proxy application takes too long to load
+
+This article helps you to understand why an Azure AD Application Proxy application may take a long time to load. It also explains what you can do to resolve this issue.
+
+## Overview
+Although your applications are working, they can experience a long latency. There might be network topology tweaks that you can make to improve speed. For an evaluation of different topologies, see the [network considerations document](application-proxy-network-topology.md).
+
+Besides network topology, there are currently no further recommendations for performance tuning. As the Application Proxy service expands it might come to a data center that is physically closer. The closer proximity might help with latency. For a list of Azure data centers, see the [latency test page](http://www.azurespeed.com/Azure/Latency).
+
+## Feedback on Application Proxy data center locations
+There may be Azure data centers that donΓÇÖt yet include Application Proxy, but would lead to a great latency improvement for you. Send the data center location to aadapfeedback@microsoft.com. Microsoft uses your feedback for expansion plans.
+
+Microsoft is working on additional capabilities to improve latency. As soon as these improvements are available, the documentation will be updated.
+
+## Next steps
+[Work with existing on-premises proxy servers](application-proxy-configure-connectors-with-proxy-servers.md)
active-directory Application Proxy Qlik https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-qlik.md
+
+ Title: Azure Active Directory Application Proxy and Qlik Sense
+description: Integrate Azure Active Directory Application Proxy with Qlik Sense.
+++++++ Last updated : 04/27/2021+++
+# Azure Active Directory Application Proxy and Qlik Sense
+Azure Active Directory Application Proxy and Qlik Sense have partnered together to ensure you are easily able to use Application Proxy to provide remote access for your Qlik Sense deployment.
+
+## Prerequisites
+The remainder of this scenario assumes you done the following:
+
+- Configured [Qlik Sense](https://community.qlik.com/docs/DOC-19822).
+- [Installed an Application Proxy connector](../app-proxy/application-proxy-add-on-premises-application.md#install-and-register-a-connector)
+
+## Publish your applications in Azure
+To publish QlikSense, you will need to publish two applications in Azure.
+
+### Application #1:
+Follow these steps to publish your app. For a more detailed walkthrough of steps 1-8, see [Publish applications using Azure AD Application Proxy](../app-proxy/application-proxy-add-on-premises-application.md).
++
+1. Sign in to the Azure portal as a global administrator.
+2. Select **Azure Active Directory** > **Enterprise applications**.
+3. Select **Add** at the top of the blade.
+4. Select **On-premises application**.
+5. Fill out the required fields with information about your new app. Use the following guidance for the settings:
+ - **Internal URL**: This application should have an internal URL that is the QlikSense URL itself. For example, **https&#58;//demo.qlikemm.com:4244**
+ - **Pre-authentication method**: Azure Active Directory (Recommended but not required)
+1. Select **Add** at the bottom of the blade. Your application is added, and the quick start menu opens.
+2. In the quick start menu, select **Assign a user for testing**, and add at least one user to the application. Make sure this test account has access to the on-premises application.
+3. Select **Assign** to save the test user assignment.
+4. (Optional) On the app management blade, select Single sign-on. Choose **Kerberos Constrained Delegation** from the drop-down menu, and fill out the required fields based on your Qlik configuration. Select **Save**.
+
+### Application #2:
+Follow the same steps as for Application #1, with the following exceptions:
+
+**Step #5**: The Internal URL should now be the QlikSense URL with the authentication port used by the application. The default is **4244** for HTTPS, and **4248** for HTTP for QlikSense releases prior to April 2018. The default for QlikSense releases after April 2018 is **443** for HTTPS and **80** for HTTP. Ex: **https&#58;//demo.qlik.com:4244**</br></br>
+**Step #10:** DonΓÇÖt set up SSO, and leave the **Single sign-on disabled**
+
+
+## Testing
+Your application is now ready to test. Access the external URL you used to publish QlikSense in Application #1, and login as a user assigned to both applications.
+
+## Additional references
+For more information about publishing Qlik Sense with Application Proxy, refer to following the Qlik Community Articles:
+- [Azure AD with Integrated Windows Authentication using a Kerberos Constrained Delegation with Qlik Sense](https://community.qlik.com/docs/DOC-20183)
+- [Qlik Sense integration with Azure AD Application Proxy](https://community.qlik.com/t5/Technology-Partners-Ecosystem/Azure-AD-Application-Proxy/ta-p/1528396)
+
+## Next steps
+
+- [Publish applications with Application Proxy](../app-proxy/application-proxy-add-on-premises-application.md)
+- [Working with Application Proxy connectors](../app-proxy/application-proxy-connector-groups.md)
active-directory Application Proxy Register Connector Powershell https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-register-connector-powershell.md
+
+ Title: Silent install Azure Active Directory Application Proxy connector
+description: Covers how to perform an unattended installation of Azure Active Directory Application Proxy Connector to provide secure remote access to your on-premises apps.
+++++++ Last updated : 04/27/2021++++
+# Create an unattended installation script for the Azure Active Directory Application Proxy connector
+
+This topic helps you create a Windows PowerShell script that enables unattended installation and registration for your Azure AD Application Proxy connector.
+
+This capability is useful when you want to:
+
+* Install the connector on Windows servers that don't have user interface enabled, or that you can't access with Remote Desktop.
+* Install and register many connectors at once.
+* Integrate the connector installation and registration as part of another procedure.
+* Create a standard server image that contains the connector bits but is not registered.
+
+For the [Application Proxy connector](application-proxy-connectors.md) to work, it has to be registered with your Azure AD directory using an application administrator and password. Ordinarily this information is entered during Connector installation in a pop-up dialog box, but you can use PowerShell to automate this process instead.
+
+There are two steps for an unattended installation. First, install the connector. Second, register the connector with Azure AD.
+
+> [!IMPORTANT]
+> If you are installing the connector for Azure Government cloud review the [pre-requisites](../hybrid/reference-connect-government-cloud.md#allow-access-to-urls) and [installation steps](../hybrid/reference-connect-government-cloud.md#install-the-agent-for-the-azure-government-cloud). This requires enabling access to a different set of URLs and an additional parameter to run the installation.
+
+## Install the connector
+Use the following steps to install the connector without registering it:
+
+1. Open a command prompt.
+2. Run the following command, in which the /q means quiet installation. A quiet installation doesn't prompt you to accept the End-User License Agreement.
+
+ ```
+ AADApplicationProxyConnectorInstaller.exe REGISTERCONNECTOR="false" /q
+ ```
+
+## Register the connector with Azure AD
+There are two methods you can use to register the connector:
+
+* Register the connector using a Windows PowerShell credential object
+* Register the connector using a token created offline
+
+### Register the connector using a Windows PowerShell credential object
+1. Create a Windows PowerShell Credentials object `$cred` that contains an administrative username and password for your directory. Run the following command, replacing *\<username\>* and *\<password\>*:
+
+ ```powershell
+ $User = "<username>"
+ $PlainPassword = '<password>'
+ $SecurePassword = $PlainPassword | ConvertTo-SecureString -AsPlainText -Force
+ $cred = New-Object ΓÇôTypeName System.Management.Automation.PSCredential ΓÇôArgumentList $User, $SecurePassword
+ ```
+2. Go to **C:\Program Files\Microsoft AAD App Proxy Connector** and run the following script using the `$cred` object that you created:
+
+ ```powershell
+ .\RegisterConnector.ps1 -modulePath "C:\Program Files\Microsoft AAD App Proxy Connector\Modules\" -moduleName "AppProxyPSModule" -Authenticationmode Credentials -Usercredentials $cred -Feature ApplicationProxy
+ ```
+
+### Register the connector using a token created offline
+1. Create an offline token using the AuthenticationContext class using the values in this code snippet or PowerShell cmdlets below:
+
+ **Using C#:**
+
+ ```csharp
+ using System;
+ using System.Linq;
+ using System.Collections.Generic;
+ using Microsoft.Identity.Client;
+
+ class Program
+ {
+ #region constants
+ /// <summary>
+ /// The AAD authentication endpoint uri
+ /// </summary>
+ static readonly string AadAuthenticationEndpoint = "https://login.microsoftonline.com/common/oauth2/v2.0/authorize";
+
+ /// <summary>
+ /// The application ID of the connector in AAD
+ /// </summary>
+ static readonly string ConnectorAppId = "55747057-9b5d-4bd4-b387-abf52a8bd489";
+
+ /// <summary>
+ /// The AppIdUri of the registration service in AAD
+ /// </summary>
+ static readonly string RegistrationServiceAppIdUri = "https://proxy.cloudwebappproxy.net/registerapp/user_impersonation";
+
+ #endregion
+
+ #region private members
+ private string token;
+ private string tenantID;
+ #endregion
+
+ public void GetAuthenticationToken()
+ {
+
+ IPublicClientApplication clientApp = PublicClientApplicationBuilder
+ .Create(ConnectorAppId)
+ .WithDefaultRedirectUri() // will automatically use the default Uri for native app
+ .WithAuthority(AadAuthenticationEndpoint)
+ .Build();
+
+ AuthenticationResult authResult = null;
+
+ IAccount account = null;
+
+ IEnumerable<string> scopes = new string[] { RegistrationServiceAppIdUri };
+
+ try
+ {
+ authResult = await clientApp.AcquireTokenSilent(scopes, account).ExecuteAsync();
+ }
+ catch (MsalUiRequiredException ex)
+ {
+ authResult = await clientApp.AcquireTokenInteractive(scopes).ExecuteAsync();
+ }
++
+ if (authResult == null || string.IsNullOrEmpty(authResult.AccessToken) || string.IsNullOrEmpty(authResult.TenantId))
+ {
+ Trace.TraceError("Authentication result, token or tenant id returned are null");
+ throw new InvalidOperationException("Authentication result, token or tenant id returned are null");
+ }
+
+ token = authResult.AccessToken;
+ tenantID = authResult.TenantId;
+ }
+ ```
+
+ **Using PowerShell:**
+
+ ```powershell
+ # Load MSAL (Tested with version 4.7.1)
+
+ Add-Type -Path "..\MSAL\Microsoft.Identity.Client.dll"
+
+ # The AAD authentication endpoint uri
+
+ $authority = "https://login.microsoftonline.com/common/oauth2/v2.0/authorize"
+
+ #The application ID of the connector in AAD
+
+ $connectorAppId = "55747057-9b5d-4bd4-b387-abf52a8bd489";
+
+ #The AppIdUri of the registration service in AAD
+ $registrationServiceAppIdUri = "https://proxy.cloudwebappproxy.net/registerapp/user_impersonation"
+
+ # Define the resources and scopes you want to call
+
+ $scopes = New-Object System.Collections.ObjectModel.Collection["string"]
+
+ $scopes.Add($registrationServiceAppIdUri)
+
+ $app = [Microsoft.Identity.Client.PublicClientApplicationBuilder]::Create($connectorAppId).WithAuthority($authority).WithDefaultRedirectUri().Build()
+
+ [Microsoft.Identity.Client.IAccount] $account = $null
+
+ # Acquiring the token
+
+ $authResult = $null
+
+ $authResult = $app.AcquireTokenInteractive($scopes).WithAccount($account).ExecuteAsync().ConfigureAwait($false).GetAwaiter().GetResult()
+
+ # Check AuthN result
+ If (($authResult) -and ($authResult.AccessToken) -and ($authResult.TenantId)) {
+
+ $token = $authResult.AccessToken
+ $tenantId = $authResult.TenantId
+
+ Write-Output "Success: Authentication result returned."
+
+ }
+ Else {
+
+ Write-Output "Error: Authentication result, token or tenant id returned with null."
+
+ }
+ ```
+
+2. Once you have the token, create a SecureString using the token:
+
+ ```powershell
+ $SecureToken = $Token | ConvertTo-SecureString -AsPlainText -Force
+ ```
+
+3. Run the following Windows PowerShell command, replacing \<tenant GUID\> with your directory ID:
+
+ ```powershell
+ .\RegisterConnector.ps1 -modulePath "C:\Program Files\Microsoft AAD App Proxy Connector\Modules\" -moduleName "AppProxyPSModule" -Authenticationmode Token -Token $SecureToken -TenantId <tenant GUID> -Feature ApplicationProxy
+ ```
+
+## Next steps
+* [Publish applications using your own domain name](application-proxy-configure-custom-domain.md)
+* [Enable single-sign on](application-proxy-configure-single-sign-on-with-kcd.md)
+* [Troubleshoot issues you're having with Application Proxy](application-proxy-troubleshoot.md)
active-directory Application Proxy Release Version History https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-release-version-history.md
+
+ Title: 'Azure Active Directory Application Proxy: Version release history'
+description: This article lists all releases of Azure Active Directory Application Proxy and describes new features and fixed issues.
++++++ Last updated : 04/27/2021+++++
+# Azure AD Application Proxy: Version release history
+This article lists the versions and features of Azure Active Directory (Azure AD) Application Proxy that have been released. The Azure AD team regularly updates Application Proxy with new features and functionality. Application Proxy connectors are updated automatically when a new version is released.
+
+We recommend making sure that auto-updates are enabled for your connectors to ensure you have the latest features and bug fixes. Microsoft provides direct support for the latest connector version and one version before.
+
+Here is a list of related resources:
+
+| Resource | Details |
+| | |
+| How to enable Application Proxy | Pre-requisites for enabling Application Proxy and installing and registering a connector are described in this [tutorial](application-proxy-add-on-premises-application.md). |
+| Understand Azure AD Application Proxy connectors | Find out more about [connector management](application-proxy-connectors.md) and how connectors [auto-upgrade](application-proxy-connectors.md#automatic-updates). |
+| Azure AD Application Proxy Connector Download | [Download the latest connector](https://download.msappproxy.net/subscription/d3c8b69d-6bf7-42be-a529-3fe9c2e70c90/connector/download). |
+
+## 1.5.1975.0
+
+### Release status
+
+July 22, 2020: Released for download
+This version is only available for install via the download page. An auto-upgrade release of this version will be released at a later time.
+
+### New features and improvements
+- Improved support for Azure Government cloud environments. For steps on how to properly install the connector for Azure Government cloud review the [pre-requisites](../hybrid/reference-connect-government-cloud.md#allow-access-to-urls) and [installation steps](../hybrid/reference-connect-government-cloud.md#install-the-agent-for-the-azure-government-cloud).
+- Support for using the Remote Desktop Services web client with Application Proxy. See [Publish Remote Desktop with Azure AD Application Proxy](application-proxy-integrate-with-remote-desktop-services.md) for more details.
+- Improved websocket extension negotiations.
+- Support for optimized routing between connector groups and Application Proxy cloud services based on region. See [Optimize traffic flow with Azure Active Directory Application Proxy](application-proxy-network-topology.md) for more details.
+
+### Fixed issues
+- Fixed a websocket issue that forced lowercase strings.
+- Fixed an issue that caused connectors to be occasionally unresponsive.
+
+## 1.5.1626.0
+
+### Release status
+
+July 17, 2020: Released for download.
+This version is only available for install via the download page. An auto-upgrade release of this version will be released at a later time.
+
+### Fixed issues
+- Resolved memory leak issue present in previous version
+- General improvements for websocket support
+
+## 1.5.1526.0
+
+### Release status
+
+April 07, 2020: Released for download
+This version is only available for install via the download page. An auto-upgrade release of this version will be released at a later time.
+
+### New features and improvements
+- Connectors only use TLS 1.2 for all connections. See [Connector pre-requisites](application-proxy-add-on-premises-application.md#prerequisites) for more details.
+- Improved signaling between the Connector and Azure services. This includes supporting reliable sessions for WCF communication between the Connector and Azure services and DNS caching improvements for WebSocket communications.
+- Support for configuring a proxy between the Connector and the backend application. For more information see [Work with existing on-premises proxy servers](application-proxy-configure-connectors-with-proxy-servers.md).
+
+### Fixed issues
+- Removed falling back to port 8080 for communications from the Connector to Azure services.
+- Added debug traces for WebSocket communications.
+- Resolved preserving the SameSite attribute when set on backend application cookies.
+
+## 1.5.612.0
+
+### Release status
+
+September 20, 2018: Released for download
+
+### New features and improvements
+
+- Added WebSocket support for the QlikSense application. To learn more about how to integrate QlikSense with Application Proxy, see this [walkthrough](application-proxy-qlik.md).
+- Improved the installation wizard to make it easier to configure an outbound proxy.
+- Set TLS 1.2 as the default protocol for connectors.
+- Added a new End-User License Agreement (EULA).
+
+### Fixed issues
+
+- Fixed a bug that caused some memory leaks in the connector.
+- Updated the Azure Service Bus version, which includes a bug fix for connector timeout issues.
+
+## 1.5.402.0
+
+### Release status
+
+January 19, 2018: Released for download
+
+### Fixed issues
+
+- Added support for custom domains that need domain translation in the cookie.
+
+## 1.5.132.0
+
+### Release status
+
+May 25, 2017: Released for download
+
+### New features and improvements
+
+Improved control over connectors' outbound connection limits.
+
+## 1.5.36.0
+
+### Release status
+
+April 15, 2017: Released for download
+
+### New features and improvements
+
+- Simplified onboarding and management with fewer required ports. Application Proxy now requires opening only two standard outbound ports: 443 and 80. Application Proxy continues to use only outbound connections, so you still don't need any components in a DMZ. For details, see ourΓÇ»[configuration documentation](application-proxy-add-on-premises-application.md).
+- If supported by your external proxy or firewall, you can now open your network by DNS instead of IP range. Application Proxy services require connections to *.msappproxy.net and *.servicebus.windows.net only.
++
+## Earlier versions
+
+If you're using an Application Proxy connector version earlier than 1.5.36.0, update to the latest version to ensure you have the latest fully supported features.
+
+## Next steps
+- Learn more about [Remote access to on-premises applications through Azure AD Application Proxy](application-proxy.md).
+- To start using Application Proxy, see [Tutorial: Add an on-premises application for remote access through Application Proxy](application-proxy-add-on-premises-application.md).
active-directory Application Proxy Secure Api Access https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-secure-api-access.md
+
+ Title: Access on-premises APIs with Azure Active Directory Application Proxy
+description: Azure Active Directory's Application Proxy lets native apps securely access APIs and business logic you host on-premises or on cloud VMs.
+++++++ Last updated : 04/27/2021+++
+# Secure access to on-premises APIs with Azure Active Directory Application Proxy
+
+You may have business logic APIs running on-premises, or hosted on virtual machines in the cloud. Your native Android, iOS, Mac, or Windows apps need to interact with the API endpoints to use data or provide user interaction. Azure AD Application Proxy and the [Microsoft Authentication Library (MSAL)](../azuread-dev/active-directory-authentication-libraries.md) let your native apps securely access your on-premises APIs. Azure Active Directory Application Proxy is a faster and more secure solution than opening firewall ports and controlling authentication and authorization at the app layer.
+
+This article walks you through setting up an Azure AD Application Proxy solution for hosting a web API service that native apps can access.
+
+## Overview
+
+The following diagram shows a traditional way to publish on-premises APIs. This approach requires opening incoming ports 80 and 443.
+
+![Traditional API access](./media/application-proxy-secure-api-access/overview-publish-api-open-ports.png)
+
+The following diagram shows how you can use Azure AD Application Proxy to securely publish APIs without opening any incoming ports:
+
+![Azure AD Application Proxy API access](./media/application-proxy-secure-api-access/overview-publish-api-app-proxy.png)
+
+The Azure AD Application Proxy forms the backbone of the solution, working as a public endpoint for API access, and providing authentication and authorization. You can access your APIs from a vast array of platforms by using the [Microsoft Authentication Library (MSAL)](../azuread-dev/active-directory-authentication-libraries.md) libraries.
+
+Since Azure AD Application Proxy authentication and authorization are built on top of Azure AD, you can use Azure AD Conditional Access to ensure only trusted devices can access APIs published through Application Proxy. Use Azure AD Join or Azure AD Hybrid Joined for desktops, and Intune Managed for devices. You can also take advantage of Azure Active Directory Premium features like Azure AD Multi-Factor Authentication, and the machine learning-backed security of [Azure Identity Protection](../identity-protection/overview-identity-protection.md).
+
+## Prerequisites
+
+To follow this walkthrough, you need:
+
+- Admin access to an Azure directory, with an account that can create and register apps
+- The sample web API and native client apps from [https://github.com/jeevanbisht/API-NativeApp-ADAL-SampleApp](https://github.com/jeevanbisht/API-NativeApp-ADAL-SampleApp)
+
+## Publish the API through Application Proxy
+
+To publish an API outside of your intranet through Application Proxy, you follow the same pattern as for publishing web apps. For more information, see [Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory](application-proxy-add-on-premises-application.md).
+
+To publish the SecretAPI web API through Application Proxy:
+
+1. Build and publish the sample SecretAPI project as an ASP.NET web app on your local computer or intranet. Make sure you can access the web app locally.
+
+1. In the [Azure portal](https://portal.azure.com), select **Azure Active Directory**. Then select **Enterprise applications**.
+
+1. At the top of the **Enterprise applications - All applications** page, select **New application**.
+
+1. On the **Add an application** page, select **On-premises applications**. The **Add your own on-premises application** page appears.
+
+1. If you don't have an Application Proxy Connector installed, you'll be prompted to install it. Select **Download Application Proxy Connector** to download and install the connector.
+
+1. Once you've installed the Application Proxy Connector, on the **Add your own on-premises application** page:
+
+ 1. Next to **Name**, enter *SecretAPI*.
+
+ 1. Next to **Internal Url**, enter the URL you use to access the API from within your intranet.
+
+ 1. Make sure **Pre-Authentication** is set to **Azure Active Directory**.
+
+ 1. Select **Add** at the top of the page, and wait for the app to be created.
+
+ ![Add API app](./media/application-proxy-secure-api-access/3-add-api-app.png)
+
+1. On the **Enterprise applications - All applications** page, select the **SecretAPI** app.
+
+1. On the **SecretAPI - Overview** page, select **Properties** in the left navigation.
+
+1. You don't want APIs to be available to end users in the **MyApps** panel, so set **Visible to users** to **No** at the bottom of the **Properties** page, and then select **Save**.
+
+ ![Not visible to users](./media/application-proxy-secure-api-access/5-not-visible-to-users.png)
+
+You've published your web API through Azure AD Application Proxy. Now, add users who can access the app.
+
+1. On the **SecretAPI - Overview** page, select **Users and groups** in the left navigation.
+
+1. On the **Users and groups** page, select **Add user**.
+
+1. On the **Add assignment** page, select **Users and groups**.
+
+1. On the **Users and groups** page, search for and select users who can access the app, including at least yourself. After selecting all users, select **Select**.
+
+ ![Select and assign user](./media/application-proxy-secure-api-access/7-select-admin-user.png)
+
+1. Back on the **Add Assignment** page, select **Assign**.
+
+> [!NOTE]
+> APIs that use Integrated Windows Authentication might require [additional steps](./application-proxy-configure-single-sign-on-with-kcd.md).
+
+## Register the native app and grant access to the API
+
+Native apps are programs developed to use on a particular platform or device. Before your native app can connect and access an API, you must register it in Azure AD. The following steps show how to register a native app and give it access to the web API you published through Application Proxy.
+
+To register the AppProxyNativeAppSample native app:
+
+1. On the Azure Active Directory **Overview** page, select **App registrations**, and at the top of the **App registrations** pane, select **New registration**.
+
+1. On the **Register an application** page:
+
+ 1. Under **Name**, enter *AppProxyNativeAppSample*.
+
+ 1. Under **Supported account types**, select **Accounts in any organizational directory and personal Microsoft accounts**.
+
+ 1. Under **Redirect URL**, drop down and select **Public client (mobile & desktop)**, and then enter *https://login.microsoftonline.com/common/oauth2/nativeclient*.
+
+ 1. Select **Register**, and wait for the app to be successfully registered.
+
+ ![New application registration](./media/application-proxy-secure-api-access/8-create-reg-ga.png)
+
+You've now registered the AppProxyNativeAppSample app in Azure Active Directory. To give your native app access to the SecretAPI web API:
+
+1. On the Azure Active Directory **Overview** > **App Registrations** page, select the **AppProxyNativeAppSample** app.
+
+1. On the **AppProxyNativeAppSample** page, select **API permissions** in the left navigation.
+
+1. On the **API permissions** page, select **Add a permission**.
+
+1. On the first **Request API permissions** page, select the **APIs my organization uses** tab, and then search for and select **SecretAPI**.
+
+1. On the next **Request API permissions** page, select the check box next to **user_impersonation**, and then select **Add permissions**.
+
+ ![Select an API](./media/application-proxy-secure-api-access/10-secretapi-added.png)
+
+1. Back on the **API permissions** page, you can select **Grant admin consent for Contoso** to prevent other users from having to individually consent to the app.
+
+## Configure the native app code
+
+The last step is to configure the native app. The following snippet from the *Form1.cs* file in the NativeClient sample app causes the MSAL library to acquire the token for requesting the API call, and attach it as bearer to the app header.
+
+ ```
+ // Acquire Access Token from AAD for Proxy Application
+ IPublicClientApplication clientApp = PublicClientApplicationBuilder
+.Create(<App ID of the Native app>)
+.WithDefaultRedirectUri() // will automatically use the default Uri for native app
+.WithAuthority("https://login.microsoftonline.com/{<Tenant ID>}")
+.Build();
+
+AuthenticationResult authResult = null;
+var accounts = await clientApp.GetAccountsAsync();
+IAccount account = accounts.FirstOrDefault();
+
+IEnumerable<string> scopes = new string[] {"<Scope>"};
+
+try
+ {
+ authResult = await clientApp.AcquireTokenSilent(scopes, account).ExecuteAsync();
+ }
+ catch (MsalUiRequiredException ex)
+ {
+ authResult = await clientApp.AcquireTokenInteractive(scopes).ExecuteAsync();
+ }
+
+if (authResult != null)
+ {
+ //Use the Access Token to access the Proxy Application
+
+ HttpClient httpClient = new HttpClient();
+ HttpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", authResult.AccessToken);
+ HttpResponseMessage response = await httpClient.GetAsync("<Proxy App Url>");
+ }
+```
+
+To configure the native app to connect to Azure Active Directory and call the API App Proxy, update the placeholder values in the *App.config* file of the NativeClient sample app with values from Azure AD:
+
+- Paste the **Directory (tenant) ID** in the `<add key="ida:Tenant" value="" />` field. You can find and copy this value (a GUID) from the **Overview** page of either of your apps.
+
+- Paste the AppProxyNativeAppSample **Application (client) ID** in the `<add key="ida:ClientId" value="" />` field. You can find and copy this value (a GUID) from the AppProxyNativeAppSample **Overview** page.
+
+- Paste the AppProxyNativeAppSample **Redirect URI** in the `<add key="ida:RedirectUri" value="" />` field. You can find and copy this value (a URI) from the AppProxyNativeAppSample **Authentication** page.
+
+- Paste the SecretAPI **Application ID URI** in the `<add key="todo:TodoListResourceId" value="" />` field. You can find and copy this value (a URI) from the SecretAPI **Expose an API** page.
+
+- Paste the SecretAPI **Home Page URL** in the `<add key="todo:TodoListBaseAddress" value="" />` field. You can find and copy this value (a URL) from the SecretAPI **Branding** page.
+
+After you configure the parameters, build and run the native app. When you select the **Sign In** button, the app lets you sign in, and then displays a success screen to confirm that it successfully connected to the SecretAPI.
+
+![Screenshot shows a message Secret A P I Successful and an OK button.](./media/application-proxy-secure-api-access/success.png)
+
+## Next steps
+
+- [Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory](application-proxy-add-on-premises-application.md)
+- [Quickstart: Configure a client application to access web APIs](../develop/quickstart-configure-app-access-web-apis.md)
+- [How to enable native client applications to interact with proxy applications](application-proxy-configure-native-client-application.md)
active-directory Application Proxy Security https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-security.md
+
+ Title: Security considerations for Azure Active Directory Application Proxy
+description: Covers security considerations for using Azure AD Application Proxy
+++++++ Last updated : 04/21/2021++++
+# Security considerations for accessing apps remotely with Azure Active Directory Application Proxy
+
+This article explains the components that work to keep your users and applications safe when you use Azure Active Directory Application Proxy.
+
+The following diagram shows how Azure AD enables secure remote access to your on-premises applications.
+
+ ![Diagram of secure remote access through Azure AD Application Proxy](./media/application-proxy-security/secure-remote-access.png)
+
+## Security benefits
+
+Azure AD Application Proxy offers the following security benefits:
+
+### Authenticated access
+
+If you choose to use Azure Active Directory preauthentication, then only authenticated connections can access your network.
+
+Azure AD Application Proxy relies on the Azure AD security token service (STS) for all authentication. Preauthentication, by its very nature, blocks a significant number of anonymous attacks, because only authenticated identities can access the back-end application.
+
+If you choose Passthrough as your preauthentication method, you don't get this benefit.
+
+### Conditional Access
+
+Apply richer policy controls before connections to your network are established.
+
+With [Conditional Access](../conditional-access/concept-conditional-access-cloud-apps.md), you can define restrictions on how users are allowed to access your applications. You can create policies that restrict sign-ins based on location, strength of authentication, and user risk profile.
+
+You can also use Conditional Access to configure Multi-Factor Authentication policies, adding another layer of security to your user authentications. Additionally, your applications can also be routed to Microsoft Cloud App Security via Azure AD Conditional Access to provide real-time monitoring and controls, via [access](/cloud-app-security/access-policy-aad) and [session](/cloud-app-security/session-policy-aad) policies
+
+### Traffic termination
+
+All traffic is terminated in the cloud.
+
+Because Azure AD Application Proxy is a reverse-proxy, all traffic to back-end applications is terminated at the service. The session can get reestablished only with the back-end server, which means that your back-end servers are not exposed to direct HTTP traffic. This configuration means that you are better protected from targeted attacks.
+
+### All access is outbound
+
+You don't need to open inbound connections to the corporate network.
+
+Application Proxy connectors only use outbound connections to the Azure AD Application Proxy service, which means that there is no need to open firewall ports for incoming connections. Traditional proxies required a perimeter network (also known as *DMZ*, *demilitarized zone*, or *screened subnet*) and allowed access to unauthenticated connections at the network edge. This scenario required investments in web application firewall products to analyze traffic and protect the environment. With Application Proxy, you don't need a perimeter network because all connections are outbound and take place over a secure channel.
+
+For more information about connectors, see [Understand Azure AD Application Proxy connectors](application-proxy-connectors.md).
+
+### Cloud-scale analytics and machine learning
+
+Get cutting-edge security protection.
+
+Because it's part of Azure Active Directory, Application Proxy can leverage [Azure AD Identity Protection](../identity-protection/overview-identity-protection.md), with data from the Microsoft Security Response Center and Digital Crimes Unit. Together we proactively identify compromised accounts and offer protection from high-risk sign-ins. We take into account numerous factors to determine which sign-in attempts are high risk. These factors include flagging infected devices, anonymizing networks, and atypical or unlikely locations.
+
+Many of these reports and events are already available through an API for integration with your security information and event management (SIEM) systems.
+
+### Remote access as a service
+
+You donΓÇÖt have to worry about maintaining and patching on-premises servers.
+
+Unpatched software still accounts for a large number of attacks. Azure AD Application Proxy is an Internet-scale service that Microsoft owns, so you always get the latest security patches and upgrades.
+
+To improve the security of applications published by Azure AD Application Proxy, we block web crawler robots from indexing and archiving your applications. Each time a web crawler robot tries to retrieve the robot's settings for a published app, Application Proxy replies with a robots.txt file that includes `User-agent: * Disallow: /`.
+
+#### Azure DDoS protection service
+
+Applications published through Application Proxy are protected against Distributed Denial of Service (DDoS) attacks. This protection is managed by Microsoft and is automatically enabled in all our datacenters. The Azure DDoS protection service provides always-on traffic monitoring and real-time mitigation of common network-level attacks.
+
+## Under the hood
+
+Azure AD Application Proxy consists of two parts:
+
+* The cloud-based service: This service runs in Azure, and is where the external client/user connections are made.
+* [The on-premises connector](application-proxy-connectors.md): An on-premises component, the connector listens for requests from the Azure AD Application Proxy service and handles connections to the internal applications.
+
+A flow between the connector and the Application Proxy service is established when:
+
+* The connector is first set up.
+* The connector pulls configuration information from the Application Proxy service.
+* A user accesses a published application.
+
+>[!NOTE]
+>All communications occur over TLS, and they always originate at the connector to the Application Proxy service. The service is outbound only.
+
+The connector uses a client certificate to authenticate to the Application Proxy service for nearly all calls. The only exception to this process is the initial setup step, where the client certificate is established.
+
+### Installing the connector
+
+When the connector is first set up, the following flow events take place:
+
+1. The connector registration to the service happens as part of the installation of the connector. Users are prompted to enter their Azure AD admin credentials. The token acquired from this authentication is then presented to the Azure AD Application Proxy service.
+2. The Application Proxy service evaluates the token. It checks whether the user is a Global Administrator in the tenant. If the user is not an administrator, the process is terminated.
+3. The connector generates a client certificate request and passes it, along with the token, to the Application Proxy service. The service in turn verifies the token and signs the client certificate request.
+4. The connector uses the client certificate for future communication with the Application Proxy service.
+5. The connector performs an initial pull of the system configuration data from the service using its client certificate, and it is now ready to take requests.
+
+### Updating the configuration settings
+
+Whenever the Application Proxy service updates the configuration settings, the following flow events take place:
+
+1. The connector connects to the configuration endpoint within the Application Proxy service by using its client certificate.
+2. After the client certificate is validated, the Application Proxy service returns configuration data to the connector (for example, the connector group that the connector should be part of).
+3. If the current certificate is more than 180 days old, the connector generates a new certificate request, which effectively updates the client certificate every 180 days.
+
+### Accessing published applications
+
+When users access a published application, the following events take place between the Application Proxy service and the Application Proxy connector:
+
+1. The service authenticates the user for the app
+2. The service places a request in the connector queue
+3. A connector processes the request from the queue
+4. The connector waits for a response
+5. The service streams data to the user
+
+To learn more about what takes place in each of these steps, keep reading.
++
+#### 1. The service authenticates the user for the app
+
+If you configured the app to use Passthrough as its preauthentication method, the steps in this section are skipped.
+
+If you configured the app to preauthenticate with Azure AD, users are redirected to the Azure AD STS to authenticate, and the following steps take place:
+
+1. Application Proxy checks for any Conditional Access policy requirements for the specific application. This step ensures that the user has been assigned to the application. If two-step verification is required, the authentication sequence prompts the user for a second authentication method.
+
+2. After all checks have passed, the Azure AD STS issues a signed token for the application and redirects the user back to the Application Proxy service.
+
+3. Application Proxy verifies that the token was issued to the correct application. It performs other checks also, such as ensuring that the token was signed by Azure AD, and that it is still within the valid window.
+
+4. Application Proxy sets an encrypted authentication cookie to indicate that authentication to the application has occurred. The cookie includes an expiration timestamp that's based on the token from Azure AD and other data, such as the user name that the authentication is based on. The cookie is encrypted with a private key known only to the Application Proxy service.
+
+5. Application Proxy redirects the user back to the originally requested URL.
+
+If any part of the preauthentication steps fails, the userΓÇÖs request is denied, and the user is shown a message indicating the source of the problem.
++
+#### 2. The service places a request in the connector queue
+
+Connectors keep an outbound connection open to the Application Proxy service. When a request comes in, the service queues up the request on one of the open connections for the connector to pick up.
+
+The request includes items from the application, such as the request headers, data from the encrypted cookie, the user making the request, and the request ID. Although data from the encrypted cookie is sent with the request, the authentication cookie itself is not.
+
+#### 3. The connector processes the request from the queue.
+
+Based on the request, Application Proxy performs one of the following actions:
+
+* If the request is a simple operation (for example, there is no data within the body as is with a RESTful *GET* request), the connector makes a connection to the target internal resource and then waits for a response.
+
+* If the request has data associated with it in the body (for example, a RESTful *POST* operation), the connector makes an outbound connection by using the client certificate to the Application Proxy instance. It makes this connection to request the data and open a connection to the internal resource. After it receives the request from the connector, the Application Proxy service begins accepting content from the user and forwards data to the connector. The connector, in turn, forwards the data to the internal resource.
+
+#### 4. The connector waits for a response.
+
+After the request and transmission of all content to the back end is complete, the connector waits for a response.
+
+After it receives a response, the connector makes an outbound connection to the Application Proxy service, to return the header details and begin streaming the return data.
+
+#### 5. The service streams data to the user. 
+
+Some processing of the application may occur here. If you configured Application Proxy to translate headers or URLs in your application, that processing happens as needed during this step.
++
+## Next steps
+
+[Network topology considerations when using Azure AD Application Proxy](application-proxy-network-topology.md)
+
+[Understand Azure AD Application Proxy connectors](application-proxy-connectors.md)
active-directory Application Proxy Sign In Bad Gateway Timeout Error https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-sign-in-bad-gateway-timeout-error.md
+
+ Title: Can't access this Corporate Application error with Azure Active Directory Application Proxy app
+description: How to resolve common access issues with Azure Active Directory Application Proxy applications.
+++++++ Last updated : 04/27/2021++++
+# "Can't Access this Corporate Application" error when using an Application Proxy application
+
+This article helps you troubleshoot common issues for the "This corporate app can't be accessed" error on an Azure AD Application Proxy application.
+
+## Overview
+
+When you see this error, find the status code on the error page. That code is likely one of the following status codes:
+
+- **Gateway Timeout**: The Application Proxy service is unable to reach the connector. This error typically indicates a problem with the connector assignment, connector itself, or the networking rules around the connector.
+- **Bad Gateway**: The connector is unable to reach the backend application. This error could indicate a misconfiguration of the application.
+- **Forbidden**: The user is not authorized to access the application. This error can happen either when the user is not assigned to the application in Azure Active Directory, or if on the backend the user does not have permission to access the application.
+
+To find the code, look at the text at the bottom left of the error message for the "Status Code" field. Also look for any additional tips at the bottom of the page.
+
+![Example: Gateway timeout error](./media/application-proxy-sign-in-bad-gateway-timeout-error/connection-problem.png)
+
+For details on how to troubleshoot the root cause of these errors and more details on suggested fixes, see the corresponding section below.
+
+## Gateway Timeout errors
+
+A gateway timeout occurs when the service tries to reach the connector and is unable to within the timeout window. This error is typically caused by an application assigned to a Connector Group with no working connectors, or some ports required by the Connector are not open.
+
+## Bad Gateway errors
+
+A bad gateway error indicates that the connector is unable to reach the backend application. make sure that you have published the correct application. Common mistakes that cause this error are:
+
+- A typo or mistake in the internal URL
+- Not publishing the root of the application. For example, publishing `http://expenses/reimbursement` but trying to access `http://expenses`
+- Problems with the Kerberos Constrained Delegation (KCD) configuration
+- Problems with the backend application
+
+## Forbidden errors
+
+If you see a forbidden error, the user has not been assigned to the application. This error could be either in Azure Active Directory or on the backend application.
+
+To learn how to assign users to the application in Azure, see the [configuration documentation](application-proxy-add-on-premises-application.md#test-the-application).
+
+If you confirm the user is assigned to the application in Azure, check the user configuration in the backend application. If you are using Kerberos Constrained Delegation/Integrated Windows Authentication, see the KCD Troubleshoot page for guidelines.
+
+## Check the application's internal URL
+
+As a first quick step, double check and fix the internal URL by opening the application through **Enterprise Applications**, then selecting the **Application Proxy** menu. Verify the internal URL is the one used from your on premises network to access the application.
+
+## Check the application is assigned to a working Connector Group
+
+To verify the application is assigned to a working Connector Group:
+
+1. Open the application in the portal by going to **Azure Active Directory**, clicking on **Enterprise Applications**, then **All Applications.** Open the application, then select **Application Proxy** from the left menu.
+1. Look at the Connector Group field. If there are no active connectors in the group, you see a warning. If you don't see any warnings, move on to verify all [required ports](application-proxy-add-on-premises-application.md) are allowed.
+1. If the wrong Connector Group is showing, use the drop-down to select the correct group, and confirm you no longer see any warnings. If the intended Connector Group is showing, click the warning message to open the page with Connector management.
+1. From here, there are a few ways to drill in further:
+
+ - Move an active Connector into the group: If you have an active Connector that should belong to this group and has line of sight to the target backend application, you can move the Connector into the assigned group. To do so, click the Connector. In the "Connector Group" field, use the drop-down to select the correct group, and click save.
+ - Download a new Connector for that group: From this page, you can get the link to [download a new Connector](https://download.msappproxy.net/Subscription/d3c8b69d-6bf7-42be-a529-3fe9c2e70c90/Connector/Download). Install the Connector on a machine with direct line of sight to the backend application. Typically, the Connector is installed on the same server as the application. Use the download Connector link to download a connector onto the target machine. Next, click the Connector, and use the "Connector Group" drop-down to make sure it belongs to the right group.
+ - Investigate an inactive Connector: If a connector shows as inactive, it is unable to reach the service. This error is typically due to some required ports being blocked. To solve this issue, move on to verify all required ports are allowed.
+
+After using these steps to ensure the application is assigned to a group with working Connectors, test the application again. If it is still not working, continue to the next section.
+
+## Check all required ports are open
+
+Verify that all required ports are open. For required ports, see the open ports section of [Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory](application-proxy-add-on-premises-application.md). If all the required ports are open, move to the next section.
+
+## Check for other Connector Errors
+
+If none of the above resolve the issue, the next step is to look for issues or errors with the Connector itself. You can see some common errors in the [Troubleshoot document](./application-proxy-troubleshoot.md#connector-errors).
+
+You can also look directly at the Connector logs to identify any errors. Many of the error messages share specific recommendations for fixes. To view the logs, see the [connectors documentation](application-proxy-connectors.md#under-the-hood).
+
+## Additional Resolutions
+
+If the above didn't fix the problem, there are a few different possible causes. To identify the issue:
+
+If your application is configured to use Integrated Windows Authentication (IWA), test the application without single sign-on. If not, move to the next paragraph. To check the application without single sign-on, open your application through **Enterprise Applications,** and go to the **Single Sign-On** menu. Change the drop-down from "Integrated Windows Authentication" to "Azure AD single sign-on disabled".
+
+Now open a browser and try to access the application again. You should be prompted for authentication and get into the application. If you are able to authenticate, the problem is with the Kerberos Constrained Delegation (KCD) configuration that enables the single sign-on. For more information, see the KCD Troubleshoot page.
+
+If you continue to see the error, go to the machine where the Connector is installed, open a browser and attempt to reach the internal URL used for the application. The Connector acts like another client from the same machine. If you can't reach the application, investigate why that machine is unable to reach the application, or use a connector on a server that is able to access the application.
+
+If you can reach the application from that machine, to look for issues or errors with the Connector itself. You can see some common errors in the [Troubleshoot document](application-proxy-troubleshoot.md#connector-errors). You can also look directly at the Connector logs to identify any errors. Many of our error messages be able to share more specific recommendations for fixes. To learn how to view the logs, see [our connectors documentation](application-proxy-connectors.md#under-the-hood).
+
+## Next steps
+
+[Understand Azure AD Application Proxy connectors](application-proxy-connectors.md)
active-directory Application Proxy Troubleshoot https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-troubleshoot.md
+
+ Title: Troubleshoot Azure Active Directory Application Proxy
+description: Covers how to troubleshoot errors in Azure Active Directory Application Proxy.
+++++++ Last updated : 04/27/2021+++++
+# Troubleshoot Application Proxy problems and error messages
+
+When troubleshooting Application Proxy issues, we recommend you start with reviewing the troubleshooting flow, [Debug Application Proxy Connector issues](../manage-apps/application-proxy-debug-connectors.md), to determine if Application Proxy connectors are configured correctly. If you're still having trouble connecting to the application, follow the troubleshooting flow in [Debug Application Proxy application issues](../manage-apps/application-proxy-debug-apps.md).
+
+If errors occur in accessing a published application or in publishing applications, check the following options to see if Microsoft Azure AD Application Proxy is working correctly:
+
+* Open the Windows Services console. Verify that the **Microsoft AAD Application Proxy Connector** service is enabled and running. You may also want to look at the Application Proxy service properties page, as shown in the following image:
+ ![Microsoft AAD Application Proxy Connector Properties window screenshot](./media/application-proxy-troubleshoot/connectorproperties.png)
+* Open Event Viewer and look for Application Proxy connector events in **Applications and Services Logs** > **Microsoft** > **AadApplicationProxy** > **Connector** > **Admin**.
+* If needed, more detailed logs are available by [turning on the Application Proxy connector session logs](application-proxy-connectors.md#under-the-hood).
+
+## The page is not rendered correctly
+You may have problems with your application rendering or functioning incorrectly without receiving specific error messages. This can occur if you published the article path, but the application requires content that exists outside that path.
+
+For example, if you publish the path `https://yourapp/app` but the application calls images in `https://yourapp/media`, they won't be rendered. Make sure that you publish the application using the highest level path you need to include all relevant content. In this example, it would be `http://yourapp/`.
+
+## Connector errors
+
+If registration fails during the Connector wizard installation, there are two ways to view the reason for the failure. Either look in the event log under **Applications and Services Logs\Microsoft\AadApplicationProxy\Connector\Admin**, or run the following Windows PowerShell command:
+
+```powershell
+Get-EventLog application ΓÇôsource "Microsoft AAD Application Proxy Connector" ΓÇôEntryType "Error" ΓÇôNewest 1
+```
+
+Once you find the Connector error from the event log, use this table of common errors to resolve the problem:
+
+| Error | Recommended steps |
+| -- | -- |
+| Connector registration failed: Make sure you enabled Application Proxy in the Azure Management Portal and that you entered your Active Directory user name and password correctly. Error: 'One or more errors occurred.' | If you closed the registration window without signing in to Azure AD, run the Connector wizard again and register the Connector. <br><br> If the registration window opens and then immediately closes without allowing you to log in, you'll probably get this error. This error occurs when there is a networking error on your system. Make sure that it's possible to connect from a browser to a public website and that the ports are open as specified in [Application Proxy prerequisites](application-proxy-add-on-premises-application.md#prepare-your-on-premises-environment). |
+| Clear error is presented in the registration window. Cannot proceed | If you see this error and then the window closes, you entered the wrong username or password. Try again. |
+| Connector registration failed: Make sure you enabled Application Proxy in the Azure Management Portal and that you entered your Active Directory user name and password correctly. Error: 'AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials and search by service principal URI has failed. | You're trying to sign in using a Microsoft Account and not a domain that is part of the organization ID of the directory you're trying to access. Make sure that the admin is part of the same domain name as the tenant domain, for example, if the Azure AD domain is contoso.com, the admin should be admin@contoso.com. |
+| Failed to retrieve the current execution policy for running PowerShell scripts. | If the Connector installation fails, check to make sure that PowerShell execution policy isn't disabled. <br><br>1. Open the Group Policy Editor.<br>2. Go to **Computer Configuration** > **Administrative Templates** > **Windows Components** > **Windows PowerShell** and double-click **Turn on Script Execution**.<br>3. The execution policy can be set to either **Not Configured** or **Enabled**. If set to **Enabled**, make sure that under Options, the Execution Policy is set to either **Allow local scripts and remote signed scripts** or to **Allow all scripts**. |
+| Connector failed to download the configuration. | The ConnectorΓÇÖs client certificate, which is used for authentication, expired. This may also occur if you have the Connector installed behind a proxy. In this case, the Connector cannot access the Internet and will not be able to provide applications to remote users. Renew trust manually using the `Register-AppProxyConnector` cmdlet in Windows PowerShell. If your Connector is behind a proxy, it is necessary to grant Internet access to the Connector accounts ΓÇ£network servicesΓÇ¥ and ΓÇ£local system.ΓÇ¥ This can be accomplished either by granting them access to the Proxy or by setting them to bypass the proxy. |
+| Connector registration failed: Make sure you are an Application Administrator of your Active Directory to register the Connector. Error: 'The registration request was denied.' | The alias you're trying to log in with isn't an admin on this domain. Your Connector is always installed for the directory that owns the userΓÇÖs domain. Make sure that the admin account you're trying to sign in with has atleast application administrator permissions to the Azure AD tenant. |
+| The Connector was unable to connect to the service due to networking issues. The Connector tried to access the following URL. | The connector is unable to connect to the Application Proxy cloud service. This may happen if you have a firewall rule blocking the connection. Make sure that you have allowed access to the correct ports and URLS listed in [Application Proxy prerequisites](application-proxy-add-on-premises-application.md#prepare-your-on-premises-environment). |
+
+## Kerberos errors
+
+This table covers the more common errors that come from Kerberos setup and configuration, and includes suggestions for resolution.
+
+| Error | Recommended steps |
+| -- | -- |
+| Failed to retrieve the current execution policy for running PowerShell scripts. | If the Connector installation fails, check to make sure that PowerShell execution policy is not disabled.<br><br>1. Open the Group Policy Editor.<br>2. Go to **Computer Configuration** > **Administrative Templates** > **Windows Components** > **Windows PowerShell** and double-click **Turn on Script Execution**.<br>3. The execution policy can be set to either **Not Configured** or **Enabled**. If set to **Enabled**, make sure that under Options, the Execution Policy is set to either **Allow local scripts and remote signed scripts** or to **Allow all scripts**. |
+| 12008 - Azure AD exceeded the maximum number of permitted Kerberos authentication attempts to the backend server. | This error may indicate incorrect configuration between Azure AD and the backend application server, or a problem in time and date configuration on both machines. The backend server declined the Kerberos ticket created by Azure AD. Verify that Azure AD and the backend application server are configured correctly. Make sure that the time and date configuration on the Azure AD and the backend application server are synchronized. |
+| 13016 - Azure AD cannot retrieve a Kerberos ticket on behalf of the user because there is no UPN in the edge token or in the access cookie. | There is a problem with the STS configuration. Fix the UPN claim configuration in the STS. |
+| 13019 - Azure AD cannot retrieve a Kerberos ticket on behalf of the user because of the following general API error. | This event may indicate incorrect configuration between Azure AD and the domain controller server, or a problem in time and date configuration on both machines. The domain controller declined the Kerberos ticket created by Azure AD. Verify that Azure AD and the backend application server are configured correctly, especially the SPN configuration. Make sure the Azure AD is domain joined to the same domain as the domain controller to ensure that the domain controller establishes trust with Azure AD. Make sure that the time and date configuration on the Azure AD and the domain controller are synchronized. |
+| 13020 - Azure AD cannot retrieve a Kerberos ticket on behalf of the user because the backend server SPN is not defined. | This event may indicate incorrect configuration between Azure AD and the domain controller server, or a problem in time and date configuration on both machines. The domain controller declined the Kerberos ticket created by Azure AD. Verify that Azure AD and the backend application server are configured correctly, especially the SPN configuration. Make sure the Azure AD is domain joined to the same domain as the domain controller to ensure that the domain controller establishes trust with Azure AD. Make sure that the time and date configuration on the Azure AD and the domain controller are synchronized. |
+| 13022 - Azure AD cannot authenticate the user because the backend server responds to Kerberos authentication attempts with an HTTP 401 error. | This event may indicate incorrect configuration between Azure AD and the backend application server, or a problem in time and date configuration on both machines. The backend server declined the Kerberos ticket created by Azure AD. Verify that Azure AD and the backend application server are configured correctly. Make sure that the time and date configuration on the Azure AD and the backend application server are synchronized. For more information, see [Troubleshoot Kerberos Constrained Delegation Configurations for Application Proxy](application-proxy-back-end-kerberos-constrained-delegation-how-to.md). |
+
+## End-user errors
+
+This list covers errors that your end users might encounter when they try to access the app and fail.
+
+| Error | Recommended steps |
+| -- | -- |
+| The website cannot display the page. | Your user may get this error when trying to access the app you published if the application is an IWA application. The defined SPN for this application may be incorrect. For IWA apps, make sure that the SPN configured for this application is correct. |
+| The website cannot display the page. | Your user may get this error when trying to access the app you published if the application is an OWA application. This could be caused by one of the following:<br><li>The defined SPN for this application is incorrect. Make sure that the SPN configured for this application is correct.</li><li>The user who tried to access the application is using a Microsoft account rather than the proper corporate account to sign in, or the user is a guest user. Make sure the user signs in using their corporate account that matches the domain of the published application. Microsoft Account users and guest cannot access IWA applications.</li><li>The user who tried to access the application is not properly defined for this application on the on premises side. Make sure that this user has the proper permissions as defined for this backend application on the on premises machine. |
+| This corporate app canΓÇÖt be accessed. You are not authorized to access this application. Authorization failed. Make sure to assign the user with access to this application. | Your user may get this error when trying to access the app you published if they use Microsoft accounts instead of their corporate account to sign in. Guest users may also get this error. Microsoft Account users and guests cannot access IWA applications. Make sure the user signs in using their corporate account that matches the domain of the published application.<br><br>You may not have assigned the user for this application. Go to the **Application** tab, and under **Users and Groups**, assign this user or user group to this application. |
+| This corporate app can’t be accessed right now. Please try again later…The connector timed out. | Your user may get this error when trying to access the app you published if they are not properly defined for this application on the on-premises side. Make sure that your users have the proper permissions as defined for this backend application on the on premises machine. |
+| This corporate app canΓÇÖt be accessed. You are not authorized to access this application. Authorization failed. Make sure that the user has a license for Azure Active Directory Premium. | Your user may get this error when trying to access the app you published if they weren't explicitly assigned with a Premium license by the subscriberΓÇÖs administrator. Go to the subscriberΓÇÖs Active Directory **Licenses** tab and make sure that this user or user group is assigned a Premium license. |
+| A server with the specified host name could not be found. | Your user may get this error when trying to access the app you published if the application's custom domain is not configured correctly. Make sure you've uploaded a certificate for the domain and configured the DNS record correctly by following the steps in [Working with custom domains in Azure AD Application Proxy](../manage-apps/application-proxy-configure-custom-domain.md) |
+|Forbidden: This corporate app can't be accessed OR The user could not be authorized. Make sure the user is defined in your on-premises AD and that the user has access to the app in your on-premises AD. | This could be a problem with access to authorization information, see [Some applications and APIs require access to authorization information on account objects]( https://support.microsoft.com/help/331951/some-applications-and-apis-require-access-to-authorization-information). In a nutshell, add the app proxy connector machine account to the "Windows Authorization Access Group" builtin domain group to resolve. |
+
+## My error wasn't listed here
+
+If you encounter an error or problem with Azure AD Application Proxy that isn't listed in this troubleshooting guide, we'd like to hear about it. Send an email to our [feedback team](mailto:aadapfeedback@microsoft.com) with the details of the error you encountered.
+
+## See also
+* [Enable Application Proxy for Azure Active Directory](application-proxy-add-on-premises-application.md)
+* [Publish applications with Application Proxy](application-proxy-add-on-premises-application.md)
+* [Enable single sign-on](application-proxy-configure-single-sign-on-with-kcd.md)
+* [Enable Conditional Access](../manage-apps/application-proxy-integrate-with-sharepoint-server.md)
++
+<!--Image references-->
+[1]: ./media/application-proxy-troubleshoot/connectorproperties.png
+[2]: ./media/active-directory-application-proxy-troubleshoot/sessionlog.png
active-directory Application Proxy Wildcard https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy-wildcard.md
+
+ Title: Wildcard applications in Azure Active Directory Application Proxy
+description: Learn how to use Wildcard applications in Azure Active Directory Application Proxy.
+++++++ Last updated : 04/27/2021+++++
+# Wildcard applications in the Azure Active Directory Application Proxy
+
+In Azure Active Directory (Azure AD), configuring a large number of on-premises applications can quickly become unmanageable and introduces unnecessary risks for configuration errors if many of them require the same settings. With [Azure AD Application Proxy](application-proxy.md), you can address this issue by using wildcard application publishing to publish and manage many applications at once. This is a solution that allows you to:
+
+- Simplify your administrative overhead
+- Reduce the number of potential configuration errors
+- Enable your users to securely access more resources
+
+This article provides you with the information you need to configure wildcard application publishing in your environment.
+
+## Create a wildcard application
+
+You can create a wildcard (*) application if you have a group of applications with the same configuration. Potential candidates for a wildcard application are applications sharing the following settings:
+
+- The group of users having access to them
+- The SSO method
+- The access protocol (http, https)
+
+You can publish applications with wildcards if both, the internal and external URLs are in the following format:
+
+> http(s)://*.\<domain\>
+
+For example: `http(s)://*.adventure-works.com`.
+
+While the internal and external URLs can use different domains, as a best practice, they should be same. When publishing the application, you see an error if one of the URLs doesn't have a wildcard.
+
+Creating a wildcard application is based on the same [application publishing flow](application-proxy-add-on-premises-application.md) that is available for all other applications. The only difference is that you include a wildcard in the URLs and potentially the SSO configuration.
+
+## Prerequisites
+
+To get started, make sure you've met these requirements.
+
+### Custom domains
+
+While [custom domains](../manage-apps/application-proxy-configure-custom-domain.md) are optional for all other applications, they are a prerequisite for wildcard applications. Creating custom domains requires you to:
+
+1. Create a verified domain within Azure.
+1. Upload a TLS/SSL certificate in the PFX format to your application proxy.
+
+You should consider using a wildcard certificate to match the application you plan to create.
+
+For security reasons, this is a hard requirement and we will not support wildcards for applications that cannot use a custom domain for the external URL.
+
+### DNS updates
+
+When using custom domains, you need to create a DNS entry with a CNAME record for the external URL (for example, `*.adventure-works.com`) pointing to the external URL of the application proxy endpoint. For wildcard applications, the CNAME record needs to point to the relevant external URL:
+
+> `<yourAADTenantId>.tenant.runtime.msappproxy.net`
+
+To confirm that you have configured your CNAME correctly, you can use [nslookup](/windows-server/administration/windows-commands/nslookup) on one of the target endpoints, for example, `expenses.adventure-works.com`. Your response should include the already mentioned alias (`<yourAADTenantId>.tenant.runtime.msappproxy.net`).
+
+### Using connector groups assigned to an App Proxy cloud service region other than the default region
+If you have connectors installed in regions different from your default tenant region, it may be beneficial to change which region your connector group is optimized for to improve performance accessing these applications. To learn more see, [Optimize connector groups to use closest Application Proxy cloud service](application-proxy-network-topology.md#optimize-connector-groups-to-use-closest-application-proxy-cloud-service-preview).
+
+If the connector group assigned to the wildcard application uses a **different region than your default region**, you will need to update the CNAME record to point to a regional specific external URL. Use the following table to determine the relevant URL:
+
+| Connector Assigned Region | External URL |
+| | |
+| Asia | `<yourAADTenantId>.asia.tenant.runtime.msappproxy.net`|
+| Australia | `<yourAADTenantId>.aus.tenant.runtime.msappproxy.net` |
+| Europe | `<yourAADTenantId>.eur.tenant.runtime.msappproxy.net`|
+| North America | `<yourAADTenantId>.nam.tenant.runtime.msappproxy.net` |
+
+## Considerations
+
+Here are some considerations you should take into account for wildcard applications.
+
+### Accepted formats
+
+For wildcard applications, the **Internal URL** must be formatted as `http(s)://*.<domain>`.
+
+![For internal URL, use the format http(s)://*.\<domain>](./media/application-proxy-wildcard/22.png)
+
+When you configure an **External URL**, you must use the following format: `https://*.<custom domain>`
+
+![For external URL, use the format https://*.\<custom domain>](./media/application-proxy-wildcard/21.png)
+
+Other positions of the wildcard, multiple wildcards, or other regex strings are not supported and are causing errors.
+
+### Excluding applications from the wildcard
+
+You can exclude an application from the wildcard application by
+
+- Publishing the exception application as regular application
+- Enabling the wildcard only for specific applications through your DNS settings
+
+Publishing an application as regular application is the preferred method to exclude an application from a wildcard. You should publish the excluded applications before the wildcard applications to ensure that your exceptions are enforced from the beginning. The most specific application will always take precedence ΓÇô an application published as `budgets.finance.adventure-works.com` takes precedence over the application `*.finance.adventure-works.com`, which in turn takes precedence over the application `*.adventure-works.com`.
+
+You can also limit the wildcard to only work for specific applications through your DNS management. As a best practice, you should create a CNAME entry that includes a wildcard and matches the format of the external URL you have configured. However, you can instead point specific application URLs to the wildcards. For example, instead of `*.adventure-works.com`, point `hr.adventure-works.com`, `expenses.adventure-works.com` and `travel.adventure-works.com individually` to `000aa000-11b1-2ccc-d333-4444eee4444e.tenant.runtime.msappproxy.net`.
+
+If you use this option, you also need another CNAME entry for the value `AppId.domain`, for example, `00000000-1a11-22b2-c333-444d4d4dd444.adventure-works.com`, also pointing to the same location. You can find the **AppId** on the application properties page of the wildcard application:
+
+![Find the application ID on the app's property page](./media/application-proxy-wildcard/01.png)
+
+### Setting the homepage URL for the MyApps panel
+
+The wildcard application is represented with just one tile in the [MyApps panel](https://myapps.microsoft.com). By default this tile is hidden. To show the tile and have users land on a specific page:
+
+1. Follow the guidelines for [setting a homepage URL](application-proxy-configure-custom-home-page.md).
+1. Set **Show Application** to **true** on the application properties page.
+
+### Kerberos constrained delegation
+
+For applications using [kerberos constrained delegation (KCD) as the SSO method](../manage-apps/application-proxy-configure-single-sign-on-with-kcd.md), the SPN listed for the SSO method may also need a wildcard. For example, the SPN could be: `HTTP/*.adventure-works.com`. You still need to have the individual SPNs configured on your backend servers (for example, `HTTP/expenses.adventure-works.com and HTTP/travel.adventure-works.com`).
+
+## Scenario 1: General wildcard application
+
+In this scenario, you have three different applications you want to publish:
+
+- `expenses.adventure-works.com`
+- `hr.adventure-works.com`
+- `travel.adventure-works.com`
+
+All three applications:
+
+- Are used by all your users
+- Use *Integrated Windows Authentication*
+- Have the same properties
+
+You can publish the wildcard application using the steps outlined in [Publish applications using Azure AD Application Proxy](application-proxy-add-on-premises-application.md). This scenario assumes:
+
+- A tenant with the following ID: `000aa000-11b1-2ccc-d333-4444eee4444e`
+- A verified domain called `adventure-works.com` has been configured.
+- A **CNAME** entry that points `*.adventure-works.com` to `000aa000-11b1-2ccc-d333-4444eee4444e.tenant.runtime.msappproxy.net` has been created.
+
+Following the [documented steps](application-proxy-add-on-premises-application.md), you create a new Application Proxy application in your tenant. In this example, the wildcard is in the following fields:
+
+- Internal URL:
+
+ ![Example: Wildcard in internal URL](./media/application-proxy-wildcard/42.png)
+
+- External URL:
+
+ ![Example: Wildcard in external URL](./media/application-proxy-wildcard/43.png)
+
+- Internal Application SPN:
+
+ ![Example: Wildcard in SPN configuration](./media/application-proxy-wildcard/44.png)
+
+By publishing the wildcard application, you can now access your three applications by navigating to the URLs you are used to (for example, `travel.adventure-works.com`).
+
+The configuration implements the following structure:
+
+![Shows the structure implemented by the example configuration](./media/application-proxy-wildcard/05.png)
+
+| Color | Description |
+| | |
+| Blue | Applications explicitly published and visible in the Azure portal. |
+| Gray | Applications you can accessible through the parent application. |
+
+## Scenario 2: General wildcard application with exception
+
+In this scenario, you have in addition to the three general applications another application, `finance.adventure-works.com`, which should only be accessible by Finance division. With the current application structure, your finance application would be accessible through the wildcard application and by all employees. To change this, you exclude your application from your wildcard by configuring Finance as a separate application with more restrictive permissions.
+
+You need to make sure that a CNAME records exist that points `finance.adventure-works.com` to the application specific endpoint, specified on the Application Proxy page for the application. For this scenario, `finance.adventure-works.com` points to `https://finance-awcycles.msappproxy.net/`.
+
+Following the [documented steps](application-proxy-add-on-premises-application.md), this scenario requires the following settings:
+
+- In the **Internal URL**, you set **finance** instead of a wildcard.
+
+ ![Example: Set finance instead of a wildcard in internal URL](./media/application-proxy-wildcard/52.png)
+
+- In the **External URL**, you set **finance** instead of a wildcard.
+
+ ![Example: Set finance instead of a wildcard in external URL](./media/application-proxy-wildcard/53.png)
+
+- Internal Application SPN you set **finance** instead of a wildcard.
+
+ ![Example: Set finance instead of a wildcard in SPN configuration](./media/application-proxy-wildcard/54.png)
+
+This configuration implements the following scenario:
+
+![Shows the configuration implemented by the sample scenario](./media/application-proxy-wildcard/09.png)
+
+Because `finance.adventure-works.com` is a more specific URL than `*.adventure-works.com`, it takes precedence. Users navigating to `finance.adventure-works.com` have the experience specified in the Finance Resources application. In this case, only finance employees are able to access `finance.adventure-works.com`.
+
+If you have multiple applications published for finance and you have `finance.adventure-works.com` as a verified domain, you could publish another wildcard application `*.finance.adventure-works.com`. Because this is more specific than the generic `*.adventure-works.com`, it takes precedence if a user accesses an application in the finance domain.
+
+## Next steps
+
+- To learn more about **Custom domains**, see [Working with custom domains in Azure AD Application Proxy](../manage-apps/application-proxy-configure-custom-domain.md).
+- To learn more about **Publishing applications**, see [Publish applications using Azure AD Application Proxy](application-proxy-add-on-premises-application.md)
active-directory Application Proxy https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-proxy.md
+
+ Title: Remote access to on-premises apps - Azure AD Application Proxy
+description: Azure Active Directory's Application Proxy provides secure remote access to on-premises web applications. After a single sign-on to Azure AD, users can access both cloud and on-premises applications through an external URL or an internal application portal. For example, Application Proxy can provide remote access and single sign-on to Remote Desktop, SharePoint, Teams, Tableau, Qlik, and line of business (LOB) applications.
+++++++ Last updated : 04/27/2021++++
+# Remote access to on-premises applications through Azure AD Application Proxy
+
+Azure Active Directory's Application Proxy provides secure remote access to on-premises web applications. After a single sign-on to Azure AD, users can access both cloud and on-premises applications through an external URL or an internal application portal. For example, Application Proxy can provide remote access and single sign-on to Remote Desktop, SharePoint, Teams, Tableau, Qlik, and line of business (LOB) applications.
+
+Azure AD Application Proxy is:
+
+- **Simple to use**. Users can access your on-premises applications the same way they access Microsoft 365 and other SaaS apps integrated with Azure AD. You don't need to change or update your applications to work with Application Proxy.
+
+- **Secure**. On-premises applications can use Azure's authorization controls and security analytics. For example, on-premises applications can use Conditional Access and two-step verification. Application Proxy doesn't require you to open inbound connections through your firewall.
+
+- **Cost-effective**. On-premises solutions typically require you to set up and maintain demilitarized zones (DMZs), edge servers, or other complex infrastructures. Application Proxy runs in the cloud, which makes it easy to use. To use Application Proxy, you don't need to change the network infrastructure or install additional appliances in your on-premises environment.
+
+## What is Application Proxy?
+Application Proxy is a feature of Azure AD that enables users to access on-premises web applications from a remote client. Application Proxy includes both the Application Proxy service which runs in the cloud, and the Application Proxy connector which runs on an on-premises server. Azure AD, the Application Proxy service, and the Application Proxy connector work together to securely pass the user sign-on token from Azure AD to the web application.
+
+Application Proxy works with:
+
+* Web applications that use [Integrated Windows Authentication](../manage-apps/application-proxy-configure-single-sign-on-with-kcd.md) for authentication
+* Web applications that use form-based or [header-based](../manage-apps/application-proxy-configure-single-sign-on-with-headers.md) access
+* Web APIs that you want to expose to rich applications on different devices
+* Applications hosted behind a [Remote Desktop Gateway](../manage-apps/application-proxy-integrate-with-remote-desktop-services.md)
+* Rich client apps that are integrated with the Microsoft Authentication Library (MSAL)
+
+Application Proxy supports single sign-on. For more information on supported methods, see [Choosing a single sign-on method](../manage-apps/sso-options.md#choosing-a-single-sign-on-method).
+
+Application Proxy is recommended for giving remote users access to internal resources. Application Proxy replaces the need for a VPN or reverse proxy. It is not intended for internal users on the corporate network. These users who unnecessarily use Application Proxy can introduce unexpected and undesirable performance issues.
+
+## How Application Proxy works
+
+The following diagram shows how Azure AD and Application Proxy work together to provide single sign-on to on-premises applications.
+
+![AzureAD Application Proxy diagram](./media/application-proxy/azureappproxxy.png)
+
+1. After the user has accessed the application through an endpoint, the user is directed to the Azure AD sign-in page.
+2. After a successful sign-in, Azure AD sends a token to the user's client device.
+3. The client sends the token to the Application Proxy service, which retrieves the user principal name (UPN) and security principal name (SPN) from the token. Application Proxy then sends the request to the Application Proxy connector.
+4. If you have configured single sign-on, the connector performs any additional authentication required on behalf of the user.
+5. The connector sends the request to the on-premises application.
+6. The response is sent through the connector and Application Proxy service to the user.
+
+> [!NOTE]
+> Like most Azure AD hybrid agents, the Application Proxy Connector doesn't require you to open inbound connections through your firewall. User traffic in step 3 terminates at the Application Proxy Service (in Azure AD). The Application Proxy Connector (on-premises) is responsible for the rest of the communication.
+>
++
+| Component | Description |
+| | -- |
+| Endpoint | The endpoint is a URL or an [end-user portal](../manage-apps/end-user-experiences.md). Users can reach applications while outside of your network by accessing an external URL. Users within your network can access the application through a URL or an end-user portal. When users go to one of these endpoints, they authenticate in Azure AD and then are routed through the connector to the on-premises application.|
+| Azure AD | Azure AD performs the authentication using the tenant directory stored in the cloud. |
+| Application Proxy service | This Application Proxy service runs in the cloud as part of Azure AD. It passes the sign-on token from the user to the Application Proxy Connector. Application Proxy forwards any accessible headers on the request and sets the headers as per its protocol, to the client IP address. If the incoming request to the proxy already has that header, the client IP address is added to the end of the comma separated list that is the value of the header.|
+| Application Proxy Connector | The connector is a lightweight agent that runs on a Windows Server inside your network. The connector manages communication between the Application Proxy service in the cloud and the on-premises application. The connector only uses outbound connections, so you don't have to open any inbound ports or put anything in the DMZ. The connectors are stateless and pull information from the cloud as necessary. For more information about connectors, like how they load-balance and authenticate, see [Understand Azure AD Application Proxy connectors](application-proxy-connectors.md).|
+| Active Directory (AD) | Active Directory runs on-premises to perform authentication for domain accounts. When single sign-on is configured, the connector communicates with AD to perform any additional authentication required.
+| On-premises application | Finally, the user is able to access an on-premises application.
+
+## Next steps
+To start using Application Proxy, see [Tutorial: Add an on-premises application for remote access through Application Proxy](application-proxy-add-on-premises-application.md).
active-directory Application Sign In Problem On Premises Application Proxy https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/application-sign-in-problem-on-premises-application-proxy.md
+
+ Title: Problem signing in to on-premises app using Azure Active Directory Application Proxy
+description: Troubleshooting common issues faced when you are unable to sign in to an on-premises application integrated using the Azure Active Directory Application Proxy
+++++++ Last updated : 04/27/2021++++
+# Problems signing in to an on-premises application using the Azure Active Directory Application Proxy
+
+If you are having problems signing in an on-premises application, you can try following the steps below to resolving your problem.
+
+## I can load my application, but something on the page looks broken
+
+The following documents can help you to resolve some of the most common issues in this category.
+
+ * [I can get to my application, but the application page isn't displaying correctly](application-proxy-page-appearance-broken-problem.md)
+ * [I can get to my application, but the application takes too long to load](application-proxy-page-load-speed-problem.md)
+ * [I can get to my application, but the links on the application page do not work](application-proxy-page-links-broken-problem.md)
+
+## I'm having a connectivity problem my application
+ The following documents can help you to resolve some of the most common issues in this category.
+ * [I don't know what ports to open for my application](application-proxy-add-on-premises-application.md)
+ * [I encountered a problem because there was no working connector in a connector group for my application](application-proxy-connectivity-no-working-connector.md)
+
+## I'm having a problem configuring the Azure AD Application Proxy in the admin portal
+ The following documents can help you to resolve some of the most common issues in this category.
+ * [I am having difficulty configuring an application Proxy application](application-proxy-config-how-to.md)
+ * [I don't know how to configure single sign-on to my application Proxy application](application-proxy-config-sso-how-to.md)
+ * [I encountered a problem when creating my application in admin portal](application-proxy-config-problem.md)
+
+## I'm having a problem setting up back-end authentication to my application
+ The following documents can help you to resolve some of the most common issues in this category.
+ * [I don't know how to configure Kerberos Constrained Delegation](application-proxy-back-end-kerberos-constrained-delegation-how-to.md)
+ * [I don't know how to configure my application with PingAccess](../manage-apps/application-proxy-ping-access-publishing-guide.md)
+
+## I'm having a problem when signing in to my application
+ The following documents can help you to resolve some of the most common issues in this category.
+ * [I get a "Can't Access this Corporate Application" error](application-proxy-sign-in-bad-gateway-timeout-error.md)
+
+## I'm having a problem with the Application Proxy Agent Connector
+ The following documents can help you to resolve some of the most common issues in this category.
+ * [I am having issues installing the Application Proxy Agent Connector](application-proxy-connector-installation-problem.md)
+
+## Next steps
+[How to provide secure remote access to on-premises applications](application-proxy.md)
active-directory What Is Application Proxy https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/app-proxy/what-is-application-proxy.md
Connector groups are useful when you need to support the following scenarios:
* Application segmentation/isolation * Publishing web apps running in the cloud or on-premises
-For more information about choosing where to install your connectors and optimizing your network, see [Network topology considerations when using Azure Active Directory Application Proxy](../manage-apps/application-proxy-network-topology.md).
+For more information about choosing where to install your connectors and optimizing your network, see [Network topology considerations when using Azure Active Directory Application Proxy](application-proxy-network-topology.md).
## Other use cases
active-directory Howto Password Ban Bad On Premises Deploy https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/authentication/howto-password-ban-bad-on-premises-deploy.md
The following requirements apply to the Azure AD Password Protection proxy servi
* All machines that host the Azure AD Password Protection proxy service must be configured to grant domain controllers the ability to log on to the proxy service. This ability is controlled via the "Access this computer from the network" privilege assignment. * All machines that host the Azure AD Password Protection proxy service must be configured to allow outbound TLS 1.2 HTTP traffic. * A *Global Administrator* or *Security Administrator* account to register the Azure AD Password Protection proxy service and forest with Azure AD.
-* Network access must be enabled for the set of ports and URLs specified in the [Application Proxy environment setup procedures](../manage-apps/application-proxy-add-on-premises-application.md#prepare-your-on-premises-environment).
+* Network access must be enabled for the set of ports and URLs specified in the [Application Proxy environment setup procedures](../app-proxy/application-proxy-add-on-premises-application.md#prepare-your-on-premises-environment).
### Microsoft Azure AD Connect Agent Updater prerequisites The Microsoft Azure AD Connect Agent Updater service is installed side by side with the Azure AD Password Protection Proxy service. Additional configuration is required in order for the Microsoft Azure AD Connect Agent Updater service to be able to function: * If your environment uses an HTTP proxy server, follow the guidelines specified in [Work with existing on-premises proxy servers](../manage-apps/application-proxy-configure-connectors-with-proxy-servers.md).
-* The Microsoft Azure AD Connect Agent Updater service also requires the TLS 1.2 steps specified in [TLS requirements](../manage-apps/application-proxy-add-on-premises-application.md#tls-requirements).
+* The Microsoft Azure AD Connect Agent Updater service also requires the TLS 1.2 steps specified in [TLS requirements](../app-proxy/application-proxy-add-on-premises-application.md#tls-requirements).
> [!WARNING] > Azure AD Password Protection proxy and Azure AD Application Proxy install different versions of the Microsoft Azure AD Connect Agent Updater service, which is why the instructions refer to Application Proxy content. These different versions are incompatible when installed side by side and doing so will prevent the Agent Updater service from contacting Azure for software updates, so you should never install Azure AD Password Protection Proxy and Application Proxy on the same machine.
active-directory How To Gmsa Cmdlets https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/cloud-sync/how-to-gmsa-cmdlets.md
# Azure AD Connect cloud provisioning agent gMSA PowerShell cmdlets
-The purpose of this document is to describe the Azure AD Connect cloud provisioning agent gMSA PowerShell cmdlets. These cmdlets allow you to have more granularity on the permissions that are applied on the service account (gmsa). By default, Azure AD Connect cloud sync applies all permissions similar to Azure AD Connect on the default gmsa or a custom gmsa.
+The purpose of this document is to describe the Azure AD Connect cloud provisioning agent gMSA PowerShell cmdlets. These cmdlets allow you to have more granularity on the permissions that are applied on the service account (gmsa). By default, Azure AD Connect cloud sync applies all permissions similar to Azure AD Connect on the default gmsa or a custom gmsa.
-This document will cover the following cmdlets:ΓÇ»
+This document will cover the following cmdlets:
`Set-AADCloudSyncRestrictedPermissions`
-`Set-AADCloudSyncPermissions`
+`Set-AADCloudSyncPermissions`
-## How to use the cmdlets:ΓÇ»
+## How to use the cmdlets:
The following prerequisites are required to use these cmdlets.
-1. Install provisioning agent.
-2. Import Provisioning Agent PS module into a PowerShell session.
+1. Install provisioning agent.
- ```PowerShell
- Import-Module "C:\Program Files\Microsoft Azure AD Connect Provisioning Agent\Microsoft.CloudSync.Powershell.dll" 
- ```
-3. Remove existing permissions. To remove all existing permissions on the service account, except SELF use: `Set-AADCloudSyncRestrictedPermission`.
+2. Import Provisioning Agent PS module into a PowerShell session.
- This cmdlet requires a parameter called `Credential` which can be passed, or it will prompt if called without it.
+ ```powershell
+ Import-Module "C:\Program Files\Microsoft Azure AD Connect Provisioning Agent\Microsoft.CloudSync.Powershell.dll"
+ ```
+
+3. Remove existing permissions. To remove all existing permissions on the service account, except SELF use: `Set-AADCloudSyncRestrictedPermission`.
+
+ This cmdlet requires a parameter called `Credential` which can be passed, or it will prompt if called without it.
+
+ To create a variable, use:
- To create a variable use
+ `$credential = Get-Credential`
- `$credential = Get-Credential`
+ This will prompt the user to enter username and password. The credentials must be at a minimum domain administrator(of the domain where agent is installed), could be enterprise admin as well.
- This will prompt the user to enter username and password. The credentials must be at a minimum domain administrator(of the domain where agent is installed), could be enterprise admin as well.
+4. Then you can call the cmdlet to remove extra permissions:
-4. Then you can call the cmdlet to remove extra permissions:
- ```PowerShell
+ ```powershell
Set-AADCloudSyncRestrictedPermissions -Credential $credential ```
-5. Or you could simply call
- `Set-AADCloudSyncRestrictedPermissions` which will prompt for credentials.
+5. Or you can simply call:
- 6. Add specific permission type. Permissions added are same as Azure AD Connect. See [Using Set-AADCloudSyncPermissions](#using-set-aadcloudsyncpermissions) below for examples on setting the permissions.
+ `Set-AADCloudSyncRestrictedPermissions` which will prompt for credentials.
-## Using Set-AADCloudSyncPermissions
-`Set-AADCloudSyncPermissions` supports the following permission types which are identical to the permissions used by Azure AD Connect. The following permission types are supported:
+6. Add specific permission type. Permissions added are same as Azure AD Connect. See [Using Set-AADCloudSyncPermissions](#using-set-aadcloudsyncpermissions) below for examples on setting the permissions.
+
+## Using Set-AADCloudSyncPermissions
+
+`Set-AADCloudSyncPermissions` supports the following permission types which are identical to the permissions used by Azure AD Connect. The following permission types are supported:
|Permission type|Description| |--|--| |BasicRead| See [BasicRead](../../active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account.md#configure-basic-read-only-permissions) permissions for Azure AD Connect| |PasswordHashSync|See [PasswordHashSync](../../active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account.md#permissions-for-password-hash-synchronization) permissions for Azure AD Connect| |PasswordWriteBack|See [PasswordWriteBack](../../active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account.md#permissions-for-password-writeback) permissions for Azure AD Connect|
-|HybridExchangePermissions|See [HybridExchangePermissions](../../active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account.md#permissions-for-exchange-hybrid-deployment) permissions for Azure AD Connect|
-|ExchangeMailPublicFolderPermissions| See [ExchangeMailPublicFolderPermissions](../../active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account.md#permissions-for-exchange-mail-public-folders-preview) permissions for Azure AD Connect|
-|CloudHR| Applies 'Full control' on 'Descendant User objects' and 'Create/delete User objects' on 'This object and all descendant objects'|
-|All|adds all the above permissions.|
+|HybridExchangePermissions|See [HybridExchangePermissions](../../active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account.md#permissions-for-exchange-hybrid-deployment) permissions for Azure AD Connect|
+|ExchangeMailPublicFolderPermissions| See [ExchangeMailPublicFolderPermissions](../../active-directory/hybrid/how-to-connect-configure-ad-ds-connector-account.md#permissions-for-exchange-mail-public-folders-preview) permissions for Azure AD Connect|
+|CloudHR| Applies 'Full control' on 'Descendant User objects' and 'Create/delete User objects' on 'This object and all descendant objects'|
+|All|adds all the above permissions.|
+You can use AADCloudSyncPermissions in one of two ways:
+- [Grant a certain permission to all configured domains](#grant-a-certain-permission-to-all-configured-domains)
+- [Grant a certain permission to a specific domain](#grant-a-certain-permission-to-a-specific-domain)
+## Grant a certain permission to all configured domains
-You can use AADCloudSyncPermissions in one of two ways:
-- [Grant a certain permission to all configured domains](#grant-a-certain-permission-to-all-configured-domains) -- [Grant a certain permission to a specific domain](#grant-a-certain-permission-to-a-specific-domain)
-## Grant a certain permission to all configured domains
Granting certain permissions to all configured domains will require the use of an enterprise admin account. -
- ```PowerShell
-Set-AADCloudSyncPermissions -PermissionType ΓÇ£Any mentioned aboveΓÇ¥ -EACredential $credential (prepopulated same as above [$credential = Get-Credential])
+```powershell
+Set-AADCloudSyncPermissions -PermissionType "Any mentioned above" -EACredential $credential (prepopulated same as above [$credential = Get-Credential])
```
-## Grant a certain permission to a specific domain
-Granting certain permissions to a specific domain will require the use of, at minimum a domain admin account of the domain you are attempting to add.
+## Grant a certain permission to a specific domain
+Granting certain permissions to a specific domain will require the use of, at minimum a domain admin account of the domain you are attempting to add.
- ```PowerShell
-Set-AADCloidSyncPermissions -PermissionType ΓÇ£Any mentioned aboveΓÇ¥ -TargetDomain ΓÇ£FQDN of domainΓÇ¥ (has to be already configured through wizard) -TargetDomaincredential $credential(same as above)
+```powershell
+Set-AADCloudSyncPermissions -PermissionType "Any mentioned above" -TargetDomain "FQDN of domain" (has to be already configured through wizard) -TargetDomainCredential $credential(same as above)
```
-
-
-Note: for 1. The credentials must be at a minimum Enterprise admin.
-
-For 2. The Credentials can be either Domain admin or enterprise admin.
-ΓÇ»
+Note: for 1. The credentials must be at a minimum Enterprise admin.
+For 2. The Credentials can be either Domain admin or enterprise admin.
active-directory How To Inbound Synch Ms Graph https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/cloud-sync/how-to-inbound-synch-ms-graph.md
+ # How to programmatically configure cloud sync using MS Graph API The following document describes how to replicate a synchronization profile from scratch using only MSGraph APIs.
Use these [Microsoft Azure Active Directory Module for Windows PowerShell](/powe
### Enable tenant flags
- ```PowerShell
- Connect-MsolService ('-AzureEnvironment <AzureEnvironmnet>')
+```powershell
+Connect-MsolService ('-AzureEnvironment <AzureEnvironmnet>')
Set-MsolDirSyncEnabled -EnableDirSync $true
- ```
-The first of those two commands, require Azure Active Directory credentials. These commandlets implicitly identify the tenant and enable it for synchronization.
+```
+
+The first of those two commands, require Azure Active Directory credentials. These cmdlets implicitly identify the tenant and enable it for synchronization.
## Create service principals+ Next, we need to create the [AD2AAD application/ service principal](/graph/api/applicationtemplate-instantiate?view=graph-rest-beta&tabs=http&preserve-view=true) You need to use this application ID 1a4721b3-e57f-4451-ae87-ef078703ec94. The displayName is the AD domain url, if used in the portal (for example, contoso.com), but it may be named something else.
- ```
- POST https://graph.microsoft.com/beta/applicationTemplates/1a4721b3-e57f-4451-ae87-ef078703ec94/instantiate
- Content-type: application/json
- {
+```
+POST https://graph.microsoft.com/beta/applicationTemplates/1a4721b3-e57f-4451-ae87-ef078703ec94/instantiate
+Content-type: application/json
+{
displayName: [your app name here]
- }
- ```
-
+}
+```
## Create sync job
-The output of the above command will return the objectId of the service principal that was created. For this example, the objectId is 614ac0e9-a59b-481f-bd8f-79a73d167e1c. Use Microsoft Graph to add a synchronizationJob to that service principal.
+
+The output of the above command will return the objectId of the service principal that was created. For this example, the objectId is 614ac0e9-a59b-481f-bd8f-79a73d167e1c. Use Microsoft Graph to add a synchronizationJob to that service principal.
Documentation for creating a sync job can be found [here](/graph/api/synchronization-synchronizationjob-post?tabs=http&view=graph-rest-beta&preserve-view=true). If you did not record the ID above, you can find the service principal by running the following MS Graph call. You'll need Directory.Read.All permissions to make that call:
-
- `GET https://graph.microsoft.com/beta/servicePrincipals `
+
+`GET https://graph.microsoft.com/beta/servicePrincipals`
Then look for your app name in the output. Run the following two commands to create two jobs: one for user/group provisioning, and one for password hash syncing. It's the same request twice but with different template IDs. - Call the following two requests:
- ```
- POST https://graph.microsoft.com/beta/servicePrincipals/[SERVICE_PRINCIPAL_ID]/synchronization/jobs
- Content-type: application/json
- {
- "templateId":"AD2AADProvisioning"
- }
- ```
-
- ```
- POST https://graph.microsoft.com/beta/servicePrincipals/[SERVICE_PRINCIPAL_ID]/synchronization/jobs
- Content-type: application/json
- {
- "templateId":"AD2AADPasswordHash"
- }
- ```
+```
+POST https://graph.microsoft.com/beta/servicePrincipals/[SERVICE_PRINCIPAL_ID]/synchronization/jobs
+Content-type: application/json
+{
+"templateId":"AD2AADProvisioning"
+}
+```
+
+```
+POST https://graph.microsoft.com/beta/servicePrincipals/[SERVICE_PRINCIPAL_ID]/synchronization/jobs
+Content-type: application/json
+{
+"templateId":"AD2AADPasswordHash"
+}
+```
You will need two calls if you want to create both. Example return value (for provisioning):
- ```
+```
HTTP 201/Created { "@odata.context": "https://graph.microsoft.com/beta/$metadata#servicePrincipals('614ac0e9-a59b-481f-bd8f-79a73d167e1c')/synchronization/jobs/$entity",
HTTP 201/Created
``` ## Update targeted domain+ For this tenant, the object identifier and application identifier of the service principal are as follows: ObjectId: 8895955e-2e6c-4d79-8943-4d72ca36878f
We're going to need to update the domain this configuration is targeting, so upd
Make sure the domain name you use is the same url you set for your on-prem domain controller
- ```
- PUT ΓÇô https://graph.microsoft.com/beta/servicePrincipals/[SERVICE_PRINCIPAL_ID]/synchronization/secrets
- ```
- Add the following Key/value pair in the below value array based on what youΓÇÖre trying to do:
-{ key: "AppKey", value: "{"appKeyScenario":"AD2AADPasswordHash"}" }
-
-{ key: "AppKey", value: "{"appKeyScenario":"AD2AADProvisioning"}" }
- ```
- Request body ΓÇô
- {
- "value": [
- {
- "key": "Domain",
- "value": "{\"domain\":\"ad2aadTest.com\"}"
- }
- ]
- }
+```
+PUT ΓÇô https://graph.microsoft.com/beta/servicePrincipals/[SERVICE_PRINCIPAL_ID]/synchronization/secrets
+```
+
+Add the following key/value pair in the below value array based on what you're trying to do:
+
+- Enable both PHS and sync tenant flags
+ { key: "AppKey", value: "{"appKeyScenario":"AD2AADPasswordHash"}" }
+
+- Enable only sync tenant flag (do not turn on PHS)
+ { key: "AppKey", value: "{"appKeyScenario":"AD2AADProvisioning"}" }
+
+```
+Request body ΓÇô
+{
+ "value": [
+ {
+ "key": "Domain",
+ "value": "{\"domain\":\"ad2aadTest.com\"}"
+ }
+ ]
+}
``` The expected response is …
Here, the highlighted "Domain" value is the name of the on-premises Active Direc
This section will cover enabling syncing password hashes for a particular configuration. This is different than the AppKey secret that enables the tenant-level feature flag - this is only for a single domain/config. You will need to set the application key to the PHS one for this to work end to end.
-1. Grab the schema (warning this is pretty large)
- ```
- GET ΓÇôhttps://graph.microsoft.com/beta/servicePrincipals/[SERVICE_PRINCIPAL_ID]/synchronization/jobs/ [AD2AADProvisioningJobId]/schema
- ```
+1. Grab the schema (warning, it's pretty large):
+
+ ```
+ GET ΓÇôhttps://graph.microsoft.com/beta/servicePrincipals/[SERVICE_PRINCIPAL_ID]/synchronization/jobs/ [AD2AADProvisioningJobId]/schema
+ ```
+ 2. Take this CredentialData attribute mapping:
- ```
- {
- "defaultValue": null,
- "exportMissingReferences": false,
- "flowBehavior": "FlowWhenChanged",
- "flowType": "Always",
- "matchingPriority": 0,
- "targetAttributeName": "CredentialData",
- "source": {
- "expression": "[PasswordHash]",
- "name": "PasswordHash",
- "type": "Attribute",
- "parameters": []
- }
- ```
+
+ ```
+ {
+ "defaultValue": null,
+ "exportMissingReferences": false,
+ "flowBehavior": "FlowWhenChanged",
+ "flowType": "Always",
+ "matchingPriority": 0,
+ "targetAttributeName": "CredentialData",
+ "source": {
+ "expression": "[PasswordHash]",
+ "name": "PasswordHash",
+ "type": "Attribute",
+ "parameters": []
+ }
+ ```
+ 3. Find the following object mappings with the following names in the schema
+ - Provision Active Directory Users
+ - Provision Active Directory inetOrgPersons
- Object mappings are within the schema.synchronizationRules[0].objectMappings (For now you can assume thereΓÇÖs only 1 Synchronization Rule)
+ Object mappings are within the schema.synchronizationRules[0].objectMappings (For now you can assume there's only 1 Synchronization Rule)
4. Take the CredentialData Mapping from Step (2) and insert it into the object mappings in Step (3)
- Your object mapping looks something like this:
- ```
- {
- "enabled": true,
- "flowTypes": "Add,Update,Delete",
- "name": "Provision Active Directory users",
- "sourceObjectName": "user",
- "targetObjectName": "User",
- "attributeMappings": [
- ...
- }
- ```
- Copy/paste the mapping from the **Create AD2AADProvisioning and AD2AADPasswordHash jobs** step above into the attributeMappings array.
-
- Order of elements in this array doesn't matter (backend will sort for you). Be careful about adding this attribute mapping if the name exists already in the array (e.g. if there's already an item in attributeMappings that has the targetAttributeName CredentialData) - you may get conflict errors, or the preexisting and new mappings may be combined together (usually not desired outcome). Backend does not dedupe for you.
-
- Remember to do this for both Users and inetOrgpersons
-
-5. Save the schema youΓÇÖve created
- ```
- PUT ΓÇô
- https://graph.microsoft.com/beta/servicePrincipals/[SERVICE_PRINCIPAL_ID]/synchronization/jobs/ [AD2AADProvisioningJobId]/schema
-```
+ Your object mapping looks something like this:
- Add the Schema in the request body.
+ ```
+ {
+ "enabled": true,
+ "flowTypes": "Add,Update,Delete",
+ "name": "Provision Active Directory users",
+ "sourceObjectName": "user",
+ "targetObjectName": "User",
+ "attributeMappings": [
+ ...
+ }
+ ```
+
+ Copy/paste the mapping from the **Create AD2AADProvisioning and AD2AADPasswordHash jobs** step above into the attributeMappings array.
+
+ Order of elements in this array doesn't matter (backend will sort for you). Be careful about adding this attribute mapping if the name exists already in the array (e.g. if there's already an item in attributeMappings that has the targetAttributeName CredentialData) - you may get conflict errors, or the preexisting and new mappings may be combined together (usually not desired outcome). Backend does not dedupe for you.
+
+ Remember to do this for both Users and inetOrgpersons.
+
+5. Save the schema you've created:
+
+ ```
+ PUT ΓÇô
+ https://graph.microsoft.com/beta/servicePrincipals/[SERVICE_PRINCIPAL_ID]/synchronization/jobs/ [AD2AADProvisioningJobId]/schema
+ ```
+
+Add the Schema in the request body.
## Accidental deletes
-This section will cover how to programmatically enable/disable and use [accidental deletes](how-to-accidental-deletes.md) programmatically.
+This section will cover how to programmatically enable/disable and use [accidental deletes](how-to-accidental-deletes.md) programmatically.
### Enabling and setting the threshold+ There are two per job settings that you can use, they are:
+- DeleteThresholdEnabled - Enables accidental delete prevention for the job when set to 'true'. Set to 'true' by default.
+- DeleteThresholdValue - Defines the maximum number of deletes that will be allowed in each execution of the job when accidental deletes prevention is enabled. The value is set to 500 by default. So, if the value is set to 500, the maximum number of deletes allowed will be 499 in each execution.
-The delete threshold settings are a part of the `SyncNotificationSettings` and can be modified via graph.
+The delete threshold settings are a part of the `SyncNotificationSettings` and can be modified via graph.
We're going to need to update the SyncNotificationSettings this configuration is targeting, so update the secrets.
- ```
- PUT ΓÇô https://graph.microsoft.com/beta/servicePrincipals/[SERVICE_PRINCIPAL_ID]/synchronization/secrets
- ```
-
- Add the following Key/value pair in the below value array based on what youΓÇÖre trying to do:
- ```
- Request body -
- {
- "value":[
- {
- "key":"SyncNotificationSettings",
- "value": "{\"Enabled\":true,\"Recipients\":\"foobar@xyz.com\",\"DeleteThresholdEnabled\":true,\"DeleteThresholdValue\":50}"
- }
- ]
- }
+PUT ΓÇô https://graph.microsoft.com/beta/servicePrincipals/[SERVICE_PRINCIPAL_ID]/synchronization/secrets
+```
+Add the following Key/value pair in the below value array based on what you're trying to do:
+```
+Request body -
+{
+ "value":[
+ {
+ "key":"SyncNotificationSettings",
+ "value": "{\"Enabled\":true,\"Recipients\":\"foobar@xyz.com\",\"DeleteThresholdEnabled\":true,\"DeleteThresholdValue\":50}"
+ }
+ ]
+}
``` The "Enabled" setting in the example above is for enabling/disabling notification emails when the job is quarantined. - Currently, we do not support PATCH requests for secrets, so you will need to add all the values in the body of the PUT request(like in the example above) in order to preserve the other values.
-The existing values for all the secrets can be retrieved by using
+The existing values for all the secrets can be retrieved by using:
``` GET https://graph.microsoft.com/beta/servicePrincipals/{id}/synchronization/secrets ``` ### Allowing deletes
-To allow the deletes to flow through after the job goes into quarantine, you need to issue a restart with just "ForceDeletes" as the scope.
+
+To allow the deletes to flow through after the job goes into quarantine, you need to issue a restart with just "ForceDeletes" as the scope.
``` Request:
Request Body:
} ``` ----- ## Start sync job+ The job can be retrieved again via the following command:
- `GET https://graph.microsoft.com/beta/servicePrincipals/[SERVICE_PRINCIPAL_ID]/synchronization/jobs/ `
+ `GET https://graph.microsoft.com/beta/servicePrincipals/[SERVICE_PRINCIPAL_ID]/synchronization/jobs/`
+
+Documentation for retrieving jobs can be found [here](/graph/api/synchronization-synchronizationjob-list?tabs=http&view=graph-rest-beta&preserve-view=true).
-Documentation for retrieving jobs can be found [here](/graph/api/synchronization-synchronizationjob-list?tabs=http&view=graph-rest-beta&preserve-view=true).
-
To start the job, issue this request, using the objectId of the service principal created in the first step, and the job identifier returned from the request that created the job.
-Documentation for how to start a job can be found [here](/graph/api/synchronization-synchronizationjob-start?tabs=http&view=graph-rest-beta&preserve-view=true).
+Documentation for how to start a job can be found [here](/graph/api/synchronization-synchronizationjob-start?tabs=http&view=graph-rest-beta&preserve-view=true).
- ```
- POST https://graph.microsoft.com/beta/servicePrincipals/8895955e-2e6c-4d79-8943-4d72ca36878f/synchronization/jobs/AD2AADProvisioning.fc96887f36da47508c935c28a0c0b6da/start
- ```
+```
+POST https://graph.microsoft.com/beta/servicePrincipals/8895955e-2e6c-4d79-8943-4d72ca36878f/synchronization/jobs/AD2AADProvisioning.fc96887f36da47508c935c28a0c0b6da/start
+```
The expected response is … HTTP 204/No content. Other commands for controlling the job are documented [here](/graph/api/resources/synchronization-synchronizationjob?view=graph-rest-beta&preserve-view=true).
-
-To restart a job, one would use …
-
- ```
- POST https://graph.microsoft.com/beta/servicePrincipals/8895955e-2e6c-4d79-8943-4d72ca36878f/synchronization/jobs/AD2AADProvisioning.fc96887f36da47508c935c28a0c0b6da/restart
- {
- "criteria": {
- "resetScope": "Full"
- }
- }
- ```
+
+To restart a job, use:
+
+```
+POST https://graph.microsoft.com/beta/servicePrincipals/8895955e-2e6c-4d79-8943-4d72ca36878f/synchronization/jobs/AD2AADProvisioning.fc96887f36da47508c935c28a0c0b6da/restart
+{
+ "criteria": {
+ "resetScope": "Full"
+ }
+}
+```
## Review status
-Retrieve your job statuses via …
- ```
- GET https://graph.microsoft.com/beta/servicePrincipals/[SERVICE_PRINCIPAL_ID]/synchronization/jobs/
- ```
+Retrieve your job statuses via:
+
+```
+GET https://graph.microsoft.com/beta/servicePrincipals/[SERVICE_PRINCIPAL_ID]/synchronization/jobs/
+```
Look under the 'status' section of the return object for relevant details
-## Next steps
+## Next steps
- [What is Azure AD Connect cloud sync?](what-is-cloud-sync.md) - [Transformations](how-to-transformation.md)
active-directory Block Legacy Authentication https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/conditional-access/block-legacy-authentication.md
If your environment is ready to block legacy authentication to improve your tena
This article assumes that you are familiar with the [basic concepts](overview.md) of Azure AD Conditional Access.
+> [!NOTE]
+> Conditional Access policies are enforced after first-factor authentication is completed. Conditional Access isn't intended to be an organization's first line of defense for scenarios like denial-of-service (DoS) attacks, but it can use signals from these events to determine access.
+ ## Scenario description Azure AD supports several of the most widely used authentication and authorization protocols including legacy authentication. Legacy authentication refers to protocols that use basic authentication. Typically, these protocols can't enforce any type of second factor authentication. Examples for apps that are based on legacy authentication are:
To block B2B user access via legacy authentication to SharePoint Online, organiz
- [Determine impact using Conditional Access report-only mode](howto-conditional-access-insights-reporting.md) - If you are not familiar with configuring Conditional Access policies yet, see [require MFA for specific apps with Azure Active Directory Conditional Access](../authentication/tutorial-enable-azure-mfa.md) for an example. - For more information about modern authentication support, see [How modern authentication works for Office 2013 and Office 2016 client apps](/office365/enterprise/modern-auth-for-office-2013-and-2016) -- [How to set up a multifunction device or application to send email using Microsoft 365](/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365)
+- [How to set up a multifunction device or application to send email using Microsoft 365](/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365)
active-directory Howto Conditional Access Policy Block Access https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/conditional-access/howto-conditional-access-policy-block-access.md
A second policy is created below to require multi-factor authentication or a com
1. Confirm your settings and set **Enable policy** to **Report-only**. 1. Select **Create** to create to enable your policy.
+> [!NOTE]
+> Conditional Access policies are enforced after first-factor authentication is completed. Conditional Access isn't intended to be an organization's first line of defense for scenarios like denial-of-service (DoS) attacks, but it can use signals from these events to determine access.
+ ## Next steps [Conditional Access common policies](concept-conditional-access-policy-common.md)
active-directory Howto Conditional Access Policy Block Legacy https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/conditional-access/howto-conditional-access-policy-block-legacy.md
The following steps will help create a Conditional Access policy to block legacy
1. Confirm your settings and set **Enable policy** to **Report-only**. 1. Select **Create** to create to enable your policy.
+> [!NOTE]
+> Conditional Access policies are enforced after first-factor authentication is completed. Conditional Access isn't intended to be an organization's first line of defense for scenarios like denial-of-service (DoS) attacks, but it can use signals from these events to determine access.
+ ## Next steps [Conditional Access common policies](concept-conditional-access-policy-common.md)
active-directory Howto Conditional Access Policy Location https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/conditional-access/howto-conditional-access-policy-location.md
With the location condition in Conditional Access, you can control access to your cloud apps based on the network location of a user. The location condition is commonly used to block access from countries/regions where your organization knows traffic should not come from.
+> [!NOTE]
+> Conditional Access policies are enforced after first-factor authentication is completed. Conditional Access isn't intended to be an organization's first line of defense for scenarios like denial-of-service (DoS) attacks, but it can use signals from these events to determine access.
+ ## Define locations 1. Sign in to the **Azure portal** as a global administrator, security administrator, or Conditional Access administrator.
active-directory Howto Add Terms Of Service Privacy Statement https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/howto-add-terms-of-service-privacy-statement.md
# How to: Configure terms of service and privacy statement for an app
-Developers who build and manage apps that integrate with Azure Active Directory (Azure AD) and Microsoft accounts should include links to the app's terms of service and privacy statement. The terms of service and privacy statement are surfaced to users through the user consent experience. They help your users know that they can trust your app. The terms of service and privacy statement are especially critical for user-facing multi-tenant apps--apps that are used by multiple directories or are available to any Microsoft account.
+Developers who build and manage multi-tenant apps that integrate with Azure Active Directory (Azure AD) and Microsoft accounts should include links to the app's terms of service and privacy statement. The terms of service and privacy statement are surfaced to users through the user consent experience. They help your users know that they can trust your app. The terms of service and privacy statement are especially critical for user-facing multi-tenant apps--apps that are used by multiple directories or are available to any Microsoft account.
You are responsible for creating the terms of service and privacy statement documents for your app, and for providing the URLs to these documents. For multi-tenant apps that fail to provide these links, the user consent experience for your app will show an alert, which may discourage users from consenting to your app. > [!NOTE]
-> * Single-tenant apps will not show an alert.
+> * The terms of service and privacy statement links are not applicable to single-tenant apps
> * If one or both of the two links are missing, your app will show an alert. ## User consent experience
-The following examples show the user consent experience when the terms of service and privacy statement are configured and when these links are not configured.
+The following example shows the user consent experience for a multi-tenant app when the terms of service and privacy statement are configured and when these links are not configured.
![Screenshots with and without a privacy statement and terms of service provided](./media/howto-add-terms-of-service-privacy-statement/user-consent-exp-privacy-statement-terms-service.png)
active-directory Howto Build Services Resilient To Metadata Refresh https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/howto-build-services-resilient-to-metadata-refresh.md
+
+ Title: "How to: Build services that are resilient to Azure AD's OpenID Connect metadata refresh | Azure"
+
+description: Learn how to ensure that your web app or web api is resilient to Azure AD's OpenID Connect metadata refresh.
++++++++ Last updated : 04/21/2021+++
+# Customer intent: As a web app or web API developer, I want to learn how to ensure that my app is resilient to outages due to Azure AD OpenID Connect metadata refresh.
++
+# How to: Build services that are resilient to Azure AD's OpenID Connect metadata refresh
+
+Protected web APIs need to validate access tokens. Web apps also validate the ID tokens. Token Validation has multiple parts, checking whether the token belongs to the application, has been issued by a trusted Identity Provider (IDP), has a lifetime that's still in range and hasn't been tampered with. There can also be special validations. For instance, the app needs to validate the signature and that signing keys (when embedded in a token) are trusted and that the token isn't being replayed. When the signing keys aren't embedded in the token, they need to be fetched from the identity provider (Discovery or Metadata). Sometimes it's also necessary to obtain keys dynamically at runtime.
+
+Web apps and web APIs need to refresh stale OpenID Connect metadata for them to be resilient. This article helps guide on how to achieve resilient apps. It applies to ASP.NET Core, ASP.NET classic, and Microsoft.IdentityModel.
+
+## ASP.NET Core
+
+Use latest version of [Microsoft.IdentityModel.*](https://www.nuget.org/packages?q=Microsoft.IdentityModel) and manually follow the guidelines below.
+
+In the `ConfigureServices` method of the Startup.cs, ensure that `JwtBearerOptions.RefreshOnIssuerKeyNotFound` is set to true, and that you're using the latest Microsoft.IdentityModel.* library. This property should be enabled by default.
+
+```csharp
+ services.Configure<JwtBearerOptions>(AzureADDefaults.JwtBearerAuthenticationScheme, options =>
+ {
+ …
+ // shouldnΓÇÖt be necessary as itΓÇÖs true by default
+ options.RefreshOnIssuerKeyNotFound = true;
+ …
+ };
+```
+
+## ASP.NET/ OWIN
+
+Microsoft recommends that you move to ASP.NET Core, as development has stopped on ASP.NET.
+
+If you're using ASP.NET classic, use the latest [Microsoft.IdentityModel.*](https://www.nuget.org/packages?q=Microsoft.IdentityModel).
+
+OWIN has an automatic 24-hour refresh interval for the `OpenIdConnectConfiguration`. This refresh will only be triggered if a request is received after the 24-hour time span has passed. As far as we know, there's no way to change this value or trigger a refresh early, aside from restarting the application.
+
+## Microsoft.IdentityModel
+
+If you validate your token yourself, for instance in an Azure Function, use the latest version of [Microsoft.IdentityModel.*](https://www.nuget.org/packages?q=Microsoft.IdentityModel) and follow the metadata guidance illustrated by the code snippets below.
+
+```csharp
+ConfigurationManager<OpenIdConnectConfiguration> configManager =
+ new ConfigurationManager<OpenIdConnectConfiguration>("http://someaddress.com",
+ new OpenIdConnectConfigurationRetriever());
+OpenIdConnectConfiguration config = await configManager.GetConfigurationAsync().ConfigureAwait(false);
+TokenValidationParameters validationParameters = new TokenValidationParameters()
+{
+ …
+ IssuerSigningKeys = config.SigningKeys;
+ …
+}
+
+JsonWebTokenHandler tokenHandler = new JsonWebTokenHandler();
+result = Handler.ValidateToken(jwtToken, validationParameters);
+if (result.Exception != null && result.Exception is SecurityTokenSignatureKeyNotFoundException)
+{
+ configManager.RequestRefresh();
+ config = await configManager.GetConfigurationAsync().ConfigureAwait(false);
+ validationParameters = new TokenValidationParameters()
+ {
+ …
+ IssuerSigningKeys = config.SigningKeys,
+ …
+ };
+ // attempt to validate token again after refresh
+ result = Handler.ValidateToken(jwtToken, validationParameters);
+}
+```
+
+## Next Steps
+
+To learn more, see [token validation in a protected web API](scenario-protected-web-api-app-configuration.md#token-validation)
active-directory Msal Logging Dotnet https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/msal-logging-dotnet.md
+ # Logging in MSAL.NET [!INCLUDE [MSAL logging introduction](../../../includes/active-directory-develop-error-logging-introduction.md)]
In MSAL 3.x, logging is set per application at app creation using the `.WithLogg
```csharp class Program
- {
+{
private static void Log(LogLevel level, string message, bool containsPii) { if (containsPii)
class Program
AuthenticationResult result = application.AcquireTokenInteractive(scopes) .ExecuteAsync().Result; }
- }
- ```
+}
+```
> [!TIP] > See the [MSAL.NET wiki](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki) for samples of MSAL.NET logging and more. ## Next steps
-For more code samples, refer to [Microsoft identity platform code samples](sample-v2-code.md).
+For more code samples, refer to [Microsoft identity platform code samples](sample-v2-code.md).
active-directory Msal Logging Ios https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/msal-logging-ios.md
+ # Logging in MSAL for iOS/macOS [!INCLUDE [MSAL logging introduction](../../../includes/active-directory-develop-error-logging-introduction.md)]
Set a callback to capture MSAL logging and incorporate it in your own applicatio
```objc /*! The LogCallback block for the MSAL logger
-
+ @param level The level of the log message @param message The message being logged @param containsPII If the message might contain Personally Identifiable Information (PII)
For example:
```objc MSALGlobalConfig.loggerConfig.logLevel = MSALLogLevelVerbose;
- ```
+```
### Log message format
Set a callback to capture MSAL logging and incorporate it in your own applicatio
```objc /*! The LogCallback block for the MSAL logger
-
+ @param level The level of the log message @param message The message being logged @param containsPII If the message might contain Personally Identifiable Information (PII)
For example:
```swift MSALGlobalConfig.loggerConfig.logLevel = .verbose
- ```
+```
### Log message format
Providing correlation IDs and timestamps are helpful for tracking down issues. T
## Next steps
-For more code samples, refer to [Microsoft identity platform code samples](sample-v2-code.md).
+For more code samples, refer to [Microsoft identity platform code samples](sample-v2-code.md).
active-directory Quickstart V2 Aspnet Core Webapp Calls Graph https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/quickstart-v2-aspnet-core-webapp-calls-graph.md
# Quickstart: ASP.NET Core web app that signs in users and calls Microsoft Graph on their behalf
-In this quickstart, you download and run a code sample that demonstrates how an ASP.NET Core web app can sign in users from any Azure Active Directory (Azure AD) organization and calls Microsoft Graph.
+In this quickstart, you download and run a code sample that demonstrates how an ASP.NET Core web app can sign in users from any Azure Active Directory (Azure AD) organization and calls Microsoft Graph.
See [How the sample works](#how-the-sample-works) for an illustration.
See [How the sample works](#how-the-sample-works) for an illustration.
> - If your application supports **Accounts in any organizational directory**, replace this value with `organizations` > - If your application supports **All Microsoft account users**, leave this value as `common` > - Replace `Enter_the_Client_Secret_Here` with the **Client secret** you created and recorded in an earlier step.
->
+>
> For this quickstart, don't change any other values in the *appsettings.json* file. > > #### Step 4: Build and run the application
See [How the sample works](#how-the-sample-works) for an illustration.
This section gives an overview of the code required to sign in users and call the Microsoft Graph API on their behalf. This overview can be useful to understand how the code works, main arguments, and also if you want to add sign-in to an existing ASP.NET Core application and call Microsoft Graph. It uses [Microsoft.Identity.Web](microsoft-identity-web.md), which is a wrapper around [MSAL.NET](msal-overview.md). ### How the sample works+ ![Shows how the sample app generated by this quickstart works](media/quickstart-v2-aspnet-core-webapp-calls-graph/aspnetcorewebapp-intro.svg) ### Startup class
app.UseEndpoints(endpoints =>
You can protect a controller or its methods by applying the `[Authorize]` attribute to the controller's class or one or more of its methods. This `[Authorize]` attribute restricts access by allowing only authenticated users. If the user isn't already authenticated, an authentication challenge can be started to access the controller. In this quickstart, the scopes are read from the configuration file:
-```CSharp
+```csharp
[AuthorizeForScopes(ScopeKeySection = "DownstreamApi:Scopes")] public async Task<IActionResult> Index() {
public async Task<IActionResult> Index()
return View(); }
- ```
+```
[!INCLUDE [Help and support](../../../includes/active-directory-develop-help-support-include.md)]
active-directory Quickstart V2 Ios https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/quickstart-v2-ios.md
The quickstart applies to both iOS and macOS apps. Some steps are needed only fo
> > 1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>. > 1. If you have access to multiple tenants, use the **Directory + subscription** filter :::image type="icon" source="./media/common/portal-directory-subscription-filter.png" border="false"::: in the top menu to select the tenant in which you want to register an application.
-> 1. Search for and select **Azure Active Directory**.
+> 1. Search for and select **Azure Active Directory**.
> 1. Under **Manage**, select **App registrations** > **New registration**. > 1. Enter a **Name** for your application. Users of your app might see this name, and you can change it later. > 1. Select **Register**.
In a terminal window, navigate to the folder with the downloaded code sample and
> > `Enter_the_Supported_Account_Info_Here` > > [!div renderon="docs"]
->#### Step 4: Configure your project
+> #### Step 4: Configure your project
> If you selected Option 1 above, you can skip these steps. > 1. Extract the zip file and open the project in XCode. > 1. Edit **ViewController.swift** and replace the line starting with 'let kClientID' with the following code snippet. Remember to update the value for `kClientID` with the clientID that you saved when you registered your app in the portal earlier in this quickstart:
+>
> ```swift > let kClientID = "Enter_the_Application_Id_Here" > ```+ > 1. If you're building an app for [Azure AD national clouds](/graph/deployments#app-registration-and-token-service-root-endpoints), replace the line starting with 'let kGraphEndpoint' and 'let kAuthority' with correct endpoints. For global access, use default values:
-> ```swift
-> let kGraphEndpoint = "https://graph.microsoft.com/"
-> let kAuthority = "https://login.microsoftonline.com/common"
-> ```
+>
+> ```swift
+> let kGraphEndpoint = "https://graph.microsoft.com/"
+> let kAuthority = "https://login.microsoftonline.com/common"
+> ```
+ > 1. Other endpoints are documented [here](/graph/deployments#app-registration-and-token-service-root-endpoints). For example, to run the quickstart with Azure AD Germany, use following:
-> ```swift
-> let kGraphEndpoint = "https://graph.microsoft.de/"
-> let kAuthority = "https://login.microsoftonline.de/common"
-> ```
+>
+> ```swift
+> let kGraphEndpoint = "https://graph.microsoft.de/"
+> let kAuthority = "https://login.microsoftonline.de/common"
+> ```
+ > 1. Open the project settings. In the **Identity** section, enter the **Bundle Identifier** that you entered into the portal. > 1. Right-click **Info.plist** and select **Open As** > **Source Code**. > 1. Under the dict root node, replace `Enter_the_bundle_Id_Here` with the ***Bundle Id*** that you used in the portal.
In a terminal window, navigate to the folder with the downloaded code sample and
> </array> > </dict> > </array>
->
> ```
-> 1. Build & run the app!
+
+> 1. Build and run the app!
## More Information
MSAL ([MSAL.framework](https://github.com/AzureAD/microsoft-authentication-libra
``` $ vi Podfile- ```+ Add the following to this podfile (with your project's target): ```
use_frameworks!
target 'MSALiOS' do pod 'MSAL' end- ``` Run CocoaPods installation command:
-```pod install```
+`podinstall`
### Initialize MSAL
self.applicationContext = try MSALPublicClientApplication(configuration: msalCon
Your app must also have the following in your `AppDelegate`. This lets MSAL SDK handle token response from the Auth broker app when you do authentication.
- ```swift
- func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
-
- return MSALPublicClientApplication.handleMSALResponse(url, sourceApplication: options[UIApplication.OpenURLOptionsKey.sourceApplication] as? String)
- }
+```swift
+func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
- ```
+ return MSALPublicClientApplication.handleMSALResponse(url, sourceApplication: options[UIApplication.OpenURLOptionsKey.sourceApplication] as? String)
+}
+```
> [!NOTE] > On iOS 13+, if you adopt `UISceneDelegate` instead of `UIApplicationDelegate`, place this code into the `scene:openURLContexts:` callback instead (See [Apple's documentation](https://developer.apple.com/documentation/uikit/uiscenedelegate/3238059-scene?language=objc)). > If you support both UISceneDelegate and UIApplicationDelegate for compatibility with older iOS, MSAL callback needs to be placed into both places.
- ```swift
- func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
+```swift
+func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
- guard let urlContext = URLContexts.first else {
- return
- }
+ guard let urlContext = URLContexts.first else {
+ return
+ }
- let url = urlContext.url
- let sourceApp = urlContext.options.sourceApplication
+ let url = urlContext.url
+ let sourceApp = urlContext.options.sourceApplication
- MSALPublicClientApplication.handleMSALResponse(url, sourceApplication: sourceApp)
- }
- ```
+ MSALPublicClientApplication.handleMSALResponse(url, sourceApplication: sourceApp)
+}
+```
Finally, your app must have an `LSApplicationQueriesSchemes` entry in your ***Info.plist*** alongside the `CFBundleURLTypes`. The sample comes with this included.
active-directory Quickstart V2 Nodejs Webapp Msal https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/quickstart-v2-nodejs-webapp-msal.md
Title: "Quickstart: Add Authentication to a Node web app with MSAL Node | Azure"
+ Title: "Quickstart: Add authentication to a Node.js web app with MSAL Node | Azure"
description: In this quickstart, you learn how to implement authentication with a Node.js web app and the Microsoft Authentication Library (MSAL) for Node.js.
# Quickstart: Sign in users and get an access token in a Node web app using the auth code flow
-In this quickstart, you download and run a code sample that demonstrates how a Node.js web app can sign in users using the authorization code flow. The code sample also demonstrates how to get an access token to call Microsoft Graph API.
+In this quickstart, you download and run a code sample that demonstrates how a Node.js web app can sign in users by using the authorization code flow. The code sample also demonstrates how to get an access token to call Microsoft Graph API.
See [How the sample works](#how-the-sample-works) for an illustration.
This quickstart uses the Microsoft Authentication Library for Node.js (MSAL Node
## Prerequisites
-* Azure subscription - [Create an Azure subscription for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F)
+* An Azure subscription. [Create an Azure subscription for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).
* [Node.js](https://nodejs.org/en/download/) * [Visual Studio Code](https://code.visualstudio.com/download) or another code editor
This quickstart uses the Microsoft Authentication Library for Node.js (MSAL Node
> #### Step 1: Register your application > > 1. Sign in to the <a href="https://portal.azure.com/" target="_blank">Azure portal</a>.
-> 1. If you have access to multiple tenants, use the **Directory + subscription** filter :::image type="icon" source="./media/common/portal-directory-subscription-filter.png" border="false"::: in the top menu to select the tenant in which you want to register an application.
+> 1. If you have access to multiple tenants, use the **Directory + subscription** filter :::image type="icon" source="./media/common/portal-directory-subscription-filter.png" border="false"::: to select the tenant in which you want to register an application.
> 1. Under **Manage**, select **App registrations** > **New registration**. > 1. Enter a **Name** for your application. Users of your app might see this name, and you can change it later. > 1. Under **Supported account types**, select **Accounts in any organizational directory and personal Microsoft accounts**. > 1. Set the **Redirect URI** value to `http://localhost:3000/redirect`.
-> 1. Select **Register**.
+> 1. Select **Register**.
> 1. On the app **Overview** page, note the **Application (client) ID** value for later use. > 1. Under **Manage**, select **Certificates & secrets** > **New client secret**. Leave the description blank and default expiration, and then select **Add**.
-> 1. Note the **Value** of the **Client Secret** for later use.
+> 1. Note the value of **Client secret** for later use.
> [!div class="sxs-lookup" renderon="portal"] > #### Step 1: Configure the application in Azure portal
-> For the code sample for this quickstart to work, you need to create a client secret and add a reply URL as **http://localhost:3000/redirect**.
+> For the code sample for this quickstart to work, you need to create a client secret and add the following reply URL: `http://localhost:3000/redirect`.
> > [!div renderon="portal" id="makechanges" class="nextstepaction"] > > [Make this change for me]() >
This quickstart uses the Microsoft Authentication Library for Node.js (MSAL Node
> To run the project with a web server by using Node.js, [download the core project files](https://github.com/Azure-Samples/ms-identity-node/archive/main.zip). > [!div renderon="portal" class="sxs-lookup"]
-> Run the project with a web server by using Node.js
+> Run the project with a web server by using Node.js.
> [!div renderon="portal" class="sxs-lookup" id="autoupdate" class="nextstepaction"] > [Download the code sample](https://github.com/Azure-Samples/ms-identity-node/archive/main.zip)
This quickstart uses the Microsoft Authentication Library for Node.js (MSAL Node
> [!div renderon="docs"] > #### Step 3: Configure your Node app >
-> Extract the project, and open the folder *ms-identity-node-main*, then open the *index.js* file.
-> Set the `clientID` with the **Application (client) ID**.
-> Set the `clientSecret` with the **Value** of the **Client secret**.
+> Extract the project, open the *ms-identity-node-main* folder, and then open the *index.js* file.
+>
+> Set the `clientID` value with the application (client) ID, and then set the `clientSecret` value with the client secret.
> >```javascript >const config = {
This quickstart uses the Microsoft Authentication Library for Node.js (MSAL Node
> [!div renderon="docs"] >
-> Modify the values in the `config` section as described here:
+> Modify the values in the `config` section:
>
-> - `Enter_the_Application_Id_Here` is the **Application (client) ID** for the application you registered.
+> - `Enter_the_Application_Id_Here` is the application (client) ID for the application you registered.
>
-> To find the value of **Application (client) ID**, go to the app registration's **Overview** page in the Azure portal.
-> - `Enter_the_Client_Secret_Here` is the **Value** of the **Client secret** for the application you registered.
+> To find the application (client) ID, go to the app registration's **Overview** page in the Azure portal.
+> - `Enter_the_Client_Secret_Here` is the client secret for the application you registered.
>
-> To retrieve or generate a new **Client secret**, under **Manage**, select **Certificates & secrets**.
+> To retrieve or generate a new client secret, under **Manage**, select **Certificates & secrets**.
> > The default `authority` value represents the main (global) Azure cloud: >
This quickstart uses the Microsoft Authentication Library for Node.js (MSAL Node
> > #### Step 4: Run the project
-Run the project by using Node.js:
+Run the project by using Node.js.
1. To start the server, run the following commands from within the project directory:+ ```console npm install npm start ```
-1. Browse to `http://localhost:3000/`.
+
+1. Go to `http://localhost:3000/`.
1. Select **Sign In** to start the sign-in process.
Run the project by using Node.js:
### How the sample works
-The sample, when run, hosts a web server on localhost, port 3000. When a web browser accesses this site, the sample immediately redirects the user to a Microsoft authentication page. Because of this, the sample does not contain any *html* or display elements. Authentication success displays the message, "OK".
+The sample hosts a web server on localhost, port 3000. When a web browser accesses this site, the sample immediately redirects the user to a Microsoft authentication page. Because of this, the sample does not contain any HTML or display elements. Authentication success displays the message "OK".
### MSAL Node
active-directory Scenario Desktop Acquire Token https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/scenario-desktop-acquire-token.md
catch(MsalUiRequiredException ex)
# [Java](#tab/java) ```java- Set<IAccount> accountsInCache = pca.getAccounts().join(); // Take first account in the cache. In a production application, you would filter // accountsInCache to get the right account for the user authenticating.
try {
} } return result;- ``` # [macOS](#tab/macOS)
MSALSilentTokenParameters *silentParams = [[MSALSilentTokenParameters alloc] ini
} }]; ```+ Swift: ```swift
application.acquireTokenSilent(with: silentParameters) { (result, error) in
In MSAL Node, you acquire tokens via authorization code flow with Proof Key for Code Exchange (PKCE). MSAL Node uses an in-memory token cache to see if there are any user accounts in the cache. If there is, the account object can be passed to the `acquireTokenSilent()` method to retrieve a cached access token.
-```JavaScript
+```javascript
const msal = require("@azure/msal-node");
let accounts = await msalTokenCache.getAllAccounts();
account: accounts[0], // Index must match the account that is trying to acquire token silently scopes: ["user.read"], };
-
+ pca.acquireTokenSilent(silentRequest).then((response) => { console.log("\nSuccessful silent token acquisition"); console.log("\nResponse: \n:", response);
let accounts = await msalTokenCache.getAllAccounts();
codeChallenge: challenge, // PKCE Code Challenge codeChallengeMethod: "S256" // PKCE Code Challenge Method };
-
+ // get url to sign user in and consent to scopes needed for application pca.getAuthCodeUrl(authCodeUrlParameters).then((response) => { console.log(response);
-
+ const tokenRequest = { code: response["authorization_code"], codeVerifier: verifier // PKCE Code Verifier redirectUri: "your_redirect_uri", scopes: ["User.Read"], };
-
+ // acquire a token by exchanging the code pca.acquireTokenByCode(tokenRequest).then((response) => { console.log("\nResponse: \n:", response);
let accounts = await msalTokenCache.getAllAccounts();
# [Python](#tab/python)
-```Python
+```python
result = None # Firstly, check the cache to see if this end user has signed in before
if accounts:
if not result: result = app.acquire_token_by_xxx(scopes=config["scope"]) ```+ Here are the various ways to acquire tokens in a desktop application.
The class defines the following constants:
This method enables you to specify if you want to force the usage of an embedded WebView or the system WebView (when available). For more information, see [Usage of web browsers](msal-net-web-browsers.md).
- ```csharp
- var result = await app.AcquireTokenInteractive(scopes)
- .WithUseEmbeddedWebView(true)
- .ExecuteAsync();
- ```
+```csharp
+var result = await app.AcquireTokenInteractive(scopes)
+ .WithUseEmbeddedWebView(true)
+ .ExecuteAsync();
+```
#### WithExtraScopeToConsent
application.acquireToken(with: interactiveParameters, completionBlock: { (result
In MSAL Node, you acquire tokens via authorization code flow with Proof Key for Code Exchange (PKCE). The process has two steps: first, the application obtains a URL that can be used to generate an authorization code. This URL can be opened in a browser of choice, where the user can input their credentials, and will be redirected back to the `redirectUri` (registered during the app registration) with an authorization code. Second, the application passes the authorization code received to the `acquireTokenByCode()` method which exchanges it for an access token.
-```JavaScript
+```javascript
const msal = require("@azure/msal-node"); const msalConfig = {
pca.getAuthCodeUrl(authCodeUrlParameters).then((response) => {
redirectUri: "your_redirect_uri", scopes: ["User.Read"], };
-
+ // acquire a token by exchanging the code pca.acquireTokenByCode(tokenRequest).then((response) => { console.log("\nResponse: \n:", response);
pca.getAuthCodeUrl(authCodeUrlParameters).then((response) => {
MSAL Python doesn't provide an interactive acquire token method directly. Instead, it requires the application to send an authorization request in its implementation of the user interaction flow to obtain an authorization code. This code can then be passed to the `acquire_token_by_authorization_code` method to get the token.
-```Python
+```python
result = None # Firstly, check the cache to see if this end user has signed in before
if not result:
result = app.acquire_token_by_authorization_code( request.args['code'], scopes=config["scope"])- ```+ ## Integrated Windows Authentication
To sign in a domain user on a domain or Azure AD joined machine, use Integrated
- Integrated Windows Authentication is usable for *federated+* users only, that is, users created in Active Directory and backed by Azure AD. Users created directly in Azure AD without Active Directory backing, known as *managed* users, can't use this authentication flow. This limitation doesn't affect the username and password flow. - IWA is for apps written for .NET Framework, .NET Core, and Universal Windows Platform (UWP) platforms. - IWA doesn't bypass [multi-factor authentication (MFA)](../authentication/concept-mfa-howitworks.md). If MFA is configured, IWA might fail if an MFA challenge is required, because MFA requires user interaction.
-
+ IWA is non-interactive, but MFA requires user interactivity. You don't control when the identity provider requests MFA to be performed, the tenant admin does. From our observations, MFA is required when you sign in from a different country/region, when not connected via VPN to a corporate network, and sometimes even when connected via VPN. Don't expect a deterministic set of rules. Azure AD uses AI to continuously learn if MFA is required. Fall back to a user prompt like interactive authentication or device code flow if IWA fails. - The authority passed in `PublicClientApplicationBuilder` needs to be:
static async Task GetATokenForGraph()
} } - Console.WriteLine(result.Account.Username); } ```
For the list of possible modifiers on AcquireTokenByIntegratedWindowsAuthenticat
This extract is from the [MSAL Java dev samples](https://github.com/AzureAD/microsoft-authentication-library-for-java/blob/dev/src/samples/public-client/).
-```Java
+```java
private static IAuthenticationResult acquireTokenIwa() throws Exception { // Load token cache from file and initialize token cache aspect. The token cache will have
For more information on all the modifiers that can be applied to `AcquireTokenBy
The following extract is from the [MSAL Java dev samples](https://github.com/AzureAD/microsoft-authentication-library-for-java/blob/dev/src/samples/public-client/).
-```Java
+```java
private static IAuthenticationResult acquireTokenUsernamePassword() throws Exception { // Load token cache from file and initialize token cache aspect. The token cache will have
This flow isn't supported on MSAL for macOS.
# [Node.js](#tab/nodejs)
-This extract is from the [MSAL Node dev samples](https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/samples/msal-node-samples/username-password). In the code snippet below, the username and password are hardcoded for illustration purposes only. This should be avoided in production. Instead, a basic UI prompting the user to enter her username/password would be recommended.
+This extract is from the [MSAL Node dev samples](https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/samples/msal-node-samples/username-password). In the code snippet below, the username and password are hardcoded for illustration purposes only. This should be avoided in production. Instead, a basic UI prompting the user to enter her username/password would be recommended.
-```JavaScript
+```javascript
const msal = require("@azure/msal-node"); const msalConfig = {
pca.acquireTokenByUsernamePassword(usernamePasswordRequest).then((response) => {
This extract is from the [MSAL Python dev samples](https://github.com/AzureAD/microsoft-authentication-library-for-python/blob/dev/sample/).
-```Python
+```python
# Create a preferably long-lived app instance which maintains a token cache. app = msal.PublicClientApplication( config["client_id"], authority=config["authority"],
This flow doesn't apply to macOS.
This extract is from the [MSAL Node dev samples](https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/samples/msal-node-samples/device-code).
-```JavaScript
+```javascript
const msal = require('@azure/msal-node'); const msalConfig = {
pca.acquireTokenByDeviceCode(deviceCodeRequest).then((response) => {
This extract is from the [MSAL Python dev samples](https://github.com/AzureAD/microsoft-authentication-library-for-python/blob/dev/sample/).
-```Python
+```python
# Create a preferably long-lived app instance which maintains a token cache. app = msal.PublicClientApplication( config["client_id"], authority=config["authority"],
app = PublicClientApplicationBuilder.Create(clientId)
FilesBasedTokenCacheHelper.EnableSerialization(app.UserTokenCache, unifiedCacheFileName, adalV3cacheFileName);- ``` This time the helper class looks like the following code:
active-directory Scenario Web Api Call Api Call Api https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/scenario-web-api-call-api-call-api.md
When you use *Microsoft.Identity.Web*, you have three usage scenarios:
In this scenario, you've added `.AddMicrosoftGraph()` in *Startup.cs* as specified in [Code configuration](scenario-web-api-call-api-app-configuration.md#option-1-call-microsoft-graph), and you can directly inject the `GraphServiceClient` in your controller or page constructor for use in the actions. The following example Razor page displays the photo of the signed-in user.
-```CSharp
+```csharp
[Authorize] [AuthorizeForScopes(Scopes = new[] { "user.read" })] public class IndexModel : PageModel
In this scenario, you've added `.AddMicrosoftGraph()` in *Startup.cs* as specifi
In this scenario, you've added `.AddDownstreamWebApi()` in *Startup.cs* as specified in [Code configuration](scenario-web-api-call-api-app-configuration.md#option-2-call-a-downstream-web-api-other-than-microsoft-graph), and you can directly inject an `IDownstreamWebApi` service in your controller or page constructor and use it in the actions:
-```CSharp
+```csharp
[Authorize] [AuthorizeForScopes(ScopeKeySection = "TodoList:Scopes")] public class TodoListController : Controller
In this scenario, you've added `.AddDownstreamWebApi()` in *Startup.cs* as speci
The `CallWebApiForUserAsync` method also has strongly typed generic overrides that enable you to directly receive an object. For example, the following method received a `Todo` instance, which is a strongly typed representation of the JSON returned by the web API.
-```CSharp
+```csharp
// GET: TodoList/Details/5 public async Task<ActionResult> Details(int id) {
If you've decided to acquire a token manually by using the `ITokenAcquisition` s
After you've acquired the token, use it as a bearer token to call the downstream API. ```csharp
- private async Task CallTodoListService(string accessToken)
- {
+private async Task CallTodoListService(string accessToken)
+{
// After the token has been returned by Microsoft.Identity.Web, add it to the HTTP authorization header before making the call to access the todolist service.
- _httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", result.AccessToken);
+ _httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", result.AccessToken);
- // Call the todolist service.
- HttpResponseMessage response = await _httpClient.GetAsync(TodoListBaseAddress + "/api/todolist");
- // ...
- }
- ```
+ // Call the todolist service.
+ HttpResponseMessage response = await _httpClient.GetAsync(TodoListBaseAddress + "/api/todolist");
+ // ...
+}
+```
# [Java](#tab/java)
The following code continues the example code that's shown in [A web API that ca
After you've acquired the token, use it as a bearer token to call the downstream API.
-```Java
+```java
private String callMicrosoftGraphMeEndpoint(String accessToken){ RestTemplate restTemplate = new RestTemplate();
private String callMicrosoftGraphMeEndpoint(String accessToken){
``` # [Python](#tab/python)+ A sample demonstrating this flow with MSAL Python is available at [ms-identity-python-on-behalf-of](https://github.com/Azure-Samples/ms-identity-python-on-behalf-of).
active-directory Scenario Web App Call Api Call Api https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/develop/scenario-web-app-call-api-call-api.md
When you use *Microsoft.Identity.Web*, you have three usage options for calling
You want to call Microsoft Graph. In this scenario, you've added `AddMicrosoftGraph` in *Startup.cs* as specified in [Code configuration](scenario-web-app-call-api-app-configuration.md#option-1-call-microsoft-graph), and you can directly inject the `GraphServiceClient` in your controller or page constructor for use in the actions. The following example Razor page displays the photo of the signed-in user.
-```CSharp
+```csharp
[Authorize] [AuthorizeForScopes(Scopes = new[] { "user.read" })] public class IndexModel : PageModel
public class IndexModel : PageModel
You want to call a web API other than Microsoft Graph. In that case, you've added `AddDownstreamWebApi` in *Startup.cs* as specified in [Code configuration](scenario-web-app-call-api-app-configuration.md#option-2-call-a-downstream-web-api-other-than-microsoft-graph), and you can directly inject an `IDownstreamWebApi` service in your controller or page constructor and use it in the actions:
-```CSharp
+```csharp
[Authorize] [AuthorizeForScopes(ScopeKeySection = "TodoList:Scopes")] public class TodoListController : Controller
public class TodoListController : Controller
The `CallWebApiForUserAsync` also has strongly typed generic overrides that enable you to directly receive an object. For example, the following method receives a `Todo` instance, which is a strongly typed representation of the JSON returned by the web API.
-```CSharp
+```csharp
// GET: TodoList/Details/5 public async Task<ActionResult> Details(int id) {
You've decided to acquire a token manually using the `ITokenAcquisition` service
After you've acquired the token, use it as a bearer token to call the downstream API, in this case Microsoft Graph.
- ```csharp
+```csharp
public async Task<IActionResult> Profile() {
- // Acquire the access token.
- string[] scopes = new string[]{"user.read"};
- string accessToken = await tokenAcquisition.GetAccessTokenForUserAsync(scopes);
+ // Acquire the access token.
+ string[] scopes = new string[]{"user.read"};
+ string accessToken = await tokenAcquisition.GetAccessTokenForUserAsync(scopes);
- // Use the access token to call a protected web API.
- HttpClient client = new HttpClient();
- client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", accessToken);
+ // Use the access token to call a protected web API.
+ HttpClient client = new HttpClient();
+ client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", accessToken);
var response = await httpClient.GetAsync($"{webOptions.GraphApiUrl}/beta/me"); if (response.StatusCode == HttpStatusCode.OK) {
- var content = await response.Content.ReadAsStringAsync();
+ var content = await response.Content.ReadAsStringAsync();
- dynamic me = JsonConvert.DeserializeObject(content);
- ViewData["Me"] = me;
+ dynamic me = JsonConvert.DeserializeObject(content);
+ ViewData["Me"] = me;
} return View(); } ```+ > [!NOTE] > You can use the same principle to call any web API. >
public async Task<IActionResult> Profile()
# [Java](#tab/java)
-```Java
+```java
private String getUserInfoFromGraph(String accessToken) throws Exception { // Microsoft Graph user endpoint URL url = new URL("https://graph.microsoft.com/v1.0/me");
private String getUserInfoFromGraph(String accessToken) throws Exception {
JSONObject responseObject = HttpClientHelper.processResponse(responseCode, response); return responseObject.toString(); }- ``` # [Python](#tab/python)
-```Python
+```python
@app.route("/graphcall") def graphcall(): token = _get_token_from_cache(app_config.SCOPE)
def graphcall():
## Next steps Move on to the next article in this scenario,
-[Move to production](scenario-web-app-call-api-production.md).
+[Move to production](scenario-web-app-call-api-production.md).
active-directory Hybrid Azuread Join Control https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/devices/hybrid-azuread-join-control.md
Use the following example to create a Group Policy Object (GPO) to deploy a regi
1. Key Path: **SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD** 1. Value name: **TenantId** 1. Value type: **REG_SZ**
- 1. Value data: The GUID or **Directory ID** of your Azure AD instance (This value can be found in the **Azure portal** > **Azure Active Directory** > **Properties** > **Directory ID**)
+ 1. Value data: The GUID or **Tenant ID** of your Azure AD instance (This value can be found in the **Azure portal** > **Azure Active Directory** > **Properties** > **Tenant ID**)
1. Click **OK** 1. Right-click on the Registry and select **New** > **Registry Item** 1. On the **General** tab, configure the following
active-directory Troubleshoot Device Dsregcmd https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/devices/troubleshoot-device-dsregcmd.md
Title: Troubleshoot using the dsregcmd command - Azure Active Directory
-description: Using the output from dsregcmd to understand the state of devices in Azure AD
+description: Using the output from dsregcmd to understand the state of devices in Azure AD
+ # Troubleshooting devices using the dsregcmd command The dsregcmd /status utility must be run as a domain user account.
This section lists the device join state parameters. The table below lists the c
> [!NOTE] > Workplace Join (Azure AD registered) state is displayed in the "User State" section -- **AzureAdJoined:** - Set to ΓÇ£YESΓÇ¥ if the device is Joined to Azure AD. ΓÇ£NOΓÇ¥ otherwise.-- **EnterpriseJoined:** - Set to ΓÇ£YESΓÇ¥ if the device is Joined to an on-premises DRS. A device cannot be both EnterpriseJoined and AzureAdJoined.-- **DomainJoined:** - Set to ΓÇ£YESΓÇ¥ if the device is joined to a domain (AD).-- **DomainName:** - Set to the name of the domain if the device is joined to a domain.
+- **AzureAdJoined:** Set to "YES" if the device is Joined to Azure AD. "NO" otherwise.
+- **EnterpriseJoined:** Set to "YES" if the device is Joined to an on-premises DRS. A device cannot be both EnterpriseJoined and AzureAdJoined.
+- **DomainJoined:** Set to "YES" if the device is joined to a domain (AD).
+- **DomainName:** Set to the name of the domain if the device is joined to a domain.
### Sample device state output
This section lists the device join state parameters. The table below lists the c
Displayed only when the device is Azure AD joined or hybrid Azure AD joined (not Azure AD registered). This section lists device identifying details stored in the cloud. -- **DeviceId:** - Unique ID of the device in the Azure AD tenant-- **Thumbprint:** - Thumbprint of the device certificate -- **DeviceCertificateValidity:** - Validity of the device certificate
+- **DeviceId:** Unique ID of the device in the Azure AD tenant
+- **Thumbprint:** Thumbprint of the device certificate
+- **DeviceCertificateValidity:** Validity of the device certificate
- **KeyContainerId:** - ContainerId of the device private key associated with the device certificate-- **KeyProvider:** - KeyProvider (Hardware/Software) used to store the device private key.-- **TpmProtected:** - ΓÇ£YESΓÇ¥ if the device private key is stored in a Hardware TPM.
+- **KeyProvider:** KeyProvider (Hardware/Software) used to store the device private key.
+- **TpmProtected:** "YES" if the device private key is stored in a Hardware TPM.
### Sample device details output
Displayed only when the device is Azure AD joined or hybrid Azure AD joined (not
> If the MDM URLs in this section are empty, it indicates that the MDM was either not configured or current user is not in scope of MDM enrollment. Check the Mobility settings in Azure AD to review your MDM configuration. > [!NOTE]
-> Even if you see MDM URLs this does not mean that the device is managed by an MDM. The information is displayed if the tenant has MDM configuration for auto-enrollment even if the device itself is not managed.
+> Even if you see MDM URLs this does not mean that the device is managed by an MDM. The information is displayed if the tenant has MDM configuration for auto-enrollment even if the device itself is not managed.
### Sample tenant details output
This section lists the status of various attributes for the user currently logge
> [!NOTE] > The command must run in a user context to retrieve valid status. -- **NgcSet:** - Set to ΓÇ£YESΓÇ¥ if a Windows Hello key is set for the current logged on user.-- **NgcKeyId:** - ID of the Windows Hello key if one is set for the current logged on user.-- **CanReset:** - Denotes if the Windows Hello key can be reset by the user. -- **Possible values:** - DestructiveOnly, NonDestructiveOnly, DestructiveAndNonDestructive, or Unknown if error. -- **WorkplaceJoined:** - Set to ΓÇ£YESΓÇ¥ if Azure AD registered accounts have been added to the device in the current NTUSER context.-- **WamDefaultSet:** - Set to ΓÇ£YESΓÇ¥ if a WAM default WebAccount is created for the logged in user. This field could display an error if dsreg /status is run from an elevated command prompt. -- **WamDefaultAuthority:** - Set to ΓÇ£organizationsΓÇ¥ for Azure AD.-- **WamDefaultId:** - Always ΓÇ£https://login.microsoft.comΓÇ¥ for Azure AD.-- **WamDefaultGUID:** - The WAM providerΓÇÖs (Azure AD/Microsoft account) GUID for the default WAM WebAccount.
+- **NgcSet:** Set to "YES" if a Windows Hello key is set for the current logged on user.
+- **NgcKeyId:** ID of the Windows Hello key if one is set for the current logged on user.
+- **CanReset:** Denotes if the Windows Hello key can be reset by the user.
+- **Possible values:** DestructiveOnly, NonDestructiveOnly, DestructiveAndNonDestructive, or Unknown if error.
+- **WorkplaceJoined:** Set to "YES" if Azure AD registered accounts have been added to the device in the current NTUSER context.
+- **WamDefaultSet:** Set to "YES" if a WAM default WebAccount is created for the logged in user. This field could display an error if dsreg /status is run from an elevated command prompt.
+- **WamDefaultAuthority:** Set to "organizations" for Azure AD.
+- **WamDefaultId:** Always "https://login.microsoft.com" for Azure AD.
+- **WamDefaultGUID:** The WAM provider's (Azure AD/Microsoft account) GUID for the default WAM WebAccount.
### Sample user state output
This section can be ignored for Azure AD registered devices.
> [!NOTE] > The command must run in a user context to retrieve valid status for that user. -- **AzureAdPrt:** - Set to ΓÇ£YESΓÇ¥ if a PRT is present on the device for the logged-on user.-- **AzureAdPrtUpdateTime:** - Set to the time in UTC when the PRT was last updated.-- **AzureAdPrtExpiryTime:** - Set to the time in UTC when the PRT is going to expire if it is not renewed.-- **AzureAdPrtAuthority:** - Azure AD authority URL-- **EnterprisePrt:** - Set to ΓÇ£YESΓÇ¥ if the device has PRT from on-premises ADFS. For hybrid Azure AD joined devices the device could have PRT from both Azure AD and on-premises AD simultaneously. On-premises joined devices will only have an Enterprise PRT.-- **EnterprisePrtUpdateTime:** - Set to the time in UTC when the Enterprise PRT was last updated.-- **EnterprisePrtExpiryTime:** - Set to the time in UTC when the PRT is going to expire if it is not renewed.-- **EnterprisePrtAuthority:** - ADFS authority URL
+- **AzureAdPrt:** Set to "YES" if a PRT is present on the device for the logged-on user.
+- **AzureAdPrtUpdateTime:** Set to the time in UTC when the PRT was last updated.
+- **AzureAdPrtExpiryTime:** Set to the time in UTC when the PRT is going to expire if it is not renewed.
+- **AzureAdPrtAuthority:** Azure AD authority URL
+- **EnterprisePrt:** Set to "YES" if the device has PRT from on-premises ADFS. For hybrid Azure AD joined devices the device could have PRT from both Azure AD and on-premises AD simultaneously. On-premises joined devices will only have an Enterprise PRT.
+- **EnterprisePrtUpdateTime:** Set to the time in UTC when the Enterprise PRT was last updated.
+- **EnterprisePrtExpiryTime:** Set to the time in UTC when the PRT is going to expire if it is not renewed.
+- **EnterprisePrtAuthority:** ADFS authority URL
### Sample SSO state output
This section is displayed only if the device is domain joined and is unable to h
This section performs various tests to help diagnose join failures. This section also includes the details of the previous (?). This information includes the error phase, the error code, the server request ID, server response http status, server response error message. -- **User Context:** - The context in which the diagnostics are run. Possible values: SYSTEM, UN-ELEVATED User, ELEVATED User.
+- **User Context:** The context in which the diagnostics are run. Possible values: SYSTEM, UN-ELEVATED User, ELEVATED User.
> [!NOTE] > Since the actual join is performed in SYSTEM context, running the diagnostics in SYSTEM context is closest to the actual join scenario. To run diagnostics in SYSTEM context, the dsregcmd /status command must be run from an elevated command prompt. -- **Client Time:** - The system time in UTC.-- **AD Connectivity Test:** - Test performs a connectivity test to the domain controller. Error in this test will likely result in Join errors in pre-check phase.-- **AD Configuration Test:** - Test reads and verifies whether the SCP object is configured properly in the on-premises AD forest. Errors in this test would likely result in Join errors in the discover phase with the error code 0x801c001d.-- **DRS Discovery Test:** - Test gets the DRS endpoints from discovery metadata endpoint and performs a user realm request. Errors in this test would likely result in Join errors in the discover phase.-- **DRS Connectivity Test:** - Test performs basic connectivity test to the DRS endpoint.-- **Token acquisition Test:** - Test tries to get an Azure AD authentication token if the user tenant is federated. Errors in this test would likely result in Join errors in the auth phase. If auth fails sync join will be attempted as fallback, unless fallback is explicitly disabled with the below registry key settings.
+- **Client Time:** The system time in UTC.
+- **AD Connectivity Test:** Test performs a connectivity test to the domain controller. Error in this test will likely result in Join errors in pre-check phase.
+- **AD Configuration Test:** Test reads and verifies whether the SCP object is configured properly in the on-premises AD forest. Errors in this test would likely result in Join errors in the discover phase with the error code 0x801c001d.
+- **DRS Discovery Test:** Test gets the DRS endpoints from discovery metadata endpoint and performs a user realm request. Errors in this test would likely result in Join errors in the discover phase.
+- **DRS Connectivity Test:** Test performs basic connectivity test to the DRS endpoint.
+- **Token acquisition Test:** Test tries to get an Azure AD authentication token if the user tenant is federated. Errors in this test would likely result in Join errors in the auth phase. If auth fails sync join will be attempted as fallback, unless fallback is explicitly disabled with the below registry key settings.
+ ```
- Keyname: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ
- Value: FallbackToSyncJoin
- Type: REG_DWORD
- Value: 0x0 -> Disabled
- Value: 0x1 -> Enabled
- Default (No Key): Enabled
- ```
-- **Fallback to Sync-Join:** - Set to ΓÇ£EnabledΓÇ¥ if the above registry key, to prevent the fallback to sync join with auth failures, is NOT present. This option is available from Windows 10 1803 and later.-- **Previous Registration:** - Time the previous Join attempt occurred. Only failed Join attempts are logged.-- **Error Phase:** - The stage of the join in which it was aborted. Possible values are pre-check, discover, auth, join.-- **Client ErrorCode:** - Client error code returned (HRESULT).-- **Server ErrorCode:** - Server error code if a request was sent to the server and server responded back with an error code. -- **Server Message:** - Server message returned along with the error code.-- **Https Status:** - Http status returned by the server.-- **Request ID:** - The client requestId sent to the server. Useful to correlate with server-side logs.
+Keyname: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ
+Value: FallbackToSyncJoin
+Type: REG_DWORD
+Value: 0x0 -> Disabled
+Value: 0x1 -> Enabled
+Default (No Key): Enabled
+```
+
+- **Fallback to Sync-Join:** Set to "Enabled" if the above registry key, to prevent the fallback to sync join with auth failures, is NOT present. This option is available from Windows 10 1803 and later.
+- **Previous Registration:** Time the previous Join attempt occurred. Only failed Join attempts are logged.
+- **Error Phase:** The stage of the join in which it was aborted. Possible values are pre-check, discover, auth, join.
+- **Client ErrorCode:** Client error code returned (HRESULT).
+- **Server ErrorCode:** Server error code if a request was sent to the server and server responded back with an error code.
+- **Server Message:** Server message returned along with the error code.
+- **Https Status:** Http status returned by the server.
+- **Request ID:** The client requestId sent to the server. Useful to correlate with server-side logs.
### Sample pre-join diagnostics output
The following example shows diagnostics tests are passing but the registration a
This section displays the output of sanity checks performed on a device joined to the cloud. -- **AadRecoveryEnabled:** - If ΓÇ£YESΓÇ¥, the keys stored in the device are not usable and the device is marked for recovery. The next sign in will trigger the recovery flow and re-register the device.-- **KeySignTest:** - If ΓÇ£PASSEDΓÇ¥ the device keys are in good health. If KeySignTest fails, the device will usually be marked for recovery. The next sign in will trigger the recovery flow and re-register the device. For hybrid Azure AD joined devices the recovery is silent. While Azure AD joined or Azure AD registered, devices will prompt for user authentication to recover and re-register the device if necessary. **The KeySignTest requires elevated privileges.**
+- **AadRecoveryEnabled:** If "YES", the keys stored in the device are not usable and the device is marked for recovery. The next sign in will trigger the recovery flow and re-register the device.
+- **KeySignTest:** If "PASSED" the device keys are in good health. If KeySignTest fails, the device will usually be marked for recovery. The next sign in will trigger the recovery flow and re-register the device. For hybrid Azure AD joined devices the recovery is silent. While Azure AD joined or Azure AD registered, devices will prompt for user authentication to recover and re-register the device if necessary. **The KeySignTest requires elevated privileges.**
#### Sample post-join diagnostics output
This section displays the output of sanity checks performed on a device joined t
## NGC prerequisite check
-This section performs the prerequisite checks for the provisioning of Windows Hello for Business (WHFB).
+This section performs the prerequisite checks for the provisioning of Windows Hello for Business (WHFB).
> [!NOTE] > You may not see NGC prerequisite check details in dsregcmd /status if the user already successfully configured WHFB. -- **IsDeviceJoined:** - Set to ΓÇ£YESΓÇ¥ if the device is joined to Azure AD.-- **IsUserAzureAD:** - Set to ΓÇ£YESΓÇ¥ if the logged in user is present in Azure AD .-- **PolicyEnabled:** - Set to "YES" if the WHFB policy is enabled on the device.-- **PostLogonEnabled:** - Set to "YES" if WHFB enrollment is triggered natively by the platform. If it's set to "NO", it indicates that Windows Hello for Business enrollment is triggered by a custom mechanism-- **DeviceEligible:** - Set to ΓÇ£YESΓÇ¥ if the device meets the hardware requirement for enrolling with WHFB.-- **SessionIsNotRemote:** - Set to ΓÇ£YESΓÇ¥ if the current user is logged in directly to the device and not remotely.-- **CertEnrollment:** - Specific to WHFB Certificate Trust deployment, indicating the certificate enrollment authority for WHFB. Set to ΓÇ£enrollment authorityΓÇ¥ if source of WHFB policy is Group Policy, ΓÇ£mobile device managementΓÇ¥ if source is MDM. ΓÇ£noneΓÇ¥ otherwise-- **AdfsRefreshToken:** - Specific to WHFB Certificate Trust deployment. Only present if CertEnrollment is ΓÇ£enrollment authorityΓÇ¥. Indicates if the device has an enterprise PRT for the user.-- **AdfsRaIsReady:** - Specific to WHFB Certificate Trust deployment. Only present if CertEnrollment is ΓÇ£enrollment authorityΓÇ¥. Set to ΓÇ£YESΓÇ¥ if ADFS indicated in discovery metadata that it supports WHFB *and* if logon certificate template is available.-- **LogonCertTemplateReady:** - Specific to WHFB Certificate Trust deployment. Only present if CertEnrollment is ΓÇ£enrollment authorityΓÇ¥. Set to ΓÇ£YESΓÇ¥ if state of logon certificate template is valid and helps troubleshoot ADFS RA.-- **PreReqResult:** - Provides result of all WHFB prerequisite evaluation. Set to ΓÇ£Will ProvisionΓÇ¥ if WHFB enrollment would be launched as a post-logon task when user signs in next time.
+- **IsDeviceJoined:** Set to "YES" if the device is joined to Azure AD.
+- **IsUserAzureAD:** Set to "YES" if the logged in user is present in Azure AD .
+- **PolicyEnabled:** Set to "YES" if the WHFB policy is enabled on the device.
+- **PostLogonEnabled:** Set to "YES" if WHFB enrollment is triggered natively by the platform. If it's set to "NO", it indicates that Windows Hello for Business enrollment is triggered by a custom mechanism
+- **DeviceEligible:** Set to "YES" if the device meets the hardware requirement for enrolling with WHFB.
+- **SessionIsNotRemote:** Set to "YES" if the current user is logged in directly to the device and not remotely.
+- **CertEnrollment:** Specific to WHFB Certificate Trust deployment, indicating the certificate enrollment authority for WHFB. Set to "enrollment authority" if source of WHFB policy is Group Policy, "mobile device management" if source is MDM. "none" otherwise
+- **AdfsRefreshToken:** Specific to WHFB Certificate Trust deployment. Only present if CertEnrollment is "enrollment authority". Indicates if the device has an enterprise PRT for the user.
+- **AdfsRaIsReady:** Specific to WHFB Certificate Trust deployment. Only present if CertEnrollment is "enrollment authority". Set to "YES" if ADFS indicated in discovery metadata that it supports WHFB *and* if logon certificate template is available.
+- **LogonCertTemplateReady:** Specific to WHFB Certificate Trust deployment. Only present if CertEnrollment is "enrollment authority". Set to "YES" if state of logon certificate template is valid and helps troubleshoot ADFS RA.
+- **PreReqResult:** Provides result of all WHFB prerequisite evaluation. Set to "Will Provision" if WHFB enrollment would be launched as a post-logon task when user signs in next time.
### Sample NGC prerequisite check output
active-directory Direct Federation Adfs https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/external-identities/direct-federation-adfs.md
Previously updated : 07/01/2019 Last updated : 04/27/2021
An AD FS server must already be set up and functioning before you begin this pro
1. In the **Edit Claim Rules** wizard, select **Add Rule**. In **Choose Rule Type**, select **Send Claims Using a Custom Rule**. Select *Next*. 1. In **Configure Claim Rule**, specify the following values:
- - **Claim rule name**: Issue Immutable Id
+ - **Claim rule name**: Issue Immutable ID
- **Custom rule**: `c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"] => issue(store = "Active Directory", types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), query = "samAccountName={0};objectGUID;{1}", param = regexreplace(c.Value, "(?<domain>[^\\]+)\\(?<user>.+)", "${user}"), param = c.Value);` 1. Select **Finish**.
An AD FS server must already be set up and functioning before you begin this pro
1. Click **OK**. The AD FS server is now configured for direct federation using WS-Fed. ## Next steps
-Next, you'll [configure direct federation in Azure AD](direct-federation.md#step-2-configure-direct-federation-in-azure-ad) either in the Azure AD portal or by using PowerShell.
+Next, you'll [configure direct federation in Azure AD](direct-federation.md#step-3-configure-direct-federation-in-azure-ad) either in the Azure AD portal or by using PowerShell.
active-directory Direct Federation https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/external-identities/direct-federation.md
Previously updated : 04/23/2021 Last updated : 04/28/2021
This article describes how to set up direct federation with another organization for B2B collaboration. You can set up direct federation with any organization whose identity provider (IdP) supports the SAML 2.0 or WS-Fed protocol. When you set up direct federation with a partner's IdP, new guest users from that domain can use their own IdP-managed organizational account to sign in to your Azure AD tenant and start collaborating with you. There's no need for the guest user to create a separate Azure AD account.
+> [!IMPORTANT]
+> - We've removed the limitation that required the authentication URL domain to match the target domain or be from an allowed identity provider. For details, see [Step 1: Determine if the partner needs to update their DNS text records](#step-1-determine-if-the-partner-needs-to-update-their-dns-text-records).
+>- We now recommend that the partner set the audience of the SAML or WS-Fed based IdP to a tenanted audience. Refer to the [SAML 2.0](#required-saml-20-attributes-and-claims) and [WS-Fed](#required-ws-fed-attributes-and-claims) required attributes and claims sections below.
+ ## When is a guest user authenticated with direct federation? After you set up direct federation with an organization, any new guest users you invite will be authenticated using direct federation. ItΓÇÖs important to note that setting up direct federation doesnΓÇÖt change the authentication method for guest users who have already redeemed an invitation from you. Here are some examples: - If guest users have already redeemed invitations from you, and you subsequently set up direct federation with their organization, those guest users will continue to use the same authentication method they used before you set up direct federation.
You can also give Direct federation guest users a direct link to an application
### DNS-verified domains in Azure AD The domain you want to federate with must ***not*** be DNS-verified in Azure AD. You're allowed to set up direct federation with unmanaged (email-verified or "viral") Azure AD tenants because they aren't DNS-verified.
-### Authentication URL
-Direct federation is only allowed for policies where the authentication URLΓÇÖs domain matches the target domain, or where the authentication URL is one of these allowed identity providers (this list is subject to change):
--- accounts.google.com-- pingidentity.com-- login.pingone.com-- okta.com-- oktapreview.com-- okta-emea.com-- my.salesforce.com-- federation.exostar.com-- federation.exostartest.com-
-For example, when setting up direct federation for **fabrikam.com**, the authentication URL `https://fabrikam.com/adfs` will pass the validation. A host in the same domain will also pass, for example `https://sts.fabrikam.com/adfs`. However, the authentication URL `https://fabrikamconglomerate.com/adfs` or `https://fabrikam.com.uk/adfs` for the same domain won't pass.
- ### Signing certificate renewal If you specify the metadata URL in the identity provider settings, Azure AD will automatically renew the signing certificate when it expires. However, if the certificate is rotated for any reason before the expiration time, or if you don't provide a metadata URL, Azure AD will be unable to renew it. In this case, you'll need to update the signing certificate manually.
When direct federation is established with a partner organization, it takes prec
No, the [email one-time passcode](one-time-passcode.md) feature should be used in this scenario. A ΓÇ£partially synced tenancyΓÇ¥ refers to a partner Azure AD tenant where on-premises user identities aren't fully synced to the cloud. A guest whose identity doesnΓÇÖt yet exist in the cloud but who tries to redeem your B2B invitation wonΓÇÖt be able to sign in. The one-time passcode feature would allow this guest to sign in. The direct federation feature addresses scenarios where the guest has their own IdP-managed organizational account, but the organization has no Azure AD presence at all. ### Once Direct Federation is configured with an organization, does each guest need to be sent and redeem an individual invitation? Setting up direct federation doesnΓÇÖt change the authentication method for guest users who have already redeemed an invitation from you. You can update a guest userΓÇÖs authentication method by [resetting their redemption status](reset-redemption-status.md).
-## Step 1: Configure the partner organizationΓÇÖs identity provider
-First, your partner organization needs to configure their identity provider with the required claims and relying party trusts.
+
+## Step 1: Determine if the partner needs to update their DNS text records
+
+Depending on the partner's IdP, the partner might need to update their DNS records to enable direct federation with you. Use the following steps to determine if DNS updates are needed.
+
+1. If the partner's IdP is one of these allowed identity providers, no DNS changes are needed (this list is subject to change):
+
+ - accounts.google.com
+ - pingidentity.com
+ - login.pingone.com
+ - okta.com
+ - oktapreview.com
+ - okta-emea.com
+ - my.salesforce.com
+ - federation.exostar.com
+ - federation.exostartest.com
+ - idaptive.app
+ - idaptive.qa
+
+2. If the IdP is not one of the allowed providers listed in the previous step, check the partner's IdP authentication URL to see if the domain matches the target domain or a host within the target domain. In other words, when setting up direct federation for `fabrikam.com`:
+
+ - If the authentication URL is `https://fabrikam.com` or `https://sts.fabrikam.com/adfs` (a host in the same domain), no DNS changes are needed.
+ - If the authentication URL is `https://fabrikamconglomerate.com/adfs` or `https://fabrikam.com.uk/adfs`, the domain doesn't match the fabrikam.com domain, so the partner will need to add a text record for the authentication URL to their DNS configuration; go to the next step.
+
+3. If DNS changes are needed based on the previous step, ask the partner to add a TXT record to their domain's DNS records, like the following example:
+
+ `fabrikam.com.ΓÇ» IN ΓÇ» TXT ΓÇ» DirectFedAuthUrl=https://fabrikamconglomerate.com/adfs`
+## Step 2: Configure the partner organizationΓÇÖs identity provider
+
+Next, your partner organization needs to configure their identity provider with the required claims and relying party trusts.
> [!NOTE] > To illustrate how to configure an identity provider for direct federation, weΓÇÖll use Active Directory Federation Services (AD FS) as an example. See the article [Configure direct federation with AD FS](direct-federation-adfs.md), which gives examples of how to configure AD FS as a SAML 2.0 or WS-Fed identity provider in preparation for direct federation.
Required attributes for the SAML 2.0 response from the IdP:
|Attribute |Value | ||| |AssertionConsumerService |`https://login.microsoftonline.com/login.srf` |
-|Audience |`urn:federation:MicrosoftOnline` |
+|Audience |`https://login.microsoftonline.com/<tenant ID>/` (Recommended tenanted audience.) Replace `<tenant ID>` with the tenant ID of the Azure AD tenant you're setting up direct federation with.<br><br>`urn:federation:MicrosoftOnline` (This value will be deprecated.) |
|Issuer |The issuer URI of the partner IdP, for example `http://www.example.com/exk10l6w90DHM0yi...` |
Required attributes in the WS-Fed message from the IdP:
|Attribute |Value | ||| |PassiveRequestorEndpoint |`https://login.microsoftonline.com/login.srf` |
-|Audience |`urn:federation:MicrosoftOnline` |
+|Audience |`https://login.microsoftonline.com/<tenant ID>/` (Recommended tenanted audience.) Replace `<tenant ID>` with the tenant ID of the Azure AD tenant you're setting up direct federation with.<br><br>`urn:federation:MicrosoftOnline` (This value will be deprecated.) |
|Issuer |The issuer URI of the partner IdP, for example `http://www.example.com/exk10l6w90DHM0yi...` | Required claims for the WS-Fed token issued by the IdP:
Required claims for the WS-Fed token issued by the IdP:
|ImmutableID |`http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID` | |emailaddress |`http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress` |
-## Step 2: Configure direct federation in Azure AD
+## Step 3: Configure direct federation in Azure AD
Next, you'll configure federation with the identity provider configured in step 1 in Azure AD. You can use either the Azure AD portal or PowerShell. It might take 5-10 minutes before the direct federation policy takes effect. During this time, don't attempt to redeem an invitation for the direct federation domain. The following attributes are required: - Issuer URI of partner IdP - Passive authentication endpoint of partner IdP (only https is supported)
Next, you'll configure federation with the identity provider configured in step
### To configure direct federation in Azure AD using PowerShell
-1. Install the latest version of the Azure AD PowerShell for Graph module ([AzureADPreview](https://www.powershellgallery.com/packages/AzureADPreview)). (If you need detailed steps, the Quickstart includes the guidance, [Powershell Module](b2b-quickstart-invite-powershell.md#prerequisites).)
+1. Install the latest version of the Azure AD PowerShell for Graph module ([AzureADPreview](https://www.powershellgallery.com/packages/AzureADPreview)). If you need detailed steps, the Quickstart includes the guidance, [PowerShell module](b2b-quickstart-invite-powershell.md#prerequisites).
2. Run the following command: ```powershell Connect-AzureAD ```
-1. At the sign-in prompt, sign in with the managed Global Administrator account.
-2. Run the following commands, replacing the values from the federation metadata file. For AD FS Server and Okta, the federation file is federationmetadata.xml, for example: `https://sts.totheclouddemo.com/federationmetadata/2007-06/federationmetadata.xml`.
+3. At the sign-in prompt, sign in with the managed Global Administrator account.
+4. Run the following commands, replacing the values from the federation metadata file. For AD FS Server and Okta, the federation file is federationmetadata.xml, for example: `https://sts.totheclouddemo.com/federationmetadata/2007-06/federationmetadata.xml`.
```powershell $federationSettings = New-Object Microsoft.Open.AzureAD.Model.DomainFederationSettings
Next, you'll configure federation with the identity provider configured in step
New-AzureADExternalDomainFederation -ExternalDomainName $domainName -FederationSettings $federationSettings ```
-## Step 3: Test direct federation in Azure AD
+## Step 4: Test direct federation in Azure AD
Now test your direct federation setup by inviting a new B2B guest user. For details, see [Add Azure AD B2B collaboration users in the Azure portal](add-users-administrator.md). ## How do I edit a direct federation relationship?
active-directory Hybrid Cloud To On Premises https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/external-identities/hybrid-cloud-to-on-premises.md
If your on-premises app uses SAML-based authentication, you can easily make thes
You must do both of the following: - Integrate the app using SAML as described in [Configure SAML-based single sign-on](../manage-apps/configure-saml-single-sign-on.md). Make sure to note what you use for the **Sign-on URL** value.-- Use Azure AD Application Proxy to publish the on-premises app, with **Azure Active Directory** configured as the authentication source. For instructions, see [Publish applications using Azure AD Application Proxy](../manage-apps/application-proxy-add-on-premises-application.md).
+- Use Azure AD Application Proxy to publish the on-premises app, with **Azure Active Directory** configured as the authentication source. For instructions, see [Publish applications using Azure AD Application Proxy](../app-proxy/application-proxy-add-on-premises-application.md).
When you configure the **Internal Url** setting, use the sign-on URL that you specified in the non-gallery application template. In this way, users can access the app from outside the organization boundary. Application Proxy performs the SAML single sign-on for the on-premises app.
You must do both of the following:
To provide B2B users access to on-premises applications that are secured with Integrated Windows Authentication and Kerberos constrained delegation, you need the following components: -- **Authentication through Azure AD Application Proxy**. B2B users must be able to authenticate to the on-premises application. To do this, you must publish the on-premises app through the Azure AD Application Proxy. For more information, see [Tutorial: Add an on-premises application for remote access through Application Proxy](../manage-apps/application-proxy-add-on-premises-application.md).
+- **Authentication through Azure AD Application Proxy**. B2B users must be able to authenticate to the on-premises application. To do this, you must publish the on-premises app through the Azure AD Application Proxy. For more information, see [Tutorial: Add an on-premises application for remote access through Application Proxy](../app-proxy/application-proxy-add-on-premises-application.md).
- **Authorization via a B2B user object in the on-premises directory**. The application must be able to perform user access checks, and grant access to the correct resources. IWA and KCD require a user object in the on-premises Windows Server Active Directory to complete this authorization. As described in [How single sign-on with KCD works](../manage-apps/application-proxy-configure-single-sign-on-with-kcd.md#how-single-sign-on-with-kcd-works), Application Proxy needs this user object to impersonate the user and get a Kerberos token to the app. > [!NOTE]
active-directory Active Directory Deployment Checklist P2 https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/fundamentals/active-directory-deployment-checklist-p2.md
As we continue to build on the previous phases, we identify candidate applicatio
| - | | - | | Identify your applications | Identify applications in use in your organization: on-premises, SaaS applications in the cloud, and other line-of-business applications. Determine if these applications can and should be managed with Azure AD. | No license required | | [Integrate supported SaaS applications in the gallery](../manage-apps/add-application-portal.md) | Azure AD has a gallery that contains thousands of pre-integrated applications. Some of the applications your organization uses are probably in the gallery accessible directly from the Azure portal. | Azure AD Free |
-| [Use Application Proxy to integrate on-premises applications](../manage-apps/application-proxy-add-on-premises-application.md) | Application Proxy enables users to access on-premises applications by signing in with their Azure AD account. | |
+| [Use Application Proxy to integrate on-premises applications](../app-proxy/application-proxy-add-on-premises-application.md) | Application Proxy enables users to access on-premises applications by signing in with their Azure AD account. | |
## Phase 4: Audit privileged identities, complete an access review, and manage user lifecycle
active-directory Auth Header Based https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/fundamentals/auth-header-based.md
Remote users need to securely single sign-on (SSO) into to on-premises applicati
## Implement header-based authentication with Azure AD
-* [Add an on-premises application for remote access through Application Proxy in Azure AD](../manage-apps/application-proxy-add-on-premises-application.md)
+* [Add an on-premises application for remote access through Application Proxy in Azure AD](../app-proxy/application-proxy-add-on-premises-application.md)
* [Header-based authentication for single sign-on with Application Proxy and PingAccess](../manage-apps/application-proxy-configure-single-sign-on-with-headers.md)
active-directory Auth Kcd https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/fundamentals/auth-kcd.md
There is a need to provide remote access, protect with pre-authentication, and p
* [Kerberos Constrained Delegation for single sign-on to your apps with Application Proxy](../manage-apps/application-proxy-configure-single-sign-on-with-kcd.md)
-* [Add an on-premises application for remote access through Application Proxy in Azure Active Directory](../manage-apps/application-proxy-add-on-premises-application.md)
+* [Add an on-premises application for remote access through Application Proxy in Azure Active Directory](../app-proxy/application-proxy-add-on-premises-application.md)
active-directory Auth Remote Desktop Gateway https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/fundamentals/auth-remote-desktop-gateway.md
You need to provide remote access and protect your Remote Desktop Services deplo
* [Publish remote desktop with Azure AD Application Proxy](../manage-apps/application-proxy-integrate-with-remote-desktop-services.md)
-* [Add an on-premises application for remote access through Application Proxy in Azure AD](../manage-apps/application-proxy-add-on-premises-application.md)
+* [Add an on-premises application for remote access through Application Proxy in Azure AD](../app-proxy/application-proxy-add-on-premises-application.md)
active-directory Concept Secure Remote Workers https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/fundamentals/concept-secure-remote-workers.md
The following table is intended to highlight the key actions for the following l
| [Enable ADFS smart lock out](/windows-server/identity/ad-fs/operations/configure-ad-fs-extranet-smart-lockout-protection) (If applicable) | Protects your users from experiencing extranet account lockout from malicious activity. | | [Enable Azure Active Directory smart lockout](../authentication/howto-password-smart-lockout.md) (if using managed identities) | Smart lockout assists in locking out bad actors who are trying to guess your users' passwords or use brute-force methods to get in. | | [Disable end-user consent to applications](../manage-apps/configure-user-consent.md) | The admin consent workflow gives admins a secure way to grant access to applications that require admin approval so end users do not expose corporate data. Microsoft recommends disabling future user consent operations to help reduce your surface area and mitigate this risk. |
-| [Enable remote access to on-premises legacy applications with Application Proxy](../manage-apps/application-proxy-add-on-premises-application.md) | Enable Azure AD Application Proxy and integrate with legacy apps for users to securely access on-premises applications by signing in with their Azure AD account. |
+| [Enable remote access to on-premises legacy applications with Application Proxy](../app-proxy/application-proxy-add-on-premises-application.md) | Enable Azure AD Application Proxy and integrate with legacy apps for users to securely access on-premises applications by signing in with their Azure AD account. |
| [Enable Secure hybrid access: Secure legacy apps with existing app delivery controllers and networks](../manage-apps/secure-hybrid-access.md) (if applicable). | Publish and protect your on-premises and cloud legacy authentication applications by connecting them to Azure AD with your existing application delivery controller or network. | | [Integrate supported SaaS applications from the gallery to Azure AD and enable Single sign on](../manage-apps/add-application-portal.md) | Azure AD has a gallery that contains thousands of pre-integrated applications. Some of the applications your organization uses are probably in the gallery accessible directly from the Azure portal. Provide access to corporate SaaS applications remotely and securely with improved user experience (SSO). | | [Automate user provisioning and deprovisioning from SaaS Applications](../app-provisioning/user-provisioning.md) (if applicable) | Automatically create user identities and roles in the cloud (SaaS) applications that users need access to. In addition to creating user identities, automatic provisioning includes the maintenance and removal of user identities as status or roles change, increasing your organization's security. |
The following table is intended to highlight the key actions for the following l
| [Enable ADFS smart lock out](/windows-server/identity/ad-fs/operations/configure-ad-fs-extranet-smart-lockout-protection) (If applicable) | Protects your users from experiencing extranet account lockout from malicious activity. | | [Enable Azure Active Directory smart lockout](../authentication/howto-password-smart-lockout.md) (if using managed identities) | Smart lockout assists in locking out bad actors who are trying to guess your users' passwords or use brute-force methods to get in. | | [Disable end-user consent to applications](../manage-apps/configure-user-consent.md) | The admin consent workflow gives admins a secure way to grant access to applications that require admin approval so end users do not expose corporate data. Microsoft recommends disabling future user consent operations to help reduce your surface area and mitigate this risk. |
-| [Enable remote access to on-premises legacy applications with Application Proxy](../manage-apps/application-proxy-add-on-premises-application.md) | Enable Azure AD Application Proxy and integrate with legacy apps for users to securely access on-premises applications by signing in with their Azure AD account. |
+| [Enable remote access to on-premises legacy applications with Application Proxy](../app-proxy/application-proxy-add-on-premises-application.md) | Enable Azure AD Application Proxy and integrate with legacy apps for users to securely access on-premises applications by signing in with their Azure AD account. |
| [Enable Secure hybrid access: Secure legacy apps with existing app delivery controllers and networks](../manage-apps/secure-hybrid-access.md) (if applicable). | Publish and protect your on-premises and cloud legacy authentication applications by connecting them to Azure AD with your existing application delivery controller or network. | | [Integrate supported SaaS applications from the gallery to Azure AD and enable Single sign on](../manage-apps/add-application-portal.md) | Azure AD has a gallery that contains thousands of pre-integrated applications. Some of the applications your organization uses are probably in the gallery accessible directly from the Azure portal. Provide access to corporate SaaS applications remotely and securely with improved user experience (SSO). | | [Automate user provisioning and deprovisioning from SaaS Applications](../app-provisioning/user-provisioning.md) (if applicable) | Automatically create user identities and roles in the cloud (SaaS) applications that users need access to. In addition to creating user identities, automatic provisioning includes the maintenance and removal of user identities as status or roles change, increasing your organization's security. |
active-directory Five Steps To Full Application Integration With Azure Ad https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/fundamentals/five-steps-to-full-application-integration-with-azure-ad.md
Traditionally, applications were kept secure by allowing access only while conne
![A diagram shows the Application Proxy Service in action. A user accesses "https://sales.contoso.com" and their request is redirected through "https://sales-contoso.msappproxy.net" in Azure Active Directory to the on premises address "http://sales"](./media/five-steps-to-full-application-integration-with-azure-ad\app-proxy.png)
-You can use [Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory](../manage-apps/application-proxy-add-on-premises-application.md) to enable Application Proxy and add an on-premises application to your Azure AD tenant.
+You can use [Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory](../app-proxy/application-proxy-add-on-premises-application.md) to enable Application Proxy and add an on-premises application to your Azure AD tenant.
In addition, you can integrate application delivery controllers like F5 Big-IP APM or Zscaler Private Access. By integrating these with Azure AD, you get the modern authentication and identity management of Azure AD alongside the traffic management and security features of the partner product. We call this solution [Secure Hybrid Access](../manage-apps/secure-hybrid-access.md). If you use any of the following services today, we have tutorials that will step you through how to integrate them with Azure AD.
active-directory Resilience App Development Overview https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/fundamentals/resilience-app-development-overview.md
These articles provide guidance on increasing resiliency in apps using the Micro
- [Build resilience into applications without users](resilience-daemon-app.md) - [Build resilience in your identity and access management infrastructure](resilience-in-infrastructure.md) - [Build resilience in your CIAM systems](resilience-b2c.md)-- [Build services that are resilent to metadata refresh](../develop/howto-build-services-resilent-to-metadata-refresh.md)
+- [Build services that are resilient to metadata refresh](../develop/howto-build-services-resilient-to-metadata-refresh.md)
active-directory Service Accounts Computer https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/fundamentals/service-accounts-computer.md
Title: Securing computer accounts | Azure Active Directory
-description: A guide to securing on-premises computer accounts.
+ Title: Secure computer accounts | Azure Active Directory
+description: A guide to helping secure on-premises computer accounts.
-# Securing computer accounts
+# Secure on-premises computer accounts
-The computer account, or LocalSystem account, is a built-in, highly privileged account with access to virtually all resources on the local computer. This account is not associated with any signed-on user account. Services running as LocalSystem access network resources by presenting the computer's credentials to remote servers. It presents credentials in the form <domain_name>\<computer_name>$. A computer accountΓÇÖs pre-defined name is NT AUTHORITY\SYSTEM. It can be used to start a service and provide security context for that service.
+A computer account, or LocalSystem account, is a built-in, highly privileged account with access to virtually all resources on the local computer. The account is not associated with any signed-on user account. Services run as LocalSystem access network resources by presenting the computer's credentials to remote servers in the format <domain_name>\\<computer_name>$. The computer account's predefined name is NT AUTHORITY\SYSTEM. You can use it to start a service and provide security context for that service.
-![[Picture 4](.\media\securing-service-accounts\secure-computer-accounts-image-1.png)](.\media\securing-service-accounts\secure-computer-accounts-image-1.png)
+![Screenshot of a list of local services on a computer account.](.\media\securing-service-accounts\secure-computer-accounts-image-1.png)
-## Benefits of using the computer account
+## Benefits of using a computer account
-The computer account provides the following benefits.
+A computer account provides the following benefits:
* **Unrestricted local access**: The computer account provides complete access to the machineΓÇÖs local resources.
-* **Automatic password management**: The computer account removes the need for you to manually change passwords. Instead, this account is a member of Active Directory and the account password is changed automatically. It also eliminates the need to register the service principal name for the service.
+* **Automatic password management**: Removes the need for you to manually change passwords. The account is a member of Active Directory, and the account password is changed automatically. Using a computer account eliminates the need to register the service principal name for the service.
-* **Limited access rights off-machine**: The default Access Control List (ACL) in Active Directory Domain Services permits minimal access for computer accounts. If this service were to be hacked, it would only have limited access to resources on your network.
+* **Limited access rights off-machine**: The default access-control list in Active Directory Domain Services (AD DS) permits minimal access to computer accounts. In the event of access by an unauthorized user, the service would have only limited access to resources on your network.
-## Assess security posture of computer accounts
+## Assess the security posture of computer accounts
-Potential challenges and associated mitigations when using computer accounts.
-
-| Issues| Mitigations |
+Some potential challenges and associated mitigations when you use a computer account are listed in the following table:
+
+| Issue | Mitigation |
| - | - |
-| Computer accounts are subject to deletion and recreation when the computer leaves and rejoins the domain.| Validate the need to add a computer to an AD group and verify which computer account has been added to a group using the example scripts provided on this page.|
-| If you add a computer account to a group, all services running as LocalSystem on that computer are given access rights of the group.| Be selective of the group memberships of your computer account. Avoid making computer accounts members of any domain administrator groups because the associated service has complete access to Active Directory Domain Services. |
-| Improper network defaults for LocalSystem| Do not assume that the computer account has the default limited access to network resources. Instead, check group memberships for this account carefully. |
-| Unknown services running as LocalSystem| Ensure that all services running under the LocalSystem account are Microsoft services or trusted services from third parties. |
-
+| Computer accounts are subject to deletion and re-creation when the computer leaves and rejoins the domain. | Validate the need to add a computer to an Active Directory group, and verify which computer account has been added to a group by using the example scripts in the next section of this article.|
+| If you add a computer account to a group, all services that run as LocalSystem on that computer are given the access rights of the group.| Be selective about the group memberships of your computer account. Avoid making a computer account a member of any domain administrator groups, because the associated service has complete access to AD DS. |
+| Improper network defaults for LocalSystem. | Do not assume that the computer account has the default limited access to network resources. Instead, check group memberships for the account carefully. |
+| Unknown services that run as LocalSystem. | Ensure that all services that run under the LocalSystem account are Microsoft services or trusted services from third parties. |
+| | |
-## Find services running under the computer account
+## Find services that run under the computer account
-Use the following PowerShell cmdlet to find services running under LocalSystem context
+To find services that run under the LocalSystem context, use the following PowerShell cmdlet:
```powershell- Get-WmiObject win32_service | select Name, StartName | Where-Object {($_.StartName -eq "LocalSystem")} ```
-**Find Computers accounts that are members of a specific group**
-
-Use the following PowerShell cmdlet to find computer accounts that are member of a specific group.
+To find computer accounts that are members of a specific group, run the following PowerShell cmdlet:
```powershell-
-```Get-ADComputer -Filter {Name -Like "*"} -Properties MemberOf | Where-Object {[STRING]$_.MemberOf -like "Your_Group_Name_here*"} | Select Name, MemberOf
+Get-ADComputer -Filter {Name -Like "*"} -Properties MemberOf | Where-Object {[STRING]$_.MemberOf -like "Your_Group_Name_here*"} | Select Name, MemberOf
```
-**Find Computers accounts that are members of privileged groups**
-
-Use the following PowerShell cmdlet to find computer accounts that are member of Identity Administrators groups (Domain Admins, Enterprise Admins, Administrators)
+To find computer accounts that are members of identity administrators groups (domain administrators, enterprise administrators, and administrators), run the following PowerShell cmdlet:
```powershell Get-ADGroupMember -Identity Administrators -Recursive | Where objectClass -eq "computer" ```+ ## Move from computer accounts > [!IMPORTANT]
-> Computer accounts are highly privileged accounts and should be used only when your service needs unrestricted access to local resources on the machine, and you cannot use a managed service account (MSA).
+> Computer accounts are highly privileged accounts and should be used only when your service needs unrestricted access to local resources on the machine and you can't use a managed service account (MSA).
-* Check with your service owner if their service can be run using an MSA, and use a group managed service account (gMSA) or a standalone managed service account (sMSA) if your service supports it.
+* Check with your service owner to see whether their service can be run by using an MSA, and use a group managed service account (gMSA) or a standalone managed service account (sMSA) if your service supports it.
-* Use a domain user account with just the privileges needed to run your service.
+* Use a domain user account with only the permissions that you need to run your service.
-## Next Steps
+## Next steps
-See the following articles on securing service accounts
+To learn more about securing service accounts, see the following articles:
* [Introduction to on-premises service accounts](service-accounts-on-premises.md)- * [Secure group managed service accounts](service-accounts-group-managed.md)- * [Secure standalone managed service accounts](service-accounts-standalone-managed.md)-
-* [Secure computer accounts](service-accounts-computer.md)
-
-* [Secure user accounts](service-accounts-user-on-premises.md)
-
+* [Secure user accounts](service-accounts-user-on-premises.md)
* [Govern on-premises service accounts](service-accounts-govern-on-premises.md)-
-
-
-
active-directory Service Accounts Govern On Premises https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/fundamentals/service-accounts-govern-on-premises.md
Title: Governing on-premises service accounts | Azure Active Directory
-description: A guide to creating and running an account lifecycle process for service accounts
+ Title: Govern on-premises service accounts | Azure Active Directory
+description: Use this guide to create and run an account lifecycle process for service accounts.
-# Governing on-premises service accounts
+# Govern on-premises service accounts
-There are four types of on-premises service accounts in Windows Active Directory:
+Active Directory offers four types of on-premises service accounts:
-* [Group managed service accounts](service-accounts-group-managed.md) (gMSAs)
+* [Group managed service accounts (gMSAs)](service-accounts-group-managed.md)
+* [Standalone managed service accounts (sMSAs)](service-accounts-standalone-managed.md)
+* [Computer accounts](service-accounts-computer.md)
+* [User accounts that function as service accounts](service-accounts-user-on-premises.md)
-* [standalone managed service accounts](service-accounts-standalone-managed.md) (sMSAs)
-* [Computer accounts](service-accounts-computer.md)
-
-* [User accounts functioning as service accounts](service-accounts-user-on-premises.md)
--
-It is critical to govern service accounts closely to:
-
-* Protect service accounts based on their use-case requirements and purpose.
-
-* Manage the lifecycle of service accounts and their credentials.
-
-* Assess service accounts based on the risk they'll be exposed to and the permissions they carry,
+It is critical to govern service accounts closely so that you can:
+* Protect them based on their use-case requirements and purpose.
+* Manage the lifecycle of the accounts and their credentials.
+* Assess them based on the risk they'll be exposed to and the permissions they carry.
* Ensure that Active Directory and Azure Active Directory have no stale service accounts with potentially far-reaching permissions. ## Principles for creating a new service account
-Use the following criteria when creating a new service account.
+When you create a service account, understand the considerations listed in the following table:
-| Principles| Considerations |
+| Principle| Consideration |
| - |- | | Service account mapping| Tie the service account to a single service, application, or script. | | Ownership| Ensure that there's an owner who requests and assumes responsibility for the account. |
-| Scope| Define the scope clearly and anticipate usage duration for the service account. |
-| Purpose| Create service accounts for a single specific purpose. |
-| Privilege| Apply the principle of least privilege by: <br>Never assigning them to built-in groups like administrators.<br> Removing local machine privileges where appropriate.<br>Tailoring access and using Active Directory delegation for directory access.<br>Using granular access permissions.<br>Setting account expirations and location-based restrictions on user-based service accounts |
-| Monitor and audit use| Monitor sign-in data and ensure it matches the intended usage. Set alerts for anomalous usage. |
+| Scope| Define the scope clearly, and anticipate usage duration for the service account. |
+| Purpose| Create service accounts for a single, specific purpose. |
+| Permissions | Apply the principle of *least permission*. To do so:<li>Never assign permissions to built-in groups, such as administrators.<li>Remove local machine permissions, where appropriate.<li>Tailor access, and use Active Directory delegation for directory access.<li>Use granular access permissions.<li>Set account expirations and location-based restrictions on user-based service accounts. |
+| Monitor and audit use| Monitor sign-in data, and ensure that it matches the intended usage. Set alerts for anomalous usage. |
+| | |
-### Enforce least privilege for user accounts and limit account overuse
+### Set restrictions for user accounts
-Use the following settings with user accounts used as service accounts:
+For user accounts that are used as service accounts, apply the following settings:
-* [**Account Expiry**](/powershell/module/activedirectory/set-adaccountexpiration?view=winserver2012-ps&preserve-view=true): set the service account to automatically expire a set time after its review period unless it's determined that it should continue
+* [**Account expiration**](/powershell/module/activedirectory/set-adaccountexpiration?view=winserver2012-ps&preserve-view=true): Set the service account to automatically expire at a set time after its review period, unless you've determined that the account should continue.
-* **LogonWorkstations**: restrict permissions for where the service account can sign in. If it runs locally on a machine and accesses only resources on that machine, restrict it from logging on anywhere else.
-
-* [**Cannot change password**](/powershell/module/activedirectory/set-aduser): prevent the service account from changing its own password by setting the parameter to false.
+* **LogonWorkstations**: Restrict permissions where the service account can sign in. If it runs locally on a machine and accesses only resources on that machine, restrict it from signing in anywhere else.
+* [**Cannot change password**](/powershell/module/addsadministration/set-aduser): Prevent the service account from changing its own password by setting the parameter to false.
## Build a lifecycle management process
-To maintain security of your service accounts, you must manage them from the time you identify the need until they're decommissioned.
+To help maintain the security of your service accounts, you must manage them from the time you identify the need until they're decommissioned.
-Use the following process for lifecycle management of service accounts:
+For lifecycle management of service accounts, use the following process:
-1. Collect usage information for the account
-1. Onboard the service account and app to configuration management database (CMDB)
-1. Perform risk assessment or formal review
+1. Collect usage information for the account.
+1. Move the service account and app to the configuration management database (CMDB).
+1. Perform risk assessment or a formal review.
1. Create the service account and apply restrictions. 1. Schedule and perform recurring reviews. Adjust permissions and scopes as necessary.
-1. Deprovision account when appropriate.
+1. Deprovision the account when appropriate.
### Collect usage information for the service account
-Collect the relevant business information for each service account. The below table shows minimum information to be collected, but you should collect everything necessary to make the business case for the accounts' existence.
+Collect relevant business information for each service account. The following table lists the minimum amount of information to collect, but you should collect everything that's necessary to make the business case for each account's existence.
-| Data| Details |
+| Data| Description |
| - | - |
-| Owner| User or group that is accountable for the service account |
-| Purpose| Purpose of the service account |
-| Permissions (Scopes)| Expected set of permissions |
-| Configuration management database (CMDB) links| Cross-link service account with target script/application and owner(s) |
-| Risk| Risk and business impact scoring based on security risk assessment |
-| Lifetime| Anticipated maximum lifetime to enable scheduling of account expiration or recertification |
--
-
+| Owner| The user or group that's accountable for the service account |
+| Purpose| The purpose of the service account |
+| Permissions (scopes)| The expected set of permissions |
+| CMDB links| The cross-link service account with the target script or application and owners |
+| Risk| The risk and business impact scoring, based on the security risk assessment |
+| Lifetime| The anticipated maximum lifetime for enabling the scheduling of account expiration or recertification |
+| | |
-Ideally, make the request for an account self-service, and require the relevant information. The owner, who can be an application or business owner, an IT member, or an infrastructure owner. Using a tool such as Microsoft forms for this request and associated information will make it easy to port it to your CMDB inventory tool if the account is approved.
+Ideally, you want to make the request for an account self-service, and require the relevant information. The owner can be an application or business owner, an IT member, or an infrastructure owner. By using a tool such as Microsoft Forms for this request and associated information, you'll make it easier to port it to your CMDB inventory tool if the account is approved.
### Onboard service account to CMDB
-Store the collected information in a CMDB-type application. In addition to the business information, include all dependencies to other infrastructure, apps, and processes. This central repository will make it easier to:
-
-* Assess risk.
-
-* Configure the service account with required restrictions.
+Store the collected information in a CMDB-type application. In addition to the business information, include all dependencies on other infrastructure, apps, and processes. This central repository makes it easier to:
-* Understand relevant functional and security dependencies.
+* Assess risk.
+* Configure the service account with the required restrictions.
+* Understand any relevant functional and security dependencies.
+* Conduct regular reviews for security and continued need.
+* Contact the owners for reviewing, retiring, and changing the service account.
-* Conduct regular reviews for security and continued need.
+Consider a service account that's used to run a website and has permissions to connect to one or more Human Resources (HR) SQL databases. The information stored in your CMDB for the service account, including example descriptions, is listed in the following table:
-* Contact the owner(s) for reviewing, retiring, and changing the service account.
-
-Consider a service account that is used to run a web site and has privileges to connect to one or more SQL databases. Information stored in your CMDB for this service account could be:
-
-|Data | Details|
+|Data | Example description|
| - | - | | Owner, Deputy| John Bloom, Anna Mayers |
-| Purpose| Run the HR webpage and connect to HR-databases. Can impersonate end user when accessing databases. |
-| Permissions, Scopes| HR-WEBServer: log on locally, run web page<br>HR-SQL1: log on locally, Read on all HR* database<br>HR-SQL2: log on locally, READ on SALARY* database |
+| Purpose| Run the HR webpage and connect to HR databases. Can impersonate end users when accessing databases. |
+| Permissions, scopes| HR-WEBServer: sign in locally; run web page<br>HR-SQL1: sign in locally; read permissions on all HR databases<br>HR-SQL2: sign in locally; read permissions on Salary database only |
| Cost Center| 883944 | | Risk Assessed| Medium; Business Impact: Medium; private information; Medium | | Account Restrictions| Log on to: only aforementioned servers; Cannot change password; MBI-Password Policy; |
-| Lifetime| unrestricted |
-| Review Cycle| Bi-annually (by owner, by security team, by privacy) |
-
-### Perform risk assessment or formal review of service account usage
-
-Given its permissions and purpose, assess the risk the account may pose to its associated application or service and to your infrastructure if it is compromised. Consider both direct and indirect risk.
-
-* What would an adversary gain direct access to?
-
-* What other information or systems can the service account access?
+| Lifetime| Unrestricted |
+| Review Cycle| Biannually (by owner, by security team, by privacy) |
+| | |
-* Can the account be used to grant additional permissions?
+### Perform a risk assessment or formal review of service account usage
-* How will you know when permissions change?
+Suppose your account is compromised by an unauthorized source. Assess the risks the account might pose to its associated application or service and to your infrastructure. Consider both direct and indirect risks.
-The risk assessment, once conducted and documented, may have impact on:
+* What would an unauthorized user gain direct access to?
+* What other information or systems can the service account access?
+* Can the account be used to grant additional permissions?
+* How will you know when the permissions change?
-* Account restrictions
+After you've conducted and documented the risk assessment, you might find that the risks have an impact on:
-* Account lifetime
-
-* Account review requirements (cadence and reviewers)
+* Account restrictions.
+* Account lifetime.
+* Account review requirements (cadence and reviewers).
### Create a service account and apply account restrictions
-Create service account only after relevant information is documented in your CMDB and you perform a risk assessment. Account restrictions should be aligned to risk assessment. Consider the following restrictions when relevant to you assessment.:
-
-* [Account Expiry](/powershell/module/activedirectory/set-adaccountexpiration?view=winserver2012-ps&preserve-view=true)
+Create a service account only after you've completed the risk assessment and documented the relevant information in your CMDB. Align the account restrictions with the risk assessment. Consider the following restrictions when they're relevant to your assessment:
- * For all user accounts used as service accounts, define a realistic and definite end-date for use. Set this using the "Account Expires" flag. For more details, refer to[ Set-ADAccountExpiration](/powershell/module/activedirectory/set-adaccountexpiration).
+* For all user accounts that you use as service accounts, define a realistic, definite end date. Set the date by using the **Account Expires** flag. For more information, see [Set-ADAccountExpiration](/powershell/module/activedirectory/set-adaccountexpiration).
-* Log On To ([LogonWorkstation](/powershell/module/activedirectory/set-aduser))
+* Login to the [LogonWorkstation](/powershell/module/activedirectory/set-aduser).
-* [Password Policy](../../active-directory-domain-services/password-policy.md) requirements
+* [Password Policy](../../active-directory-domain-services/password-policy.md) requirements.
-* Creation in an [OU location](/windows-server/identity/ad-ds/plan/delegating-administration-of-account-ous-and-resource-ous) that ensures management only for privileged users
+* Account creation in an [organizational unit location](/windows-server/identity/ad-ds/plan/delegating-administration-of-account-ous-and-resource-ous) that ensures management only for allowed users.
-* Set up and collect auditing [that detects changes](/windows/security/threat-protection/auditing/audit-directory-service-changes) to the service account ΓÇô and [service account use](https://www.manageengine.com/products/active-directory-audit/how-to/audit-kerberos-authentication-events.html).
+* Setting up and collecting auditing [that detects changes](/windows/security/threat-protection/auditing/audit-directory-service-changes) to the service account, and [service account use](https://www.manageengine.com/products/active-directory-audit/how-to/audit-kerberos-authentication-events.html).
-When ready to put into production, grant access to the service account securely.
+When you're ready to put the service account into production, grant access to it more securely.
### Schedule regular reviews of service accounts
-Set up regular reviews of service accounts classified as medium and high risk. Reviews should include:
+Set up regular reviews of service accounts that are classified as medium and high risk. Reviews should include:
-* Owner attestation to the continued need for the account, and justification of privileges and scopes.
+* Owner attestation to the continued need for the account, and a justification of permissions and scopes.
-* Review by privacy and security teams, including evaluation of upstream and downstream connections.
+* Review by privacy and security teams, including an evaluation of upstream and downstream connections.
-* Data from audits ensuring it is being used only for intended purposes
+* Data from audits, ensuring that it's being used only for its intended purposes.
### Deprovision service accounts
-In your deprovisioning process, first remove permissions and monitor, then remove the account if appropriate.
+In your deprovisioning process, first remove permissions and monitoring, and then remove the account, if appropriate.
-Deprovision service accounts when:
+You deprovision service accounts when:
-* The script or application the service account was created for is retired.
+* The script or application that the service account was created for is retired.
-* The function within the script or application, which the service account is used for (for example, access to a specific resource) is retired.
+* The function within the script or application, which the service account is used for (for example, access to a specific resource), is retired.
* The service account has been replaced with a different service account.
-After removing all permissions, use this process for removing the account.
+After you've removed all permissions, remove the account by doing the following:
-1. Once the associated application or script is deprovisioned, monitor sign-ins and resource access for the associated service account(s) to be sure it is not used in another process. If you are sure it is no longer needed, go to next step.
+1. When the associated application or script is deprovisioned, monitor the sign-ins and resource access for the associated service accounts to be sure that they're not being used in another process. If you're sure it's no longer needed, go to next step.
-2. Disable the service account from signing in and be sure it is no longer needed. Create a business policy for the time accounts should remain disabled.
+1. Disable the service account to prevent sign-in, and ensure that it's no longer needed. Create a business policy for the time during which accounts should remain disabled.
-3. Delete the service account after the remain disabled policy is fulfilled.
+1. After the remain-disabled policy is fulfilled, delete the service account.
- * For MSAs, you can [uninstall it](/powershell/module/activedirectory/uninstall-adserviceaccount?view=winserver2012-ps&preserve-view=true) using PowerShell or delete manually from the managed service account container.
+ * **For MSAs**: [Uninstall the account](/powershell/module/activedirectory/uninstall-adserviceaccount?view=winserver2012-ps&preserve-view=true) by using PowerShell, or delete it manually from the managed service account container.
- * For computer or user accounts, you can manually delete the account from in Active Directory.
+ * **For computer or user accounts**: Manually delete the account from within Active Directory.
## Next steps
-See the following articles on securing service accounts
-
-* [Introduction to on-premises service accounts](service-accounts-on-premises.md)
-* [Secure group managed service accounts](service-accounts-group-managed.md)
-
-* [Secure standalone managed service accounts](service-accounts-standalone-managed.md)
-
-* [Secure computer accounts](service-accounts-computer.md)
+To learn more about securing service accounts, see the following articles:
+* [Introduction to on-premises service accounts](service-accounts-on-premises.md)
+* [Secure group managed service accounts](service-accounts-group-managed.md)
+* [Secure standalone managed service accounts](service-accounts-standalone-managed.md)
+* [Secure computer accounts](service-accounts-computer.md)
* [Secure user accounts](service-accounts-user-on-premises.md)-
-* [Govern on-premises service accounts](service-accounts-govern-on-premises.md)
active-directory Service Accounts Group Managed https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/fundamentals/service-accounts-group-managed.md
Title: Securing group managed service accounts | Azure Active Directory
-description: A guide to securing group managed service accounts computer accounts.
+ Title: Secure group managed service accounts | Azure Active Directory
+description: A guide to securing group managed service account (gMSA) computer accounts.
-# Securing group managed service accounts
+# Secure group managed service accounts
-Group managed service accounts (gMSAs) are managed domain accounts that are used for securing services. gMSAs can run on a single server, or in a server farm, such as systems behind a Network Load Balancer (NLB) or an Internet Information Services (IIS) server. Once you configure your services to use a gMSA principal, password management for that account is handled by Windows.
+Group managed service accounts (gMSAs) are managed domain accounts that you use to help secure services. gMSAs can run on a single server or on a server farm, such as systems behind a network load balancing or Internet Information Services (IIS) server. After you configure your services to use a gMSA principal, password management for that account is handled by the Windows operating system.
## Benefits of using gMSAs
-gMSAs offer a single identity solution with greater security while reducing administrative overhead by:
+gMSAs offer a single identity solution with greater security. At the same time, to help reduce administrative overhead, they:
-* **Setting strong passwords**. gMSAs use 240 byte randomly generated complex passwords. The complexity and length of gMSA passwords minimizes the likelihood of a service getting compromised by brute force or dictionary attacks.
+* **Set strong passwords**: gMSAs use 240-byte, randomly generated complex passwords. The complexity and length of gMSA passwords minimizes the likelihood of a service getting compromised by brute force or dictionary attacks.
-* **Cycling passwords regularly**. gMSAs shift password management to Windows, which changes the password every 30 days. Service and domain administrators no longer need to schedule password changes or manage service outages to keep service accounts secure.
+* **Cycle passwords regularly**: gMSAs shift password management to the Windows operating system, which changes the password every 30 days. Service and domain administrators no longer need to schedule password changes or manage service outages to help keep service accounts secure.
-* **Supporting deployment to server farms**. The ability to deploy gMSAs to multiple servers allows for the support of load balanced solutions where multiple hosts run the same service.
+* **Support deployment to server farms**: The ability to deploy gMSAs to multiple servers allows for the support of load balanced solutions where multiple hosts run the same service.
-* **Supporting simplified Server Principal Name (SPN) management**. You can set up SPN using PowerShell at the time of account creation. In addition, services that support automatic SPN registrations may do so against the gMSA, provided gMSA permissions are correctly set.
+* **Support simplified service principal name (SPN) management**: You can set up an SPN by using PowerShell when you create an account. In addition, services that support automatic SPN registrations might do so against the gMSA, provided that the gMSA permissions are correctly set.
## When to use gMSAs Use gMSAs as the preferred account type for on-premises services unless a service, such as Failover Clustering, doesn't support it. > [!IMPORTANT]
-> You must test your service with gMSAs prior to deployment into production. To do so, set up a test environment and ensure the application can use the gMSA, and access the resources it needs to access. For more information, see [Support for group managed service accounts](/system-center/scom/support-group-managed-service-accounts).
+> You must test your service with gMSAs before you deploy it into production. To do so, set up a test environment to ensure that the application can use the gMSA, and then access the resources it needs to access. For more information, see [Support for group managed service accounts](/system-center/scom/support-group-managed-service-accounts).
-If a service doesn't support the use of gMSAs, your next best option is to use a standalone Managed Service Account (sMSA). sMSAs provide the same functionality as a gMSA, but are intended for deployment on a single server only.
+If a service doesn't support the use of gMSAs, your next best option is to use a standalone managed service account (sMSA). An sMSA provides the same functionality as a gMSA, but it's intended for deployment on a single server only.
-If you can't use a gMSA or sMSA is supported by your service, then the service must be configured to run as a standard user account. Service and domain administrators are required to observe strong password management processes to keep the account secure.
+If you can't use a gMSA or sMSA that's supported by your service, you must configure the service to run as a standard user account. Service and domain administrators are required to observe strong password management processes to help keep the account secure.
## Assess the security posture of gMSAs
-gMSAs are inherently more secure than standard user accounts, which require ongoing password management. However, it's important to consider gMSAs' scope of access as you look at their overall security posture.
+gMSA accounts are inherently more secure than standard user accounts, which require ongoing password management. However, it's important to consider a gMSA's scope of access as you look at its overall security posture.
-The following table shows potential security issues and mitigations for using gMSAs.
+Potential security issues and mitigations for using gMSAs are shown in the following table:
-| Security issues| Mitigations |
+| Security issue| Mitigation |
| - | - |
-| gMSA is a member of privileged groups. | Review your group memberships. To do so you can create a PowerShell script to enumerate all group memberships, and then filter a resultant CSV file by the names of your gMSA files. <br>Remove the gMSA from privileged groups.<br> Grant the gMSA only the rights and permissions it requires to run its service (consult with your service vendor).
-| gMSA has read/write access to sensitive resources. | Audit access to sensitive resources. Archive audit logs to a SIEM, for example Azure Log Analytics or Azure Sentinel, for analysis. Remove unnecessary resource permissions if an undesirable level of access is detected. |
+| gMSA is a member of privileged groups. | <li>Review your group memberships. To do so, you create a PowerShell script to enumerate all group memberships. You can then filter a resultant CSV file by the names of your gMSA files.<li>Remove the gMSA from privileged groups.<li>Grant the gMSA only the rights and permissions it requires to run its service (consult with your service vendor).
+| gMSA has read/write access to sensitive resources. | <li>Audit access to sensitive resources.<li>Archive audit logs to a SIEM, such as Azure Log Analytics or Azure Sentinel, for analysis.<li>Remove unnecessary resource permissions if you detect an undesirable level of access. |
+| | |
## Find gMSAs
-Your organization may already have gMSAs created. Run the following PowerShell cmdlet to retrieve these accounts:
+Your organization might already have created gMSAs. To retrieve these accounts, run the following PowerShell cmdlets:
-To work effectively, gMSAs must be in the Managed Service Accounts organizational unit (OU).
+```powershell
+Get-ADServiceAccount
+Install-ADServiceAccount
+New-ADServiceAccount
+Remove-ADServiceAccount
+Set-ADServiceAccount
+Test-ADServiceAccount
+Uninstall-ADServiceAccount
+```
-
-![Screen shot of managed service account OU.](./media/securing-service-accounts/secure-gmsa-image-1.png)
-To find service MSAs that may not be there, see the following commands.
+To work effectively, gMSAs must be in the managed service account's organizational unit (OU).
-**To find all service accounts, including gMSAs and sMSAs:**
+
+![Screen shot of a gMSA account in the managed service account OU.](./media/securing-service-accounts/secure-gmsa-image-1.png)
+To find service MSAs that might not be in the list, run the following commands:
```powershell Get-ADServiceAccount -Filter *
-# This PowerShell cmdlet will return all Managed Service Accounts (both gMSAs and sMSAs). An administrator can differentiate between the two by examining the ObjectClass attribute on returned accounts.
+# This PowerShell cmdlet will return all managed service accounts (both gMSAs and sMSAs). An administrator can differentiate between the two by examining the ObjectClass attribute on returned accounts.
# For gMSA accounts, ObjectClass = msDS-GroupManagedServiceAccount
Get-ADServiceAccount ΓÇôFilter * | where $_.ObjectClass -eq "msDS-GroupManagedSe
## Manage gMSAs
-You can use the following Active Directory PowerShell cmdlets for managing gMSAs:
+To manage gMSA accounts, you can use the following Active Directory PowerShell cmdlets:
`Get-ADServiceAccount`
You can use the following Active Directory PowerShell cmdlets for managing gMSAs
`Uninstall-ADServiceAccount` > [!NOTE]
-> Beginning with Windows Server 2012, the *-ADServiceAccount cmdlets work with gMSAs by default. For more information on usage of the above cmdlets, see [**Getting Started with Group Managed Service Accounts**](/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts).
+> Beginning with Windows Server 2012, the *-ADServiceAccount cmdlets work with gMSAs by default. For more information about using the preceding cmdlets, see [Get started with group managed service accounts](/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts).
## Move to a gMSA
-gMSAs are the most secure type of service account for on-premises needs. If you can move to one, you should. Additionally, consider moving your services to Azure and your service accounts to Azure Active directory.
+gMSA accounts are the most secure type of service account for on-premises needs. If you can move to one, you should. Additionally, consider moving your services to Azure and your service accounts to Azure Active Directory. To move to a gMSA account, do the following:
-1. Ensure that the [KDS Root Key is deployed in the forest](/windows-server/security/group-managed-service-accounts/create-the-key-distribution-services-kds-root-key). This is a one-time operation.
+1. Ensure that the [Key Distribution Service (KDS) root key](/windows-server/security/group-managed-service-accounts/create-the-key-distribution-services-kds-root-key) is deployed in the forest. This is a one-time operation.
-2. [Create a new gMSA](/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts).
+1. [Create a new gMSA](/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts).
-3. Install the new gMSA on each host running the service.
+1. Install the new gMSA on each host that runs the service.
> [!NOTE]
- > For more information on creation and installation of gMSA on a host, prior to configuring your service to use gMSA, see [Getting Started with Group Managed Service Accounts](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj128431(v=ws.11))
+ > For more information about creating and installing a gMSA on a host, prior to configuring your service to use the gMSA, see [Get started with group managed service accounts](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj128431(v=ws.11)).
-
-4. Change your service identity to gMSA and specify a blank password.
+1. Change your service identity to gMSA, and specify a blank password.
-5. Validate that your service is working under the new gMSA identity.
+1. Validate that your service is working under the new gMSA identity.
-6. Delete the old service account identity.
+1. Delete the old service account identity.
## Next steps
-See the following articles on securing service accounts
-
-* [Introduction to on-premises service accounts](service-accounts-on-premises.md)
-
-* [Secure group managed service accounts](service-accounts-group-managed.md)
-
-* [Secure standalone managed service accounts](service-accounts-standalone-managed.md)
-
-* [Secure computer accounts](service-accounts-computer.md)
-* [Secure user accounts](service-accounts-user-on-premises.md)
+To learn more about securing service accounts, see the following articles:
-* [Govern on-premises service accounts](service-accounts-govern-on-premises.md)
+* [Introduction to on-premises service accounts](service-accounts-on-premises.md)
+* [Secure standalone managed service accounts](service-accounts-standalone-managed.md)
+* [Secure computer accounts](service-accounts-computer.md)
+* [Secure user accounts](service-accounts-user-on-premises.md)
+* [Govern on-premises service accounts](service-accounts-govern-on-premises.md)
active-directory Service Accounts On Premises https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/fundamentals/service-accounts-on-premises.md
# Introduction to Active Directory service accounts
-A service has a primary security identity that determines the access rights for local and network resources. The security context for a Microsoft Win32 service is determined by the service account that is used to start the service. A service account is used to:
-* identify and authenticate a service
-* successfully start a service
-* access or execute code or an application
-* start a process.
+A service has a primary security identity that determines the access rights for local and network resources. The security context for a Microsoft Win32 service is determined by the service account that's used to start the service. You use a service account to:
+* Identify and authenticate a service.
+* Successfully start a service.
+* Access or execute code or an application.
+* Start a process.
## Types of on-premises service accounts
-Based on your use case, you can use a managed service account (MSA), a computer account, or a user account to run a service. Services must be tested to confirm they can use a managed service account. If they can, you should use one.
+Depending on your use case, you can use a managed service account (MSA), a computer account, or a user account to run a service. You must first test a service to confirm that it can use a managed service account. If the service can use an MSA, you should use one.
-### Group MSA accounts
+### Group managed service accounts
-Use [group managed service accounts](service-accounts-group-managed.md) (gMSAs) whenever possible for services running in your on-premises environment. gMSAs provide a single identity solution for a service running on a server farm, or behind a network load balancer. They can also be used for a service running on a single server. [gMSAs have specific requirements that must be met](/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts)
+For services that run in your on-premises environment, use [group managed service accounts (gMSAs)](service-accounts-group-managed.md) whenever possible. gMSAs provide a single identity solution for services that run on a server farm or behind a network load balancer. gMSAs can also be used for services that run on a single server. For information about the requirements for gMSAs, see [Get started with group managed service accounts](/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts).
-### Standalone MSA accounts
+### Standalone managed service accounts
-If you can't use a gMSA, use a [standalone managed service accounts](service-accounts-standalone-managed.md)(sMSA). sMSAs require at least Windows Server 2008R2. Unlike gMSAs, sMSAs run only on one server. They can be used for multiple services on that server.
+If you can't use a gMSA, use a [standalone managed service account (sMSA)](service-accounts-standalone-managed.md). sMSAs require at least Windows Server 2008 R2. Unlike gMSAs, sMSAs run on only one server. They can be used for multiple services on that server.
-### Computer account
+### Computer accounts
-If you can't use an MSA, investigate using a [computer accounts](service-accounts-computer.md). The LocalSystem account is a predefined local account that has extensive privileges on the local computer, and acts as the computer identity on the network.
-ΓÇÄServices that run as a LocalSystem account access network resource by using the credentials of the computer account in the format
-<domain_name>\<computer_name>.
+If you can't use an MSA, consider using a [computer account](service-accounts-computer.md). The LocalSystem account is a predefined local account that has extensive permissions on the local computer and acts as the computer identity on the network.
-NT AUTHORITY\SYSTEM is the predefined name for the LocalSystem account. It can be used to start a service and provide the security context for that service.
+Services that run as a LocalSystem account access network resources by using the credentials of the computer account in the format <domain_name>\\<computer_name>. Its predefined name is NT AUTHORITY\SYSTEM. You can use it to start a service and provide a security context for that service.
> [!NOTE]
-> When a computer account is used, you cannot tell which service on the computer is using that account, and therefore cannot audit which service is making changes.
+> When you use a computer account, you can't determine which service on the computer is using that account. Consequently, you can't audit which service is making changes.
-### User account
+### User accounts
-If you can't use an MSA, investigate using a [user accounts](service-accounts-user-on-premises.md). User accounts can be a domain user account or a local user account.
+If you can't use an MSA, consider using a [user account](service-accounts-user-on-premises.md). A user account can be a *domain* user account or a *local* user account.
-A domain user account enables the service to take full advantage of the service security features of Windows and Microsoft Active Directory Domain Services. The service will have the local and network access granted to the account. It will also have the permissions of any groups of which the account is a member. Domain service accounts support Kerberos mutual authentication.
+A domain user account enables the service to take full advantage of the service security features of Windows and Microsoft Active Directory Domain Services. The service will have local and network permissions granted to the account. It will also have the permissions of any groups of which the account is a member. Domain service accounts support Kerberos mutual authentication.
-A local user account (name format: ".\UserName") exists only in the SAM database of the host computer; it doesn't have a user object in Active Directory Domain Services. A local account can't be authenticated by the domain. So, a service that runs in the security context of a local user account doesn't have access to network resources (except as an anonymous user). Services running in the local user context can't support Kerberos mutual authentication in which the service is authenticated by its clients. For these reasons, local user accounts are typically inappropriate for directory-enabled services.
+A local user account (name format: *.\UserName*) exists only in the Security Account Manager database of the host computer. It doesn't have a user object in Active Directory Domain Services. A local account can't be authenticated by the domain. So, a service that runs in the security context of a local user account doesn't have access to network resources (except as an anonymous user). Services that run in the local user context can't support Kerberos mutual authentication in which the service is authenticated by its clients. For these reasons, local user accounts are ordinarily inappropriate for directory-enabled services.
> [!IMPORTANT]
-> Service accounts should not be members of any privileged groups, as privileged group membership confers permissions that may be a security risk. Each service should have its own service account for auditing and security purposes.
+> Service accounts shouldn't be members of any privileged groups, because privileged group membership confers permissions that might be a security risk. Each service should have its own service account for auditing and security purposes.
## Choose the right type of service account
-| Criteria| gMSA| sMSA| Computer account| User account |
+| Criterion| gMSA| sMSA| Computer&nbsp;account| User&nbsp;account |
| - | - | - | - | - |
-| App runs on single server| Yes| Yes. Use a gMSA if possible| Yes. Use an MSA if possible| Yes. Use MSA if possible. |
-| App runs on multiple servers| Yes| No| No. Account is tied to the server| Yes. Use MSA if possible. |
-| App runs behind load balancers| Yes| No| No| Yes. Use only if you can't use a gMSA |
-| App runs on Windows Server 2008 R2| No| Yes| Yes. Use MSA if possible.| Yes. Use MSA if possible. |
-| Runs on Windows server 2012| Yes| Yes. Use gMSA if possible| Yes. Use MSA if possible| Yes. Use MSA if possible. |
-| Requirement to restrict service account to single server| No| Yes| Yes. Use sMSA if possible| No. |
+| App runs on a single server| Yes| Yes. Use a gMSA if possible.| Yes. Use an MSA if possible.| Yes. Use an MSA if possible. |
+| App runs on multiple servers| Yes| No| No. Account is tied to the server.| Yes. Use an MSA if possible. |
+| App runs behind a load balancer| Yes| No| No| Yes. Use only if you can't use a gMSA. |
+| App runs on Windows Server 2008 R2| No| Yes| Yes. Use an MSA if possible.| Yes. Use an MSA if possible. |
+| App runs on Windows Server 2012| Yes| Yes. Use a gMSA if possible.| Yes. Use an MSA if possible.| Yes. Use an MSA if possible. |
+| Requirement to restrict service account to single server| No| Yes| Yes. Use an sMSA if possible.| No |
+| | |
-
- ### Use server logs and PowerShell to investigate You can use server logs to determine which servers, and how many servers, an application is running on.
-You can run the following PowerShell command to get a listing of the Windows Server version for all servers on your network.
+To get a listing of the Windows Server version for all servers on your network, you can run the following PowerShell command:
```PowerShell
Out-GridView
## Find on-premises service accounts
-We recommend that you add a prefix such as ΓÇ£svc.ΓÇ¥ To all accounts used as service accounts. This naming convention will make them easier to find and manage. Also consider the use of a description attribute for the service account and the owner of the service account, this may be a team alias or security team owner.
+We recommend that you add a prefix such as ΓÇ£svc-ΓÇ¥ to all accounts that you use as service accounts. This naming convention will make the accounts easier to find and manage. Also consider using a description attribute for the service account and the owner of the service account. The description can be a team alias or security team owner.
-Finding on-premises service accounts is key to ensuring their security. And, it can be difficult for non-MSA accounts. We recommend reviewing all the accounts that have access to your important on-premises resources, and determining which computer or user accounts may be acting as service accounts. You can also use the following methods to find accounts.
+Finding on-premises service accounts is key to ensuring their security. Doing so can be difficult for non-MSA accounts. We recommend that you review all the accounts that have access to your important on-premises resources, and that you determine which computer or user accounts might be acting as service accounts.
-* The articles for each type of account have detailed steps for finding that account type. For links to these articles, see the Next steps section of this article.
+To learn how to find a service account, see the article about that account type in the ["Next steps" section](#next-steps).
## Document service accounts
-Once you have found the service accounts in your on-premises environment, document the following information about each account.
+After you've found the service accounts in your on-premises environment, document the following information:
-* The owner. The person accountable for maintaining the account.
+* **Owner**: The person accountable for maintaining the account.
-* The purpose. The application the account represents, or other purpose.
+* **Purpose**: The application the account represents, or other purpose.
-* Permission scopes. What permissions does it have, and should it have? What if any groups is it a member of?
+* **Permission scopes**: The permissions it has or should have, and any groups it's a member of.
-* Risk profile. What is the risk to your business if this account is compromised? If high risk, use an MSA.
+* **Risk profile**: The risk to your business if this account is compromised. If the risk is high, use an MSA.
-* Anticipated lifetime and periodic attestation. How long do you anticipate this account being live? How often must the owner review and attest to ongoing need?
+* **Anticipated lifetime and periodic attestation**: How long you anticipate that this account will be live, and how often the owner should review and attest to its ongoing need.
-* Password security. For user and local computer accounts, where the password is stored. Ensure passwords are kept secure, and document who has access. Consider using [Privileged Identity Management](../privileged-identity-management/pim-configure.md) to secure stored passwords.
+* **Password security**: For user and local computer accounts, where the password is stored. Ensure that passwords are kept secure, and document who has access. Consider using [Privileged Identity Management](../privileged-identity-management/pim-configure.md) to secure stored passwords.
## Next steps
-See the following articles on securing service accounts
-
-* [Introduction to on-premises service accounts](service-accounts-on-premises.md)
-
-* [Secure group managed service accounts](service-accounts-group-managed.md)
-
-* [Secure standalone managed service accounts](service-accounts-standalone-managed.md)
-
-* [Secure computer accounts](service-accounts-computer.md)
-
-* [Secure user accounts](service-accounts-user-on-premises.md)
+To learn more about securing service accounts, see the following articles:
+* [Secure group managed service accounts](service-accounts-group-managed.md)
+* [Secure standalone managed service accounts](service-accounts-standalone-managed.md)
+* [Secure computer accounts](service-accounts-computer.md)
+* [Secure user accounts](service-accounts-user-on-premises.md)
* [Govern on-premises service accounts](service-accounts-govern-on-premises.md)
active-directory Service Accounts Standalone Managed https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/fundamentals/service-accounts-standalone-managed.md
Title: Securing standalone managed service accounts | Azure Active Directory
+ Title: Secure standalone managed service accounts | Azure Active Directory
description: A guide to securing standalone managed service accounts.
-# Securing standalone managed service accounts
+# Secure standalone managed service accounts
-Standalone Managed Service Accounts (sMSAs) are managed domain accounts used to secure one or more services running on a server. They cannot be reused across multiple servers. sMSAs provide automatic password management, simplified service principal name (SPN) management, and the ability to delegate management to other administrators.
+Standalone managed service accounts (sMSAs) are managed domain accounts that you use to help secure one or more services that run on a server. They can't be reused across multiple servers. sMSAs provide automatic password management, simplified service principal name (SPN) management, and the ability to delegate management to other administrators.
In Active Directory, sMSAs are tied to a specific server that runs a service. You can find these accounts listed in the Active Directory Users and Computers snap-in of the Microsoft Management Console.
-![A screen shot of the Active Directory users and computers snap-in showing the managed service accounts OU.](./media/securing-service-accounts/secure-standalone-msa-image-1.png)
+![Screenshot of the Active Directory users and computers snap-in showing the managed service accounts OU.](./media/securing-service-accounts/secure-standalone-msa-image-1.png)
-Managed Service Accounts were introduced with Windows Server 2008R2 Active Directory Schema and require a minimum OS level of Windows Server 2008R2ΓÇï.
+Managed service accounts were introduced with Windows Server 2008 R2 Active Directory Schema, and they require at least Windows Server 2008 R2ΓÇï.
## Benefits of using sMSAs
-sMSAs offer greater security than user accounts used as service accounts, while reducing administrative overhead by:
+sMSAs offer greater security than user accounts that are used as service accounts. At the same time, to help reduce administrative overhead, they:
-* Setting strong passwords. sMSAs use 240 byte randomly generated complex passwords. The complexity and length of sMSA passwords minimizes the likelihood of a service getting compromised by brute force or dictionary attacks.
+* **Set strong passwords**: sMSAs use 240-byte, randomly generated complex passwords. The complexity and length of sMSA passwords minimizes the likelihood of a service getting compromised by brute force or dictionary attacks.
-* Cycling passwords regularly. Windows automatically changes the sMSA password every 30 days. Service and domain administrators donΓÇÖt need to schedule password changes or manage the associated downtime.
+* **Cycle passwords regularly**: Windows automatically changes the sMSA password every 30 days. Service and domain administrators donΓÇÖt need to schedule password changes or manage the associated downtime.
-* Simplifying SPN management. Service principal names are automatically updated if the Domain Functional Level (DFL) is Windows Server 2008 R2. ΓÇïFor instance, the service principal name is automatically updated in the following scenarios:
-
- * The host computer account is renamed. ΓÇï
-
- * The DNS name of the host computer is changed.
-
- * When adding or removing an additional sam-accountname or dns-hostname parameters using [PowerShell](/powershell/module/activedirectory/set-adserviceaccount)
+* **Simplify SPN management**: Service principal names are automatically updated if the domain functional level is Windows Server 2008 R2. For instance, the service principal name is automatically updated when you:
+ * Rename the host computer account.
+ * Change the domain name server (DNS) name of the host computer.
+ * Add or remove other sam-accountname or dns-hostname parameters by using [PowerShell](/powershell/module/activedirectory/set-adserviceaccount).
## When to use sMSAs
-sMSAs can simplify management and security tasks. Use sMSAs when you've one or more services deployed to a single server, and you cannot use a gMSA.
+sMSAs can simplify management and security tasks. Use sMSAs when you have one or more services deployed to a single server and you can't use a group managed service account (gMSA).
> [!NOTE]
-> While you can use sMSAs for more than one service, we recommend that each service have its own identity for auditing purposes.
+> Although you can use sMSAs for more than one service, we recommend that each service have its own identity for auditing purposes.
-If the creator of the software canΓÇÖt tell you if it can use an MSA, you must test your application. To do so, create a test environment and ensure it can access all required resources. See [create and install an sMSA](/archive/blogs/askds/managed-service-accounts-understanding-implementing-best-practices-and-troubleshooting) for step-by-step directions.
+If the creator of the software canΓÇÖt tell you whether it can use an MSA, you must test your application. To do so, create a test environment and ensure that it can access all required resources. For more information, see [Create and install an sMSA](/archive/blogs/askds/managed-service-accounts-understanding-implementing-best-practices-and-troubleshooting).
-### Assess security posture of sMSAs
+### Assess the security posture of sMSAs
sMSAs are inherently more secure than standard user accounts, which require ongoing password management. However, it's important to consider sMSAsΓÇÖ scope of access as part of their overall security posture.
-The following table shows how to mitigate potential security issues posed by sMSAs.
+To see how to mitigate potential security issues posed by sMSAs, refer to the following table:
-| Security issues| Mitigations |
+| Security issue| Mitigation |
| - | - |
-| sMSA is a member of privileged groups|Remove the sMSA from elevated privileged groups (such as Domain Admins). <br> Use the least privileged model and grant the sMSA only the rights and permissions it requires to run its service(s). <br> If you're unsure of the required permissions, consult the service creator. |
-| sMSA has read/write access to sensitive resources.|Audit access to sensitive resources. Archive audit logs to a SIEM (Azure Log Analytics or Azure Sentinel) for analysis. <br> Remediate resource permissions if an undesirable level of access is detected. |
-| By default, sMSA password rollover frequency is 30 days| Group policy can be used to tune the duration depending on enterprise security requirements. <br> *You can set the password expiration duration using the following path. <br>Computer Configuration\Policies\Windows Settings\Security Settings\Security Options\ΓÇïDomain member: Maximum machine account password age |
+| sMSA is a member of privileged groups. | <li>Remove the sMSA from elevated privileged groups, such as Domain Admins.<li>Use the *least privileged* model, and grant the sMSA only the rights and permissions it requires to run its services.<li>If you're unsure of the required permissions, consult the service creator. |
+| sMSA has read/write access to sensitive resources. | <li>Audit access to sensitive resources.<li>Archive audit logs to a Security Information and Event Management (SIEM) program, such as Azure Log Analytics or Azure Sentinel, for analysis.<li>Remediate resource permissions if an undesirable level of access is detected. |
+| By default, the sMSA password rollover frequency is 30 days. | You can use group policy to tune the duration, depending on enterprise security requirements. To set the password expiration duration, use the following path:<br>*Computer Configuration\Policies\Windows Settings\Security Settings\Security Options*. For domain member, use **Maximum machine account password age**. |
+| | |
The following table shows how to mitigate potential security issues posed by sMS
The challenges associated with sMSAs are as follows:
-| Challenges| Mitigations |
+| Challenge| Mitigation |
| - | - |
-| They can be used on a single server.| Use gMSAs if you need to use the account across servers. |
-| They cannot be used across domains.| Use gMSAs if you need to use the account across domains. |
-| Not all applications support sMSAs.| Use gMSAs if possible. If not use a standard user account or a computer account as recommended by the application creator. |
+| sMSAs can be used on a single server only. | Use a gMSA if you need to use the account across servers. |
+| sMSAs can't be used across domains. | Use a gMSA if you need to use the account across domains. |
+| Not all applications support sMSAs. | Use a gMSA if possible. Otherwise, use a standard user account or a computer account, as recommended by the application creator. |
+| | |
## Find sMSAs
-On any domain controller, run DSA.msc and expand the Managed Service Accounts container to view all sMSAs.
+On any domain controller, run DSA.msc, and then expand the managed service accounts container to view all sMSAs.
-The following PowerShell command returns all sMSAs and gMSAs in the Active Directory domain.
+To return all sMSAs and gMSAs in the Active Directory domain, run the following PowerShell command:
`Get-ADServiceAccount -Filter *`
-The following command returns only sMSAs in the Active Directory domain.
+To return only sMSAs in the Active Directory domain, run the following command:
`Get-ADServiceAccount -Filter * | where { $_.objectClass -eq "msDS-ManagedServiceAccount" }` ## Manage sMSAs
-You can use the following Active Directory PowerShell cmdlets for managing sMSAs:
-
-`Get-ADServiceAccount`
-
-` Install-ADServiceAccount`
-
-` New-ADServiceAccount`
-
-` Remove-ADServiceAccount`
-
-`Set-ADServiceAccount`
-
-`Test-ADServiceAccount`
+To manage your sMSAs, you can use the following Active Directory PowerShell cmdlets:
+`Get-ADServiceAccount`
+` Install-ADServiceAccount`
+` New-ADServiceAccount`
+` Remove-ADServiceAccount`
+`Set-ADServiceAccount`
+`Test-ADServiceAccount`
`Ininstall-ADServiceAccount` ## Move to sMSAs
-If an application service supports sMSA but not gMSAs, and is currently using a user account or computer account for the security context, [create and install an sMSA](/archive/blogs/askds/managed-service-accounts-understanding-implementing-best-practices-and-troubleshooting) on the server.
-
-Ideally, move resources to Azure, and use Azure Managed Identities or service principals.
+If an application service supports sMSAs but not gMSAs, and you're currently using a user account or computer account for the security context, [Create and install an sMSA](/archive/blogs/askds/managed-service-accounts-understanding-implementing-best-practices-and-troubleshooting) on the server.
-
+Ideally, you would move resources to Azure and use Azure Managed Identities or service principals.
## Next steps
-See the following articles on securing service accounts
-
-* [Introduction to on-premises service accounts](service-accounts-on-premises.md)
-
-* [Secure group managed service accounts](service-accounts-group-managed.md)
-* [Secure standalone managed service accounts](service-accounts-standalone-managed.md)
-
-* [Secure computer accounts](service-accounts-computer.md)
-
-* [Secure user accounts](service-accounts-user-on-premises.md)
+To learn more about securing service accounts, see the following articles:
+* [Introduction to on-premises service accounts](service-accounts-on-premises.md)
+* [Secure group managed service accounts](service-accounts-group-managed.md)
+* [Secure computer accounts](service-accounts-computer.md)
+* [Secure user accounts](service-accounts-user-on-premises.md)
* [Govern on-premises service accounts](service-accounts-govern-on-premises.md)-
active-directory Service Accounts User On Premises https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/fundamentals/service-accounts-user-on-premises.md
Title: Securing user-based service accounts | Azure Active Directory
-description: A guide to securing on-premises user accounts.
+ Title: Secure user-based service accounts | Azure Active Directory
+description: A guide to securing user-based service accounts.
-# Securing user-based service accounts in Active Directory
+# Secure user-based service accounts in Active Directory
-On-premises user accounts are the traditional approach for securing services running on Windows. Use these accounts as a last resort when global managed service accounts (gMSAs) and standalone managed service accounts (sMSAs) are not supported by your service. See overview of on-premises service accounts for information on selecting the best type of account to use. Also investigate if you can move your service to use an Azure service account like a managed identity or a service principle.
+Using on-premises user accounts is the traditional approach to helping secure services that run on Windows. Use these accounts as a last resort when group managed service accounts (gMSAs) and standalone managed service accounts (sMSAs) aren't supported by your service. For information about selecting the best type of account to use, see [Introduction to on-premises service accounts](service-accounts-on-premises.md).
-On-premises user accounts can be created to provide a security context for services and granted privileges required for the services to access local and network resources. They require manual password management much like any other Active Directory (AD) user account. Service and domain administrators are required to observe strong password management processes to keep these accounts secure.
+You might also want to investigate whether you can move your service to use an Azure service account such as a managed identity or a service principal.
-When using a user account as a service account, use it for a single service only. Name it in a way that makes it clear that it is a service account and for which service.
+You can create on-premises user accounts to provide a security context for the services and permissions that the accounts require to access local and network resources. On-premises user accounts require manual password management, much like any other Active Directory user account. Service and domain administrators are required to observe strong password management processes to help keep these accounts secure.
-## Benefits and challenges
-
-Benefits
+When you create a user account as a service account, use it for a single service only. Name it in a way that makes it clear that it's a service account and which service it's for.
-On-premises user accounts are the most versatile account type for use with services. User accounts used as service accounts can be controlled by all the policies govern normal user accounts. That said, use them only if you can't use an MSA. Also evaluate if a computer account is a better option.
+## Benefits and challenges
-Challenges with on-premises user accounts
+On-premises user accounts can provide significant benefits. They're the most versatile account type for use with services. User accounts used as service accounts can be controlled by all the policies that govern normal user accounts. But you should use them only if you can't use an MSA. Also evaluate whether a computer account is a better option.
-The following challenges are associated with the use of on-premises user accounts.
+The challenges associated with the use of on-premises user accounts are summarized in the following table:
-| Challenges| Mitigations |
+| Challenge | Mitigation |
| - | - |
-| Password management is a manual process that may lead to weaker security and service downtime.| Ensure that password complexity and password change are governed by a robust process that ensures regular updates with strong password. <br> Coordinate password change with a password update on the service, which will result in service downtime. |
-| Identifying on-premises user accounts that are acting as service accounts can be difficult.| Document and maintain records of service accounts deployed in your environment. <br> Track the account name and the resources to which they're assigned access. <br> Consider adding a prefix of svc_ to all user accounts used as service accounts. |
+| Password management is a manual process that can lead to weaker security and service downtime.| <li>Make sure that password complexity and password changes are governed by a robust process that ensures regular updates with strong passwords.<li>Coordinate password changes with a password update on the service, which will help reduce service downtime. |
+| Identifying on-premises user accounts that are acting as service accounts can be difficult. | <li>Document and maintain records of service accounts that are deployed in your environment.<li>Track the account name and the resources to which they're assigned access.<li>Consider adding a prefix of "svc-" to all user accounts that are used as service accounts. |
+| | |
## Find on-premises user accounts used as service accounts
-On-premises user accounts are just like any other AD user account. Consequently, it can be difficult to find these accounts as there's no single attribute of a user account that identifies it as a service account.
-
-We recommend that you create an easily identifiable naming convention for any user account used as a service account.
+On-premises user accounts are just like any other Active Directory user account. It can be difficult to find such accounts, because no single attribute of a user account identifies it as a service account.
-For example, add "service-" as a prefix, and name the service: ΓÇ£service-HRDataConnectorΓÇ¥.
+We recommend that you create an easily identifiable naming convention for any user account that you use as a service account. For example, you might add "svc-" as a prefix and name the service ΓÇ£svc-HRDataConnector.ΓÇ¥
-You can use some of the indicators below to find these service accounts, however, this may not find all such accounts.
+You can use some of the following criteria to find these service accounts. However, this approach might not find all accounts, such as:
-* Accounts trusted for delegation.
+* Accounts that are trusted for delegation.
+* Accounts with service principal names.
+* Accounts with passwords that are set to never expire.
-* Accounts with service principal names.
+To find the on-premises user accounts you've created for services, you can run the following PowerShell commands.
-* Accounts whose password is set to never expire.
-
-You can run the following PowerShell commands to find the on-premises user accounts created for services.
-
-### Find accounts trusted for delegation
+To find accounts that are trusted for delegation:
```PowerShell
Get-ADObject -Filter {(msDS-AllowedToDelegateTo -like '*') -or (UserAccountContr
```
-### Find accounts with service principle names
+To find accounts that have service principal names:
```PowerShell
Get-ADUser -Filter * -Properties servicePrincipalName | where {$_.servicePrincip
```
-
-
-### Find accounts with passwords set to never expire
+To find accounts with passwords that are set to never expire:
```PowerShell
Get-ADUser -Filter * -Properties PasswordNeverExpires | where {$_.PasswordNeverE
```
+You can also audit access to sensitive resources, and archive audit logs to a security information and event management (SIEM) system. By using systems such as Azure Log Analytics or Azure Sentinel, you can search for and analyze and service accounts.
-You can also audit access to sensitive resources, and archive audit logs to a security information and event management (SIEM) system. Using systems such as Azure Log Analytics or Azure Sentinel, you can search for and analyze and service accounts.
+## Assess the security of on-premises user accounts
-## Assess security of on-premises user accounts
+You can assess the security of on-premises user accounts that are being used as service accounts by using the following criteria:
-Assess the security of your on-premises user accounts being used as service accounts using the following criteria:
-
-* What is the password management policy?
-
-* Is the account a member of any privileged groups?
-
-* Does the account have read/write access to important resources?
+* What is the password management policy?
+* Is the account a member of any privileged groups?
+* Does the account have read/write permissions to important resources?
### Mitigate potential security issues
-The following table shows potential security issues and corresponding mitigations for on-premises user accounts.
+Potential security issues and their mitigations for on-premises user accounts are summarized in the following table:
-| Security issues| Mitigations |
+| Security issue | Mitigation |
| - | - |
-| Password management|* Ensure that password complexity and password change are governed by a robust process that ensures regular updates with strong password requirements. <br> * Coordinate password change with a password update to minimize service downtime. |
-| Account is a member of privileged groups.| Review group memberships. Remove the account from privileged groups. Grant the account only the rights and permissions it requires to run its service (consult with service vendor). For example, you may be able to deny sign-in locally or deny interactive sign-in. |
-| Account has read/write access to sensitive resources.| Audit access to sensitive resources. Archive audit logs to a SIEM (Azure Log Analytics or Azure Sentinel) for analysis. Remediate resource permissions if an undesirable level of access is detected. |
+| Password management.| <li>Ensure that password complexity and password change are governed by a robust process that includes regular updates and strong password requirements.<li>Coordinate password changes with a password update to minimize service downtime. |
+| The account is a member of privileged groups.| <li>Review group memberships.<li>Remove the account from privileged groups.<li>Grant the account only the rights and permissions it requires to run its service (consult with service vendor). For example, you might be able to deny sign-in locally or deny interactive sign-in. |
+| The account has read/write permissions to sensitive resources.| <li>Audit access to sensitive resources.<li>Archive audit logs to a SIEM (Azure Log Analytics or Azure Sentinel) for analysis.<li>Remediate resource permissions if an undesirable level of access is detected. |
+| | |
## Move to more secure account types
-Microsoft does not recommend that customers use on-premises user accounts as service accounts. For any service using this type of account, assess if it can instead be configured to use a gMSA or a sMSA.
+Microsoft doesn't recommend that you use on-premises user accounts as service accounts. For any service that uses this type of account, assess whether it can instead be configured to use a gMSA or an sMSA.
-Additionally, evaluate if the service itself could be moved to Azure so that more secure service account types can be used.
+Additionally, evaluate whether the service itself could be moved to Azure so that more secure service account types can be used.
## Next steps
-See the following articles on securing service accounts
-
-* [Introduction to on-premises service accounts](service-accounts-on-premises.md)
-
-* [Secure group managed service accounts](service-accounts-group-managed.md)
-
-* [Secure standalone managed service accounts](service-accounts-standalone-managed.md)
-
-* [Secure computer accounts](service-accounts-computer.md)
-* [Secure user accounts](service-accounts-user-on-premises.md)
+To learn more about securing service accounts, see the following articles:
+* [Introduction to on-premises service accounts](service-accounts-on-premises.md)
+* [Secure group managed service accounts](service-accounts-group-managed.md)
+* [Secure standalone managed service accounts](service-accounts-standalone-managed.md)
+* [Secure computer accounts](service-accounts-computer.md)
* [Govern on-premises service accounts](service-accounts-govern-on-premises.md)
active-directory Whats New Archive https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/fundamentals/whats-new-archive.md
To help provide you with our strongest encryption, we're going to begin limiting
To maintain the connection to the Application Proxy service throughout this change, we recommend that you make sure your client-server and browser-server combinations are updated to use TLS 1.2. We also recommend that you make sure to include any client systems used by your employees to access apps published through the Application Proxy service.
-For more information, see [Add an on-premises application for remote access through Application Proxy in Azure Active Directory](../manage-apps/application-proxy-add-on-premises-application.md).
+For more information, see [Add an on-premises application for remote access through Application Proxy in Azure Active Directory](../app-proxy/application-proxy-add-on-premises-application.md).
For more information, see [Getting started with the Azure Multi-Factor Authentic
To help provide best-in-class encryption for our customers, we're limiting access to only TLS 1.2 protocols on the Application Proxy service. This change is gradually being rolled out to customers who are already only using TLS 1.2 protocols, so you shouldn't see any changes.
-Deprecation of TLS 1.0 and TLS 1.1 happens on August 31, 2019, but we'll provide additional advanced notice, so you'll have time to prepare for this change. To prepare for this change make sure your client-server and browser-server combinations, including any clients your users use to access apps published through Application Proxy, are updated to use the TLS 1.2 protocol to maintain the connection to the Application Proxy service. For more information, see [Add an on-premises application for remote access through Application Proxy in Azure Active Directory](../manage-apps/application-proxy-add-on-premises-application.md#prerequisites).
+Deprecation of TLS 1.0 and TLS 1.1 happens on August 31, 2019, but we'll provide additional advanced notice, so you'll have time to prepare for this change. To prepare for this change make sure your client-server and browser-server combinations, including any clients your users use to access apps published through Application Proxy, are updated to use the TLS 1.2 protocol to maintain the connection to the Application Proxy service. For more information, see [Add an on-premises application for remote access through Application Proxy in Azure Active Directory](../app-proxy/application-proxy-add-on-premises-application.md#prerequisites).
There's a new setting called, **HTTP-Only Cookies** in your Application Proxy ap
This setting isn't compatible with apps using ActiveX controls, such as Remote Desktop. If you're in this situation, we recommend that you turn off this setting.
-For more information about the HTTP-Only Cookies setting, see [Publish applications using Azure AD Application Proxy](../manage-apps/application-proxy-add-on-premises-application.md).
+For more information about the HTTP-Only Cookies setting, see [Publish applications using Azure AD Application Proxy](../app-proxy/application-proxy-add-on-premises-application.md).
active-directory Whats New https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/fundamentals/whats-new.md
Currently, this user action only allows you to enable MFA as a control when user
**Service category:** App Proxy **Product capability:** Access Control
-With this new capability, connector groups can be assigned to the closest regional Application Proxy service an application is hosted in. This can improve app performance in scenarios where apps are hosted in regions other than the home tenantΓÇÖs region. [Learn more](../manage-apps/application-proxy-network-topology.md#optimize-connector-groups-to-use-closest-application-proxy-cloud-service-preview).
+With this new capability, connector groups can be assigned to the closest regional Application Proxy service an application is hosted in. This can improve app performance in scenarios where apps are hosted in regions other than the home tenantΓÇÖs region. [Learn more](../app-proxy/application-proxy-network-topology.md#optimize-connector-groups-to-use-closest-application-proxy-cloud-service-preview).
active-directory How To Connect Fed Group Claims https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/hybrid/how-to-connect-fed-group-claims.md
Azure Active Directory can provide a users group membership information in token
> [!IMPORTANT] > There are a number of caveats to note for this functionality: >
->- Support for use of sAMAccountName and security identifier (SID) attributes synced from on-premises is designed to enable moving existing applications from AD FS and other identity providers. Groups managed in Azure AD do not contain the attributes necessary to emit these claims.
->- In larger organizations the number of groups a user is a member of may exceed the limit that Azure Active Directory will add to a token. 150 groups for a SAML token, and 200 for a JWT. This can lead to unpredictable results. If your users have large numbers of group memberships, we recommend using the option to restrict the groups emitted in claims to the relevant groups for the application.
->- For new application development, or in cases where the application can be configured for it, and where nested group support isn't required, we recommend that in-app authorization is based on application roles rather than groups. This limits the amount of information that needs to go into the token, is more secure, and separates user assignment from app configuration.
+> - Support for use of sAMAccountName and security identifier (SID) attributes synced from on-premises is designed to enable moving existing applications from AD FS and other identity providers. Groups managed in Azure AD do not contain the attributes necessary to emit these claims.
+> - In larger organizations the number of groups a user is a member of may exceed the limit that Azure Active Directory will add to a token. 150 groups for a SAML token, and 200 for a JWT. This can lead to unpredictable results. If your users have large numbers of group memberships, we recommend using the option to restrict the groups emitted in claims to the relevant groups for the application.
+> - For new application development, or in cases where the application can be configured for it, and where nested group support isn't required, we recommend that in-app authorization is based on application roles rather than groups. This limits the amount of information that needs to go into the token, is more secure, and separates user assignment from app configuration.
## Group claims for applications migrating from AD FS and other identity providers
Applications can call the MS Graph groups endpoint to obtain group information f
However, if an existing application expects to consume group information via claims, Azure Active Directory can be configured with a number of different claims formats. Consider the following options: - When using group membership for in-application authorization purposes it is preferable to use the Group ObjectID. The Group ObjectID is immutable and unique in Azure Active Directory and available for all groups.-- If using the on-premises group sAMAccountName for authorization, use domain qualified names; thereΓÇÖs less chance of names clashing. sAMAccountName may be unique within an Active Directory domain, but if more than one Active Directory domain is synchronized with an Azure Active Directory tenant there is a possibility for more than one group to have the same name.
+- If using the on-premises group sAMAccountName for authorization, use domain qualified names; there's less chance of names clashing. sAMAccountName may be unique within an Active Directory domain, but if more than one Active Directory domain is synchronized with an Azure Active Directory tenant there is a possibility for more than one group to have the same name.
- Consider using [Application Roles](../../active-directory/develop/howto-add-app-roles-in-azure-ad-apps.md) to provide a layer of indirection between the group membership and the application. The application then makes internal authorization decisions based on role claims in the token. - If the application is configured to get group attributes that are synced from Active Directory and a Group doesn't contain those attributes, it won't be included in the claims. - Group claims in tokens include nested groups except when using the option to restrict the group claims to groups assigned to the application. If a user is a member of GroupB and GroupB is a member of GroupA, then the group claims for the user will contain both GroupA and GroupB. When an organization's users have large numbers of group memberships, the number of groups listed in the token can grow the token size. Azure Active Directory limits the number of groups it will emit in a token to 150 for SAML assertions, and 200 for JWT. If a user is a member of a larger number of groups, the groups are omitted and a link to the Graph endpoint to obtain group information is included instead.
There are two steps to configuring Azure Active Directory to emit group names fo
Before Azure Active Directory can emit the group names or on premises group SID in group or role claims, the required attributes need to be synchronized from Active Directory. You must be running Azure AD Connect version 1.2.70 or later. Earlier versions of Azure AD Connect than 1.2.70 will synchronize the group objects from Active Directory, but will not include the required group name attributes. Upgrade to the current version. 2. **Configure the application registration in Azure Active Directory to include group claims in tokens**
-Group claims can be configured in the Enterprise Applications section of the portal, or using the Application Manifest in the Application Registrations section. To configure group claims in the application manifest see ΓÇ£Configuring the Azure Active Directory Application Registration for group attributesΓÇ¥ below.
+Group claims can be configured in the Enterprise Applications section of the portal, or using the Application Manifest in the Application Registrations section. To configure group claims in the application manifest see "Configuring the Azure Active Directory Application Registration for group attributes" below.
## Add group claims to tokens for SAML applications using SSO configuration To configure Group Claims for a Gallery or Non-Gallery SAML application, open **Enterprise Applications**, click on the application in the list, select **Single Sign On configuration**, and then select **User Attributes & Claims**.
-Click on **Add a group claim**
+Click on **Add a group claim**
![Screenshot that shows the "User Attributes & Claims" page with "Add a group claim" selected.](media/how-to-connect-fed-group-claims/group-claims-ui-1.png)
To emit only groups assigned to the application, select **Groups Assigned to the
Groups assigned to the application will be included in the token. Other groups the user is a member of will be omitted. With this option nested groups are not included and the user must be a direct member of the group assigned to the application.
-To change the groups assigned to the application, select the application from the **Enterprise Applications** list and then click **Users and Groups** from the applicationΓÇÖs left-hand navigation menu.
+To change the groups assigned to the application, select the application from the **Enterprise Applications** list and then click **Users and Groups** from the application's left-hand navigation menu.
See the document [Assign a user or group to an enterprise app](../../active-directory/manage-apps/assign-user-or-group-access-portal.md) for details of managing group assignment to applications.
Valid values are:
| **name:** | Must be "groups" | | **source:** | Not used. Omit or specify null | | **essential:** | Not used. Omit or specify false |
- | **additionalProperties:** | List of additional properties. Valid options are "sam_account_name", ΓÇ£dns_domain_and_sam_account_nameΓÇ¥, ΓÇ£netbios_domain_and_sam_account_nameΓÇ¥, "emit_as_roles" |
+ | **additionalProperties:** | List of additional properties. Valid options are "sam_account_name", "dns_domain_and_sam_account_name", "netbios_domain_and_sam_account_name", "emit_as_roles" |
- In additionalProperties only one of "sam_account_name", ΓÇ£dns_domain_and_sam_account_nameΓÇ¥, ΓÇ£netbios_domain_and_sam_account_nameΓÇ¥ are required. If more than one is present, the first is used and any others ignored.
+ In additionalProperties only one of "sam_account_name", "dns_domain_and_sam_account_name", "netbios_domain_and_sam_account_name" are required. If more than one is present, the first is used and any others ignored.
- Some applications require group information about the user in the role claim. To change the claim type to from a group claim to a role claim, add ΓÇ£emit_as_rolesΓÇ¥ to additional properties. The group values will be emitted in the role claim.
+ Some applications require group information about the user in the role claim. To change the claim type to from a group claim to a role claim, add "emit_as_roles" to additional properties. The group values will be emitted in the role claim.
> [!NOTE] > If "emit_as_roles" is used any Application Roles configured that the user is assigned will not appear in the role claim
Emit groups as group names in OAuth access tokens in dnsDomainName\SAMAccountNam
"additionalProperties": ["dns_domain_and_sam_account_name"] }] }
- ```
+```
To emit group names to be returned in netbiosDomain\samAccountName format as the roles claim in SAML and OIDC ID Tokens:
To emit group names to be returned in netbiosDomain\samAccountName format as the
"name": "groups", "additionalProperties": ["netbios_name_and_sam_account_name", "emit_as_roles"] }]
- }
- ```
+}
+```
## Next steps
active-directory How To Connect Group Writeback https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/hybrid/how-to-connect-group-writeback.md
- # Azure AD Connect group writeback Groups writeback enables customers to leverage cloud groups for their hybrid needs. If you use the Microsoft 365 Groups feature, then you can have these groups represented in your on-premises Active Directory. This option is **only** available if you have Exchange present in your on-premises Active Directory. ## Pre-requisites+ The following pre-requisites must be met in order to enable group writeback. - Azure Active Directory Premium licenses for your tenant. - A configured hybrid deployment between your Exchange on-premises organization and Microsoft 365 and verified it's functioning correctly. - Installed a supported version of Exchange on-premises-- Configured single sign-on using Azure Active Directory Connect
+- Configured single sign-on using Azure Active Directory Connect
## Enable group writeback+ To enable group writeback, use the following steps: 1. Open the Azure AD Connect wizard, select **Configure** and then click **Next**.
To enable group writeback, use the following steps:
8. When the wizard is complete, click **Exit** on the Configuration complete page. 9. Open the Windows PowerShell as an Administrator on the Azure Active Directory Connect server, and run the following commands.
-```Powershell
+```powershell
$AzureADConnectSWritebackAccountDN = <MSOL_ account DN> Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1"
Set-ADSyncUnifiedGroupWritebackPermissions -ADConnectorAccountDN $AzureADConnect
For additional information on configuring the Microsoft 365 groups see [Configure Microsoft 365 Groups with on-premises Exchange hybrid](/exchange/hybrid-deployment/set-up-microsoft-365-groups#enable-group-writeback-in-azure-ad-connect). ## Disabling group writeback
-To disable Group Writeback, use the following steps:
+To disable Group Writeback, use the following steps:
1. Launch the Azure Active Directory Connect wizard and navigate to the Additional Tasks page. Select the **Customize synchronization options** task and click **next**. 2. On the **Optional Features** page, uncheck group writeback. You will receive a warning letting you know that groups will be deleted. Click **Yes**.
- >[!IMPORTANT]
- > Disabling Group Writeback will cause any groups that were previously created by this feature to be deleted from your local Active Directory on the next synchronization cycle.
+ > [!IMPORTANT]
+ > Disabling Group Writeback will cause any groups that were previously created by this feature to be deleted from your local Active Directory on the next synchronization cycle.
![Uncheck box](media/how-to-connect-group-writeback/group2.png)
-
+ 3. Click **Next**. 4. Click **Configure**.
- >[!NOTE]
+ > [!NOTE]
> Disabling Group Writeback will set the Full Import and Full Synchronization flags to 'true' on the Azure Active Directory Connector, causing the rule changes to propagate through on the next synchronization cycle, deleting the groups that were previously written back to your Active Directory. ## Next steps+ Learn more about [Integrating your on-premises identities with Azure Active Directory](whatis-hybrid-identity.md).
active-directory How To Connect Selective Password Hash Synchronization https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/hybrid/how-to-connect-selective-password-hash-synchronization.md
[Password hash synchronization](whatis-phs.md) is one of the sign-in methods used to accomplish hybrid identity. Azure AD Connect synchronizes a hash, of the hash, of a user's password from an on-premises Active Directory instance to a cloud-based Azure AD instance. By default, once it has been setup, password hash synchronization will occur on all of the users you are synchronizing.
-If youΓÇÖd like to have a subset of users excluded from synchronizing their password hash to Azure AD, you can configure selective password hash synchronization using the guided steps provided in this article.
+If you'd like to have a subset of users excluded from synchronizing their password hash to Azure AD, you can configure selective password hash synchronization using the guided steps provided in this article.
->[!Important]
-> Microsoft doesn't support modifying or operating Azure AD Connect sync outside of the configurations or actions that are formally documented. Any of these configurations or actions might result in an inconsistent or unsupported state of Azure AD Connect sync. As a result, Microsoft cannot guarantee that we will be able to provide efficient technical support for such deployments.
+> [!IMPORTANT]
+> Microsoft doesn't support modifying or operating Azure AD Connect sync outside of the configurations or actions that are formally documented. Any of these configurations or actions might result in an inconsistent or unsupported state of Azure AD Connect sync. As a result, Microsoft cannot guarantee that we will be able to provide efficient technical support for such deployments.
+## Consider your implementation
-## Consider your implementation
To reduce the configuration administrative effort, you should first consider the number of user objects you wish to exclude from password hash synchronization. Verify which of the scenarios below, which are mutually exclusive, aligns with your requirements to select the right configuration option for you. - If the number of users to **exclude** is **smaller** than the number of users to **include**, follow the steps in this [section](#excluded-users-is-smaller-than-included-users). - If the number of users to **exclude** is **greater** than the number of users to **include**, follow the steps in this [section](#excluded-users-is-larger-than-included-users).
-> [!Important]
+> [!IMPORTANT]
> With either configuration option chosen, a required initial sync (Full Sync) to apply the changes, will be performed automatically over the next sync cycle.
-> [!Important]
-> Configuring selective password hash synchronization directly influences password writeback. Password changes or password resets that are initiated in Azure Active Directory write back to on-premises Active Directory only if the user is in scope for password hash synchronization.
+> [!IMPORTANT]
+> Configuring selective password hash synchronization directly influences password writeback. Password changes or password resets that are initiated in Azure Active Directory write back to on-premises Active Directory only if the user is in scope for password hash synchronization.
### The adminDescription attribute+ Both scenarios rely on setting the adminDescription attribute of users to a specific value. This allows the rules to be applied and is what makes selective PHS work. |Scenario|adminDescription value|
This attribute can be set either:
- using the Active Directory Users and Computers UI - using `Set-ADUser` PowerShell cmdlet. For more information see [Set-ADUser](/powershell/module/activedirectory/set-aduser).
-
-- ### Disable the synchronization scheduler:
-Before you start either scenario, you must disable the synchronization scheduler while making changes to the sync rules.
- 1. Start windows PowerShell enter.
- ```Set-ADSyncScheduler -SyncCycleEnabled $false```
-
-2. Confirm the scheduler is disabled by running the following cmdlet:
-
- ```Get-ADSyncScheduler```
+Before you start either scenario, you must disable the synchronization scheduler while making changes to the sync rules.
+ 1. Start windows PowerShell enter.
-For more information on the scheduler see [Azure AD Connect sync scheduler](how-to-connect-sync-feature-scheduler.md).
+ `set-adsyncscheduler-synccycleenabled$false`
+2. Confirm the scheduler is disabled by running the following cmdlet:
+ `get-adsyncscheduler`
+For more information on the scheduler see [Azure AD Connect sync scheduler](how-to-connect-sync-feature-scheduler.md).
## Excluded users is smaller than included users+ The following section describes how to enable selective password hash synchronization when the number of users to **exclude** is **smaller** than the number of users to **include**.
->[!Important]
+> [!IMPORTANT]
> Before you proceed ensure the synchronization scheduler is disabled as outlined above. -- Create an editable copy of the **In from AD ΓÇô User AccountEnabled** with the option to **enable password hash sync un-selected** and define its scoping filter -- Create another editable copy of the default **In from AD ΓÇô User AccountEnabled** with the option to **enable password hash sync selected** and define its scoping filter -- Re-enable the synchronization scheduler -- Set the attribute value, in active directory, that was defined as scoping attribute on the users you want to allow in password hash synchronization.
+- Create an editable copy of the **In from AD ΓÇô User AccountEnabled** with the option to **enable password hash sync un-selected** and define its scoping filter
+- Create another editable copy of the default **In from AD ΓÇô User AccountEnabled** with the option to **enable password hash sync selected** and define its scoping filter
+- Re-enable the synchronization scheduler
+- Set the attribute value, in active directory, that was defined as scoping attribute on the users you want to allow in password hash synchronization.
->[!Important]
->The steps provided to configure selective password hash synchronization will only affect user objects that have
+> [!IMPORTANT]
+> The steps provided to configure selective password hash synchronization will only affect user objects that have
the attribute **adminDescription** populated in Active Directory with the value of **PHSFiltered**.
->If this attribute is not populated or the value is something other than **PHSFiltered** then these rules will not be applied to the user objects.
-
+> If this attribute is not populated or the value is something other than **PHSFiltered** then these rules will not be applied to the user objects.
### Configure the necessary synchronization rules:
- 1. Start the Synchronization Rules Editor and set the filters **Password Sync** to **On** and **Rule Type** to **Standard**.
+ 1. Start the Synchronization Rules Editor and set the filters **Password Sync** to **On** and **Rule Type** to **Standard**.
![Start sync rules editor](media/how-to-connect-selective-password-hash-synchronization/exclude-1.png)
- 2. Select the rule **In from AD ΓÇô User AccountEnabled** for the Active Directory forest Connector you want to configure selective password had hash synchronization on and click **Edit**. Select **Yes** in the next dialog box to create an editable copy of the original rule.
+ 2. Select the rule **In from AD ΓÇô User AccountEnabled** for the Active Directory forest Connector you want to configure selective password had hash synchronization on and click **Edit**. Select **Yes** in the next dialog box to create an editable copy of the original rule.
![Select rule](media/how-to-connect-selective-password-hash-synchronization/exclude-2.png)
- 3. The first rule will disable password hash sync.
+ 3. The first rule will disable password hash sync.
Provide the following name to the new custom rule: **In from AD - User AccountEnabled - Filter Users from PHS**. Change the precedence value to a number lower than 100 (for example **90** or whichever is the lowest value available in your environment). Make sure the checkboxes **Enable Password Sync** and **Disabled** are unchecked. Click **Next**. ![Edit inbound](media/how-to-connect-selective-password-hash-synchronization/exclude-3.png)
- 4. In **Scoping filter**, click **Add clause**.
+ 4. In **Scoping filter**, click **Add clause**.
Select **adminDescription** in the attribute column, **EQUAL** in the Operator column and enter **PHSFiltered** as the value. ![Scoping filter](media/how-to-connect-selective-password-hash-synchronization/exclude-4.png) 5. No further changes are required. **Join rules** and **Transformations** should be left with the default copied settings so you can click **Save** now. Click **OK** in the warning dialog box informing a full synchronization will be run on the next synchronization cycle of the connector. ![Save rule](media/how-to-connect-selective-password-hash-synchronization/exclude-5.png)
- 6. Next, create another custom rule with password hash synchronization enabled. Select again the default rule **In from AD ΓÇô User AccountEnabled** for the Active Directory forest you want to configure selective password had synchronization on and click **Edit**. Select **yes** in the next dialog box to create an editable copy of the original rule.
+ 6. Next, create another custom rule with password hash synchronization enabled. Select again the default rule **In from AD ΓÇô User AccountEnabled** for the Active Directory forest you want to configure selective password had synchronization on and click **Edit**. Select **yes** in the next dialog box to create an editable copy of the original rule.
![Custom rule](media/how-to-connect-selective-password-hash-synchronization/exclude-6.png) 7. Provide the following name to the new custom rule: **In from AD - User AccountEnabled - Users included for PHS**.
- Change the precedence value to a number lower than the rule previously created (In this example thatΓÇÖll be **89**).
+ Change the precedence value to a number lower than the rule previously created (In this example that'll be **89**).
Make sure the checkbox **Enable Password Sync** is checked and the **Disabled** checkbox is unchecked. Click **Next**. ![Edit new rule](media/how-to-connect-selective-password-hash-synchronization/exclude-7.png)
the attribute **adminDescription** populated in Active Directory with the value
Click **OK** in the warning dialog box informing a full synchronization will be run on the next synchronization cycle of the connector. ![Join rules](media/how-to-connect-selective-password-hash-synchronization/exclude-9.png) 10. Confirm the rules creation. Remove the filters **Password Sync** **On** and **Rule Type** **Standard**. And you should see both new rules you just created.
- ![Confirm rules](media/how-to-connect-selective-password-hash-synchronization/exclude-10.png)
+ ![Confirm rules](media/how-to-connect-selective-password-hash-synchronization/exclude-10.png)
+### Re-enable synchronization scheduler:
-### Re-enable synchronization scheduler:
Once you completed the steps to configure the necessary synchronization rules, re-enable the synchronization scheduler with the following steps:
- 1. In Windows PowerShell run:
+ 1. In Windows PowerShell run:
- ```Set-ADSyncScheduler -SyncCycleEnabled $true```
- 2. Then confirm it has been successfully enabled by running:
+ `set-adsyncscheduler-synccycleenabled$true`
- ```Get-ADSyncScheduler```
+ 2. Then confirm it has been successfully enabled by running:
+
+ `get-adsyncscheduler`
For more information on the scheduler see [Azure AD Connect sync scheduler](how-to-connect-sync-feature-scheduler.md). ### Edit users **adminDescription** attribute:+ Once all configurations are complete, you need edit the attribute **adminDescription** for all users you wish to **exclude** from password hash synchronization in Active Directory and add the string used in the scoping filter: **PHSFiltered**.
-
+ ![Edit attribute](media/how-to-connect-selective-password-hash-synchronization/exclude-11.png) You can also use the following PowerShell command to edit a user's **adminDescription** attribute:
-```Set-ADUser myuser -Replace @{adminDescription="PHSFiltered"}```
+`set-adusermyuser-replace@{adminDescription="PHSFiltered"}`
## Excluded users is larger than included users+ The following section describes how to enable selective password hash synchronization when the number of users to **exclude** is **larger** than the number of users to **include**.
->[!Important]
+> [!IMPORTANT]
> Before you proceed ensure the synchronization scheduler is disabled as outlined above. The following is a summary of the actions that will be taken in the steps below: -- Create an editable copy of the **In from AD ΓÇô User AccountEnabled** with the option to **enable password hash sync un-selected** and define its scoping filter -- Create another editable copy of the default **In from AD ΓÇô User AccountEnabled** with the option to **enable password hash sync selected** and define its scoping filter -- Re-enable the synchronization scheduler -- Set the attribute value, in active directory, that was defined as scoping attribute on the users you want to allow in password hash synchronization.
+- Create an editable copy of the **In from AD ΓÇô User AccountEnabled** with the option to **enable password hash sync un-selected** and define its scoping filter
+- Create another editable copy of the default **In from AD ΓÇô User AccountEnabled** with the option to **enable password hash sync selected** and define its scoping filter
+- Re-enable the synchronization scheduler
+- Set the attribute value, in active directory, that was defined as scoping attribute on the users you want to allow in password hash synchronization.
->[!Important]
->The steps provided to configure selective password hash synchronization will only affect user objects that have
+> [!IMPORTANT]
+> The steps provided to configure selective password hash synchronization will only affect user objects that have
the attribute **adminDescription** populated in Active Directory with the value of **PHSIncluded**.
->If this attribute is not populated or the value is something other than **PHSIncluded** then these rules will not be applied to the user objects.
-
+> If this attribute is not populated or the value is something other than **PHSIncluded** then these rules will not be applied to the user objects.
### Configure the necessary synchronization rules:
- 1. Start the synchronization Rules Editor and set the filters **Password Sync** **On** and **Rule Type** **Standard**.
+ 1. Start the synchronization Rules Editor and set the filters **Password Sync** **On** and **Rule Type** **Standard**.
![Rule type](media/how-to-connect-selective-password-hash-synchronization/include-1.png)
- 2. Select the rule **In from AD ΓÇô User AccountEnabled** for the Active Directory forest you want to configure selective password had synchronization on and click **Edit**. Select **yes** in the next dialog box to create an editable copy of the original rule.
+ 2. Select the rule **In from AD ΓÇô User AccountEnabled** for the Active Directory forest you want to configure selective password had synchronization on and click **Edit**. Select **yes** in the next dialog box to create an editable copy of the original rule.
![In from AD](media/how-to-connect-selective-password-hash-synchronization/include-2.png)
- 3. The first rule will disable password hash sync.
+ 3. The first rule will disable password hash sync.
Provide the following name to the new custom rule: **In from AD - User AccountEnabled - Filter Users from PHS**. Change the precedence value to a number lower than 100 (for example **90** or whichever is the lowest value available in your environment). Make sure the checkboxes **Enable Password Sync** and **Disabled** are unchecked. Click **Next**. ![Set precedence](media/how-to-connect-selective-password-hash-synchronization/include-3.png)
- 4. In **Scoping filter**, click **Add clause**.
+ 4. In **Scoping filter**, click **Add clause**.
Select **adminDescription** in the attribute column, **NOTEQUAL** in the Operator column and enter **PHSIncluded** as the value. ![Add clause](media/how-to-connect-selective-password-hash-synchronization/include-4.png) 5. No further changes are required. **Join rules** and **Transformations** should be left with the default copied settings so you can click **Save** now. Click **OK** in the warning dialog box informing a full synchronization will be run on the next synchronization cycle of the connector. ![Transformation](media/how-to-connect-selective-password-hash-synchronization/include-5.png)
- 6. Next, create another custom rule with password hash synchronization enabled. Select again the default rule **In from AD ΓÇô User AccountEnabled** for the Active Directory forest you want to configure selective password had synchronization on and click **Edit**. Select **yes** in the next dialog box to create an editable copy of the original rule.
+ 6. Next, create another custom rule with password hash synchronization enabled. Select again the default rule **In from AD ΓÇô User AccountEnabled** for the Active Directory forest you want to configure selective password had synchronization on and click **Edit**. Select **yes** in the next dialog box to create an editable copy of the original rule.
![User AccountEnabled](media/how-to-connect-selective-password-hash-synchronization/include-6.png)
- 7. Provide the following name to the new custom rule: **In from AD - User AccountEnabled - Users included for PHS**.
- Change the precedence value to a number lower than the rule previously created (In this example thatΓÇÖll be **89**).
+ 7. Provide the following name to the new custom rule: **In from AD - User AccountEnabled - Users included for PHS**.
+ Change the precedence value to a number lower than the rule previously created (In this example that'll be **89**).
Make sure the checkbox **Enable Password Sync** is checked and the **Disabled** checkbox is unchecked. Click **Next**. ![Enable Password Sync](media/how-to-connect-selective-password-hash-synchronization/include-7.png)
- 8. In **Scoping filter**, click **Add clause**.
+ 8. In **Scoping filter**, click **Add clause**.
Select **adminDescription** in the attribute column, **EQUAL** in the Operator column and enter **PHSIncluded** as the value. ![PHSIncluded](media/how-to-connect-selective-password-hash-synchronization/include-8.png) 9. No further changes are required. **Join rules** and **Transformations** should be left with the default copied settings so you can click **Save** now. Click **OK** in the warning dialog box informing a full synchronization will be run on the next synchronization cycle of the connector. ![Save now](media/how-to-connect-selective-password-hash-synchronization/include-9.png)
- 10. Confirm the rules creation. Remove the filters **Password Sync** **On** and **Rule Type** **Standard**. And you should see both new rules you just created.
+ 10. Confirm the rules creation. Remove the filters **Password Sync** **On** and **Rule Type** **Standard**. And you should see both new rules you just created.
![Sync on](media/how-to-connect-selective-password-hash-synchronization/include-10.png)
-### Re-enable synchronization scheduler:
+### Re-enable synchronization scheduler:
+ Once you completed the steps to configure the necessary synchronization rules, re-enable the synchronization scheduler with the following steps:
- 1. In Windows PowerShell run:
- ```Set-ADSyncScheduler -SyncCycleEnabled $true```
- 2. Then confirm it has been successfully enabled by running:
+1. In Windows PowerShell, run:
- ```Get-ADSyncScheduler```
+ `set-adsyncscheduler-synccycleenabled$true`
+
+2. Then confirm it has been successfully enabled by running:
+
+ `get-adsyncscheduler`
For more information on the scheduler see [Azure AD Connect sync scheduler](how-to-connect-sync-feature-scheduler.md). ### Edit users **adminDescription** attribute:+ Once all configurations are complete, you need edit the attribute **adminDescription** for all users you wish to **include** for password hash synchronization in Active Directory and add the string used in the scoping filter: **PHSIncluded**. ![Edit attributes](media/how-to-connect-selective-password-hash-synchronization/include-11.png)
-
- You can also use the following PowerShell command to edit a user's **adminDescription** attribute:
- ```Set-ADUser myuser -Replace @{adminDescription="PHSIncluded"}```
+You can also use the following PowerShell command to edit a user's **adminDescription** attribute:
+
+`Set-ADUser myuser -Replace @{adminDescription="PHSIncluded"}`
## Next Steps+ - [What is password hash synchronization?](whatis-phs.md) - [How password hash sync works](how-to-connect-password-hash-synchronization.md)
active-directory Tshoot Connect Pass Through Authentication https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/hybrid/tshoot-connect-pass-through-authentication.md
This article helps you find troubleshooting information about common issues regarding Azure AD Pass-through Authentication.
->[!IMPORTANT]
->If you are facing user sign-in issues with Pass-through Authentication, don't disable the feature or uninstall Pass-through Authentication Agents without having a cloud-only Global Administrator account to fall back on. Learn about [adding a cloud-only Global Administrator account](../fundamentals/add-users-azure-active-directory.md). Doing this step is critical and ensures that you don't get locked out of your tenant.
+> [!IMPORTANT]
+> If you are facing user sign-in issues with Pass-through Authentication, don't disable the feature or uninstall Pass-through Authentication Agents without having a cloud-only Global Administrator account to fall back on. Learn about [adding a cloud-only Global Administrator account](../fundamentals/add-users-azure-active-directory.md). Doing this step is critical and ensures that you don't get locked out of your tenant.
## General issues
Ensure that the Pass-through Authentication feature is still **Enabled** on your
### User-facing sign-in error messages
-If the user is unable to sign into using Pass-through Authentication, they may see one of the following user-facing errors on the Azure AD sign-in screen:
+If the user is unable to sign into using Pass-through Authentication, they may see one of the following user-facing errors on the Azure AD sign-in screen:
|Error|Description|Resolution | | |
-|AADSTS80001|Unable to connect to Active Directory|Ensure that agent servers are members of the same AD forest as the users whose passwords need to be validated and they are able to connect to Active Directory.
+|AADSTS80001|Unable to connect to Active Directory|Ensure that agent servers are members of the same AD forest as the users whose passwords need to be validated and they are able to connect to Active Directory.
|AADSTS8002|A timeout occurred connecting to Active Directory|Check to ensure that Active Directory is available and is responding to requests from the agents. |AADSTS80004|The username passed to the agent was not valid|Ensure the user is attempting to sign in with the right username. |AADSTS80005|Validation encountered unpredictable WebException|A transient error. Retry the request. If it continues to fail, contact Microsoft support. |AADSTS80007|An error occurred communicating with Active Directory|Check the agent logs for more information and verify that Active Directory is operating as expected.
-### Users get invalid username/password error
+### Users get invalid username/password error
-This can happen when a userΓÇÖs on-premises UserPrincipalName (UPN) is different than the user's cloud UPN.
+This can happen when a user's on-premises UserPrincipalName (UPN) is different than the user's cloud UPN.
To confirm that this is the issue, first test that the Pass-through Authentication agent is working correctly:
+1. Create a test account.
-1. Create a test account.
2. Import the PowerShell module on the agent machine:
- ```powershell
- Import-Module "C:\Program Files\Microsoft Azure AD Connect Authentication Agent\Modules\PassthroughAuthPSModule\PassthroughAuthPSModule.psd1"
- ```
-3. Run the Invoke PowerShell command:
+ ```powershell
+ Import-Module "C:\Program Files\Microsoft Azure AD Connect Authentication Agent\Modules\PassthroughAuthPSModule\PassthroughAuthPSModule.psd1"
+ ```
+
+3. Run the Invoke PowerShell command:
+
+ ```powershell
+ Invoke-PassthroughAuthOnPremLogonTroubleshooter
+ ```
- ```powershell
- Invoke-PassthroughAuthOnPremLogonTroubleshooter
- ```
4. When you are prompted to enter credentials, enter the same username and password that are used to sign in to (https://login.microsoftonline.com). If you get the same username/password error, this means that the Pass-through Authentication agent is working correctly and the issue may be that the on-premises UPN is non-routable. To learn more, see [Configuring Alternate Login ID](/windows-server/identity/ad-fs/operations/configuring-alternate-login-id).
Navigate to **Azure Active Directory** -> **Sign-ins** on the [Azure Active Dire
| 80004 | Incorrect User Principal Name (UPN) used in sign-in request. | Ask the user to sign in with the correct username. | 80005 | Authentication Agent: Error occurred. | Transient error. Try again later. | 80007 | Authentication Agent unable to connect to Active Directory. | Check if your Active Directory is reachable from the Authentication Agent.
-| 80010 | Authentication Agent unable to decrypt password. | If the problem is consistently reproducible, install and register a new Authentication Agent. And uninstall the current one.
+| 80010 | Authentication Agent unable to decrypt password. | If the problem is consistently reproducible, install and register a new Authentication Agent. And uninstall the current one.
| 80011 | Authentication Agent unable to retrieve decryption key. | If the problem is consistently reproducible, install and register a new Authentication Agent. And uninstall the current one. | 80014 | Validation request responded after maximum elapsed time exceeded. | Authentication agent timed out. Open a support ticket with the error code, correlation ID, and timestamp to get more details on this error
->[!IMPORTANT]
->Pass-through Authentication Agents authenticate Azure AD users by validating their usernames and passwords against Active Directory by calling the [Win32 LogonUser API](/windows/win32/api/winbase/nf-winbase-logonusera). As a result, if you have set the "Logon To" setting in Active Directory to limit workstation logon access, you will have to add servers hosting Pass-through Authentication Agents to the list of "Logon To" servers as well. Failing to do this will block your users from signing into Azure AD.
+> [!IMPORTANT]
+> Pass-through Authentication Agents authenticate Azure AD users by validating their usernames and passwords against Active Directory by calling the [Win32 LogonUser API](/windows/win32/api/winbase/nf-winbase-logonusera). As a result, if you have set the "Logon To" setting in Active Directory to limit workstation logon access, you will have to add servers hosting Pass-through Authentication Agents to the list of "Logon To" servers as well. Failing to do this will block your users from signing into Azure AD.
## Authentication Agent installation issues
For errors related to the Authentication Agent, open up the Event Viewer applica
For detailed analytics, enable the "Session" log (right-click inside the Event Viewer application to find this option). Don't run the Authentication Agent with this log enabled during normal operations; use only for troubleshooting. The log contents are only visible after the log is disabled again. -- ### Detailed trace logs To troubleshoot user sign-in failures, look for trace logs at **%ProgramData%\Microsoft\Azure AD Connect Authentication Agent\Trace\\**. These logs include reasons why a specific user sign-in failed using the Pass-through Authentication feature. These errors are also mapped to the sign-in failure reasons shown in the preceding sign-in failure reasons table. Following is an example log entry:
Another way to monitor Authentication Agents is to track specific Performance Mo
![Pass-through Authentication Performance Monitor counters](./media/tshoot-connect-pass-through-authentication/pta12.png)
->[!IMPORTANT]
->Pass-through Authentication provides high availability using multiple Authentication Agents, and _not_ load balancing. Depending on your configuration, _not_ all your Authentication Agents receive roughly _equal_ number of requests. It is possible that a specific Authentication Agent receives no traffic at all.
+> [!IMPORTANT]
+> Pass-through Authentication provides high availability using multiple Authentication Agents, and _not_ load balancing. Depending on your configuration, _not_ all your Authentication Agents receive roughly _equal_ number of requests. It is possible that a specific Authentication Agent receives no traffic at all.
active-directory Application Management Fundamentals https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/manage-apps/application-management-fundamentals.md
This article contains recommendations and best practices for managing applicatio
| Synchronize users before deploying Application Proxy | Before deploying application proxy, synchronize user identities from an on-premises directory or create them directly in Azure AD. Identity synchronization allows Azure AD to pre-authenticate users before granting them access to App Proxy published applications. It also provides the necessary user identifier information to perform single sign-on (SSO). (See [Application Proxy planning](application-proxy-deployment-plan.md).) | | Follow our tips for high availability and load balancing | To learn how traffic flows among users, Application Proxy connectors, and back-end app servers, and to get tips for optimizing performance and load balancing, see [High availability and load balancing of your Application Proxy connectors and applications](application-proxy-high-availability-load-balancing.md). | | Use multiple connectors | Use two or more Application Proxy connectors for greater resiliency, availability, and scale (see [Application Proxy connectors](application-proxy-connectors.md)). Create connector groups and ensure each connector group has at least two connectors (three connectors is optimal). |
-| Locate connector servers close to application servers, and make sure they're in the same domain | To optimize performance, physically locate the connector server close to the application servers (see [Network topology considerations](application-proxy-network-topology.md)). Also, the connector server and web applications servers should belong to the same Active Directory domain, or they should span trusting domains. This configuration is required for SSO with Integrated Windows Authentication (IWA) and Kerberos Constrained Delegation (KCD). If the servers are in different domains, you'll need to use resource-based delegation for SSO (see [KCD for single sign-on with Application Proxy](application-proxy-configure-single-sign-on-with-kcd.md)). |
+| Locate connector servers close to application servers, and make sure they're in the same domain | To optimize performance, physically locate the connector server close to the application servers (see [Network topology considerations](../app-proxy/application-proxy-network-topology.md)). Also, the connector server and web applications servers should belong to the same Active Directory domain, or they should span trusting domains. This configuration is required for SSO with Integrated Windows Authentication (IWA) and Kerberos Constrained Delegation (KCD). If the servers are in different domains, you'll need to use resource-based delegation for SSO (see [KCD for single sign-on with Application Proxy](../app-proxy/application-proxy-configure-single-sign-on-with-kcd.md)). |
| Enable auto-updates for connectors | Enable auto-updates for your connectors for the latest features and bug fixes. Microsoft provides direct support for the latest connector version and one version before. (See [Application Proxy release version history](application-proxy-release-version-history.md).) | | Bypass your on-premises proxy | For easier maintenance, configure the connector to bypass your on-premises proxy so it directly connects to the Azure services. (See [Application Proxy connectors and proxy servers](application-proxy-configure-connectors-with-proxy-servers.md).) | | Use Azure AD Application Proxy over Web Application Proxy | Use Azure AD Application Proxy for most on-premises scenarios. Web Application Proxy is only preferred in scenarios that require a proxy server for AD FS and where you can't use custom domains in Azure Active Directory. (See [Application Proxy migration](application-proxy-migration.md).) |
active-directory Application Proxy Integrate With Microsoft Cloud Application Security https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/manage-apps/application-proxy-integrate-with-microsoft-cloud-application-security.md
On-premises application:
Configure Application Proxy: -- Configure Azure AD to use Application Proxy, including preparing your environment and installing the Application Proxy connector. For a tutorial, see [Add an on-premises applications for remote access through Application Proxy in Azure AD](application-proxy-add-on-premises-application.md).
+- Configure Azure AD to use Application Proxy, including preparing your environment and installing the Application Proxy connector. For a tutorial, see [Add an on-premises applications for remote access through Application Proxy in Azure AD](../app-proxy/application-proxy-add-on-premises-application.md).
## Add on-premises application to Azure AD
-Add an on-premises application to Azure AD. For a quickstart, see [Add an on-premises app to Azure AD](application-proxy-add-on-premises-application.md#add-an-on-premises-app-to-azure-ad). When adding the application, be sure to set the following two settings in the **Add your on-premises application** blade:
+Add an on-premises application to Azure AD. For a quickstart, see [Add an on-premises app to Azure AD](../app-proxy/application-proxy-add-on-premises-application.md#add-an-on-premises-app-to-azure-ad). When adding the application, be sure to set the following two settings in the **Add your on-premises application** blade:
- **Pre Authentication**: Enter **Azure Active Directory**. - **Translate URLs in Application Body**: Choose **Yes**.
Those two settings are required for the application to work with MCAS.
## Test the on-premises application
-After adding your application to Azure AD, use the steps in [Test the application](application-proxy-add-on-premises-application.md#test-the-application) to add a user for testing, and test the sign-on.
+After adding your application to Azure AD, use the steps in [Test the application](../app-proxy/application-proxy-add-on-premises-application.md#test-the-application) to add a user for testing, and test the sign-on.
## Deploy Conditional Access App Control
active-directory Application Proxy Integrate With Power Bi https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/manage-apps/application-proxy-integrate-with-power-bi.md
This article discusses how to use Azure AD Application Proxy to enable the Power
## Prerequisites
-This article assumes you've already deployed Report Services and [enabled Application Proxy](application-proxy-add-on-premises-application.md).
+This article assumes you've already deployed Report Services and [enabled Application Proxy](../app-proxy/application-proxy-add-on-premises-application.md).
-- Enabling Application Proxy requires installing a connector on a Windows server and completing the [prerequisites](application-proxy-add-on-premises-application.md#prepare-your-on-premises-environment) so that the connector can communicate with Azure AD services.
+- Enabling Application Proxy requires installing a connector on a Windows server and completing the [prerequisites](../app-proxy/application-proxy-add-on-premises-application.md#prepare-your-on-premises-environment) so that the connector can communicate with Azure AD services.
- When publishing Power BI, we recommended you use the same internal and external domains. To learn more about custom domains, see [Working with custom domains in Application Proxy](./application-proxy-configure-custom-domain.md). - This integration is available for the **Power BI Mobile iOS and Android** application.
For more information, see [Kerberos Constrained Delegation for single sign-on to
Now you're ready to configure Azure AD Application Proxy.
-1. Publish Report Services through Application Proxy with the following settings. For step-by-step instructions on how to publish an application through Application Proxy, see [Publishing applications using Azure AD Application Proxy](application-proxy-add-on-premises-application.md#add-an-on-premises-app-to-azure-ad).
+1. Publish Report Services through Application Proxy with the following settings. For step-by-step instructions on how to publish an application through Application Proxy, see [Publishing applications using Azure AD Application Proxy](../app-proxy/application-proxy-add-on-premises-application.md#add-an-on-premises-app-to-azure-ad).
- **Internal URL**: Enter the URL to the Report Server that the connector can reach in the corporate network. Make sure this URL is reachable from the server the connector is installed on. A best practice is using a top-level domain such as `https://servername/` to avoid issues with subpaths published through Application Proxy. For example, use `https://servername/` and not `https://servername/reports/` or `https://servername/reportserver/`. > [!NOTE] > We recommend using a secure HTTPS connection to the Report Server. See [Configure SSL connections on a native mode report server](/sql/reporting-services/security/configure-ssl-connections-on-a-native-mode-report-server) for information how to.
active-directory Application Proxy Integrate With Tableau https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/manage-apps/application-proxy-integrate-with-tableau.md
The scenario in this article assumes that you have:
- [Tableau](https://onlinehelp.tableau.com/current/server/en-us/proxy.htm#azure) configured. -- An [Application Proxy connector](application-proxy-add-on-premises-application.md) installed.
+- An [Application Proxy connector](../app-proxy/application-proxy-add-on-premises-application.md) installed.
## Enabling Application Proxy for Tableau
To publish Tableau, you need to publish an application in the Azure Portal.
For: -- Detailed instructions of steps 1-8, see [Publish applications using Azure AD Application Proxy](application-proxy-add-on-premises-application.md).
+- Detailed instructions of steps 1-8, see [Publish applications using Azure AD Application Proxy](../app-proxy/application-proxy-add-on-premises-application.md).
- Information about how to find Tableau values for the App Proxy fields, please see the Tableau documentation. **To publish your app**:
active-directory Application Proxy Integrate With Teams https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/manage-apps/application-proxy-integrate-with-teams.md
Your users can add cloud apps to their Teams channels [using tabs](https://suppo
## Install the Application Proxy connector and publish your app
-If you haven't already, [configure Application Proxy for your tenant and install the connector](application-proxy-add-on-premises-application.md). Then, [publish your on-premises application](application-proxy-add-on-premises-application.md) for remote access. When you're publishing the app, make note of the external URL because it's used to add the app to Teams.
+If you haven't already, [configure Application Proxy for your tenant and install the connector](../app-proxy/application-proxy-add-on-premises-application.md). Then, publish your on-premises application for remote access. When you're publishing the app, make note of the external URL because it's used to add the app to Teams.
If you already have your apps published but don't remember their external URLs, look them up in the [Azure portal](https://portal.azure.com). Sign in, then navigate to **Azure Active Directory** > **Enterprise applications** > **All applications** > select your app > **Application proxy**.
active-directory Application Proxy Ping Access Publishing Guide https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/manage-apps/application-proxy-ping-access-publishing-guide.md
This article is for people to publish an application with this scenario for the
If you've enabled Application Proxy enabled and installed a connector already, you can skip this section and go to [Add your application to Azure AD with Application Proxy](#add-your-application-to-azure-ad-with-application-proxy).
-The Application Proxy connector is a Windows Server service that directs the traffic from your remote employees to your published applications. For more detailed installation instructions, see [Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory](application-proxy-add-on-premises-application.md).
+The Application Proxy connector is a Windows Server service that directs the traffic from your remote employees to your published applications. For more detailed installation instructions, see [Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory](../app-proxy/application-proxy-add-on-premises-application.md).
1. Sign in to the [Azure Active Directory portal](https://aad.portal.azure.com/) as an application administrator. The **Azure Active Directory admin center** page appears. 1. Select **Azure Active Directory** > **Application proxy** > **Download connector service**. The **Application Proxy Connector Download** page appears.
To publish your own on-premises application:
1. Fill out the required fields with information about your new application. Use the guidance below for the settings. > [!NOTE]
- > For a more detailed walkthrough of this step, see [Add an on-premises app to Azure AD](application-proxy-add-on-premises-application.md#add-an-on-premises-app-to-azure-ad).
+ > For a more detailed walkthrough of this step, see [Add an on-premises app to Azure AD](../app-proxy/application-proxy-add-on-premises-application.md#add-an-on-premises-app-to-azure-ad).
1. **Internal URL**: Normally you provide the URL that takes you to the appΓÇÖs sign-in page when youΓÇÖre on the corporate network. For this scenario, the connector needs to treat the PingAccess proxy as the front page of the application. Use this format: `https://<host name of your PingAccess server>:<port>`. The port is 3000 by default, but you can configure it in PingAccess.
active-directory Application Proxy Understand Cors Issues https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/manage-apps/application-proxy-understand-cors-issues.md
You can change your app to support CORS by adding the Access-Control-Allow-Origi
Some CORS issues can't be resolved, such as when your app redirects to *login.microsoftonline.com* to authenticate, and the access token expires. The CORS call then fails. A workaround for this scenario is to extend the lifetime of the access token, to prevent it from expiring during a userΓÇÖs session. For more information about how to do this, see [Configurable token lifetimes in Azure AD](../develop/active-directory-configurable-token-lifetimes.md). ## See also-- [Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory](application-proxy-add-on-premises-application.md)
+- [Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory](../app-proxy/application-proxy-add-on-premises-application.md)
- [Plan an Azure AD Application Proxy deployment](application-proxy-deployment-plan.md) - [Remote access to on-premises applications through Azure Active Directory Application Proxy](application-proxy.md)
active-directory Configure Authentication For Federated Users Portal https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/manage-apps/configure-authentication-for-federated-users-portal.md
The user will be taken to one of the following identity providers to be authenti
## Auto-acceleration
-Some organizations configure domains in their Azure Active Directory tenant to federate with another IdP, such as AD FS for user authentication.
+Some organizations configure domains in their Azure Active Directory tenant to federate with another IdP, such as AD FS for user authentication.
When a user signs into an application, they are first presented with an Azure AD sign-in page. After they have typed their UPN, if they are in a federated domain they are then taken to the sign-in page of the IdP serving that domain. Under certain circumstances, administrators might want to direct users to the sign-in page when they're signing in to specific applications.
-As a result users can skip the initial Azure Active Directory page. This process is referred to as ΓÇ£sign-in auto-acceleration.ΓÇ¥
+As a result users can skip the initial Azure Active Directory page. This process is referred to as "sign-in auto-acceleration."
In cases where the tenant is federated to another IdP for sign-in, auto-acceleration makes user sign-in more streamlined. You can configure auto-acceleration for individual applications.
->[!NOTE]
->If you configure an application for auto-acceleration, users can't use managed credentials (like FIDO) and guest users can't sign in. If you take a user straight to a federated IdP for authentication, there is no way to for them to get back to the Azure Active Directory sign-in page. Guest users, who might need to be directed to other tenants or an external IdP such as a Microsoft account, can't sign in to that application because they're skipping the Home Realm Discovery step.
+> [!NOTE]
+> If you configure an application for auto-acceleration, users can't use managed credentials (like FIDO) and guest users can't sign in. If you take a user straight to a federated IdP for authentication, there is no way to for them to get back to the Azure Active Directory sign-in page. Guest users, who might need to be directed to other tenants or an external IdP such as a Microsoft account, can't sign in to that application because they're skipping the Home Realm Discovery step.
There are three ways to control auto-acceleration to a federated IdP:
There are three ways to control auto-acceleration to a federated IdP:
### Domain hints
-Domain hints are directives that are included in the authentication request from an application. They can be used to accelerate the user to their federated IdP sign-in page. Or they can be used by a multi-tenant application to accelerate the user straight to the branded Azure AD sign-in page for their tenant.
+Domain hints are directives that are included in the authentication request from an application. They can be used to accelerate the user to their federated IdP sign-in page. Or they can be used by a multi-tenant application to accelerate the user straight to the branded Azure AD sign-in page for their tenant.
For example, the application "largeapp.com" might enable their customers to access the application at a custom URL "contoso.largeapp.com." The app might also include a domain hint to contoso.com in the authentication request.
By default, Azure AD attempts to redirect sign-in to the IdP that's configured f
- A domain hint is included in the authentication request from the application **and** - The tenant is federated with that domain.
-If the domain hint doesnΓÇÖt refer to a verified federated domain, it is ignored.
+If the domain hint doesn't refer to a verified federated domain, it is ignored.
For more information about auto-acceleration using the domain hints that are supported by Azure Active Directory, see the [Enterprise Mobility + Security blog](https://cloudblogs.microsoft.com/enterprisemobility/2015/02/11/using-azure-ad-to-land-users-on-their-custom-login-page-from-within-your-app/).
->[!NOTE]
->If a domain hint is included in an authentication request and [should be respected](#home-realm-discovery-policy-to-prevent-auto-acceleration), its presence overrides auto-acceleration that is set for the application in HRD policy.
+> [!NOTE]
+> If a domain hint is included in an authentication request and [should be respected](#home-realm-discovery-policy-to-prevent-auto-acceleration), its presence overrides auto-acceleration that is set for the application in HRD policy.
### Home Realm Discovery policy for auto-acceleration
-Some applications do not provide a way to configure the authentication request they emit. In these cases, itΓÇÖs not possible to use domain hints to control auto-acceleration. Auto-acceleration can be configured via Home Realm Discovery policy to achieve the same behavior.
+Some applications do not provide a way to configure the authentication request they emit. In these cases, it's not possible to use domain hints to control auto-acceleration. Auto-acceleration can be configured via Home Realm Discovery policy to achieve the same behavior.
### Home Realm Discovery policy to prevent auto-acceleration
-Some Microsoft and SaaS applications automatically include domain_hints (for example, `https://outlook.com/contoso.com` results in a login request with `&domain_hint=contoso.com` appended), which can disrupt rollout of managed credentials like FIDO. You can use [Home Realm Discovery Policy](/graph/api/resources/homeRealmDiscoveryPolicy) to ignore domain hints from certain apps or for certain domains, during rollout of managed credentials.
+Some Microsoft and SaaS applications automatically include domain_hints (for example, `https://outlook.com/contoso.com` results in a login request with `&domain_hint=contoso.com` appended), which can disrupt rollout of managed credentials like FIDO. You can use [Home Realm Discovery Policy](/graph/api/resources/homeRealmDiscoveryPolicy) to ignore domain hints from certain apps or for certain domains, during rollout of managed credentials.
## Enable direct ROPC authentication of federated users for legacy applications
There are three steps to setting HRD policy on an application for federated sign
Policies only take effect for a specific application when they are attached to a service principal.
-Only one HRD policy can be active on a service principal at any one time.
+Only one HRD policy can be active on a service principal at any one time.
You can use the Azure Active Directory PowerShell cmdlets to create and manage HRD policy. Following is an example HRD policy definition:
- ```JSON
- {
- "HomeRealmDiscoveryPolicy":
- {
+```json
+{
+ "HomeRealmDiscoveryPolicy":
+ {
"AccelerateToFederatedDomain":true, "PreferredDomain":"federated.example.edu", "AllowCloudPasswordValidation":false,
- }
- }
+ }
+}
``` The policy type is "[HomeRealmDiscoveryPolicy](/graph/api/resources/homeRealmDiscoveryPolicy)".
In the following examples, you create, update, link, and delete policies on appl
2. After you have downloaded the Azure AD PowerShell cmdlets, run the Connect command to sign in to Azure AD with your admin account:
- ``` powershell
+ ```powershell
Connect-AzureAD -Confirm ``` 3. Run the following command to see all the policies in your organization:
- ``` powershell
+ ```powershell
Get-AzureADPolicy ```
In this example, you create a policy that when it is assigned to an application
The following policy auto-accelerates users to an AD FS sign-in screen when they are signing in to an application when there is a single domain in your tenant.
-``` powershell
+```powershell
New-AzureADPolicy -Definition @("{`"HomeRealmDiscoveryPolicy`":{`"AccelerateToFederatedDomain`":true}}") -DisplayName BasicAutoAccelerationPolicy -Type HomeRealmDiscoveryPolicy ``` The following policy auto-accelerates users to an AD FS sign-in screen there is more than one federated domain in your tenant. If you have more than one federated domain that authenticates users for applications, you need specify the domain to auto-accelerate.
-``` powershell
+```powershell
New-AzureADPolicy -Definition @("{`"HomeRealmDiscoveryPolicy`":{`"AccelerateToFederatedDomain`":true, `"PreferredDomain`":`"federated.example.edu`"}}") -DisplayName MultiDomainAutoAccelerationPolicy -Type HomeRealmDiscoveryPolicy ``` To create a policy to enable username/password authentication for federated users directly with Azure Active Directory for specific applications, run the following command:
-``` powershell
+```powershell
New-AzureADPolicy -Definition @("{`"HomeRealmDiscoveryPolicy`":{`"AllowCloudPasswordValidation`":true}}") -DisplayName EnableDirectAuthPolicy -Type HomeRealmDiscoveryPolicy ``` To see your new policy and get its **ObjectID**, run the following command:
-``` powershell
+```powershell
Get-AzureADPolicy ```
You can use the portal, or you can query [Microsoft Graph](/graph/api/resources/
Because you are using PowerShell, you can use the following cmdlet to list the service principals and their IDs.
-``` powershell
+```powershell
Get-AzureADServicePrincipal ```
Get-AzureADServicePrincipal
After you have the **ObjectID** of the service principal of the application for which you want to configure auto-acceleration, run the following command. This command associates the HRD policy that you created in step 1 with the service principal that you located in step 2.
-``` powershell
+```powershell
Add-AzureADServicePrincipalPolicy -Id <ObjectID of the Service Principal> -RefObjectId <ObjectId of the Policy> ``` You can repeat this command for each service principal to which you want to add the policy.
-In the case where an application already has a HomeRealmDiscovery policy assigned, you wonΓÇÖt be able to add a second one. In that case, change the definition of the Home Realm Discovery policy that is assigned to the application to add additional parameters.
+In the case where an application already has a HomeRealmDiscovery policy assigned, you won't be able to add a second one. In that case, change the definition of the Home Realm Discovery policy that is assigned to the application to add additional parameters.
#### Step 4: Check which application service principals your HRD policy is assigned to To check which applications have HRD policy configured, use the **Get-AzureADPolicyAppliedObject** cmdlet. Pass it the **ObjectID** of the policy that you want to check on.
-``` powershell
+```powershell
Get-AzureADPolicyAppliedObject -id <ObjectId of the Policy> ```
Try the application to check that the new policy is working.
#### Step 1: List all policies that were created in your organization
-``` powershell
+```powershell
Get-AzureADPolicy ``` Note the **ObjectID** of the policy that you want to list assignments for.
-#### Step 2: List the service principals to which the policy is assigned
+#### Step 2: List the service principals to which the policy is assigned
-``` powershell
+```powershell
Get-AzureADPolicyAppliedObject -id <ObjectId of the Policy> ```
Get-AzureADPolicyAppliedObject -id <ObjectId of the Policy>
Use the previous example to get the **ObjectID** of the policy, and that of the application service principal from which you want to remove it.
-#### Step 2: Remove the policy assignment from the application service principal
+#### Step 2: Remove the policy assignment from the application service principal
-``` powershell
+```powershell
Remove-AzureADServicePrincipalPolicy -id <ObjectId of the Service Principal> -PolicyId <ObjectId of the policy> ``` #### Step 3: Check removal by listing the service principals to which the policy is assigned
-``` powershell
+```powershell
Get-AzureADPolicyAppliedObject -id <ObjectId of the Policy> ```
Get-AzureADPolicyAppliedObject -id <ObjectId of the Policy>
- For more information about how authentication works in Azure AD, see [Authentication scenarios for Azure AD](../develop/authentication-vs-authorization.md). - For more information about user single sign-on, see [Single sign-on to applications in Azure Active Directory](what-is-single-sign-on.md).-- Visit the [Microsoft identity platform](../develop/v2-overview.md) for an overview of all developer-related content.
+- Visit the [Microsoft identity platform](../develop/v2-overview.md) for an overview of all developer-related content.
active-directory F5 Bigip Deployment Guide https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/manage-apps/f5-bigip-deployment-guide.md
A BIG-IP system is administered via its web config UI, which can be accessed usi
- From a VPN client connected to the BIG-IP-VMΓÇÖs internal network -- Published via [Azure AD Application Proxy](./application-proxy-add-on-premises-application.md)
+- Published via [Azure AD Application Proxy](../app-proxy/application-proxy-add-on-premises-application.md)
YouΓÇÖll need to decide on the most suitable method before you can proceed with the remaining configurations. If necessary, you can connect directly to the web config from the internet by configuring the BIG-IPΓÇÖs primary IP with a public IP. Then adding an NSG rule to allow the 8443 traffic to that primary IP. Make sure to restrict the source to your own trusted IP, otherwise anyone will be able to connect.
active-directory Manage Application Permissions https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/manage-apps/manage-application-permissions.md
+ # Take action on overprivileged or suspicious applications in Azure Active Directory Learn how to review and manage application permissions. This article provides different actions you can take to secure your application according to the scenario. These actions apply to all applications that were added to your Azure Active Directory (Azure AD) tenant via user or admin consent.
To do the following actions, you must sign in as a global administrator, an appl
To restrict access to applications, you need to require user assignment and then assign users or groups to the application. For more information, see [Methods for assigning users and groups](./assign-user-or-group-access-portal.md). You can access the Azure AD portal to get contextual PowerShell scripts to perform the actions.
-
+ 1. Sign in to the [Azure portal](https://portal.azure.com) as a global administrator, an application administrator, or a cloud application administrator. 2. Select **Azure Active Directory** > **Enterprise applications**. 3. Select the application that you want to restrict access to.
You can access the Azure AD portal to get contextual PowerShell scripts to perfo
![Screenshot of the review permissions window.](./media/manage-application-permissions/review-permissions.png) - ## Control access to an application We recommend that you restrict access to the application by turning on the **User assignment** setting.
Optionally, by using PowerShell, you can:
Or you can disable the application to block users' access and stop the application's access to your data. -
-## Disable a malicious application
+## Disable a malicious application
We recommend that you disable the application to block users' access and to keep the application from accessing your data. If you delete the application instead, then users can re-consent to the application and grant access to your data.
We recommend that you disable the application to block users' access and to keep
### PowerShell commands - Retrieve the service principal object ID. 1. Sign in to the [Azure portal](https://portal.azure.com) as a global administrator, an application administrator, or a cloud application administrator.
Retrieve the service principal object ID.
3. Select the application that you want to restrict access to. 4. Select **Properties**, and then copy the object ID.
-```powershell
-$sp = Get-AzureADServicePrincipal -Filter "displayName eq '$app_name'"
-$sp.ObjectId
-```
+ ```powershell
+ $sp = Get-AzureADServicePrincipal -Filter "displayName eq '$app_name'"
+ $sp.ObjectId
+ ```
+ Remove all users who are assigned to the application.
- ```powershell
+
+```powershell
Connect-AzureAD # Get Service Principal using objectId
$assignments | ForEach-Object {
Remove-AzureADGroupAppRoleAssignment -ObjectId $_.PrincipalId -AppRoleAssignmentId $_.ObjectId } }
- ```
+```
Revoke permissions granted to the application.
$spApplicationPermissions | ForEach-Object {
Remove-AzureADServiceAppRoleAssignment -ObjectId $_.PrincipalId -AppRoleAssignmentId $_.objectId } ```+ Invalidate the refresh tokens.+ ```powershell Connect-AzureAD
$assignments | ForEach-Object {
Revoke-AzureADUserAllRefreshToken -ObjectId $_.PrincipalId } ```+ ## Next steps+ - [Manage consent to applications and evaluate consent request](manage-consent-requests.md) - [Configure user consent](configure-user-consent.md) - [Configure admin consent workflow](configure-admin-consent-workflow.md)
active-directory Secure Hybrid Access https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/manage-apps/secure-hybrid-access.md
You can bridge the gap and strengthen your security posture across all applicati
## Secure hybrid access (SHA) through Azure AD Application Proxy
-Using [Application Proxy](./what-is-application-proxy.md) you can provide [secure remote access](./application-proxy.md) to your on-premises web applications. Your users donΓÇÖt require to use a VPN. Users benefit by easily connecting to their applications from any device after a [single sign-on](./add-application-portal-setup-sso.md). Application Proxy provides remote access as a service and allows you to [easily publish your on-premise applications](./application-proxy-add-on-premises-application.md) to users outside the corporate network. It helps you scale your cloud access management without requiring you to modify your on-premises applications. [Plan an Azure AD Application Proxy deployment](./application-proxy-deployment-plan.md) as a next step.
+Using [Application Proxy](../app-proxy/what-is-application-proxy.md) you can provide [secure remote access](../app-proxy/application-proxy.md) to your on-premises web applications. Your users donΓÇÖt require to use a VPN. Users benefit by easily connecting to their applications from any device after a [single sign-on](add-application-portal-setup-sso.md). Application Proxy provides remote access as a service and allows you to [easily publish your on-premise applications](../app-proxy/application-proxy-add-on-premises-application.md) to users outside the corporate network. It helps you scale your cloud access management without requiring you to modify your on-premises applications. [Plan an Azure AD Application Proxy deployment](application-proxy-deployment-plan.md) as a next step.
## Azure AD partner integrations
active-directory Sso Options https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/manage-apps/sso-options.md
To configure an on-premises app for IWA, see [Kerberos Constrained Delegation fo
### How single sign-on with KCD works This diagram explains the flow when a user accesses an on-premises application that uses IWA.
-![Microsoft Azure AD authentication flow diagram](./media/application-proxy-configure-single-sign-on-with-kcd/AuthDiagram.png)
+![Microsoft Azure AD authentication flow diagram](../app-proxy/media/application-proxy-configure-single-sign-on-with-kcd/AuthDiagram.png)
1. The user enters the URL to access the on premises application through Application Proxy. 1. Application Proxy redirects the request to Azure AD authentication services to preauthenticate. At this point, Azure AD applies any applicable authentication and authorization policies, such as multifactor authentication. If the user is validated, Azure AD creates a token and sends it to the user.
active-directory Whats New Docs https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/manage-apps/whats-new-docs.md
Welcome to what's new in Azure Active Directory application management documenta
- [Troubleshoot Kerberos constrained delegation configurations for Application Proxy](application-proxy-back-end-kerberos-constrained-delegation-how-to.md) - [Quickstart: Set up SAML-based single sign-on (SSO) for an application in your Azure Active Directory (Azure AD) tenant](add-application-portal-setup-sso.md) - [Azure Active Directory application management: What's new](whats-new-docs.md)-- [Active Directory (Azure AD) Application Proxy frequently asked questions](application-proxy-faq.yml)
+- [Active Directory (Azure AD) Application Proxy frequently asked questions](../app-proxy/application-proxy-faq.yml)
- [Troubleshoot problems signing in to an application from Azure AD My Apps](application-sign-in-other-problem-access-panel.md)-- [Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory](application-proxy-add-on-premises-application.md)-- [Optimize traffic flow with Azure Active Directory Application Proxy](application-proxy-network-topology.md)
+- [Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory](../app-proxy/application-proxy-add-on-premises-application.md)
+- [Optimize traffic flow with Azure Active Directory Application Proxy](../app-proxy/application-proxy-network-topology.md)
- [Azure AD Application Proxy: Version release history](application-proxy-release-version-history.md) - [Configure Azure Active Directory sign in behavior for an application by using a Home Realm Discovery policy](configure-authentication-for-federated-users-portal.md) - [Moving application authentication from Active Directory Federation Services to Azure Active Directory](migrate-adfs-apps-to-azure.md)
Welcome to what's new in Azure Active Directory application management documenta
- [Integrate with SharePoint (SAML)](application-proxy-integrate-with-sharepoint-server-saml.md) - [Grant tenant-wide admin consent to an application](grant-admin-consent.md) - [Moving application authentication from Active Directory Federation Services to Azure Active Directory](migrate-adfs-apps-to-azure.md)-- [Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory](application-proxy-add-on-premises-application.md)
+- [Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory](../app-proxy/application-proxy-add-on-premises-application.md)
- [Use tenant restrictions to manage access to SaaS cloud applications](tenant-restrictions.md) ## January 2021
Welcome to what's new in Azure Active Directory application management documenta
- [Application management best practices](application-management-fundamentals.md) - [Integrating Azure Active Directory with applications getting started guide](plan-an-application-integration.md) - [What is application management?](what-is-application-management.md)-- [Active Directory (Azure AD) Application Proxy frequently asked questions](application-proxy-faq.yml)-- [Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory](application-proxy-add-on-premises-application.md)
+- [Active Directory (Azure AD) Application Proxy frequently asked questions](../app-proxy/application-proxy-faq.yml)
+- [Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory](../app-proxy/application-proxy-add-on-premises-application.md)
- [Work with existing on-premises proxy servers](application-proxy-configure-connectors-with-proxy-servers.md) - [Develop line-of-business apps for Azure Active Directory](../develop/v2-overview.md) - [Understand Azure AD Application Proxy connectors](application-proxy-connectors.md)
Welcome to what's new in Azure Active Directory application management documenta
- [Quickstart: Delete an application from your Azure Active Directory (Azure AD) tenant](delete-application-portal.md) - [Publish Remote Desktop with Azure AD Application Proxy](application-proxy-integrate-with-remote-desktop-services.md) - [Take action on overprivileged or suspicious applications in Azure Active Directory](manage-application-permissions.md)--
-## December 2020
-
-### Updated articles
--- [Quickstart: Set up OIDC-based single sign-on (SSO) for an application in your Azure Active Directory (Azure AD) tenant](add-application-portal-setup-oidc-sso.md)-- [Tutorial: Add an on-premises application for remote access through Application Proxy in Azure Active Directory](application-proxy-add-on-premises-application.md)-- [Understand OIDC-based single sign-on](configure-oidc-single-sign-on.md)-- [Moving application authentication from Active Directory Federation Services to Azure Active Directory](migrate-adfs-apps-to-azure.md)-- [Work with existing on-premises proxy servers](application-proxy-configure-connectors-with-proxy-servers.md)-- [Azure Active Directory application management: What's new](whats-new-docs.md)-- [Use the AD FS application activity report (preview) to migrate applications to Azure AD](migrate-adfs-application-activity.md)-- [Publish Remote Desktop with Azure AD Application Proxy](application-proxy-integrate-with-remote-desktop-services.md)--
-## November 2020
-
-### New articles
-- [Header-based single sign-on for on-premises apps with Azure AD App Proxy (Preview)](application-proxy-configure-single-sign-on-with-headers.md)-
-### Updated articles
-- [Azure Active Directory application management: What's new](whats-new-docs.md)--
-## October 2020
-
-### New articles
--- [Azure Active Directory application management: What's new](whats-new-docs.md)-- [Understand OIDC-based single sign-on](configure-oidc-single-sign-on.md)-- [Configure permission classifications](configure-permission-classifications.md)-- [Configure group owner consent to apps accessing group data](configure-user-consent-groups.md)-- [Manage app consent policies](manage-app-consent-policies.md)-
-### Updated articles
--- [Problem installing the Application Proxy Agent Connector](application-proxy-connector-installation-problem.md)-- [Moving application authentication from Active Directory Federation Services to Azure Active Directory](migrate-adfs-apps-to-azure.md)-- [Configure how end-users consent to applications](configure-user-consent.md)--
-## September 2020
-
-### New articles
-- [Quickstart: Set up OIDC-based single sign-on (SSO) for an application in your Azure Active Directory (Azure AD) tenant](add-application-portal-setup-oidc-sso.md)-- [Quickstart: Assign users to an app that is using Azure AD as an identity provider](add-application-portal-assign-users.md)-- [What's new in docs?](whats-new-docs.md)--
-### Updated articles
-- [Quickstart: Add an application to your Azure Active Directory (Azure AD) tenant](add-application-portal.md)-- [Troubleshoot common problem adding or removing an application to Azure Active Directory](/troubleshoot/azure/active-directory/troubleshoot-adding-apps)-- [Managing consent to applications and evaluating consent requests](manage-consent-requests.md)-- [Viewing apps using your Azure AD tenant for identity management](application-types.md)-- [Understand how users are assigned to apps in Azure Active Directory](ways-users-get-assigned-to-applications.md)-- [Manage user assignment for an app in Azure Active Directory](assign-user-or-group-access-portal.md)--
-## August 2020
-
-### New articles
-- [Single sign-on options in Azure AD](sso-options.md)--
-### Updated articles
-- [End-user experiences for applications in Azure Active Directory](end-user-experiences.md)-- [How to use self-service application access](access-panel-manage-self-service-access.md)-- [Troubleshoot problems signing in to an application from Azure AD My Apps](application-sign-in-other-problem-access-panel.md)-- [Troubleshoot password-based single sign-on in Azure AD](troubleshoot-password-based-sso.md)-- [Plan an Azure Active Directory My Apps deployment](my-apps-deployment-plan.md)-- [What is single sign-on (SSO)?](what-is-single-sign-on.md)-- [Take action on overprivileged or suspicious applications in Azure Active Directory](manage-application-permissions.md)-- [Quickstart: Configure properties for an application in your Azure Active Directory (Azure AD) tenant](add-application-portal-configure.md)-- [Automate SAML-based SSO app configuration with Microsoft Graph API](/graph/application-saml-sso-configure-api)--
-## July 2020
-
-### New articles
-- [Configure SAML-based single sign-on](configure-saml-single-sign-on.md)-- [Get It Now - add an app from the Azure Marketplace](get-it-now-azure-marketplace.md)-- [Quickstart: Configure properties for an application in your Azure Active Directory (Azure AD) tenant](add-application-portal-configure.md)-- [Quickstart: Set up single sign-on (SSO) for an application in your Azure Active Directory (Azure AD) tenant](add-application-portal-setup-sso.md)-- [Quickstart: Delete an application from your Azure Active Directory (Azure AD) tenant](delete-application-portal.md)-- [Take action on overpriviledged, or suspicious application in Azure Active Directory](manage-application-permissions.md)--
-### Updated articles
-- [Configure linked sign-on](configure-linked-sign-on.md)-- [Configure password-based single sign-on](configure-password-single-sign-on-non-gallery-applications.md)-- [Redirect hard-coded links for apps published with Azure AD Application Proxy](application-proxy-configure-hard-coded-link-translation.md)-- [Publish Remote Desktop with Azure AD Application Proxy](application-proxy-integrate-with-remote-desktop-services.md)-- [Azure AD Application Proxy: Version release history](application-proxy-release-version-history.md)-- [Quickstart: Configure properties for an application in your Azure Active Directory (Azure AD) tenant](add-application-portal-configure.md)-- [Quickstart: Set up single sign-on (SSO) for an application in your Azure Active Directory (Azure AD) tenant](add-application-portal-setup-sso.md)-- [Quickstart: View applications using your Azure Active Directory (Azure AD) tenant for identity management](view-applications-portal.md)-- [Quickstart: Add an application to your Azure Active Directory (Azure AD) tenant](add-application-portal.md)
active-directory How To Manage Ua Identity Powershell https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/managed-identities-azure-resources/how-to-manage-ua-identity-powershell.md
documentationcenter:
+editor:
# Create, list, or delete a user-assigned managed identity using Azure PowerShell
-Managed identities for Azure resources provide Azure services with a managed identity in Azure Active Directory. You can use this identity to authenticate to services that support Azure AD authentication, without needing credentials in your code.
+Managed identities for Azure resources provide Azure services with a managed identity in Azure Active Directory. You can use this identity to authenticate to services that support Azure AD authentication, without needing credentials in your code.
In this article, you learn how to create, list, and delete a user-assigned managed identity using Azure PowerShell.
To create a user-assigned managed identity, use the `New-AzUserAssignedIdentity`
[!INCLUDE [ua-character-limit](~/includes/managed-identity-ua-character-limits.md)]
- ```azurepowershell-interactive
+```azurepowershell-interactive
New-AzUserAssignedIdentity -ResourceGroupName <RESOURCEGROUP> -Name <USER ASSIGNED IDENTITY NAME> ```+ ## List user-assigned managed identities To list/read a user-assigned managed identity, your account needs the [Managed Identity Operator](../../role-based-access-control/built-in-roles.md#managed-identity-operator) or [Managed Identity Contributor](../../role-based-access-control/built-in-roles.md#managed-identity-contributor) role assignment.
To list user-assigned managed identities, use the [Get-AzUserAssigned] command.
```azurepowershell-interactive Get-AzUserAssignedIdentity -ResourceGroupName <RESOURCE GROUP> ```+ In the response, user-assigned managed identities have `"Microsoft.ManagedIdentity/userAssignedIdentities"` value returned for key, `Type`. `Type :Microsoft.ManagedIdentity/userAssignedIdentities`
To delete a user-assigned managed identity, your account needs the [Managed Iden
To delete a user-assigned managed identity, use the `Remove-AzUserAssignedIdentity` command. The `-ResourceGroupName` parameter specifies the resource group where the user-assigned identity was created and the `-Name` parameter specifies its name. Replace the `<RESOURCE GROUP>` and the `<USER ASSIGNED IDENTITY NAME>` parameters values with your own values:
- ```azurepowershell-interactive
+```azurepowershell-interactive
Remove-AzUserAssignedIdentity -ResourceGroupName <RESOURCE GROUP> -Name <USER ASSIGNED IDENTITY NAME> ```+ > [!NOTE] > Deleting a user-assigned managed identity will not remove the reference, from any resource it was assigned to. Identity assignments need to be removed separately.
active-directory Qs Configure Template Windows Vm https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/managed-identities-azure-resources/qs-configure-template-windows-vm.md
As with the Azure portal and scripting, [Azure Resource Manager](../../azure-res
- Using a [custom template from the Azure Marketplace](../../azure-resource-manager/templates/deploy-portal.md#deploy-resources-from-custom-template), which allows you to create a template from scratch, or base it on an existing common or [quickstart template](https://azure.microsoft.com/documentation/templates/). - Deriving from an existing resource group, by exporting a template from either [the original deployment](../../azure-resource-manager/templates/export-template-portal.md), or from the [current state of the deployment](../../azure-resource-manager/templates/export-template-portal.md). - Using a local [JSON editor (such as VS Code)](../../azure-resource-manager/templates/quickstart-create-templates-use-the-portal.md), and then uploading and deploying by using PowerShell or CLI.
- - Using the Visual Studio [Azure Resource Group project](../../azure-resource-manager/templates/create-visual-studio-deployment-project.md) to both create and deploy a template.
+ - Using the Visual Studio [Azure Resource Group project](../../azure-resource-manager/templates/create-visual-studio-deployment-project.md) to both create and deploy a template.
Regardless of the option you choose, template syntax is the same during initial deployment and redeployment. Enabling a system or user-assigned managed identity on a new or existing VM is done in the same manner. Also, by default, Azure Resource Manager does an [incremental update](../../azure-resource-manager/templates/deployment-modes.md) to deployments.
To enable system-assigned managed identity on a VM, your account needs the [Virt
2. To enable system-assigned managed identity, load the template into an editor, locate the `Microsoft.Compute/virtualMachines` resource of interest within the `resources` section and add the `"identity"` property at the same level as the `"type": "Microsoft.Compute/virtualMachines"` property. Use the following syntax:
- ```JSON
+ ```json
"identity": { "type": "SystemAssigned" }, ``` -- 3. When you're done, the following sections should be added to the `resource` section of your template and it should resemble the following:
- ```JSON
+ ```json
"resources": [ { //other resource provider properties...
To assign a role to your VM's system-assigned identity, your account needs the [
Under the `parameters` section add the following:
- ```JSON
+ ```json
"builtInRoleType": { "type": "string", "defaultValue": "Reader"
To assign a role to your VM's system-assigned identity, your account needs the [
Under the `variables` section add the following:
- ```JSON
+ ```json
"Reader": "[concat('/subscriptions/', subscription().subscriptionId, '/providers/Microsoft.Authorization/roleDefinitions/', 'acdd72a7-3385-48ef-bd42-f606fba81ae7')]" ``` Under the `resources` section add the following:
- ```JSON
+ ```json
{ "apiVersion": "2017-09-01", "type": "Microsoft.Authorization/roleAssignments",
To remove system-assigned managed identity from a VM, your account needs the [Vi
1. Whether you sign in to Azure locally or via the Azure portal, use an account that is associated with the Azure subscription that contains the VM.
-2. Load the template into an [editor](#azure-resource-manager-templates) and locate the `Microsoft.Compute/virtualMachines` resource of interest within the `resources` section. If you have a VM that only has system-assigned managed identity, you can disable it by changing the identity type to `None`.
+2. Load the template into an [editor](#azure-resource-manager-templates) and locate the `Microsoft.Compute/virtualMachines` resource of interest within the `resources` section. If you have a VM that only has system-assigned managed identity, you can disable it by changing the identity type to `None`.
**Microsoft.Compute/virtualMachines API version 2018-06-01**
To remove system-assigned managed identity from a VM, your account needs the [Vi
**Microsoft.Compute/virtualMachines API version 2018-06-01**
- If your `apiVersion` is `2017-12-01` and your VM has both system and user-assigned managed identities, remove `SystemAssigned` from the identity type and keep `UserAssigned` along with the `identityIds` array of the user-assigned managed identities.
+ If your `apiVersion` is `2017-12-01` and your VM has both system and user-assigned managed identities, remove `SystemAssigned` from the identity type and keep `UserAssigned` along with the `identityIds` array of the user-assigned managed identities.
The following example shows you how to remove a system-assigned managed identity from a VM with no user-assigned managed identities:
- ```JSON
- {
- "apiVersion": "2018-06-01",
- "type": "Microsoft.Compute/virtualMachines",
- "name": "[parameters('vmName')]",
- "location": "[resourceGroup().location]",
- "identity": {
- "type": "None"
- }
- }
- ```
+```json
+{
+ "apiVersion": "2018-06-01",
+ "type": "Microsoft.Compute/virtualMachines",
+ "name": "[parameters('vmName')]",
+ "location": "[resourceGroup().location]",
+ "identity": {
+ "type": "None"
+ }
+}
+```
## User-assigned managed identity In this section, you assign a user-assigned managed identity to an Azure VM using Azure Resource Manager template.
-> [!Note]
+> [!NOTE]
> To create a user-assigned managed identity using an Azure Resource Manager Template, see [Create a user-assigned managed identity](how-to-manage-ua-identity-arm.md#create-a-user-assigned-managed-identity). ### Assign a user-assigned managed identity to an Azure VM
To assign a user-assigned identity to a VM, your account needs the [Virtual Mach
If your `apiVersion` is `2018-06-01`, your user-assigned managed identities are stored in the `userAssignedIdentities` dictionary format and the `<USERASSIGNEDIDENTITYNAME>` value must be stored in a variable defined in the `variables` section of your template.
- ```JSON
+ ```json
{ "apiVersion": "2018-06-01", "type": "Microsoft.Compute/virtualMachines",
To assign a user-assigned identity to a VM, your account needs the [Virtual Mach
If your `apiVersion` is `2017-12-01`, your user-assigned managed identities are stored in the `identityIds` array and the `<USERASSIGNEDIDENTITYNAME>` value must be stored in a variable defined in the `variables` section of your template.
- ```JSON
+ ```json
{ "apiVersion": "2017-12-01", "type": "Microsoft.Compute/virtualMachines",
To assign a user-assigned identity to a VM, your account needs the [Virtual Mach
3. When you're done, the following sections should be added to the `resource` section of your template and it should resemble the following:
- **Microsoft.Compute/virtualMachines API version 2018-06-01**
+ **Microsoft.Compute/virtualMachines API version 2018-06-01**
- ```JSON
+ ```json
"resources": [ { //other resource provider properties...
To assign a user-assigned identity to a VM, your account needs the [Virtual Mach
} ] ```+ **Microsoft.Compute/virtualMachines API version 2017-12-01**
- ```JSON
+ ```json
"resources": [ { //other resource provider properties...
active-directory Services Support Managed Identities https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/managed-identities-azure-resources/services-support-managed-identities.md
Managed identity type | All Generally Available<br>Global Azure Regions | Azure
| Managed identity type | All Generally Available<br>Global Azure Regions | Azure Government | Azure Germany | Azure China 21Vianet | | | :-: | :-: | :-: | :-: | | System assigned | ![Available][check] | ![Available][check] | Not available | Not available |
-| User assigned | Preview | Not available | Not available | Not available |
+| User assigned | Preview | ![Available][check] | Not available | Not available |
For more information, see [Use managed identities in Azure Kubernetes Service](../../aks/use-managed-identity.md).
active-directory Groups Concept https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/roles/groups-concept.md
Previously updated : 11/05/2020 Last updated : 04/27/2021
Consider this example: Contoso has hired people across geographies to manage and
## How this feature works
-Create a new Microsoft 365 or security group with the ΓÇÿisAssignableToRoleΓÇÖ property set to ΓÇÿtrueΓÇÖ. You could also enable this property when creating a group in the Azure portal by turning on **Azure AD roles can be assigned to the group**. Either way, you can then assign the group to one or more Azure AD roles in the same way as you assign roles to users. A maximum of 250 role-assignable groups can be created in a single Azure AD organization (tenant).
+Create a new Microsoft 365 or security group with the ΓÇÿisAssignableToRoleΓÇÖ property set to ΓÇÿtrueΓÇÖ. You could also enable this property when creating a group in the Azure portal by turning on **Azure AD roles can be assigned to the group**. Either way, you can then assign the group to one or more Azure AD roles in the same way as you assign roles to users. A maximum of 300 role-assignable groups can be created in a single Azure AD organization (tenant).
If you do not want members of the group to have standing access to the role, you can use Azure AD Privileged Identity Management. Assign a group as an eligible member of an Azure AD role. Each member of the group is then eligible to have their assignment activated for the role that the group is assigned to. They can then activate their role assignment for a fixed time duration.
active-directory Cisco Umbrella User Management Provisioning Tutorial https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/saas-apps/cisco-umbrella-user-management-provisioning-tutorial.md
+
+ Title: 'Tutorial: Configure Cisco Umbrella User Management for automatic user provisioning with Azure Active Directory | Microsoft Docs'
+description: Learn how to automatically provision and de-provision user accounts from Azure AD to Cisco Umbrella User Management.
+
+documentationcenter: ''
+
+writer: Zhchia
++
+ms.assetid: 1aa20f40-19ec-4213-9a3b-5eb2bcdd9bbd
+++
+ na
+ms.devlang: na
+ Last updated : 04/20/2021+++
+# Tutorial: Configure Cisco Umbrella User Management for automatic user provisioning
+
+This tutorial describes the steps you need to perform in both Cisco Umbrella User Management and Azure Active Directory (Azure AD) to configure automatic user provisioning. When configured, Azure AD automatically provisions and de-provisions users and groups to [Cisco Umbrella User Management](https://umbrella.cisco.com/) using the Azure AD Provisioning service. For important details on what this service does, how it works, and frequently asked questions, see [Automate user provisioning and deprovisioning to SaaS applications with Azure Active Directory](../manage-apps/user-provisioning.md).
++
+## Capabilities Supported
+> [!div class="checklist"]
+> * Create users in Cisco Umbrella User Management
+> * Remove users in Cisco Umbrella User Management when they do not require access anymore
+> * Keep user attributes synchronized between Azure AD and Cisco Umbrella User Management
+> * Provision groups and group memberships in Cisco Umbrella User Management
+
+## Prerequisites
+
+The scenario outlined in this tutorial assumes that you already have the following prerequisites:
+
+* [An Azure AD tenant](https://docs.microsoft.com/azure/active-directory/develop/quickstart-create-new-tenant)
+* A user account in Azure AD with [permission](https://docs.microsoft.com/azure/active-directory/users-groups-roles/directory-assign-admin-roles) to configure provisioning (e.g. Application Administrator, Cloud Application administrator, Application Owner, or Global Administrator).
+* A [Cisco Umbrella subscription](https://signup.umbrella.com).
+* A user account in Cisco Umbrella with full admin permissions.
+
+## Step 1. Plan your provisioning deployment
+1. Learn about [how the provisioning service works](https://docs.microsoft.com/azure/active-directory/manage-apps/user-provisioning).
+2. Determine who will be in [scope for provisioning](https://docs.microsoft.com/azure/active-directory/manage-apps/define-conditional-rules-for-provisioning-user-accounts).
+3. Determine what data to [map between Azure AD and Cisco Umbrella User Management](https://docs.microsoft.com/azure/active-directory/manage-apps/customize-application-attributes).
+
+## Step 2. Import ObjectGUID attribute via Azure AD Connect (Optional)
+If you have previously provisioned user and group identities from on-premise AD to Cisco Umbrella and would now like to provision the same users and groups from Azure AD, you will need to synchronize the ObjectGUID attribute so that previously provisioned identities persist in the Umbrella policy.
+
+> [!NOTE]
+> The on-premise Umbrella AD Connector should be turned off before importing the ObjectGUID attribute.
+
+When using Microsoft Azure AD Connect, the ObjectGUID attribute of users and groups is not synchronized from on-premise AD to Azure AD by default. To synchronize this attribute, enable the optional **Directory Extension attribute sync** and select the objectGUID attributes for groups and users.
+
+ ![Azure Active Directory Connect wizard Optional features page](./media/cisco-umbrella-user-management-provisioning-tutorial/active-directory-connect-directory-extension-attribute-sync.png)
+
+> [!NOTE]
+> The search under **Available Attributes** is case sensitive.
+
+ ![Screenshot that shows the "Directory extensions" selection page](./media/cisco-umbrella-user-management-provisioning-tutorial/active-directory-connect-directory-extensions.png)
+
+## Step 3. Configure Cisco Umbrella User Management to support provisioning with Azure AD
+
+1. Log in to [Cisco Umbrella dashboard](https://login.umbrella.com ). Navigate to **Deployments** > **Core Identities** > **Users and Groups**.
+
+2. If the import mechanism is set to Manual import, click on **Import from IdP** to switch the import mechanism.
+
+3. Expand the Azure Active Directory card and click on the **API Keys page**.
+
+ ![Api](./media/cisco-umbrella-user-management-provisioning-tutorial/keys.png)
+
+4. Expand the Azure Active Directory card on the API Keys page and click on **Generate Token**.
+
+ ![Generate](./media/cisco-umbrella-user-management-provisioning-tutorial/token.png)
+
+5. The generated token will be displayed only once. Copy and save the URL and the token. These values will be entered in the **Tenant URL** and **Secret Token** fields respectively in the Provisioning tab of your Cisco Umbrella User Management application in the Azure portal.
++
+## Step 4. Add Cisco Umbrella User Management from the Azure AD application gallery
+
+Add Cisco Umbrella User Management from the Azure AD application gallery to start managing provisioning to Cisco Umbrella User Management. Learn more about adding an application from the gallery [here](https://docs.microsoft.com/azure/active-directory/manage-apps/add-gallery-app).
+
+## Step 5. Define who will be in scope for provisioning
+
+The Azure AD provisioning service allows you to scope who will be provisioned based on assignment to the application and or based on attributes of the user / group. If you choose to scope who will be provisioned to your app based on assignment, you can use the following [steps](../manage-apps/assign-user-or-group-access-portal.md) to assign users and groups to the application. If you choose to scope who will be provisioned based solely on attributes of the user or group, you can use a scoping filter as described [here](https://docs.microsoft.com/azure/active-directory/manage-apps/define-conditional-rules-for-provisioning-user-accounts).
+
+* When assigning users and groups to Cisco Umbrella User Management, you must select a role other than **Default Access**. Users with the Default Access role are excluded from provisioning and will be marked as not effectively entitled in the provisioning logs. If the only role available on the application is the default access role, you can [update the application manifest](https://docs.microsoft.com/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps) to add additional roles.
+
+* Start small. Test with a small set of users and groups before rolling out to everyone. When scope for provisioning is set to assigned users and groups, you can control this by assigning one or two users or groups to the app. When scope is set to all users and groups, you can specify an [attribute based scoping filter](https://docs.microsoft.com/azure/active-directory/manage-apps/define-conditional-rules-for-provisioning-user-accounts).
+
+## Step 6. Configure automatic user provisioning to Cisco Umbrella User Management
+
+This section guides you through the steps to configure the Azure AD provisioning service to create, update, and disable users and/or groups in Cisco Umbrella User Management based on user and/or group assignments in Azure AD.
+
+### To configure automatic user provisioning for Cisco Umbrella User Management in Azure AD:
+
+1. Sign in to the [Azure portal](https://portal.azure.com). Select **Enterprise Applications**, then select **All applications**.
+
+ ![Enterprise applications blade](common/enterprise-applications.png)
+
+2. In the applications list, select **Cisco Umbrella User Management**.
+
+ ![The Cisco Umbrella User Management link in the Applications list](common/all-applications.png)
+
+3. Select the **Provisioning** tab.
+
+ ![Provisioning tab](common/provisioning.png)
+
+4. Set the **Provisioning Mode** to **Automatic**.
+
+ ![Provisioning tab automatic](common/provisioning-automatic.png)
+
+5. Under the **Admin Credentials** section, input your Cisco Umbrella User Management Tenant URL and Secret Token. Click **Test Connection** to ensure Azure AD can connect to Cisco Umbrella User Management. If the connection fails, ensure your Cisco Umbrella User Management account has Admin permissions and try again.
+
+ ![Token](common/provisioning-testconnection-tenanturltoken.png)
+
+6. In the **Notification Email** field, enter the email address of a person or group who should receive the provisioning error notifications and select the **Send an email notification when a failure occurs** check box.
+
+ ![Notification Email](common/provisioning-notification-email.png)
+
+7. Select **Save**.
+
+8. Under the **Mappings** section, select **Synchronize Azure Active Directory Users to Cisco Umbrella User Management**.
+
+9. Review the user attributes that are synchronized from Azure AD to Cisco Umbrella User Management in the **Attribute-Mapping** section. The attributes selected as **Matching** properties are used to match the user accounts in Cisco Umbrella User Management for update operations. If you choose to change the [matching target attribute](https://docs.microsoft.com/azure/active-directory/manage-apps/customize-application-attributes), you will need to ensure that the Cisco Umbrella User Management API supports filtering users based on that attribute. Select the **Save** button to commit any changes.
+
+ |Attribute|Type|Supported for Filtering|
+ ||||
+ |userName|String|&check;|
+ |externalId|String|
+ |active|Boolean|
+ |displayName|String|
+ |name.givenName|String|
+ |name.familyName|String|
+ |name.formatted|String|
+ |urn:ietf:params:scim:schemas:extension:ciscoumbrella:2.0:User:nativeObjectId|String|
+
+> [!NOTE]
+> If you have imported the objectGUID attribute for users via Azure AD Connect (refer Step 2), add a mapping from objectGUID to urn:ietf:params:scim:schemas:extension:ciscoumbrella:2.0:User:nativeObjectId.
+
+10. Under the **Mappings** section, select **Synchronize Azure Active Directory Groups to Cisco Umbrella User Management**.
+
+11. Review the group attributes that are synchronized from Azure AD to Cisco Umbrella User Management in the **Attribute-Mapping** section. The attributes selected as **Matching** properties are used to match the groups in Cisco Umbrella User Management for update operations. Select the **Save** button to commit any changes.
+
+ |Attribute|Type|Supported for Filtering|
+ ||||
+ |displayName|String|&check;|
+ |externalId|String|
+ |members|Reference|
+ |urn:ietf:params:scim:schemas:extension:ciscoumbrella:2.0:Group:nativeObjectId|String|
+
+> [!NOTE]
+> If you have imported the objectGUID attribute for groups via Azure AD Connect (refer Step 2), add a mapping from objectGUID to urn:ietf:params:scim:schemas:extension:ciscoumbrella:2.0:Group:nativeObjectId.
+
+12. To configure scoping filters, refer to the following instructions provided in the [Scoping filter tutorial](../manage-apps/define-conditional-rules-for-provisioning-user-accounts.md).
+
+13. To enable the Azure AD provisioning service for Cisco Umbrella User Management, change the **Provisioning Status** to **On** in the **Settings** section.
+
+ ![Provisioning Status Toggled On](common/provisioning-toggle-on.png)
+
+14. Define the users and/or groups that you would like to provision to Cisco Umbrella User Management by choosing the desired values in **Scope** in the **Settings** section.
+
+ ![Provisioning Scope](common/provisioning-scope.png)
+
+15. When you are ready to provision, click **Save**.
+
+ ![Saving Provisioning Configuration](common/provisioning-configuration-save.png)
+
+This operation starts the initial synchronization cycle of all users and groups defined in **Scope** in the **Settings** section. The initial cycle takes longer to perform than subsequent cycles, which occur approximately every 40 minutes as long as the Azure AD provisioning service is running.
+
+## Step 7. Monitor your deployment
+Once you've configured provisioning, use the following resources to monitor your deployment:
+
+1. Use the [provisioning logs](https://docs.microsoft.com/azure/active-directory/reports-monitoring/concept-provisioning-logs) to determine which users have been provisioned successfully or unsuccessfully
+2. Check the [progress bar](https://docs.microsoft.com/azure/active-directory/app-provisioning/application-provisioning-when-will-provisioning-finish-specific-user) to see the status of the provisioning cycle and how close it is to completion
+3. If the provisioning configuration seems to be in an unhealthy state, the application will go into quarantine. Learn more about quarantine states [here](https://docs.microsoft.com/azure/active-directory/manage-apps/application-provisioning-quarantine-status).
+
+## Connector Limitations
+* Cisco Umbrella User Management supports provisioning a maximum of 200 groups. Any groups beyond this number that are in scope may not be provisioned to Cisco Umbrella.
+
+## Additional resources
+
+* [Managing user account provisioning for Enterprise Apps](../manage-apps/configure-automatic-user-provisioning-portal.md)
+* [What is application access and single sign-on with Azure Active Directory?](../manage-apps/what-is-single-sign-on.md)
+
+## Next steps
+
+* [Learn how to review logs and get reports on provisioning activity](../manage-apps/check-status-user-account-provisioning.md)
active-directory Euromonitor Passport Tutorial https://github.com/MicrosoftDocs/azure-docs/commits/master/articles/active-directory/saas-apps/euromonitor-passport-tutorial.md
Previously updated : 10/31/2019 Last updated : 04/23/2021
In this tutorial, you'll learn how to integrate Euromonitor Passport with Azure
* Enable your users to be automatically signed-in to Euromonitor Passport with their Azure AD accounts. * Manage your accounts in one central location - the Azure portal.
-To learn more about SaaS app integration with Azure AD, see [What is application access and single sign-on with Azure Active Directory](../manage-apps/what-is-single-sign-on.md).
- ## Prerequisites To get started, you need the following items:
To get started, you need the following items:
In this tutorial, you configure and test Azure AD SSO in a test environment.
-* Euromonitor Passport supports **SP and IDP** initiated SSO
+* Euromonitor Passport supports **SP and IDP** initiated SSO.
> [!NOTE] > Identifier of this application is a fixed string value so only one instance can be configured in one tenant.
-## Adding Euromonitor Passport from the gallery
+## Add Euromonitor Passport from the gallery
To configure the integration of Euromonitor Passport into Azure AD, you need to add Euromonitor Passport from the gallery to your list of managed SaaS apps.
-1. Sign in to the [Azure portal](https://portal.azure.com) using either a work or school account, or a personal Microsoft account.
+1. Sign in to the Azure portal using either a work or school account, or a personal Microsoft account.
1. On the left navigation pane, select the **Azure Active Directory** service. 1. Navigate to **Enterprise Applications** and then select **All Applications**. 1. To add new application, select **New application**. 1. In the **Add from the gallery** section, type **Euromonitor Passport** in the search box. 1. Select **Euromonitor Passport** from results panel and then add the app. Wait a few seconds while the app is added to your tenant.
-## Configure and test Azure AD single sign-on for Euromonitor Passport
+## Configure and test Azure AD SSO for Euromonitor Passport
Configure and test Azure AD SSO with Euromonitor Passport using a test user called **B.Simon**. For SSO to work, you need to establish a link relationship between an Azure AD user and the related user in Euromonitor Passport.
-To configure and test Azure AD SSO with Euromonitor Passport, complete the following building blocks:
+To configure and test Azure AD SSO with Euromonitor Passport, perform the following steps:
1. **[Configure Azure AD SSO](#configure-azure-ad-sso)** - to enable your users to use this feature.
- * **[Create an Azure AD test user](#create-an-azure-ad-test-user)** - to test Azure AD single sign-on with B.Simon.
- * **[Assign the Azure AD test user](#assign-the-azure-ad-test-user)** - to enable B.Simon to use Azure AD single sign-on.
+ 1. **[Create an Azure AD test user](#create-an-azure-ad-test-user)** - to test Azure AD single sign-on with B.Simon.
+ 1. **[Assign the Azure AD test user](#assign-the-azure-ad-test-user)** - to enable B.Simon to use Azure AD single sign-on.
1. **[Configure Euromonitor Passport SSO](#configure-euromonitor-passport-sso)** - to configure the single sign-on settings on application side.
- * **[Create Euromonitor Passport test user](#create-euromonitor-passport-test-user)** - to have a counterpart of B.Simon in Euromonitor Passport that is linked to the Azure AD representation of user.
+ 1. **[Create Euromonitor Passport test user](#create-euromonitor-passport-test-user)** - to have a counterpart of B.Simon in Euromonitor Passport that is linked to the Azure AD representation of user.
1. **[Test SSO](#test-sso)** - to verify whether the configuration works. ## Configure Azure AD SSO Follow these steps to enable Azure AD SSO in the Azure portal.
-1. In the [Azure portal](https://portal.azure.com/), on the **Euromonitor Passport** application integration page, find the **Manage** section and select **single sign-on**.
+1. In the Azure portal on the **Euromonitor Passport** application integration page, find the **Manage** section and select **single sign-on**.
1. On the **Select a single sign-on method** page, select **SAML**.
-1. On the **Set up single sign-on with SAML** page, click the edit/pen icon for **Basic SAML Configuration** to edit the settings.
+1. On the **Set up single sign-on with SAML** page, click the pencil icon for **Basic SAML Configuration** to edit the settings.
![Edit Basic SAML Configuration](common/edit-urls.png)
In this section, you'll enable B.Simon to use Azure single sign-on by granting a
1. In the Azure portal, select **Enterprise Applications**, and then select **All applications**. 1. In the applications list, select **Euromonitor Passport**. 1. In the app's overview page, find the **Manage** section and select **Users and groups**.-
- ![The "Users and groups" link](common/users-groups-blade.png)
- 1. Select **Add user**, then select **Users and groups** in the **Add Assignment** dialog.-
- ![The Add User link](common/add-assign-user.png)
- 1. In the **Users and groups** dialog, select **B.Simon** from the Users list, then click the **Select** button at the bottom of the screen.
-1. If you're expecting any role value in the SAML assertion, in the **Select Role** dialog, select the appropriate role for the user from the list and then click the **Select** button at the bottom of the screen.
+1. If you are expecting a role to be assigned to the users, you can select it from the **Select a role** dropdown. If no role has been set up for this app, you see "Default Access" role selected.
1. In the **Add Assignment** dialog, click the **Assign** button. ## Configure Euromonitor Passport SSO
In this section, you create a user called B.Simon in Euromonitor Passport. Work
## Test SSO
-In this section, you test your Azure AD single sign-on configuration using the Access Panel.
+In this section, you test your Azure AD single sign-on configuration with following options.
+
+#### SP initiated:
+
+* Click on **Test this application** in Azure portal. This will redirect to Euromonitor Passport Sign on URL where you can initiate the login flow.
-When you click the Euromonitor Passport tile in the Access Panel, you should be automatically signed in to the Euromonitor Passport for which you set up SSO. For more information about the Access Panel, see [In