Hello! In this third installment of the series, we cover joining clients and servers to the domain.

Introduction

Hello, and welcome to Part 3 of the series, "Joining Clients and Servers to the Domain."

In the previous installment (Part 2), we walked through building an Active Directory domain environment in detail, from setting up the domain controller to configuring DNS. Now that the foundation of the domain environment is in place, it is finally time to join actual computers to the domain.

Have you ever run into situations like "I created a domain user account, but for some reason I can't log in" or "we added a new PC, but domain authentication doesn't work"? In the world of Active Directory, creating a user account is not enough — the computer that user works on must itself be "joined" to the domain.

In this article, we go beyond a simple walkthrough of the steps and explain the underlying mechanics — why the domain join is necessary and what actually happens behind the scenes — in a way that beginners can follow. We cover practical ground: how to join Windows PCs, Windows Servers, and even Linux servers to a domain, plus how Group Policy is automatically applied after joining.

In particular, when deploying AI security tools or cloud services in an enterprise, understanding how domain joins work becomes a powerful asset for troubleshooting. So let's explore together the world of "trust relationships" at the heart of Active Directory!

Series Outline

Chapter 1: Understanding the Basic Concepts - Fundamentals of Active Directory and Kerberos/NTLM authentication

Chapter 2: Building the Domain Environment - Steps for building a test environment

[★ This installment ★] Chapter 3: Joining Clients and Servers to the Domain - Detailed domain join procedures

Chapter 4: Proxy Servers and Integrated Windows Authentication

Chapter 5: Browser Configuration and Authentication - Configuration steps for each browser

Chapter 6: Troubleshooting - Common problems and solutions

Chapter 7: Security and Best Practices - Considerations for production environments

Chapter 8: Practical Configuration Examples - Integration examples with AI security tools

Chapter 3: Joining Clients and Servers to the Domain

3.1 Domain Join Fundamentals

3.1.1 Why the Domain Join Is Necessary

A misconception many beginners share is the idea that

"as long as a user has a domain account, they can log in from any PC."

In reality, even if the user has an account, the PC that user works on must also be joined to the domain.

[A common misconception]
New employee: "I got my domain account (tanaka_t)!"
New employee: "So I can use any PC in the company now, right?"
IT admin: "No — that PC also needs to be joined to the domain."
New employee: "What? The PC needs to join too?"

(A real-world analogy)
New employee: "I got my employee badge!"
New employee: "So I can enter any company building, right?"
Security guard: "No — the building must be under the company's management."
New employee: "I see..."

Let's look at what happens on a PC that has not joined the domain.

[Login attempt on a non-joined PC]
Tanaka: "I want to log in to this PC."
(Login screen)
Username: tanaka_t
Password: ********
Sign in to: This computer  <- The domain cannot be selected!

Tanaka: "Huh? I can't choose the domain."
PC: "I don't know any domain. I only accept local accounts."

Tanaka: "Then let me type it manually... JP\tanaka_t"
PC: "JP? What's that? I don't know that domain."

On a domain-joined PC, the situation is completely different.

[Login on a joined PC]
Tanaka: "I want to log in to this PC."
(Login screen)
Username: tanaka_t
Password: ********
Sign in to: JP  <- The domain can be selected!

PC: "You are tanaka_t of the JP domain (jp.qualiteg.com), correct?"
PC -> DC (domain controller): "Is this person genuine?"
DC: "Checking the password... yes, this is the real Tanaka."
PC: "Confirmed. Please go ahead and log in."
Tanaka: "Great!"

Let's understand what the domain join really means.

[Establishing a trust relationship]
IT admin: "Joining a domain means creating a trust relationship between the PC and the domain."

Before joining:
PC: "I am an independent computer."
DC: "I don't know this PC. I can't trust it."

Join process:
Admin: "I am joining this PC to the domain." (run with administrator privileges)
DC: "Verifying the administrator's credentials... OK, registering this PC as one of us."
PC: "From now on, I am a member of the jp.qualiteg.com domain."

After joining:
PC: "I am PC-001 of the jp.qualiteg.com domain."
DC: "Ah, PC-001. You are a trusted member."

Let's look at the benefits of joining the domain.

[Administrative benefits]
CEO: "Is it worth the effort of joining every PC to the domain?"
IT admin: "There are major benefits."

1. Unified management
IT admin: "Group Policy lets us configure every PC at once."
Example: "Lock the screen after 10 minutes of inactivity on all PCs" — achieved with a single setting

2. Single sign-on
Tanaka: "Once I log in in the morning, no extra authentication for the file server or email!"

3. Roaming profiles
Tanaka: "Whichever PC I log in to, my desktop environment follows me."

4. Security
IT admin: "Who used which PC and when — everything is recorded."

CEO: "I see — management becomes dramatically easier."

3.1.2 What Is a Computer Account?

In AD, not only users but computers themselves are managed as accounts. This may be a concept many people find hard to grasp.

[Are computers employees too?]
Newcomer: "What is a computer account? It's not a person."
IT admin: "Let's use the company as an analogy."

What the company manages:
- Full-time employees (Tanaka, Yamada) -> user accounts
- Company cars (car No. 1, No. 2) -> computer accounts

General affairs: "Company cars have asset numbers, and who may use them is defined."
IT admin: "In the same way, PCs must be registered as managed assets."

Let's look at computer accounts in practice.

[Viewed in the AD management tool]
IT admin: "Open 'Active Directory Users and Computers'."

jp.qualiteg.com
├── Users
│   ├── tanaka_t (Taro Tanaka)
│   ├── yamada_h (Hanako Yamada)
│   └── Administrator
└── Computers
    ├── PC-001$  <- The $ mark indicates a computer account
    ├── PC-002$
    └── SERVER-01$

Newcomer: "You're right! The PCs are listed too."
IT admin: "The trailing $ on the computer name is the telltale sign."

Let's understand computer account credentials.

[Computers have passwords too]
Newcomer: "But I've never seen a PC type in a password."
IT admin: "It actually happens automatically behind the scenes."

Characteristics of a computer account:
- Account name: PC-001$
- Password: (a random 120-character string)
- Password change: automatically renewed every 30 days

Newcomer: "120 characters!?"
IT admin: "No human needs to remember it. The PC manages it automatically."

What actually happens:
Every morning at startup...
PC: "Good morning. This is PC-001$."
PC: "My password is... Xk9#mP2$... (120 characters)"
DC: "Checking the password... OK, this is the real PC-001$."

Let's look at the role computer accounts play.

[Why are computer accounts necessary?]
Sales: "Isn't user authentication enough?"
IT admin: "For security, the PC must be authenticated too."

Scenario 1: Blocking a malicious PC
Attacker: "Let me plug a rogue PC into the company network."
Rogue PC: "Tanaka is trying to log in."
DC: "Hold on — who are you? Where is your computer account?"
Rogue PC: "...I don't have one."
DC: "Access from an untrusted PC is denied."

Scenario 2: A legitimate PC
PC-001: "Tanaka is trying to log in."
DC: "PC-001$ — you are a registered, trusted PC."
DC: "Tanaka's credentials check out as well. Login OK."

Let's see what a computer account can do.

[Computer account privileges]
Newcomer: "What can a computer account actually do?"
IT admin: "Quite a lot, actually."

1. Register its own information in DNS
PC-001: "My IP address changed, so I'm updating DNS."
DNS: "A request from PC-001$... trusted, update accepted."

2. Retrieve Group Policy
PC-001: "Please give me the latest policy."
DC: "Here is the policy for PC-001$."

3. Broker user authentication
PC-001: "Please authenticate Tanaka."
DC: "The request comes from the trusted PC-001$, so I'll process it."

4. Change its own password
PC-001: "30 days have passed, so I'm changing my password."
DC: "OK, the new password has been set."

3.1.3 Why Administrator Privileges Are Required

Joining a domain always requires administrator privileges. This is an important security mechanism.

[Why are admin privileges required?]
Employee: "It's my PC, so I want to join it to the domain myself."
IT admin: "I'm afraid you can't."
Employee: "Why not?"

(A real-world analogy)
Employee: "It's my desk, so I want to put it in the CEO's office."
General affairs: "That requires approval from general affairs."
Employee: "Ah, I see..."

Let's see what happens without the privilege.

[Attempting a domain join as a regular user]
Tanaka (regular user): "Let me join this PC to the domain."

System Properties -> Change domain
Domain: enter jp.qualiteg.com
Click [OK]

Error message:
"You do not have permission to join the domain.
 Contact your domain administrator."

Tanaka: "No luck after all..."

Let's look at joining with administrator privileges.

[Join performed by an administrator]
IT admin: "Alright, I'll join it."

Authentication dialog:
"Credentials for joining the jp.qualiteg.com domain"
Username: Administrator
Password: ************

↓

"Welcome to the jp.qualiteg.com domain"

IT admin: "Join complete. Please restart the machine."

So why is this mechanism necessary? Let's look at the following example.

[The security perspective]
Security officer: "What if anyone could join machines to the domain?"

Nightmare scenario:
Attacker: "I'll join my own PC to the domain without permission."
Malicious PC: "I am a legitimate domain member."
Malicious PC: "Collecting internal information..."

Reality:
Attacker: "I want to join the domain."
System: "Administrator credentials?"
Attacker: "...I don't have any."
System: "Denied."

Security officer: "That's why administrator privileges are required."

Let's also look at the types of privileges and when to use them.

[Privileges that can join machines to a domain]
Newcomer: "Can only Administrator perform the join?"
IT admin: "No, there are several options."

1. Domain Admins
- The highest privileges
- Can do anything
- Normally not used (too powerful)

2. Administrator
- The default administrator
- Can join machines to the domain

3. Account Operators
- Specialized in account management
- Can join machines to the domain
- Can also create users

4. Delegated permissions
- Can join machines only into a specific OU (organizational unit)
- The principle of least privilege

IT admin: "In practice, we usually create a dedicated account."

Let's go one step further and look at a practical operational technique.

[A dedicated domain-join account]
IT director: "I don't want to give the Administrator password to help desk staff."
IT admin: "Let's create a dedicated account."

Account to create:
- Name: join_domain
- Group membership: Account Operators
- Purpose: domain joins only

Operational rules:
1. The help desk uses this account for domain joins
2. No other administrative work is possible
3. The password is changed periodically
4. Usage history is audited

IT director: "Now I can rest easy."

3.2 Domain Join Procedures

In this section, we walk through the actual procedures for joining a domain.

3.2.1 Joining a Windows PC to the Domain

First, let's walk through joining a Windows 10/11 PC to the domain, following the actual on-screen steps.

[The day a new PC arrives]
General affairs: "The PC for the new employee has arrived."
IT admin: "Alright, let's join it to the domain."

Pre-join checklist:
☑ The PC is connected to the network
☑ It has obtained an IP address (DHCP or static)
☑ The DNS server points to the DC
☑ Domain administrator ID/password are at hand
☑ A computer name has been decided

Let's look at the basic join procedure (GUI).

[Step 1: Open System Properties]
IT admin: "First, open System Properties."

Method 1:
- Windows key + Pause/Break

Method 2:
- Start -> Settings -> System -> About -> "Rename this PC"

Method 3:
- In File Explorer, right-click "This PC" -> Properties

Let's look at renaming the computer and joining at the same time.

[Step 2: Join the domain]
Current state:
Computer name: DESKTOP-ABC123 (a random name)
Workgroup: WORKGROUP

IT admin: "First, let's change it to a meaningful name."

Click the [Change] button

Computer name: PC-101 (new name)
Member of:
○ Workgroup
● Domain: [jp.qualiteg.com]

Click [OK]

Let's look at how to handle the authentication dialog.

[Step 3: Enter credentials]
Dialog: "Enter credentials to join the domain"

(An easy mistake to make)
Junior IT: "Username... Administrator should be fine, right?"
Error: "Logon failure"
Senior: "Include the domain name as well."

Correct input formats:
1. JP\Administrator
2. Administrator@jp.qualiteg.com

Password: ************

Click [OK]

Let's understand what happens on success.

[Join succeeded]
Message: "Welcome to the jp.qualiteg.com domain"

What happens behind the scenes:
1. PC -> DC: "I would like to join as PC-101."
2. DC: "Administrator authentication OK. Creating the PC-101$ account."
3. DC -> PC: "Join approved. Here is your password (120 characters)."
4. PC: "Password stored securely."

IT admin: "Now let's restart."

Let's also look at joining via PowerShell.

[For advanced users: PowerShell]
IT admin: "PowerShell is handy when joining a large number of PCs."

# Launch PowerShell with administrator privileges
# Basic command
Add-Computer -DomainName "jp.qualiteg.com" -Credential JP\Administrator

# Example with options
Add-Computer -DomainName "jp.qualiteg.com" `
             -NewName "PC-101" `
             -Credential (Get-Credential) `
             -OUPath "OU=Computers,OU=Tokyo,DC=jp,DC=qualiteg,DC=com" `
             -Restart

Newcomer: "What is OUPath?"
IT admin: "It lets you place the machine into a specific OU (organizational unit) at join time."

3.2.2 Joining a Windows Server to the Domain

The procedure for joining a Windows Server to the domain is basically the same as for a client PC, but there are server-specific considerations.

[File server build day]
IT director: "Build the new file server."
IT admin: "First, I'll join it to the domain."

Server-specific checks:
- Static IP address configured?
- Does the hostname follow the naming convention?
- Before or after installing roles/features?

Now let's look at the join procedure on a server.

[Joining from Server Manager]
1. Open Server Manager
2. Click "Local Server"
3. Click "WORKGROUP" next to the computer name

Before:
Computer name: WIN-RANDOMSTRING
Workgroup: WORKGROUP

After:
Computer name: FS-01 (file server 01)
Domain: jp.qualiteg.com

Next, let's understand the difference between a member server and a DC.

[Differences by role]
Newcomer: "Will this server become a DC as well?"
IT admin: "No, it will be a member server."

Types of servers:
1. Domain controller (DC)
   - Has the AD DS role installed
   - Is "promoted" for the domain
   - The side that provides authentication

2. Member server
   - "Joins" the domain
   - The side that consumes authentication
   - Provides services such as file, web, and DB

Newcomer: "Same domain, but different roles."

The timing of the domain join also matters. Let's look at when to join.

[When should you join the domain?]
Newcomer: "Is it okay to join after installing SQL Server?"
Senior: "Hold on!"

Recommended order:
1. Install the OS
2. Configure the network (static IP)
3. Join the domain  <- here!
4. Install roles/features
5. Install applications

Reasons:
- Many applications assume a domain environment during setup
- Service accounts are often domain accounts
- Joining later means reconfiguration

3.2.3 Joining a Linux Server to the Domain

In fact, Linux servers can also join a Windows AD domain.

This lets you leverage AD's authentication infrastructure on Linux as well.

[Linux servers in the domain too?]
Developer: "I want to use Linux — does that mean managing authentication separately?"
IT admin: "No, Linux can join AD as well."
Developer: "Really? Even though it's Microsoft technology?"
IT admin: "We use software called Samba."

Let's install the required packages (Ubuntu/Debian).

[Preparation]
# Update packages
sudo apt update
sudo apt upgrade

# Install the required packages
sudo apt install samba winbind libnss-winbind libpam-winbind krb5-user

Questions asked during installation:
"Default Kerberos version 5 realm:"
-> JP.QUALITEG.COM (enter in uppercase)

"Kerberos servers for JP.QUALITEG.COM:"
-> dc01.jp.qualiteg.com dc02.jp.qualiteg.com

"Administrative server for JP.QUALITEG.COM:"
-> dc01.jp.qualiteg.com

Next, configure Kerberos.

[Editing /etc/krb5.conf]
IT admin: "Let's configure Kerberos."

[libdefaults]
    default_realm = JP.QUALITEG.COM
    dns_lookup_realm = false
    dns_lookup_kdc = true

[realms]
    JP.QUALITEG.COM = {
        kdc = dc01.jp.qualiteg.com
        kdc = dc02.jp.qualiteg.com
        admin_server = dc01.jp.qualiteg.com
    }

[domain_realm]
    .jp.qualiteg.com = JP.QUALITEG.COM
    jp.qualiteg.com = JP.QUALITEG.COM

Test:
kinit administrator@JP.QUALITEG.COM
(enter the password)
klist (check the tickets)

Configure Samba and join the domain.

[Configuring /etc/samba/smb.conf]
[global]
    workgroup = JP
    security = ADS
    realm = JP.QUALITEG.COM
    
    # Winbind settings
    winbind enum users = yes
    winbind enum groups = yes
    winbind use default domain = yes
    winbind refresh tickets = yes
    
    # UID/GID mapping
    idmap config * : backend = tdb
    idmap config * : range = 10000-19999
    idmap config JP : backend = rid
    idmap config JP : range = 20000-29999

Run the actual join command.

[Executing the domain join]
# DNS test
host -t SRV _ldap._tcp.jp.qualiteg.com

# Join the domain
sudo net ads join -U Administrator
Enter Administrator's password: ********

Message on success:
Using short domain name -- JP
Joined 'LINUX-FS-01' to dns domain 'jp.qualiteg.com'

# Verify
sudo net ads testjoin
Join is OK

# Start the Winbind service
sudo systemctl enable winbind
sudo systemctl start winbind

# Check that it works
wbinfo -u (list domain users)
wbinfo -g (list domain groups)

Configure NSS/PAM.

[Configuring integrated authentication]
# Edit /etc/nsswitch.conf
passwd: compat winbind
group:  compat winbind

# Automatic PAM configuration
sudo pam-auth-update
[*] Winbind NT/Active Directory authentication

# Test
id JP\\tanaka_t
uid=20001(tanaka_t) gid=20000(domain users) groups=20000(domain users)

Developer: "Nice — the AD user is recognized!"

3.2.4 Troubleshooting

Various errors can occur when joining a domain.
Let's look at common problems and their solutions.

[Error 1: Domain not found]
Error message:
"Could not connect to the domain jp.qualiteg.com.
 The domain either does not exist or could not be contacted."

Newcomer: "But the domain name is correct..."
Senior: "Let's check the DNS settings."

Check the DNS-related settings.

[DNS verification steps]
1. Check the IP configuration
ipconfig /all

What to look for:
DNS server: 192.168.1.1  <- It's pointing at the router!

Senior: "That's the cause. It has to point to the DC."

Correct setting:
DNS server: 192.168.1.10 (DC01's IP)

2. Test name resolution
nslookup jp.qualiteg.com
nslookup -type=SRV _ldap._tcp.jp.qualiteg.com

On success:
Server:  dc01.jp.qualiteg.com
Address: 192.168.1.10

_ldap._tcp.jp.qualiteg.com    SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = dc01.jp.qualiteg.com

Check the network connectivity.

[Error 2: Network path not found]
Verification steps:
1. Ping the DC
ping dc01.jp.qualiteg.com

On failure:
"Could not find host dc01.jp.qualiteg.com"
-> DNS problem

"Request timed out"
-> Firewall or network problem

2. Check the ports
Test-NetConnection -ComputerName dc01.jp.qualiteg.com -Port 389
Test-NetConnection -ComputerName dc01.jp.qualiteg.com -Port 445

Required ports:
- 389 (LDAP)
- 445 (SMB)
- 88 (Kerberos)
- 135 (RPC)

Handle authentication errors.

[Error 3: Authentication failed]
Symptom:
"Could not log on to the specified domain.
 The user name or password is incorrect."

Checklist:
1. Username format
   × administrator (confused with the local account)
   ○ JP\administrator
   ○ administrator@jp.qualiteg.com

2. Password checks
   - Case sensitivity
   - NumLock state
   - Keyboard layout (US/JP)

3. Account state
   - Not locked out?
   - Not expired?
   - Has sufficient privileges?

Check for time synchronization problems.

[Error 4: Kerberos-related errors]
Symptom:
"The computer account could not be found,
 or access was denied"

The most common cause: clock skew

How to check:
# On the client
w32tm /query /status

# Check the time offset
w32tm /stripchart /computer:dc01.jp.qualiteg.com

If the skew exceeds 5 minutes:
# Synchronize immediately
w32tm /resync /computer:dc01.jp.qualiteg.com

# Configure the NTP server
w32tm /config /manualpeerlist:"dc01.jp.qualiteg.com" /syncfromflags:manual

Resolve problems with an existing computer account.

[Error 5: The account already exists]
Symptom:
"The computer account JP\PC-101 already exists"

Causes:
- A previously joined PC was reinstalled
- Another PC with the same name exists

Solutions:
1. Check in the AD management tool
   "Active Directory Users and Computers"
   -> Computers -> look for PC-101$

2. Delete the old account (administrator task)
   Right-click -> Delete

3. Or join under a different name
   PC-101 -> PC-101B

IT admin: "Periodically clean up accounts that are no longer in use."

Verify the join afterward.

[Confirming the join succeeded]
1. System Properties
   Full computer name: PC-101.jp.qualiteg.com
   Domain: jp.qualiteg.com

2. Command-line check
   systeminfo | findstr /B "Domain"
   Domain: jp.qualiteg.com

3. Logon screen
   "JP" appears as a sign-in destination

4. Event log
   Event Viewer -> System
   Source: NetJoin
   Event ID: 4096
   "This computer has successfully joined the domain"

Newcomer: "Now we know for sure the join succeeded."
IT admin: "Yes. Next comes a login test with a domain user."

3.3 What Happens After the Domain Join

3.3.1 Establishing the Trust Relationship

Once the domain join completes, a "trust relationship" is established between the computer and the domain.

It is a special relationship in which the two sides trust each other.

[What is a trust relationship?]
Newcomer: "What exactly is a trust relationship?"
IT admin: "Let's use a bank account as an analogy."

The bank account analogy:
1. Opening an account (joining the domain)
   - Identity verification (administrator authentication)
   - Account number issued (computer account created)
   - PIN set (computer password)

2. Using an ATM (logging in)
   - Insert the card (computer authentication)
   - Enter the PIN (user authentication)
   - Transactions allowed (access granted)

IT admin: "It's the same as the trust between you and your bank."

Let's understand the technical mechanism behind the trust relationship.

[The shared secret]
IT admin: "The PC and the DC hold a 'shared secret'."

What happens at join time:
1. DC: "I've generated a password for you."
   Password: Xk9#mP2$...(120 characters)

2. PC: "Received. I'll store it securely."
   Storage location: LSA (Local Security Authority) secrets

3. Subsequent communication:
   PC: "I am PC-101$. Let me prove it."
   PC: (sends data signed with the shared secret)
   DC: "Verifying the signature... yes, you are indeed PC-101$."

Newcomer: "So they authenticate with a secret only the two of them know."

Now let's see how to actually check the trust relationship.

[Testing the trust relationship]
Run at a command prompt (with administrator privileges):
nltest /sc_query:jp.qualiteg.com

When healthy:
Flags: 30 HAS_IP  HAS_TIMESERV
Trusted DC Name \\DC01.jp.qualiteg.com
Trusted DC Connection Status Status = 0 0x0 NERR_Success
Trust Verification Status = 0 0x0 NERR_Success
The command completed successfully

When there is a problem:
Trust Verification Status = 1717 0x6b5 RPC_S_UNKNOWN_IF
-> The trust relationship is broken

Conversely, let's understand what breaks the trust relationship.

[A broken trust relationship]
User: "It worked yesterday, but now I can't log in!"
Error: "The trust relationship between this workstation
        and the primary domain failed"

Common causes:
1. The PC was powered off for a long time
   PC: "Booting for the first time in 3 months"
   DC: "Your password is too old. I can't trust you."

2. Recovery from a system restore or backup
   PC: "I've been restored to my state from a month ago."
   DC: "Your password has rolled back! Impostor!"

3. Re-joining under the same name
   Other PC: "I am PC-101$."
   DC: "A new PC-101$? Updating the password."
   Original PC: "I am PC-101$."
   DC: "Wrong password! Impostor!"

Now let's look at how to repair the trust relationship.

[Repair methods]
Method 1: Re-join (reliable but tedious)
1. Move back to a workgroup
2. Restart
3. Re-join the domain
4. Restart

Method 2: Repair with PowerShell (efficient)
# Run with administrator privileges
Test-ComputerSecureChannel -Repair -Credential JP\Administrator

On success:
True

# A more thorough repair
Reset-ComputerMachinePassword -Server DC01 -Credential JP\Administrator

3.3.2 Computer Account Password Management

Computer account passwords are not managed by humans — they are managed automatically.

[Automatic password changes]
Newcomer: "Who changes the PC's password?"
IT admin: "The PC changes it by itself, automatically."

Default behavior:
- Change interval: 30 days
- Password length: 120 characters
- Change time: randomized (to spread the load)

Let's follow the password change flow.

[2 a.m., 30 days later]
PC-101: "Time to change my password."
PC-101: "Generating a new password... Yt7&nB9#... (120 characters)"
PC-101 -> DC: "I'd like to change my password."
DC: "Authenticate with your current password first."
PC-101: "My current password is Xk9#mP2$..."
DC: "Confirmed. And the new password?"
PC-101: "It's Yt7&nB9#..."
DC: "Changed."
PC-101: "Storing the new password... done."

Check the password change settings.

[Checking in the registry]
Location: HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

Key values:
- DisablePasswordChange: 0 (changes enabled) / 1 (changes disabled)
- MaximumPasswordAge: 30 (days)
- RefusePasswordChange: 0 (the DC accepts changes)

Command to check:
reg query HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

Let's look at when to disable password changes.

[Configuration for special environments]
Virtualization engineer: "Template VMs must not have their passwords changed."
IT admin: "In that case, it can be disabled."

Configuring via Group Policy:
Computer Configuration
└ Policies
  └ Windows Settings
    └ Security Settings
      └ Local Policies
        └ Security Options
          └ Domain member: Disable machine account
            password changes: Enabled

Caution:
IT admin: "This carries security risk, so it is generally not recommended."

Let's understand how the old password is retained.

[Password history]
IT admin: "Actually, the previous password is remembered as well."

Why:
- To avoid inconsistencies caused by network delays
- To guarantee authentication during replication

Behavior:
PC: "Authenticating with my new password."
DC2: "I only know the old password so far..."
PC: "Then here is the old password."
DC2: "OK, authentication succeeded."

(Replication then brings everything in sync)

3.3.3 Group Policy Application

One of the biggest benefits after joining a domain is centralized management through Group Policy.

[What is Group Policy?]
CEO: "I want to ban USB flash drives on every employee's PC."
IT admin: "With Group Policy, that's a single change."

Without Group Policy:
- Configure 500 PCs one by one
- New employees' PCs configured individually as well
- Risk of missed machines

With Group Policy:
- Configure in one place
- Applied automatically to all PCs
- Newly joined PCs pick it up automatically

Let's understand when policies are applied.

[When is it applied?]
1. At computer startup (computer policies)
PC boots: "Good morning."
PC -> DC: "Please give me the latest computer policy."
DC: "Here is the latest version."
PC: "Applied."

2. At user logon (user policies)
Tanaka logs on: "Logging in."
PC -> DC: "Please give me Tanaka's policy."
DC: "Tanaka is in Sales, so here it is."
PC: "Applied."

3. Periodic refresh (90 minutes ± 30 minutes)
PC: "Time for the periodic refresh."
PC -> DC: "Any policy updates?"
DC: "Updated from Version 15 to Version 16."
PC: "Applying the differences."

4. Manual refresh
Admin: "I want it applied right now."
gpupdate /force

Let's understand policy precedence.

[The LSDOU order]
Newcomer: "What if multiple policies exist?"
IT admin: "They are applied in LSDOU order."

L - Local
S - Site
D - Domain
OU - Organizational Unit

Example:
1. Local policy: "wallpaper is blue"
2. Domain policy: "wallpaper is green"
3. Sales OU: "wallpaper is red"

Result: red (the OU applied last wins)

Let's look at real policy examples.

[Frequently used policies]
IT admin: "Let's look at real configuration examples."

1. Password policy
Location: Computer Configuration -> Windows Settings ->
      Security Settings -> Account Policies
Settings:
- Minimum password length: 8 characters
- Complexity requirements: enabled
- History: 24 passwords remembered

2. Screen saver
Location: User Configuration -> Administrative Templates ->
      Control Panel -> Personalization
Settings:
- Enable screen saver
- Timeout: 600 seconds (10 minutes)
- Password protect the screen saver

3. Windows Update
Location: Computer Configuration -> Administrative Templates ->
      Windows Components -> Windows Update
Settings:
- Configure Automatic Updates: 4 - Auto download and schedule the install
- Scheduled install day: 0 - Every day
- Scheduled install time: 03:00

Let's see how to verify that policies are applied.

[Checking application status]
# Check which policies are applied
gpresult /r

COMPUTER SETTINGS
Applied Group Policy Objects:
    Default Domain Policy
    Sales Department Computer Policy

USER SETTINGS
Applied Group Policy Objects:
    Default Domain Policy
    Sales Department User Policy

# A more detailed report (HTML format)
gpresult /h c:\temp\gpreport.html

Troubleshoot policy problems.

[When a policy is not applied]
User: "Other people's PCs changed, but mine didn't."

Steps to check:
1. Manual refresh
   gpupdate /force

2. Check the event log
   Event Viewer -> Applications and Services Logs ->
   Microsoft -> Windows -> GroupPolicy

3. Check communication with the DC
   nltest /dsgetdc:jp.qualiteg.com

4. Check policy inheritance
   - Position within the OU structure
   - Blocked inheritance settings
   - WMI filters

Common causes:
- The policy link is set to disabled
- Excluded by a WMI filter
- Inheritance is blocked
- Replication has not completed yet

Through these mechanisms, domain-joined computers come to be managed automatically according to your organization's policies.

That wraps up an in-depth Part 3, covering Active Directory domain joins in a way that even beginners can follow. Below are the summary and a preview of the next installment.

Summary of This Installment

In Part 3, we took a detailed look at the "domain join" — the very heart of Active Directory.

Joining a domain is not simply "connecting to the network" — it is a critical process that establishes a trust relationship between a computer and the domain controller. We learned that not only user accounts but computers themselves are managed as accounts, and that authentication happens automatically using complex passwords as long as 120 characters.

Beyond Windows PCs and servers, Linux servers can also join an AD domain using Samba, enabling a unified authentication infrastructure even in heterogeneous environments. And once machines are joined, Group Policy allows organization-wide security policies to be applied in one stroke — improving both administrative efficiency and security at the same time.

In the troubleshooting section, we covered the problems you will encounter in real operations and how to resolve them: the importance of DNS configuration, the need for time synchronization, and maintaining the trust relationship. With this knowledge, you should be well equipped to handle most domain join issues.

Coming Next: Chapter 4 — Proxy Servers and Integrated Windows Authentication

In the next installment, we finally tackle proxy servers and Integrated Windows Authentication — a cornerstone of enterprise networks!

Many companies deploy proxy servers for security and access control. But you may well have struggled with problems like "I'm asked for a password every time I go through the proxy" or "a particular application can't authenticate."

In Part 4, we cover practical ground in an approachable way: from building a proxy server with Squid or IIS to implementing Integrated Windows Authentication (IWA) in coordination with Active Directory. By understanding how Kerberos and NTLM authentication behave in a proxy environment — and why single sign-on is possible at all — you will be able to build enterprise networks that are both safer and easier to use.

Proxy authentication is an unavoidable element when integrating with AI security tools and cloud services in particular. In the next installment as well, we will use concrete configuration examples and plenty of diagrams to make these complex authentication mechanisms easy to understand.

See you in Part 4!