Export (0) Print
Expand All

Configuring Client Access Policies



Some organizations may want to create policies that limit access to Microsoft ® Office 365 services, depending on where the client resides. For example, you might want to:

  • Block all extranet client access to Office 365

  • Block all extranet client access to Office 365, except for devices accessing Exchange Online for Exchange Active Sync

  • Block all extranet client access to Office 365, except for users in one or more Active Directory group

  • Block all extranet client access to Office 365, except for browser based applications

Active Directory Federation Services (AD FS) in Windows Server 2012 R2 provides a way for organizations to configure these types of policies. Office 365 customers using Single Sign-On (SSO) who require these policies can now use client access policy rules to restrict access based on the location of the computer or device that is making the request. Customers using Microsoft Online Services cloud User IDs cannot implement these restrictions at this time.

For more information about how to deploy AD FS in Windows Server 2012 R2 for SSO with Microsoft Online services, see http://go.microsoft.com/fwlink/?LInkId=321138.

Client access policy works by identifying which authentication requests should be permitted based upon attributes of the request itself. To provide this additional request context information, AD FS populates claim values from the client request information such as the connection IP address, the AD FS endpoint, and HTTP headers sent by the client. For a detailed description of the new claim types and values, see Claim Types.

The following table describes the scenarios supported by the client access policy feature.

 

Scenario Description

Block all external access to Office 365

Office 365 access is allowed from all clients on the internal corporate network, but requests from external clients are denied based on the IP address of the external client.

Block all external access to Office 365, except Exchange ActiveSync

Office 365 access is allowed from all clients on the internal corporate network, as well as from any external client devices, such as smart phones, that make use of Exchange ActiveSync. All other external clients, such as those using Outlook, are blocked.

Block all external access to Office 365, except for browser-based applications such as Outlook Web Access or SharePoint Online

Blocks external access to Office 365, except for passive (browser-based) applications such as Outlook Web Access or SharePoint Online.

Block all external access to Office 365 for members of designated Active Directory groups

This scenario is used for testing and validating client access policy deployment. It blocks external access to Office 365 only for members of one or more Active Directory group. It can also be used to provide external access only to members of a group.

noteNote
The following client access policy scenarios have the effect of blocking external access to Microsoft Lync Online and Office Subscription Services:

  • Scenario 1: Block all external access to Office 365

  • Scenario 2: Block all external access to Office 365 except Exchange ActiveSync

  • Scenario 3: Block all external access to Office 365 except browser-based applications

To enable client access policy in AD FS in Windows Server 2012 R2, you must update the Microsoft Office 365 Identity Platform relying party trust. Choose one of the example scenarios below to configure the claim rules on the Microsoft Office 365 Identity Platform relying party trust that best meets the needs of your organization.

This client access policy scenario allows access from all internal clients and blocks all external clients based on the IP address of the external client. You can use the following procedures to add the correct Issuance Authorization rules to the Office 365 relying party trust for your chosen scenario.

  1. From Server Manager, click Tools, then click AD FS Management.

  2. In the console tree, under AD FS\Trust Relationships, click Relying Party Trusts, right-click the Microsoft Office 365 Identity Platform trust, and then click Edit Claim Rules.

  3. In the Edit Claim Rules dialog box, select the Issuance Authorization Rules tab, and then click Add Rule to start the Claim Rule Wizard.

    noteNote
    If you have never configured any custom Issuance Authorization Rules on the Microsoft Office 365 Identity Platform relying party trust, you will see the default Permit Access to All Users rule. The rules specified below are intended to replace this rule by issuing an “http://schemas.microsoft.com/authorization/claims/permit” claim based on a more specific set of conditions. Once you have finished adding the rules specified below for your scenario, be sure to come back and delete the Permit Access to All Users rule. Otherwise, your client access policy rules will not work.

  4. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule, and then click Next.

  5. On the Configure Rule page, under Claim rule name, type the display name for this rule, for example “Issue custom claim for internal client requests directly to federation server”. Under Custom rule, type or paste the following claim rule language syntax: c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "true"] => issue(Type = "http://custom/allow", Value = "true");

  6. Click Finish. Verify that the new rule appears in the Issuance Authorization Rules list.

  7. Next, in the Edit Claim Rules dialog box, on the Issuance Authorization Rules tab, click Add Rule to start the Claim Rule Wizard again.

  8. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule, and then click Next.

    On the Configure Rule page, under Claim rule name, type the display name for this rule, for example “Issue custom claim based on IP regex”. Under Custom rule, type or paste the following claim rule language syntax:c:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "customer provided public ip address regex"] => issue(Type = "http://custom/allow", Value = "true");

    You will have to replace the value above for “public ip address regex” with a valid IP expression; see Building the IP address range expression for more information.

  9. Click Finish. Verify that the new rule appears immediately below the previous rule in the Issuance Authorization Rules list.

  10. Next, in the Edit Claim Rules dialog box, on the Issuance Authorization Rules tab, click Add Rule to start the Claim Rule Wizard again.

  11. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule, and then click Next.

    On the Configure Rule page, under Claim rule name, type the display name for this rule, for example “Issue permit claim based on the custom claim”. Under Custom rule, type or paste the following claim rule language syntax:c:[Type == "http://custom/allow", Value == "true"] => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

  12. Click Finish. Verify that the new rule appears immediately below the previous rule in the Issuance Authorization Rules list.

  13. If you still have the default Permit Access to All Users rule in the Issuance Authentication Rules list, select it and click Remove Rule. Click Yes to confirm.

  14. To save the new rules, in the Edit Claim Rules dialog box, click OK.

The following example allows access to all Office 365 applications, including Exchange Online, from internal clients including Outlook. It blocks access from clients residing outside the corporate network, as indicated by the client IP address, except for Exchange ActiveSync clients such as smart phones.

  1. From Server Manager, click Tools, then click AD FS Management.

  2. In the console tree, under AD FS\Trust Relationships, click Relying Party Trusts, right-click the Microsoft Office 365 Identity Platform trust, and then click Edit Claim Rules.

  3. In the Edit Claim Rules dialog box, select the Issuance Authorization Rules tab, and then click Add Rule to start the Claim Rule Wizard.

    noteNote
    If you have never configured any custom Issuance Authorization Rules on the Microsoft Office 365 Identity Platform relying party trust, you will see the default “Permit Access to All Users” rule. The rules specified below are intended to replace this rule by issuing an “http://schemas.microsoft.com/authorization/claims/permit” claim based on a more specific set of conditions. Once you have finished adding the rules specified below for your scenario, be sure to come back and delete the “Permit Access to All Users” rule. Otherwise, your client access policy rules will not work.

  4. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule, and then click Next.

  5. On the Configure Rule page, under Claim rule name, type the display name for this rule, for example “Issue custom claim for internal client requests directly to federation server”. Under Custom rule, type or paste the following claim rule language syntax: c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "true"] => issue(Type = "http://custom/allow", Value = "true");

  6. Click Finish. Verify that the new rule appears in the Issuance Authorization Rules list.

  7. Next, in the Edit Claim Rules dialog box, on the Issuance Authorization Rules tab, click Add Rule to start the Claim Rule Wizard again.

  8. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule, and then click Next.

  9. On the Configure Rule page, under Claim rule name, type the display name for this rule, for example “Issue custom claim based on IP regex”. Under Custom rule, type or paste the following claim rule language syntax: c:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "customer provided public ip address regex"] => issue(Type = "http://custom/allow", Value = "true");

    You will have to replace the value above for “public ip address regex” with a valid IP expression; see Building the IP address range expression for more information.

  10. Click Finish. Verify that the new rule appears immediately below the previous rule in the Issuance Authorization Rules list.

  11. Next, in the Edit Claim Rules dialog box, on the Issuance Authorization Rules tab, click Add Rule to start the Claim Rule Wizard again.

  12. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule, and then click Next.

    On the Configure Rule page, under Claim rule name, type the display name for this rule, for example “Issue custom claim based on the presence of the Exchange ActiveSync Header”. Under Custom rule, type or paste the following claim rule language syntax: c:[type=="http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value=="ONE_OF_EXO_CLIENT_APP_VALUES"] => issue(Type = "http://custom/allow", Value = "true");

    WarningWarning
    For more information, see X-MS-Client-Application.

  13. Click Finish. Verify that the new rule appears immediately below the previous rule in the Issuance Authorization Rules list.

  14. Next, in the Edit Claim Rules dialog box, on the Issuance Authorization Rules tab, click Add Rule to start the Claim Rule Wizard again.

  15. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule, and then click Next.

    On the Configure Rule page, under Claim rule name, type the display name for this rule, for example “Issue permit claim based on the custom claim”. Under Custom rule, type or paste the following claim rule language syntax: c:[Type == "http://custom/allow", Value == "true"] => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

  16. Click Finish. Verify that the new rule appears immediately below the previous rule in the Issuance Authorization Rules list.

  17. If you still have the default “Permit Access to All Users” rule in the Issuance Authentication Rules list, select it and click Remove Rule. Click Yes to confirm.

  18. To save the new rules, in the Edit Claim Rules dialog box, click OK.

  1. From Server Manager, click Tools, then click AD FS Management.

  2. In the console tree, under AD FS\Trust Relationships, click Relying Party Trusts, right-click the Microsoft Office 365 Identity Platform trust, and then click Edit Claim Rules.

  3. In the Edit Claim Rules dialog box, select the Issuance Authorization Rules tab, and then click Add Rule to start the Claim Rule Wizard.

    noteNote
    If you have never configured any custom Issuance Authorization Rules on the Microsoft Office 365 Identity Platform relying party trust, you will see the default “Permit Access to All Users” rule. The rules specified below are intended to replace this rule by issuing an “http://schemas.microsoft.com/authorization/claims/permit” claim based on a more specific set of conditions. Once you have finished adding the rules specified below for your scenario, be sure to come back and delete the “Permit Access to All Users” rule. Otherwise, your client access policy rules will not work.

  4. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule, and then click Next.

  5. On the Configure Rule page, under Claim rule name, type the display name for this rule, for example “Issue custom claim for internal client requests directly to federation server”. Under Custom rule, type or paste the following claim rule language syntax:c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "true"] => issue(Type = "http://custom/allow", Value = "true");

  6. Click Finish. Verify that the new rule appears in the Issuance Authorization Rules list.

  7. Next, in the Edit Claim Rules dialog box, on the Issuance Authorization Rules tab, click Add Rule to start the Claim Rule Wizard again.

  8. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule, and then click Next.

    On the Configure Rule page, under Claim rule name, type the display name for this rule, for example “Issue custom claim based on IP regex”. Under Custom rule, type or paste the following claim rule language syntax:c:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "customer provided public ip address regex"] => issue(Type = "http://custom/allow", Value = "true");

    You will have to replace the value above for “public ip address regex” with a valid IP expression; see Building the IP address range expression for more information.

  9. Click Finish. Verify that the new rule appears immediately below the previous rule in the Issuance Authorization Rules list.

  10. Next, in the Edit Claim Rules dialog box, on the Issuance Authorization Rules tab, click Add Rule to start the Claim Rule Wizard again.

  11. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule, and then click Next.

  12. On the Configure Rule page, under Claim rule name, type the display name for this rule, for example “Issue custom claim based on the endpoint”. Under Custom rule, type or paste the following claim rule language syntax:c:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value == "/adfs/ls/"] => issue(Type = "http://custom/allow", Value = "true");

  13. Click Finish. Verify that the new rule appears immediately below the previous rule in the Issuance Authorization Rules list.

  14. Next, in the Edit Claim Rules dialog box, on the Issuance Authorization Rules tab, click Add Rule to start the Claim Rule Wizard again.

  15. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule, and then click Next.

    On the Configure Rule page, under Claim rule name, type the display name for this rule, for example “Issue permit claim based on the custom claim”. Under Custom rule, type or paste the following claim rule language syntax:c:[Type == "http://custom/allow", Value == "true"] => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

  16. Click Finish. Verify that the new rule appears immediately below the previous rule in the Issuance Authorization Rules list.

  17. If you still have the default “Permit Access to All Users” rule in the Issuance Authentication Rules list, select it and click Remove Rule. Click Yes to confirm.

  18. To save the new rules, in the Edit Claim Rules dialog box, click OK.

The following example enables access from internal clients based on IP address. It blocks access from clients residing outside the corporate network that have an external client IP address, except for those individuals in a specified Active Directory Group.Use the following steps to add the correct Issuance Authorization rules to the Microsoft Office 365 Identity Platform relying party trust using the Claim Rule Wizard:

  1. From Server Manager, click Tools, then click AD FS Management.

  2. In the console tree, under AD FS\Trust Relationships, click Relying Party Trusts, right-click the Microsoft Office 365 Identity Platform trust, and then click Edit Claim Rules.

  3. In the Edit Claim Rules dialog box, select the Issuance Authorization Rules tab, and then click Add Rule to start the Claim Rule Wizard.

    noteNote
    If you have never configured any custom Issuance Authorization Rules on the Microsoft Office 365 Identity Platform relying party trust, you will see the default “Permit Access to All Users” rule. The rules specified below are intended to replace this rule by issuing an “http://schemas.microsoft.com/authorization/claims/permit” claim based on a more specific set of conditions. Once you have finished adding the rules specified below for your scenario, be sure to come back and delete the “Permit Access to All Users” rule. Otherwise, your client access policy rules will not work.

  4. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule, and then click Next.

  5. On the Configure Rule page, under Claim rule name, type the display name for this rule, for example “Issue custom claim for internal client requests directly to federation server”. Under Custom rule, type or paste the following claim rule language syntax:c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "true"]=> issue(Type = "http://custom/allow", Value = "true");

  6. Click Finish. Verify that the new rule appears in the Issuance Authorization Rules list.

  7. Next, in the Edit Claim Rules dialog box, on the Issuance Authorization Rules tab, click Add Rule to start the Claim Rule Wizard again.

  8. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule, and then click Next.

  9. On the Configure Rule page, under Claim rule name, type the display name for this rule, for example “Issue custom claim based on IP regex”. Under Custom rule, type or paste the following claim rule language syntax:c:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "customer provided public ip address regex"] => issue(Type = "http://custom/allow", Value = "true");

    You will have to replace the value above for “public ip address regex” with a valid IP expression; see Building the IP address range expression for more information.

  10. Click Finish. Verify that the new rule appears immediately below the previous rule in the Issuance Authorization Rules list.

  11. Next, in the Edit Claim Rules dialog box, on the Issuance Authorization Rules tab, click Add Rule to start the Claim Rule Wizard again.

  12. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule, and then click Next.

  13. On the Configure Rule page, under Claim rule name, type the display name for this rule, for example “Issue custom claim based on presence of AD group SID”. Under Custom rule, type or paste the following claim rule language syntax:c:[type=="http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value=="S-1-5-21-913475896-37678304-286007319-2105"] => issue(Type = "http://custom/allow", Value = "true");

  14. Click Finish. Verify that the new rule appears immediately below the previous rule in the Issuance Authorization Rules list.

  15. Next, in the Edit Claim Rules dialog box, on the Issuance Authorization Rules tab, click Add Rule to start the Claim Rule Wizard again.

  16. On the Select Rule Template page, under Claim rule template, select Send Claims Using a Custom Rule, and then click Next.

  17. On the Configure Rule page, under Claim rule name, type the display name for this rule, for example “Issue permit claim based on the custom claim”. Under Custom rule, type or paste the following claim rule language syntax:c:[Type == "http://custom/allow", Value == "true"] => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

  18. Click Finish. Verify that the new rule appears immediately below the previous rule in the Issuance Authorization Rules list.

  19. If you still have the default “Permit Access to All Users” rule in the Issuance Authentication Rules list, select it and click Remove Rule. Click Yes to confirm.

  20. To save the new rules, in the Edit Claim Rules dialog box, click OK.

The x-ms-forwarded-client-ip claim is populated from an HTTP header that is currently set only by Exchange Online, which populates the header when passing the authentication request to AD FS. The value of the claim may be one of the following:

noteNote
Exchange Online currently supports only IPV4 and not IPV6 addresses.

  • A single IP address: The IP address of the client that is directly connected to Exchange Online

    noteNote
    • The IP address of a client on the corporate network will appear as the external interface IP address of the organization’s outbound proxy or gateway.

    • Clients that are connected to the corporate network by a VPN or by Microsoft DirectAccess (DA) may appear as internal corporate clients or as external clients depending upon the configuration of VPN or DA.

  • One or more IP addresses: When Exchange Online cannot determine the IP address of the connecting client, it will set the value based on the value of the x-forwarded-for header, a non-standard header that can be included in HTTP-based requests and is supported by many clients, load balancers, and proxies on the market.

    noteNote
    • Multiple IP addresses, indicating the client IP address and the address of each proxy that passed the request, will be separated by a comma.

    • IP addresses related to Exchange Online infrastructure will not on the list.

When you have to match a range of IP addresses, it becomes necessary to construct a regular expression to perform the comparison. In the next series of steps, we will provide examples for how to construct such an expression to match the following address ranges (note that you will have to change these examples to match your public IP range):

  • 192.168.1.1 – 192.168.1.25

  • 10.0.0.1 – 10.0.0.14

First, the basic pattern that will match a single IP address is as follows: \b###\.###\.###\.###\b

Extending this, we can match two different IP addresses with an OR expression as follows: \b###\.###\.###\.###\b|\b###\.###\.###\.###\b

So, an example to match just two addresses (such as 192.168.1.1 or 10.0.0.1) would be: \b192\.168\.1\.1\b|\b10\.0\.0\.1\b

This gives you the technique by which you can enter any number of addresses. Where a range of address need to be allowed, for example 192.168.1.1 – 192.168.1.25, the matching must be done character by character: \b192\.168\.1\.([1-9]|1[0-9]|2[0-5])\b

noteNote
The IP address is treated as string and not a number.

The rule is broken down as follows: \b192\.168\.1\.

This matches any value beginning with 192.168.1.

The following matches the ranges required for the portion of the address after the final decimal point:

  • ([1-9] Matches addresses ending in 1-9

  • |1[0-9] Matches addresses ending in 10-19

  • |2[0-5]) Matches addresses ending in 20-25

noteNote
Note that the parentheses must be correctly positioned, so that you don’t start matching other portions of IP addresses.

With the 192 block matched, we can write a similar expression for the 10 block: \b10\.0\.0\.([1-9]|1[0-4])\b

And putting them together, the following expression should match all the addresses for “192.168.1.1~25” and “10.0.0.1~14”: \b192\.168\.1\.([1-9]|1[0-9]|2[0-5])\b|\b10\.0\.0\.([1-9]|1[0-4])\b

Regex expressions can become quite tricky, so we highly recommend using a regex verification tool. If you do an internet search for “online regex expression builder”, you will find several good online utilities that will allow you to try out your expressions against sample data.

When testing the expression, it’s important that you understand what to expect to have to match. The Exchange online system may send many IP addresses, separated by commas. The expressions provided above will work for this. However, it’s important to think about this when testing your regex expressions. For example, one might use the following sample input to verify the examples above:

192.168.1.1, 192.168.1.2, 192.169.1.1. 192.168.12.1, 192.168.1.10, 192.168.1.25, 192.168.1.26, 192.168.1.30, 1192.168.1.20

10.0.0.1, 10.0.0.5, 10.0.0.10, 10.0.1.0, 10.0.1.1, 110.0.0.1, 10.0.0.14, 10.0.0.15, 10.0.0.10, 10,0.0.1

AD FS in Windows Server 2012 R2 provides request context information using the following claim types:

Claim type: http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip

This AD FS claim represents a “best attempt” at ascertaining the IP address of the user (for example, the Outlook client) making the request. This claim can contain multiple IP addresses, including the address of every proxy that forwarded the request.  This claim is populated from an HTTP. The value of the claim can be one of the following:

  • A single IP address - The IP address of the client that is directly connected to Exchange Online

    noteNote
    The IP address of a client on the corporate network will appear as the external interface IP address of the organization’s outbound proxy or gateway.

  • One or more IP addresses

    • If Exchange Online cannot determine the IP address of the connecting client, it will set the value based on the value of the x-forwarded-for header, a non-standard header that can be included in HTTP based requests and is supported by many clients, load balancers, and proxies on the market.

    • Multiple IP addresses indicating the client IP address and the address of each proxy that passed the request will be separated by a comma.

      noteNote
      IP addresses related to Exchange Online infrastructure will not be present in the list.

WarningWarning
Exchange Online currently supports only IPV4 addresses; it does not support IPV6 addresses.

Claim type: http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application

This AD FS claim represents the protocol used by the end client, which corresponds loosely to the application being used.  This claim is populated from an HTTP header that is currently only set by Exchange Online, which populates the header when passing the authentication request to AD FS. Depending on the application, the value of this claim will be one of the following:

  • In the case of devices that use Exchange Active Sync, the value is Microsoft.Exchange.ActiveSync.

  • Use of the Microsoft Outlook client may result in any of the following values:

    • Microsoft.Exchange.Autodiscover

    • Microsoft.Exchange.OfflineAddressBook

    • Microsoft.Exchange.RPC

    • Microsoft.Exchange.WebServices

  • Other possible values for this header include the following:

    • Microsoft.Exchange.Powershell

    • Microsoft.Exchange.SMTP

    • Microsoft.Exchange.PopImap

Claim type: http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-user-agent

This AD FS claim provides a string to represent the device type that the client is using to access the service. This can be used when customers would like to prevent access for certain devices (such as particular types of smart phones).  Example values for this claim include (but are not limited to) the values below.

noteNote
The below are examples of what the x-ms-user-agent value might contain for a client whose x-ms-client-application is “Microsoft.Exchange.ActiveSync”

  • Vortex/1.0

  • Apple-iPad1C1/812.1

  • Apple-iPhone3C1/811.2

  • Apple-iPhone/704.11

  • Moto-DROID2/4.5.1

  • SAMSUNGSPHD700/100.202

  • Android/0.3

noteNote
It is also possible that this value is empty.

Claim type: http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy

This AD FS claim indicates that the request has passed through the Web Application proxy.  This claim is populated by the Web Application proxy, which populates the header when passing the authentication request to the back end Federation Service. AD FS then converts it to a claim.

The value of the claim is the DNS name of the Web Application proxy that passed the request.

Claim type: http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork

Similar to the above x-ms-proxy claim type, this claim type indicates whether the request has passed through the web application proxy. Unlike x-ms-proxy, insidecorporatenetwork is a boolean value with True indicating a request directly to the federation service from inside the corporate network.

Claim type: http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path

This claim type can be used for determining requests originating from “active” (rich) clients versus “passive” (web-browser-based) clients. This enables external requests from browser-based applications such as the Outlook Web Access, SharePoint Online, or the Office 365 portal to be allowed while requests originating from rich clients such as Microsoft Outlook are blocked.

The value of the claim is the name of the AD FS service that received the request.

See Also

Concepts

AD FS Operations

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft