{"id":202,"date":"2025-10-05T16:08:01","date_gmt":"2025-10-05T16:08:01","guid":{"rendered":"https:\/\/carlostech.com\/?p=202"},"modified":"2025-11-03T23:14:47","modified_gmt":"2025-11-03T23:14:47","slug":"active-directory-implementation-using-azure","status":"publish","type":"post","link":"https:\/\/carlostech.com\/?p=202","title":{"rendered":"Active Directory Lab 1 – Azure"},"content":{"rendered":"\n

Project Summary<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

\n

Infrastructure Architecture<\/h3>\n<\/blockquote>\n\n\n\n

Primary Domain Controller (Azure VM)<\/strong><\/p>\n\n\n\n

Using Azure’s GUI we configured our DC as: <\/p>\n\n\n\n

    \n
  • Operating System:<\/strong> Windows Server 2019 Datacenter.<\/li>\n\n\n\n
  • Azure Region:<\/strong> East US (selected for optimal latency and cost-efficiency).<\/li>\n\n\n\n
  • Security Tier:<\/strong> Standard (lab environment; production would require premium security features)<\/li>\n\n\n\n
  • Redundancy:<\/strong> 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).<\/li>\n<\/ul>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
      \n
    • 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.<\/li>\n<\/ul>\n\n\n\n
      \"\"<\/figure>\n\n\n\n
        \n
      • 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).<\/li>\n<\/ul>\n\n\n\n
        \"\"<\/figure>\n\n\n\n
          \n
        • 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 \u2013 but that’s for our Network Projects. <\/li>\n<\/ul>\n\n\n\n
          \n

          Network Architecture<\/h3>\n<\/blockquote>\n\n\n\n

          Virtual Network Configuration:<\/strong><\/p>\n\n\n\n

            \n
          • Address Space:<\/strong> 10.0.0.0\/24 (private IPs).<\/li>\n\n\n\n
          • Subnet Mask:<\/strong> \/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).<\/li>\n\n\n\n
          • Available Host Addresses:<\/strong> 254 usable addresses (256 total minus network and broadcast addresses).<\/li>\n\n\n\n
          • IP Address Allocation:<\/strong>\n
              \n
            • Domain Controller: 10.0.0.4 (provided by Azure DHCP).<\/li>\n\n\n\n
            • Client Workstation: 10.0.0.5 (provided by Azure DHCP).<\/li>\n\n\n\n
            • 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). <\/li>\n<\/ul>\n<\/li>\n\n\n\n
            • Gateway Configuration:<\/strong> Azure-managed default gateway.<\/li>\n\n\n\n
            • DHCP Services:<\/strong> Azure-provided (production environments typically use a dedicated server providing the DHCP role)<\/li>\n<\/ul>\n\n\n\n

              Network Security Considerations:<\/strong> 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.<\/p>\n\n\n\n

              Active Directory Implementation<\/h3>\n\n\n\n

              Domain Configuration<\/h3>\n\n\n\n

              Domain Specifications:<\/strong><\/p>\n\n\n\n

                \n
              • Forest Functional Level:<\/strong> 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.<\/li>\n\n\n\n
              • Domain Name:<\/strong> carlostech.local <\/li>\n\n\n\n
              • NetBIOS Name:<\/strong> CARLOSTECH (for legacy systems)<\/li>\n\n\n\n
              • DNS Integration:<\/strong> Integrated DNS zones for lookups (allows for auto replication to all domain controllers and multiple DCs can update DNS records).<\/li>\n<\/ul>\n\n\n\n
                \"\"<\/figure>\n\n\n\n
                  \n
                • Using the Server Manager application, we are adding the AD role to our server, making it a Domain Controller.<\/li>\n<\/ul>\n\n\n\n
                  \"\"<\/figure>\n\n\n\n
                  \"\"<\/figure>\n\n\n\n
                    \n
                  • 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\u2019s therefore vital to have redundant DC\u2019s 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 \u201ccarlostech.local\u201d, 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.\n
                      \n
                    • We created a new forest because we are starting from scratch.<\/li>\n\n\n\n
                    • AD domains need a forest as they cannot exist outside of one and a forest does not exist without domains either. <\/li>\n\n\n\n
                    • AD automatically names the forest after the “root domain” we configured when you first configure it. <\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n
                        \n
                      • Typically, you do NOT use .local, you would use carlostech.com and create subdomains such as local.carlostech.com, mail.carlostech.com, etc. because:\n
                          \n
                        • You could have technical conflicts with various technologies.<\/li>\n\n\n\n
                        • If you ever wanted to expand into the cloud, you could have integration issues.<\/li>\n\n\n\n
                        • You will not be able to get a public SSL certificate.<\/li>\n\n\n\n
                        • It lacks professional appearance and does not follow standardized naming for internet domains.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n

                          The Domain Controller was configured with multiple roles such as:<\/p>\n\n\n\n

                            \n
                          • Active Directory Domain Services (AD DS):<\/strong> Core directory services (hosting the AD database).<\/li>\n\n\n\n
                          • DNS Server Role:<\/strong> Provides name resolution for domain resources.<\/li>\n\n\n\n
                          • File and Storage Services:<\/strong> Enables file sharing and storage management.<\/li>\n<\/ul>\n\n\n\n

                            Note<\/em>:<\/strong> In production environments, role separation would typically be implemented across multiple servers for security and performance optimization.<\/p>\n\n\n\n

                            Remote Administration Configuration<\/h3>\n\n\n\n

                            Remote Server Administration Tools were deployed on the Windows 10 client workstation to demonstrate secure remote management principles:<\/p>\n\n\n\n

                            \"\"<\/figure>\n\n\n\n

                            Security Benefits:<\/strong><\/p>\n\n\n\n