The RADIUS authentication sequence for MSCHAPv2 follows this protocol exchange:

1. NAS → RADIUS: Access-Request (MS-CHAP-Challenge)
2. RADIUS → NAS: Access-Challenge (MS-CHAP-Challenge)
3. NAS → RADIUS: Access-Request (MS-CHAP-Response)
4. RADIUS → Domain Controller: Authentication Request
5. Domain Controller → RADIUS: Authentication Response
6. RADIUS → NAS: Access-Accept/Reject

Here's my systematic approach to diagnosing Error 691:

Packet Capture Analysis

Using Wireshark, filter for RADIUS traffic (port 1812) and examine:

radius and (ip.src == 10.0.0.10 or ip.dst == 10.0.0.10)

Key fields to validate:

• User-Name attribute format (FQDN or UPN)
• MS-CHAP attributes (Challenge, Response)
• Message-Authenticator integrity

NPS Server Configuration

Verify these PowerShell commands return proper configuration:

Get-NpsRadiusClient -Name "sbc1mgmt" | fl *
Get-NpsConnectionRequestPolicy -Name "SBC Authentication" | fl *

Case Sensitivity Issues

MSCHAPv2 is case-sensitive for both username and password. Test with this PowerShell script:

$cred = Get-Credential
$result = Invoke-Command -ComputerName DC1 -ScriptBlock {
    param($u,$p)
    Add-Type -AssemblyName System.DirectoryServices.AccountManagement
    $ct = [System.DirectoryServices.AccountManagement.ContextType]::Domain
    $pc = New-Object System.DirectoryServices.AccountManagement.PrincipalContext $ct
    $pc.ValidateCredentials($u,$p)
} -ArgumentList $cred.UserName,$cred.GetNetworkCredential().Password
Write-Host "Validation Result: $result"

Password Policy Conflicts

Check for these GPO settings that might interfere:

gpresult /h radius_policy.html
# Specifically examine:
# - Minimum password length
# - Password complexity
# - Account lockout threshold

RADIUS Server Logging

Enable verbose logging in NPS:

netsh nps set tracing enable level=verbose
# Logs will appear in:
# %systemroot%\System32\LogFiles\IN*.log

FreeRADIUS Cross-Verification

Sample FreeRADIUS configuration for MSCHAPv2:

authorize {
    auth_log
    mschap {
        use_mppe = yes
        require_encryption = yes
        require_strong = yes
    }
    if (ok || updated) {
        update control {
            Auth-Type := mschap
        }
    }
}

authenticate {
    Auth-Type mschap {
        mschap
    }
}

After extensive testing, these configurations resolved the issue:

1. Domain Prefix Requirement:

   # In NAS configuration:
   auth format = DOMAIN\username
   # Instead of just username

2. NPS Network Policy:
   • Set "Ignore User Dial-in Properties" to true
   • Add explicit "Grant Access" permission
3. Time Synchronization:

   w32tm /config /syncfromflags:domhier /update
   net stop w32time && net start w32time

---

After analyzing your detailed scenario, we're dealing with a classic RADIUS authentication challenge where valid credentials consistently fail with MS-CHAPv2 (Error 691). The Windows Event IDs 6273 and 4625 clearly indicate credential mismatch, but your testing confirms the credentials are correct. Let's break this down systematically.

The authentication sequence between your Acme Packet SBC and Windows NPS server follows this path:

1. SBC → RADIUS: Access-Request (MS-CHAPv2 Challenge)
2. RADIUS → DC: LDAP/Kerberos verification
3. DC → RADIUS: Authentication response
4. RADIUS → SBC: Access-Reject (Error 691)

Based on your environment (Windows Server 2012 R2, SQL 2012 backend), these elements require verification:

• NPS Server Role Configuration
• Active Directory User Account Settings
• RADIUS Client Shared Secret
• MS-CHAP Protocol Compatibility

Run these on your NPS server to verify configuration:

# Check NPS service status
Get-Service -Name "IAS" | Select-Object Status, StartType

# Verify RADIUS client registration
Get-NpsRadiusClient | Where-Object { $_.Address -eq "10.0.0.10" } | 
  Format-List Name, Address, SharedSecretEnabled, VendorName

# Check network policies
Get-NpsNetworkPolicy | 
  Where-Object { $_.Name -like "*SBC*" } | 
  Format-List Name, Conditions, Constraints, Settings

Create a dedicated test policy with minimal constraints:

# Network Policy Conditions
NAS-Identifier == "radius1.real_domain"
NAS-IPv4-Address == 10.0.0.10

# Authentication Methods
MS-CHAP-v2 (primary)
MS-CHAP (secondary)

# Constraints
Ignore user dial-in properties: Enabled

When examining RADIUS traffic in Wireshark, focus on these attributes:

radius.code == Access-Request
radius.identifier
radius.User_Name
radius.User_Password
radius.Calling_Station_Id
radius.Called_Station_Id

1. SChannel Registry Verification:

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL"

2. NPS Database Repair:

netsh nps reset config

3. Alternative Authentication Test:

# Test with PAP (temporarily)
Set-NpsNetworkPolicy -Name "SBC Policy" -AuthenticationMethods "PAP"

Here's a working configuration snippet from a production environment:

<NetworkPolicy xmlns="http://www.microsoft.com/networking/Policy/config/v1">
  <Name>SBC_MSCHAPv2_Policy</Name>
  <Conditions>
    <NASIPv4Address>10.0.0.10</NASIPv4Address>
  </Conditions>
  <AuthenticationMethods>
    <AuthenticationMethod>
      <Type>MS-CHAP-v2</Type>
      <Configured>true</Configured>
    </AuthenticationMethod>
  </AuthenticationMethods>
  <Constraints>
    <IgnoreUserDialInProperties>true</IgnoreUserDialInProperties>
  </Constraints>
</NetworkPolicy>