Force Tunneling Azure Firewall to pfSense – Part 2

Posted on April 16, 2020 by mattfeltonma

Welcome back to my series on forced tunneling Azure Firewall using pfSense. In my last post I covered the background of the problem I wanted to solve, the lab makeup I’m using, and the process to setup the S2S (site-to-site) VPN with pfSense and exchange of routes over BGP. Take a few read through that post before jumping into this one.

At this point you should a working S2S VPN from your Azure VNet to your pfSense router and the two should be exchanging a few routes over BGP. If you didn’t complete all the steps in the first post, go back and do them now.

Now that connectivity is established, it’s time to incorporate Azure Firewall. Azure Firewall was introduced back in 2018 as a managed stateful firewall that can act as an alternative to rolling your own NVAs (network virtual appliances) like a Palo Alto or Checkpoint firewall. Now I’m not going to lie to you and tell you it has all the bells and whistles that a 3rd party NVA has, but it can provide a reasonable alternative depending on what your needs are. The major benefit is it’s a managed service to Microsoft owns the responsibility of managing the health of the service, its high availability and failover, it’s closely integrated with the Azure platform, more than likely cheaper than what you’d pay for a 3rd-party NVA license.

Recently, Microsoft has introduced support for forced tunneling into public preview. This provides you with the ability to send all of the traffic received by Azure Firewall on to another security stack that may exist within Azure, on-premises, or in another cloud. It helps to address some of the capability gaps such as lack of support for (DPI) deep packet inspection for Internet-bound traffic. You can leverage Azure Firewall to transitively route and mediate traffic between on-premises and Azure, hub-spoke, and spoke to spoke while passing Internet bound traffic on to another security stack with DPI capabilities.

With that out of the way, let’s continue with the lab.

The first thing you’ll want to do is to deploy an instance of Azure Firewall. To support forced tunneling, you’ll need to toggle the option to enabled. You then need to provide another public IP address. What’s happening here is the nodes are being created with two NICs (network interface cards). One NIC will live in the AzureFirewallSubnet and one will live in the AzureFirewallManagementSubnet. Traffic dedicated to Microsoft’s management of the nodes will go out to the Internet (but remains on Microsoft’s backbone) through the NIC in the AzureFirewallManagementSubnet. Traffic from your VMs will exist the NIC in the AzureFirewallSubnet. This split also means you can now attach a UDR (user defined route) to the AzureFirewallSubnet to route that traffic to your own security stack.

The Azure Firewall instance will take about 10-20 minutes to provision. While you’re waiting you need to prepare the Virtual Network Gateway for forced tunneling.

Now if you go Googling, you’re going to come across this Microsoft article which describes setting a GatewayDefaultSite for the VPN Gateway. While you can do it this way and you opt for an active/active both on-premises and for the VPN Gateway configuration, you’ll need to need to flip this setting to the other local network gateway (your other router) in the event of a failover.

As an alternative solution you can propagate a default route via BGP from your on-premises router into Azure. ECMP will be used by default and will spread the traffic across all available tunnels. If one of your on-premises routers goes down, traffic will still be able to flow back on-premises without requiring you to fail anything over on the Azure end. Note that if you want make one of your routers preferred, you’ll have to try your luck with AS Path Prepending.

For this lab scenario, I opted to broadcast a default route via BGP. My OpenBGPD config file is pictured below. Notice I’ve added a default route to be propagated.

Hopping over to Azure and enumerating the effective routes shows the new routes being propagated into the VNet via the VPN Gateway.

With this configuration, all traffic without a more specific route (like all our Internet traffic) will be routed back to the VPN Gateway. Since this lab calls for this traffic to be sent to Azure Firewall first, you’ll need to configure a UDR (user defined route). As described in this link, when multiple routes exist for the same prefix, Azure picks from UDRs first, then BGP, and finally system routes.

For this you’re going to need to set up three route tables.

One routing table will be applied to the primary subnet the VM is living in. This will contain a UDR for the default route (0.0.0.0/0) with a next hop type of Virtual appliance and next hop address of the Azure Firewall instance’s NIC in the AzureFirewallSubnet. By order of

The second routing table will be applied to the AzureFirewallSubnet. This will contain a UDR for the default route with a next hop of the Virtual network gateway. This forces Azure Firewall to pipe all the VM traffic bound for the networks outside the VNet to the Virtual Network Gateway which will then tunnel it through the VPN tunnel.

Last but not least, you have an optional route table you can add. This route table will be applied to the AzureFirewallManagementSubnet and will be configured with Virtual Network Gateway route propagation disabled. It will have a single UDR with a default route and next hop type of Internet. The reason I like adding this route table is it avoids the risk of someone propagating a default route from on-premises. If this route were to be propagated to the AzureFirewallManagementSubnet, the management plane would see it down and may deallocate the instance.

The last thing you need to do in Azure is create a rule in Azure Firewall to allow traffic to the web. For this I created a very simple application rule allowing all HTTP and HTTPS traffic to any domain.

At this point the Azure end of the configuration is complete. We now need to hop over to pfSense and finish that configuration.

Remember back in the last post when I had you configure the phase 2 entry with a local network of 0.0.0.0/0? That was the traffic selector which allows traffic destined for any network from the VNet to flow through our VPN tunnel.

Now you have a requirement to NAT traffic from the VNet out the WAN interface on the pfSense box. For that you have to navigate to the Firewall drop-down menu and choose the NAT menu item. From there you’ll navigate to the Outbound option and ensure your Outbound NAT Mode is set to Hybrid Outbound NAT rule generation since we’ll continue to leverage the automatic rules pfSense creates as well as this new custom rule.

Add a new mapping by clicking the Add button. For this you’ll want to configure it as seen in the screenshot below. Once complete save the new rule and new mappings.

Last but not least, we need to open flows within the pfSense firewall to allow the traffic to go out to the Internet over HTTP and HTTPS as seen below.

You’re done! Now time to test the configuration. For this you’ll want to RDP into your VM, open up a web browser, and try to hit a website.

Excellent, so you made it out to the web, but how do you know you were force tunneled through? Simple! Just hit a website like https://whatismyipaddress.com and validate the IP returned is the IP associated with your pfSense WAN interface.

One thing to note is that if you deallocate and reallocate your Azure Firewall or delete and recreate your Azure Firewall after everything is in place, you may run into an issue where forced tunneling doesn’t seem to work. All you need to do is bring down the VPN tunnel and bring it back up again. There is some type of dependency there, but what that is, I don’t know.

Well that’s it folks. Hope you enjoyed the series and got some value out of it. Azure Firewall is a solid alternative to a self-managed NVA. Sure you don’t get all the bells and whistles, but you get key capabilities such as transitive routing and features that build on NSGs such as filtering traffic via FQDN, centralized rule management, and centralized logging of what’s being allowed and denied through your network. As an added bonus, you can always leverage the forced tunneling feature you learned about today to tunnel traffic to a security stack which can perform features Azure Firewall can’t such as deep packet inspection.

Stay healthy!

Force Tunneling Azure Firewall to pfSense – Part 1

Posted on April 16, 2020 by mattfeltonma

The Problem

Welcome back fellow geeks! I hope you all are staying healthy and not going too stir crazy being stuck at home. I’m here tonight to help break the monotony and walk you through a fun lab I recently put together.

I recently had a customer building out a sandbox environment for experimentation in Microsoft Azure. For this environment the customer opted to setup a S2S VPN (site-to-site virtual private network) to establish connectivity between their on-premises data center and Azure. The customer had requirements to use BGP (border gateway protocol) to exchange routes between on-premises and Azure. Additionally, their security team required all Internet-bound traffic be piped back on-premises (force tunneling) through a set of security appliances before being egressed out to the Internet from their data center.

While I’ve setup connectivity with Azure in the past using an S2S VPN, it was with a policy-based VPN vs a route-based VPN that utilized BGP. I’ve also worked with a lot of customers that had requirements for forced tunneling, but never got involved much in the implementation. My customers typically use Microsoft ExpressRoute for connectivity with on-premises and a third-party NVA (network virtual appliance) like a Palo Alto or Imperva. Since I’m not cool enough to have a lab with ExpressRoute and I’m too cheap to pay for an NVA, I’ve never had a chance to do the implementation myself. This has meant relying on documentation and other folks within Microsoft that have had that experience.

Beyond the implementation gap in that pattern, I also have gaps in my BGP skill set. While I’ve been lucky enough to play with a lot different technologies over the course of my career, enterprise routing was one area I never got to dive deep in. Over my time at Microsoft and AWS, I’ve had to learn the concepts of the protocol and how to use it within the public cloud, but still have lacked any practical implementation experience.

If you know me, you know I hate not being able to implement the technologies I speak with customers about. Hence, this blog post was born. I’ll be walking you through the lab I built to address the gaps in my BGP and get some practical experience force tunneling traffic. Enough with my blabbing, let’s get into it.

Lab Environment

The complete lab setup I used is illustrated above. In my home lab I’m using the 192.168.100.0/24 address range and have assigned the .1 address to the pfSense interface. Another interface on the device has been configured for DHCP to receive a public IP address from my ISP. Within Azure I’ve setup a single VNet (Virtual Network) assigned the address block of 10.0.0.0/16. Within the VNet I’ve create five subnets each using a /24 block of address space (I’m terrible at subnetting).

Inside the GatewaySubnet I’ve provisioned a VPN VNG (Virtual Network Gateway) with the VpnGw2 SKU to support BGP. The subnet named primary contains a single Windows Server 2016 VM (Virtual Machine) that I’ll be using to test the setup. Azure Bastion sits in the Azure Bastion subnet providing me with remote access into the VM.

Finally, an Azure Firewall instance has been provisioned using the new forced tunneling feature in preview. To support this feature, I’ve provisioned two subnets, one named AzureFirewallSubnet and one named AzureFirewallManagementSubnet as well as two public IPs. To route the traffic as needed, I’ve created three route tables with some user defined routes.

For this post I’m going to walk through the setup of the S2S VPN tunnel. Anytime I can refer you to official documentation for a step-by-step process, I’ll include a hyperlink. The steps that aren’t documented in a single place or documented at all will be the steps I’ll cover in detail.

The first thing you need to do is provision a VNet (Virtual Network). The VNet must at least include a subnet named GatewaySubnet. Microsoft requires this name for the subnet in order to deploy a VNG (Virtual Network Gateway). You’ll additionally want to provision another subnet named whatever you want to hold the VM (virtual machine) to test connectivity with. If you want to use Azure Bastion for remote access to the VM, you’ll need a third subnet which must be named AzureBastionSubnet.

While you’re twiddling your thumbs for 20 minutes waiting for the VNG, optional Bastion, and VM, you can create the local network gateway. The local network gateway is a logical resource in Azure which represents your on-premises VPN appliance. To set this resource up you’ll need a few different items:

The public IP address in use by your VPN appliance
The BGP peer address you’ll be peering with Azure
The ASN (autonomous system number) you’re using on-premises

For this lab you’ll want to use a private ASN between 64512-65514 or 65521-65534.

Below is a screenshot of my configuration. I included the entire address space I’m going to advertise, but if you’re using BGP you only need to include the addresses you’ll be using as BGP peer.

Now that Azure is provisioning all your necessary resources, it’s a good time to bounce over to pfSense. Note that pfSense doesn’t provide BGP support. For that you’ll need to add the OpenBGPD package. To do that you’ll navigate to the System drop down menu and choose Package Manger. Search for BGP and install the OpenBGP package. Once complete you’ll see it as an installed package as seen below.

Once the VPN Gateway has been provisioned you can begin configuration of the connection. The connection is also represented in Azure as a logical resource. There isn’t much to configure when you create the connection through the Portal. If you configure it through PowerShell, CLI, or an ARM template, you’ll have the flexibility to tweak the configuration of the tunnel. This includes the ability to limit the encryption ciphers and hashing algorithms supported on the Azure end. Once the connection is provisioned, open up the resource blade for it, go to the Configuration menu item in the Settings section and toggle BGP to Enabled.

Before you bounce over to pfSense and configure that end, you’ll need a few pieces of information from the VPN Gateway. Within the Portal open up the VNG resource blade. Note the public IP address that has been assigned to the VNG. You’ll need this for the pfSense setup.Next click the Configuration menu item in the Settings section. Here you’ll want to check off the Configure BGP ASN check box and note the ASN (by default 65515) and the BGP peer IP address because you’ll need them later. Click Save once you complete. This change will take around 5 minutes.

It’s now time to hop over to pfSense. From the main menu navigate to the VPN drop down menu and choose the IPsec option. You’ll first need to create a IKE Phase 1 entry to establish the authentication for the tunnel.In the General Information section ensure the Key Exchange Version box is populated with IKEv2 and the Remote Gateway is populated with the public IP address of the VNG. In the Phase 1 Proposal (Authentication) section, choose to the Mutual PSK (Pre-Shared Key) option, the My identifier is set to My IP Address and Peer identifier set to Peer IP address. Plus in the PSK you setup in Azure.In the Phase 1 Proposal (Encryption Algorithm) section pick your preferred encryption algorithm, key length, hashing algorithm, and Diffie-Hellman Group.The Azure end supports a number of cryptographic combinations just be aware you’ll need to configure a custom IPSec Policy using the CLI, PowerShell, or ARM template if you pick a combination that isn’t offered by default. I’m not sure what it supports by default because I couldn’t find any documentation on it. It seems like you’ll be forced to use DHGroup2 if you create through the Azure Portal, which you really shouldn’t be using due the small key length. If you want to nerd out a bit, take a read through this document. I wanted to bump this up to DHGroup24, so I opted to create the custom IPSec policy with the configuration below.

ipsecpol = New-AzIpsecPolicy -IkeEncryption AES256 -IkeIntegrity SHA256 -DhGroup Dhgroup24 -IpsecEncryption GCMAES256 -IpsecIntegrity GMAES256 -PfsGroup None -SALifeTimeSeconds 28800

Next up you need to configure a Phase 2 entry which will control how traffic is carried across the tunnel. Expand the Phase 1 entry you created and click the Add P2 button to add a phase 2 entry. In the General Information section you’ll want to set the Local Network option to Network with an address of 0.0.0.0/0. This will allow us to tunnel traffic to any address through the VPN tunnel which will support our use case for the forced tunneling we’ll create later on. In the Remote Network section, set it to the CIDR block of the VNet.In the Phase 2 proposal configure the settings to support whatever encryption setup you’re using. For my configuration, I set it up as seen in the screenshot below.

Once the phase 2 entry is configured, navigate to the Status drop-down menu and choose IPsec. Click the Connect button and assuming you configured everything correctly, the status shift from Disconnected, to Connecting, and will end on Established as seen below.

Hurray, you have an established VPN tunnel. Now it’s time to configure BGP.

Since you’ve already toggled the appropriate options in Azure to support BGP, it’s now time to configure it in pfSense. You will first need to create a firewall rule to allow the BGP traffic to flow between Azure and the pfSense box. To do this you’ll select the Firewall drop-down menu and choose the Rules option. Create a new rule to allow TCP port 179 from the source of the Azure BGP peer IP you noted earlier to the pfSense interface IP for the network you’re connecting to Azure.

Next you have to open the Services drop-down menu and choose OpenBGPD.In this section you have a few menu options, one which allows you to modify the raw config. Like the idiot I am, I ignored the comment at the beginning of the raw config that says not to edit it. After editing it, I was unable to configure using the menu options. If you’re not an idiot like me, you should be able to configure it using the menus. My working config is illustrated below.

Once you have your Config set, save it and give it a minute. The navigate to the Status section of the OpenBGPD service. Scroll to the bottom and check out the OpenBGPD Neighbors section. If you’ve misconfigured anything you’ll receive an error that the log file can’t be written (useful right?)

Additionally when I check the effective routes for the network interface of the VM in Azure I can see the routes propagating into the VM’s subnet.

You can validate your connectivity at this point in any number of ways. I went the lazy route and used pfSense’s Test Port capability located in the Diagnostics drop-down menu. Make sure that you open the appropriate rules in any NSGs between you and the VM. Also consider the VM’s host firewall if you opt to use a non-standard port or protocol like ICMP. If you opt to test from Azure back on-premises, make sure to open the appropriate firewall rules in the pfSense firewall for the IPSec interface.

With that you have a working S2S VPN complete with BGP exchange of routes. That will wrap up this post. In the next post I’ll walk through the configuration of forced tunneling with Azure Firewall.

Continue the journey in the second post.

DNS in Microsoft Azure Part 4 – Private Link DNS

Posted on March 5, 2020 by mattfeltonma

Updated October 2023

This is part of my series on DNS in Microsoft Azure.

Hi there geeks!

Azure Private Link is a common topic for customers. It provides a service provider with the ability to inject a path to the instance of their service into a customer’s virtual network. It should come as no surprise that Microsoft makes full use this service to provide its customers with the same capability for it’s PaaS services. While the DNS configuration is straightforward for 3rd-party-provided Private Link services, there is some complexity to DNS when using it for access to Microsoft PaaS services behind a Private Link Private Endpoint.

Before I dive into the complexities of DNS, I want to cover how and why the service came to be.

The service was introduced in September 2019. One of the primary drivers behind the introduction of the service was to address the customer demand for secure and private connectivity to native Azure services and 3rd-party services. Native Azure PaaS services used to be accessible only via public IP addresses which required traffic to traverse the public Internet. If the customer wanted the traffic to take a known path to that public IP and have some assurance of consistency in the latency, the customer was forced to implement ExpressRoute with Microsoft Peering (formerly known as ExpressRoute Public Peering) which can be complex and comes with lots of considerations.

Microsoft first tried to address this technical challenge with Service Endpoints, which were introduced in February 2018. For you AWS folk, the Service Endpoints are probably closest to VPC Gateway Endpoints. Service Endpoints provide a means for services deployed with the virtual network to access an Azure PaaS service directly over the Microsoft backbone while also tagging the traffic egressing the Service Endpoint with the virtual network identity. The customer’s instance of that PaaS service could then be locked down access from a specific virtual network.

Service Endpoints came with a few gaps. One gap was Service Endpoints are not routable from on-premises so machines coming from on-premises can’t benefit from their deployment. The other gap was a Service Endpoint creates a data exfiltration risk because it is a more efficient route to ALL instances of the Azure PaaS service. Customers were often implementing Service Endpoints directly on the compute subnets which would cause traffic to bypass an organization’s security appliance (think traditional hub-and-spoke) making that exfiltration risk that much greater.

Microsoft made an attempt to mitigate the exfiltration risk Service Endpoint policies which are similar to VPC Gateway Endpoint Policies in controls could be applied via the policy to limit which instances of a PaaS service the Service Endpoint would allow traffic to. Unfortunately, Service Endpoint Policies never seemed to catch on and they are limited to Azure Storage.

Microsoft needed a solution to these two gaps and that’s how Azure Private Link came to be. Azure Private Link includes the concept of an Azure Private Link Service and Private Link Endpoint. I won’t be digging into the details of the Private Link Service component, because the focus of this two-part series is on DNS and its role in providing name resolution for Microsoft native PaaS Private Link Private Endpoints. I do want to cover the benefits Private Link brings to the table because it will reinforce why it’s so important to under the DNS integration.

Private Link addresses the major gaps in Service Endpoints by doing the following:

Private access to services running on the Azure platform through the provisioning of a virtual network interface within the customer VNet that is assigned one of the VNet IP addresses from the RFC1918 address space.
Makes the services routable and accessible over private IP space to resources running outside of Azure such as machines running in an on-premises data center or virtual machines running in other clouds.
Protects against data exfiltration by the Private Endpoint providing access to only a specific instance of a PaaS service.

Now that you understand what Private Link brings to the table, I’ll focus on the DNS integration required to support Azure native PaaS services deployed behind a Private Link Private Endpoint.

The series is continued in my second post.

Deep Dive into Azure AD and AWS SSO Integration – Part 5

Posted on December 16, 2019 by mattfeltonma

I’m back yet again with the fifth entry into my series on integrating Azure AD and AWS SSO. It’s been a journey and the series has covered a lot of ground. It started with outlining the challenge with the initial integration of Azure AD and AWS using the AWS app in the Azure Marketplace. From there it took a deep dive into the components of the solution and how it compares to a standard integration using your SAML provider of choice. It continued with the steps necessary to configure Azure AD and AWS SSO to support the federated trust to enable single sign-on. The fourth post explored the benefits of SCIM and went step by step on how to configure SCIM between the two services. For this final post I’m going to cover a few different scenarios to demonstrate what’s possible with this new integration.

Before I jump into the scenarios, there is one final task that needs to be completed now that the federated trust and SCIM have been setup. That task is setting up the permission sets in AWS SSO. Permission sets are simply IAM policies (either AWS-managed or custom policies you create). For those of you from the Microsoft Azure world, an IAM policy is a collection of permissions which define what a security principal (such as a user or role) is authorized to do. They are most similar to an Azure RBAC role definition but more flexible and granular due to advanced features such as condition keys. Permission sets are projected into the AWS accounts they are assigned to as AWS IAM roles. These are the IAM roles the security principal assumes.

As I mentioned above, AWS SSO supports both AWS-managed IAM policies and custom IAM policies for permission sets. If you go into the AWS Accounts menu option of AWS SSO you’ll see the accounts associated with the AWS Organization and which permission sets have been associated to the AWS accounts thus resulting in AWS IAM Roles being created within the AWS account. In the image below you can see that I’ve provisioned two permission sets to account1 and account2.

The permission sets tab displays the permission sets I’ve created and whether or not they’ve been provisioned to any accounts. In the screenshot below you’ll see I’ve added four AWS-managed policies for Billing, SecurityAudit, AdministratorAccess, and NetworkAdministrator. Additionally, I created a new permission set named SystemsAdmin which uses a custom IAM policy which restricts the principal assuming the rule to EC2, CloudWatch, and ELB activities.

Back on the AWS organization tab, if you click on an account you can see the AWS SSO Users or Groups that have been assigned to a permission set. In the image below, you can see that I’ve assigned both the B2B Security Admins group and the Security Admins group to the AdministratorAccess permission set and the System Operators group to the SystemsAdmin permission set.

With permission sets out of the way, let’s jump into the scenarios.

Scenario 1 – Windows AD User, AD FS, Azure AD, AWS SSO

In this scenario the user is Bart Simpson who is a member of the System Operators group on-premises and exists authoritatively in a Windows AD forest. A federated trust has been established with Azure AD using an instance of AD FS running on-premises. Azure AD has been integrated with AWS SSO for both SSO (via SAML) and provisioning (via SCIM).

Once Bart was logged into a domain-joined machine, I popped open a browser and navigated to My Apps portal at https://myapps.microsoft.com. This redirected me to the Azure AD login screen. Here I entered Bart’s user name.

Azure AD performed its home realm discovery process, identified that the domain jogcloud.com is configured for federated authentication, and redirected me to AD FS. Take note I purposely broke integrated windows authentication here to show you each step. In a correctly configured browser, you wouldn’t see this screen.

After I successfully authenticated to AD FS, I was bounced back over to Azure AD where the assertion was delivered. Azure AD then whipped up a SAML assertion for AWS SSO, returned it to the browser, and redirected the browser to the AWS SSO assertion consumer URL. AWS SSO consumed the assertion and authenticated Bart into AWS SSO displaying the AWS IAM Role selection page with the relevant roles he has permission to access.

Scenario 2 – Windows AD User, AD FS with Certificate MFA, Azure AD with Conditional Access, AWS SSO

Scenario 1 is pretty simple, so let’s get fancy and layer on some security. Here I added an access control policy into AD FS requiring certificate-based authentication for members of the Security Admins group. Additionally, I added a conditional access policy in Azure AD requiring MFA for any user that is a member of that same group.

Since Homer Simpson regularly runs a nuclear reactor, he’s also the Security Admin for JOGCLOUD. He has been made member of the Windows AD Security Admin group.

As a first step I again popped open a browser and navigated to the My Apps portal. After Homer’s username was plugged in, Azure AD redirected me to the AD FS server. I again broke IWA to capture each step in the process.

After the password challenge was satisfied, I was prompted to provide the appropriate user certificate.

From there I was authenticated to Azure AD and served up the My Apps portal.

Wondering why I wasn’t prompted for Azure MFA? No, I didn’t misconfigure it (at least this time). A not well documented feature (at least in my opinion) of Azure AD is that you can pass a claim asserting a user has satisfied the MFA requirement thus making for a better user experience because the user isn’t required to authenticate multiple times. Yes folks, this means you can layer your traditional certificate-based authentication on top of Azure AD and AWS.

After selecting the AWS SSO app, I was signed into AWS SSO and presented with the role selection screen.

I then selected a one of the roles and was signed into the relevant AWS account assuming the AdministratorAccess IAM Role.

Scenario 3 – Azure AD B2B User, AWS SSO

What if you have a multi-tenant situation due to an acquisition or merger or perhaps you farm out operations to a managed service provider? No worries there, B2B is also supported with this pattern. In this scenario I’m using a user sourced from tenant that has been invited via Azure AD’s B2B. The user has been added to the B2B Security Admins group which exists authoritatively in the inviting tenant (jogcloud.com) and was synchronized to AWS SSO via SCIM.

Opening a browser and navigating to the My Apps portal kicks off Azure AD authentication and drops the user into their source tenant. Once there I can change my tenant by selecting the profile icon and selecting the jogcloud tenant.

I’m then presented with the apps that I’m authorized to use in the jogcloud tenant, which includes the AWS SSO app.

Azure AD kicks off the federated authentication and I’m presented with the AWS role selection page where I can choose to assume the AdministratorAccess role in two of the AWS accounts.

Scenario 4 – AWS CLI

I know what you’re saying now, “But what about CLI?” Well folks, for that you can leverage the AWS CLI v2. It’s still in preview right now, but I did test it using the user from scenario 2 and it worked flawlessly. The experience is pretty anti-climatic so I’m not going to dive into it. The user experience is similar to using the Azure PowerShell cmdlets in that a web browser instance is opened and guides you through the authentication process.

That will sum up this series.

Few technologies get me excited enough to write five posts, but this integration is really amazing. With AWS hooking into Azure AD as effectively as they have (especially love the CLI integration), it reduces operational overhead and improves security which is a combination you rarely see together. Most importantly, it puts the customer first by optimizing the user experience. If you weren’t convinced on Azure AD’s capabilities as an IDaaS, hopefully this series has helped educate you as to the value of the platform.

With that I’ll sign off. A big thanks to the AWS product team that worked on this integration. You did an amazing job that will greatly benefit our mutual customers.

To the rest of you, I wish you happy holidays!

Journey Of The Geek

The chronicles of a Bostonian tech geek navigating through life and technology

Tag Archives: Microsoft

Force Tunneling Azure Firewall to pfSense – Part 2

DNS in Microsoft Azure Part 4 – Private Link DNS

Deep Dive into Azure AD and AWS SSO Integration – Part 5