Hello!

Starting with this article, we will be walking through Active Directory over the next several installments.

Active Directory (AD) is a directory service developed by Microsoft. It is no exaggeration to call it the de facto standard in the IT infrastructure of today's large enterprises, and it is widely adopted as the foundation for centrally managing an organization's users, computers, and other resources.

The Reality of AI Security: It Does Not Work Alone

As generative AI such as ChatGPT and Claude spreads rapidly through companies, the term "AI security" is drawing attention. Preventing information leaks, detecting inappropriate use, ensuring compliance—the list of challenges companies must tackle is long.

But there is a fact we need to be careful about here:

an AI security solution, on its own, can deliver only limited effect in an enterprise environment

.

The Essential Challenge Companies Face

When an AI security tool is introduced, corporate IT departments invariably ask questions like these:

• "How do we identify who used this AI?"
• "Can we apply different security policies per department?"
• "Can it integrate with our existing audit log system?"
• "Can we avoid burdening users with extra authentication steps?"

Meeting these demands requires deep integration with the company's existing IT infrastructure.

The Corporate Environment This Article Assumes

In this article, we assume

a typical enterprise environment in which the standard business PCs run Windows and are, moreover, domain-controlled

, and answer these questions on that basis.

In many large companies, the PCs employees use for work are Windows-based, and their security requirements (policies) are centrally managed.

In this kind of environment, an AI security solution cannot avoid integrating with Active Directory (AD), which sits at the core of authentication and authorization.

Why Proxy Authentication Is the Bridge

Many AI security solutions, including classic DLP solutions, operate as a proxy server, mediating the traffic between users and AI services. Integration with the existing infrastructure is then achieved through the following flow:

1. Transparent authentication
   Integrated Windows Authentication authenticates users without their even noticing
   
2. User identification
   Information obtained from AD clearly records the "who"
   
3. Policy enforcement
   Applies the appropriate security rules based on AD group information
   
4. Audit trail
   Generates detailed logs that satisfy corporate compliance requirements

The Blend of Knowledge Required of Engineers

AI security engineers need not only knowledge of AI technology but also a deep understanding of the following foundational technologies:

• Active Directory: how enterprise authentication works; the Kerberos/NTLM authentication protocols
• Proxy technology: HTTP authentication; Windows authentication APIs such as SSPI
• Networking: routing and name resolution in domain environments
• Security: handling authentication tokens; designing audit logs

The Goal of This Series

In this series, we systematically cover practical knowledge of the foundational technologies behind enterprise AI security. Rather than pure theory, we present the challenges you actually face in corporate environments and show concretely how to solve them.

Even in the new field of AI security, the principle that everything ultimately rests on solid foundational technology remains unchanged. We hope this series deepens your understanding of how to integrate AI security with your existing IT infrastructure. Throughout the series, we have worked role-play dialogues into the material so that even beginners can understand Active Directory and have fun learning it—we hope you will stay with us to the end!

Series Outline

[★You are here★] Chapter 1: Understanding the Basic Concepts - The basics of Active Directory and Kerberos/NTLM authentication

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

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 cases with AI security tools

Chapter 1: Understanding the Basic Concepts

1.1 What Is Active Directory (AD)?

1.1.1 The Role and Functions of AD

Active Directory (AD) is an integrated management system for Windows environments, developed by Microsoft. It is widely used in companies and organizations as the mechanism for centrally managing computers, users, and other resources.

The easiest way to understand AD is to compare it to how a company manages its organization. First, imagine a world without AD.

[A morning at a company without AD]
Tanaka: "Good morning. I'd like to log in to the accounting system..."
IT staff: "Ah, Mr. Tanaka. Let's see, your password for the accounting system is... (flips through papers)"
Tanaka: "I also need to access the file server."
IT staff: "The file server uses a different password. Let me write it down for you..."
Tanaka: "And I need email too."
IT staff: "That's yet another one... (sweats)"

In a situation like this, every system needs its own ID and password, and management becomes a tangle. AD was born to solve this problem.

[A morning at a company with AD]
Tanaka: "Good morning." (logs in to the PC)
PC: "AD, Taro Tanaka is trying to log in."
AD: "Confirmed. Taro Tanaka is a full-time employee in Accounting. Authentication OK."
PC: "Thank you. Mr. Tanaka, you're all set."
Tanaka: (uses the accounting system, the file server, and email—all without any additional logins)

AD's primary roles are authentication and authorization. Authentication answers the question "who are you?"; authorization answers the question "what are you allowed to do?"

[Authentication vs. authorization]
Tanaka: "I want to open the Accounting department's shared folder."
AD (authentication): "Checking your password... yes, you really are Taro Tanaka."
AD (authorization): "Taro Tanaka belongs to Accounting... access to the Accounting folder is OK."

Yamada: "I want to open the Accounting department's shared folder."  
AD (authentication): "Checking your password... yes, you really are Jiro Yamada."
AD (authorization): "Jiro Yamada belongs to Sales... I'm sorry, but you do not have permission to access the Accounting folder."

AD provides a wide range of functions. One of the most important is single sign-on (SSO): once you have logged in, you never need to re-enter a password when accessing the various resources on the network.

Group Policy is another: it lets administrators apply uniform settings to every computer in the organization.

[The power of Group Policy]
IT admin: "I want every employee PC to lock automatically after 10 minutes of inactivity."

(Without AD)
IT admin: "PC number 1... done. Number 2... done. Number 3... (there are 500 of these...)"

(With AD)
IT admin: "Set it in AD Group Policy... and done."
AD: "Understood. Distributing the setting to all 500 PCs."

1.1.2 What AD Manages (Users, Computers, Groups)

AD manages the various elements of an organization as "objects." Think of it as recreating the real-world company organization in the digital world.

First, let's look at user objects.

[A new employee's first day]
HR: "Effective April 1, Hanako Yamada joins the Accounting department."
IT admin: "Got it. I'll create a user in AD."

The IT admin's work:
- Login name: yamada_h
- Full name: Hanako Yamada
- Department: Accounting
- Email: yamada_h@jp.qualiteg.com
- Initial password: (set)

Yamada: "It's my first day. Which PC should I use?"
IT admin: "Any PC is fine. Just log in as yamada_h."
Yamada: "What, any PC?"
IT admin: "Yes. AD manages your information, so you can log in from any PC in the company."

Next, computer objects—something many people misunderstand. AD manages not just people, but the computers themselves.

[The day a new PC arrives]
IT staff: "A new PC arrived. We need to join it to AD..."
Newbie: "The PC has to join too? It's not a person!"
IT staff: "That's right. Think of it this way."

(If the PC has not joined AD)
Yamada: "I want to log in to this PC."
PC: "Who are you? I don't know any 'AD'."
Yamada: "I'm yamada_h from AD."
PC: "AD? What's that? I don't let in people I don't know."

(If the PC has joined AD)
Yamada: "I want to log in to this PC."
PC: "One moment, let me check with AD."
PC→AD: "Someone called yamada_h is trying to log in."
AD→PC: "Confirmed. That's Hanako Yamada from Accounting. Login OK."
PC: "Please go ahead."

Group objects are the mechanism for managing users and computers collectively.

[The efficiency of group management]
CEO: "Please create a shared folder everyone in Accounting can use."

(Without groups)
IT admin: "Grant access to Tanaka... grant access to Yamada... grant access to Suzuki..."
The next day
HR: "A new hire, Sato, has joined Accounting."
IT admin: "Individual settings all over again..."

(With groups)
IT admin: "Grant access to the 'Accounting' group... done."
The next day
HR: "A new hire, Sato, has joined Accounting."
IT admin: "Add Sato to the 'Accounting' group... and done. He automatically gets access to the shared folder."

These objects are managed in a hierarchy and organized into containers called organizational units (OUs).

1.1.3 The Concept of the Domain Controller (DC)

The domain controller (DC) is the server at the heart of Active Directory. The easiest way to understand a DC is to compare it to a company's reception desk or security guard.

[The DC as a reception desk]
(Morning arrival time)
Tanaka: "Good morning." (taps his employee badge)
DC (reception): "Checking your badge... Taro Tanaka, Accounting. Please come in."

Yamada: "Good morning." (taps his employee badge)
DC (reception): "Checking your badge... Jiro Yamada, Sales. Please come in."

Stranger: "Let me in."
DC (reception): "Please show your employee badge."
Stranger: "I don't have one."
DC (reception): "I'm sorry, but you may not enter."

A real DC performs this kind of authentication hundreds of times per second. And it remembers the information for every employee (user) and every company PC (computer).

[The DC's database]
DC: "My database contains the following:"
- Taro Tanaka: Accounting, ext. 1234, email tanaka@jp.qualiteg.com
- Jiro Yamada: Sales, ext. 5678, email yamada@jp.qualiteg.com  
- PC-001: PC on the Accounting floor, usually used by Tanaka
- PC-002: PC on the Sales floor, usually used by Yamada
... (and so on, for every employee and every PC)

Depending on the size of the organization, anywhere from one to dozens of DCs are deployed.

[Small office (50 employees)]
CEO: "We're a small company—one receptionist is enough, right?"
IT admin: "Yes, and one DC is enough too."

[Large office (5,000 employees)]  
CEO: "With this many employees, one receptionist can't keep up."
IT admin: "Exactly. We'll deploy multiple DCs and spread the load."
IT admin: "Let's place two DCs at Tokyo HQ and two at the Osaka branch."

(Actual behavior)
Tanaka in Tokyo: "Logging in."
Tokyo DC1: "I'll handle it. Authentication OK."

Suzuki in Osaka: "Logging in."
Osaka DC1: "I'll handle it. Authentication OK."

Tokyo DC1: "Getting a bit busy here..."
Sato in Tokyo: "Logging in."
Tokyo DC2: "DC1 looks busy, so I'll take this one. Authentication OK."

What matters is that all DCs share the same information. This is called replication.

[DC replication]
Tokyo DC1: "I registered a new user, 'New Hire A'."
Tokyo DC1→all DCs: "Everyone, please copy this information."
Tokyo DC2: "Copied."
Osaka DC1: "Copied."
Osaka DC2: "Copied."

Result: whichever DC you ask, you can get New Hire A's information

In this way, domain controllers manage every authentication in the organization 24 hours a day, 365 days a year—true guardian deities of the organization.

1.2 The Relationship Between DNS and AD

1.2.1 Why AD Requires DNS

The relationship between Active Directory and DNS (Domain Name System) is a point that confuses many beginners. Why does using AD require DNS? To understand, let's start with an everyday example.

[Making a phone call]
Taro: "I'd like to call Hanako."
Taro: "But I don't know her number..."
Taro: "Let me check the phone book. Hanako is... 090-1234-5678."
Taro: "Hello, Hanako?"

[If there were no phone book]
Taro: "I want to call Hanako, but I don't know her number."
Taro: "What now... I can't call her."

DNS plays the role of the "phone book" in computer networks. It converts names that are easy for humans to remember (Hanako) into numbers computers can understand (phone numbers).

Now let's look at the relationship between AD and DNS.

[When a PC tries to log in to the domain]
User: "I want to log in to the jp.qualiteg.com domain."
PC: "Where is the domain controller for jp.qualiteg.com?"
PC: "Let me ask DNS."
PC→DNS: "Where is the domain controller for jp.qualiteg.com?"
DNS: "It's at 192.168.1.10."
PC: "Thanks!"
PC→DC (192.168.1.10): "Please log me in."

What would happen without DNS?

[Without DNS]
User: "I want to log in to the jp.qualiteg.com domain."  
PC: "jp.qualiteg.com? Where's that? What's the IP address?"
User: "No idea..."
PC: "I can't connect without an IP address."

User: "Fine, I'll memorize the domain controller's IP address. 192.168.1.10."
PC: "That works."

The next day
IT admin: "We changed the DC's IP address. The new IP is 192.168.1.20."
User: "What! I have to memorize it all over again?"

Without DNS, every user would have to memorize the domain controller's IP address, and chaos would break out every time it changed.

More importantly, AD demands more from DNS than simple name resolution.

[AD's advanced demands]
PC: "I want to log in—which DC is closest?"
DNS: "You're in the Tokyo office. Use Tokyo DC1 (192.168.1.10) or Tokyo DC2 (192.168.1.11)."

Another PC: "I want to log in from the Osaka office."
DNS: "Then Osaka DC1 (192.168.2.10) or Osaka DC2 (192.168.2.11) is closer."

1.2.2 What Is AD-Integrated DNS?

AD-integrated DNS is a mechanism that couples Active Directory and DNS tightly together. Picture the reception desk (DC) and the information desk (DNS) sharing the same records.

[Managed separately]
Reception (DC): "A new employee, Tanaka, has joined."
Information desk (DNS): "Never heard of him. He's not in my directory."

Visitor: "Where can I find Mr. Tanaka?"
Information desk (DNS): "I don't know that person."
Reception (DC): "No, he does work here..."

[With AD-integrated DNS]
Reception (DC): "A new employee, Tanaka, has joined."
AD-integrated DNS: "Automatically added him to the directory. Accounting, third floor."

Visitor: "Where can I find Mr. Tanaka?"
AD-integrated DNS: "Accounting, on the third floor."

The biggest advantage of AD-integrated DNS is automatic synchronization of information.

[When a new PC is added]
IT admin: "Let's join the new PC 'PC-101' to the domain."
AD: "PC-101 registered."
AD-integrated DNS: "The DNS record for PC-101 was created automatically as well."

(With ordinary DNS)
IT admin: "Let's join the new PC 'PC-101' to the domain."
AD: "PC-101 registered."
IT admin: "Now I have to register it in DNS manually too..."
DNS: "PC-101 registered."
IT admin: "Everything twice..."

AD-integrated DNS also synchronizes information automatically across multiple domain controllers.

[Replication in action]
Tokyo DC: "Registered the new server 'FILE-SERVER-01'."
DNS inside the Tokyo DC: "DNS record created too."

(Automatic replication)
Osaka DC: "An update arrived from Tokyo. Registering FILE-SERVER-01."
DNS inside the Osaka DC: "Creating the DNS record here as well."

Result: FILE-SERVER-01 can be resolved by name from any office

1.2.3 The Role of SRV Records

SRV records (service records) are a key element in the coupling of AD and DNS. They are special DNS records that indicate "which service is provided where."

Let's compare ordinary DNS resolution with resolution using SRV records.

[Ordinary DNS resolution]
User: "What's the IP address of www.example.com?"
DNS: "203.0.113.1."
User: "Then I'll go there."

[Resolution using SRV records]
PC: "Where is the domain controller for jp.qualiteg.com?"
DNS: "Hold on—what kind of service do you need?"
PC: "LDAP (the authentication service)."
DNS: "The LDAP service is provided at:
      - DC01.jp.qualiteg.com (priority: 0, weight: 50)
      - DC02.jp.qualiteg.com (priority: 0, weight: 50)"
PC: "Same priority, weights 50:50... I'll pick one and balance the load."

Here is a concrete example of why SRV records are necessary.

[A large company's office]
IT admin: "Our company runs all sorts of services."
- Authentication service (LDAP): DC01, DC02
- Global catalog: DC01
- Kerberos service: DC01, DC02
- PDC emulator: DC01 only

New employee: "I'd like to log in."
PC→DNS: "Please give me the SRV record for _ldap._tcp.jp.qualiteg.com."
DNS: "Either DC01 or DC02 is fine."

Admin tool: "I need to talk to the PDC emulator."
Tool→DNS: "Please give me the SRV record for _ldap._tcp.pdc._msdcs.jp.qualiteg.com."
DNS: "That one is DC01 only."

An actual SRV record contains information like the following.

[Inside an SRV record]
_ldap._tcp.jp.qualiteg.com. 600 IN SRV 0 100 389 dc01.jp.qualiteg.com.

Explanation:
- _ldap._tcp: the LDAP service (over TCP)
- jp.qualiteg.com: the domain name
- 600: TTL (cache duration)
- SRV: the record type
- 0: priority (lower wins)
- 100: weight (load-balancing ratio)
- 389: port number
- dc01.jp.qualiteg.com: the actual server name

1.2.4 How Dynamic DNS Updates Work

Dynamic DNS updates are an extremely convenient feature of the AD-DNS partnership: computers automatically register and update their own information in DNS.

[The era before dynamic updates]
Monday
Tanaka: "My PC (PC-101) has IP address 192.168.1.50."
IT admin: "I'll register it in DNS manually..."

Tuesday (DHCP changed the IP)
Tanaka: "Huh, today it's 192.168.1.75."
Colleague: "I'm trying to connect to PC-101 but I can't."
IT admin: "Ah, the IP address changed. Updating DNS..."

Wednesday (it changed again)
Tanaka: "Today it's 192.168.1.60..."
IT admin: "Manual updates are hopeless!"

Dynamic DNS updates solve this problem.

[Today, with dynamic updates]
Monday 8:00
PC-101: "Booted. DHCP gave me IP 192.168.1.50."
PC-101→DNS: "Please register PC-101 as 192.168.1.50."
DNS: "Registered."

Tuesday 8:00
PC-101: "Booted. Today I got IP 192.168.1.75."
PC-101→DNS: "Please update PC-101 to 192.168.1.75."
DNS: "Updated."

Colleague: "I want to connect to PC-101."
DNS: "Its current IP is 192.168.1.75."
Colleague: "Connected!"

With secure dynamic updates, only authenticated computers can perform updates.

[Secure dynamic updates]
The real PC-101: "Please update my IP."
DNS: "Are you really PC-101?"
PC-101: "Yes, here are my credentials." (Kerberos authentication)
DNS: "Verified. Update allowed."

A malicious PC: "I'm PC-101. Change my IP."
DNS: "Show me your credentials."
Malicious PC: "...I don't have any."
DNS: "Update denied."

Dynamic updates really shine in situations like the following.

[For laptops]
Yamada from Sales: "HQ today, the branch office tomorrow, working from home the day after..."

Monday (HQ)
Yamada's PC: "Got IP 192.168.1.100 on the HQ network."
DNS: "Registering yamada-note as 192.168.1.100."

Tuesday (branch office)
Yamada's PC: "Got IP 192.168.2.200 on the branch network."
DNS: "Updating yamada-note to 192.168.2.200."

Wednesday (VPN connection)
Yamada's PC: "Got IP 10.0.0.50 over the VPN."
DNS: "Updating yamada-note to 10.0.0.50."

IT admin: "Wherever Yamada goes, DNS updates itself. So easy."

Thanks to dynamic DNS updates, the administrator's burden drops dramatically, and name resolution stays current at all times.

1.3 Authentication Methods and Their Differences

1.3.1 Kerberos Authentication

Kerberos authentication is the most secure authentication method used by Active Directory. The name comes from Cerberus, the three-headed watchdog of Greek mythology. Why three heads? Because they represent the three parties involved in authentication: the client, the server, and the authentication server.

Let's explain how Kerberos works using an amusement-park day pass.

[A day pass at an amusement park]
Visitor: "I'd like to enter."
Ticket booth: "Please show me some ID."
Visitor: "Here you go."
Ticket booth: "Verified. Here is your day pass. You can ride any attraction all day today."

(At the roller coaster)
Visitor: "I'd like to ride." (shows the day pass)
Attendant: "Checking the pass... genuine. Go ahead."

(At the Ferris wheel)
Visitor: "I'd like to ride." (shows the day pass)
Attendant: "Checking the pass... genuine. Go ahead."

Kerberos works much the same way.

[The Kerberos flow]
9:00 a.m.
Tanaka: "I want to log in to the company system."
PC→KDC (ticket booth): "Tanaka would like to log in."
KDC: "Password checks out... it's really him. Issuing a TGT (day pass)."
PC: "TGT received."

9:30 (accessing the file server)
PC→KDC: "A ticket for the file server, please." (presents the TGT)
KDC: "The TGT is genuine. Here is a service ticket for the file server."
PC→file server: "I'd like access." (presents the service ticket)
File server: "Checking the ticket... genuine. Access OK."

10:00 (accessing the mail server)
PC→KDC: "A ticket for the mail server, please." (presents the TGT)
KDC: "Here is a service ticket for the mail server."
PC→mail server: "I'd like to read my mail." (presents the service ticket)
Mail server: "Ticket checks out. Go ahead."

A crucial property of Kerberos is that the password never travels over the network.

[How passwords are handled]
(The dangerous way)
Tanaka: "My password is 123456."
Network: "123456... 123456..." (in plain sight)
Malicious person: "So Tanaka's password is 123456... noted."

(The Kerberos way)
Tanaka: (types the password) (processed locally on the PC)
PC: "I'm sending data encrypted using the password."
Network: "#%&$@*..." (encrypted and unreadable)
Malicious person: "What is this? I can't make out a thing."

Kerberos tickets also expire.

[Ticket expiration]
9:00 a.m.
KDC: "This TGT is valid until 18:00 today."

17:55
Tanaka: "I'd like to work a little longer."
PC: "Your TGT is about to expire. Renew it?"
Tanaka: "Yes."
PC→KDC: "Please renew the TGT."
KDC: "Still logged in, I see. Here's a fresh TGT."

The next day
Malicious person: "Let me use the TGT I stole from Tanaka yesterday."
System: "That ticket has expired. Invalid."
Malicious person: "Curses!"

1.3.2 NTLM Authentication

NTLM (NT LAN Manager) authentication is older than Kerberos but is still used for backward compatibility. NTLM uses a mechanism called challenge and response.

Let's compare it to authentication with a secret passphrase.

[The secret hideout in a movie]
Visitor: "Let me in."
Guard: "What's the countersign? Today's challenge is 'mountain'." (challenge)
Visitor: "'River'." (response)
Guard: "Correct. Come in."

Note: the passphrase pair is "mountain → river";
      the correct answer "river" was agreed in advance

The actual NTLM flow looks like this.

[NTLM authentication]
Tanaka: "I want to access the file server."
File server: "Who are you?"
Tanaka's PC: "Tanaka."
File server: "Then encrypt this random number 'ABC123' with Tanaka's password." (challenge)
Tanaka's PC: "Encrypted. The result is 'XYZ789'." (response)
File server→DC: "Tanaka encrypted 'ABC123' and got 'XYZ789'. Is that correct?"
DC: "Let me compute it myself... correct. That really is Tanaka."
File server: "Access granted."

The main differences between NTLM and Kerberos can be summed up as follows.

[Kerberos]
Tanaka: "Authenticate once in the morning, and I have a day pass I can use anywhere, all day."
Each server: "Just verifying the pass (ticket) is enough."
DC: "After the morning, the servers verify things on their own."

[NTLM]
Tanaka: "Accessing the file server."
File server: "One moment, checking with the DC."
DC: "Confirmed."

Tanaka: "Accessing the mail server."
Mail server: "One moment, checking with the DC."
DC: "Confirming again..."

Tanaka: "Now the print server..."
Print server: "One moment, checking with the DC."
DC: "Again!? I'm swamped..."

NTLM is used in situations like these.

[When accessing by IP address]
Tanaka: "I want to access \\192.168.1.50\share."
PC: "An IP address... Kerberos needs a name, so it won't work."
PC: "Authenticating with NTLM."

[With legacy systems]
Tanaka: "I want to log in to this ten-year-old system."
Old system: "Kerberos? What's that? I only know NTLM."
PC: "NTLM it is, then..."

1.3.3 Basic Authentication

Basic authentication is the simplest—and most dangerous—authentication method. Why dangerous? Because it sends the username and password essentially as-is.

[The danger of Basic authentication]
(A real-world analogy)
Tanaka: "I'd like to open the safe."
Safe keeper: "What's the PIN?"
Tanaka: (loudly) "It's 1234!"
Bystanders: "He just said 1234... noted."

(Basic authentication)
Browser: "Username: tanaka, password: Pass123"
Base64 encoding: "dGFuYWthOlBhc3MxMjM="
Network: "dGFuYWthOlBhc3MxMjM= is passing through"
Malicious person: "Base64-decode it and... tanaka:Pass123!"

Base64 encoding is not encryption.

[Encoding vs. encryption]
(Encoding = substituting characters)
Kid: "Let's play secret code: a→1, b→2, c→3."
Kid: "'abc' becomes '123'!"
Adult: "That's cracked in no time."

(Real encryption)
Cryptographer: "Without the special key, it absolutely cannot be decrypted."

Even so, there are reasons Basic authentication is still used.

[When Basic authentication is needed]
IT admin: "I've set up Integrated Windows Authentication."
Tanaka: "Automatic login from company PCs—so convenient!"

(At home)
Tanaka: "I want to access the company system from home."
Personal PC: "Integrated Windows Authentication? Never heard of it."
System: "Then please enter your username and password via Basic authentication."
Tanaka: "tanaka / Pass123"
System: "Verified. Access OK."

There is also a way to make Basic authentication at least somewhat safe.

[Combined with HTTPS]
(HTTP = no encryption)
Tanaka: "tanaka / Pass123"
Network: "tanaka / Pass123 is flowing in plain sight"
Malicious person: "Lucky me!"

(HTTPS = encrypted)
Tanaka: "tanaka / Pass123"
HTTPS: "Encrypting the entire connection."
Network: "%#@$&*..." (everything is encrypted)
Malicious person: "I can't read a thing..."

1.3.4 Choosing Between the Methods, and Their Priority

Active Directory automatically selects the appropriate authentication method for the situation. Let's look at that selection process.

[Automatic selection of the authentication method]
Tanaka: "I want to access a server."
PC: "Let me check which methods are available."

(Pattern 1: everything available)
PC: "Accessing server.jp.qualiteg.com"
Server: "Kerberos, NTLM, Basic—all available."
PC: "Then the safest one: Kerberos."

(Pattern 2: Kerberos unavailable)
PC: "Accessing 192.168.1.100" (an IP address)
Server: "With an IP address, Kerberos won't work. NTLM or Basic."
PC: "NTLM, then."

(Pattern 3: from outside the company)
Tanaka: "Accessing the company web system from home."
Web system: "You're outside the domain. Only Basic is available."
PC: "No choice—Basic it is... but it's over HTTPS, so it's safe."

The actual priority ranking looks like this.

[Security levels]
Highest ↑ Kerberos
    │ "As safe as talking inside bulletproof glass"
    │
    │ NTLM  
    │ "About as safe as exchanging a countersign through a door"
    │
Lowest ↓ Basic
      "As risky as shouting out loud (without HTTPS)"

Here are real examples of how the methods get used.

[On the corporate network]
Morning login
Tanaka: "Good morning."
PC→DC: "Logging in with Kerberos."
DC: "Issuing a TGT. Valid for the rest of the day."

File server access
PC: "Accessing file-server.jp.qualiteg.com"
→ Kerberos is used (the safest)

Access to an old NAS
PC: "Accessing \\192.168.1.200\share"
→ NTLM is used (an IP address, so Kerberos is not possible)

[Remote work]
After connecting to the VPN
Tanaka: "Connected to the company network over VPN."
PC: "Kerberos works just like in the office."

Access via the web
Tanaka: "Accessing https://webapp.jp.qualiteg.com"
Web app: "You're outside the company. Basic authentication, please."
→ Basic authentication (protected by HTTPS)

When troubleshooting, check the following points.

[When authentication fails]
User: "I can't log in!"
IT admin: "Let's check which authentication method is being used."

Check 1: the event logs
"Kerberos authentication failed → NTLM authentication succeeded"
IT admin: "Kerberos is failing and it's falling back to NTLM."

Check 2: common causes
- Clock skew (more than 5 minutes) → Kerberos fails
- DNS problems → Kerberos fails  
- Misconfigured SPN → Kerberos fails
- Old OS/application → no Kerberos support in the first place

The fix:
IT admin: "Checking time sync... it's off by more than 5 minutes!"
IT admin: "After syncing the clocks, Kerberos works again."

Finally, here is a summary of where each method belongs.

[Best practices for choosing a method]
Corporate network:
- Kerberos as a rule (selected automatically)
- NTLM only when unavoidable (automatic fallback)
- Disabling Basic authentication is recommended

DMZ / public-facing web services:
- Kerberos/NTLM cannot be used
- Basic + HTTPS (or forms authentication)
- Add multi-factor authentication where possible

Legacy systems:
- Often support NTLM only
- Protect them with network segmentation and the like
- Draw up a phased migration plan

As you can see, each authentication method has its own characteristics, and it is important to use the right one for the situation. AD tries to select the safest method it can automatically, but depending on the environment and configuration, an unintended method may end up being used—which is exactly why understanding all of this matters.