Azure AD Judgment when InsideCorporateNetwork Claim with ADFS is Used

Hello Team,

Ahmad Yasin

Today we will go through a small topic but very important one. This article will explain some scenarios where InsideCorporateNetwork claim may behave in unexpected way.

before going deeply in some scenarios, let’s start by explaining in which scenarios InsideCorporateNetwork are used, typically when your domain is federated and you have AD FS on-premises, Azure AD will traffic all Authentication request to AD FS (Externally through WAP) in order to get a token to allow user to Authenticate as Azure AD has no info about the user credentials.

Some customers preferred to take an action based on where is the user connecting from, for example the customer may have an azure conditional access that require the user to pass the MFA Challenge such as phone call after the user passed the primary authentication method like username/Password. In some scenarios customer prefer to ask for MFA for example if the users only connecting from outside the corporate network as they believe that connecting from the internal corporate network does not need MFA since they are sure no un-authorized person is connecting internally which make sense.

In this article we are talking about Modern Authentication, we are not discussing legacy Authentication protocol, if you have no experience with these Authentication types, read this article which describe in some parts the meaning of these Authentication types:

To make the scenario more clear, let’s take a real example, assuming that the scenario as below:

1- Target service is Exchange online.

2- User is using Outlook client.

3- Domain is and the domain is federated with AD FS.

Simply, let’s assume the requirements are below:

1- if the user is connecting from external network then Azure MFA will be triggered.

2- if the user is connecting from internal network, then MFA should NOT be triggered.


Additional info of creating InsideCorporateNetwork can be found in my previous article:

one of the easiest way to create such policy is using azure conditional access, we can target all users or some users as requested, then Target EXO as an app as below:

Select the target Users:


Select the target App, in our scenario it’s EXO:


Now, under location, for simplicity let’s include Any Location:


Now under the exclude, we will select All Trusted locations:


The control will be MFA as below:


In this Article we will not discuss more about conditional access, if you are not familiar with conditional access, you can read this:


Now, the CA we just created, will simply ask for MFA if the user is trying to access EXO from any location except trusted location, it’s very important to understand what All Trusted Locations means 🙂

Trusted locations in Azure can be determined in many ways, most popular ways listed below:

1- Named location configured in Azure, we will not use it this article as it’s not our topic and for simplicity , for more info about this please make sure to read this: this is what we recommend currently.

2- From MFA portal in Azure you can configure some trusted public IP’s, we will not use this also here in this article for simplicity, you can read this article for more information:

3- by InsideCorporateNetwork claim sent by AD FS, this is our main topic for today so let’s deep dive on this.


InsideCorporateNetwork is determined by AD FS and has a value of True or False, if AD FS set this value to True, then this means that AD FS receive the Authentication request directly and the request will be considered as internal request, this does not means that the user is physically located in the office, for example if the customer publish the AD FS directly to the internet then InsideCorporateNetwork will always will be true as the connections will always hit the AD FS directly. In the other hand, if the connection hit the WAP first then InsideCorporateNetwork will be set to False, the same note here, if customer force all internal users going through WAP (Maybe DNS incorrect config) then the value of this claim will be always be False even the user physically located in the corporate network.


Understanding How Azure Deal with this claim.

let’s imagine that user connect from his outlook to EXO, the first time outlook is connecting, Azure will redirect the Authentication request to AD FS, AD FS will ask for credentials, if the credentials are correct, then AD FS will issue a token, this token will include some claims including the InsideCorporateNetwork and it’s value.

This Article will not describe the Meaning of the tokens and claims as we assumed you already know this, if this is not the case then please use Ping and you will get a huge results to understand it.


Now, let’s take two scenarios to make the concept more clear: user A is connecting from the company and then from His home:

let’s assume the user is connecting from the corporate network, then when Azure AD redirecting the Authentication request to AD FS, AD FS after verifying the credentials with local AD, it will issue a token which will be presented to Azure AD to get an access, in this scenario the token will look like below:


In Azure AD side, Token will be received, there is a process to validate the token, if it’s OK Azure AD will accept it and check the claims, one of the claims Azure AD care about is the InsideCorporateNetwork  claim value, in this case it’s True, hence the conditional access we created will not be applied and MFA will NOT be triggered as we consider this as trusted location.

the Azure AD will issue two types of token, Refresh token and Access token, this is a very huge topic and we will not discuss it here, but it’s very important to make sure you understand it, here are the details:

As a quick overview of the tokens definition:

Refresh Token: A refresh token is good for 14 to 90 days. An unused refresh token will expire in 14 days, regular use will extend expiration to up to 90 days.

Access / Bearer Token: An access token is good for one hour. Once the token expires the refresh token is used to request a new access token from EVOSTS. The customer’s IDP (ADFS) server is not contacted.

After above token issued the user will be able to access EXO services.

What will happen in background in Azure AD:

In this article we care about two values here:

1- Azure AD will know the source Public IP where the request came from, in this scenario the Company Public IP.

2- Azure AD will save the InsideCorporateNetwork claim value in the refresh token.


Now, let’s imagine that the user after two days tried to open his outlook again, assuming you totally understand the concept of refresh and access token, then outlook will try to use the same refresh token, below what the general points that Azure AD will check:

1- Azure AD will check if the refresh token still valid, usually refresh token has a 90 days validity in the normal scenario.

2- Azure AD will check if the refresh token got revoked for any reason, such like user changed his password recently or the admin for some reason revoke it, then Azure AD will not accept the refresh token, below are the main causes why the refresh token may got revoked from MS site:


let’s assume the two scenarios, if the refresh token is still valid, then Azure AD will allow the user to Access the resources WITHOUT ask the user to reauthenticate, this means that the AD FS will not be used at all and no credentials required, even if AD FS is completely down the user will be able to connect.

if the refresh token got revoked or expired, then Azure AD will ask the user to reauthenticate again, this means that the whole authentication process will happening again, the user will be redirected to AD FS, got a token, send it to azure AD, if the token verified and got accepted, Azure AD will issue a new refresh and access token.


Now the question where the article is written for, what if the user moved to his home? usually we should expect that based on our conditional access MFA should be triggered when user opened his outlook since CA saying that MFA will be skipped only if the user connecting from internal network which is not the case from the user Home … Good Question ….

the problem here, that when the user is trying to connect from his home, then the outlook will try to use the same refresh token issued when the user was in the corporate network, if the refresh token is not expired or not revoked then for Azure AD it’s a valid one, hence Azure AD will not ask for reauthenticate, this means that AD FS will not be involved at this point, adding to this that this refresh token already has the InsideCorporateNetwork set to True, Then Azure AD as a result will not trigger MFA since it’s still appearing that the connection coming from trusted location … that’s not good.

Azure AD has only one way to trigger MFA in this scenario, Azure AD already know the source Public IP for the Authentication request where originally issued that refresh token for.

Azure AD will keep assuming that the request is coming from trusted locations as long as the refresh token is valid unless the connection coming from different public IP …. confusing … for sure the user home public IP is different than the company, but wait Azure AD will do the best guess, means if the first 3 octet from the source public IP got changed then Azure AD will consider that the user now may connecting from un-trusted location where MFA should be applied, hence InsideCorporateNetwork will be set to false by default which will trigger MFA again based on the CA configuration.



Using InsideCorporateNetwork claim to make Azure AD judge may cause some unexpected behavior, the only way for Azure AD to re-evaluate this claim are the flowing:

1- if one of the first three octets of the source public IP got changed, InsideCorporateNetwork will be set to False again automatically. Conditional access will be re-evaluated. in some scenarios we see that these three octets got changed frequently which cause MFA to be triggered very often – Not a good user experience.

2- if the refresh token got expired or revoked, this is by default will make Azure AD ask for re-authenticate, AD FS will issue the claim with it’s value based if the connection hitting the AD FS directly or the WAP. based on the result MFA may got triggered or not.


Ahmad Yasin

Ahmad Yasin (MCSA office 365, MCSE, Messaging, Azure certified)

Ahmad Yasin is a Microsoft Cloud Engineer and the Owner & publisher of AzureDummies blog. He also holds many certificates in office 365 and windows azure including Developing Microsoft Azure Solutions, Implementing Microsoft Azure Infrastructure Solutions and MCSA office 365.

Find Ahmad at Facebook and LinkedIn.



  1. There is one more way to force authentication and that is to expire the Access token. You can create a policy and then apply the policy to a particular application.

    1. $policy = New-AzureADPolicy -Definition @(‘{“TokenLifetimePolicy”:{“Version”:1,”AccessTokenLifetime”:”00:10:00″,”MaxAgeSessionSingleFactor”:”00:10:00″,”MaxInactiveTime”:”00:10:00″,”MaxAgeMultiFactor”:”until-revoked”,”MaxAgeSingleFactor”:”00:10:00″}}’) -DisplayName “CiscoAnyConnect” -IsOrganizationDefault $false -Type “TokenLifetimePolicy”

    2.Get-AzureADPolicy -Id $policy.Id

    3. Get-AzureADServicePrincipal -objectid

    4. $sp = Get-AzureADServicePrincipal -objectid

    5. Add-AzureADServicePrincipalPolicy -Id $sp.ObjectId -RefObjectId $policy.Id

  2. Hi Ahmad,

    Not sure if you are still monitoring this post, but I have a customer where 2 factor is not working at all if the Skip multi-factor authentication for requests from federated users on my intranet is set.

    The it skips 2 factor all the time and in user signin logs the reason is the ADFS claim “InsideCorporateNetwork”

    Result detail:

    MFA requirement skipped due to ADFS-issued InsideCorpNet claim; tenant was configured to skip MFA if this claim is present.

    Even when I login from different device on a different network which is not corperate and the 3 first octets are different still it skips 2 factor.

    So only by removing this tick 2 factor works correct, which is kind of ok as it still skips it for trusted IP’s, but does not skip it if user is connected by VPN which they would want as that is the same as them being on corperate network, thou public IP is different so it requires MFA.

    Maybe you have some ideas here?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.