To successfully implement a new Impero Security Server (NSS) with integration to your Microsoft Active Directory with a single domain, the following technical requirements should be observed. 

  • Intel Pentium processor or higher or compatible
  • Memory: OS requirements plus additional 32MB
  • Video:  Any 100% VGA compatible graphics adapter supported by Windows
  • 30 MB of disk space for NSS and Security Manager (Additional space required for database)
  • TCP/IP (IPv4) Winsock 1.1 or compatible
  • Platforms (32-bit and 64-bit): Windows Server 2016, 2012, 2008  (all editions).
  • Database:  Microsoft SQL Server 2005 or higher.  For database space requirements see the following link.
    Security Server database requirements
  • Console access to the server for the installation of Impero Security Server is required.
  • It is not recommended to use Microsoft Remote Desktop (RDP) for Security Server installation and administration.  Attempting to install or administer the NSS module with Remote Desktop (RDP) requires observing certain process steps.
  • A vSphere client (or similar) is recommended for console access to virtual machines during installation.  
  • Keep in mind that once NSS is installed and configured the Impero Guest can be used for remote access to the Security Server and RDS for access to the Security Manager. 
  • If the Impero Security Server computer is not domain member it may still serve as central authentication/authorization handler for objects in one or more domains. In this case all communication with the domain(s) takes place using LDAP.

  • The Host must be able to communicate with the Security Server via UDP on port 6502 or any chosen and configured port. (The Host contacts the Security Server to authenticate the Guest user.  Communication between Guest and Host is not relayed through the Security Server.)

  • A Impero service account should be created on the domain that fulfills the following needs.
    1. In the Security Manager's Directory Service definition. This account must have domain rights to query users, computers, group membership and organizational units.
    2. In the Security Server's 'Run As' setting. If the server uses Windows calls (not LDAP) to query the domain this account must have permission to query users, computers, group membership and organization units. This account must be added to the Local Administrators Group in Windows on the Security Server computer in order to create a trusted user for the ODBC link in case the Security Server's database uses Windows authentication.
    3. In the ODBC connection to access the database. If you are using an MSSQL database that can use a Windows account then this account should have database owner permissions - at least during installation and initial configuration. At the initial launch of Security Manager the database is being populated with tables and initial data. After this operation the database account permissions can be reduced to read/write.
In a production environment it is highly recommended that you have two or more Security Servers, connected to a single database running in a clustered server environment to reduce the risk of a single point of failure.
We recognize that every organization's active directory, domain and network architecture is unique.  There are many different ways to configure the Impero Security Server.  The prerequisites listed above are intended as guidelines for the most common scenario.  Opportunities for exceptions may depend on your environment and/or configuration.  Here are a list of questions that should be considered before you begin.
  • Where will the Host computers be located on the network?  (The Host module will need to communicate with the Security Server module to authenticate the Guest user.)
  • Where will the Guest computers be located on the network?  (The Guest module does not necessarily need to be able to communicate with the Security Server module.)
  • If some of the Guests or Hosts will be communicating across the internet, have firewall considerations been made?
  • Are some or all of the Host or Guest modules going to be running in a Terminal Server or Citrix session?
  • Are all of the Host computers a member of the domain?
  • Do all of the Guest users have a unique Windows logon to the domain?
  • Are the Host computers in the Active Directory organized in to groups or organizational units?
  • If multiple domains are used, what is the trust relationship between domains?