FoxT ServerControl (software)

From Wikipedia, the free encyclopedia
Jump to: navigation, search
FoxT ServerControl
Developer(s) FoxT
Stable release 6.7
Operating system Cross-platform
Type computer security
License Proprietary
Website www.foxt.com

In computer security, FoxT ServerControl is a proprietary product for the centralized management of user authentication and authorization (Role-based access control). The product used to be known as BoKS, or BoKS AccessControl, which is an abbreviation for the Swedish "Behörighet- och KontrollSystem", which translates as "Legitimacy and Control System". FoxT ServerControl was originally designed for use on Unix systems, but has recently been ported to Windows as well.

The product's key features include:[1]

  • Centrally defined access policies for user access to Unix, Linux and Windows servers.
  • Real-time provisioning of security policies from a web interface or the command line.
  • Wide range of configuration options, including various levels of security for specific (groups of) servers.
  • Customized OpenSSH which allows fine-grained access control for SSH subsystems such as SFTP, SCP, X11 forwarding and tunnelling.
  • Extensible beyond initial set of supported protocols through the use of Pluggable Authentication Modules.
  • Provides tools for proactive security monitoring.
  • Allows for interoperability with directory services such as NIS+, LDAP and Active Directory.
  • Active Directory (AD) Bridging capabilities that allows UNIX/Linux systems to join AD and leveraging Kerberos (protocol) for user authentication.

Operation[edit]

A basic FoxT ServerControl infrastructure consists of one master server, one or more replica servers and any number of client (server or desktop) systems. All communications between these hosts is encrypted and takes place over a reserved set of TCP/IP ports.

  • The master server runs the main database and the web interface. Any changes made to accounts, security policies and access routes are all made on the master server.
  • Replica servers contain a copy of the database which is asynchronously updated. Replicas handle most of the authentication and authorization requests sent by servers and desktops. Replicas can also be promoted to master server for the purpose of disaster recovery.

On the server, no modifications to the operating system are required when the agent is installed. The ServerControl daemons run alongside all the other processes, while certain key components of the environment are exchanged to enable ServerControl security. For example, on modern UNIX/Linux platforms (e.g. Solaris, HP-UX, AIX and Linux), PAM is reconfigured in such a way to hand off authentication and authorization requests to the local FoxT ServerControl daemons, which then communicates with a Replica over the network. On older versions of AIX 4.X, 5.0, 5.1, 5.2 and HP-UX 10.X (now all End of Lifed) that are not fully PAM compliant, one usually opts to replace the actual daemons (such as OpenSSH, telnet and ftp) with the FoxT versions which automatically hand over these requests.

A similar plug-in experience is used for the Windows Server agent (e.g. in Server 2008 the FoxT ServerControl agent is installed as a credential provider).

Once a user attempts to log into a server OS, the daemon in question will ask a FoxT ServerControl Replica to verify the provided user name and password (or other authenticator, see later). If these are found to match, FoxT ServerControl will perform a second check to see whether the user is actually allowed to log into this particular server, at this time and using this access method. If this second check is passed, the user is handed back to the login process to conclude the session in the usual fashion.

Common implementation assumes that enterprise (or service provider) provisioning workflow approval of identity occurs elsewhere. Typically user IDs and business groups reside in a corporate databases (Active Directory or LDAP), identity or role managers, and datafeeds. FoxT ServerControl becomes an enforcement and compliance reporting engine.

The FoxT ServerControl configuration may be modified in a number of ways.

  • Through the web interface.
  • From the Unix command line.
  • Automatic user and group updates from Active Directory and LDAP synchronization
  • Integration with Role or Identity Managers thu APIs
  • By dumping the security database, which is then manually edited and restored (not recommended).
  • Early versions of FoxT ServerControl could be configured using a Tivoli/Plus module.

Terminology[edit]

The following terms are frequently used in the management of a FoxT ServerControl infrastructure.

Term Explanation
host Any system on the network, be it master, replica, client (server agent) or non-FoxT ServerControl host.
host group A logical grouping of hosts.
user account A combination of a username, plus its intended target host or hostgroup.
access route One specific security authorization, assigned to a user account or a user class providing a specific linkage to a host or host group.
user class A role description assigning a set of access routes to a user account.
access method A communications protocol, such as telnet, ftp and SSH. Also includes su and suexec.
program group A logical grouping of commands to be executed through suexec, which can be used in an access route.

A few notes:

  • A unique user account is identified by the combination of its user name and the host or host group for which it has been defined. Multiple occurrences of a user name are allowed, as long as they are defined for different hosts or host groups. One common example is the Unix Root user account, which is always defined on the host level. Examples of user accounts: server1:root, SOLARIS:peter, ORACLE:patrick.
  • A user account may have multiple user classes assigned to it. This allows one user account to perform work that is officially split across different departments. For example, SOLARIS:Peter may have both the user classes "SolarisThirdLine" and "BackupManagement".
  • A host can be part of any number of host groups. This allows for fine-grained control over the provisioning of user accounts to specific servers. For example, server1 may be part of host groups SOLARIS, ORACLE and BACKUPEXEC, thus receiving all user accounts defined for those groups.
  • Access routes can be assigned both to individual users, as well as to user classes. Thus one can allow server1:root to login only to the console of server1, while allowing SOLARIS:peter SSH access to all servers in host group SOLARIS.
  • The term "FoxT ServerControl client" is being replaced in FoxT literature/website and documentation with the more common market term "Server Agent"

Supported protocols[edit]

FoxT ServerControl supports the following protocols: Serial & network port login(UNIX/Linux), console login (UNIX/Linux & Windows), su, suexec (UNIX/Linux equivalent to sudo), FoxT ServerControlrunas (Windows equivalent to runas), secure RDP(Windows) secure telnet (UNIX/Linux), XDM and SSH (UNIX/Linux & Windows). The SSH protocol may be sub-defined and further split into ssh_sh (shell), ssh_exec (remote command execution), ssh_scp (SCP only), ssh_sftp (SFTP only), ssh_x11 (X11 forwarding), ssh_rfwd (remote port forwarding), ssh_fwd (local port forwarding) and ssh* (all of the above).

Older non-secure protocols: rlogin, rsh, rexec, ftp, rex, telnet are also supported for legacy purposes, but more typically are set up as banned across your server estate for compliance reasons. Support for PC-NFS has been deprecated.

Each protocol definition (defined in an Access Route) can be configured to change or require multiple factors of authentication

  • all: use password authentication
  • all: use X.509 certificate authentication
  • all: use a One Time Password authentication like SecurID or Safeword
  • for su: to use the user's own password to transition to a privileged account
  • for suexec: optionally to keystroke log the session
  • for SSH protocols: SSH keys generated by FoxT ServerControl, or to re-use existing SSH distributed keys.

A typical use case might be server support staff are challenged by a SecurID request to login on a server console in the computer room, and to use a PKI token on their own PC in their normal work area.

It is possible to plug other protocols into FoxT ServerControl, though this will require some customization. It is easiest if the software in question has support for Pluggable Authentication Modules, as there is a standard FoxT ServerControl module for PAM.

History[edit]

Over the years the FoxT ServerControl family of products has changed names and vendors a few times via product acquisition. It originated as BoKS UnixControl at DynaSoft in Sweden, after which it was sold by Security Dynamics, RSA Security (where it was known as Keon), latterly by TFS Technology (known as UnixControl or ServerControl). The company changed its name in 2004 to Fox Technologies Inc, and uses the sales/marketing label FoxT.

Over the years the product has been sold under OEM licenses by other server vendors (HP, SUN) with alternate product names.

See also[edit]

External links[edit]

References[edit]