Blog Office 365 Windows Azure

Azure AD Judgment when InsideCorporateNetwork Claim with ADFS is Used – Azure Dummies

Whats up Group,

At present we’ll undergo a small matter however essential one. This article will clarify some situations the place InsideCorporateNetwork claim might behave in sudden means.

earlier than going deeply in some situations, let’s begin by explaining by which situations InsideCorporateNetwork are used, sometimes when your domain is federated and you’ve got AD FS on-premises, Azure AD will visitors all Authentication request to AD FS (Externally via WAP) with a purpose to get a token to allow consumer to Authenticate as Azure AD has no information concerning the consumer credentials.

Some clients most popular to take an motion based mostly on where is the consumer connecting from, for example the client might have an azure conditional access that require the consumer to move the MFA Challenge corresponding to telephone name after the consumer handed the first authentication technique like username/Password. In some situations buyer favor to ask for MFA for example if the customers only connecting from outdoors the corporate community as they consider that connecting from the interior company network doesn’t want MFA since they’re positive no un-authorized individual is connecting internally which make sense.

In this article we’re speaking about Trendy Authentication, we aren’t discussing legacy Authentication protocol, when you’ve got no expertise with these Authentication varieties, read this article which describe in some elements the which means of these Authentication varieties: https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/enable-or-disable-modern-authentication-in-exchange-online

To make the state of affairs extra clear, let’s take a real instance, assuming that the state of affairs as under:

1- Goal service is Trade on-line.

2- Consumer is using Outlook shopper.

Three- Domain is xyz.com and the domain is federated with AD FS.

Merely, let’s assume the necessities are under:

1- if the consumer is connecting from exterior community then Azure MFA can be triggered.

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

Additional information of creating InsideCorporateNetwork might be found in my previous article: http://azuredummies.com/2017/10/09/azure-conditional-access-with-skip-mfa-for-requests-from-federated-users-on-my-intranet-option-scenarios/

one of many best solution to create such policy is utilizing azure conditional access, we will goal all customers or some customers as requested, then Target EXO as an app as under:

Choose the target Users:

Select the goal App, in our state of affairs it’s EXO:

Now, beneath location, for simplicity let’s embrace Any Location:

Now underneath the exclude, we’ll select All Trusted places:

The management will probably be MFA as under:

In this Article we won’t talk about extra about conditional entry, in case you are not familiar with conditional entry, you possibly can learn this: https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview

Now, the CA we simply created, will merely ask for MFA if the consumer is making an attempt to access EXO from any location except trusted location, it’s essential to know what All Trusted Places means 🙂

Trusted places in Azure might be determined in many ways, hottest methods listed under:

1- Named location configured in Azure, we won’t use it this text as it’s not our matter and for simplicity , for more information about this please make certain to learn this: https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/location-condition this is what we advocate presently.

2- From MFA portal in Azure you possibly can configure some trusted public IP’s, we won’t use this also here on this article for simplicity, you possibly can read this text for more info: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-mfasettings#mfa-service-settings

Three- by InsideCorporateNetwork claim despatched by AD FS, this is our foremost matter for as we speak so let’s deep dive on this.

InsideCorporateNetwork is decided by AD FS and has a worth of True or False, if AD FS set this value to True, then because of this AD FS receive the Authentication request instantly and the request might be thought-about as inner request, this doesn’t signifies that the consumer is bodily situated in the workplace, for example if the client publish the AD FS directly to the internet then InsideCorporateNetwork will all the time can be true as the connections will all the time hit the AD FS instantly. Within the other hand, if the connection hit the WAP first then InsideCorporateNetwork might be set to False, the identical word right here, if customer pressure all inner customers going via WAP (Perhaps DNS incorrect config) then the worth of this claim shall be all the time be False even the consumer physically situated in the company community.

Understanding How Azure Deal with this declare.

let’s imagine that consumer 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 right, then AD FS will challenge a token, this token will embrace some claims including the InsideCorporateNetwork and it’s worth.

This Article won’t describe the Which means of the tokens and claims as we assumed you already know this, if this is not the case then please use Ping and you’ll get an enormous results to know it.

Now, let’s take two situations to make the idea more clear: consumer A is connecting from the corporate after which from His residence:

let’s assume the consumer is connecting from the corporate community, then when Azure AD redirecting the Authentication request to AD FS, AD FS after verifying the credentials with local AD, it can difficulty a token which can be introduced to Azure AD to get an entry, in this state of affairs the token will seem like under:

In Azure AD aspect, Token might be acquired, there is a process to validate the token, if it’s OK Azure AD will accept it and examine the claims, one of many claims Azure AD care about is the InsideCorporateNetwork  declare value, on this case it’s True, hence the conditional entry we created won’t be utilized and MFA will NOT be triggered as we contemplate this as trusted location.

the Azure AD will situation two kinds of token, Refresh token and Entry token, this is a very big matter and we won’t talk about it right here, however it’s essential to be sure to understand it, listed here are the small print: https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-configurable-token-lifetimes

As a fast 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 prolong expiration to as much as 90 days.

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

After above token issued the consumer will be capable of entry EXO providers.

What is going to happen in background in Azure AD:

In this article we care about two values right here:

1- Azure AD will know the source Public IP the place the request came from, on this state of affairs the Firm Public IP.

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

Now, let’s imagine that the consumer after two days tried to open his outlook again, assuming you completely understand the idea of refresh and entry token, then outlook will attempt to use the same refresh token, under what the overall factors that Azure AD will verify:

1- Azure AD will examine if the refresh token nonetheless valid, often refresh token has a 90 days validity within the normal state of affairs.

2- Azure AD will examine if the refresh token obtained revoked for any purpose, such like consumer changed his password lately or the admin for some purpose revoke it, then Azure AD won’t accept the refresh token, under are the primary causes why the refresh token might acquired revoked from MS website:

let’s assume the 2 situations, if the refresh token is still legitimate, then Azure AD will permit the consumer to Access the assets WITHOUT ask the consumer to reauthenticate, because of this the AD FS won’t be used in any respect and no credentials required, even when AD FS is utterly down the consumer will have the ability to connect.

if the refresh token obtained revoked or expired, then Azure AD will ask the consumer to reauthenticate again, because of this the whole authentication course of will occurring once more, the consumer shall be redirected to AD FS, received a token, ship it to azure AD, if the token verified and received accepted, Azure AD will concern a brand new refresh and entry token.

Now the question where the article is written for, what if the consumer moved to his residence? often we should always anticipate that based mostly on our conditional entry MFA must be triggered when consumer opened his outlook since CA saying that MFA shall be skipped provided that the consumer connecting from inner network which is not the case from the consumer House … Good Query ….

the issue here, that when the consumer is making an attempt to connect from his house, then the outlook will try to use the identical refresh token issued when the consumer was in the corporate community, if the refresh token is not expired or not revoked then for Azure AD it’s a legitimate one, hence Azure AD won’t ask for reauthenticate, which means AD FS won’t be concerned at this point, adding to this that this refresh token already has the InsideCorporateNetwork set to True, Then Azure AD consequently won’t trigger MFA since it’s still appearing that the connection coming from trusted location … that’s not good.

Azure AD has just one strategy to set off MFA in this state of affairs, Azure AD already know the source Public IP for the Authentication request the place initially issued that refresh token for.

Azure AD will maintain assuming that the request is coming from trusted places so long as the refresh token is legitimate until the connection coming from totally different public IP …. confusing … for positive the consumer residence public IP is totally different than the corporate, but wait Azure AD will do the most effective guess, means if the primary 3 octet from the supply public IP received modified then Azure AD will think about that the consumer now might connecting from un-trusted location the place MFA ought to be utilized, therefore InsideCorporateNetwork might be set to false by default which can trigger MFA once more based mostly on the CA configuration.

Conclusion:

Utilizing InsideCorporateNetwork declare to make Azure AD decide might cause some sudden conduct, the only method for Azure AD to re-evaluate this declare are the flowing:

1- if one of many first three octets of the source public IP acquired changed, InsideCorporateNetwork shall be set to False again routinely. Conditional access might be re-evaluated. in some situations we see that these three octets received changed regularly which trigger MFA to be triggered fairly often – Not a great consumer experience.

2- if the refresh token received expired or revoked, this is by default will make Azure AD ask for re-authenticate, AD FS will concern the declare with it’s value based mostly if the connection hitting the AD FS instantly or the WAP. based mostly on the outcome MFA might acquired triggered or not.

<img data-attachment-id="11" data-permalink="http://azuredummies.com/about-blogger/pp/" data-orig-file="https://i0.wp.com/azuredummies.com/wp-content/uploads/2015/07/PP.png?fit=152%2C187" data-orig-size="152,187" data-comments-opened="0" data-image-meta=""aperture":"zero","credit score":"","digital camera":"","caption":"","created_timestamp":"zero","copyright":"","focal_length":"0","iso":"zero","shutter_speed":"zero","title":"","orientation":"zero"" data-image-title="Ahmad Yasin" data-image-description="

Ahmad Yasin

” data-medium-file=”https://i0.wp.com/azuredummies.com/wp-content/uploads/2015/07/PP.png?fit=152%2C187″ data-large-file=”https://i0.wp.com/azuredummies.com/wp-content/uploads/2015/07/PP.png?fit=152%2C187″ class=”size-full wp-image-11″ src=”https://i0.wp.com/azuredummies.com/wp-content/uploads/2015/07/PP.png?resize=152%2C187″ alt=”Ahmad Yasin” width=”152″ peak=”187″ data-recalc-dims=”1″/>

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

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

Discover Ahmad at Fb and LinkedIn.

Categories