Active Directory Implementation using Azure

Project Summary

This project demonstrates the deployment and configuration of Microsoft Azure Active Directory Domain Services within a cloud infrastructure environment. This will provide the foundation for detailed and complicated AD scenarios in the future.

Infrastructure Architecture

Primary Domain Controller (Azure VM)

Using Azure’s GUI we configured our DC as:

• Operating System: Windows Server 2019 Datacenter
• Azure Region: East US (selected for optimal latency and cost-efficiency)
• Security Tier: Standard (lab environment; production would require premium security features)
• Redundancy: Single instance (lab configuration; a production environment requires multi-zone redundancy or even regional – as you should never have a single point of failure in your critical infrastructure).

As this server is located within an Azure datacenter and not on-premises, we have to remote in. The two main ways to accomplish this: SSH (port 22) which only provides secure CLI access or RDP (port 3389) which provides a graphical user interface – Azure recommends using RDP.

• We have two machines in this project: the server hosting our AD services and our client management workstation that has RSAT installed to remotely manage AD (which is best practice, as explained later).

Since these are two different machines, we must ensure that they are in the same network/LAN or else they wouldn’t be able to talk to each other. Of course, using a router/gateway they would be able to speak to each other if they are in different subnets – but that’s for our Network Projects. I want to briefly describe the network architecture to lay a foundation.

Network Architecture

Virtual Network Configuration:

• Address Space: 10.0.0.0/24 (private IPs)
• Subnet Mask: /24 (255.255.255.0) (IPv4 addresses are 32 bits in total, 24 are being used for the network, 8 are being used for the host bits)
• Available Host Addresses: 254 usable addresses (256 total minus network and broadcast addresses)
• IP Address Allocation:
  • Domain Controller: 10.0.0.4 (provided by Azure DHCP)
  • Client Workstation: 10.0.0.5 (provided by Azure DHCP)
  • A public IP for each machine that has been blurred (this is what hosts outside our network identify us as – more on this in a Network Project).
• Gateway Configuration: Azure-managed default gateway
• DHCP Services: Azure-provided (production environments typically use Windows DHCP role)

Network Security Considerations: Azure Virtual Network provides Layer 3 isolation by default. In production environments, Network Security Groups (NSGs) would be configured to restrict traffic flow between subnets.

Active Directory Implementation

Domain Configuration

Domain Specifications:

• Forest Functional Level: Windows Server 2016 (this is the minimum server version required, can be updated in the future – should have the server running the newest version for maximum security as they contain updates)
• Domain Name: carlostech.local
• NetBIOS Name: CARLOSTECH (for legacy systems)
• DNS Integration: Integrated DNS zones for forward and reverse lookups (allows for auto replication to all domain controllers and multiple DCs can update DNS records).

Domain Controllers are the authoritative servers for AD. The changes you make here populate to all other servers and hosts within the domain you configure. If this fails, you are in big trouble. It’s vital to have redundant DC’s (Azure actually provides you with a set of 2 automatically when you use Entra ID, which is AD for Azure). The root domain we configured was “carlostech.local”, which means this is the domain I want all the users, computers and servers to join to. We are using .local in the forest because this is a local project that will not propagate the Internet.

• Typically, you do NOT use .local, you would use carlostech.com and create subdomains such as local.carlostech.com, mail.carlostech.com, etc. The reasonings behind this are:
  • It lacks professional appearance and does not follow standardized naming for internet domains
  • You could have technical conflicts with various technologies
  • You will not be able to get a public SSL certificate
  • If you ever wanted to expand into the cloud, you could have integration issues

The Domain Controller was configured with multiple roles such as:

• Active Directory Domain Services (AD DS): Core directory services (hosting the AD database)
• DNS Server Role: Provides name resolution for domain resources
• File and Storage Services: Enables file sharing and storage management

Note: In production environments, role separation would typically be implemented across multiple servers for security and performance optimization.

Remote Administration Configuration

Remote Server Administration Tools were deployed on the Windows 10 client workstation to demonstrate secure remote management principles:

Security Benefits:

• Minimizes direct access to domain controllers
• Reduces attack surface on critical infrastructure
• Implements principle of least privilege access
• Enables centralized administration from dedicated management workstations

Tools Enabled:

• Active Directory Users and Computers (ADUC)
• Group Policy Management Console (GPMC)
• Active Directory Sites and Services

We need to synchronize system time across all domain members to ensure proper Kerberos authentication and accurate logging which prevents authentication failures and maintains accurate audit trails.

So, we have our RSAT installed and our time is synced between the server and our PC. Now, we have to see if both devices are able to communicate. Using the command prompts in our PC and server, we can use the command “ipconfig” to see our IP address configurations

This is the output for the pc, which was identical with the output for our server except the server’s IP address was 10.0.0.4. Now we have confirmed that we are in the same subnet and have the same gateway.

Sidenote: Azure did all the networking by default. But typically in a real network, you would have a DHCP server (utilizing ports 67 and 68), that hand out IP addresses to hosts who ask for one using the DORA process unless you manually configure static IP addresses (you typically only do this on servers and vital infrastructure).

Since we’re on the same subnet, let’s see if our PC can ping the domain carlostech.local

This failed, because even though we’re on the same network, I am pinging a domain name and not an actual IP address when we haven’t configured the PC to point to a DNS server for DNS queries (typically a DHCP server tells your PC what DNS server to send queries to).

1. Humans prefer typing in google.com because its much easier to remember that than the actual IP address. However, network devices only use IP addresses for the actual routing process so DNS (port 53), automatically translates human-readable text to the configured IP address that allows the network to actually speak to each other.
2. To fix this, we go to Control Panel  -> Network and Internet -> Change Adapter Settings -> IPv4 -> and manually add the DNS server. Here, we added our main server’s IP because not only did we add Active Directory services to it, but also DNS and File Shares. Our backup DNS servers will be Google’s at 8.8.8.8.

User Account Management

To initiate this process, we have to join our PC into the domain we configured.

Note: This is not the primary method to join a machine into the desired domain. In enterprises, there are various methods:

• Windows Deployment Services which is an automated imaging process
• Microsoft Deployment Toolkit which utilizes task sequences and answer files
• System Center Configuration Manager
• Active Directory itself

Administrative Account Structure

Domain Administrator Account: The initial server administrator account (which we created called ‘helpdesk’) was automatically elevated to the ‘Domain Admins group’ during Active Directory promotion, providing administrator privileges across all domain-joined systems. This signifies that this account now has local administrator rights on every machine within the ‘carlostech.local’ domain, demonstrating the security significance of the Domain Admin group membership.

• If an enterprise has several domains under a forest, you could have ‘Enterprise Admins’ which have full control across multiple domains.

We now log into my Windows10 PC as an admin, which would be username: ‘carlostech.local\helpdesk’ as explained above. The reason why I have to include the domain carlostech.local\ is because I want the VM to authenticate against a domain account and not a local account (which I did create when I first initialized the VM). Without the domain, Windows will assume I am trying to log in with a local account instead and it will fail.

With the RSAT downloaded, I can configure the AD server remotely which is proper security posture.

Click on Group Policy Management. Here, I can set specific policies and rules that can be pushed out to hundreds and thousands of individual objects (pcs and/or users) to enforce security, compliance and enterprise operational standards.

In Active Directory Users and Computers, you can right click the empty space and click new user or click the new user button on the top and manually put in the details, as well as give them a password. Then, just right click their user and enable them.

PowerShell User Provisioning

You can significantly reduce the time and effort it takes to provision users and even other forms of objects by automating with PowerShell.

Automation Benefits:

• Consistent user account creation process
• Scalable approach for bulk user provisioning
• Reduced manual configuration errors

PowerShell has a certain syntax that you need to follow. Using the ‘get-command’, I can see all the available commands at my disposal and begin from there. Just like Python (a programming language), you would have to import certain modules to get access to commands that aren’t already there. Scrolling down, we see commands for Active Directory already there – so no need to import the module.

In our simple script, we are giving every new user the same secure password that they MUST change the moment they log on.

• Let’s breakdown this script: I am defining a secure password value: $Password in which the system will ask you to type in, shown by “Read-Host “Enter password”. The command “-AsSecureString” ensures the password is not shown in plaintext (in case a malicious actor somehow obtains these logs or files).
• Now, we only have to reference $Password in future lines. So with “New-ADUser -Name “Peter” -AccountPassword $Password” we created the user Peter with the password we just defined.
• Lastly, we enabled the account with -Enabled $true and are forcing Peter to change the password the moment he tries to log on with -ChangePasswordAtLogon $true.
• In a future AD project I will create a Group Policy Object that enforces Peter to create a secure password that aligns with our enterprise’s security policies.

In enterprises, they would likely have applications similar to vaults that contain different passwords that match the specifications required for their systems, in which they could use a script to pull these values from and give to new users (so you don’t have to use the same password for every user initially, as that can be a vulnerability).

• As you can see, the user Peter was created. Their account is enabled, has the password we securely configured, and whenever they log on, they will be prompted to change their password.