Active Directory

For CompTIA A+ Core 2 (220-1202), Domain 2.0, Objective 2.2, you need to know how Active Directory supports basic Windows OS security settings in real support work. In simple terms, AD gives IT one place to control who can sign in, what they can access, and which settings apply across many PCs. Because most business Windows networks use domains, help desk techs see AD tasks almost every day.

Picture a common onboarding ticket for a new employee: HR confirms the start date, the manager requests access, and the user needs a working PC by 9 a.m. If the account isn't placed in the right organizational unit (OU) or security group, the user may miss required apps, mapped drives, or password rules. On the other hand, if you grant too much access, you create avoidable risk.

By the end of this post, you'll be able to join a Windows device to a domain, move user and computer objects into the correct OUs, and apply Group Policy with purpose. You'll also learn how to select security groups that match job needs, assign logon scripts for consistent drive mapping, and set home folders for user data.

Finally, you'll practice configuring folder redirection so key folders (like Documents) follow the user and can be backed up. These are practical skills that reduce setup time, limit permissions issues, and keep Windows environments easier to manage.

AD Domain Control

For CompTIA A+ Core 2 (220-1202), Domain 2.0, Objective 2.2, you need a clear view of what Active Directory (AD) controls inside a Windows domain. In practice, AD acts like the organization's directory, rulebook, and gatekeeper. It connects identities (users and computers) to access (files, apps, printers) and settings (security options, desktop rules) so IT can manage many devices with consistent results.

Domain vs workgroup, what changes for users and PCs?

In a workgroup, each PC is its own island. User accounts and passwords live on each device, so the same person may have different passwords on different PCs. Access to shared folders often depends on matching local accounts, manual permissions, or saved credentials. As a result, support work turns into repeat setup on every machine.

In a domain, identities move to the center. Users sign in with a domain account (for example, EXAMWZ\j.smith or j.smith@examwz.local), and the domain controller checks the password. Because the account is centralized, password policies apply consistently. For example, minimum length, lockout rules, and password changes follow the user, not the PC.

The day-to-day sign-in experience also changes. Users can sign in to different domain-joined PCs and still receive the same baseline access and settings assigned to their account. Meanwhile, the PC itself has a domain identity too, which helps IT control it as a managed endpoint rather than a personal device.

Admins gain control because they can manage access and settings from a few central tools. Common examples include:

Centralized authentication: One username and password works across domain resources.
Access to shared resources: Permissions can rely on security groups instead of local accounts.
Policy control: Admins can apply Group Policy to set security options, firewall rules, and desktop restrictions.
Standardized onboarding: Joining a PC to the domain can trigger required settings and mappings.

Here's a simple example you will see on the job: a user signs in on any domain PC, and they get the same mapped drive (for example, the H: drive to their home folder) because a logon script or Group Policy drive mapping assigns it each time they log on.

In short, a workgroup trusts each PC to manage itself. A domain puts trust in the directory, then applies it across users and devices.

Key AD objects you will touch on the job

Most entry-level AD work revolves around a few object types. Once you recognize them, many tickets become predictable. A new hire ticket often means creating an account, placing it correctly, and confirming group membership and policy.

User accounts represent people or service identities. They store logon names, password settings, and key attributes like display name and department. More importantly, they become the "who" in access control. When a user can't open a shared folder, you often troubleshoot their group membership or the permissions assigned to those groups.

Computer accounts represent domain-joined devices. Each joined PC gets its own account in AD, which lets the domain apply device-based policies. This matters because some settings should follow the computer, not the person (for example, kiosk lockdown, local admin restrictions, or wireless profiles for a lab).

Security groups are how you assign permissions at scale. Rather than granting rights to individual users, you add users to groups, then grant the group access to a folder, printer, or application. This makes access changes safer and easier to audit.

Organizational units (OUs) are containers that structure the directory. OUs help you organize users and computers by location, department, or device type. They also define where you can link Group Policy and delegate admin tasks.

Group Policy Objects (GPOs) are collections of settings that Windows applies during startup and sign-in. You use GPOs to enforce password rules, desktop settings, mapped drives, scripts, and many security controls listed in Objective 2.2.

A common point of confusion is OUs vs groups. They solve different problems:

OUs are about structure and scope: They organize objects and control where GPOs apply.
Groups are about permissions: They decide what someone can access.

If you remember that OUs shape management and groups shape access, you will avoid many beginner mistakes.

Why DNS and time settings can break domain logins

Domain logins depend on services that must agree on names and time. When either part fails, users see errors that look like "wrong password," even when the password is correct.

First, DNS is the most common cause. Domain clients must use the organization's DNS (often the domain controller itself, or a DNS server integrated with AD). If a PC points to a public DNS server (or a home router), it may resolve internet sites but fail to locate domain controllers. As a result, the user can't authenticate, Group Policy won't apply, and mapped drives may not appear.

Common DNS failure patterns include:

The PC can't find a domain controller by name.
The domain join fails even though the network works.
Group Policy updates stall or apply only partially.

Second, time sync matters because Kerberos authentication uses time-based tickets. If the client clock drifts too far from the domain controller, authentication can fail. This can happen after a dead CMOS battery, a wrong time zone, or a device that stayed off-network for a long time.

When you suspect DNS or time, a few fast checks save minutes:

Run ipconfig /all and confirm the DNS server points to internal DNS, not a public resolver.
Check the system time and time zone on the client, then compare it to a known-good domain PC.
Test name resolution by pinging the domain by name (for example, ping yourdomain.local) and, if needed, ping a known domain controller hostname.

If those basics look wrong, fix them before you reset passwords or rejoin the domain. Many "account" tickets are really DNS or clock issues in disguise.

Domain Join

For CompTIA A+ Core 2 (220-1202), Domain 2.0, Objective 2.2, you need to join Windows PCs to an Active Directory domain with predictable results. In support work, most "domain join" tickets fail for the same reasons: wrong DNS, clock drift, weak credentials, or a naming conflict. If you treat the join like a short procedure, you reduce rework and avoid broken trust issues later.

Pre-join checklist that saves time

A domain join is like getting a key cut. If the blank is wrong, the lock will never turn. Before you click "Join," confirm a few basics so the PC can find a domain controller (DC) and complete Kerberos setup.

Start with the network and name services:

Network connection: Verify the PC is on the correct LAN or VPN. A captive portal or guest Wi-Fi often blocks domain traffic.
Correct DNS: The client must point to internal DNS (often the DC). Public DNS can browse the web but can't locate AD services.
Reach the DC by name: Confirm you can resolve and contact the DC using its hostname, not just an IP address. Name resolution is the core dependency.

Next, confirm time settings because authentication depends on them:

Correct time zone and time: Fix the time zone first, then correct the time. A wrong clock can cause Kerberos failures that look like bad passwords.

Finally, check device identity and access:

Device naming rules: Use your organization's standard (asset tag, location code, or role). Keep names unique and within common Windows limits.
Local admin access: You need local admin rights to join a domain. If you do not have them, plan for elevation before you start.

If DNS and time are correct, most domain joins succeed on the first attempt.

Joining the domain in Windows Settings and what it creates in AD

On Windows 10 and Windows 11, you can join through Settings in a few minutes. The exact wording varies by build, but the flow is consistent.

At a high level, the join steps are:

Open Settings, then go to Accounts (or System on some builds).
Find Access work or school, then choose Connect.
Select Join this device to a local Active Directory domain.
Enter the domain name (for example, corp.example.com), then provide domain credentials with join rights.
Choose the account options when prompted, then restart to complete the join.

After the restart, Windows establishes a machine identity in the domain. In Active Directory Users and Computers (ADUC), you will see a new computer object. By default, many environments place it in the Computers container unless admins redirect new computers to a specific OU. That object includes attributes such as the computer name, operating system details, and a password that the PC manages automatically.

The join also creates a trust relationship between the PC and the domain. In simple terms, the domain and the computer share a secret (the computer account password). They use it to prove identity during logon and when applying Group Policy. If that shared secret gets out of sync, users may see "The trust relationship between this workstation and the primary domain failed." That error usually means the machine account password no longer matches what AD expects, not that the user typed a bad password.

Quick fixes when the domain join fails

When a domain join fails, avoid random changes. Use a short troubleshooting order, because each step either confirms a dependency or removes a common blocker.

Follow this sequence:

Confirm DNS first: Check the client's DNS server settings. If the PC points to a router or public DNS, correct it and try again. Also confirm the client can resolve the domain and DC hostnames.
Verify the domain name: Mistyped domains cause immediate failures. Use the exact AD domain name your organization uses, and avoid guesswork.
Check time and time zone: If the clock is off, fix it before retrying. Time issues often cause authentication errors during the join.
Validate credentials and rights: Use an account allowed to join computers to the domain. Some organizations restrict this to specific groups or service accounts.
Look for firewall or network blocks: Ensure the PC can reach the DC over required services (DNS, Kerberos, LDAP, SMB, and RPC). A restrictive Wi-Fi segment or missing VPN split-tunnel routes can block the join.
Rule out a duplicate computer name: If the name already exists in AD, you may need to rename the PC, reset the existing computer account, or remove the stale object based on policy.
Reboot when prompted, and even when not: If the join partially completes, a restart may finish registration and policy processing.

A practical rule helps here: fix name resolution, then fix time, then fix permissions.