You are currently viewing Networks and Domains

Networks and Domains

Previously, I showed how you could set up a small network with the support of the Workgroup functionality, which works great at home where you have a small network. It also works in a small organization (< 30 computers), but the more computers there are connected to the network, the more complicated it will be to manage all these devices.

The problem with Workgroups is that they have to be maintained manually. At a certain point, your network infrastructure is too big to handle, reducing oversight and hurting security. At one point, you need to decide to centralize everything, increasing supervision and security. You can do this with domains, and in this post, I will show you how this is done: with the support of domains.

Domains

If you have a more extensive network, you only want control over it and want security in check. To do this, you can use a Windows domain. This network organization centralizes all user accounts, passwords, and access to resources.

When your computer runs in a Windows domain, it runs on a Windows Server, configured as a Domain Controller. A Domain Controller stores a set of domain accounts. When a user logs onto any computer inside this domain, they can use their one domain account to log into the entire network.

Working with a Domain Controller is different compared to Workgroups. In workgroups, every computer has its account, and as a system administrator, you have to manage every account on every computer separately. If a user uses different computers, you must add that account to the physical computer. The bigger the organization, the bigger the number of devices, and the more you have to walk around as a system administrator to fix issues on every machine. Although this is great to get in perfect shape (you will cross many miles every day), this is not very efficient.

You want to manage user accounts centrally, which a Domain Controller does. You can still log on using a local user account when a computer is on a domain which mainly happens during troubleshooting scenarios. When a user is a domain member, the user logs into the domain with a domain account, not a local account, attached to a physical computer. The user authenticates through the single domain account, enabling access to all the machines on the domain: single sign-on.

Active Directories

Suppose you have a single computer that stores all domain user names and passwords. In that case, you can take it one step further and store information about the domain, including printer information, computer names, location information: anything you need to define your entire network. This information can be kept centrally in Windows using an Active Directory domain.

If you want to use a domain on a network of a Windows device, you need to have a computer that runs a version of Windows Server. After that, you need to promote the server to a Domain Controller, and this step creates the Active Directory.

Briefly summarized: to create a domain, you need to set up a Windows Server as a Domain Controller, and by setting up an Active Directory, you can centrally manage and coordinate your complete network.

You don’t log onto your own computer when you use an Active Directory. Instead, you directly log on to the domain. You store all the user accounts on the Domain Controller. A lot of domains look like Web addresses. For instance, “example.com” or “example.local”. Many companies use a general name as administrator to log in, for example, “Admin.” To log into a domain, you would use example.com\Admin to log on. Security wise this is not a very smart thing to do. When you create admins to operate a domain, I would:

  • Create separate accounts for every admin, combined with the right set of authorizations
  • Create a strong password generated by a password generator that changes at least every 60 days
  • Install MFA when logging into a domain

You will be surprised how many organizations use the general name “Admin” and as a password “admin” or “1234”, the first guesses for a person outside the organization who wants unauthorized access to a network to obtain data or to infect the network with Ransomware. Just a brief “knock” on the door to check if it is wide open. When working with a domain, the first line of defense should be a compliant security policy for administrators.

Example of Domain Controller Login screen: I advise you to assign a username to an account

An active directory stores everything that happens on a network. To get into the Active Directory, you must log on directly to the Domain Controller first and run the Active Directory Users and Computers utility afterward. This tool provides the basic functions of the Active Directory, and it is easy to manage.

Active Directory Application in a Domain Controller

After that, you will get inside the application:

The Active Directory Users and Computers console, allows you to manage an individual domain

The folders beneath the domain name show the organization of the domain. They are not folders. They only look like folders, but they are organizational units. You can split organizational units into:

  • Builtin (sic): you store all the built-in domain groups in this folder, for instance, the Domain Administrators and Users
  • Computers: this folder stores every system from servers to workstations
  • Domain Controllers: it is always wise to have more than one Domain Controller in case one Domain Controller goes down. This way, you have a backup, just in case. This folder lists all Domain Controllers.

A robust Active Directory (AD) architecture is vital to manage your domains effectively. You need to set it up logically, and then it should be maintained to conform to the same structure.

Maintaining the AD is challenging for an administrator because it is not the sexiest work. Over time you tend to become sloppy, slowly drifting away from the standard architecture. Drifting away often happens when organizations increase, and people have a high retention rate, forcing admins to continuously create and remove users (including setting up proper authorizations) and add/remove computers. Especially in big organizations, AD management should be an integrated (routine part) of an admin’s day-to-day business.

IT resources (FTEs) are limited in many organizations: there is almost always under capacity and a heavy dependence on a few specialists. If this is the case, it is an option to outsource maintaining an AD to a specialized company. This way, you are sure that you initiate all your adjustments. If you don’t properly manage your AD, it can lead to security breaches and network issues for users.

Domain Administration: adding and removing devices to a domain

Once you have set up a server as a Domain Controller and an Active Directory has been created, you have to connect each network device: they all need to join the domain. When you connect all network devices, you automatically boot all the workgroup devices.

Just as individual systems have an administrator account, the domain also has domain administrators. Specific domain jobs require domain admin rights. If you want to add a computer to a domain, use the “System Properties” dialog box on the computer you want to add to the domain. You need to log into that computer physically: you can’t do this remotely. It works the same as with Workgroups. Access the System applet and click the “Change settings” link in the “Computer name, domain and workgroup settings” section to open the System Properties dialog box. Afterward, you click the Network ID button on the Computer Name tab to enter the dialog box. In graphical order (Windows 10 example):

Removing a system from a domain is done by accessing the domain controller, going into the Active Directory Users and Computers, right-clicking on the computer you want to remove from the domain, and selecting “Properties.” After that, you choose the “Member Of” tab and click the “Remove” button to remove the computer from the domain.

You can’t promote a local user or group to a domain user or group. As a domain admin, you have to create a new domain account on the Domain Controller, using Active Directory Users and Computers. Now you, right-click on Users and select New | User. After that, you open the New Object – User dialog box.

Solving account issues in a domain

One of the advantages of having a Domain Controller active is the fact that it sometimes happens that users forget their credentials. Instead of walking to a specific device and resetting the credentials, you can do this in the Active Directory, which saves a trip to the user.

If you want to reset a password, go to the “User” folder in the Active Directory and right-click on the user that needs a password reset. Then select “Reset Password,” which will open the Reset Password dialog box. Type in the new password but select that the user has to change this password the first time the user logs in. Immediately asking for a new password is basic security hygiene because, as an administrator, you should not know all passwords of local users and should not run into the risk that a provided password to a user is available to others for use.

Users try logging into their accounts a few times, but they fail. After that, they can’t log in anymore. It’s a primary security measure to prevent brute-force attacks. You can check “Unlock the user’s account” from the same dialog box” if the user is locked out. I always unlock an account simultaneously by resetting a password, and it prevents unnecessary additional communication once it appears a user is locked out and didn’t mention it. The whole password reset process in graphic order:

Final Thoughts

There is a lot of power in a domain account, and it allows features you rarely see in a local account. As an administrator, you must be very careful when working in a domain account and Active Directories. Mistakes can be very costly because they can result in a situation that creates downtime for one or more users when something goes wrong.

In the past, Domain Controllers and Active Directories were on-premise only, managing local networks. With the rise of Cloud computing, this is changing. We live in a hybrid area where Cloud computing and on-premise networks are mixed.   

As organizations continue to hunt down new operational efficiencies and the adoption of cloud-based SaaS applications continues to increase, you can’t help to start wondering if you still need on-premises Active Directory anymore. Maybe you can replace it with, for instance, Azure Active Directory, which is fully Cloud-based.

Moving away from on-premises Active Directory to Azure AD is viable, providing your organization has the necessary licensing and understands the complete cloud approach’s limitations. If you can operate within the rules, your organization can reduce the complexity of its identities by removing the on-premises directory services and gaining the efficiencies associated with this approach. And don’t forget the price tag. Cloud hosting is still relatively expensive, and thorough price research is critical. Feel free to contact me if you have any questions or if you have any additional advice/tips about this subject. If you want to keep me in the loop if I upload a new post, do not forget to subscribe to receive a notification by email.

Leave a Reply