Project Summary

This project demonstrates the deployment and configuration of Active Directory Domain Services within Microsoft Azure’s cloud infrastructure. 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 would not be able to talk to each other. Of course, if you use a router/gateway, then they would be able to speak to each other if they are in different subnets – but that’s for our Network Projects.

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 a dedicated server providing the 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 version(s) still receiving updates for maximum security.
• Domain Name: carlostech.local
• NetBIOS Name: CARLOSTECH (for legacy systems)
• DNS Integration: Integrated DNS zones for lookups (allows for auto replication to all domain controllers and multiple DCs can update DNS records).

• Using the Server Manager application, we are adding the AD role to our server, making it a Domain Controller.

• Domain Controllers are the authoritative servers for AD. The changes you make here replicate to other domain controllers where clients/hosts receive these updates through authentication and Group Policy. It’s therefore vital to have redundant DC’s for fault tolerance. Note that in this project, we did not utilize redundancy because it is an isolated lab. However, Azure AD Domain Services automatically provides you with two DCs when you utilize their managed services. The 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 domain because this is a local project that will not propagate to the Internet.
  • We created a new forest because we are starting from scratch.
  • AD domains need a forest as they cannot exist outside of one and a forest does not exist without domains either.
  • AD automatically names the forest after the “root domain” we configured when you first configure it.

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

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” command to see our IP address configurations.

• This is the output for the client workstation, which was identical with the output for our server except the server’s IP address was 10.0.0.4. That is the confirmation 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 which you typically only configure 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 workstation to point to a DNS server for DNS queries (typically a DHCP server tells your workstation what DNS server to send queries to).
  • Humans prefer typing in google.com because it’s 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.
• To fix this, 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.

• On the workstation’s settings, go to “Rename this pc (advanced)” where you can configure the name of this workstation to align with your enterprise’s naming standard and/or policy. But the most important part here is to configure the “member of: domain” setting to carlostech.local.

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.

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 all domains within the forest!

• Logging into my Windows10 PC as an admin, I would use the username: ‘carlostech.local\helpdesk’. The reason why I have to include the domain carlostech.local\ is because I want the virtual machine 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 (computers 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 located at the top menu, 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 dissect this script:

• I am defining a secure password value: ($Password) where the system will ask you to type it in, shown by the “Read-Host “Enter password” commands. The command “-AsSecureString” enforces the password to not be shown in plaintext.
  • This security measure prevents credentials from being exposed if logs or configuration files are somehow compromised by a malicious actor.
• Now, we only have to reference $Password in future lines. With the “New-ADUser -Name “Peter” -AccountPassword $Password” commands, 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 the -ChangePasswordAtLogon $true command.
  • In a future Active Directory project, I will create a Group Policy Object that enforces Peter to create a secure password that aligns with our enterprise’s security policies.

To have improved security, create a vault that contains a similar, more concise script that can pull a different, secure password from a pool each time the script is run – removing the vulnerability of reusing the same password for each user creation.

• 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.