Fix iSCSI Session Authentication Failure on Windows Server 2022
iSCSI auth fails when CHAP credentials are mismatched or the service isn't stable. Here's how to check both quickly.
Quick answer
If you're seeing an iSCSI session authentication failure—like a login request that just fails—reset the CHAP secret on both the initiator and target to match exactly, then restart the iSCSI initiator service and reconnect.
I've seen this error pop up most often after a firmware update on the SAN or when someone changes the target-side CHAP credentials but forgets to update every connecting host. You'll get a generic message like "The target failed to respond to a login request" in the iSCSI Initiator Properties window. That's the clue. The real fix is almost always a mismatch in CHAP or a stale service state.
Step-by-step fix
- Open the iSCSI Initiator. Press Win + R, type
iscsicpl.exe, and hit Enter. You'll see the iSCSI Initiator Properties window. - Check the target list. Click the Targets tab. If your target shows as Inactive or with a status like Connected (Errors), that's your signal.
- Disconnect first. Select the target and click Disconnect. This clears any partially established session. After you do this, the status will change to Inactive.
- Set CHAP credentials on the initiator. Go to the Configuration tab. Click CHAP. In the CHAP secret field, type the exact secret your target expects—case-sensitive, no extra spaces. Note: The secret must be between 12 and 16 characters for most targets (check your SAN vendor). Click OK.
- Restart the iSCSI service. Open an admin Command Prompt or PowerShell. Type
net stop msiscsiand press Enter. Wait 10 seconds. Then typenet start msiscsi. After the service starts, Windows shows "The Microsoft iSCSI Initiator Service service was started successfully." - Reconnect to the target. Back in the iSCSI Initiator, go to the Targets tab. Type the target's IP or DNS name in the Quick Connect box. Click Quick Connect. After a moment, you should see Connected in the status column.
Alternative fixes if the main one doesn't work
Check mutual CHAP settings
Some targets require mutual CHAP—that's when both sides authenticate each other. On the Configuration tab, click Mutual CHAP and set that secret to match what the target expects for reverse authentication. I've had exactly one SAN that required this, and it took me three hours to figure out. Try it only if the basic CHAP fix fails.
Verify target-side CHAP
Log into your SAN management interface (Dell EqualLogic, NetApp, StarWind, whatever you've got). Find the target's CHAP settings. Confirm the secret is identical to what you set on the initiator. Also check that the initiator's iSCSI name (the IQN) is allowed in the target's access list. You can find the IQN in the iSCSI Initiator Properties Configuration tab—it'll look like iqn.1991-05.com.microsoft:your-server-name.
Disable IPsec temporarily
If you've got IPsec policies applied to iSCSI traffic, they can interfere with authentication. Open the Windows Defender Firewall with Advanced Security. Go to Connection Security Rules. Disable any rule that references iSCSI ports (3260/TCP). Retry the connection. If it works, re-enable the rule but double-check the policy settings.
Prevention tip
Set a CHAP secret standard across your organization—same length, same complexity rules. When you rotate secrets (which you should do every 90 days), update every initiator before the target change. Write a script using PowerShell's Set-IscsiChapSecret cmdlet to push the new secret to all hosts at once. That way you never have a window where auth fails.
Was this solution helpful?