Azure MFA on-premise Server 8.x Version – Mobile App Service managed by Azure Back-end Now.

Hello All,

Recently, Azure MFA on-premises server 8.x version was released, in this version we have a very important improvement as below, and most likely we may receive some cases from our customers the design totally changed which may surprise our customers J J, find below notes from my lab:

 

“Installation of the mobile app web service is not necessary for v8.0 or higher. Complete only the steps under Configure the mobile app”

 

https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfaserver-deploy-mobileapp#install-the-mobile-app-web-service

 

I tried this in my lab as no additional info in the documents and below are my observations:

 

  1. The mobile App service will be enabled by default and it’s managed by our back-end, no any additional configurations are required, anyone tried to configure the Mobile APP service in previous version know what a headache that we had J
  2. In the MFA console, there is no option to configure the mobile APP URL as again it’s configured and managed in our backend automatically:

3. In MFA console, if you try manually to generate the code for mobile APP, it will generate a public URL for our back-end and this is why we said it’s managed by MS in the new versions of MFA:

 

4. If the customer installed the user portal, then by default the user can generate and scan the QR code, and below show the public URL for our back-end also (no additional configurations required):

 

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.

 

Secure Azure Gateway Radius Authentication with Azure MFA NPS Extension/MFA Server

Hello All,

Ahmad Yasin

It’s a new year and here it’s very Rainy day with fog, under these weather conditions i am happy to share below info.

Recently, Microsoft announced that Azure Gateway supported for Radius authentication and we start expecting that some customers will start looking in how to secure this connection using Azure MFA ( Since Azure MFA support to secure radius connections).

In this article, we will go through the steps in how to secure this Gateway radius authentication and how to setup it from both sides, MFA and Azure Gateway.

I am not a specialist in Azure Networking, but i followed below article to deploy the Gateway to do this lab and deliver this article to you:

https://docs.microsoft.com/en-us/azure/vpn-gateway/point-to-site-how-to-radius-ps#2-a-nameradiusaset-up-your-radius-server

in addition to above article, i will go quickly through the steps i did with screenshots ( as MS article used power-shell commands only):

The first step after you created the virtual Network in azure, you need to create a Gateway subnet, if you didn’t do that, just click in the Gateway subnet button and create new one by choosing the subnet address as below:

Now, Search for Virtual Network Gateway and create new one ( assuming you didn’t have a gateway, otherwise you can skip these steps). Click Create button from below page:

Choose any name for the gateway, Make sure that you selected the Gateway type to be VPN and the VPN type to be Route-Based, this is a required configuration to allow gateway to work with radius authentication as mentioned in the article i shared above, then choose the SKU type based on your requirements, Finally Click in Virtual Network and select the virtual network which we created the Gateway subnet on it in previous steps, Click Create button:


Till this steps, we have a virtual network and we configured the basic setting for Gateway.

Let’s skip now for the MFA Part, in Azure MFA we have currently two deployments model as below:

1- Full MFA on-premise deployment, in this type you will deploy the MFA with full features, i already explained how to deploy this in previous articles, see http://azuredummies.com/2016/02/06/secure-terminal-services-rdp-using-azure-multi-factor-authentication-mfa-part-2/

2- MFA NPS Extension model: in this deployment you will install the Extension only, noting that this model supporting Radius authentication only, Also i already explained about this, see http://azuredummies.com/2017/07/01/securing-rdp-connection-using-azure-mfa-for-windows-2012-r22016/

Official MS documentation for both Models deployment can be found below:

Full MFA server deployment: https://docs.microsoft.com/en-us/azure/multi-factor-authentication/multi-factor-authentication-get-started-server
MFA NPS Deployment: https://docs.microsoft.com/en-us/azure/multi-factor-authentication/multi-factor-authentication-nps-extension ; make sure to go through the steps here to deploy the MFA NPS extension as i will assume in next part that you already did this step.

Which deployment you should choose to work with Azure Gateway Radius Authentication:

The good question here, which deployment to choose, the answer is very simple and it depends.

Basically, if you don’t have any MFA deployment i recommend you to use the MFA NPS model as it support the Radius authentication.

Now, if you have an existing MGA NPS then you can use it without the need to deploy new one, but what if you have MFA full server deployment in your environment and you need to use it ?! GOOD QUESTION … The answer is: YOU CAN USE IT, but when it come to configure the Radius client in MFA Full server deployment, you need to enter the IP of Radius client, in Azure Gateway Radius Authentication, the IP of the Radius will be the gateway subnet (not only one IP), the question here, what is the problem with that !

Assume that when you created the Gateway subnet you chose it to be 192.168.10.0./16, this means you have 2^16 IP’s, in this case and if you use MFA full deployment, then you need to enter these IP’s manually as a radius client in MFA console (Under Radius configuration) because simply till the time of this article MFA not support Subnets in Radius client configuration, only one IP per radius client.

Now, this issue not exist in MFA NPS extension, because in this model you can enter a subnet instead of single IP as radius client in one shot instead of entering all IP’s manually, this is why we recommend this model for now.

Note: if you have a gateway subnet include small number of IP’s then it should not be an issue to enter these IP’s manually even in MFA full deployment model.

MFA NPS Extension configuration:

In this article we decided to use the MFA NPS extension, i am assuming you followed the article i shared above and you have MFA extension installed with NPS role, now open the NPS console as right click on Radius Clients then click in New option as below:

Enter any friendly name for the Radius client, then it asks for the Address, here you want to enter the gateway subnet of Azure Gateway that we created at the first of this article, as you see here that we can enter the whole subnet at one shot using the prefix /24 for example (This is not availble in MFA full deployment), finally choose any secret key and remember it as we will use it later on, as below:

in the advance tab, make sure we have below configuration, finally click Ok to close this box:

Now, go to Network Policies section, the default policy will Deny access for all as you see below, double click on the first policy:

Choose Grant Access instead of Deny one, then click Ok:

Now, the MFA NPS is ready …

 

Azure Gateway Radius Configuration:

Now. it’s the time to configure the Radius in Azure gateway, again just make sure that the gateway type is VPN and the VPN type is Route-Based, then click in point to site configuration (we will discuss only point to site in this article):

In the address pool, i chose the same Gateway subnet, make sure to select the Radius authentication under authentication type, under server IP address enter the IP of the MFA NPS server, then enter the secret key that we created previously in the NPS console then click save, now from the green box you can install the VPN client:

After you installed the VPN client in your machine, open control panel -> Network Connections, double click on the VPN client as below:

 

Enter the username and the password, it will start connect and you will receive the MFA challenge:

when using MFA NPS extensions, the users should be in azure AD ( Synced or cloud only) and the user should already completed the proof up process for MFA, users can complete the proof up process using https://myapps.microsoft.com or aka.ms/MFASetup.

Prepare for users that aren’t enrolled for MFA

For testing scenarios, where you need to enable MFA with Radius authentication, maybe some of users or all of them still not enrolled in MFA service, in that case you can use below approach to apply it only for the enrolled users while allow other users to use the gateway without MFA (Remember: NO MFA = NO Security).

If you have users that aren’t enrolled for MFA, you can determine what happens when they try to authenticate. Use the registry setting REQUIRE_USER_MATCH in the registry path HKLM\Software\Microsoft\AzureMFA to control the feature behavior. This setting has a single configuration option:

Key Value Default
REQUIRE_USER_MATCH TRUE/FALSE Not set (equivalent to TRUE)

The purpose of this setting is to determine what to do when a user is not enrolled for MFA. When the key does not exist, is not set, or is set to TRUE, and the user is not enrolled, then the extension fails the MFA challenge. When the key is set to FALSE and the user is not enrolled, authentication proceeds without performing MFA. If a user is enrolled in MFA, they must authenticate with MFA even if REQUIRE_USER_MATCH is set to FALSE.

You can choose to create this key and set it to FALSE while your users are onboarding, and may not all be enrolled for Azure MFA yet. However, since setting the key permits users that aren’t enrolled for MFA to sign in, you should remove this key before going to production.

If you are using full MFA server deployment, then you need to enable Radius authentication, add all gateway subnet IP’s one by one as it will not work if you are using the prefix as below, also don’t forget to configure the target tab also

 

 

 

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.

Azure Conditional Access with “Skip MFA for Requests From Federated users on my intranet” option – Scenarios

Hello All,

In this Short article, I will explain some scenarios for enabling Conditional Access For MFA, Recently i start to  see a lot of customers using Azure Condition Access (CA) For MFA, The most scenario i saw that after enabling Azure CA for MFA and if the Environment is federated (AD FS deployed) then MFA not skipped for internal users assuming that Skip MFA for Requests From Federated users on my intranet” is enabled in MFA portal.

 

First of all, before discussing the Scenarios, You need to have Office 365 as relying party in AD FS, also you need to make sure that AD FS issuing the insidecorporatenetwork claim as below:

 

if you don’t have this claim, you can simply add it, below is the syntax:

c:[Type == “http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork”]
=> issue(claim = c);

If you are looking in how to federate your domain with AD FS, refer to this good article: https://blogs.technet.microsoft.com/rmilne/2017/04/28/how-to-install-ad-fs-2016-for-office-365/

 

Assuming that AD FS is configured correctly, let’s discuss below scenarios:

Scenario 1: the domain is federated using AD FS, No conditional access configured, only “Skip MFA for Requests From Federated users on my intranet” option Enabled from MFA portal as below snapshot:

 

 

In this case and as you may know, AD FS will send a claim “insidecorporatenetwork” to Azure to determine if the request is internal or external, for example if the request came from the internal network we can see that AD FS issued the insidecorporatenetwork claim with value “True” which means that the request came from internal which will not trigger MFA based on the option we selected before to Skip MFA for internal requests:

 

<saml:Attribute AttributeName=”insidecorporatenetwork” AttributeNamespace=”http://schemas.microsoft.com/ws/2012/01″ a:OriginalIssuer=”CLIENT CONTEXT” xmlns:a=”http://schemas.xmlsoap.org/ws/2009/09/identity/claims”>

<saml:AttributeValue b:type=”tn:boolean” xmlns:tn=”http://www.w3.org/2001/XMLSchema” xmlns:b=”http://www.w3.org/2001/XMLSchema-instance”>true</saml:AttributeValue>

</saml:Attribute>

 

Scenario 2: the domain is federated using AD FS, there is a conditional access to require MFA from any location except MFA trusted IP’s (Preview Feature) as below, also “Skip MFA for Requests From Federated users on my intranet” option Enabled

 

 

In this Scenario, MFA will be skipped for internal users and will triggered for external users.

 

Scenario 3: Same as scenario 2 except that “Skip MFA for Requests From Federated users on my intranet” is NOT enabled, then MFA will be triggered internally and externally

 

Scenario 4 ( I saw it in a lot ): the domain is federated using AD FS, there is a conditional access to require MFA from any location except MFA trusted IP’s (Preview Feature) as below, also “Skip MFA for Requests From Federated users on my intranet” option Enabled, but here assuming that we turned off the configuration for location in the CA, so CA configured but without configure the location as below:

 

Skip MFA for Requests From Federated users on my intranet” option will not have any effect here and MFA will be triggered for internal and external users.

 

Scenario 5: If you choose in CA to exclude the trusted IP’s, then you can specify it in MFA portal as below, this will skip MFA for all request came from the public IP 52.174.244.227/32 :

 

 

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.

Deep Dive in Azure Active Directory Synchronization – Ahmad Yasin – Beta Edition

Hello All,

Today, we published our First E-Book which discuss some topics in Azure AD Synchronization process and federation services.

This is the first edition of this book, it’s a beta edition, Me and the other contributors in this book wrote it without any external support, we did our best to make it useful to the reader. You may find some mistakes from language side or technical side, it will be our pleasure to hear from you. To contact us please send us an email to Author@AzureDummies.com ; we will try to improve it in next version.

This book took around seven months to be completed, some commands or procedures may be changed as cloud technology grow rapidly and changed every day, the most important thing that we focused in the concept more than “HOW TO”, even if you find anything got changes most likely the concept is the same and this is what we tried to achieve in this book to demonstrate the concept.

We got assistance from Microsoft article in some parts, we admit that the content of this book is no 100% from our minds, sometimes we found that Microsoft or other sites explain the idea better than us so we take some texts from these articles.

Again, in this book we didn’t assume that you will master the implementation of Azure identities after reading this book, we only focusing in the concept so we expect that the reader will be able to understand the concept behind Azure AD, for that we assumed that the reader should have a little background in below topics:

Basic experience in Active Directory.

Basic experience in cloud solutions.

Basic experience in federation services such as AD FS.

To Download It: https://gallery.technet.microsoft.com/Deep-Dive-in-Azure-Active-77d39370 

Securing the RDP connection Using Azure MFA for windows 2012/ 2012R2/2016 with RD Gateway and NPS server.

Hello All,

Ahmad Yasin

In my previous articles, we explained a step by step how to secure the remote access (RDP connection) using Azure Multi-factor Authentication (MFA), at that time we mentioned that the same procedure can only applied to windows 2012 and earlier and it’s not supported to be applied to windows 2012 R2 and above.

You can review the previous articles using below links:

Part 1: http://azuredummies.com/2016/02/05/secure-terminal-services-rdp-using-azure-multifactor-authentication-mfa-part-1/

Part 2: http://azuredummies.com/2016/02/06/secure-terminal-services-rdp-using-azure-multi-factor-authentication-mfa-part-2/

Part 3: http://azuredummies.com/2016/02/13/azure-active-directory-part-3-azure-ad-connect-installation-and-configuration/

Today in this article we will walk through the steps in how to secure the RDP connection to windows 2012 R2 and above, I found many articles on the internet that describe the procedure, i followed a lot of them with no luck,

We found multiple public articles which described this deployment.Unfortunately, we followed these articles but it never works, i collaborated with my colleague “Lucian Busoi” in order to find what are the missing steps in these articles, Finally we found it and i will summarize all required steps in this article, Thanks Lucian for this help.

“Other Public Articles may Assumed that the missing steps something that the reader should know by default”

To simplify the scenario, let’s summarize what are the components required for this deployment:

1- Windows 2012 R2/2016 machine which will be used to setup the MFA stand alone server which will be used for MFA authentication with MS back-end service.

2- Windows 2012 R2/2016 machine which will be used to install and deploy the Gateway and NPS roles, to simplify the concept of this server let’s imagine that this server will be used as an intermediate between the target server and MFA server, when the user try to connect to the target server using RDP, the traffic actually will reach the gateway server first, after gateway server verify the domain credentials it will forward the traffic to the MFA server to do the second factor Authentication, if MFA challenge Passed then the user will be allowed to access the target server.

3- The target Server(s) which you require to access it thorough RDP, for example windows 2012 R2 or 2016 machines.

before start the Implementation, let’s first explain the concept, for the MFA server as we already know we need this machine n order to deploy the MFA server, deploying the MFA server is easy process, in order to be able to download the MFA setup package from Azure portal, you need to have a license that allow you to deploy the MFA stand alone server, you need to have one of the following licenses:

  • Azure Multi-Factor Authentication
  • Azure Active Directory Premium
  • Enterprise Mobility + Security

one important thing i noticed that many customers tried to follow MS article to deploy the MFA stand alone server as described in below article:

https://docs.microsoft.com/en-us/azure/multi-factor-authentication/multi-factor-authentication-get-started-auth-provider

Some customers stuck in above article in the “Create a Multi-Factor Auth Provider” step as they don’t have this option in their Azure Tenant even they have a valid license for MFA, at this point they stop deploying the MFA and start complaining about this, HEADACHE !!

If you don’t see the option to create the MFA provider, Then a default MFA provider is already setup for Your tenant assuming that you have a valid license.

To access the MFA provider, you need to follow below steps:

login to https://portal.azure.com with global administrator user, then from the left pane select “Azure Active Directory” as below:

Then Click on ” Users and Groups” option as below:

Now, Make sure to select “All Users” option, then click in “Multi-Factor Authentication” option as below:

The MFA page will appear as below, make sure to click on the “Service Settings” option, then in the bottom of the page click on “Go to Portal” option as below:

 

Note: if “Go to the portal” option doesn’t appear, then this means usually that you don’t have a valid license for MFA stand alone deployment or you didn’t assign any user for an MFA license.

Finally, you will find the option to download the MFA stand alone server as below:

In this article we will assume that the MFA server already deployed as we discussed this in details in my previous article as below:

http://azuredummies.com/2016/02/06/secure-terminal-services-rdp-using-azure-multi-factor-authentication-mfa-part-2/

For now, we have an MFA stand alone server already deployed but not configured yet.

Let’s move to the second component which is the Gateway/NPS server, let’s go a little deep from technical perspectives, the most important question why this component is required in this deployment, to answer this question let’s try to understand the flow in GW/NPS with MFA:

i draw above diagram (Not professional in drawing 🙂 ) to demonstrate the concept and the functionality of GW/NPS server, let’s summarize the flow as below using the numbers in the diagram:

1- User will trying to access on-premises resource using gateway, in this stage the user credential will be sent to the gateway server.

2- Gateway will forward the request to the MFA server, till this stage the provided credentials by the user not validated yet.

3- since the credentials still not validated, then the MFA server will forward the request to the NPS server asking it to verify the credentials before moving forward and start the MFA process.

Note: in our demo, Gateway and NPS is the same server.

4- Now, NPS will verify the user credential using the local Active directory, depends on the response from local AD the NPS will respond to the MFA server, if the user credentials are correct then the NPS will receive and accept response from local AD, otherwise NPS will receive rject request from local AD which will deny the user to access the resource, noting that if the NPS got a reject message from local AD then the MFA will not be processed and this make sense as no need to apply second factor Auth if the credentials (first Factor Auth) are wrong.

Note: when we are saying “Accept” or ” Reject” message this is not actually mean that AD send Accept or Reject message literally, we are trying to simplify the process only.

5- in case of Accept response from AD, NPS will send the request back to the MFA with Accept Message.

6- MFA will perform the second factor authentication, it will challenge the use by MFA challenge, for example it may call user phone or send notification in Microsoft Auth App.

7- MFA will send the result of MFA challenge to the RD Gateway again.

8- In case the MFA challenge passed, then RD Gateway will evaluate the request against Resource Authorization Policies (RAP) and check if the user is allowed to access the resource or not.

9- if the user is allowed to access the target resource, then RD Gateway will allow the user, otherwise the user will be rejected.

 

To summarize above, in order to the user to successfully access the resource, three major conditions should be met:

1- The Users credentials should be correct and accepted by local active directory.

2- User should pass the MFA Challenge.

3- User should be allowed to access the resource based on the RAP policies.

As we now understand the purposes of each components, let’s start the implementation, to do that i have below servers:

1- Windows 2016 machine for MFA deployment, IP: 192.168.0.15

2- Windows 2016 for gateway and NPS deployment, IP: 192.168.0.14

3- Target resource, it may be windows 2016, 2012 R2, 2012.

Theoretically, earlier versions of target resource such as windows 2008 R2 should work using the procedure in this article, but i didn’t test this, no guarantee.

As mentioned before, the installation of MFA server is an easy process, and i already discussed it in my previous posts, if you are not familiar in how to install the MFA server please follow my previous article:

http://azuredummies.com/2016/02/06/secure-terminal-services-rdp-using-azure-multi-factor-authentication-mfa-part-2/

Now, let’s go to the implementation of gateway/NPS server, first of all, the RD gateway is a windows Role whick means you can deploy it without the need of any external package, You can deploy it using server manager, to do deploy these services, open the “Add Roles and features Wizard” from server manager then click Next in the first page as below:

Now, Choose “Role-based or feature-based installation” option and click Next:

Choose the right server and click Next:

Choose “Remote Desktop Services” option only and click next, Don’t choose the NPS from here as it will be added automatically by the wizard later on:

Now, once you reach the Role Services tab, choose “Remote Desktop Gateway” option, new dialog box will appear asking you to install other related roles/features including the NPS as below:

Click Add features to add all required features including the NPS:

Now, keep clicking Next till you reach the Role Services tab again, make sure that the “Network Policy Server” option selected then click Next:

Finish the wizard by click Install and wait till the installation finish:

The Installation of Gateway and NPS services finished as below:

Till this step, we have two server, the first one is the MFA server and the Second one is the Gateway/NPS server, now let’s go through the Configurations Part.

First of all, let’s configure the GW/NPS server, to do that, from server manager, launch the remote desktop gateway manager as below:

From RD Gateway console, right click on the Server name and choose Properties as below:

Now, click on the “RD CAP Store” tab, then select “Central Server running NPS” option, enter the IP (or the name) of MFA server then click Add button as below:

a new windows will appear asking you to enter a shared secret key, enter any key you want and click OK:

Note: this shared secret key will be used later on on the MFA configuration, let’s call this in our minds GATEWAY SECRET KEY.

after adding the MFA server successfully, click OK:

Now, Open the NPS console from server manager as below:

Choose the “Remote Radius Server Groups”, then right click on the “TS GATEWAY SERVER GROUP” and choose properties, or double click as below:

Make Sure that the IP of MFA server appears under the General Tab, select it and click on the Edit button as below:

Click on load balancing tab, increase the highlighted values to avoid any time out issues, i prefer to set these values to 60 seconds or more:

Now, let’s create a Radius client, to do that from the NPS console, right click on the RADIUS Clients option and choose New as below:

Make Sure to check the “Enable this RADIUS client”, enter any friendly name you want, keep in mind that this name should be used exactly in another next step, choose any name and write it down for later on usage, Also you need to fill the IP (or name) of the MFA server and finally choose a a new shared secret, Remember that this secret key will be used also in MFA configuration later on, for that let’s call this in our minds NPS SECRET KEY, once finish click OK button as below:

Now let’s create two policies which will be user to forward and receive the requests from the MFA server, the easiest way to do that is to duplicate the Default policy “TS GATEWAY AUTHORIZATION POLICY” as below:

Now, Rename Both Policies exactly as appear below, make sure that both policies are enabled, the “Processing order” is very important here:

Righ click on the first Policy which is called “From MFA”, go to condition tab and click Add button as below:

Choose Client Friendly name option, then click Add button as below:

This is will ask you about the name of the Radius client, you SHOULD use the same name you used when you create the radius client in one of the previous steps, if you remember we used MFA as the name of the radius client, so we should use the same name here as this will specify from which radius client the NPS will receive the requests: 

Now in the same policy, go to the settings Tab, under Authentication request make sure to select the “Authenticate Requests on this server” option as below:

Under Accounting tab, make sure to remove the check from “Forward accounting requests ….” option as below:

Now, in the other policy which is called ” To MFA”, under the setting tab , verify the the Authentication have the option to forward the request to the TS GATEWAY SERVER GROUP as below:

Under Accounting, make sure that the ” Forward accounting requests …. ” is selected as below:

Under Conditions tab, you should have only “NAS Port Type” as a condition as below:

Just to verify above settings, both policies SHOULD have below configurations, click in the first one and see below configurations:

Now click on the second Policy and check the configurations:

Now, we still have three steps to do before finalize the configurations of GATEWAY/NPS, these two steps as per my search i didn’t find it in any public article which are related to this topic, so we need to make sure to do below steps.

The first one, as we mentioned in the flow diagram of GW,NPS,AD and the MFA server in Step No. 8, we mentioned that if the user respond to the  MFA challenge successfully, then MFA server will send the request back to the Gateway, Now Gateway will validate if the user is allowed to access the Target resource based on RAP policies, DO YOU REMEMBER THAT 🙂

if we open the RD Gateway console, under Resource Authorization Policies (RAP) tab we will not see any policy, this is by default, as the installation of gateway role only will not create any default RAP, so if you missed this step no user will be allowed to access any internal resource even if the user respond to MFA challenge successfully:

So we need to create a new policy, the policy will define who is allowed to access and what to access, to do that right click and choose “create New Policy using the wizard for simplicity as below:

Choose “Create only a RD RAP” then click Next as below:

Give the policy and friendly name and click Next:

Here, you need to decide which group will have an access, i created a group in my AD called it “Home Users”, add the groups you need to grant it an access then click Next:

Here, you have an option to decide which Resource(s) can be accessed by the groups you selected in previous step, for simplicityi will allow the group to acc

Also you can decide to allow the connection in specific ports, in this demo i will allow any port for simplicity as below:

Note: In production environments, you need to select the options based on your company requirements, choose above options as i did may be a security concerns for others, BE CAREFUL !

Finally, click Finish as below:

The Policy should be completed successfully as below:

The new Policy will appear in the Gateway Console:

The second important thing, by default the NPS will have a network policy to deny all requests as below, this policy is enabled by default:

Double click on the policy, you can see that the policy deny all connections and ignore user account dial in properties:

Each user in AD have a user account dial in property, this option by default will keep the NPS to take the decision to allow user to access or not as below snapshot from my AD:

Even if you try to change the option from AD to Allow Access, this is will not effect as the default NPS policy is to ignore this value from AD.

Now we need to change the option to be Grant Access as below, again if you missed this option no users will be able to access any resource through the gateway:

Now, you should see that the policy have a Grant Access as an access type as below:

The third important step, that we need to configure the RD Gateway certificate, I am using public certificate and i think you can use a private certificate from your internal CA but you need to make sure that the client machine trust the CA certificate, based on my testing if you don’t configure the gateway certificate the connection to gateway externally will not work, also if you decide to use the IP of GW instead of the name it will not work also as we will see this in the teasing part.

to configure the certificate, open the gateway console, choose the properties of the server name as below:

Under the certificate Tab, select the option to import the certificate and continue the process, from below snapshot you can notice that i am using a Public certificate issued by DigiCert, also you can see that my certificate is a wild card so i can access the Gateway using any name end with my domain name in the format of: xxxxxx.JoTechLab.com, if you don’t use a wild card certificate, then make sure that the name which will be used to publish the Gateway externally is included in the certificate SAN:

Now, the last thing we need to do is to configure the MFA server, to do that launch the MFA console and Go to “Radius Authentication” tab as below, make sure that “Enable RADIUS Authentication” is checked, then click in Add button:

As you can see from below snapshot, the Auth and Accounting have specific ports, if there is any network device that prevent these ports you need to allow them.

Add the IP of the Gateway Server, give any friendly name beside the Application Name field, then enter the shared secret key, the key that SHOULD be used here should match the one we configured in the gateway console (We called GATEWAY SECRET KEY if you Remember), finally click OK:

Now, from the target TAB, choose RADIUS Server(s) option and click Add as below:

You can see that there is a Server timeout option, i recommend to increase it to 45 seconds to avoid any time out in the MFA process, i forgot to do this in my lab.

Again, Add the IP of the NPS server (in our case the same IP of GW), enter the sahred Secret Key, again this should match the secret key we used in the NPS configurations, if you remember we called it NPS SECRET KEY:

Now to test this, we need to configure a test user, to do that we need to add the user to the MFA console, there are multiple ways to do that, i prefer the easiest one, Just go to the users Tab, then click Import from Active Directory:

Find the user and add it as below, in my example i will add a user called “Mohamad” then click Import as below:

Now, choose the user from the MFA console and Click Edit, make sure that the user have a valid phone number, if the value is incorrect or empty you can fill it from MFA directly as usually it’s supposed to import these info from local AD, fill the country code, Phone number and the MFA Method and finally make sure to enable the user, Click Apply as below:

From MFA console and under Users tab, verify that the user exist and configured as below:

Now the final part is the testing one, to test this i will access a target server using RDP connection, the Private IP of target server is 192.168.0.10, from my machine which is located externally from servers network, i will launch MSTSC /Admin, in the computer field i will enter the Private IP of the detestation server as below:

Now, from Advance Tab, click on the Settings button as below:

Choose “Use These RD Gateway Server Settings” option, enter the Name of the of the RD Gateway server that is accessible externally as below then click OK:

Here there is a very important note, based on my testing you cannot enter the public IP of the gateway because the connection will failed with certificate error as we discussed earlier in this article and as appears below, maybe there is another way to configure it, but at least this is what i find in my lab:

You can see that in my connection i used RG.JoTechLab.com which is point to the public IP of my Gateway server, as we mentioned before since i have a wild card certificate then this name is covered by my certificate.

Now enter the Credentials then click OK as below:

Based on the Policy that we created in previous steps, only the users who are member of HOME Users group will be allowed to access the gateway, the User Mohamad already member of this group as below:

Now the connection started:

Finally, i got the MFA challenge in my mobile as below snapshot, it ask me to press the # key to continue:

once i responded to the MFA challenge successfully the connection was allowed as below:

For example if i didn’t respond to the MFA challenge then the connection will be denied as below:

As a conclusion, in this article we covered the implementation of securing the RDP connection with Azure MFA using gateway/NPS server, in Next article we will discuss a very common issues, Also we will discuss how to troubleshoot the issues related to this deployment starting by reading the gateway and NPS logs ends with understanding the MFA logs.

Stay Tuned 🙂

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.

 

Configure AD FS to use Email Address as Alternate Login ID – Case Study

Hello Experts,

Ahmad Yasin

Recently, i saw some requests asking how to Allow AD FS to authenticate against Email address instead of username, to understand the concept more, let’s imaging below scenario:

Customer have an AD Connect to sync objects from local Active Directory to Azure AD, usually when you deploy AD Connect using Express setting or if you use customize setting as below, AD Connect will choose the Azure AD User name to be the local userPrincipleName:

 

So let’s imagine that we have an internal user with a userPricncipleName called “Ahmad@AzureDummies.com”, and let’s see that the email address for the same user is “Ahmad.Yasin@AzureDummies.com”.

in Above scenario and with AD Connect default configuration, when the Ahmad trying to access the portal he need to enter Ahmad@AzureDummies.com instead of his email address to login, usually this may make a trouble for some users as they used to enter the email address anywhere they asked for authenticate.

To solve above issue, some IT Admins deploy AD Connect and choose the mail attribute to be Azure username instead of the userPrincipleName and that’s fine as long as no AD FS in the environment.

The problem Now, if the environment have AD FS to redirect users to authenticate against local AD instead of Azure (Office 365), assuming that AD Connect syncing the mail as the Azure username, when the user enter the mail and the redirection happens to AD FS, then AD FS will receive the mail and try to authenticate against AD,unfortunately this is will fail as it will not be able to authenticate against AD using the mail.

AD FS by default will authenticate the users based on their AD usernames, to allow AD FS to authenticate the user using his email address it require to be configured to use alternate login ID (This is based on my knowledge and not sure if there is another method to achieve it), to achieve that you need to run below command in the AD FS server:

Set-AdfsClaimsProviderTrust -TargetIdentifier “AD AUTHORITY” -AlternateLoginID mail -LookupForests dummieslab.local

After that the user will be able to Authenticate against local AD using Ahmad.Yasin@AzureDummies.com instead of  Ahmad@AzureDummies.com.

Important Notes:

  1. For more information in how to change ADFS to use Mail instead of UPN, please read this carefully as there is some side effects and limitations: https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configuring-alternate-login-id ; in same article you will find the command to roll back from mail to UPN. https://blogs.office.com/2015/03/23/office-2013-modern-authentication-public-preview-announced/
  2. Changing AD connect to use mail instead of UPN have some limitations as mention here: https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configuring-alternate-login-id
  3. Using Set-AdfsClaimsProviderTrust -TargetIdentifier “AD AUTHORITY” -AlternateLoginID mail -LookupForests dummieslab.local will effect all federated domains in ADFS.
  4. Changing AD connect to use mail instead of UPN will effect all synced users.
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.

Enable Persistent Single Sign on (PSSO) for SharePoint online

Hello All,

Ahmad Yasin

In this short article, we will discuss the steps in order to enable Persistent Single Sign on (PSSO) for SharePoint Online with ADFS integration.

Simply, PSSO means that within a period of time, the users can access SharePoint online without the need to authenticate every time with ADFS (within specific period), usually the normal process that happens when the user trying to Access SharePoint online (Assuming that SharePoint online already integrated with ADFS to Authenticate Against local AD), when the user close the browser and try to access the SharePoint again, he will be redirected to ADFS to get the Authentication token which sometimes make a little delay.

to solve this issue, we can use PSSO claim which will allow the user to access SharePoint without the need to go each time to the ADFS within the life time of the cookies that will be issued.

To do that, open ADFS management console, right click on the O365 relying party and choose Edit claim Rule as below:

 

From Claim Rule Template, choose “Send Claim Using a Custom Rule as below:

Finally Add below:

c:[Type == “http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork“] => issue(Type = “http://schemas.microsoft.com/2014/03/psso“, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

 

Now, from the PowerShell, if you write below command:

Get-AdfsProperties | fl *persistent*

You can see from the result the PSSO lifetime in minutes:

Make sure that PSSO is enabled, Also you can play with the lifetime using the Set-AdfsProperties command.

 

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.

SalesForce with ADFS Integration for SSO – IOS devices cannot access the SalesForce page

Hello All,

Ahmad Yasin

In this article, we will discuss a small topic but it’s very important for most of the companies that Integrate Salesforce with Active directory Federation Service (ADFS) to achieve single Sign on (SSO).

For some reason, I tried to deployed ADFS with SalesForce to achieve SSO following below article from SalesForce site:

https://developer.salesforce.com/page/Single_Sign-On_with_Force.com_and_Microsoft_Active_Directory_Federation_Services

Note: we will not discuss how to integrate SalesForce with ADFS in this article, for the deployment guide see: https://developer.salesforce.com/page/Single_Sign-On_with_Force.com_and_Microsoft_Active_Directory_Federation_Services

After complete the integration between SalesForce and ADFS everything works as expected except the IOS devices. when the user try to access the SalesForce pagethey login to the SalesFroce page, then click on STS to reach the ADFS Page:

My ADFS URL is sts.mydummieslab.com as appears below, it will ask for on-premises credential as below:


After entered the credential, Damn, i got below error:

 

Dummies STS

An error occurred

An error occurred. Contact your administrator for more information.

Error details

  • Activity ID: 00000000-0000-0000-7100-00800000009a
  • Error time: Fri, 28 Apr 2017 16:59:06 GMT
  • Cookie: enabled

User agent string: Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_1 like Mac OS X) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.0 Mobile/14E304 Safari/602.1

As usual, i went to Google and bing my best friends and start searching, unfortunately, i didn’t find something that can help directly, but while am reading i find one important article which is: http://kb.tableau.com/articles/issue/error-saml-protocol-parameter-relaystate-was-not-found-or-not-valid-using-adfs-saml-with-ios ; this article mentioned the same error with different application but with IOS also, what i noticed in the article that the reason of the issue as per the Article is: iOS and OS X browsers, such as mobile and desktop Safari, truncate cookies larger than 4KB, which are required by Microsoft ADFS.

Above reason make me think in different way, for that I started to collect Fiddler traces to see whats happening in the Network level, configuring Fiddler to collect traces from IOS devices explained very well in Fiddler Article: http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/ConfigureForiOS

Note: I am not a fiddler specialist but i am doing my best to analysis the traces, if you find that i mentioned something wrong in the analysis don’t blame me 🙂

After collected the logs i found that the size of the packets (Cookies) exceed 4KB which maybe the cause in our case as below snapshots:

for now, i knew that there is some limitation in the cookies size and it seems (as per my understanding for Fiddler) that the size is more than 4KB, Then i start thinking what to do now ! Again went to my best friends Google and Bing but nothing found, suddenly i say ok let me try to change the HTTP Method used in the SalesForce, i am very lucky that i thought in this way because changes the SalesForce HTTP method from HTTP Post to HTTP redirect solve the issue totally, let me explain what i did exactly:

From the ADFS side, i made sure that the default configurations is the same and not changed as below:

Go to the SalesForce relying part that you already configured in the ADFS per SalesForce Article and make sure that the HTTP method binding is Set to POST as below:

From SalesForce admin page, open the single sign on configuration page, click on Edit to modify the SAML Single Sign on Setting as below:

You will find that the Service Provider Initiated Request Binding is set to HTTP Post as below (This configuration mentioned in the SalesFroce Article):

Now, this is the modification that you need to do, Just change Service Provider Initiated Request Binding to HTTP Redirect and save the configuration as below:

After that, Try the IOS it will work like a charm and of course in addition to other OS’s like windows and Android.

I don’t have enough info why this change solve the issue but at least it’s solve it 🙂 🙂

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.

 

 

How to deal with Stopped deletion threshold exceeded error in AD Connect

Hello All,

Ahmad Yasin

Today we will discuss very simple topic but sometimes it may confuse the IT Admins, this scenario happens when the Admin made a changes in the synchronization filtering by mistake, for example unselect one OU from OU filtering.

AD Connect have a built in feature to prevent accidental deletion for the objects, when AD Connect sync cycle occurs, if the number of objects to be excluded (deleted) from sync exceed more than 500 objects, AD Connect will prevent this process by default and the export in the Azure AD Connecter will failed with error: Stopped-deletion-threshold-exceeded.

Previously, we discussed this feature , if you are not familiar with this feature read my previous article: http://azuredummies.com/2016/07/15/ad-connect-object-deletion-threshold-office-365/

In this article, we will discuss how to deal with this error if you edited the Sync filtering by mistake, for example remove some OU’s from OU Filtering option.

To make it easier to understand, imagine that you need to exclude some OU’s from syncing, usually you will edit the properties of local AD Connecter in AD Connect console, then uncheck the unwanted OU as below snapshots:

 

Then Uncheck the unwanted OU’s, for example i need to uncheck Users OU, but by mistake let say i unchecked Employees OU as well as below:

Then I tried to run Initial sync using PowerShell As below:

When i went to AD Connect Management Console, i got below result:

from above snapshot, i ended up with 895 objects to be deleted! This is what i did by mistake since Employees OU contains this number of objects, fortunately in this case am very luck and thanks for AD Connect since it will prevent this process to be exported based on the deletion threshold feature, as the number of objects to be deleted exceed 500 objects then the process will be terminated as below snapshot:

Again, Thanks for AD Connect to prevent this accidental deletion for my objects, but what Next and how to deal with this?

Be careful, in this demo i already know that i unchecked Employees OU only, if i go and check the Employees OU again it will solve the issue, but assume that you don’t know which OU’s that was unchecked or another admin who did this!

in this situation, first, let’s go to Azure AD Connecter and click on search connector Space option as appears below:

Then from Scope choose Pending Export Option, check the delete checkbox and finally click search, as appears below all object that will be deleted will appears in the result, in our case it’s under pending Export since AD Connect prevent the completion of this process as below:

so, till now, we know that i have more than 500 objects to be deleted by Mistake, also i know that AD Connect terminate this process.

Note: if the number of objects to be deleted less than 500 objects then the process will complete successfully and the objects will be deleted from Azure AD which may interrupt cloud services such as exchange online. In this case, you need to revert the changes back and sync the objects again, don’t worry because AD Connect will match the objects again.

in this stage, be very careful, if you are trying to guess which OU’s should be selected and in any level, you reach below than 500 objects to be deleted then the process will be completed and you will lose some objects in Azure AD which will interrupt the cloud services until you sync the objects again.

the best approach in this case is to enable the staging Mode for AD Connect server, i will not discuss the staging Mode deeply here (maybe in Next Articles), but simply this action makes the server active for import and synchronization, but it does not run any exports which means that nothing will be commit in Azure AD or local AD and this is what we need till we correct the AD Connect OU filtering operation.

To enable the staging Mode, Run AD Connect Wizard Again, click Configure as below:

Choose “Configure Staging Mode” and click Next:

Enter the GA credential and Click Next:

Check the “Enable Staging Mode” option and click Next:

Finally, click Configure:

Once the configuration completed, click Exit:

if you go to the AD Connect management console, we can see that no export operation was executed as below:

Also, to double confirm, i ran initial sync again as below:

Again, no export operations was executed as below:

For Now this is Great as i can modify and try to correct the configuration without be worried, if we go now to the Azure Connector and search for connector space, we still see the pending deleted objects, Now even while i am correct the configuration ends with less than 500 objects, it will not be deleted since the export operation will not be executed as we are currently in staging mode:

In you case, you need to correct the configuration, and you can go every time to the connector space and see if there is still pending deletion objects or not, in my case i know that the Employees OU should be included again in the sync to prevent this deletion, in your case if you are not sure you can click in any pending export deletion object and see in which OU for example it’s located to check it as below:

Note: From My point of view, if you still not sure which OU’s should be selected, i prefer to select the whole directory then you can exclude one by one based on your requirements.

I went back and check the Employees OU as below:

Once i ran the initial sync again, i can see again that the export not executed as we are still in the staging mode as below:

I went again and search in the Azure AD Connector, i found nothing will be deleted and this make sense since now AD Connect doesn’t see anything to be deleted as Employees OU included in the Sync again as below:

Once i verified nothing will be deleted, i will disable the staging Mode, the same procedure as enabling it but now Just uncheck the option:

Once, the configurations finish, i can see that the export executed without any deletion as below snapshot: ( I Have some errors in export for other objects so don’t worry about that 🙂 )

 

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.

Azure ADConnect Export Failed with Permission-issue error (Insufficient access rights to perform this operation)

Hello Guys,

while i am working in one of the ADConnect deployment, we faced an issue in the export operation with error “Permission-Issue” for some users as appears in below snapshot:

from above console, when we clicked on the one of the effected users to expand the error, we got below snapshot with an error “Insufficient access rights to perform this operation” as appears below:

when we went to the AD users and computers, we noticed that all effected users have disabled inheritance permission as appear below (since the button enable inheritance appears this mean the inheritance is disabled):

Simply, enabling the inheritance solve the issue and the ADConnect was able to export these identities.

Now, the important question is why to enable the inheritance !

the answer is very simple, Disable Inheritance means that the account no longer inherits permissions from a parent object (I.E. an OU), in most cases this happens when the object were added to privileged group such as domain admins group.

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.