DEV Community: David Omokhodion

Building Out Your Active Directory Homelab - A Hands-on Guide

David Omokhodion — Tue, 19 May 2026 11:30:49 +0000

Setting up an Active Directory domain from scratch is one of the most valuable hands-on projects a Windows sysadmin can have in their portfolio. In this guide, you will build a fully functional simulated enterprise environment — complete with a Domain Controller, Group Policy, DNS, DHCP, and domain-joined workstation.

Skill level: Intermediate
What you need: 2 Windows VMs with at least 4 GB RAM each

Key Concepts

Before touching a single command, here is the mental model you need.

Concept	What it is
Active Directory Domain Services (AD DS)	Microsoft's directory service. Stores information about every user, computer, and resource on a network, and controls who can access what.
Domain Controller (DC)	The server running AD DS. It authenticates logins, enforces policies, and is the authority for the entire domain.
Organisational Units (OUs)	Folders inside AD. You group users and computers into OUs so different policies can be applied to different departments cleanly.
Group Policy Objects (GPOs)	Rules linked to OUs that control security settings, drive mappings, restrictions, and more — applied automatically to every machine in scope.
DNS	AD DS relies entirely on DNS to locate the Domain Controller. Without correct DNS, domain joins fail and logins fail.
DHCP	Automatically assigns IP addresses and can push the correct DNS server address to every device on the network.

How they fit together: AD DS is the database, the Domain Controller hosts it, OUs organise the records inside it, and GPOs are the rules attached to those records. DNS is the glue that lets every machine find the DC in the first place.

Lab Architecture

[Proxmox Host]
   ├── DC01  —  Windows Server 2022  —  192.168.100.27  (Domain Controller)
   └── WS01  —  Windows 11           —  192.168.100.28  (Domain Member)

Gateway: 192.168.100.1
Domain:  contoso.local

VM Specs

VM	OS	Role	RAM	Disk	IP
DC01	Windows Server 2022 (Desktop Experience)	Domain Controller	4 GB	60 GB	`192.168.100.27` (static)
WS01	Windows 10 or 11	Client workstation	4 GB	60 GB	`192.168.100.28`

Phase 1 — Install & Configure DC01

Boot DC01 from the Windows Server 2022 ISO. Select Windows Server 2022 Standard (Desktop Experience) when prompted. Complete the installation and set a strong Administrator password.

Set a static IP address

A Domain Controller must always be reachable at the same IP. Dynamic addresses will break DNS and domain joins. Open PowerShell as Administrator:

# Set static IP
New-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress "192.168.100.27" `
 -PrefixLength 24 -DefaultGateway "192.168.100.1"


### Rename the computer
Rename-Computer -NewName "DC01" -Restart

The VM reboots. Log back in as Administrator before continuing.

Phase 2 — Promote DC01 to Domain Controller

Install the AD DS and DNS roles

Install-WindowsFeature -Name AD-Domain-Services, DNS -IncludeManagementTools

⚠️ Common mistake: Install-WindowsFeature only exists on Windows Server. If you see "term not recognised", you are running this on the wrong machine — confirm you are on DC01 running Server 2022, not your Windows 10/11 workstation.

Promote to Domain Controller

This command creates a new forest and domain called contoso.local. DC01 reboots automatically when complete.

Install-ADDSForest `
 -DomainName "contoso.local" `
 -DomainNetBiosName "CONTOSO" `
 -SafeModeAdministratorPassword (ConvertTo-SecureString "P@ssw0rd123!" -AsPlainText -Force) `
 -InstallDns `
 -Force

After the reboot, log in as CONTOSO\Administrator. The login screen now shows the domain name — promotion was successful.

Connect via RDP from from your machine

First, go into the DC01 and enable remote desktop.

Next, if you are managing DC01 from a Linux machine using xfreerdp:

xfreerdp /v:192.168.100.27 /u:Administrator /d:CONTOSO /p:'YourPassword' /cert:ignore /dynamic-resolution /clipboard

Alternatively, you could connect using a GUI RDP client like Remmina (On Linux) or Remote Desktop. Remember that "domain" is CONTOSO

Phase 3 — Build the OU Structure

Organisational Units are the filing system of Active Directory. A well-designed OU structure makes GPO targeting clean and mirrors how real enterprises are organised.

contoso.local
└── Contoso Corp
   ├── IT
   ├── HR
   ├── Finance
   ├── Sales
   ├── Servers
   ├── Service Accounts
   └── _Admin

$domain = "DC=contoso,DC=local"

# Top-level OU
New-ADOrganizationalUnit -Name "Contoso Corp" -Path $domain

$base = "OU=Contoso Corp,$domain"

# Department OUs
foreach ($ou in @("IT","HR","Finance","Sales","Servers","Service Accounts","_Admin")) {
   New-ADOrganizationalUnit -Name $ou -Path $base
}

✅ The _Admin OU uses an underscore prefix so it sorts to the top alphabetically — a common real-world convention for keeping privileged accounts visually separated from standard department OUs.

Phase 4 — Create Users & Groups

Rather than creating users manually through the GUI, use PowerShell (exactly how sysadmins handle bulk provisioning in production).

Create security groups

$groups = @("IT-Team","HR-Team","Finance-Team","Sales-Team")
foreach ($g in $groups) {
   New-ADGroup -Name $g -GroupScope Global -GroupCategory Security `
     -Path "OU=IT,OU=Contoso Corp,DC=contoso,DC=local"
}

Bulk-create users

$domain = "DC=contoso,DC=local"

$users = @(
   @{First="Alice"; Last="Johnson"; Dept="IT";      OU="IT"},
   @{First="Bob";   Last="Smith";   Dept="HR";      OU="HR"},
   @{First="Carol"; Last="Davis";   Dept="Finance";  OU="Finance"},
   @{First="Dan";   Last="Lee";     Dept="Sales";    OU="Sales"}
)

foreach ($u in $users) {
   $username  = ($u.First[0] + $u.Last).ToLower()
   $upn       = "$username@contoso.local"
   $ouPath    = "OU=$($u.OU),OU=Contoso Corp,$domain"
   $password  = ConvertTo-SecureString "Welcome1!" -AsPlainText -Force

   New-ADUser `
       -GivenName       $u.First `
       -Surname         $u.Last `
       -Name            "$($u.First) $($u.Last)" `
       -SamAccountName  $username `
       -UserPrincipalName $upn `
       -Department      $u.Dept `
       -Path            $ouPath `
       -AccountPassword $password `
       -Enabled         $true `
       -PasswordNeverExpires $false `
       -ChangePasswordAtLogon $false
}

⚠️ RDP gotcha: Setting -ChangePasswordAtLogon $true blocks RDP logins entirely — the protocol cannot prompt for a password change mid-connection. Keep it $false for lab use. In production, set it to $true so users choose their own password on first login.

Phase 5 — Configure Group Policy Objects (GPOs)

Group Policy Objects (GPOs) are rules you create and link to Organisational Units. Every user and computer inside that OU automatically receives and enforces those rules — no manual configuration needed on each machine. You manage GPOs through the Group Policy Management Console (GPMC), which was installed alongside AD DS earlier.

Open GPMC from DC01 via: Server Manager → Tools → Group Policy Management

GPO 1 — Security Baseline (linked to Contoso Corp)

This GPO applies to every user and computer under the Contoso Corp OU — think of it as your organisation-wide minimum security standard.

First, create and link the GPO via PowerShell:

New-GPO -Name "Security Baseline"
New-GPLink -Name "Security Baseline" -Target "OU=Contoso Corp,DC=contoso,DC=local"

Then configure the settings inside GPMC.

To find it, in the left panel, expand:
Forest: contoso.local → Domains → contoso.local → Group Policy Objects
You should see Security Baseline listed there.

Right-click Security Baseline → Edit to open the Group Policy Management Editor, then follow each path below:

Enforce UAC (User Account Control) UAC is a Windows security feature that prevents unauthorised changes to the system by prompting for administrator approval. Enforcing it via GPO ensures users cannot disable it locally.

Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options

Set "User Account Control: Run all administrators in Admin Approval Mode" → Enabled

Minimum Password Length

Enforces that no account in the domain can have a password shorter than 12 characters.

Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Password Policy

Set "Minimum password length" → 12 characters

Account Lockout Policy

Locks an account after repeated failed login attempts, protecting against brute-force attacks. After 15 minutes the account unlocks automatically.

Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Account Lockout Policy

Set "Account lockout threshold" → 5 invalid logon attempts
Set "Account lockout duration" → 15 minutes
Set "Reset account lockout counter after" → 15 minutes

GPO 2 — Workstation Lockdown (linked to non-IT OUs)

This GPO restricts what standard users can do on their workstations. You will link it to HR, Finance, and Sales — but not IT, since your IT team needs unrestricted access to manage systems.

First, create and link the GPO to each non-IT department OU:

New-GPO -Name "Workstation Lockdown"

# Link to each non-IT OU
foreach ($ou in @("HR","Finance","Sales")) {
   New-GPLink -Name "Workstation Lockdown" `
     -Target "OU=$ou,OU=Contoso Corp,DC=contoso,DC=local"
}

Then in GPMC, right-click Workstation Lockdown → Edit

... then configure the following:

Disable Access to Control Panel and PC Settings

Prevents standard users from changing system settings, uninstalling software, or modifying network configuration — common restrictions in managed enterprise environments.

User Configuration → Policies → Administrative Templates → Control Panel (Click on it)

Double-click "Prohibit access to Control Panel and PC Settings" → Set to Enabled → Click OK

Prevent Access to Command Prompt

The Command Prompt (cmd.exe) can be used to bypass desktop restrictions. Disabling it for non-IT users reduces the risk of accidental or deliberate system changes.

User Configuration → Policies → Administrative Templates → System

Double-click "Prevent access to the command prompt" → Set to Enabled

When prompted "Disable the command prompt script processing also?" → Select No (selecting Yes would also break logon scripts, which you don't want)

Click OK

Remove Run Dialog from Start Menu

The Run dialog (Win + R) gives users a quick way to launch programs and access network paths, which can be used to circumvent other restrictions. Removing it closes that gap.

User Configuration → Policies → Administrative Templates → Start Menu and Taskbar

Double-click "Remove Run menu from Start Menu" → Set to Enabled → Click OK

Verify the GPO is linked correctly

foreach ($ou in @("HR","Finance","Sales")) {
   Write-Host "`n--- $ou ---"
   Get-GPInheritance -Target "OU=$ou,OU=Contoso Corp,DC=contoso,DC=local" |
     Select-Object -ExpandProperty GpoLinks
}

You should see Workstation Lockdown listed under each of the three OUs.

GPO 3 — IT Drive Mapping (linked to IT OU)

First create the share on DC01:

New-Item -Path "C:\Shares\ITShare" -ItemType Directory
New-SmbShare -Name "ITShare" -Path "C:\Shares\ITShare" `
 -FullAccess "CONTOSO\IT-Team" -ReadAccess "CONTOSO\Domain Users"

Next, Create the Drive Map in GPMC manually...
This part is done entirely through the GUI. In GPMC, right-click Workstation Lockdown (or whichever GPO is linked to the IT OU) → Edit, then navigate to:

User Configuration → Preferences → Windows Settings → Drive Maps

Right-click in the right-hand pane → New → Mapped Drive

Then in GPMC: User Configuration → Preferences → Windows Settings → Drive Maps → map \\DC01\ITShare to Z: for the IT OU.

Phase 6 — Join WS01 to the Domain

On WS01, first point DNS at DC01. Without this, WS01 cannot resolve contoso.local and the domain join will fail.

Step 1: Open Network Settings → Change adapter options → IPv4 Properties. Set Preferred DNS to 192.168.100.27.

Step 2: Join the domain — run this on WS01 as Administrator:

Add-Computer -DomainName "contoso.local" `
 -Credential (Get-Credential) `
 -OUPath "OU=IT,OU=Contoso Corp,DC=contoso,DC=local" `
 -Restart

Step 2.5: Allow ajohnson to use RDP
Domain users are not automatically allowed to RDP into machines — you need to add them to the local Remote Desktop Users group on WS01:

powershellAdd-LocalGroupMember -Group "Remote Desktop Users" -Member "CONTOSO\ajohnson"

Or to allow all domain users to RDP into WS01:

powershellAdd-LocalGroupMember -Group "Remote Desktop Users" -Member "CONTOSO\Domain Users"

Step 3: RDP into WS01 from Linux as a domain user:

xfreerdp /v:192.168.100.28 /u:ajohnson /d:CONTOSO /p:'Welcome1!' /cert:ignore /dynamic-resolution /clipboard

Step 4: Verify GPOs applied correctly:

# Quick summary in terminal
gpresult /r

# Full HTML report
gpresult /h "C:\Users\ajohnson\Documents\gp-report.html"

Bonus — DNS & DHCP

Verify and extend DNS

Do the the following in DC01...

# View all DNS zones
Get-DnsServerZone

# View A records in contoso.local
Get-DnsServerResourceRecord -ZoneName "contoso.local" -RRType A

# Add a custom record for a simulated intranet server
Add-DnsServerResourceRecordA -ZoneName "contoso.local" `
 -Name "intranet" -IPv4Address "192.168.100.29"

Install and configure DHCP

Install-WindowsFeature DHCP -IncludeManagementTools

Add-DhcpServerv4Scope -Name "CorpLAN" `
 -StartRange "192.168.100.100" -EndRange "192.168.100.199" `
 -SubnetMask "255.255.255.0"

Set-DhcpServerv4OptionValue -ScopeId "192.168.100.0" `
 -DnsServer "192.168.100.27" -Router "192.168.100.1"

Add-DhcpServerInDC -DnsName "dc01.contoso.local"

Skills This Project Demonstrates

Active Directory DS — forest/domain deployment, OU structure design
Group Policy — security baseline, account lockout, drive map preferences
DNS & DHCP — zone management, custom records, scope configuration
PowerShell automation — bulk user/group creation, role installation
Windows networking — static IPs, domain join, name resolution
Security fundamentals — password policy, account lockout, UAC enforcement

Wrapping Up

You now have a fully functional enterprise-grade Active Directory environment running in your lab — a Domain Controller, a domain-joined workstation, a structured OU hierarchy, enforced Group Policy, DNS, and DHCP, all provisioned largely through PowerShell.

Want to extend this? Here are possible next steps:

Add a second domain controller and explore AD replication — understanding how DCs sync is essential knowledge for any enterprise environment
Set up RSAT on WS01 and practice managing the domain entirely from the workstation, the way most administrators actually work day-to-day
Simulate a user offboarding workflow — disable the account, move it to a dedicated Disabled OU, strip group memberships, and document the process as a runbook
Explore fine-grained password policies — apply stricter password requirements to the _Admin OU without affecting standard users
Break something on purpose — delete a GPO link, misconfigure DNS, corrupt a user account — and practice diagnosing and recovering from it. Troubleshooting under pressure is a skill, and the only way to build it is to practise it in a safe environment

Found this useful? Drop a comment below or connect with me — I am always happy to talk through home lab setups and sysadmin career questions.

-> See the GitHub Repo
-> Connect with me On LinkedIn

Stop Getting 'Access Denied': Fixing Cross-Account Access in AWS with IAM STS

David Omokhodion — Tue, 03 Mar 2026 23:56:18 +0000

If you've ever worked in a multi-account AWS environment, you've probably hit the dreaded AccessDenied error when trying to access resources across accounts. Whether it's sharing data between dev and prod accounts, aggregating logs to a central security account, or enabling cross-team collaboration, cross-account access is essential—but it's also where many engineers struggle.

In this post, I'll show you exactly how to implement secure cross-account resource access using AWS Identity & Access Management (IAM) with AWS Security Token Service (STS) with a real-world example: a Lambda function that tracks the International Space Station's location and stores the data in an S3 bucket in a different AWS account.

Prerequisites

Have Terraform installed
Have access to 2 AWS accounts

🏗️ The Architecture

Here's what we're building:

Account A (Source):

Lambda function that fetches ISS position data
IAM execution role with permission to assume a role in Account B
EventBridge trigger (runs every 5 minutes)

Account B (Target):

S3 bucket for storing ISS position logs
IAM role that trusts Account A's Lambda role
Policies granting S3 access to the trusted role

The Flow:

EventBridge triggers Lambda in Account A
Lambda calls sts:AssumeRole to get temporary credentials for Account B
Lambda uses temporary credentials to read/write to S3 bucket in Account B
Lambda fetches ISS position from public API and appends it to a file pulled from s3
Lambda pushes the update file back to s3

🛠️ Let's Implement the Trust Chain

Step 1: Configure the Terraform Providers

Configure you cli with credentials from account A. Then run aws sts get-caller-identity to get your identity.
e.g

{
    "UserId": "<redacted>",
    "Account": "<redacted>",
    "Arn": "arn:aws:iam::<redacted>:user/nobleman"
}

Next, create a role (called terraform, for example) in account B. In its trust relationship, allow the previous identity to assume it.

For example...

{
    ...
    "Statement": [
        {
            ...
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::<redacted>:user/nobleman"
                ]
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Next, configure Terraform providers for both accounts like this...

terraform {
  required_version = ">= 1.0.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

provider "aws" {
  region = "us-east-1"
  # role_arn is set in ~/.aws/config
}

provider "aws" {
  region = "us-east-1"
  alias  = "account_b"

  assume_role {
    role_arn = "arn:aws:iam::${var.account_b_id}:role/terraform"
  }
}

Step 2: Lambda's Execution Role (Account A)

Next, create a role that Lambda can assume:

# Account A: Role that Lambda assumes
resource "aws_iam_role" "cross_account_role" {
  name               = "connect-to-bridge"
  assume_role_policy = data.aws_iam_policy_document.ec2_assume_role.json
}

# Trust policy: Allow Lambda service to assume this role
data "aws_iam_policy_document" "ec2_assume_role" {
  statement {
    effect  = "Allow"
    actions = ["sts:AssumeRole"]

    principals {
      type        = "Service"
      identifiers = ["lambda.amazonaws.com"]
    }
  }
}

What this means: The Lambda service can wear this role like a badge.

Step 3: Grant Role Permission to Assume Cross-Account Role

Now we give this role permission to assume another role in Account B:

# Account A: Policy that allows assuming role in Account B
data "aws_iam_policy_document" "assume_cross_account_role" {
  statement {
    effect    = "Allow"
    actions   = ["sts:AssumeRole"]
    resources = [aws_iam_role.access_s3_bucket.arn]  # Role in Account B
  }
}

resource "aws_iam_role_policy_attachment" "ec2_assume_cross_account" {
  role       = aws_iam_role.cross_account_role.name
  policy_arn = aws_iam_policy.assume_cross_account_role.arn
}

What this means: "Hey Lambda role, you're allowed to assume the access_s3_bucket role in Account B."

Step 4: The Target Role in Account B

Here's the role in Account B with the crucial trust policy:

# Account B: Role that grants S3 access
resource "aws_iam_role" "access_s3_bucket" {
  provider = aws.account_b  # Important: This is in Account B

  name               = "access-s3-bucket"
  assume_role_policy = data.aws_iam_policy_document.allow_role_assumption_a.json
}

# Trust policy: Allow Account A's role to assume this role
data "aws_iam_policy_document" "allow_role_assumption_a" {
  statement {
    effect = "Allow"

    principals {
      type        = "AWS"
      identifiers = [aws_iam_role.cross_account_role.arn]  # Account A role ARN
    }

    actions = ["sts:AssumeRole"]
  }
}

This is the key: Account B explicitly trusts Account A's role. Without this trust relationship, the assume role call will fail.

Step 5: Grant S3 Permissions to the Account B Role

data "aws_iam_policy_document" "s3_bucket_access" {
  statement {
    effect = "Allow"

    actions = [
      "s3:GetObject",
      "s3:PutObject",
      "s3:DeleteObject",
      "s3:ListBucket"
    ]

    resources = [
      module.reporting-bucket.s3_bucket_arn,
      "${module.reporting-bucket.s3_bucket_arn}/*"
    ]
  }
}

resource "aws_iam_role_policy_attachment" "s3_bucket_access_attachment" {
  provider   = aws.account_b
  role       = aws_iam_role.access_s3_bucket.name
  policy_arn = aws_iam_policy.s3_bucket_access.arn
}

The complete trust chain:

→ Lambda Service assumes Lambda Execution Role (Account A) 
→ Lambda Execution Role (Account A) assumes S3 Access Role (Account B) 
→ S3 Access Role (Account B) has permission to S3 Bucket (Account B)

💻 The Lambda Implementation

Now let's look at how the Lambda function uses STS to assume the cross-account role:

import boto3
import os
import urllib3
import json
from datetime import datetime

def lambda_handler(event, context):
    # Environment variables from Terraform
    account2_role_arn = os.environ['ACCOUNT2_ROLE_ARN']
    bucket_name = os.environ['BUCKET_NAME']
    bucket_region = os.environ['BUCKET_REGION']
    object_key = 'iss_position.txt'

    # Step 1: Assume the role in Account B using STS
    sts_client = boto3.client('sts')
    assumed_role = sts_client.assume_role(
        RoleArn=account2_role_arn,
        RoleSessionName='LambdaCrossAccountS3Access'
    )

    # Step 2: Extract temporary credentials
    credentials = assumed_role['Credentials']

    # Step 3: Create S3 client with temporary credentials
    s3_client = boto3.client(
        's3',
        aws_access_key_id=credentials['AccessKeyId'],
        aws_secret_access_key=credentials['SecretAccessKey'],
        aws_session_token=credentials['SessionToken'],
        region_name=bucket_region
    )

    # Step 4: Read existing file from S3
    response = s3_client.get_object(Bucket=bucket_name, Key=object_key)
    content = response['Body'].read().decode('utf-8')

    # Step 5: Fetch ISS position from public API
    http = urllib3.PoolManager()
    response = http.request("GET", "http://api.open-notify.org/iss-now.json")
    data = json.loads(response.data.decode("utf-8"))
    timestamp = datetime.fromtimestamp(data['timestamp'])

    # Step 6: Append new data
    new_content = content + f"""Time: {timestamp}
Latitude: {data['iss_position']['latitude']}
Longitude: {data['iss_position']['longitude']}

"""

    # Step 7: Write back to S3 using temporary credentials
    s3_client.put_object(
        Bucket=bucket_name,
        Key=object_key,
        Body=new_content
    )

    return {
        'statusCode': 200,
        'body': 'Cross-account S3 access successful'
    }

Key Points:

sts_client.assume_role(): This is where the magic happens. Lambda uses its execution role to request temporary credentials for the Account B role.
Temporary Credentials: STS returns short-lived credentials (valid for 1 hour by default). These credentials have all the permissions of the assumed role.
Session Name: The RoleSessionName appears in CloudTrail logs, making it easier to audit who assumed the role and when.
Explicit Credential Usage: We explicitly pass the temporary credentials to the S3 client. This is different from the default boto3 behavior which uses the Lambda's execution role.

📦 Deployment

Prerequisites:

Two AWS accounts (A & B)
AWS CLI configured with access to Account A
Terraform >= 1.0
A pre-existing terraform role in Account B that Account A can assume

Steps:

Clone the repository:

git clone https://github.com/nobleman97/cross-account-iam.git
cd cross-account-iam

Create a dev.tfvars file:

account_b_id = "123456789012"  # Replace with your Account B ID

Deploy the infrastructure:

cd infra
terraform init
terraform plan -var-file=dev.tfvars
terraform apply -var-file=dev.tfvars

Watch it work:

# Check Lambda logs
aws logs tail /aws/lambda/write-report-to-crossaccount-s3 --follow

# After 5-10 minutes, check the S3 file in Account B
aws s3 cp s3://iss-reporting-24534576df/iss_position.txt - \
  --profile account-b

If setup properly, the file should look something like this:

ISS Location Logs
===================


Time: 2025-12-06 17:19:45
Latitude: -50.5587
Longitude: 122.1887

Time: 2025-12-06 17:29:07
Latitude: -32.9030
Longitude: 163.3656

...

Common Pitfalls and Solutions

Problem 1: "User is not authorized to perform: sts:AssumeRole"

Cause: The role in Account A doesn't have permission to assume the role in Account B.

Solution: Verify the policy attachment:

aws iam list-attached-role-policies --role-name connect-to-bridge

Problem 2: "AccessDenied" when accessing S3

Causes:

The trust policy in Account B doesn't trust Account A's role
The role in Account B doesn't have S3 permissions
The S3 bucket has a restrictive bucket policy

Debug:

# Check trust policy
aws iam get-role --role-name access-s3-bucket \
  --profile account-b --query 'Role.AssumeRolePolicyDocument'

# Check attached policies
aws iam list-attached-role-policies --role-name access-s3-bucket \
  --profile account-b

Problem 3: Terraform Can't Create Resources in Account B

Cause: Terraform doesn't have permission to assume the role in Account B.

Solution: Ensure you have a terraform role in Account B with this trust policy:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "<arn_of_cli_identity>"
    },
    "Action": "sts:AssumeRole"
  }]
}

🎓 Key Takeaways

Two-Way Trust: Cross-account access requires both accounts to cooperate:
- Account A must be allowed to assume roles in Account B
- Account B must trust Account A's role
STS is Your Friend: Temporary credentials are more secure than permanent access keys. They expire automatically and can be audited.

Conclusion

Cross-account IAM access doesn't have to be scary. By understanding the trust relationships, using STS for temporary credentials, and following least privilege principles, you can securely share resources across AWS accounts.

The pattern I've shown here—Lambda in Account A assuming a role in Account B to access S3—applies to many other scenarios:

EC2 instances accessing DynamoDB in another account
Step Functions orchestrating resources across accounts
EventBridge forwarding events between accounts
Centralized logging and monitoring

Have you implemented cross-account access in your AWS environment? What challenges did you face? Drop a comment below!

Resources

If you found this helpful, consider starring the GitHub repo and sharing it with your team!

Docker Networking 101: A Blueprint for Seamless Container Connectivity

David Omokhodion — Wed, 13 Dec 2023 14:05:42 +0000

Docker is a platform for developing, shipping, and running applications in containers. Containers are lightweight, standalone, and executable software packages that include everything needed to run a piece of software, including the code, runtime, libraries, and system tools. Docker provides a consistent and reproducible environment across different environments, making it easier to build, deploy, and scale applications.

To enable communication between containers, your host and the outside world, docker implements an interesting networking system. It is this system that bridges the gap between isolated containers, allowing them to function as well-coordinated services.

In this article, you will learn about the basics of the different network types and how to use them in development or deployment.

We will cover:

Docker Network Types
Using Docker Networks

Prerequisites

Have Docker Engine Installed
Have a basic understanding of Docker

Docker Network Types

Docker comes with 7 (rumours say there are more) network types. However, we will discuss the most important four. They are:

None
Bridge (default)
Bridge (user-defined)
Host

If you already have Docker setup on your host machine, and you run the command "docker network list", you should get an output similar to this:

$ docker network list
NETWORK ID     NAME      DRIVER    SCOPE
6f23ed77734d   bridge    bridge    local
3bbca0d09738   host      host      local
a67ca10d6dfd   none      null      local

"Driver" in this list, tells us the network type, and by default, docker creates one bridge, host and null(none) network each.

Let's discuss each network type in more detail...

1. None

None is a docker network-type where the container is not attached to any network. As a result, the container is unable to communicate with any external network or other containers. It is isolated from every other network.

You can run an nginx container in a "none" network type using the following command:

docker run -d --network none --name my_nginx nginx

2. Bridge (default)

The bridge network mode sets up an internal private network within the host. This allows communication between containers within such network, but isolates them from the host's network.

When docker containers are created without specifying a network, they are automatically placed in the default bridge network.

For example:

# running a container in the default bridge network
$ docker run -dit --name Rock nginx

3. Bridge (user-defined)

This network type is similar to the user-defined bridge network. It also creates an internal private network within the host, but it does not come already created by Docker. You have to create it yourself.

Here's how you create a user-defined bridge network called "demo_net":

# create a user-defined bridge network
$ docker network create -d bridge demo_net

# list all your docker networks
$ docker network list
NETWORK ID     NAME       DRIVER    SCOPE
6f23ed77734d   bridge     bridge    local
7a824036d47a   demo_net   bridge    local
3bbca0d09738   host       host      local
a67ca10d6dfd   none       null      local

Here's how to attach a container to the user-defined bridge network you just created...

# Attaching containers to bridged network
$ docker run -dit --network demo_net --name service_A nginx

# create another container and publish a port
$ docker run -dit -p 8000:80 --network demo_net --name service_B nginx

service_A and service_B containers are now attached to the 'demo_net' network. By default, all containers within the same network can communicate with one another freely but are isolated from the host network and other user-defined networks.

In order to access applications running on these containers from the host network, we have to publish (or expose) ports from the containers. In the snippet above, port 80 on service_B container is mapped to port 8000 on the host, allowing access to an application running on service_B's container port 80 to be accessed from port 8000 on the host.

4. Host

Containers in host network mode directly utilize your host's network stack, lacking isolation. They do not receive separate IP addresses, and any port bindings are directly exposed on your host's network interface. In practical terms, if a container process is configured to listen on port 80, it will bind to your host machine's IP address on port 80.

Here's an example of a container that binds nginx to a host network:

# bind container to host network
docker run -d --network host --name my_nginx nginx

If you're using the host's network for your web container (like Nginx), it means you can't run multiple web containers on the same host and port. This is because they would all share the same network settings, causing conflicts.

Using Docker Networks

Testing Communications Within and Between Networks

In an earlier step, we attached two containers (service_A and service_B) to the demo_net network. Let's confirm that they can communicate with one another within the same network and whether they can communicate with a container in a different network(e.g the "Rock" container in the default bridge network).

# open a shell into service_A container
$ docker exec -it service_A /bin/bash

# when inside service_A container update its apt repos and install ping
$ apt update && apt install iputils-ping -y

# Then ping service_B using the container name because name resolution is automatically enabled within the network 
$ ping service_B

root@06dbaea8c2a2:/# ping service_B
PING service_B (172.18.0.3) 56(84) bytes of data.
64 bytes from service_B.demo_net (172.18.0.3): icmp_seq=1 ttl=64 time=0.086 ms
64 bytes from service_B.demo_net (172.18.0.3): icmp_seq=2 ttl=64 time=0.154 ms
64 bytes from service_B.demo_net (172.18.0.3): icmp_seq=3 ttl=64 time=0.119 ms
64 bytes from service_B.demo_net (172.18.0.3): icmp_seq=4 ttl=64 time=0.121 ms
...

The results are similar when you exec into service_B and ping service_A container. However, none of the containers can reach the "Rock" container which is in the default bridge network because they exist in different virtual networks.

# Inside service_A
root@06dbaea8c2a2:/# ping Rock
ping: Rock: Temporary failure in name resolution

Reaching Apps Running in Containers via Published Ports

When creating service_B in an earlier step, we ran the following command:

$ docker run -dit -p 8000:80 --network demo_net --name service_B nginx

This command mapped port 80 within the container to port 8000 on the host machine. Hence, when we visit localhost:8000 in our browser, we see the web server running in service_B:

Manipulating Network Connections

# Disconnect service_A
$ docker network disconnect demo_net service_A

# Reconnect service_A to default "bridge" network
docker network connect bridge service_A

#Next, use `docker inspect` to get the ip of the Rock container and try pinging it.

root@06dbaea8c2a2:/# ping 172.17.0.2
PING 172.17.0.2 (172.17.0.2) 56(84) bytes of data.
64 bytes from 172.17.0.2: icmp_seq=1 ttl=64 time=0.093 ms
64 bytes from 172.17.0.2: icmp_seq=2 ttl=64 time=0.186 ms
64 bytes from 172.17.0.2: icmp_seq=3 ttl=64 time=0.149 ms

# It works!

List Docker Networks

$ docker network ls
NETWORK ID     NAME       DRIVER    SCOPE
a87871978d59   bridge     bridge    local
747d0aff98fc   demo_net   bridge    local
3bbca0d09738   host       host      local
a67ca10d6dfd   none       null      local

Deleting Docker Networks

To delete a custom network, you must first stop or disconnect all running containers attached to the network. When that's done, proceed to delete the network by running the docker network rm command like this:

$ docker network rm demo_net

# Confirm that the demo_net network has been removed
$ docker network ls
NETWORK ID     NAME      DRIVER    SCOPE
a87871978d59   bridge    bridge    local
3bbca0d09738   host      host      local
a67ca10d6dfd   none      null      local

Conclusion

Docker's networking system gives you different choices for handling communication between containers, their nearby containers, and your Docker host. In a network, containers can connect with each other using their names or IP addresses.

User-defined bridge networks work well when you want various containers to talk to each other on the same Docker host. On the flip side, host networks are more suitable when you don't want the network stack to be separate from the Docker host, but you still want other parts of the container to be isolated.

Docker's networking system could initially feel overwhelming, but I hope this gives you some clarity.

...

If you have any questions or comments, you can leave them below, or reach out to me on LinkedIn. Till we meet again...

Stay awesome!
~ David Omokhodion

Attributions

How to Provision a Linux EC2 Instance (server) on AWS Step-by-step

David Omokhodion — Sun, 30 Oct 2022 17:58:52 +0000

Have you ever needed a server to deploy a web app, complete a lab or something else? I have had need to do both, and AWS always came through for me.

In this tutorial, you will learn how to set up and connect to your own AWS Linux EC2 instance to meet your needs for a server.

Let's go...

What is an EC2 Instance?

An Amazon EC2 instance is a virtual server in the AWS cloud. With the Amazon EC2 service, you can configure your instance to run operating system or applications of your choice.

Overview

When launching an instance, you have to secure it using security groups(which acts like a virtual firewall to control traffic to and from your instance) and key pairs(a proof of identity).

Here is an architectural diagram of what we will be setting up:

Prerequisites:

An AWS account
Create key pair and security group by following instructions found here

To avoid being billed unnecessarily, please ensure to terminate you instance when you complete this tutorial. Instructions for that are included in the last step here.

Step 1: Launch Your Instance

There are several ways to launch an EC2 instance, but in this tutorial, we will use the AWS console.

Here are the steps:

Open the EC2 console at AWS console link
From the dashboard, click on Launch instance

Next, enter a name for your server.
Under the Application and OS Images (Amazon Machine Image), select the "Quick Start" tab and select the Ubuntu image. This will be the OS for your instance.
Under the Amazon Machine Images(AMI) section, pick an option with the "free tier eligible" label for now.

Next, under Instance type, choose an option that has "free tier eligible" too. These instance types are hardware configurations for your server.
Under Key pair(login) choose a key pair you create before, or create one at this step.

Warning: If you launch your instance without a key pair, then you can't connect to it.

Next, we have to configure Network settings
- Choose "select existing security group"
- From the "Common security groups" dropdown, pick the security group you configured earlier from the Prerequisites section of this blog. If you didn't do that, go here.
In order to easily access your access your instance, check to see whether the "Auto-assign public ip" is enabled. If not, enable it to allow a public Ip to be associated with your instance when it is launched.

Keep the other default selections, review the configurations for your instance and confirm instance launch.
On the Instances screen, you could monitor the status of your instance. It may take some time for the instance to launch. Just wait until the state changes to "running."
Also wait for the Status check to pass before attempting to connect to it.

Step 2: Connect to Your Instance (via SSH)

You can't connect to your instance unless:

You have the .pem file for the key pair you used to create the instance.

Your security group is configured to allow you to connect via SSH from your computer.

...so ensure that you have these setup correctly.

In the Instances page, select your instance and copy the Public IP address.

Head over to your terminal and let's connect to our instance.

The syntax for connecting to the instance is:

$ ssh -i <path_to_pem_file> user@<Instance_public_ip>

In my case, it was:

$ ssh -i ~/Downloads/Davi-test.pem ubuntu@54.175.160.84

Successful connection should look something like this:

If ssh complains about the key permission, ensure to change the permission of the .pem file to 400, using chmod. For example, by running:

sudo chmod 400 <path_to_pem_file>)

If you still can't connect to your instance, see Troubleshoot Connecting to Your Instance for assistance.

Step 3: Clean Up Your Instance

Head over to your EC2 instances page and select the instance you just created.
Click on the "Instance state" dropdown and select Terminate instance.
Amazon will then shutdown and terminate your instance. You will no longer be able to connect to it after termination.

Conclusion

Congratulations! You just provisioned a server in the AWS cloud.

I hope you enjoyed the tutorial.

If you have any questions or had any difficulty following along, kindly drop a comment below or reached out to me on LinkedIn. Till we meet again...

Stay awesome!
~ David Omokhodion.

How to Configure Remote Linux Servers Using Ansible

David Omokhodion — Tue, 18 Oct 2022 09:04:55 +0000

Imagine that you were asked to install a piece of software (e.g apache2) on 250 different Linux servers.

How would you go about it?

Well, you could decide to ssh (open a secure connection) into the servers one after the other, and install the software, but that would take an awefully long time to complete.

A more efficient approach will be to use a configuration management tool like Ansible to automate the process.

In this tutorial, you will learn how to use Ansible to target your servers and:

Install Apache web server and
Change the default timezone of your servers

Here, we will use two servers, but the procedure is similar when configuring 250 (or more) servers.

Prerequisites:

An AWS account
A linux machine (could be a VM)

Let's go...

From an Architectural standpoint, this is how Ansible works:

Step 1: Install Dependencies

For Ansible to function properly you need to ensure you have Python and softwares-properties-common installed. Run the following commands to install them:

$ sudo apt install software-properties-common

$ sudo apt install python3

And then install ansible:

$sudo apt install ansible

Confirm Ansible installation:

$ ansible-playbook -v

Step 2: Provision servers on AWS

For this tutorial, I will provision two Ubuntu servers(EC2 instances on AWS). If you don't already know how to do that, follow the instruction here.

Important:
When you provision your servers, ensure that you download the privatekey file(the file with the ".pem" extension), and that you note down the public ip addresses of the provisioned EC2 instances.
Also, for ease, I like to move my privatekeys to my ~/.ssh/ folder. So mine is located at ~/.ssh/Davi-test.pem

Also ensure that your security group allows ssh and web traffic into the server.

Step 3: Setup host-inventory

Create a directory for my this project

$ mkdir ansible_proj && cd ansible_proj

Then create your host-inventory file:

$ touch host-inventory

Next, using your favourite text editor (vi, nano or even VScode) add the ip addresses (or hostnames) of your servers. Like this:

and save.

You would notice that I grouped all my servers under "webservers."

Grouping targets like this makes it easy to separate different groups of machines and this often comes in handy.

Next, you need to tell ansible how to locate your host-inventory file. If you don't, ansible will try to get it from /etc/ansible/hosts.

But since we have the file at ~/ansible_proj, go ahead and do:

export ANSIBLE_INVENTORY=~/ansible_proj/host-inventory

and we're ready to go.

Step 4: Create the Ansible Playbook

touch test.yaml

And then, using your favourite text editor, paste in the following code in the test.yaml file:

---
  - name: Setup Web Server
    hosts: webservers
    become: true
    become_method: sudo
    tasks:
      - name: Install Apache Server
        apt: name=apache2 state=present

      - name: Set timezone to Africa/Lagos
        timezone:
          name: Africa/Lagos

and save.

In the yaml, we target the webserver group using

hosts: webservers

, and we describe 2 tasks, using the apt and timezone modules respectively.

Step 5: Test the connection

Before proceeding with this step, ensure that your $ANSIBLE_INVENTORY variable is set in your current bash as describe previously.

Based on the location of the key you got earlier, you will need to run:

$ ansible --private-key PRIVATEKEY_FILE -u USER HOST_GROUP -m ping

I want to connect as the "ubuntu" user and target the servers under "webservers" host group. So that will be:

$ ansible --private-key ~/.ssh/Davi-test.pem -u ubuntu webservers -m ping

Step 6: Test the Playbook

Before we run our ansible playbook, it is important to test using the "--check" flag along with the ansible-playbook command. Like this:

$ ansible-playbook --private-key ~/.ssh/Davi-test.pem -u ubuntu test.yaml --check

The output should look something like this:

Before you go ahead to finally run the playbook, ssh into any of the servers and check whether apache2 is running and confirm the timezone. If you don't know how to ssh into your server, go here.

I checked inside one of my servers, and here is what I got:

Apache2 was not not installed and timezone was Etc/UTC.

Now let's run the playbook:

Step 7: Run the Ansible playbook

Apply the intended changes to the servers by running the command we used to check, but without the "--check" flag. i.e

$ ansible-playbook --private-key ~/.ssh/Davi-test.pem -u ubuntu test.yaml

If there are no errors and everything goes well, then ssh into any of the servers and try check apache2 and timezone again. Here's what I got:

Awesome!, right? Ansible did it's thing again!.

Before you leave, here's a little exercise:

Try adjusting the timezone to a different one within the test.yaml and run it again to see what happens.

Step 8: Clean up

Finally, if you don't need the servers for other reasons, ensure that you terminate them from the AWS console to avoid racking up unnecessary bills.

Conclusion

Hey,

I hope you enjoyed this tutorial, and I hope that you learned a thing or two about Ansible.

As of the time of writing this tutorial, I just got started with Ansible myself, but I'll be using it a lot from now on because I think it's an awesome tool.

If you have any questions, or comments, you can leave them below, or reach out to me on LinkedIn. Till we meet again...

Stay awesome!
~ David Omokhodion