Hybrid Identity &
Access Management.
AWS Active Directory + Okta.

1. Resolve the missing outbound path

The instance launched without a public address and initially failed to register with Systems Manager. A connection attempt to the regional SSM endpoint on TCP 443 timed out. I checked the subnet route-table association, internet gateway route, security-group egress, network ACL and address association. An Elastic IP supplied internet connectivity without a NAT gateway for this lab. SSM then showed the instance online and a session connected.

2. Recover Windows administrator access

No EC2 key pair had been selected, so the usual initial Windows password decryption was unavailable. In the SSM PowerShell session, whoami identified ssm-user; group checks showed enabled local administrator membership. I set an Administrator password through an interactive prompt and connected using Fleet Manager Remote Desktop.

whoami
whoami /groups
net user Administrator *

3. Install AD DS and rename the server

I installed the AD Domain Services role and management tools, then renamed the generated EC2 hostname to PHYLAX-DC01 and restarted. Before promotion, I replaced the initially proposed test namespace with ad.phylaxcyber.com, using PHYLAX as the NetBIOS name.

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
Rename-Computer -NewName "PHYLAX-DC01" -Restart
# After restarting, run in an elevated PowerShell session:
$dsrm = Read-Host "Enter a unique DSRM password" -AsSecureString
Install-ADDSForest -DomainName "ad.phylaxcyber.com" `
  -DomainNetbiosName "PHYLAX" -InstallDNS `
  -SafeModeAdministratorPassword $dsrm

4. Troubleshoot the DSRM password input

Forest promotion repeatedly reported password complexity failures. Policy inspection showed complexity enabled. A diagnostic revealed that one hidden-input attempt had captured only one character, explaining why apparently complex entries failed. Promotion eventually succeeded after correcting input handling.

5. Validate the domain and DNS

Get-ADDomain returned the new forest and PHYLAX NetBIOS name. Local DNS resolved ad.phylaxcyber.com to 10.50.1.103, and dcdiag passed its connectivity and DNS tests. The server’s DNS client used 127.0.0.1. A DHCP-related warning remained; the lab retained the EC2-assigned private address.

Get-ADDomain | Select-Object DNSRoot, NetBIOSName, Forest
Resolve-DnsName ad.phylaxcyber.com -Server 127.0.0.1
dcdiag /test:DNS
Get-DnsClientServerAddress -AddressFamily IPv4

6. Create dedicated OUs, a test user and the access group

I created PHYLAX-Users and PHYLAX-Groups below the domain root. John Doe was a synthetic user with sAMAccountName jdoe and UPN jdoe@ad.phylaxcyber.com. After setting his password, I explicitly enabled the account. Okta-Users was a Global Security group in the group OU; adding John established the directory-side entitlement.

$base = "DC=ad,DC=phylaxcyber,DC=com"
New-ADOrganizationalUnit -Name "PHYLAX-Users" -Path $base
New-ADOrganizationalUnit -Name "PHYLAX-Groups" -Path $base
# Create jdoe in PHYLAX-Users with a unique securely entered password.
Enable-ADAccount -Identity jdoe
Get-ADUser jdoe -Properties Enabled,UserPrincipalName
New-ADGroup -Name "Okta-Users" -GroupScope Global `
  -GroupCategory Security -Path "OU=PHYLAX-Groups,$base"
Add-ADGroupMember -Identity "Okta-Users" -Members jdoe
Get-ADGroupMember -Identity "Okta-Users"

7. Install and register the AD Agent

From Okta Directory Integrations, I added Active Directory and downloaded the Windows agent installer. The lab used agent version 3.23.0 and the OktaService service account. Registration used the Okta administrator activation flow, with direct outbound internet access and no proxy. Activation codes and organization identifiers are excluded.

I scoped the import to the dedicated lab OUs rather than selecting the domain root. The user OU was PHYLAX-Users; the lab group OU was PHYLAX-Groups. UPN was selected as the Okta username format.

8. Import, match and activate the identity

A full import discovered John Doe, but discovery alone did not create an active account. I selected the staged user, confirmed the assignment and enabled auto-activation. Okta then showed John as Active and AD-sourced. Okta-Users synchronized as an AD-managed group, so membership changes belonged in AD.

The integration imported directory identifiers and user attributes. Optional profile fields were discussed, but no ABAC or governance policy was tested. A provisioning mapping warning did not establish reverse provisioning or password writeback.

9. Test delegated authentication and fix email delivery

I enabled delegated authentication and its test succeeded. A fresh browser login then reached email verification. The UPN was a lab sign-in name, not a working mailbox, so I updated John’s AD mail attribute to a reachable private email address and ran an incremental import. The imported email received the code and sign-in completed.

# Replace the example with the test account's reachable mailbox.
Set-ADUser -Identity jdoe -EmailAddress "test-mailbox@example.com"
Get-ADUser jdoe -Properties mail,UserPrincipalName |
  Select-Object UserPrincipalName,mail
# Run an incremental import in Okta, then test a fresh sign-in.

10. Replace the unavailable SAML test service

The first custom SAML app attempt targeted SAMLtest.id, which was unavailable during the lab. I switched to the RSA SAML Test Service Provider from the Okta catalog and named the application PHYLAX-SAML-SSO-LAB. Assigning Okta-Users gave John the app tile. Launching it produced the RSA “Hello John Doe” result and an accepted SAML assertion.

Service-provider metadata and endpoints depend on the chosen service; the record does not support inventing exact ACS or entity-ID values. The captured result, rather than a proposed configuration, is the evidence of successful federation.