Build an Azure Foundation for FreeIPA

Buy a domain and build a secure Azure foundation for a future FreeIPA server.

Introduction

30 Second Summary

You will prepare a permanent online home for your future sign-in system. Like choosing an address before building a house, this keeps its identity stable from the start.

In this project, you will use Azure Portal to bring an externally purchased domain into Azure and prepare a future FreeIPA identity server. You will also set up an AlmaLinux OS 9 host that can be accessed securely and deallocated when idle.

What You'll Build

Your final demo shows a locked-down Azure host that you can safely reach from Azure Cloud Shell through a temporary SSH connection, with its DNS fully delegated to Azure.

By the end of this project, you'll have:

An owned namespace with cloudseam.tech delegated to Azure DNS and the future identity names recorded.
A reachable AlmaLinux host that keeps the same private and public addresses.
A least-privilege access workflow that permits one Cloud Shell address before returning the virtual machine to a locked and deallocated state.
Secret Mission: Create a passphrase-protected home SSH identity for independent testing and revocation in Project 2.

Are there any prerequisites?

You need a personally controlled Azure subscription and an externally purchased domain (this project uses cloudseam.tech from Namecheap).

Before We Start

Before we dive in, commit to building a reusable identity-lab foundation around your newly purchased domain, cloudseam.tech. This foundation brings centralized identity, DNS, and certificates to your future Foreman projects.

Set Up Persistent Cloud Shell Access

Your future FreeIPA host needs a durable administrative identity. Azure Cloud Shell gives you a browser-based environment for managing that identity.

Cloud Shell sessions use temporary hosts. Persistent storage backed by Azure Files keeps your SSH key files available across sessions.

In this step, get ready to:

Configure persistent Cloud Shell storage.
Create a dedicated Ed25519 SSH key resource.
Confirm the key files survive a new Cloud Shell session.

In an air-gapped classified environment

There is no Azure Cloud Shell. You would work from a hardened admin workstation or bastion host on the classified network with pre-loaded CLI tools. Persistent key storage would use an encrypted local drive or approved network share instead of Azure Files.

SSH key generation would use a FIPS 140-2/3 validated cryptographic module. Your organization may mandate specific key types or minimum key lengths beyond Ed25519.

💡 In an enterprise vCenter environment

There is no Azure Cloud Shell or Azure-managed SSH key resource. Administrators connect to vCenter Server through the vSphere Client and manage SSH keys through VM customization specifications. A customization spec can inject an SSH public key into a Linux template at clone time, eliminating manual key placement.

For key management at the infrastructure level, vCenter integrates with a Standard Key Provider backed by an external KMIP-compliant key management server, or uses the built-in vSphere Native Key Provider to generate and distribute encryption keys without an external KMS. These key providers handle VM disk encryption rather than SSH authentication, but they represent the centralized key lifecycle that vCenter controls.

Confirm persistent storage

The clouddrive mount shows that Cloud Shell has an attached file share. This storage protects the key files you create later in this step.

In Azure Portal, select Cloud Shell from the top navigation bar.
Select Bash if Cloud Shell asks you to choose a shell.
Check your home directory by running this command:

ls

What does this command show?

The command lists the files and directories in your Cloud Shell home directory.
A clouddrive entry confirms that persistent storage is mounted.

✔️ I see clouddrive

Your persistent storage is already mounted. You can continue to the next check.

ⓧ I do not see clouddrive

Your current session needs an attached storage account before it can hold a durable SSH identity.

Select Settings from the Cloud Shell toolbar.
Select Reset User Settings.
Select Reset to confirm the change.
Select Cloud Shell from the Azure Portal navigation bar again.
Select Bash.

Why reset the settings?

Resetting removes the ephemeral-session preference. Cloud Shell can then present the persistent-storage setup.

Select Mount storage account in the Getting started pane.
Select your Azure subscription from the dropdown menu.
Select Apply.
Select We will create a storage account for you.
Select Next to create the persistent storage resources.

Confirm the mount is now available by running this command:

ls

What should you see?

The output includes clouddrive. Your Cloud Shell home directory is now backed by persistent storage.

🙋‍♀️ Still missing clouddrive?

Confirm that you selected persistent storage during the Cloud Shell setup. A storage policy or missing subscription permission can prevent the file share from mounting.

Help me diagnose why persistent storage is not mounting in Azure Cloud Shell.

Create the dedicated Cloud Shell key

A dedicated SSH identity limits this environment to its own credential. The public key can be installed on the future VM while the private key stays in Cloud Shell.

Create the Azure SSH key resource in foreman-lab-rg by running this command:

az sshkey create --name "sshkey-cloudshell-ipa1" --resource-group "foreman-lab-rg" --encryption-type Ed25519

What does this command create?

The command creates the Azure SSH key resource named sshkey-cloudshell-ipa1 in foreman-lab-rg.
The --encryption-type Ed25519 option creates an Ed25519 key pair.
The output prints the local private-key path and public-key path.

Record the command-printed private-key path in your project notes.
Record the command-printed public-key path in your project notes.
Copy the permission command below into the Cloud Shell prompt without running it yet:

chmod 600 /home/user/.ssh/7777777777_9999999

Why set this permission?

The chmod 600 setting gives only your Cloud Shell user read and write access to the private key. SSH expects private credentials to have restricted permissions.

Replace the sample path with the exact private-key path printed by the key creation command.
Run the edited permission command.
Inspect the key directory by running this command:

ls -al ~/.ssh

Check the key files

The output includes the private and public key files whose paths you recorded.
The private-key row begins with -rw-------, which represents mode 600.

🙋‍♀️ Key files or permissions missing?

Check that the key creation output reported both file paths. Confirm that your permission command used the printed private-key path without the public-key suffix.

Help me check my Cloud Shell SSH key files and private-key permissions.

❌ Keep the private key private

Keep the private key only in persistent Cloud Shell storage. Never paste its contents into notes or messages. Never email or upload it.

Prove the key survives a new session

A persistence check proves that the key belongs to your durable Cloud Shell environment. This is the evidence that protects your future access workflow from a session reset.

Close the Cloud Shell pane.
Select Cloud Shell from the Azure Portal navigation bar.
Select Bash if prompted.

Before you run the final check, which mount and key files do you expect the reopened session to show?

Check the persistent mount by running this command:

ls

What does this prove?

The reopened session still shows clouddrive. This confirms that persistent storage remains attached.

Check the key files and permissions by running this command:

ls -al ~/.ssh

What should remain?

The same private and public key files remain in the directory. The private-key row still begins with -rw-------.

🙋‍♀️ Did the key files disappear?

Confirm that the reopened session shows clouddrive. Missing files usually indicate that the earlier session did not use the persistent Cloud Shell home directory.

Help me recover my persistent Cloud Shell setup without exposing any private key contents.

✔️ Awesome, I've got everything!

Your persistent Cloud Shell home now holds the dedicated key files. Keep your recorded paths ready for the VM deployment.

ⓧ I'd like to double check the final state

Confirm Azure Cloud Shell is open in Bash with persistent Azure Files-backed storage.
Confirm clouddrive is mounted in the Cloud Shell home directory.
Confirm sshkey-cloudshell-ipa1 exists in foreman-lab-rg with Ed25519 encryption.
Confirm the command-printed private and public key files remain in the persistent home directory.
Confirm the private-key file has mode 600.
Confirm your notes contain both key paths without any private-key contents.

Your persistent administrative identity is ready. Next, you'll bring your cloudseam.tech domain into Azure DNS and record the naming contract for your future FreeIPA server.

Purchase the CloudSeamTech Domain

Integrate the CloudSeam Domain with Azure DNS

Your persistent Cloud Shell SSH identity is ready. You can now bring your purchased domain into Azure so that it can manage identity records for the future lab.

Changing an existing FreeIPA DNS domain is extremely hard. Owning the domain first and delegating it to Azure DNS prevents a temporary name from becoming permanent technical debt.

In this step, get ready to:

Confirm that cloudseam.tech is registered on Namecheap.
Create an Azure DNS zone for the domain.
Delegate DNS authority to Azure and record the naming contract.

In an air-gapped classified environment

There is no external registrar like Namecheap and no Azure DNS. Your domain would be an internal-only zone that never touches the public internet. Instead, you would stand up a BIND server on the classified network. BIND is the most widely deployed authoritative DNS server and runs on the same AlmaLinux you are using here.

To set up BIND, install it with dnf install bind bind-utils. Define your forward zone (e.g. idm.cloudseam.tech) in /etc/named.conf by adding a zone block that points to a zone file. Create that zone file in /var/named/ with SOA, NS, and A records for your FreeIPA host. Then enable the service with systemctl enable --now named. Clients on the classified network point their resolver at this BIND server's IP.

The Kerberos realm and DNS domain naming contract works identically regardless of whether the authority is Azure DNS or BIND. FreeIPA only cares that forward and reverse DNS resolve correctly at install time.

💡 In an enterprise vCenter environment

There is no external domain registrar or Azure DNS zone. DNS for the vSphere environment is typically managed by an internal Microsoft DNS or BIND server that the vCenter infrastructure already relies on. vCenter itself requires forward and reverse DNS to function, so DNS zones already exist before any VM is provisioned.

The naming contract still matters. vCenter uses FQDNs throughout its inventory, and a FreeIPA deployment on vSphere follows the same rule: plan the DNS domain and Kerberos realm before installation. The difference is that you create the zone and records on the internal DNS server rather than delegating a public domain.

Confirm your Namecheap purchase

Azure App Service Domains do not support .tech TLDs and restrict purchases on some subscription types. Purchasing cloudseam.tech externally on Namecheap bypasses both limitations.

Open Namecheap in a new browser tab.
Sign in to your Namecheap account.
Select Domain List from the left sidebar.
Confirm that cloudseam.tech appears in your active domains.

Why not buy SSL from Namecheap?

FreeIPA deploys its own built-in certificate authority during installation. It automatically mints and signs certificates for LDAPS and HTTPS on your identity server.

A standard SSL certificate from Namecheap would only validate the root domain. Your identity server will live at ipa1.idm.cloudseam.tech, which FreeIPA's internal CA handles for free.

Create the Azure DNS zone

An Azure DNS zone gives Azure control over the domain's DNS records. Once delegated, Azure can publish records like ipa1.idm.cloudseam.tech for your future virtual machine.

Return to Azure Portal from earlier.
Use the portal search bar to find DNS zones.
Select DNS zones from the search results.
Select Create.
Select your personally controlled Azure subscription.
Select foreman-lab-rg as the resource group.
Enter cloudseam.tech as the zone name.
Select Review + create.
Select Create.
Select Go to resource.

What does the DNS zone do?

The DNS zone holds authoritative records for cloudseam.tech and all its subdomains. Azure DNS serves these records once the domain's nameservers point here.

On the DNS zone Overview page, locate the four Azure nameservers listed under the essentials pane.
Record all four nameservers in your project notes.

The nameservers look like ns1-01.azure-dns.com. and ns2-01.azure-dns.net. with a trailing dot.

DNS zone creation failed?

Confirm you entered cloudseam.tech exactly as your registered domain name. Check that foreman-lab-rg exists in your subscription.

Help me create an Azure DNS zone for my externally purchased domain.

Delegate DNS authority to Azure

Namecheap currently controls where DNS queries for cloudseam.tech are answered. Updating the nameservers in Namecheap hands that authority to Azure.

Switch to your Namecheap tab.
Select Manage next to cloudseam.tech.
Scroll to the Nameservers section.
Change the dropdown from Namecheap BasicDNS to Custom DNS.
Enter the four Azure nameservers you recorded from the DNS zone overview.
Omit the trailing dot if Namecheap rejects it.
Select the green checkmark to save the nameserver changes.

How long does delegation take?

Nameserver changes can take up to 48 hours to propagate globally. Azure DNS can start serving records immediately for queries that reach the new nameservers.

🙋‍♀️ Namecheap rejecting a nameserver?

Remove the trailing dot from each nameserver entry. Namecheap expects the format ns1-01.azure-dns.com without a period at the end.

Help me update my Namecheap nameservers to point to Azure DNS.

Record the naming contract values in your project notes:

Root domain: cloudseam.tech
Future DNS domain: idm.cloudseam.tech
Future Kerberos realm: IDM.CLOUDSEAM.TECH

Why these three values?

The idm subdomain gives FreeIPA its own primary domain while keeping the root free for future websites. The Kerberos realm must be the uppercase form of the complete DNS domain.

Before you verify, what do you expect to see on the Azure DNS zone overview page?

Return to the cloudseam.tech DNS zone in Azure Portal.
Confirm that the four nameservers are listed under the essentials pane.
Confirm that the zone shows the default SOA and NS record sets.

The DNS zone overview shows your four Azure nameservers and the default record sets. Your Namecheap dashboard shows Custom DNS with the same four nameservers.

Your domain is now delegated to Azure DNS. Next, you will create the AlmaLinux host that uses this identity foundation.

Create the AlmaLinux FreeIPA Host

Your cloudseam.tech domain is now delegated to Azure DNS, giving your future FreeIPA deployment a durable namespace. The next piece is a host that can keep that identity stable.

A stable Azure Virtual Machine provides the address and operating system foundation. Keeping inbound access closed protects the host until its operating system and access controls are validated.

In this step, get ready to:

Configure an AlmaLinux OS 9 VM with the dedicated SSH public key.
Connect the VM to the existing subnet with static public and private addressing.
Keep public inbound ports closed through a NIC-level network security group.

In an air-gapped classified environment

VM images would come from an approved internal repository of STIG-hardened golden images, not the Azure Marketplace. Your security team maintains and patches these images on a defined cadence.

There would be no public IP address. All access routes through a bastion host or jump box on the classified network, and the VM would have only a private address on an isolated VLAN. The network security group equivalent would be a dedicated firewall appliance with change-controlled rule sets approved through your organization's accreditation process.

💡 In an enterprise vCenter environment

There is no Azure Marketplace. VMs are cloned from templates stored in the vCenter Content Library. Your infrastructure team maintains hardened golden images of approved operating systems, and you deploy new VMs by right-clicking a template and selecting New VM from This Template. A customization specification applies hostname, network, and SSH settings during the clone.

Instead of an Azure NSG, network security is handled by a vSphere Distributed Switch or NSX distributed firewall. These provide microsegmentation rules at the virtual NIC level, similar to a NIC-level NSG. Static IP addressing is configured in the customization spec or through the guest OS, and vCenter tracks the assignment in its inventory.

Configure the VM identity and image

The VM name and image become part of the host's long-term identity. Azure also attaches a managed OS disk when it creates the VM.

Return to the Azure Portal from earlier.
Use the portal search bar to find Azure Virtual Machines.
Select Create.
Select Virtual machine.
Select your personally controlled Azure subscription.
Select foreman-lab-rg as the resource group.
Enter vm-ipa1-lab as the virtual machine name.
Select West US 3 as the region.

Why These Foundation Choices Matter

A fixed resource group and region keep the VM beside the existing lab network. No infrastructure redundancy keeps this single-host lab focused on development use.

Choose no infrastructure redundancy.
Select See All Images from the Image options.
Search for AlmaLinux.
Select the official AlmaLinux OS 9 x86_64/AMD64 image from the AlmaLinux OS Foundation.
Set the security type to Standard.
Choose a burstable size with at least 2 GiB of memory.
Prefer Standard_B2s_v2 when its live price and availability are acceptable.

Why This VM Size

FreeIPA recommends 2 GB of memory for a demonstration or test installation. The selected VM size must meet that baseline.

The Standard_B2s_v2 size provides 2 vCPUs and 8 GiB of memory. That capacity leaves room for the follow-on installation.

Select SSH public key as the authentication type.
Enter azureuser as the administrator username.
Select Use a key stored in Azure as the SSH public key source.
Select sshkey-cloudshell-ipa1 as the stored key.

Lock down the VM network

A NIC-level network security group limits policy changes to this VM. The existing Foreman host keeps its current subnet policy.

Select the Networking tab.
Select vnet-westus3-1 as the virtual network.
Select snet-westus3-1 as the subnet.
Create a new public IPv4 resource.
Enter pip-ipa1-lab as the public IP resource name.
Set its SKU to Standard.
Set its IP address assignment to Static.

Why Start With No Inbound Access

A Standard public IP requires an NSG to allow intended inbound traffic. Starting without a custom allow rule leaves the host protected by default.

Create a NIC-level NSG named nsg-ipa1-lab.
Set Public inbound ports to None.
Select Review + create.
Review the displayed VM price.
Select Create.
Wait for the deployment to finish.
Select Go to resource.

The VM overview should show vm-ipa1-lab running in West US 3.

Did the VM Deployment Fail?

Check whether your subscription has enough quota for the selected VM size.
Choose another burstable size with at least 2 GiB if the preferred size is unavailable.
Confirm that every resource uses West US 3.
Help me diagnose why my Azure VM deployment failed.

Make the private address static

Keep Static Addressing in Azure

Azure assigns the private address through the NIC configuration. Setting the assignment there preserves the current address.

Do not configure a static address inside AlmaLinux. A mismatch between the operating system and the Azure NIC can break connectivity.

Select Network settings from the VM resource.
Select the attached network interface.
Select IP configurations.
Select ipconfig1.
Keep the assigned private IP address unchanged.
Set Assignment to Static.
Select Save.

Before you check the finished host, what settings do you expect to confirm on the VM and its NIC?

Return to the vm-ipa1-lab resource.
Confirm that its status reads Running.
Confirm that the image identifies AlmaLinux OS 9.
Confirm that the NIC uses vnet-westus3-1.
Confirm that the NIC uses snet-westus3-1.
Confirm that pip-ipa1-lab is a Standard static public IPv4 resource.
Confirm that ipconfig1 shows a static private assignment.
Confirm that nsg-ipa1-lab has no custom inbound allow rule.

What Should You See?

The VM status reads Running. The image is the official AlmaLinux OS 9 image from the AlmaLinux OS Foundation.

The NIC is connected to vnet-westus3-1 and snet-westus3-1. The subnet uses the 172.16.0.0/24 address range.

The pip-ipa1-lab resource uses a Standard static public IPv4 address. The ipconfig1 configuration retains its assigned private IP with a static Azure assignment.

The nsg-ipa1-lab NSG has no custom inbound allow rule. Public inbound ports remain set to None.

Your protected AlmaLinux host now has stable Azure addressing. Next, you'll test its current access boundary from Cloud Shell.

Allow Temporary SSH Access

Your AlmaLinux VM is running with no inbound access. You now have a safe environment for proving that the default-deny posture works.

You will test the blocked connection from Azure Cloud Shell. You will then add one temporary network security group rule that permits SSH only from the current Cloud Shell address.

In this step, get ready to:

Experience the default-deny SSH block.
Allow TCP port 22 from the current Cloud Shell address.
Verify the host fingerprint and confirm AlmaLinux.

In an air-gapped classified environment

There is no curl https://api.ipify.org — there is no internet. Your source IP is a known bastion address already documented in the network accreditation package.

Firewall rule changes would go through a formal change request and approval workflow before implementation. Temporary rules would carry an explicit expiration and audit trail.

SSH authentication might require CAC/PIV smart card certificates instead of or alongside key-based auth. FreeIPA supports this natively through its built-in certificate authority integration.

💡 In an enterprise vCenter environment

There is no public IP or Cloud Shell egress address to discover. SSH access to a vSphere VM uses the private IP visible in the vCenter inventory. Firewall rules are managed on a dedicated appliance or through NSX distributed firewall policies, not through per-VM NSG rules in a portal.

Temporary access rules follow a change management process. An administrator submits a request to open a port, the change is approved, and the firewall rule carries a documented expiration. vCenter's built-in event log and NSX audit trail provide the same accountability that Azure activity logs give you here.

Experience the default-deny block

A Standard public IP accepts inbound traffic only when an attached NSG explicitly permits it. Your first connection attempt tests that protection before any exception exists.

Predict whether the connection will complete before you run it.

Return to the Azure Cloud Shell Bash session from earlier.
Attempt the SSH connection using the private-key path printed when you created the key:

ssh -i [[PRIVATE_KEY_PATH="<printed-private-key-path>"]] azureuser@[[VM_PUBLIC_IP="<vm-public-ip>"]]

The blocked connection is expected

The connection cannot complete because TCP port 22 has no inbound allow rule. This timeout proves that the NSG protects the VM by default.

Press Ctrl+C to stop the stalled connection attempt.

Allow the current Cloud Shell address

Cloud Shell can use a different public address in a later session. A temporary /32 rule limits access to the single address you are using now.

Discover the current Cloud Shell egress address by running this command:

curl https://api.ipify.org

What does this command do?

The request returns the public IPv4 address used by this Cloud Shell session. That address becomes the only permitted source for temporary SSH access.

Record the returned address as <cloud-shell-egress-ip>.
Append /32 when you enter the address in the NSG rule.
Return to the Azure Portal from earlier.
Enter nsg-ipa1-lab in the portal search bar.
Select the nsg-ipa1-lab network security group.
Select Inbound security rules.
Select Add.
Set Source to IP Addresses.

Why use one source address?

A /32 prefix identifies one IPv4 address. This keeps the exception limited to your current Cloud Shell session.

Enter <cloud-shell-egress-ip>/32 in Source IP addresses/CIDR ranges.
Enter * for Source port ranges.
Set Destination to Any.
Enter 22 for Destination port ranges.
Set Protocol to TCP.
Set Action to Allow.
Enter an unused Priority between 100 and 4096.
Enter Allow-SSH-CloudShell-Temporary for Name.

Select Add to create the rule.

The inbound rules list now shows Allow-SSH-CloudShell-Temporary. Its source is your current Cloud Shell address with a /32 prefix.

Verify the host and open SSH

A host fingerprint identifies the SSH server that answers your connection. Comparing it through Azure Run Command helps you avoid trusting an unexpected host.

Return to vm-ipa1-lab in Azure Portal.
Select Run command.
Select RunShellScript.
Retrieve the VM host fingerprint by running this script:

ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub | awk '{print $2}'

What does this fingerprint prove?

The command reads the VM's public host key and returns its fingerprint. You can compare that value with the fingerprint shown by your SSH client.

Record the fingerprint returned by Run Command.
Switch back to the Azure Cloud Shell Bash session.
Predict whether the same SSH command will now reach the VM.
Retry the SSH connection using the same private key and public IP:

ssh -i [[PRIVATE_KEY_PATH="<printed-private-key-path>"]] azureuser@[[VM_PUBLIC_IP="<vm-public-ip>"]]

What happens during the connection?

The temporary NSG rule now permits the SSH request from your current Cloud Shell address. The VM asks you to verify its host fingerprint before opening the session.

Compare the SSH prompt fingerprint with the value returned by Run Command.
Accept the fingerprint only when the two values match.
Confirm the operating system by running this command inside the SSH session:

cat /etc/os-release

What should you see?

The release information identifies the host as AlmaLinux OS 9. This proves that your restricted SSH path reaches the intended VM.

Press Ctrl+D to close the SSH session.

SSH still not connecting?

Confirm that the NSG rule source matches the latest address returned by the Cloud Shell IP check. A new Cloud Shell session can use a different address.

Confirm that the rule targets TCP port 22 on nsg-ipa1-lab.

Ask for help diagnosing the restricted connection: Why can Cloud Shell still not SSH to my Azure VM through this temporary NSG rule?

Your VM now has a tested least-privilege access path. Next, you will record the final naming contract and remove this temporary exposure before deallocating the VM.

Record the Naming Contract and Deallocate

Your temporary SSH rule gave Azure Cloud Shell controlled access to the AlmaLinux host. You also proved that the host is ready for the future FreeIPA installation.

That installation needs an auditable naming contract. The VM should also stop consuming compute while it waits for Project 2.

In this step, get ready to:

Complete the naming and access contract.
Remove the temporary SSH access rule.
Deallocate the VM for cost control.

In an air-gapped classified environment

The naming contract would follow your organization's host naming convention, often dictated by the applicable STIG or Security Requirements Guide. Names typically encode site, classification level, and function.

Deallocation would require documented approval and an audit log entry. In production classified environments, compute rarely gets deallocated. It runs continuously behind monitored access controls, and cost control is handled through program budgets rather than metered cloud billing.

💡 In an enterprise vCenter environment

There is no metered compute billing to stop. Instead of deallocating a VM, you would power it off or suspend it through the vSphere Client. vCenter tracks power states across the inventory and can enforce policies through DRS rules and scheduled tasks.

The naming contract is recorded in vCenter's own inventory: custom attributes, notes fields, and tags let you document the FQDN, realm, and network assignments directly on the VM object. Many enterprises also feed this into a CMDB. The principle is the same: lock down the identity contract before the first service installation.

Complete the naming and access contract

Your existing contract already records the root domain, future DNS domain, and uppercase Kerberos realm. Extend it with the host details that Project 2 needs.

Add the planned server FQDN ipa1.idm.cloudseam.tech to the contract.
Add the Azure VM name vm-ipa1-lab to the contract.
Return to the vm-ipa1-lab page in Azure Portal to identify its static private IP.
Record the private IP as <vm-private-ip>.
Identify the attached public IP address on the same VM page.
Record the public IP as <vm-public-ip>.

Why Record Both Addresses?

The private IP identifies the host inside the Azure network. The public IP supports the controlled administration workflow.

Add the network security group name nsg-ipa1-lab to the contract.
Add the public-key path printed when you created sshkey-cloudshell-ipa1.
Keep all private-key contents out of the contract.

Your contract now connects the root domain cloudseam.tech to the planned server identity ipa1.idm.cloudseam.tech. It also preserves the future realm IDM.CLOUDSEAM.TECH.

Remove temporary SSH access

The temporary rule served one Cloud Shell session. Removing it restores the VM's restricted inbound posture.

Delete Allow-SSH-CloudShell-Temporary from the inbound security rules on nsg-ipa1-lab.
Review the remaining inbound rules to determine whether any rule exposes TCP ports 22, 53, 80, 88, 389, 443, 464, or 636 to Any or Internet.

The temporary rule no longer appears. None of the listed service ports has a public inbound allow rule.

Still See the Temporary Rule?

Refresh the inbound security rules view. Confirm that you deleted the rule from nsg-ipa1-lab.

If the rule remains, help me remove the temporary NSG rule safely.

Deallocate the VM

Before you stop the VM, what final power state do you expect Azure Portal to show?

Return to the vm-ipa1-lab page in Azure Portal.
Select Stop from the VM toolbar.
Wait for the power-state update to finish.
Confirm that the VM status reads Stopped (deallocated).

The VM now shows Stopped (deallocated). The temporary SSH rule remains absent from nsg-ipa1-lab.

What Deallocation Changes

Deallocation releases the VM's compute allocation. The managed disk can still incur charges.

Azure DNS can still incur charges. The Standard static public IPv4 resource can also continue to incur charges.

Secret mission

Add a Separate Home SSH Identity

Create a passphrase-protected SSH identity that stays on your home Mac. Record only its public-key path and fingerprint for Project 2.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. Your deallocated VM has stopped compute billing.

Cost warning

The Namecheap domain registration costs $9.99 for the first year (promotional price). Renewal is approximately $58.98 per year at the standard rate.

Azure DNS zone hosting is billed separately. The managed disk and Standard static public IPv4 resource can also continue to incur charges.

Resources you used:

A cloudseam.tech domain registered on Namecheap.
An Azure DNS zone for cloudseam.tech in foreman-lab-rg.
A deallocated AlmaLinux OS 9 VM named vm-ipa1-lab.
The VM's managed OS disk.
The VM's network interface with its static private assignment.
A network security group named nsg-ipa1-lab.
A Standard static public IPv4 resource named pip-ipa1-lab.
An Azure SSH key resource named sshkey-cloudshell-ipa1.
The dedicated private and public key files in your persistent Cloud Shell home directory.

Keep everything running

No action is needed. Choose this if you plan to continue with Project 2.

Retain vm-ipa1-lab in its Stopped (deallocated) state.
Retain the cloudseam.tech Azure DNS zone for the future FreeIPA namespace.
Retain the managed disk and network resources for the next project.
Keep nsg-ipa1-lab free from temporary inbound SSH rules.
Protect the dedicated Cloud Shell private key in its persistent home directory.
Keep your Namecheap cloudseam.tech registration active.

Pause - I'll come back to this later

Shut down running processes to stop compute usage while preserving the lab. Your VM is already deallocated.

Confirm vm-ipa1-lab still shows Stopped (deallocated) in Azure Portal.
Confirm Allow-SSH-CloudShell-Temporary is absent from nsg-ipa1-lab.
Review your Namecheap auto-renewal preference for cloudseam.tech.
Disable auto renewal on Namecheap only if you accept the risk that cloudseam.tech may expire.
Retain the naming contract for Project 2.

Delete - I don't want to use this again

Remove the project resources if you are abandoning the lab. Keep the shared resource group because it contains your Foreman resources.

Delete vm-ipa1-lab from its resource page in foreman-lab-rg.
Delete the managed OS disk that was attached to vm-ipa1-lab from foreman-lab-rg.
Delete the network interface that was attached to vm-ipa1-lab from foreman-lab-rg.
Delete nsg-ipa1-lab from its resource page.
Delete pip-ipa1-lab from its resource page.
Delete sshkey-cloudshell-ipa1 from its resource page in foreman-lab-rg.
Delete only the dedicated private and public key files created for sshkey-cloudshell-ipa1 from your persistent Cloud Shell home directory.
Delete the cloudseam.tech Azure DNS zone from its resource page in foreman-lab-rg.
Sign in to Namecheap, select Domain List, and disable auto-renewal for cloudseam.tech to let the registration expire.
Keep foreman-lab-rg because it contains separate Foreman resources.

Nice Work!

Nice work! You've prepared a cost-controlled Azure foundation for a future FreeIPA server, with cloudseam.tech fully delegated to Azure DNS. The deallocated host is ready for Project 2.

What you learned:

Delegated domain ownership from Namecheap to Azure DNS. Reserved the idm.cloudseam.tech namespace for future identity services.
Created a persistent Azure Cloud Shell SSH identity. Deployed vm-ipa1-lab with stable private and public addresses.
Proved default-deny protection with a temporary /32 rule. Removed that access before deallocating vm-ipa1-lab.
Secret Mission: Prepared an independent home SSH identity for later enrollment without copying another private key.

Ready to quiz yourself?