This chapter covers the fundamental differences between a workgroup and a domain join in Windows environments, a core topic for CompTIA A+ 220-1102 Objective 1.5. Understanding these networking models is critical because exam questions frequently test your ability to identify which model is appropriate for a given scenario and to explain the underlying authentication and resource-sharing mechanisms. Approximately 5-7% of the Operating Systems domain questions touch on workgroup vs domain concepts, often in the context of troubleshooting connectivity or determining the correct network type for a small business.
Jump to a section
Imagine a workgroup as an apartment complex where each resident owns their own lockbox with keys to their own apartment. If you want to share a lawnmower, you must manually give a copy of your key to each neighbor who needs it. If a neighbor moves out, you have to retrieve your key or change the lock. There is no central management—each resident decides who can enter their apartment. Now imagine a domain as a corporate headquarters with a single security desk. Every employee gets a badge that the security desk issues and verifies. If you need to access the server room, you don't give out your key; you request access from the security desk, which checks your badge and logs the entry. If an employee is fired, the security desk simply deactivates their badge, instantly revoking all access. In a workgroup, each computer maintains its own local user database—like each apartment having its own list of allowed visitors. In a domain, a central directory service (Active Directory) holds all user accounts and permissions—like a master list at the security desk. When a user logs on to a domain-joined computer, the computer sends the credentials to the domain controller for verification, just as an employee swipes their badge at the security desk before entering the building. The domain controller responds with an authentication token that grants access based on group memberships—like the security desk giving a visitor badge with specific floor access. This centralized authentication eliminates the need to manage accounts on every single machine, simplifying administration and enhancing security.
What is a Workgroup?
A workgroup is a peer-to-peer networking model where each computer in the network is equal. There is no central authority; each computer manages its own local user accounts and security policies. In a workgroup, every machine has its own Security Accounts Manager (SAM) database stored in the Windows registry. When a user logs on locally, the computer checks its own SAM. When accessing shared resources on another workgroup computer, the user must supply credentials that exist on that remote computer. This means you need a separate user account on each machine you want to access. Workgroups are designed for small networks (typically fewer than 20 computers) where centralized management is not required. By default, Windows installs in a workgroup called "WORKGROUP" (or "MSHOME" in older versions).
What is a Domain?
A domain is a client-server networking model where a central directory database called Active Directory (AD) runs on one or more domain controllers (DCs). The AD database stores all user accounts, computer accounts, groups, and security policies for the entire domain. When a computer joins a domain, it becomes a member of the domain and trusts the domain controllers to authenticate user logins. This enables single sign-on (SSO): a user can log on once with their domain credentials and access any resource in the domain that their account is permitted to use, without re-entering credentials. Domains are essential for organizations with more than a handful of computers, as they provide centralized user management, group policy enforcement, and scalable security.
How Domain Authentication Works
When a user logs on to a domain-joined computer, the following steps occur:
The user presses Ctrl+Alt+Del and enters their username and password (or smart card PIN).
The Local Security Authority (LSA) on the client computer packages the credentials and sends them to a domain controller using Kerberos v5 (the default authentication protocol in Active Directory).
The domain controller verifies the credentials against the AD database. If valid, it issues a Ticket-Granting Ticket (TGT) to the client.
The client caches the TGT locally. When the user tries to access a network resource (e.g., a file share), the client presents the TGT to the domain controller to request a service ticket for that specific resource.
The domain controller issues a service ticket, which the client presents to the resource server. The server grants access based on the permissions in the service ticket.
This whole process happens transparently to the user. If the domain controller is unreachable and the user has logged on to that computer before, cached credentials allow offline logon. The cached logon count is controlled by Group Policy (default is 10 logons).
Key Components and Defaults
Workgroup Name: Default is "WORKGROUP" (Windows 10/11) or "MSHOME" (older). It is case-sensitive but Windows treats it case-insensitively. Maximum length is 15 characters. No spaces allowed.
Domain Name: Must be a valid DNS name (e.g., corp.contoso.com). NetBIOS name (pre-Windows 2000) is limited to 15 characters.
Computer Account: Every domain-joined computer has a computer object in AD with a password that is automatically changed every 30 days by default.
Domain Controller: At least one DC is required. For redundancy, multiple DCs are recommended. DCs replicate AD data among themselves.
Authentication Protocols: Kerberos v5 (default), NTLMv2 (used when Kerberos fails or for older systems).
Group Policy: Applied to domain-joined computers. Local Group Policy exists on all computers but is overridden by domain-based policies.
Configuration and Verification Commands
To join a domain or workgroup, you can use the System Properties GUI (sysdm.cpl) or PowerShell.
PowerShell to join a domain:
Add-Computer -DomainName "corp.contoso.com" -Credential CORP\Administrator -RestartPowerShell to join a workgroup:
Add-Computer -WorkgroupName "WORKGROUP" -RestartVerification commands:
net config workstationThis displays the computer name and the domain/workgroup it belongs to.
systeminfo | findstr /B /C:"Domain"Get-WmiObject Win32_ComputerSystem | Select-Object Domain, WorkgroupTo check if a computer is domain-joined:
echo %userdomain%If the computer is in a domain, %userdomain% returns the domain name. Otherwise, it returns the computer name.
How Workgroup Resource Sharing Works
In a workgroup, sharing a folder requires you to create a local user account on the computer hosting the share, or use the built-in Guest account (disabled by default). When a remote user tries to access the share, they must provide credentials that match a local account on the host. The host checks its SAM database. If authentication succeeds, the host grants access based on the share and NTFS permissions. There is no centralized trust; each computer independently authenticates users. This becomes unmanageable beyond a few machines because you must create identical user accounts on every computer with the same password, and keep them synchronized manually.
Group Policy Differences
In a workgroup, only Local Group Policy (LGPO) is available. You can configure settings via gpedit.msc but these apply only to the local machine and the local users. In a domain, Group Policy objects (GPOs) are stored in AD and linked to sites, domains, or organizational units (OUs). They apply to all computers and users in the scope. Domain-based GPOs override local policies. The exam tests that you know domain-joined computers can receive GPOs from the domain, while workgroup computers cannot.
Network Discovery and Sharing
Workgroups rely on NetBIOS over TCP/IP and the Computer Browser service (deprecated in newer Windows) to discover computers. In modern Windows, network discovery uses Function Discovery and WS-Discovery. By default, Windows Firewall blocks network discovery for public networks. Domain-joined computers can use DNS and Active Directory to locate resources more efficiently. The exam expects you to know that workgroups are suitable for small, non-centralized environments, while domains are required for centralized management in larger organizations.
Joining and Leaving a Domain
To join a domain, you need:
A domain controller that is reachable and running Active Directory.
A domain user account with permission to join computers to the domain (typically Domain Admins or a delegated account).
The computer must be running a supported edition of Windows (Pro, Enterprise, or Education; Home edition cannot join a domain).
Proper DNS configuration: the computer's DNS server must point to the domain controller or a DNS server that can resolve the domain's SRV records.
To leave a domain and return to a workgroup, you need local administrator credentials on the computer (since you are removing the computer from the domain, you need to authenticate as a local admin). The domain administrator password is not required if you have local admin rights.
Common Issues and Troubleshooting
DNS misconfiguration: If the client cannot resolve the domain controller's SRV records, domain join fails. Verify DNS settings with nslookup -type=SRV _ldap._tcp.dc._msdcs.<domain>.
Time skew: Kerberos requires the client and DC clocks to be within 5 minutes of each other. Use w32tm /resync.
Duplicate computer names: Each computer in a domain must have a unique name. Use netdom verify to check.
Firewall blocking: Ports 88 (Kerberos), 389 (LDAP), 445 (SMB), 135 (RPC) must be open between client and DC.
Credential delegation: Double-hop issues can occur when accessing remote resources from a remote session. Use CredSSP or Kerberos delegation.
Interoperability
Workgroup computers can access domain resources if they have a local account on the domain resource or if the domain allows anonymous access (rare). Conversely, domain-joined computers can access workgroup resources by supplying workgroup credentials. However, seamless SSO only works within the domain.
Cloud and Modern Alternatives
With Azure AD (now Microsoft Entra ID), devices can be joined to the cloud without an on-premises domain. This is called Azure AD Join. It provides SSO to cloud resources (Office 365, Azure apps) and allows mobile device management (MDM) via Intune. Hybrid Azure AD Join combines on-premises AD with Azure AD. The exam may touch on these as modern alternatives, but the core focus remains on traditional workgroup vs domain.
Decide Network Model
The first step is to determine whether the environment requires a workgroup or a domain. For a small home network or a tiny office with fewer than 10 computers and no IT staff, a workgroup is sufficient. For any organization that needs centralized user management, security policies, or has more than 10-20 computers, a domain is necessary. The exam tests your ability to recommend the correct model based on scenario details such as number of users, need for centralized control, or single sign-on.
Set Up Domain Controller
If a domain is chosen, install Windows Server and promote it to a domain controller using Server Manager or PowerShell. This installs Active Directory Domain Services (AD DS) and creates the domain. The first DC in a forest creates the forest root domain. DNS must be installed as well, because AD DS requires DNS to locate other DCs and services. The domain controller will hold the master copy of the AD database and authenticate all domain logons.
Configure DNS
For a domain to function, DNS must be properly configured. The domain controller typically runs DNS. Client computers must have their DNS server set to the DC's IP address. Without correct DNS, clients cannot find the domain controller for authentication or group policy application. The exam often includes troubleshooting scenarios where a client cannot join a domain due to DNS misconfiguration.
Join Computer to Domain
On each client computer running Windows Pro/Enterprise, go to System Properties > Computer Name/Domain Changes, select "Domain," enter the domain name, and provide domain administrator credentials. Alternatively, use PowerShell: `Add-Computer -DomainName`. The computer creates a computer account in AD and establishes a trust relationship. The computer's local SAM is no longer used for domain user authentication; instead, the DC authenticates users.
Create User Accounts and Groups
In a domain, all user accounts are created in Active Directory Users and Computers (ADUC) on the DC. Groups (security groups) are also created centrally. Permissions to resources are assigned to these groups. In a workgroup, you must create local user accounts on each computer individually. The exam expects you to know that domain user accounts are stored in AD, while workgroup accounts are stored in the local SAM.
Configure Sharing and Permissions
In a domain, you share folders and assign permissions to domain groups (e.g., Domain Users). Users access resources with their domain credentials, and authentication is handled transparently by Kerberos. In a workgroup, you must create identical local accounts on the sharing computer and the accessing computer, or enable Guest access (insecure). The exam tests that domain sharing is simpler and more secure than workgroup sharing.
Apply Group Policies
In a domain, administrators create Group Policy Objects (GPOs) linked to OUs. These GPOs enforce settings like password policies, desktop configurations, and software installation across all domain computers. Workgroup computers only support Local Group Policy, which is much more limited. The exam highlights that domain environments can enforce consistent policies centrally.
In a real-world enterprise, the choice between workgroup and domain is clear-cut. For example, a marketing agency with 15 employees uses a domain. They have a single file server and a shared printer. Each employee has a domain account that grants access to the file shares and printer. The IT administrator uses Group Policy to enforce a password complexity policy and to map network drives automatically. If an employee leaves, the admin disables their AD account, instantly revoking access to all resources. Without a domain, the admin would need to delete or disable accounts on each computer and server individually — a tedious and error-prone process.
Another scenario: a school district with hundreds of computers across multiple schools. They use Active Directory with OUs for each school and each department. Group Policy enforces security settings, installs educational software, and restricts student accounts from installing software. Domain controllers are replicated across sites for redundancy. If a student attempts to log on with a disabled account, the domain controller rejects the login immediately. In a workgroup, managing this scale would be impossible.
A common misconfiguration occurs when a small business tries to use a workgroup but needs centralized file sharing. They create local accounts on the file server for each user, but when passwords change, they must update them on every client machine that maps drives. This leads to frequent lockouts and help desk tickets. The solution is to migrate to a domain, which the exam might present as a troubleshooting scenario. Another issue: a domain-joined computer cannot log on because the DC is unreachable and the user has never logged on before (no cached credentials). The exam tests that you should connect the computer to the network or use a local admin account to log on and troubleshoot connectivity.
Performance considerations: In a domain, authentication traffic is minimal for each logon, but if the DC is underpowered or there are many simultaneous logons, users may experience delays. Scaling to thousands of users requires multiple DCs and proper site design. Workgroups have no such infrastructure but suffer from administrative overhead as they grow.
The CompTIA A+ 220-1102 exam tests Objective 1.5: "Given a scenario, install and configure Windows networking features." Within this, the concepts of workgroup vs domain are tested in about 5-7% of the Operating Systems questions. The exam expects you to:
Identify the correct networking model for a given scenario (e.g., small office vs enterprise).
Understand the authentication process: local SAM vs Active Directory.
Know the limitations of a workgroup: no centralized management, no single sign-on, limited to 20 computers.
Recognize that only Windows Pro, Enterprise, or Education can join a domain; Home editions cannot.
Understand that Group Policy is available only in a domain (except Local Group Policy).
Know that a domain requires a domain controller running Active Directory.
Common wrong answers and why candidates choose them: 1. "A workgroup provides centralized user management." — Wrong because workgroups are peer-to-peer; each computer manages its own accounts. Candidates confuse workgroup with domain. 2. "A domain requires a dedicated server running Windows Server." — While true in practice, the exam may present a scenario where a server is not explicitly mentioned; the key is that a domain controller is needed. 3. "You can join a Windows 10 Home edition to a domain." — Wrong; Home edition lacks the necessary features. Candidates may think all Windows versions can join. 4. "In a workgroup, users can access shared resources without entering credentials if they have an account on the remote computer." — This is partially true but misleading; the credentials must match exactly. Candidates often think no credentials are needed.
Specific numbers and terms: - Default workgroup name: "WORKGROUP" (case-insensitive). - Maximum workgroup name length: 15 characters. - Cached logon count default: 10 logons. - Kerberos time skew tolerance: 5 minutes. - Ports: 88 (Kerberos), 389 (LDAP), 445 (SMB).
Edge cases: - A domain-joined computer can log on with cached credentials if the DC is unavailable, but only if the user has logged on before (cached logon count not exceeded). - A workgroup computer can access a domain resource if it has a local account on the domain resource server. - Azure AD Join is not the same as traditional domain join; the exam may ask about "Microsoft account" vs "domain account."
How to eliminate wrong answers: - If the scenario mentions "centralized management" or "single sign-on," the answer must involve a domain. - If the scenario mentions "small office with 5 computers and no server," the answer is workgroup. - If the question asks about Group Policy, the answer is domain (unless it specifies Local Group Policy). - If the question involves "local user accounts," it's a workgroup.
By understanding the underlying mechanism—centralized authentication via a domain controller vs decentralized local authentication—you can reason through any scenario.
A workgroup is a peer-to-peer network where each computer has its own local user database (SAM) and no central management.
A domain is a client-server network with Active Directory providing centralized authentication, authorization, and policy enforcement.
Only Windows Pro, Enterprise, and Education editions can join a domain; Home edition cannot.
Workgroups are limited to about 20 computers; beyond that, a domain is recommended for manageability.
Domain authentication uses Kerberos v5 by default; NTLMv2 is used as a fallback.
Group Policy in a domain allows centralized configuration; workgroups only support Local Group Policy.
To join a domain, proper DNS resolution of the domain controller's SRV records is required.
Cached credentials allow domain logon when the domain controller is unreachable, but only if the user has logged on before (default: 10 cached logons).
These come up on the exam all the time. Here's how to tell them apart.
Workgroup
Peer-to-peer network model; no central authority.
Each computer manages its own local user accounts (SAM).
No single sign-on; must authenticate separately to each resource.
Suitable for small networks (typically <20 computers).
No central Group Policy; only Local Group Policy available.
Domain
Client-server model with central Active Directory database.
User accounts stored in AD on domain controllers.
Single sign-on: one logon grants access to all permitted resources.
Scalable to thousands of computers; required for enterprise.
Centralized Group Policy via GPOs linked to OUs.
Mistake
A workgroup provides centralized user account management.
Correct
A workgroup is peer-to-peer; each computer has its own local SAM database. There is no central repository for user accounts. Centralized management is a feature of a domain using Active Directory.
Mistake
Any edition of Windows can join a domain.
Correct
Only Windows Pro, Enterprise, and Education editions can join a domain. Windows Home edition cannot; it only supports workgroups.
Mistake
In a workgroup, you can access shared resources without any credentials.
Correct
Accessing shared resources in a workgroup always requires authentication. If the Guest account is enabled, it is still an account. By default, the Guest account is disabled for security.
Mistake
A domain requires a dedicated server running Windows Server, but a workgroup can also have a server.
Correct
A domain requires at least one domain controller (typically Windows Server). A workgroup does not require any server; all computers are peers. However, you can have a server in a workgroup, but it still uses local accounts.
Mistake
Group Policy is available in both workgroups and domains.
Correct
Local Group Policy (gpedit.msc) is available on all Windows Pro/Enterprise computers, but it applies only to the local machine and local users. Domain-based Group Policy (GPOs) is only available in a domain environment and can be applied to many computers centrally.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, Windows 10 Home edition does not support domain join. Only Pro, Enterprise, and Education editions can join a domain. If you need to connect a Home computer to a domain network, you must upgrade to a supported edition. However, you can still access domain resources by logging in with a local account and supplying domain credentials when prompted, but you won't get single sign-on or Group Policy.
In a workgroup, security is per-machine; each computer must be individually secured. If one machine is compromised, others are not directly affected, but there is no central audit trail. In a domain, security is centralized: user accounts, passwords, and permissions are managed in AD. Group Policy enforces security settings across all computers. Domain controllers can enforce password policies and account lockouts. Auditing is centralized. Overall, domains provide stronger, more manageable security for organizations.
Go to System Properties > Computer Name/Domain Changes, select "Workgroup," enter the workgroup name (e.g., WORKGROUP), and click OK. You will be prompted for local administrator credentials (not domain admin). The computer will leave the domain and local user accounts will become the primary authentication method. Note that the computer account in AD remains orphaned unless cleaned up by an administrator. You can also use PowerShell: `Add-Computer -WorkgroupName "WORKGROUP" -Restart`.
If a domain controller goes down, domain users who have previously logged on to a computer can still log on using cached credentials (up to the cached logon count, default 10). However, users who have never logged on to that computer before cannot log on because there is no cache. Also, password changes cannot be processed, and Group Policy updates will not occur until a DC is available. If multiple DCs exist, the client will automatically try another DC. For uninterrupted operation, organizations deploy at least two DCs.
Yes, but not with single sign-on. The workgroup computer must supply valid domain credentials when accessing the domain resource. For example, if you map a network drive from a workgroup computer to a domain file server, you will be prompted for a username and password that exist in the domain. You can check "Remember my credentials" to avoid re-entering each time. However, this is less convenient than a domain-joined computer that uses Kerberos automatically.
The default workgroup name in Windows 10 and 11 is "WORKGROUP." In older versions like Windows XP, it was "MSHOME." The name is case-insensitive but can be changed to any name up to 15 characters, with no spaces. All computers in the same workgroup should use the same workgroup name to appear in Network Neighborhood.
Yes, a domain requires at least one server running Windows Server with Active Directory Domain Services installed. This server is called a domain controller. For small organizations, a single server can act as both domain controller and file server. For redundancy, multiple domain controllers are recommended. You cannot create a domain using only client operating systems like Windows 10.
You've just covered Workgroup vs Domain Join — now see how well it sticks with free 220-1102 practice questions. Full explanations included, no account needed.
Done with this chapter?