Summary

The website content describes an AWS user's encounter with a misleading RegionDisabledException error when attempting to use the AssumeRole operation, and their subsequent troubleshooting process to identify the actual issue related to network configurations and private VPC endpoints.

Abstract

The author of the web content experienced an error message (RegionDisabledException) suggesting that STS (Security Token Service) was not activated in a specific region for their AWS account. Despite the error's indication, the author found that STS was indeed enabled and that the error was not accurate. The troubleshooting process involved checking for Service Control Policies (SCPs), verifying network access to STS endpoints, and testing commands in AWS CloudShell. The author discovered that the error was likely due to networking issues within their VPC, particularly with private VPC endpoints, and not due to STS being disabled. They suggest that AWS should provide more accurate error messages to aid in quicker diagnosis and resolution of such issues.

Opinions

The author initially suspected service control policies or regional restrictions as the cause of the error but ruled them out after investigation.
They believe that the error message was misleading, as it suggested a problem with STS activation when the actual issue was related to network configurations.
The author emphasizes the importance of being able to override the region in AWS CLI commands and questions whether this functionality might be inconsistent across different AWS services or commands.
They suggest that the error could be related to the AWS CLI using a different region than intended, or STS attempting to use an endpoint in a region that is not accessible from the user's network.
The author provides guidance on how to check which regions have STS enabled in an AWS account and within SCPs.
They share their findings that the issue might be connected to AWS service endpoints and VPC endpoints, which could block STS operations in certain scenarios like Lambda functions or containers running in a VPC.
The author expresses a desire for AWS to improve the accuracy of their error messages to better reflect the underlying problems, thereby facilitating easier troubleshooting for users.

An error occurred (RegionDisabledException) when calling the AssumeRole operation: STS is not activated in this region for account:xxxxxxxxx. Your account administrator can activate STS in this region using the IAM Console.

This error message is not always accurate

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics | Code.

🔒 Related Stories: Bugs | AWS Security | Secure Code | CloudFormation

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Just got this error. The reason stated in the error message is does not seem to be accurate. But read on.

An error occurred (RegionDisabledException) when calling the AssumeRole operation: STS is not activated in this region for account:xxxxxxxxx. Your account administrator can activate STS in this region using the IAM Console.

I thought this error had something to do with service control policies since you can’t disable STS in certain regions. However, that is not the case because I’m now getting this in an account with no SCPs.

There is no restriction on the region where I am getting this error in the account in question either. I can prove that because I can open up AWS CloudShell in that region and run aws sts get-caller-identity and it works.

I’m using credentials in another account and requiring MFA to assume a role. This has always worked in the past. Why is it not working now?

In the past when I got this error, I tried hard coding the region us-east-1 into the command and I realized it was using the region from the AWS CLI configuration instead. Here’s what I wrote:

Perhaps I had a type in the region portion of the CLI command but shouldn’t that have thrown an error if so? Or is overriding the region not working for all route53 commands. Not sure.

So as I’m working on this I realize that I’m trying to access us-east-2 which is allowed in my network. However, is STS trying to use us-east-1 behind the scenes? Because maybe it can’t get to that endpoint on the network somehow. I try to override us-east-2 with us-east-1 in an assumerole command and the request times out.

I ended up copying the code over to CloudShell in the account where the credentials originate and everything works fine. Therefore this is an erroneous error message and I presume it has to to with networking and private VPC endpoints on my VPC and subnets where I’m using the host that is trying to run the commands. I wish the error message would be adjusted to be more accurate.

If you want to check which regions are enabled in an account:

If you are unfamiliar with the STS region enabling section of the AWS console head over to IAM and click account settings on the left and scroll down.

If you want to check which regions are enabled in your Service Control Policies:

For SCPs that limit access to specific regions for your entire organization (instead of on an account by account basis) check this out:

Root OU Service Control Policies

ACM.170 Secure your organization — before — not after- you start creating new accounts

medium.com

Kind of figured out what is causing this here:

AWS Service Endpoints and VPC Endpoints

ACM.379 Fixing the STS network problem blocking STS assume-role in Lambda and containers

medium.com

Follow for updates.

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab