Understanding Active Directory Authentication

Cerberus FTP Server Professional and Enterprise editions are able to authenticate users on a Windows domain (or the local NT account database), even if the computer Cerberus FTP Server is installed on is not the domain controller. The domain may be a pre-Windows 2000 domain (NT4), a domain configured to use Active Directory, or the local system account database (use “.” as the domain for authenticating against local machine accounts).

Prerequisites

The following are requirements for performing Active Directory authentication.

1. The machine Cerberus FTP Server is running on must be a member of the domain you wish to authenticate users against
2. The account that the Cerberus FTP Server Windows Service is running under must have permission to query for users in the selected domain
3. The account that the Cerberus FTP Server Windows Service is running under must have permission to log users onto the local machine

Configuring Active Directory Authentication

Configuring Active Directory authentication against a domain in Cerberus FTP Server is done through the Cerberus FTP Server administrative graphical user interface (GUI), and has a few items worth noting.

The administrative process is started when a user clicks the Cerberus FTP Server icon. The admin process runs under that user’s account. When configuring AD authentication, the admin process is running under the logged-in user’s account, and that account must have sufficient privileges to query for users on the selected domain. Accounts without sufficient privileges will get an access denied message when trying to query the domain for users.

Logging into the Server using Active Directory Authentication

Users logging into Cerberus FTP Server using Active Directory authentication should do so using just the account name, or the UPN format account name.

During the actual authentication process, when users are logging into Cerberus, checking for user existence and authentication is done through the Cerberus FTP Server Windows Service. During login, the Cerberus Windows Service first checks to see if it can find the user in the domain. If the user can be found, authentication is allowed to proceed. The account that the Cerberus FTP Server Windows Service is running under has to have permission to query for users in the domain for the user check to succeed. The Cerberus Windows Service usually runs using the default 'Cerberus' local Windows account upon installation. The Cerberus service of legacy Cerberus installations (pre 12.4.0) by default use the 'LocalSystem' account unless a Cerberus admin has changed that to a local or domain user. An "Access denied trying to verify user with server" error will occur if the service account does not have permission to query for users in the selected domain. As long as the machine that Cerberus is running under is part of the domain, the Local System account should have the necessary privileges, but the local 'Cerberus' account may not and you may need to consider switching to running the service using a domain account with sufficient privileges.

Authenticating users in a domain the machine is not part of is not supported. However, authentication may still work if there is a trust relationship between the two domains.

Active Directory User Filesystem Access

Active Directory users are impersonated when they successfully log into Cerberus, and all file access and file operations are carried out as if the server was the actual AD user. This means that the AD user is restricted by whatever permission are on the existing files and directories. If the AD user does not have permission to create files or folders in a directory, neither will the logged in AD user.

The administrator may need to make sure that the user-accessible directories are readable and writable by the Authenticated Users AD group, and that those permissions are inherited by all subdirectories. This will help ensure that files created by one user are readable and modifiable by other AD users. This is only a suggestion. The administrator is free to be as restrictive or as lenient as their security policy dictates.