Tag Archives: Azure Active Directory

Enable secure access to applications with Cloudflare WAF and Azure Active Directory

Post Syndicated from Abhi Das original https://blog.cloudflare.com/cloudflare-waf-integration-azure-active-directory/

Enable secure access to applications with Cloudflare WAF and Azure Active Directory

Enable secure access to applications with Cloudflare WAF and Azure Active Directory

Cloudflare and Microsoft Azure Active Directory have partnered to provide an integration specifically for web applications using Azure Active Directory B2C. From today, customers using both services can follow the simple integration steps to protect B2C applications with Cloudflare’s Web Application Firewall (WAF) on any custom domain. Microsoft has detailed this integration as well.

Cloudflare Web Application Firewall

The Web Application Firewall (WAF) is a core component of the Cloudflare platform and is designed to keep any web application safe. It blocks more than 70 billion cyber threats per day. That is 810,000 threats blocked every second.

Enable secure access to applications with Cloudflare WAF and Azure Active Directory

The WAF is available through an intuitive dashboard or a Terraform integration, and it enables users to build powerful rules. Every request to the WAF is inspected against the rule engine and the threat intelligence built from protecting approximately 25 million internet properties. Suspicious requests can be blocked, challenged or logged as per the needs of the user, while legitimate requests are routed to the destination regardless of where the application lives (i.e., on-premise or in the cloud). Analytics and Cloudflare Logs enable users to view actionable metrics.

The Cloudflare WAF is an intelligent, integrated, and scalable solution to protect business-critical web applications from malicious attacks, with no changes to customers’ existing infrastructure.

Azure AD B2C

Azure AD B2C is a customer identity management service that enables custom control of how your customers sign up, sign in, and manage their profiles when using iOS, Android, .NET, single-page (SPA), and other applications and web experiences. It uses standards-based authentication protocols including OpenID Connect, OAuth 2.0, and SAML. You can customize the entire user experience with your brand so that it blends seamlessly with your web and mobile applications. It integrates with most modern applications and commercial off-the-shelf software, providing business-to-customer identity as a service. Customers of businesses of all sizes use their preferred social, enterprise, or local account identities to get single sign-on access to their applications and APIs. It takes care of the scaling and safety of the authentication platform, monitoring and automatically handling threats like denial-of-service, password spray, or brute force attacks.

Integrated solution

When setting up Azure AD B2C, many customers prefer to customize their authentication endpoint by hosting the solution under their own domain — for example, under store.example.com — rather than using a Microsoft owned domain. With the new partnership and integration, customers can now place the custom domain behind Cloudflare’s Web Application Firewall while also using Azure AD B2C, further protecting the identity service from sophisticated attacks.

This defense-in-depth approach allows customers to leverage both Cloudflare WAF capabilities along with Azure AD B2C native Identity Protection features to defend against cyberattacks.

Instructions on how to set up the integration are provided on the Azure website and all it requires is a Cloudflare account.

Enable secure access to applications with Cloudflare WAF and Azure Active Directory

Customer benefit

Azure customers need support for a strong set of security and performance tools once they implement Azure AD B2C in their environment. Integrating Cloudflare Web Application Firewall with Azure AD B2C can provide customers the ability to write custom security rules (including rate limiting rules), DDoS mitigation, and deploy advanced bot management features. The Cloudflare WAF works by proxying and inspecting traffic towards your application and analyzing the payloads to ensure only non-malicious content reaches your origin servers. By incorporating the Cloudflare integration into Azure AD B2C, customers can ensure that their application is protected against sophisticated attack vectors including zero-day vulnerabilities, malicious automated botnets, and other generic attacks such as those listed in the OWASP Top 10.

Conclusion

This integration is a great match for any B2C businesses that are looking to enable their customers to authenticate themselves in the easiest and most secure way possible.

Please give it a try and let us know how we can improve it. Reach out to us for other use cases for your applications on Azure. Register here for expressing your interest/feedback on Azure integration and for upcoming webinars on this topic.

Enable Office 365 with AWS Managed Microsoft AD without user password synchronization

Post Syndicated from Darryn Hendricks original https://aws.amazon.com/blogs/security/enable-office-365-with-aws-managed-microsoft-ad-without-user-password-synchronization/

In this post, we explain how you can use AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) to enable your users to access Microsoft Office 365 without synchronizing passwords using Azure Active Directory (Azure AD) Pass-through Authentication (PTA). This makes it easier to configure Microsoft Office 365 with AWS Managed Microsoft AD. Azure AD PTA reduces management overhead by eliminating the need to deploy and manage complex federation or password synchronization infrastructure. It also helps you meet your organization’s security standards because you can continue to apply and manage stronger password policies using AWS Managed Microsoft AD.

Previously, AWS enabled you to access Office 365 with credentials that you manage in AWS Managed Microsoft AD. AWS did this by deploying Azure AD Connect and Active Directory Federation Services for Windows Server 2016 (AD FS 2016) with AWS Managed Microsoft AD. While AWS continues to support this model, the focus of this post is to explain a new, supported model that produces the same result without deploying a federation or password synchronization implementation. In the new model, when users sign in to Office 365, Azure AD PTA validates their passwords against AWS Managed Microsoft AD directly.

We explain how to use Azure AD Connect to synchronize users from AWS Managed Microsoft AD into Azure AD. We then show you how to enable Azure AD Connect PTA to automatically authenticate users directly against your AWS Managed Microsoft AD directory. We do this in four steps:

  1. Delegate permissions to your Active Directory Domain Services (AD DS) Connector account.
  2. Configure the AWS security group rules for your Azure AD Connect server.
  3. Install and configure Azure AD Connect Pass-through Authentication with AWS Managed Microsoft AD.
  4. Use an AWS Managed Microsoft AD user account to sign in to Office 365.

Prerequisites

The instructions in this post assume that you understand how to create Amazon Elastic Compute Cloud (Amazon EC2) for Windows Server instances and how to use Remote Desktop Protocol (RDP) to log in to the instances. They also assume you completed the following tasks:

  1. Created an AWS Managed Microsoft AD directory.
  2. Joined an Amazon EC2 for Windows Server instance to the AWS Managed Microsoft AD domain you will use as your Azure AD Connect server. We show you how to install Azure AD Connect on this instance later. Azure AD Connect supports Windows Server 2012 R2 or later, for this post, we use Windows Server 2019. While not in scope of this blog, because the Azure AD Connect server only requires outbound traffic, you should run the Azure AD Connect server in a private subnet, with outbound traffic routed via a NAT gateway or instance in a public subnet, see VPC with public and private subnets.
  3. Joined an Amazon EC2 for Windows Server instance to the AWS Managed Microsoft AD domain you will use as your management server instance (Management).
  4. Install Active Directory Administration Tools on your Management instance.
  5. Using Active Directory Users and Computers on your Management instance, create a standard user named AADConnectSvc in your AWS Managed Microsoft AD directory. The AADConnectSvc standard user will be used as your AD DS Connector account. You will use the AD DS Connector account (AADConnectSvc) in Azure AD Connect later.
  6. Created an active Office 365 subscription.
  7. Added and verified your domain in Office 365.

Solution overview

You can use Azure AD Pass-through Authentication with AWS Managed Microsoft AD to:

  • Synchronize users from AWS Managed Microsoft AD to Azure AD.
  • Assign a license to and use an AWS Managed Microsoft AD identity to sign in to Office 365.

Figure 1 shows how Azure AD Connect Server orchestrates the synchronization of AD identities from AWS Managed Microsoft AD to Azure AD. It also shows you how Azure AD Connect Pass-through authentication validates users’ credentials when a user signs in to Office 365.

Figure 1: Architecture diagram of AD synchronization and pass-through authentication between the AWS Managed Microsoft AD and Office 365

Figure 1: Architecture diagram of AD synchronization and pass-through authentication between the AWS Managed Microsoft AD and Office 365

  1. Delegate AD permissions to the AD DS Connector account using the Management instance.
  2. You install and configure Azure AD Connect Pass-through authentication with AWS Managed Microsoft AD.
  3. AWS Managed Microsoft AD identities are synchronized to Azure AD using the Azure AD Connect server.
  4. User signs in to Office 365.
  5. Azure AD communicates with the Azure AD Connect server to validate user credentials.
  6. Azure AD Connect server validates user’s credentials with the AWS Managed Microsoft AD.
  7. User successfully signed in to Office 365 with AWS Managed Microsoft AD credentials.

Note: This blog post uses a single Microsoft Windows Server running Azure AD Connect Pass-through Authentication agent. For high availability, you can install additional Authentication agents on Microsoft Windows Servers, see Ensure high availability.

Step 1: Delegate permissions to your Active Directory Domain Services (AD DS) Connector account

In this step, you delegate basic read AD permissions to your AD DS Connector account (AADConnectSvc). The AD DS Connector account (AADConnectSvc) is used by Azure AD Connect to connect to and read AD objects in your AWS Managed Microsoft AD directory. To delegate the permissions, download and use the ADSyncConfig PowerShell module included in the Azure AD Connect installation.

Perform the following steps after signing in to the Management instance using the admin user account for the AWS Managed Microsoft AD directory:

A. Download the ADSyncConfig PowerShell module from the Azure AD Connect installation

  1. Download and initiate the Azure AD Connect installation on the Management instance.
  2. On the Welcome page of the Microsoft Azure Active Directory Connect wizard, close the installation by selecting x. At this stage, the Azure AD Connect installation has downloaded the ADSyncConfig PowerShell module to the Management instance.
  3. Verify the ADSyncConfig PowerShell module has been downloaded and is in the following location:
    C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1
    

B. Configure permissions to your AD DS Connector account

  1. Import the ADSyncConfig PowerShell module, using the following Windows PowerShell command.
    Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1"
    

  2. Add basic read permissions to your AWS Managed Microsoft AD directory for the AD DS Connector account (AADConnectSvc) by running the following Windows PowerShell command. Be sure to replace the names in <red italic> text with the names from your AWS Managed Microsoft AD directory.
    Set-ADSyncBasicReadPermissions -ADConnectorAccountName AADConnectSvc -ADConnectorAccountDomain “<YourDomain>” -ADobjectDN “OU=Users,OU=<YourNetBIOSName>,DC=<YourDomainSuffix>,DC=<YourDomainRoot>” -SkipAdminSdHolders -Confirm:$false
    

  3. Next, you will add permissions to your AD DS Connector account (AADConnectSvc) by running the following Windows PowerShell command. The permissions allow Azure to manage the source anchor for AWS Managed Microsoft AD identities synchronized to Azure AD. Be sure to replace the names in <red italic> text with the names from your AWS Managed Microsoft AD directory.
    Set-ADSyncMsDsConsistencyGuidPermissions -ADConnectorAccountName AADConnectSvc -ADConnectorAccountDomain “<YourDomain>” -ADobjectDN “OU=Users,OU=<YourNetBIOSName>,DC=<YourDomainSuffix>,DC=<YourDomainRoot>” -SkipAdminSdHolders -Confirm:$false
    

Step 2: Configure the AWS security group rules for your Azure AD Connect server

In this step, you configure the AWS security group rules so that your Azure AD Connect server can communicate with Azure AD. To do this, you must add outbound rules to your Azure AD Connect server AWS security group to allow outbound traffic on HTTPS (port 443) and HTTP (port 80).

Follow these steps to configure AWS security group rules:

  1. In the navigation pane of the Amazon EC2 console, choose Security Groups.
  2. In the list, select the security group for the Azure AD Connect server, and then choose Actions, Edit outbound rules.
  3. Choose Add Rule. Choose HTTPS for Type and Anywhere for Destination. Choose Save rules.
  4. Next, choose Add Rule. Choose HTTP for Type and Anywhere for Destination. Choose Save rules.

Step 3: Install and configure Azure AD Connect Pass-through Authentication with AWS Managed Microsoft AD

Follow the outlined steps to install Azure AD Connect Pass-through Authentication on the Azure AD Connect server. The Azure AD Connect server synchronizes your users from AWS Managed Microsoft AD to Azure AD and manages password validation against your AWS Managed Microsoft AD directory.

Perform the following steps after signing in to the Azure AD Connect server using the admin user account for the AWS Managed Microsoft AD directory:

  1. Download and initiate the installation of Azure AD Connect on the Azure AD Connect server.
  2. On the Welcome page of the Microsoft Azure Active Directory Connect wizard, accept the license terms and privacy notice, and then select Continue.
  3. On the Express Settings page, at the bottom of the page, select Customize.
  4. On the Install required components page, select Install.
  5. On the User sign-in page, select Pass-through authentication, and then select Next.
  6. On the Connect to Azure AD page, enter your Office 365 global administrator account credentials, and then select Next.
  7. On the Connect your directories page, for DIRECTORY TYPE, select Active Directory, and for FOREST, select your AWS Managed Microsoft AD Forest, and then select Add Directory.

    Figure 2: Select a directory to add

    Figure 2: Select a directory to add

  8. In the AD forest account screen, select Use existing AD account, enter your AD DS Connector account (AADConnectSvc) credentials, and then select OK.

    Figure 3: Add an AD forest account

    Figure 3: Add an AD forest account

  9. Now that you’ve added your AWS Managed Microsoft AD directory, on the Connect your directories screen, select Next.
  10. On the Azure AD sign-in configuration page, select userPrincipalName in the USER PRINCIPAL NAME field, and then select Next.
    Figure 4: Select the USER PRINCIPAL NAME

    Figure 4: Select the USER PRINCIPAL NAME

    Note: If you don’t have a matching UPN suffix for your Azure AD domain in AWS Managed Microsoft AD UPN suffix. You can add a new UPN suffix to AWS Managed Microsoft AD. After adding the new UPN suffix to AWS Managed Microsoft AD, you can update your users UPN by following the steps below. The UPN attribute format combines the user’s login name and the UPN suffix. The UPN suffix is your AWS Managed Microsoft AD domain name.

    In the following example from the Account tab of the AWS User Properties in the Active Directory Users and Computers tool, the user’s UPN is [email protected]. The UPN is created by combining the User logon name, awsuser, and the UPN suffix, @awsexample.com.

    Figure 5: Example user properties

    Figure 5: Example user properties

  11. On the Domain and OU filtering page, select Sync selected domains and OUs, choose the Users OU under your NetBIOS OU, and then choose Next.

    Note: AWS Managed Microsoft AD stores your users and computers under a dedicated OU with your domain’s NetBIOS name.

     

    Figure 6: Domain and OU filtering

    Figure 6: Domain and OU filtering

  12. On the Uniquely identifying your users page, select Next.
  13. On the Filter users and devices page, select Next.
  14. On the Optional features page, select Next.
  15. On the Ready to configure page, select Start the synchronization process when configuration completes, and then select Install.
  16. Select Exit. Your Azure AD Connect installation is complete.

Note: By default, the Azure AD Connect sync scheduler runs every 30 minutes to synchronize your AWS Managed Microsoft AD identities to Azure AD. You can change this schedule using PowerShell. For more information, read Azure AD Connect sync: Scheduler.

Tip: If you need to synchronize a change immediately, you can manually start a sync cycle outside the scheduled sync cycle from the Azure AD Connect sync instance. Open a Windows PowerShell session as an administrator and run the following Windows PowerShell commands:

Import-Module ADSync
Start-ADSyncSyncCycle –PolicyType Delta

Step 4: Use an AWS Managed Microsoft AD user account to sign in to Office 365

The following steps explain how to assign a license to an AWS Managed Microsoft AD user account, and then use that account to sign in to Office 365 with the AWS Managed Microsoft AD user account UPN.

  1. Use a web browser to access the Office 365 admin center using your global administrator account.
  2. Assign a license to a user you created in your AWS Managed Microsoft AD directory.
  3. Sign in with the AWS Managed Microsoft AD user account at https://portal.office.com.

You’ve successfully configured and used Azure AD Pass-through and used it to sign in to Office 365 with your AWS Managed Microsoft AD user account!

Note: You can configure Azure AD smart lock out to compliment your AWS Managed Microsoft AD password policies.

Summary

In this post, we showed you how to use Azure AD Connect to synchronize user names from your Active Directory in AWS into Azure AD so that Office 365 can use those identities. You enabled Azure AD Pass-through Authentication to authenticate the identities against your AWS Managed Microsoft AD directory with no passwords synchronized or stored in Azure AD or Office 365.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on the AWS Directory Service forum or contact AWS Support.

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.

Author

Darryn Hendricks

Darryn is a Senior Cloud Support Engineer for AWS Single Sign-On (SSO) based in Seattle. He is passionate about cloud computing, identities, automation, and helping customers leverage these key building blocks when moving to the cloud. Outside of work, he loves spending time with his wife and daughter.

Author

Rogier van Geest

Rogier is a Senior Specialized Solution Architect for Microsoft Workloads on AWS who loves to help customers move the needle on their migrations into the AWS Cloud. In his spare time Rogier is a foodie who enjoys preparing a fresh meal every day.

On-Demand SCIM provisioning of Azure AD to AWS SSO with PowerShell

Post Syndicated from Natalie Doerr original https://aws.amazon.com/blogs/security/on-demand-scim-provisioning-of-azure-ad-to-aws-sso-with-powershell/

In this post, I will demonstrate how you can use a PowerShell script to initiate an on-demand synchronization between Azure Active Directory and AWS Single Sign-On (AWS SSO) and avoid the default 40-minute synchronization schedule between both identity providers. This solution helps enterprises quickly synchronize changes made to users, groups, or permissions within Azure AD with AWS SSO. This allows user or permission changes to be quickly reflected in associated AWS accounts.

Prerequisites

You need the following to complete this session:

This post focuses on the steps needed to set up the on-demand sync solution. You can find specifics on how to set up and use PowerShell and the Azure PowerShell modules at Installing Azure PowerShell.
 

Figure 1: Triggering the SCIM Endpoint to sync all users and groups

Figure 1: Triggering the SCIM Endpoint to sync all users and groups

Grant permission to the Graph API to access the Default Directory in Azure AD

To get started, grant the permissions needed for the application to have access to the directory endpoint.

To grant permissions

  1. Sign in to the Azure Portal and navigate to the Azure AD dashboard.
  2. From the left navigation pane, select App registrations. If you don’t see your application listed, select the All applications tab.
    For this example, I’m using an application named AWS.
     
    Figure 2: Select the AWS app registration

    Figure 2: Select the AWS app registration

  3. Choose API permissions from the navigation pane.
  4. Choose the Add a permission option.
     
    Figure 3: Select the Add API permission

    Figure 3: Select the Add API permission

  5. From the settings page that opens, choose the Microsoft Graph option.
     
    Figure 4: Request API permissions

    Figure 4: Request API permissions

    Under What type of permissions does your application require, select Delegated permissions and enter directory.readwrite.all in the permissions search field. Select Directory.ReadWrite.All and choose Add permissions at the bottom of the page.
     

    Figure 5: Request API permissions - Add permissions

    Figure 5: Request API permissions – Add permissions

  6. On the API permissions page, choose Grant admin consent for Default Directory and select Yes.
     
    Figure 6: Grant permission for the account to have administrator permissions

    Figure 6: Grant permission for the account to have administrator permissions

Create a certificate and secret to access the application

To get started, create a certificate and secret which grants secure access to the AWS application.

To create a certificate and secret

  1. Choose Certificate & secrets from the left navigation menu and then choose New client secret.
     
    Figure 7: Creating a client secret for 1 year

    Figure 7: Creating a client secret for 1 year

  2. Select the desired length of the certificate.
  3. Provide a description and choose Add.
    1. Copy the value of the certificate that’s generated and save it to use later in this process.
    2. After you’ve saved the value to use later, select Home from the top left corner of the screen.
    Figure 8: Make sure you click Copy to clipboard to store the value of the secret

    Figure 8: Make sure you click Copy to clipboard to store the value of the secret

Create a user with permissions to run the code

Now that you’ve given your application access to the directory, let’s create a user and assign the proper permissions to run the code.

To create a user and assign permissions

  1. Choose Azure Active Directory from the Azure services list.
  2. Choose Users and select New user. The User name, First name, and Last name fields are required. In this example, I set the User name and First name to Auth and the Last name to User.
    1. Take note of the password that is set for this user and save it to use later.
    2. Once completed, choose Create.
    Figure 9: Create a user in Azure AD

    Figure 9: Create a user in Azure AD

  3. Select the newly created user from the list.
    1. On the left navigation pane, select Assigned roles.
    2. Choose Add assignments.
    3. Choose Hybrid identity administrator and select Add.
    Figure 10: Assign the user the role to trigger the API

    Figure 10: Assign the user the role to trigger the API

  4. Select Default Directory from the top of the navigation pane.
    1. Choose Enterprise applications.
    2. Choose the AWS application.
    3. Select Assign users and groups.
    Figure 11: Azure Enterprise applications - Assign users and groups

    Figure 11: Azure Enterprise applications – Assign users and groups

  5. Choose + Add user at the top of the window.
    1. Select the user you created earlier. I select Auth as that was the user I created earlier.
    2. Choose Select and then Assign.
    Figure 12: Select the user we created earlier from Figure 9

    Figure 12: Select the user we created earlier from Figure 9

     

    Figure 13: Assign the user to the application

    Figure 13: Assign the user to the application

  6. Now that you’ve added the user, you can see that the user is assigned to the application.
     
    Figure 14: Screen now showing that the user has been assigned to the application

    Figure 14: Screen now showing that the user has been assigned to the application

  7. It’s recommended to log in to the Azure portal as the user you just created in a new incognito or private browser session. As part of the first log in, you’ll be prompted to change the password.

Prerequisites to trigger the SCIM endpoint

You need the following items to run the PowerShell code that triggers the endpoint.

  1. From the application registration, retrieve the items shown below. Note that you must use the client secret saved earlier when the certificate was created.
    • Tenant ID
    • Display name
    • Application ID
    • Client secret
    • User name
    • Password
  2. Copy the items to a notepad in the preceding order so you can enter all of them through a single copy and paste action while running the script.
  3. From the menu, select Azure Active Directory.
  4. Choose App registrations and select the AWS App that was set up.
  5. Copy the Application (client) ID and the Directory (tenant) ID.
Figure 15: App registration contains all the items needed for the PowerShell script

Figure 15: App registration contains all the items needed for the PowerShell script

Trigger the SCIM endpoint with PowerShell

Now that you’ve completed all of the previous steps, you need to copy the code from the GitHub repository to your local machine and run it. We’ve configured the code to run manually, but you can also automate it to trigger an Azure Automation runbook when users are added to Azure through Alerts. You can also configure CloudWatch Events to run a Lambda function at periodic intervals.

To trigger the SCIM endpoint

  1. Copy the code from the GitHub repository.
  2. Save the code using the code editor of your choice, or you can download Visual Studio Code. Give the file a user-friendly name, such as Sync.ps1.
  3. Navigate to the location where you saved the file and run ./sync.ps1.
  4. When prompted, enter the values from the notepad. You can paste these all at one time so you don’t have to copy and paste each individual item.

    Note: When copying and pasting in Windows, choose the PowerShell icon, then Edit > Paste.

     

    Figure 16: Windows Command Prompt – Select Paste to copy all items needed to trigger the sync

    Figure 16: Windows Command Prompt – Select Paste to copy all items needed to trigger the sync

After you paste the values into the PowerShell window, you see the script input as shown in the following screenshot. The client secret and password are secure values and are masked for security purposes.
 

Figure 17: PowerShell script with input values pasted in

Figure 17: PowerShell script with input values pasted in

After the job has started in PowerShell, two messages are displayed. One indicating that synchronization is starting and a following message when synchronization has completed. Both are shown in the following figure.
 

Figure 18: Output from a successful run of the PowerShell script

Figure 18: Output from a successful run of the PowerShell script

View the synchronization status and logs

To verify that the job ran successfully, you can check the completed time from the Azure portal. You can verify the time the script ran by viewing the completion time along with the current status.

To view the status and logs

  1. From the menu, choose Azure Active Directory.
  2. Choose Enterprise applications and select the AWS App.
  3. From the left navigation menu, choose Provisioning and then choose View provisioning details. This displays the last time the sync completed.
     
    Figure 19: View the Provisioning details about the job

    Figure 19: View the Provisioning details about the job

Summary

In this post, I demonstrate how you can use a PowerShell script to trigger the SCIM endpoint to on-demand synchronize Azure AD with AWS Single Sign-On. You can find the code in this GitHub repository and use it to synchronize user and group changes on demand.

If you have feedback about this post, submit comments in the Comments section below.

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.

Author

Aidan Keane

Aidan is a Senior Technical Account Manager for AWS Enterprise Support. He has been working with Cloud technologies for more than 5 years. Outside of technology, he is a sports enthusiast who enjoys golf, biking, and watching Liverpool FC. He spends his free time with his family and enjoys traveling to Ireland and South America.