There can be many reasons behind hitting 502 bad gateway error from an ALB, and most of them can be fixed by following the AWS documentation here. However, if you are serving your backend server in IIS, and its hitting the error only when the ALB to server traffic is on HTTPS, the issue is most likely due to the setting “Require Server Name Indication” as below. This scenario is not covered in the AWS documentation. So, uncheck that setting, and try again. For more information about that setting, refer to Microsoft documentation here.

However, one problem with the example in that documentation is that it only allows the configuration of one role to all users. That means, all users who are assigned the application in Azure AD will get the same access. It is not desirable when we need to have different role based access to the firewalls based on their group membership.

It is possible by modifying the attribute and claims section of the SAML configuration in Azure AD (Section Configure Azure AD SSO, step 6, in the link above)

All we need to do is to configure claim conditions in the SAML attributes and Claims section. Based on the user’s membership, the “adminrole” claim should return the role they can access in the firewall. Refer to the diagram below for example.

What I did here is to add 2 conditions:

• If the user is a member of the group “Firewall Read Only Admins”, then return the rolename “firewallreadonlyadmin”
• If the user is a member of the group “Firewall Admins”, then return the rolename “firewalladmin”

Similarly, any number of roles can be added. Just have to make sure that the admin profiles are created in the firewall with the same names.

So overall, the process is as follows:

1. Within Azure AD, create a number of groups according to the needs, and assign the users
2. Within Azure AD, Enterprise Application for firewall and assign them to the groups accordingly
3. Within the Enterprise application, configure SAML according to the documentation:
4. In the SAML attributes and claim sections, configure claim conditions. Based on the user’s membership, the “adminrole” claim should return the role they can access in the firewall.
5. Configure SAML authentication in the firewall
6. Create the different roles within the firewall based on profile.

The answer is to run the command query user /server:$SERVER.

The answer is from this StackOverflow question.

I have some RHEL 8.3 servers which I need to have security patches, but it should not upgrade to 8.4. This runs on AWS EC2 instances, and it does not have a subscription manager account. So some of the guides available in Red Hat website is not working. I also tried what is given here, but it did not work also. Eventually, I added the following line into the [main] section/etc/yum.conf and it worked.

exclude=redhat-release*

So my final yum.conf looks like this (Note that this could be different according to your needs)

[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
best=True
skip_if_unavailable=False
exclude=redhat-release*

Type dsquery /? in a command prompt.

dsquery user -name Ja*
dsquery group -name Admins

$profiles = ('cliprofilename')
foreach ($profile in $profiles){
echo "working on $profile"
$LogGroups = aws logs describe-log-groups --profile $profile --output text --query 'logGroups[*].[logGroupName]'
    foreach ($lg in $LogGroups) {
    echo "working on $lg"
    aws logs put-retention-policy --log-group-name $lg --retention-in-days 90 --profile $profile
    }
    }

The script requires you to have the AWS CLI profile configured on the machine it runs. Replace the profile name and the retention period to your liking. If ran on EC2 instances with IAM roles, the whole profile part can be skipped also.

This simple app will do the following this for you:

1. Query the running instances in all your accounts specified and display it in a tabular format with an option for you to connect.
2. Once you click connect, depending on the OS type of the instance, it will either create a tunnel to port 22 or 3389 to the instance, and display the local port number. So you can just use the local port number to connect.

So, no need to login to the EC2 console and get the information, no need to find free ports, and so on.

How to use

1. Download the repo
2. Modify the variable ‘profiles’ in the config.py file to include your AWS Config profiles to be used (Those found in ~/.aws/config)
3. Run app.py
4. Open your browser, and go to http://127.0.0.1:5000/

Pre-Requisites

1. Python3, boto3 and some other modules. (Refer to requirements.txt)
2. AWS CLI installed and configured with profiles to use
3. AWS Session Manager plugin installed
4. Your instances should have SSM agent installed and the IAM role should have permissions to be able to manage by SSM
5. Your profiles should have the required IAM permissions

Screenshots

1. HomePage
2. After Connection

Known Issues

1. Not able to handle SSM timeouts
2. Not pretty – Just plain HTML
3. Error handling is not great – Please contribute if you can.

Linux (Just change the region based on your need, or even parameterize it)

#/bin/bash
INSTANCE_ID=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)
NAME_FROM_TAG=$(/usr/local/bin/aws ec2 describe-tags --filters "Name=resource-id,Values=$INSTANCE_ID" "Name=key,Values=Name" --region=ap-southeast-1 --output=text | cut -f5)
HOST_NAME=$(hostname)
if [ -z "$NAME_FROM_TAG" ]
then
      echo "no name set in tags..exiting"
          exit 0
else
      if [ $NAME_FROM_TAG != $HOST_NAME ]
          then
                echo "name changing.."
                hostnamectl set-hostname $NAME_FROM_TAG
          fi
fi

Windows

$instanceId = (Invoke-WebRequest -usebasicparsing -Uri http://169.254.169.254/latest/meta-data/instance-id).Content
Write-Output  "Instance ID Found:$instanceId"
$ec2_name = hostname
Write-Output  "Local hostname found:$ec2_name"
$hostNameFromTag = aws ec2 describe-instances --instance-ids $instanceId --query 'Reservations[].Instances[].Tags[?Key==`Name`].Value' --output text
if (!$hostNameFromTag) { 
		Write-Output  "tags not found or permission denied. exiting"
		exit 1
}
Write-Output  "Hostname required:$hostNameFromTag"

if ($ec2_name -ne $hostNameFromTag){
	Write-Output  "The name set in the instance is different from the name from EC2 tags.."
	Write-Output  "current name is $ec2_name, but the name from tag is $hostNameFromTag"
	Write-Output  "Initiating the name change.."

	try { 
		Rename-Computer -NewName $hostNameFromTag -Force -ErrorAction Stop
	}
		catch {
		  Write-Output  "An error occurred:"
		  Write-Output  $_.ScriptStackTrace
		  Write-Output  $PSItem.Exception.Message
		  exit 1
		}
	Write-Output  "Restarting to effect the name change.."
	shutdown /r /f /t 0
}

else {
	Write-Output  "The name set in the instance is same as the name from the name from EC2 tags.."
}

You probably don’t need to install KB4103720 and KB4462928 if you are looking at this post in 2020 or later, as it should be already installed.

Recently I wanted to configure a maintenance window with an SSM Automation task, but the task did not take any instances as the inputs. The task was supposed to create a new instance and do some stuff on it.

So in order to workound with the limitation in which SSM requires a target to be registered, I just added a dummy instance as the target.

If you are using Terraform, the relevant snippet is as below:

resource "aws_ssm_maintenance_window_target" "ami_patching_maintenance_targets_windows" {
  window_id     = aws_ssm_maintenance_window.ami_patching_maintenance_window_windows.id
  name          = "ami-patching-maintenance-window-target-windows"
  description   = "This is used for patching the AMI"
  resource_type = "INSTANCE"
  #The targets are just kept because of requirement. They are not used
  targets {
    key    = "InstanceIds"
    values = ["i-0000000000012345"]
  }
}

Note, this code expects you to have familiarity with managing SSM using terraform. My particular usecase was to run the AWS-UpdateWindowsAmi SSM automation document in a schedule.