Cerberus FTP Server turns a Windows machine into a managed file-transfer endpoint. An administrator chooses which transfer protocols listen for connections, creates local users or connects an identity source, then maps those accounts to selected folders. Remote clients can reach the same stored files through SFTP, FTPS, FTP, HTTPS or HTTP when the corresponding listener is enabled. Cerberus FTP Server controls the transfer session, but Windows still controls access to the underlying disks.
+
Listeners define entry
+Each protocol listener binds an address and port. SFTP runs through SSH, while FTPS adds TLS to the FTP protocol; these are different protocols rather than two names for the same encrypted session. A client must choose the protocol that matches the listener. Selecting SFTP in a client cannot connect to an FTPS port, even when the username and password are correct.
+The administrator can place several listeners on one machine, restrict the interfaces they use and assign certificate or SSH settings where the protocol needs them. HTTPS gives browser users a web-based route, while a transfer client may suit repeated uploads better. Cerberus FTP Server also records connection and authentication events, which helps separate a rejected password from a firewall failure.
+
FTP opens twice
+Traditional FTP uses one connection for commands and another for file data. External passive-mode clients therefore need more than the visible control port. The router and firewall must also forward a configured passive port range to the server. Cerberus FTP Server can advertise the public address and limit the range, but the network equipment must agree with those values. A login that succeeds while directory listings hang usually points to the data path rather than the account.
+SFTP avoids this particular two-connection design because it carries operations through its SSH connection. That can simplify firewall work, although the server still needs a reachable listener and the client still needs the correct host key and login method. Switching protocols to solve a network problem also means changing the client configuration; it does not transparently repair an existing FTP profile.
+
Aliases hide paths
+Virtual directories expose friendly names without revealing the real Windows path. An alias such as incoming can point to a folder on another volume or a network location. Per-user and group mappings decide what appears after login, and permissions can limit listing, downloading, uploading, renaming or deletion. This lets two accounts see different views of the same server.
+The mapping alone does not grant filesystem access. Cerberus FTP Server runs under a Windows service account, and that identity must be able to reach the real directory. A share can exist and the alias can look correct while every file operation fails because Windows denies the service account. Network shares may also need a service identity with suitable remote credentials rather than a local account that works only on the server.
+
Certificates need context
+TLS listeners need a certificate whose name matches the address that clients use. A self-signed certificate can encrypt traffic, but clients will warn because no trusted authority vouches for it. SFTP instead presents an SSH host key, and clients may ask the user to confirm that fingerprint on first contact. Administrators should treat either warning as an identity question rather than train users to click through every prompt.
+Configuration changes do not all become active in the same way. Some listener and protocol changes require a service restart, which interrupts current sessions. Testing with a separate account and a file-transfer client before inviting users catches port, certificate and directory mistakes without exposing the production folders.
