14.5 iSCSI Target Server, IQNs, CHAP Authentication & Multipath I/O

iSCSI Target Server, IQNs, CHAP Authentication & Multipath I/O

Storage Replica and Storage Spaces both assume the server already has block storage. iSCSI Target Server is how Windows Server provides it: a role service that presents virtual disks as SCSI logical unit numbers (LUNs) over a standard TCP/IP network, so any initiator — a Hyper-V host building a guest cluster, a Linux database server, a diskless workstation — can attach remote storage as though it were locally connected.

1. Architecture: Targets, Initiators and Portals

The iSCSI Target Server role in Windows Server transforms a standard Windows Server into an IP-based block storage SAN appliance, serving virtual disks over standard Ethernet fabrics.

+-----------------------------------------------------------------------------------+
|                         iSCSI SAN ARCHITECTURE & MPIO                             |
|                                                                                   |
|   [iSCSI INITIATOR (CLIENT)]                           [iSCSI TARGET SERVER]      |
|   - Windows Server / Hyper-V                           - Windows Server Role      |
|   - IQN: iqn.1991-05.com.microsoft:...                 - Port: TCP 3260           |
|   +--------------------------+                         +------------------------+ |
|   | NIC 1 (192.168.20.10)    | ===(Path 1: TCP 3260)==>| Portal 1 (192.168.20.1)| |
|   |                          |    [MPIO Load Balancing]| - Target: Target-VMs   | |
|   | NIC 2 (192.168.21.10)    | ===(Path 2: TCP 3260)==>| Portal 2 (192.168.21.1)| |
|   +--------------------------+                         +------------------------+ |
|                |                                                   |              |
|   [MPIO: Round Robin / Failover]                       [iSCSI Virtual Disks]      |
|   Presents single Disk to OS                           (LUN 0: Data.vhdx)         |
+-----------------------------------------------------------------------------------+

Core iSCSI Concepts

1. iSCSI Target: A logical entity created on the target server that manages connections and exposes one or more iSCSI Virtual Disks (.vhdx files) as LUNs to authorized initiators.
2. iSCSI Initiator: The client system (Hyper-V host, database server) that mounts the remote LUNs. Each initiator is uniquely identified by its iSCSI Qualified Name (IQN) (e.g., iqn.1991-05.com.microsoft:srv-app01.corp.contoso.com).
3. Target Portals: The IP addresses and port (TCP port 3260) on which the iSCSI Target listens for incoming discovery and login requests.

Authentication: One-Way CHAP vs. Mutual CHAP

• Unauthenticated / IQN Only: Access is restricted solely by matching the client's IQN or IP address.
• One-Way CHAP (Challenge Handshake Authentication Protocol): The Target challenges the Initiator. The Initiator must supply a valid shared secret (password) to log in.
• Mutual (Reverse) CHAP: The Target authenticates the Initiator, and the Initiator simultaneously authenticates the Target using two distinct secrets. This prevents rogue target spoofing and man-in-the-middle attacks on the storage fabric.

High Availability: Multipath I/O (MPIO)

To eliminate network interface and switch single points of failure, administrators configure Multipath I/O (MPIO) on iSCSI initiators.

• Microsoft DSM (Device Specific Module): Aggregates multiple network paths to the same iSCSI LUN into a single logical disk presented to the operating system.
• MPIO Load Balancing Policies:
  • Failover Only: Active/Passive configuration; traffic flows across a primary path, switching to standby only upon path failure.
  • Round Robin: Active/Active configuration; rotates I/O requests sequentially across all healthy network paths for aggregated throughput.
  • Least Queue Depth: Routes I/O to the path currently processing the fewest active requests.

# Install iSCSI Target Server Role and MPIO Feature
Install-WindowsFeature -Name FS-iSCSITarget-Server, Multipath-IO -IncludeManagementTools

# Create an iSCSI Virtual Disk (.vhdx)
New-IscsiVirtualDisk -Path 'D:\iSCSIVirtualDisks\LUN-SQL01.vhdx' -SizeBytes 500GB

# Create an iSCSI Target and assign the Initiator IQN
New-IscsiServerTarget `
    -TargetName 'Target-SQL01' `
    -InitiatorIds @('IQN:iqn.1991-05.com.microsoft:srv-sql-01.corp.contoso.com')

# Assign the Virtual Disk to the Target
Add-IscsiVirtualDiskTargetMapping -TargetName 'Target-SQL01' -Path 'D:\iSCSIVirtualDisks\LUN-SQL01.vhdx'

---

2. Installation, Backing Storage and Where iSCSI Fits

iSCSI Target Server is a role service of the File and Storage Services role, found under File and iSCSI Services — not a standalone Windows feature. The client side needs nothing installed at all: the Microsoft iSCSI Initiator ships in every Windows Server and Windows client, exposed through iscsicpl.exe and the MSiSCSI service, which is set to Manual by default and must be started and set to Automatic.

Backing storage is a VHDX file on an NTFS or ReFS volume, which brings three practical consequences:

• Virtual disks can be fixed, dynamically expanding or differencing, and the target server can be backed by anything Windows can mount — Storage Spaces, a hardware RAID set, a SAN LUN or plain direct-attached disks.
• Because a LUN is a file, it can be snapshotted, backed up and moved with ordinary file tooling while the target is offline.
• Differencing disks are what make large-scale diskless network boot economical. Microsoft's own testing deployed 256 computers in 34 minutes, and differencing VHDs can save up to 90 percent of the storage otherwise consumed by identical operating system images.

Because iSCSI Target Server supports non-Microsoft initiators, it is also the common answer for presenting Windows-backed block storage to Linux or appliance workloads that cannot speak SMB.

[!IMPORTANT] For high availability, iSCSI Target Server itself is installed as a failover cluster role, which requires shared storage behind the cluster — Fibre Channel or a shared SAS array. Installing the role on two standalone servers and pointing initiators at both does not produce a highly available target; it produces two unrelated targets and a corrupted file system if both are written.

3. Access Control: IQNs, CHAP and Mutual CHAP

Access control has two independent layers, and the exam expects you to know that the first one is weak on its own.

Layer 1 — initiator identification. A target lists the initiators permitted to connect, identified by IQN, by IP address, by MAC address, or by DNS name. The iSCSI Qualified Name takes the form:

iqn.yyyy-mm.<reversed-domain>:<unique-name>
      |         |                  |
      |         |                  +-- host-specific identifier
      |         +-- naming authority that owned the domain at that date
      +-- year and month the naming authority was registered

Example: iqn.1991-05.com.microsoft:srv-sql-01.corp.contoso.com

An IQN is a name, not a credential — it is configured locally on the initiator and can be changed by anyone with administrative rights on that machine. IQN-only access control is therefore appropriate for an isolated storage VLAN, never for a shared network.

Layer 2 — CHAP. The Challenge Handshake Authentication Protocol proves possession of a shared secret without sending it over the wire:

Mutual CHAP is what defends against a rogue target: without it, an attacker who can answer at the target IP address can present a fake LUN to your initiator. Two constraints cause most configuration failures:

1. The Microsoft iSCSI Initiator requires the CHAP secret to be 12 to 16 characters. A shorter or longer secret is rejected at the initiator with a CHAP secret error, even though the target may have accepted it.
2. Mutual CHAP must be configured on both ends; the reverse secret is entered in the initiator's Configuration tab, not in the connection dialog, and omitting it produces an authentication failure that looks like a wrong password.

# Target side: require one-way CHAP, then add a distinct reverse secret for mutual CHAP
Set-IscsiServerTarget -TargetName 'Target-SQL01' `
    -EnableChap $true  -Chap        (Get-Credential 'iscsi-chap-user') `
    -EnableReverseChap $true -ReverseChap (Get-Credential 'iscsi-revchap-user')

# Initiator side: start the service, register the portal, and connect with MPIO enabled
Set-Service -Name MSiSCSI -StartupType Automatic; Start-Service MSiSCSI
New-IscsiTargetPortal -TargetPortalAddress '192.168.20.1'
Connect-IscsiTarget -NodeAddress 'iqn.1991-05.com.microsoft:tgt-sql01-target-sql01' `
    -IsPersistent $true -IsMultipathEnabled $true `
    -AuthenticationType MUTUALCHAP -ChapUsername 'iscsi-chap-user' -ChapSecret '<12-16 chars>'

4. Discovery, MPIO and Operational Checks

Initiators find targets in one of two ways. Target portal discovery requires each initiator to be told the target server's IP address and port explicitly — simple, and fine for a handful of hosts. The Internet Storage Name Service (iSNS) is a Windows Server feature that acts as a central registry: targets register themselves, initiators query the iSNS server, and adding a new target requires no change on any initiator. In a fleet of dozens of hosts, iSNS is the answer to "how do we avoid touching every initiator".

MPIO is not optional in production. A single NIC, cable or switch between an initiator and its LUN is a single point of failure for a disk, which is far more damaging than losing a network path. The Microsoft Device Specific Module presents multiple paths as one logical disk; the load-balancing policy determines how I/O is distributed:

# Enable MPIO for iSCSI devices (a restart is required) and set the default policy
Enable-MSDSMAutomaticClaim -BusType iSCSI
Set-MSDSMGlobalDefaultLoadBalancePolicy -Policy RR

# Verify what the initiator actually sees
Get-IscsiSession   | Format-Table InitiatorNodeAddress,TargetNodeAddress,IsPersistent,IsConnected
Get-IscsiConnection| Format-Table ConnectionIdentifier,InitiatorAddress,TargetAddress
Get-Disk | Where-Object BusType -eq 'iSCSI' | Format-Table Number,FriendlyName,OperationalStatus,Size

[!TIP] Two symptoms and their causes: the same LUN appears twice in Disk Management means MPIO is not claiming iSCSI devices, so run Enable-MSDSMAutomaticClaim -BusType iSCSI and restart. The disk disappears after a reboot means the connection was made without -IsPersistent $true, so it was never added to the favorite targets list.