I recently encountered a puzzling scenario where my FTP server (IIS 7 on Windows Server 2008) accepted connections from FileZilla but rejected authentication attempts from Windows Explorer and command prompt. Here's my troubleshooting journey:

First, I verified the basic server setup:

# PowerShell to check FTP site bindings
Get-ChildItem IIS:\Sites | Where-Object {$_.Name -like "*FTP*"} | Select-Object Name, Bindings

# Output showing the binding:
Name         Bindings
----         --------
Default FTP  ftp *:21:

The user "john" had explicit permissions set through IIS Manager with read/write access to the virtual directory.

The key discovery came when examining the authentication methods:

• FileZilla defaults to explicit FTP over TLS (FTPS)
• Windows native clients attempt basic FTP with clear-text credentials

To support both connection types, I modified the authentication settings:

# Modifying authentication settings via appcmd
%windir%\system32\inetsrv\appcmd set config /section:system.ftpServer/security/authentication /basicAuthentication.enabled:true /commit:apphost

Then restarted the FTP service:

net stop ftpsvc
net start ftpsvc

For Windows Explorer (requires passive mode):

ftp://john:password@serverip/

For command line testing:

ftp serverip
Connected to serverip.
220 Microsoft FTP Service
User (serverip:(none)): john
331 Password required
Password: 
230 User logged in.

While enabling basic authentication works, it's not recommended for production without additional protections:

1. Implement IP restrictions
2. Set up FTP SSL certificates
3. Use firewall rules to limit access

For proper security, I ultimately configured FTPS and instructed all users to use FileZilla or other FTPS-capable clients.

The complete working configuration required:

FTP Authentication: Basic enabled
Authorization: Specific user with read/write
Firewall: Port 21 TCP allowed
FTP Features: All installed (including SSL)
User Isolation: Disabled for this scenario

---

I recently encountered a puzzling scenario where FileZilla could authenticate successfully against my Windows Server 2008 FTP server (IIS 7), while Windows Explorer and command-line FTP clients failed with "Login failed" errors. Here's my deep dive into solving this authentication paradox.

The root cause lies in how different clients handle FTP authentication. FileZilla supports modern authentication protocols, while Windows built-in tools often default to older methods:

// Example of FileZilla's supported authentication methods
AUTH TLS
AUTH SSL
AUTH TLS-C
AUTH TLS-P

Meanwhile, Windows Explorer's FTP implementation typically uses:

USER username
PASS password

For Windows native clients to work, you need to ensure these IIS FTP settings:

// PowerShell to check FTP authentication settings
Get-WebConfiguration -Filter /system.ftpServer/security/authentication/* | 
Where-Object {$_.enabled -eq $true} | 
Select-Object @{Name="Authentication";Expression={$_.SectionPath.Split("/")[-1]}},enabled

Here's what fixed it for me:

1. Enable Basic Authentication in IIS:
   <basicAuthentication enabled="true" />

2. Set proper authorization rules:
   <authorization>
     <add accessType="Allow" users="john" permissions="Read, Write" />
   </authorization>

3. Configure SSL settings (if needed):
   <ssl controlChannelPolicy="SslAllow" dataChannelPolicy="SslAllow" />

Use this PowerShell script to test both authentication methods:

# Test FTP connection with different methods
function Test-FTPConnection {
    param(
        [string]$server,
        [string]$user,
        [string]$pass
    )
    
    # Method 1: WebClient (similar to Windows Explorer)
    try {
        $webClient = New-Object System.Net.WebClient
        $webClient.Credentials = New-Object System.Net.NetworkCredential($user, $pass)
        $webClient.DownloadString("ftp://$server/")
        Write-Host "WebClient authentication SUCCESS"
    } catch {
        Write-Host "WebClient authentication FAILED: $_"
    }

    # Method 2: FtpWebRequest (more control)
    try {
        $ftpRequest = [System.Net.FtpWebRequest]::Create("ftp://$server/")
        $ftpRequest.Credentials = New-Object System.Net.NetworkCredential($user, $pass)
        $ftpRequest.Method = [System.Net.WebRequestMethods+Ftp]::ListDirectory
        $ftpRequest.GetResponse()
        Write-Host "FtpWebRequest authentication SUCCESS"
    } catch {
        Write-Host "FtpWebRequest authentication FAILED: $_"
    }
}

Don't forget to check:

netsh advfirewall firewall show rule name=all | findstr "FTP"
netsh interface ipv4 show excludedportrange protocol=tcp

Remember that Windows Firewall might block passive FTP connections differently than active ones, which could explain why some clients work while others don't.

• Basic Authentication enabled in IIS
• Proper authorization rules configured
• Correct SSL settings (if using encrypted connections)
• Windows Firewall configured for both active and passive FTP
• User permissions properly set in Windows (not just IIS)