Protect your on-premises exchange with Azure AD – Azure AD Security – P.1

Posted by on Sticky post

Hello Everyone,

In this series, we will start discussing how customers can utilize Azure AD to protect their environment, Azure AD offering a lot of security features that can be utilized, hence with the time we will keep listing our customer challenges and how Azure AD can help to solve them. 

In this article I will be discussing a very interesting topic where we see a lot of confusion when customers are looking to implement a solution to protect their exchange on-premises environment with Azure MFA. 

Current traditional Exchange deployment allows the users to access their mailboxes using their traditional credentials (Username and password), in such deployment if any bad guys were able to know these credentials then it will be very easy for them to access the customer data. This raises a big concern regards the security, how we can prevent such unauthorized access to the data even if the credentials where stolen using any kind of attacks. 

Security is a big trend these days, Azure Multi-factor authentication (MFA)  is one of the Microsoft security solutions which can be used as a second layer of authentication, the simple idea of MFA is to prevent an attacker from gaining access even if they manage to learn the user’s password. It is useless without having possession of the additional authentication method. It works by requiring two or more of the following authentication methods: 

·        Something you know (typically a password) 

·        Something you have (a trusted device that is not easily duplicated, like a phone) 

·        Something you are (biometrics) 

Multi -Factor Authentication can be used in multiple scenarios, each scenario needs specific implementation that can help to protect on-premises environment, typically in this article we will focus on Exchange on-premises where customers still not using Exchange online. 

Azure offering a lot of ways to protect Exchange components, each scenario has pros and cons, in this article we will go through all options that we currently have. 

This article will focus in two main components, OWA Authentication access and Outlook for windows MAC and Outlook for mobile Access since there are the two major ways for end users to access their mailboxes. 
 
Note: anything applied in OWA will be by default applied to EAC access, in below article we only focusing in OWA, this is also applied for EAC by default without mention it explicitly. 

MS Exchange published over Azure APP proxy: 

Azure Application proxy is new way to publish your web-based application over internet securely. Application Proxy doesn’t require you to open inbound connections through your firewall which make it very secure to publish your on-premises applications in a very secure manner including Exchange OWA. 

In this way, the authentication request will be start with Azure Active directory, which simply means that most of Azure security features can be applied to this kind of access such as conditional access and MFA. 

As a quick overview of this flow:  

  1. User A is trying to access OWA to get in his mailbox 
  1. since OWA is published through Azure APP Proxy, the user will be redirected to Azure AD sign in page. 
  1. User A will be asked to enter his credentials, if validating the credentials (Managed vs Federated domains) the user will be authenticated at this stage. 
  1. Azure AD will evaluate all policies configured by admin, such as MFA, Conditional access controls … etc. User A should pass all security challenges. 
  1. If the user passed all challenges, Azure AD will issue a toked to the user client device. 
  1. User will take the token and send it to App Proxy service which will complete the flow of AuthN and AuthZ to have access to user mailbox through OWA. 
  1. If user A failed to pass any required security challenges, user will not be able to access his mailbox. 

We highly recommend starting using this deployment. 

More info about Azure APP proxy can be found here: https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy 

Below is the typical flow architecture, again since the Request is going through Azure AD (Step 2), this clearly means that you can enable and Azure AD security feature like MFA or conditional access: 

MS Exchange with hybrid modern authentication (HMA) mode 

This is a new feature announced by MS exchange team recently, the idea in this solution is to forward the Exchange Authentication traffic to Azure AD, this is only applying to outlook and outlook in mobile traffic NOT OWA. 

the steps taken during configuring Modern authentication result in evoSTS (a Security Token Service used by Azure AD) being set as Auth Server for Exchange server on-premises, in simple words, traffic will be routed to Azure AD, hence we can take advantage of azure AD security features like MFA and conditional access. 

Some simple commands to be run on exchange servers can do the whole the magic and redirect the traffic to Azure AD, no major changes required. 

This deployment working with Exchange 2013,2019 and 2019 with specific cumulative updates required, Skype for business can work under this model also even it’s not our main topic here. 

It’s recommended to start using this approach. 

More technical info can be found here: https://docs.microsoft.com/en-us/office365/enterprise/hybrid-modern-auth-overview 

Below diagram show the typical flow, noting that this model works with Federated and managed domain, below flow show the federated scenario as an example, since again the flow will go through Azure AD, this give the ability to apply any Azure AD security features like MFA or Conditional access. 

MS Exchange published over AD FS: 

This a very traditional deployment, where customers already have AD FS in-place and they already published OWA through AD FS. 

In addition to some built in security controls over AD FS itself like device registration, MFA is a valid option here, AD FS can support two types of MFA based on its version, Either to integrate AD FS directly with on-premises MFA server as secondary authentication if it’s already exist or with Azure MFA directly as Primary or secondary Authentication. Azure MFA only supported with AD FS 2016 and later versions. 

We don’t recommend customers to deploy this solution as a new deployment due to below challenges that I will list later this article. 

As a quick overview about the flow, we can summarize it as below: 

  1.  User A will try to access OWA. 
  1. User A will be redirected to AD FS Authentication Page, to enter his credentials if MFA used as secondary Authentication. 
  1. Once the user entered a correct username and password, based on the configuration user will be asked to pass the MFA challenge. 
  1. Once user passed the MFA challenge, user will be able to access his mailbox. 
  1. If MFA used as Primary Auth then user will be asked for MFA as primary Authentication. 

Additional info about the technical deployment can be found here: https://docs.microsoft.com/en-us/exchange/clients/outlook-on-the-web/ad-fs-claims-based-auth?view=exchserver-2019 

MS Exchange with MFA server on-premises: 

This is an old way to protect the Exchange OWA, OWA built based on IIS, MFA on-premises server can be used to secure the IIS Authentication. 

Currently, as we are moving away from MFA on premises server as mentioned here: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfaserver-deploy 

Also, this method requires installing the MFA server itself on each Exchange CAS server to secure the virtual directories for the OWA IIS. 

Since we are moving away from this type of deployment, we don’t recommend using it at all, our recommendation also that if customer currently use it, is to move away from this deployment. 

Now, each one of above solutions can be used in specific scenarios, for that lets summarize when we can use each scenario, to make it easier let’s use a tabular format for comparing: 

Scenario Name OWA Protection Outlook Protection Network changes Required Complexity of deployment Users Sync Requirements Other security features that can be utilized Our Recommendations level 
MS Exchange published over Azure APP proxy YES NO No major changes required specially that APP Proxy does not require any inbound ports to be opened. A very light on-premises deployment can achieve this, not much complex. Yes, users should be synced through AD Connect to Azure AD. YES High 
MS Exchange with MFA server on-premises NO YES No, it does require some changes on Exchange side and allow Exchange to reach Azure AD to pass the traffic No deployment required, just change the configuration in Exchange side. * Yes, users should be synced through AD Connect to Azure AD.  YES  High 
MS Exchange published over AD FS YES NO No, with existing environment.   Very complex for new deployments. ** Depends on which MFA deployment is used. *** NO, only MFA LOW 
MS Exchange with MFA server on-premises Yes NO – Very complex deployment No No, only MFA NOT recommended  

* Unless current Exchange environment version not matching the minimum requirement for this deployment, hence Exchange Upgrade may require: https://docs.microsoft.com/en-us/office365/enterprise/hybrid-modern-auth-overview 
 
** AD FS is hard to manage, need lot of efforts and expertise, in addition that the high availability of this deployment requires a huge resources which is very costly. 

*** in this deployment AD FS can user MFA server which does not require the users to be synced to Azure AD, also it can use Azure MFA directly which require users to be synced to Azure AD. 

GO DO’s: 

Looking to all above scenarios, we can clearly see that there is no single solution to protect all Exchange traffic (Outlook, OWA, Mobile) using Azure AD by utilizing its security features. 

Hence, customers who are planning to completely secure ALL their Exchange on-premises traffic need to choose multiple deployments from above options. 

For example, customers can use one of three main deployments to protect all exchange traffics as below options: 

  1. App Proxy to Protect OWA + HMA mode to protect outlook traffic. 
  1. AD FS (if the deployment already exists) to protect OWA + HMA mode for outlook traffic. 
  1. Move totally to exchange online and enjoy all Azure AD features. 

All above explanation should help our customers to take the best decision to protect their Exchange environment, keeping in mind that also the licensing part may play role here to take the decision. We recommend starting these kinds of deployment as mentioned above with our recommendations to avoid any unauthorized access to your company data. 

Hope this article make it clearer now to our customers to start implementing Azure MFA to secure their data, please feel free to leave a question through comments if you need any more clarifications, I will be very happy to answer it and help you move forward. 

Ahmad Yasin is a Technical Adviser at Microsoft in Azure identity Team 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, office 365, Azure Security Specialist.

Find Ahmad at Facebook and LinkedIn

How Microsoft can help working from Home – Responding to Corona crisis – MS TEAMS

Posted by on Sticky post

Hello All,

Hope all of you doing great, hope you and your family stay safe from this crisis.

In responding to current Corona Virus crisis, many governments around the world start locked down countries, which means that most employees will start thinking seriously to work from home.

Searching over search engines will show a lot of articles to show how much technologies can help in such situation, in this article I am going to discuss one of the most top requests we are getting from our customers these days and clear up all the doubts that you may have:

HOW I CAN START USING MS TEAMS TO ALLOW MY EMPLOYEES WORKING FROM HOME !
HOW I CAN START HELPING MY STUDENTS TO CONTINUE LEARNING FROM THEIR HOME !

 

Microsoft TEAMS:

One of the best solutions these days to allow employees to be productive from their homes, Microsoft recently announced a new license version which is a free one that you can start using it, it’s a six months trial license as mentioned in this article: https://docs.microsoft.com/en-us/microsoftteams/e1-trial-license

MS Teams have a lot of features that help you to be productive while working from Home, I am not going to discuss TEAMS features in this article as it’s already mentioned in our public MS documents, simple search will help you to find all these features.

But when it comes to the IT admins, sometimes it may confused how they can start get benefits from this trial license and how they can deploy it, hence I am going to discuss some common scenarios where I see it daily in our customers while I am working with them:

 Scenario #1: Customers with NO existing on-premises infrastructure:

In this scenario, you don’t have your users on-premises, you need to start using TEAMS, as an admin the process will be very easy here, Just following below steps:

1- Sign up for free Azure AD tenant: https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant#create-a-new-azure-ad-tenant

2- Verify your domain name in Azure, in this step you can verify your actual domain name in azure to allow users to have it in their UPN, if you are OK to use the .onmicrosoft domain, then you can skip this point, to add your domain you can follow these steps: https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/add-custom-domain#add-your-custom-domain-name-to-azure-ad

3- Create your users in Azure AD, fortunately Azure AD now support importing bulk users, this is can be done by have the users listed in Excel sheet then create them in one shot, you can follow these steps: https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/users-bulk-add

4- Activating the free trial E1 License to enjoy TEAMS for six months for free as described here: https://docs.microsoft.com/en-us/microsoftteams/e1-trial-license

5- Assign the licenses to the users as described here: https://docs.microsoft.com/en-us/microsoftteams/user-access#manage-teams-through-the-microsoft-365-admin-center

6- Finally, your users can now download MS TEAMS on their laptops and Mobile devices and start working remotely. End user TEAM guide can be found here: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=7&ved=2ahUKEwjP3oCVt6LoAhUBDewKHU6eAPAQFjAGegQIARAB&url=https%3A%2F%2Fdownload.microsoft.com%2Fdownload%2FD%2F9%2FF%2FD9FE8B9E-22F5-47BF-A1AB-09539C41FCD0%2FTeams%2520QS.pdf&usg=AOvVaw2KP9-FybqCgz8JIItmIUgS

Scenario #2: Customers with existing on-premises infrastructure, customer never used Azure AD before:

Here the scenario is different a little bit, if you have already an on-premises domain controllers where you already have your user objects created and you want to leverage the new TEAMS free license, then you still have the option to sync your users and give the end users the same login experience.

You can follow below steps to start using MS TEAMS:

1- Sign up for free Azure AD tenant: https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant#create-a-new-azure-ad-tenant

2- Verify your domain name in Azure, in this step you can verify your actual domain name in azure to allow users to have it in their UPN.

3- Sync your users from local AD to Azure AD using AD Connect tool, this tool will help you to sync your on-premises users to Azure AD, this tool offer multiple way for sign in’s, you can simply sync the users with their passwords, or if you have an AD FS or other federation Services you still can sync the users only without their passwords. The whole technical steps with a lot of details described here: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-custom

4- Once the users got synced, you can start Activating the free trial E1 License to enjoy TEAMS for six months for free as described here: https://docs.microsoft.com/en-us/microsoftteams/e1-trial-license

5- Assign the licenses to the users as described here: https://docs.microsoft.com/en-us/microsoftteams/user-access#manage-teams-through-the-microsoft-365-admin-center

6- Finally, your users can now download MS TEAMS on their laptops and Mobile devices and start working remotely. End user TEAM guide can be found here: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=7&ved=2ahUKEwjP3oCVt6LoAhUBDewKHU6eAPAQFjAGegQIARAB&url=https%3A%2F%2Fdownload.microsoft.com%2Fdownload%2FD%2F9%2FF%2FD9FE8B9E-22F5-47BF-A1AB-09539C41FCD0%2FTeams%2520QS.pdf&usg=AOvVaw2KP9-FybqCgz8JIItmIUgS

Note: In this scenario, the users will login to MS TEAMS using same on-premises credentials.

 

Scenario #3: Customers with existing on-premises infrastructure, customer already using Azure AD:

In this scenario I am assuming that the users already synced, if not then follow point #3 in Scenario #2, once this done or if it’s already done, then you just need to activate the license and assign it, see previous scenario for more info.

In addition to above scenarios, if you are an education sector, then Microsoft since long time providing a free license to enjoy Office 365 Services including MS TEAMS, the implementation phase shall be one of the previous three scenarios we described above depends on your current infrastructure, you can read more about educational sectors and how MS support them in the following articles:

https://docs.microsoft.com/en-us/MicrosoftTeams/remote-learning-edu

https://docs.microsoft.com/en-gb/microsoft-365/education/deploy/create-your-office-365-tenant

https://www.microsoft.com/en-us/microsoft-365/academic/compare-office-365-education-plans?activetab=tab%3aprimaryr1

 

Now, even with all these free stuff that Microsoft provide to help the world in this crisis, we didn’t forget the security part, due to time limitation while writing this article, I will discuss quickly the Multi-factor Authentication feature that will help in secure the access.

The security of two-step verification lies in its layered approach. Compromising multiple authentication factors presents a significant challenge for attackers. Even if an attacker manages to learn the user’s password, it is useless without also having possession of the additional authentication method. It works by requiring two or more of the following authentication methods:

  • Something you know (typically a password)
  • Something you have (a trusted device that is not easily duplicated, like a phone)
  • Something you are (biometrics)

Multi-Factor Authentication comes as part of the following offerings:

  • Azure Active Directory Premium or Microsoft 365 Business – Full featured use of Azure Multi-Factor Authentication using Conditional Access policies to require multi-factor authentication.
  • Azure AD Free or standalone Office 365 licenses – Use Security Defaultsto require multi-factor authentication for your users and administrators.
  • Azure Active Directory Global Administrators – A subset of Azure Multi-Factor Authentication capabilities is available as a means to protect global administrator accounts.

As per above, MFA also can be used as free services if you don’t have premium license, to activate MFA you can follow this article: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-userstates

Other security features, like identity protection, Conditional Access … etc. can be also enabled, do a quick search and you will find all of these features and it’s requirement from the implementation part and licensing part, by the way most of the security features explanation can be found here: https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-overview

 

Stay tuned for the next article in couple of days, where I will describe the best ways to access your on-premises resources and applications from your home in a very secure way 😊

Part 2 is ready here.

Stay Safe, protect yourself and others by working from home in this crisis.

Ahmad Yasin is a Technical Adviser at Microsoft in Azure identity Team 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, office 365, Azure Security Specialist.

Find Ahmad at Facebook and LinkedIn

Securing Azure VM’s External Access with Azure MFA – Whitepaper

Posted by on Sticky post

Hello All,

Today we are happy to publish our new Whitepaper which discussing one of the most secure way to access your Azure Virtual machines externally (Anytime from Everywhere).

We have heard from our customers loud and clear, and based on the feedback, security is still at the forefront of their concerns when deploying solutions. We have summarized below the leading causes for concern:

  1. Customer complains about VM’s access is not secure especially if they need to assign public IP’s to the VM’s to allow access at anytime from anywhere. In addition, assigning public IPs per VM is an increased cost incurred by the customer.
  2. Implementing site to site VPN requires effort and funding as well as constant monitoring of the connection.
  3. Open RDP protocol externally is not something that our customers are fond of, if no VPN solution then RDP should be opened.
  4. If the Admin credentials are compromised the entirety of environment will be under the attacker’s control.

 

Me and Fadi Hawari from Networking team worked on this whitepaper to propose a solution to address above pains, Download the white paper Now.

 

All feedbacks are welcomed.

 

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.

 

 

Azure MFA NPS Extension – Health Check Script V1

Posted by on Sticky post

Hello All,

Ahmad Yasin

I was very busy in the last period, hence i was not able to publish some new articles, but i am coming back so a lot of topics in it’s way soon.

Today, i am happy to announce that I implemented a simple script that will help you to perform a health check for your Azure MFA NPS Extension server(s) and detect some issues if it’s exist.

 

When this script is useful …

 

I can say that we can use it in all cases, but it’s will be very useful when a customer complains that MFA NPS Extension not working at all.

 

What to expect soon …

 

Lot of things, This script is still basic one, but always remember that The journey of a thousand miles begins with a step ,we need to develop this to include more tests, also it will be include troubleshooting scenarios where only one user is not working, issues with AD like permission issues …etc.

 

How to Run the Script …

Just download the script from TechNet gallery, run it using PowerShell directly, very easy to run, I uploaded the script to TechNet gallery to make it easier to update it.

Download Link: https://gallery.technet.microsoft.com/Azure-MFA-NPS-Extension-648de6bb

What tests this Script will do …

Basically, it will perform 11 tests against MFA Extension Server as below:

 

1- Checking Accessibility to https://login.microsoftonline.com  …

2- Checking Accessibility to https://adnotifications.windowsazure.com  …

3- Checking MFA version …

4- Checking if the NPS Service is Running …

5- Checking if the SPN for Azure MFA is Exist and Enabled …

6- Checking if Authorization and Extension Registry keys have the right values …

7- Checking other Azure MFA related Registry keys have the right values …

8- Checking if there is a valid certificated matched with the Certificates stored in Azure AD …

9- Checking the time Synchronization in the Server …

10- Comparing server time with reliable time server

11- Checking all Missing Updates on the server …

 

What Requirements needed to run the script …

The script need to be run under a user has a local admin Privilege on the server and it will ask for global admin on the tenant to be run.

How the result will be displayed ….

In PowerShell console it will only display the tests name, then it will convert the result to HTML file located under C drive under AzureMFAReport.Html name

 

Console Output:

HTML output as a final result:

In case the script detect some issues, does it will fix it automatically …

No, but the script will suggest some remediation steps as below example:

 

The script is not checking everything, right …

Sure, here I need your help, feel free to share your ideas with me and we can work together to improve it, eave a comment in this thread if you need to participate.

Do you think that the HTML design is cool …

No, I am not good in HTML design, help me to make it better, leave a comment in this thread if you need to participate.

 

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 MFA on-premise Server 8.x Version – Mobile App Service managed by Azure Back-end Now.

Posted by on Sticky post

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.

 

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

Posted by on Sticky post

Hello All,

Download it Now.

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.

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

Posted by on Sticky post

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

Posted by on Sticky post

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

Posted by on Sticky post

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.

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

Posted by on Sticky post

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.

Getting Started with Azure Active Directory Graph API

Posted by on Sticky post

Hello Everybody,

In this article we will discuss the concept of Azure Active Directory Graph API and how to start using Graph API.

In local active directory, when any application integrated with local AD want to look up for objects in the directory it used Lightweight Directory Access Protocol (LDAP) in order to perform the queries, LDAP is the protocol used to perform queries against local AD, modifying objects in AD, Adding and removing …etc. For example, if local exchange server wants to search for an object in active directory it will use LDAP protocol to achieve this. Also any other application which integrated with local AD will use LDAP to communicate with Active Directory.

So in general, LDAP is a query language with its special syntax that used to search and perform some operations in the directory such ass Add objects, Update Objects …etc.

To demonstrate the concept of LDAP, lets login to local active directory server and try to search for an object in our directory using LDAP queries, the simplest way to do that is to open Active Directory users and computers console, Right Click in the directory name and choose Find as appear below:

Now, change the find option to be “Custom Search� and click on Advance tab as appear below:

In “Enter LDAP query� field, we can enter our queries and click on Find Now button to get the result, for example if we write below LDAP Query and click on “Find Now� button:

LDAP Query to retrieve all groups in the directory:

(objectCategory=group)

We can see Cleary from above snapshot that the LDAP query get all groups in our directory.

Also, let’s try to get all objects with User type which their names begin with “MO�, to do that let’s execute below LDAP query:

(&(objectCategory=person)(objectClass=user) (cn=Mo*))

The result of the query will retrieve all users which their names starting with “Mo� as appear below:

So imagine that you have an attendance system in your environment, usually such these systems require user’s information, these systems usually configured to be integrated with local active directory to retrieve all employees’ information, in this case the attendance system most probably will apply the queries against local active directory using LDAP queries.

In azure Active Directory the story is different, LDAP was replaced with Graph API which can be used in order to execute queries against Azure Active Directory, Graph API provides programmatic access to azure AD through, Applications can use Graph API to perform Create, read, update and delete operations (CRUD) against Azure AD and get the result of queries in JSON format, so the applications should communicate with Azure AD using Graph API instead of LDAP protocol.

The general syntax of Graph API queries looks like below formula:

https://graph.windows.net/{tenant-identifier}/{resource-path}?[query-parameters]

Example on that Syntax:

https://Graph.Microsoft.net/AzureDummies.com/user?$filter=DisplayName eq “Ali Saleh�

Service Root: In Azure AD Graph API, the service root is always https://graph.windows.net.

Tenant identifier: This can be a verified (registered) domain name, in above example it’s our verified domain AzureDummies.com, we can also use .onmicrosoft domain if needed, It can also be a tenant object ID or the “myorganiztion� or “me� alias

Resource path: This section of a URL identifies the resource to be interacted with (users, groups, a particular user, or a particular group, etc.) In the example above, it is the top-level “users� to address that resource set. You can also address a specific entity, for example “users/{objectId}� or “users/userPrincipalName�.

Query parameters: ? separates the resource path section from the query parameters section. The Graph API also supports the following OData query options: $filter, $orderby, $expand, $top, and $format. The following query options are not currently supported: $count, $inlinecount, and$skip.

Note: at the end of the query you should specify the API version to be used, for example you should write above syntax in this way https://graph.windows.net/AzureDummies.com/users?api-version=1.6, but in our below examples we will not specify it since the web interface will use its API version implicitly.

To demonstrate the concept more, let’s navigate to https://graphexplorer2.cloudapp.net which is a web interface which will help us to execute Graph API queries against Azure AD, after open the web page just click on sign in label as appear below:

Enter a credential for a user with appropriate permission in the directory and click sign in button as appear below:

It will ask you to confirm the requested permission, click Accept button as appear below:

Just verify that the login successes as appear below:

Note: Graph Explorer site only support read (GET) queries, it’s not supported to execute other operations such as deleting objects, we can use https://graph.microsoft.io/en-us/graph-explorer in order to execute other operation which will be discusses in next lines.

Now, for example to get all details about all users in Azure AD we can run below query and click on the GET Button as appear below:

If we zoom out the result, we can see for example a user called “Ahmad Yasin� with his information as appear below:

Assume now we need to get all information about “Ali Saleh user, we can execute the GET query and specify the User Principle name in the query as appear below:

Also if we need to get the Job Title for “Ali Saleh� we can execute the GET query and specify the attribute we need to find it in the query as appear below:

Let’s assume we need to know the status of the password policy for the same user, we can execute below query:

Also we can execute other commands like Create, delete and update operations against azure AD, to demonstrate more, let’s navigate to other website https://graph.microsoft.io/en-us/graph-explorer which will give us the ability to execute more operations, let’s sign in in the page with our tenant privileged account as appear below:

Let’s try to get the information about “Mohammad Saleh� user by executing GET query as appear below:

Let’s double confirm that the user exists in our Azure AD by looking for it in office 365 users as appear below:

Now, let’s try to remove the user by executing below DELETE command:

To verify that the user was removed, let’s try to execute GET query as appear below:

We can be noticed from above snapshot that the user no longer exists, to double confirm that the user was removed, let’s go back to office 365 users, we will see now that the user appears in the deleted user’s container as appear below:

Note: This Article will not discuss the development side using Graph API, It’s Just to demonstrate the general concept of accessing Azure AD using Graph API, for full information about Graph API concepts and references, follow Microsoft Article: https://msdn.microsoft.com/en-us/library/azure/hh974476.aspx

As a conclusion, Application can be integrated with Azure Active Directory using Graph API in the same manner of integrating Applications with local active directory using LDAP.

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 AD Pass-Through Authentication – Concept Overview

Posted by on Sticky post

Hello Azure Lovers,

In this Paper,we will discuss the concept of Azure AD pass-through authentication which will enable the organization to keep the users’ password in on-premises and redirect all cloud authentications to be against local active directory.

To download the full document, visit Microsoft Technet: https://gallery.technet.microsoft.com/Azure-AD-pass-through-d0c97543 

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.

 

 

Understanding AZURE AD Connect Sync Scheduler

Posted by on Sticky post

Hi All,

we prepared a document to discuss the concept of Azure AD Connect Sync Scheduler, we tried to demonstrate the concept and let you have a good knowledge on it in addition to how modify the schedule using windows Azure PowerShell based on your requirements, we assumed you have a basic knowledge of Azure AD Connect in this document, to download the document visit TechNet gallery from below:

https://gallery.technet.microsoft.com/Understanding-AZURE-AD-0a837ca7

 

Ahmad Yasin (MCSA office 365, MCSE : Messaging, Azure Certified)

Ahmad Yasin (MCSA office 365, MCSE : Messaging, Azure Certified)

Ahmad Yasin in 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.

Office 365 [Solved] – Migration Permanent Exception: You can’t use the domain because it’s not an accepted domain for your organization

Posted by on Sticky post

Hello folks,

Ahmad Yasin (MCSA office 365, MCSE : Messaging, Azure Certified)

In one of our Migration projects from on-premises exchange to Exchange online (Office 365), we enabled Directory Synchronization using AD Connect tool, All on-premises users was synchronized to Azure AD successfully.

After enabling Hybrid Configuration wizard, we migrated a lot of mailboxes without any issues, few number of mailboxes failed to be migrated and showed below error (From office 365 portal, Migration Batch Details):

aa2

 

The error says:

“Migration Permanent Exception: You can’t use the domain because it’s not an accepted domain for your organization –> You can’t use the domain because it’s not an accepted domain for your organization”

Now. let’s understand why this error appear:

Assume you are the owner of AzureDummies.com domain, all email in the format of emailaddress@AzureDummies.com, in order to migrate these mailboxes to office 365 (Exchange online) you should prove for office 365 tenant that you are the real owner of the domain AzureDummies.com and this make sense, Imagine that there is no need to prove the ownership then anyone can create emails in office 365 using any public domain name which is impossible to be allowed.

In our case, our domain already verified in office but still we faced the same error for some mailboxes, when we checked the failed on-premises mailboxe (Email Address Attribute) we something similar to below:

aa1

from above snapshot, the blue arrow is the primary email address for this mailbox and use the same domain which was verified in office 365, but we can notice that the same mailbox have another alias end with different domain (Red Arrow) which is not verified in office 365 which is the main cause of this issue.

To solve the issue we have two options, the first one is to remove the alias and resync the object using AD Connect to update the attribute in Azure AD, in that case the user will not be able to receive emails using the alias.

the second option is to verified the alias domain in office 365 and re-migrate the mailbox again, and this is what we did 🙂

 

About Blogger …

 

Ahmad Yasin

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

Ahmad Yasin in 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.
Ahmad is currently working in Specialized Technical Services Company (STS).
Find Ahmad at Facebook and LinkedIn

 

 

Secure terminal Services (RDP) using Azure Multi-factor Authentication (MFA) – Part 2

Posted by on Sticky post

Ahmad Yasin (MCSA office 365, MCSE : Messaging, Azure Certified)

Ahmad Yasin

Hello Everyone,

In First article of this series we discussed the general concept of Azure Multi-Factor Authentication and how it’s work

In second part of this series we went more deeper in the technical aspects of the implementation of Azure MFA by taking an example of how to secure your remote desktop connection through Azure Multi-Factor authentication and we prepared the azure tenant and the Azure MFA provider.

In this part, we will continue our demo of integrating remote desktop connection (RDP) with Azure MFA by installing the Azure MFA server in the same server we need to secure it.

in this demo we have a server called Secure-Server with windows server 2008 r2 joined to the domain, we need to secure the remote desktop connection to it by installing the MFA server in it.

In this demo, I assumed that the MFA provider is already prepared, for more information read our previous article.

so let’s start the installation of the MFA:

Just to remind you, the below three snapshots show you how to download the MFA setup and generate the credentials which we explained in the previous article :

9

10

11

12

Now after the download of MFA completed, double click in the setup file, choose the installation path and click Next:

13

wait a seconds for the installation to complete:

14

once the installation finish click Finish:

15

A new Wizard will appear as below, Click Next:

16

Now enter the Email and Password credentials which we obtained before from the MFA provider, if you forget how to obtain it please read our previous post, if the credentials expired you can re-generate it again, once you fill the required information click Next:

21

Now, MFA server will try to communicate with Azure MFA Provider as below:

22

Ops, we received an error message as shown below ” Unable to communicate with the Multi-factor Authentication POP, The Multi-factor Authentication server could not be activated … etc“, this error is normal if you use an proxy to access internet, in this case you must verify three things if you use a proxy server:

1- Your proxy is set correctly in the server (in IE browser).
2- Run CMD as administrator, write the following command:
netsh winhttp import proxy source=ie
3-  MFA server must be able to communicate on port 443 outbound to the following:

  • https://pfd.phonefactor.net
  • https://pfd2.phonefactor.net
  • https://css.phonefactor.net

If outbound firewalls are restricted on port 443, the following IP address ranges will need to be opened:

IP Subnet Netmask IP Range
134.170.116.0/25 255.255.255.128 134.170.116.1 – 134.170.116.126
134.170.165.0/25 255.255.255.128 134.170.165.1 – 134.170.165.126
70.37.154.128/25 255.255.255.128 70.37.154.129 – 70.37.154.254

If you are not using Azure Multi-Factor Authentication Event Confirmation features and if users are not authenticating with the Multi-Factor Auth mobile apps from devices on the corporate network the IP ranges can be reduced to the following:

IP Subnet Netmask IP Range
134.170.116.72/29 255.255.255.248 134.170.116.72 – 134.170.116.79
134.170.165.72/29 255.255.255.248 134.170.165.72 – 134.170.165.79
70.37.154.200/29 255.255.255.248 70.37.154.201 – 70.37.154.206

23

After we set a proxy rules, I tried another time to activate the MFA as below:

24

finally, its verified successfully, Now the wizard will ask you to create new MFA group or choose existing one, since it’s first MFA server to be deployed, give any meaningful name for the new group as below, also note that the group used to manage more than MFA servers and enable replication between the servers if there is a need, Click Next:

25

Uncheck enable replication between servers option and click Next:

26

Now, you can select what application need to integrate it with Azure MFA, the last option is remote desktop, you can select it and click Next, but in our demo we will click cancel to configure the remote desktop from the MFA console, click Cancel.

27

Now, go to star menu and click on Multi-Factor Authentication Server icon:

28

Azure MFA server is loading as below:

29

After a while the console appear, this is the MFA server console that you can manage the MFA setup, in the status option it display that the server Secure-Server.demo.lab is online which is the same server we need to secure the RDP connection on it and the MFA server at the same time:

30

Also if you go to the Azure MFA provider manage page, click on Server Status option you will see the server is online as below:
31

Now back to the MFA server console, go to windows authentication, check “Enable Windows Authentication” option as below, then click Add button:
32

Choose the server name and terminal services as an application option, check the “Enable” option, now if you will apply all users in AD to use MFA check the “Require Multi-Factor Authentication user match” option, if not leave it uncheck as below, click OK:

33

The MFA is configured to secure the RDP in that server, it mentioned that the server need to be restarted to take the effect, click OK and wait before restart to continue the configuration:

34

As shown below, the server appear in the console:
35

Now go to Users icon to add the users you need to apply MFA authentication on them, click in Import from Active Directory button as below:

36

choose the users you need and click Import as below:

37

The users successfully imported as below, click OK:

38

the new users appear in the console, there is a warning icon beside each user, this warning because the user must enabled for MFA manual, by default when you import the user it will be not enabled for MFA automatically, double click in any user:

39

fill the required information as below:
-Country Code.
-Phone.
– choose MFA to be phone call, Text Message or mobile app … etc. we will choose for this demo a phone call option.
-check the enabled option.
Finally, Click Apply:

40

note after we check the enable option the warning icon disappear, do the same for all users you need:

41

after I prepared all users, the users appear in the console without the warning icon, to test the configuration choose any user and click the test button:

42

provide the password and click test:

43

wait a while:

44

Now, the user should receive a call, if he end the call the authentication will be refused because it will considered that another person try to use his/her credentials, if the user click (#) he/she confirm that he is the one trying to access the server:

45

After I clicked (#), the test completed as belwo:

46

Now, after I restarted the machine to take effect, I try to access the server remotely as below:

47

I tried to login with the administrator user:

48

Now the welcome page start:

49

during the login and within the welcome page  I received a call from Microsoft MFA, I answered the call and end it direct:

50 - Copy

Because I end the call and didn’t press the (#) key, the login process failed as below:
52

I tried to login again with the same user: 53

I received another call from Microsoft MFA, but this time I press (#) key:

54

Because I press the (#) key I confirmed for Microsoft that I am the same person who try to login now, so I successfully login to the server as below:

55 56

So in this article we tried to demonstrate how to install the MFA server and integrate it with the remote desktop connection (RPD).

In next part we will show you how to customize the MFA setup by using Fraud alert, changing the received call voice, generate a reports … etc.

Stay tuned 🙂

Ahmad Yasin (MCSA office 365, MCSE : Messaging, Azure Certified)

Ahmad Yasin (MCSA office 365, MCSE : Messaging, Azure Certified)

Ahmad Yasin in a Microsoft Cloud Engineer and the Owner & publisher of AzureDummies blog. He also hold many certificates in office 365 and windows azure including Developing Microsoft Azure Solutions, Implementing Microsoft Azure Infrastructure Solutions and MCSA office 365.
Ahmad is currently working in Specialized Technical Services Company (STS).
Find Ahmad at Facebook and LinkedIn

 

 

 

 

Secure terminal Services (RDP) using Azure Multi-factor Authentication (MFA) – Part 1

Posted by on Sticky post

Hello Everyone,

In First article of this series, we discussed the general concept of Azure Multifactor Authentication, and how MFA participate in securing your on premise environment and Hybrid one if exist.

In this article we will go in more technical details about how to use Azure Multifactor Authentication using a real example.

One of my customers have a server which contains a highly secure data and only around 6 users have a remote desktop access to that server, the customer need to add more security layer for accessing this server.

I suggest the customer to use Azure MFA, since it will add a highly secure layer to the remote desktop access to the server in addition to the low cost of this service.

so let’s start the technical steps to do that, remember that we need to integrate remote desktop protocol access (RDP) with Azure MFA.

in this part we will prepare the Azure MFA provider and download the MFA server setup files, In next part we will deploy and configure the MFA server to secure the RDP.

First of all let’s summarize the requirements to implement this scenario:

1- we need an azure account (Azure Tenant) to configure and install the Azure setup, if you don’t have account you can sign up for one month as trial, for more info follow this link : https://azure.microsoft.com/en-us/pricing/free-trial/

2- integrate RPD protocol with Azure MFA is not supported in windows 2012 R2 (until the date of this article), which means if you need to integrate RPD with Azure MFA you need to install windows 2012 and earlier such as windows 2008 R2.

3- To secure the remote desktop protocol (RDP) with Azure Multifactor, you must install the Azure MFA server in the same RDP server, in other word assume you have a server called “SRV1”, then you should install the MFA setup in the “SRV1” server, if you look back to point #2 you can conclude that you cannot secure the RDP for windows 2012 R2 (until the date of this article).

This deployment called MFA stand alone server since all deployment will be on premise and no integration will be done between local AD and Azure AD.

Now, log in to your azure tenant using https://manage.windowsazure.com, go to active directory tab from left pane:

1

Now choose MULTI-FACTOR AUTH PROVIDERS option from the top options,

2

Click New:

3

MULTI-FACTOR AUTH PROVIDERS used to install the MFA server setup files, also the provider will be responsible for the usage calculations and you can customize your setup from the provide such as fraud alerts.

Now choose App Services -> Active Directory -> MULTI-FACTOR AUTH PROVIDERS – Quick Create.

5

Name: choose any meaning full name for your provider.
Usage Model: you have two options here, per user enabled and per authentication, this option cannot be changed later, if you need to change it later you must create new provider, the difference between the two model is how Microsoft will charge you, if you choose per enabled user then you will be charged for how many users using MFA regardless of how many actual authentication occurs, if you choose per authentication you will be charged every time the users try to authenticate using Azure MFA.
Directory: choose Don’t link a directory since we will install the stand alone MFA server without integration with Azure AD.

After you fill the required information, click create:

6

after less than minute a new provider will be available in your tenant as shown below:

7

Click in the provider just created, then click in the MANAGE button in the bottom of the portal page:

8

The MFA Management page will appear, click in Downloads button as below:

9
in the download server page, it’s list the supported OS versions for MFA server including windows 2012 R2 and this is not what I said before, be smart I mentioned that the RPD feature is not supported in windows 2012 R2 but there is a lot of features that work in windows 2012 R2, Now click in Generate Activation Credentials button to generate the credential which will be used to register your server in MFA provider during the setup.

10

Email and password credential will  be generated, these credential valid to be used within 10 minutes, if you take more than 10 min to start the setup you can re generate a new credentials.

11

Now click the download text to start the downloading of the MFA setup:

12

After the download complete, copy the setup file to the server you need to secure the RDP on it and double click on the setup to start the installation.

In Next Part we will continue our demo by installing the multifactor server and configuring it to secure remote desktop access.

So keep tuned 🙂

About Blogger …

Ahmad Yasin (MCSA office 365, MCSE : Messaging, Azure Certified)

Ahmad Yasin (MCSA office 365, MCSE : Messaging, Azure Certified)

Ahmad Yasin in a Microsoft Cloud Engineer and the Owner & publisher of AzureDummies blog. He also hold many certificates in office 365 and windows azure including Developing Microsoft Azure Solutions, Implementing Microsoft Azure Infrastructure Solutions and MCSA office 365.
Ahmad is currently working in Specialized Technical Services Company (STS).
Find Ahmad at Facebook and LinkedIn

 

 

 

Set ForceChangePasswordNextLogin to False for bulk users in Azure AD

Posted by on

Hello All,

Hope all of you are staying safe from #COVID19 Crisis,

Recently, due to COVID19 situation we start see some customers who never use Azure AD before to start using it in order to allow working or learning remotely,

Some, of our customers especially the education sectors, start to implement a Cloud only environments ( No Sync from on-premises infrastructure), this means that the Admins using one of the ways that we have in order to create the users directly on Azure AD.

I see little challenge specially for Education sector as following:

The admin has a list of users in CSV file which include the passwords that will be assigned to students, then they import the CSV file in Azure AD and create the users, till now everything is OK.

Azure AD and due to security reason it will ask each user to reset his password at the first login, also it require the password to be a complex one which should include for example: Capital letters, Special Char., numbers…etc.

it may hard for the student to understand this, or they may face some difficulties to change their passwords at the first login, hence I don’t recommend at all to try bypassing this requirement, but still there is a way to do it.

In order to disable the requirement of changing password at the first login, you need to Create a password profile in Azure and set ForceChangePasswordNextLogin to False, here you will be in one of two situations as below:

1- You just created the users in Azure AD with Random passwords generated by Azure AD, in this scenario you don’t have the passwords of the users.

2- You created the users, you select their passwords, You know the passwords here.

We developed a small script that can help in both scenarios to set ForceChangePasswordNextLogin to False by reading a CSV file which Include the Usernames and passwords, the script simply will reset the passwords based on the csv file and disable the  ForceChangePasswordNextLogin feature.

How to user the script:

Download the sample CSV file from here:

Add all you usernames and passwords like the sample data in the CSV file, if you don’t have the users in CSV file, you can download them from Azure AD portal as described here: https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/users-bulk-download

You can create new passwords for the users in case of scenario #1, or use the same passwords in case of scenario #2.

Your CSV file will look like this (make sure NOT to change the Headers of the CSV file):


once you finish, make sure that the file exist in your C drive under temp folder, if temp folder not exist already then create it and put the CSV file inside it, sorry I didn’t have a time to modify the script to make it flexible to prompt you to select the location 🙂 Apologize for that.

File Name and  File location are very important to be the same as appearing below:

 

Then you need to run the script, simple the script will read all records in the CSV file, then it will reset the password based on the values in the CSV file, then set the ForceChangePasswordNextLogin  to FALSE.

Make sure to test this script in your testing environment before production, using this Script means that you agree that I take no any responsibility on the results of this script, I did it in my best efforts and testing in my Lab.

 

Download the Script from Here: ForceChangePasswordNextLogin_To_False_Bulk_Script (2373 downloads)   , Make sure to change the extension of this file from TXT to PS1

Download the Sample CSV file from here:  CSV_Users_List_Sample V1 (1209 downloads)  , Make sure after editing the file and before use it with the script to change the extension from TXT to CSV

Note: This script for only Cloud users, means it works with the users which created directly in Azure AD, it will not work with Synced users from Local AD.

leave a comment if you have any feedback.

Ahmad Yasin is a Technical Adviser at Microsoft in Azure identity Team 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, office 365, Azure Security Specialist.

Find Ahmad at Facebook and LinkedIn

Change Azure MFA Method for bulk users in one shot – MFA Converter Tool V1.0

Posted by on

Hello All,

Today I am exciting to announce the MFA Converter tool due to demand we see to change the Azure MFA method for bulk users, we see some scenarios where the admin need to change thousands of users MFA method to new one, hence we developed this script that can help tp achieve that.

This tool will help you to achieve the following Actions:

(1) To change MFA Method for one user…

(2) To change MFA Method for all users in your environment, This option not active yet, will be added in next version…

(3) To Change MFA method for users in specific groups in Azure AD…

(4) To change MFA method for Users listed in CSV file…

(5) To Export all of users current MFA methods information to CSV file…

Also, you can perform the MFA Conversion for targeted Audience as below: 

(1) Change MFA Method to Phone Call…

(2) Change MFA Method to one Way SMS…

(3) Change MFA Method to Authenticator APP – Notification…

(4) Change MFA Method to Authenticator APP – Code…

 

This Tool works with Azure MFA cloud only, means that it will change the MFA methods for users who has MFA enabled in Azure or using MFA NPS Extension, it will NOT work with Azure MFA on-premises server.

 

Once you start running the PowerShell, it will ask you to provide a code to allow you continue using the PowerShell, the code can be found in the usage agreement page, the idea from doing this is to make sure you read the agreement which listed all the limitation and some behaviors that may happen due to the use of this tool.

Usage Agreement and the code can be found here: http://azuredummies.com/2020/03/24/mfa-converter-tool-agreement/

 

The script can be found here, make sure to change the extension from TXT to PS1 in order to be able to run it.

 Click to Download: MFA Converter Tool V1 (995 downloads)

If you are going to use the option to update bulk users from CSV file, please make sure to use our sample template, some CVS samples not working, You can download the sample from here: CSV Sample File V1 (1048 downloads) , make sure after editing it to change the file extension o from TXT to CSV…

 

Ahmad Yasin is a Technical Adviser at Microsoft in Azure identity Team 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, office 365, Azure Security Specialist.

Find Ahmad at Facebook and LinkedIn

MFA Converter Tool Agreement

Posted by on

Please read this agreement carefully, if you are going to run this script, this means that you read this Agreement and you agreed.

After all these point you will find the code to use it to allow you run the script….

1- Always Make sure that you are using this script in your testing environment before production one, do all tests and see the behaviors.

2- if you choose to change the MFA method using this script, always make sure that the target audience already used before the Target method, for example if you want to change the MFA method to Authenticator app and the users have no devices registered, the next time the user trying to access cloud services it will fail, admin should reset the MFA method for the user as described here to solve the issue: https://docs.microsoft.com/bs-latn-ba/azure/active-directory/authentication/howto-mfa-userdevicesettings

3- You should have the required permission to change the MFA method like global admin.

4- if you are going to use the option of CSV, please download the template from here and use it, don’t change the header, CSV Sample File V1 (1048 downloads) , after finish editing the file, make sure to change the extension from TXT to CSV.

5- I don’t take any responsibility for the results of this script. I did it based on my best efforts and tests in my lab.

6- This Tool works with Azure MFA cloud only, means that it will change the MFA methods for users who has MFA enabled in Azure or using MFA NPS Extension, it will NOT work with Azure MFA on-premises server.

if you agree on all above points, then you need to enter this code in PowerShell to be able to run it: 951357.

 

How Microsoft can help working from Home – Responding to Corona crisis – Remote Access – Part2

Posted by on

Hello All,

This is Part Two of this series, Part one can be found here which discussed how to enable MS TEAMS.

In responding to current Corona Virus crisis, many governments around the world start locked down countries, which means that most employees will start thinking seriously to work from home.

Searching over search engines will show a lot of articles to show how much technologies can help in such situation, in this article I am going to discuss one of the most top requests we are getting from our customers these days and clear up all the doubts that you may have, frequent questions we are getting from our customers these days:

I have some on-premises APPS which not published over Internet and I need my employees to still be able to access them securely while they are working from home!

I want to allow my users to access internal Servers/Resources securely while they are working from home!

 

We have a multiple solutions Microsoft provide to allow your users to work affectively and more productive while they are working from home.

Azure Application proxy:

Azure Application proxy is new way to publish your web-based application over internet securely. Application Proxy doesn’t require you to open inbound connections through your firewall which make it very secure to publish your on-premises applications in a very secure manner including Exchange OWA. 

In this way, the authentication request will be start with Azure Active directory, which simply means that most of Azure security features can be applied to this kind of access such as conditional access and MFA.

 

Application Proxy works with:

  • Web applications that use Integrated Windows Authentication for authentication
  • Web applications that use form-based or header-based access
  • Web APIs that you want to expose to rich applications on different devices
  • Applications hosted behind a Remote Desktop Gateway
  • Rich client apps that are integrated with the Active Directory Authentication Library (ADAL)

Application Proxy supports single sign-on. For more information on supported methods, see Choosing a single sign-on method.

Application Proxy is recommended for giving remote users access to internal resources. Application Proxy replaces the need for a VPN or reverse proxy. It is not intended for internal users on the corporate network. These users who unnecessarily use Application Proxy can introduce unexpected and undesirable performance issues.

Full information about Azure APP Proxy can be found here: https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy

Technical Steps can be found here: https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-add-on-premises-application

 

Now, since we are talking about a crisis here, some customer may don’t have Azure AD in place already, in order to be able to use Azure APP proxy, you need to make sure that you have your Azure AD tenant configured correctly.

If you are starting from scratch, then you may need to activate your Azure AD tenant, then you need to sync your users to Azure AD, I will highlight some steps for customer who never used Azure AD before that they can follow in order to start using Azure AD Proxy:

 

1- Sign up for free Azure AD tenant: https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant#create-a-new-azure-ad-tenant

2- Verify your domain name in Azure, in this step you can verify your actual domain name in azure to allow users to have it in their UPN: https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/add-custom-domain#add-your-custom-domain-name-to-azure-ad

3- Sync your users from local AD to Azure AD using AD Connect tool, this tool will help you to sync your on-premises users to Azure AD, this tool offer multiple way for sign in’s, you can simply sync the users with their passwords, or if you have an AD FS or other federation Services you still can sync the users only without their passwords. The whole technical steps with a lot of details described here: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-custom

Once the users synced, now you need to have a valid license, Azure APP proxy need Azure AD Premium P1 or P2 license, if you are OK with the license then go ahead and start your implementation now.

What About Security!

Since the Authentication traffic will be routed to start with Azure AD, you can use any azure security features such as Multi-factor Authentication, Conditional Access … etc. for sure this depends on your license and how much security layers you want to add.

For more information about Azure AD security features, read this: https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-overview

This is a great start to allow your users to work remotely and be productive by accessing your internal apps remotely in a very secure way.

Securing Remote access to internal Servers/Resources:

The other types of requests I see these days, that the customer want to allow remote sessions to internal servers and resources, but they don’t have a good VPN solution or they want something that can be implemented easily and be secure.

First Scenario: Customers already have a VPN solution like CISCO, Fortinet … etc. they need just to secure the access by adding additional layer of security.

Azure AD providing multiple ways to secure this type of connections by adding a multi-facto authentication to any connection.
We have two solutions here, either to use Azure MFA server or MFA NPS extension, since we already announced that we are deprecating the MFA server, we don’t recommend start implementing it.

The best solution here and since most of these VPN solutions support Radius Authentication, we recommend to user Azure MFA NPS extension, it’s a light deployment that will enable MFA for all VPN connections.

If you looking how you can implement this and what is the license requirements, please follow this article: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension

If you already have MFA on-premises server and you still need to use it, you can see some sample documents on how to configure Radius/LDAP Authentication: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfaserver-nps-vpn

Noting that in MFA NPS Extension model, you must have your users synced to Azure AD, hence if the users not synced OR if you never use Azure AD before, please follow the missing points from below list:

1- Sign up for free Azure AD tenant: https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant#create-a-new-azure-ad-tenant

2- Verify your domain name in Azure, in this step you can verify your actual domain name in azure to allow users to have it in their UPN: https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/add-custom-domain#add-your-custom-domain-name-to-azure-ad

3- Sync your users from local AD to Azure AD using AD Connect tool, this tool will help you to sync your on-premises users to Azure AD, this tool offer multiple way for sign in’s, you can simply sync the users with their passwords, or if you have an AD FS or other federation Services you still can sync the users only without their passwords. The whole technical steps with a lot of details described here: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-custom

After that completed, continue with the MFA NPS extension guide mentioned above.

Second Scenario: Customers DON’T have a VPN solution; they need to allow the access to internal servers/Resources in a secure way.

The faster solution here is to deploy a windows Gateway Role and secure the access using MFA, like scenario #1, you can use both options: MFA server or MFA NPS extension, our recommendation still go to Azure MFA NPS Extension in this deployment.

I already wrote a long article long time ago described all the technical details and considerations required for such deployment: http://azuredummies.com/2017/07/01/securing-rdp-connection-using-azure-mfa-for-windows-2012-r22016/ , even this is the old model of deployment (MFA server), but I still recommend you to read the article in order to understand the concept and connection flow, this article include a huge great info.

To configure the RD Gateway with MFA NPS Extension, please follow this article:  https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension-rdg

Remember that you need to be aware about the licensing requirement of this deployment 😊

Note: if you want still to work with MFA server and you are a new customer who never used it before, you need to open a support case with Microsoft to whitelist your tenant with a critical business justification.

Stay tuned for the next article in couple of days, where I will discuss more topics that will help in this crisis 😊

Stay Safe, protect yourself and others by working from home in this crisis.

Ahmad Yasin is a Technical Adviser at Microsoft in Azure identity Team 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, office 365, Azure Security Specialist.

Find Ahmad at Facebook and LinkedIn

 

Azure MFA NPS Extension Service Principal Name (SPN) – How to deal with it.

Posted by on

Hello Azure MFA customers,

Recently, we see some cases where Azure MFA stopped working suddenly, checking Azure side we found that the Service Principal Name (SPN) for the MFA got disabled or removed which mainly cause the MFA to failed,  we figured out two main reasons for that:

1- There is no any active license covering MFA in the tenant, in this scenario the MFA SPN will got disabled Automatically.

2- Admin remove the SPN by mistake.

3- For some other reasons, the SPN got also Disabled.

 

In order to figure out what’s going on, start by checking if the SPN is exist or not, easiest way to do this from Azure portal following below steps:

 

1- Open Azure Active Directory, then Enterprise Applications, Choose All APplications from Application type drop down list, finally in the search box type this ID: 981f26a1-7f43-403b-a875-f8b09b8cd720

 

if you found the APP like appearing in above snapshot, then the SPN is exist( Display name may be different specially if it was created manually before, so always look to the ID), since SPN is exist we need to check if it’s enabled or not, to do that click on the APP now, then properties

 

 

if “Enabled for users to sign in” option set to Yes, then the SPN is enabled and this is what we need, if the it’s set to NO, this means that the SPN is disabled, you need to enable it to allow MFA to work.

 

Always make sure before enable the SPN or re-create it (will described later in this article) to have a valid license cover MFA, even you can always enable it without license but from legal perspective you always should have a valid license cover your users.

 

Now, if you didn’t find the SPN at all, you still can create it per below steps:

In order to complete this step you need to connect to your instance of Azure AD with PowerShell using Connect-MsolService. These steps assume you have already connected via PowerShell. For information see Connect-MsolService.

once you connected to your Azure AD through PowerShell, run below command:

New-MsolServicePrincipal -AppPrincipalId 981f26a1-7f43-403b-a875-f8b09b8cd720 -DisplayName “MFA SPN”

 

AppPrincipalId value is always the same since this is the ID for the MFA client SPN, you can change the display name to anything you want

 

Now, go back to your Azure tenant, follow above steps to check if the SPN now is exist and enabled.

 

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 AD Judgment when InsideCorporateNetwork Claim with ADFS is Used

Posted by on

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: https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/enable-or-disable-modern-authentication-in-exchange-online

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 xyz.com 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: http://azuredummies.com/2017/10/09/azure-conditional-access-with-skip-mfa-for-requests-from-federated-users-on-my-intranet-option-scenarios/

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: https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview

 

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: https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/location-condition 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: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-mfasettings#mfa-service-settings

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: https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-configurable-token-lifetimes

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.

 

Conclusion:

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.

 

Deploying Seamless MPLS

Posted by on

Seamless MPLS

In this post , we are going to examine what so called Seamless MPLS and the beinift from such a feature
We will start at the begining by doing usual MPLS L3VPN where R1 and R5 are MPLS PEs and all routers are running OSPF area 0 as their IGP

R1#show bgp vpnv4 unicast all
BGP table version is 4, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i – IGP, e – EGP, ? – incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 1:1 (default for vrf MSSK)
*>  10.10.10.0/24    0.0.0.0                  0         32768 i
*>i 10.10.20.0/24    5.5.5.5                  0    100      0 i

PC1> ping 10.10.20.10
84 bytes from 10.10.20.10 icmp_seq=1 ttl=59 time=98.006 ms
84 bytes from 10.10.20.10 icmp_seq=2 ttl=59 time=104.006 ms
84 bytes from 10.10.20.10 icmp_seq=3 ttl=59 time=75.005 ms
84 bytes from 10.10.20.10 icmp_seq=4 ttl=59 time=142.008 ms
84 bytes from 10.10.20.10 icmp_seq=5 ttl=59 time=86.005 ms

After checking end to end connectivity and before we go into Seamless MPLS , let us check the MPLS forwarding table on one of the PEs and on the Ps for later comparsion:

R1#sh ip bgp vpnv4 all labels
Network          Next Hop      In label/Out label
Route Distinguisher: 1:1 (MSSK)
10.10.10.0/24    0.0.0.0         23/nolabel(MSSK)
10.10.20.0/24    5.5.5.5         nolabel/23

R1#show mpls forwarding-table
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
16         Pop Label  2.2.2.2/32       0             Fa1/0      192.168.12.2
17         Pop Label  192.168.23.0/24  0             Fa1/0      192.168.12.2
18         17         3.3.3.3/32       0             Fa1/0      192.168.12.2
19         18         192.168.34.0/24  0             Fa1/0      192.168.12.2
20         19         4.4.4.4/32       0             Fa1/0      192.168.12.2
21         20         192.168.45.0/24  0             Fa1/0      192.168.12.2
22         21         5.5.5.5/32       0             Fa1/0      192.168.12.2
23         No Label   10.10.10.0/24[V] 686           aggregate/MSSK

R3#sh mpls forwarding-table
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
16         Pop Label  2.2.2.2/32       0             Fa1/0      192.168.23.2
17         16         1.1.1.1/32       2173          Fa1/0      192.168.23.2
18         Pop Label  192.168.12.0/24  0             Fa1/0      192.168.23.2
19         Pop Label  4.4.4.4/32       0             Fa1/1      192.168.34.4
20         Pop Label  192.168.45.0/24  0             Fa1/1      192.168.34.4
21         21         5.5.5.5/32       2179          Fa1/1      192.168.34.4

Now , let us divide the network illustrated in the above diagram into layers as per common design :

R2 – R3 – R4 are within the core layer , R1 – R2 and R4 – R5 are distribution layer and PCs (CEs) connections to their respective PEs are access layer
Seamless router roughly speaking aims to allow our distribution to expand smoothly and conserve the MPLS forwarding table to contain only what assist in establishing end to end LSP

We are going to modify the IGP to be divided into three routing processes instead of one process , we will use OSPF PID 12 between R1 and R2 , we will use OSPF PID 1 within our core and we will use OSPF PID 45 between R4 and R5

Now , as soon we do this , we will loose our end to end LSP , which means we will not be able to maintain connectivity between our PEs and as a result the VPNv4 iBGP session will be IDLE

The idea of Seamless MPLS is to divide the provider network as we did in the previous and to establish IPv4 iBGP with label sening capability (which means we will rely on BGP to assign labels among the LSP)

So , the first thing we will do is to leak R2 Loopback address inside OSPF PID 12 and leak R4 Loopback address inside OSPF PID 45

R2:
ip prefix-list R2LOOP seq 5 permit 2.2.2.2/32

route-map MAP permit 10
match ip address prefix R2LOOP

router ospf 12
redistribute ospf 1 subnets route-map MAP

Note :  the same to be done on R4

Next , we will establish IPv4 iBGP sessions between R1 and R2 , R2 and R4 , R4 and R5 with send-label capability

Note :  we will consider both R2 and R4 as route reflectors for the respective address-family (IPv4) and we will have to modify the next-hop using the command next-hop-self all attached to neighbor statement under the address family (we need all as we are establishing iBGP relations)

R1:
router bgp 1
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 2.2.2.2 remote-as 1
neighbor 2.2.2.2 update-source Loopback0
neighbor 5.5.5.5 remote-as 1

address-family ipv4
network 1.1.1.1 mask 255.255.255.255
neighbor 2.2.2.2 activate
neighbor 2.2.2.2 send-label
exit-address-family

address-family vpnv4
neighbor 5.5.5.5 activate
neighbor 5.5.5.5 send-community both
exit-address-family

address-family ipv4 vrf MSSK
network 10.10.10.0 mask 255.255.255.0
exit-address-family

R2:
router bgp 1
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 1.1.1.1 remote-as 1
neighbor 1.1.1.1 update-source Loopback0
neighbor 4.4.4.4 remote-as 1
neighbor 4.4.4.4 update-source Loopback0

address-family ipv4
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 route-reflector-client
neighbor 1.1.1.1 next-hop-self all
neighbor 1.1.1.1 send-label
neighbor 4.4.4.4 activate
neighbor 4.4.4.4 route-reflector-client
neighbor 4.4.4.4 next-hop-self all
neighbor 4.4.4.4 send-label
exit-address-family

R4:
router bgp 1
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 2.2.2.2 remote-as 1
neighbor 2.2.2.2 update-source Loopback0
neighbor 5.5.5.5 remote-as 1
neighbor 5.5.5.5 update-source Loopback0

address-family ipv4
neighbor 2.2.2.2 activate
neighbor 2.2.2.2 route-reflector-client
neighbor 2.2.2.2 next-hop-self all
neighbor 2.2.2.2 send-label
neighbor 5.5.5.5 activate
neighbor 5.5.5.5 route-reflector-client
neighbor 5.5.5.5 next-hop-self all
neighbor 5.5.5.5 send-label
exit-address-family

R5:
router bgp 1
bgp log-neighbor-changes
no bgp default ipv4-unicast
neighbor 1.1.1.1 remote-as 1
neighbor 1.1.1.1 update-source Loopback0
neighbor 4.4.4.4 remote-as 1
neighbor 4.4.4.4 update-source Loopback0

address-family ipv4
network 5.5.5.5 mask 255.255.255.255
neighbor 4.4.4.4 activate
neighbor 4.4.4.4 send-label
exit-address-family

address-family vpnv4
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 send-community both
exit-address-family

address-family ipv4 vrf MSSK
network 10.10.20.0 mask 255.255.255.0
exit-address-family

PC2> ping 10.10.20.5
84 bytes from 10.10.20.5 icmp_seq=1 ttl=255 time=51.003 ms
84 bytes from 10.10.20.5 icmp_seq=2 ttl=255 time=55.003 ms
84 bytes from 10.10.20.5 icmp_seq=3 ttl=255 time=60.003 ms
84 bytes from 10.10.20.5 icmp_seq=4 ttl=255 time=79.005 ms
84 bytes from 10.10.20.5 icmp_seq=5 ttl=255 time=39.002 ms

R1#sh ip bgp vpnv4 all labels
Network          Next Hop      In label/Out label
Route Distinguisher: 1:1 (MSSK)
10.10.10.0/24    0.0.0.0         23/nolabel(MSSK)
10.10.20.0/24    5.5.5.5         nolabel/24

Now , let us have a look at the MPLS forwarding-table:

R1#show mpls forwarding-table
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
16         Pop Label  2.2.2.2/32       0             Fa1/0      192.168.12.2
23         No Label   10.10.10.0/24[V] 0             aggregate/MSSK

R3#show mpls forwarding-table
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop
Label      Label      or Tunnel Id     Switched      interface
16         Pop Label  2.2.2.2/32       2925          Fa1/0      192.168.23.2
19         Pop Label  4.4.4.4/32       3017          Fa1/1      192.168.34.4

As can be seen , the difference in the number of entries is obvious , which means we conserved our resources and we gave ability to new PEs to connect and server customers smoothly