There are many avenues of communication between RPM, its components, and the managed systems. So the description must first start with how the passwords are set and a qualifier: RPM does not perform any of its own networking and we do not utilize agents. RPM commands its localhost to perform connections and issue remote commands. All networking is a result of Windows to Windows communications and therefore follows the same rules and protocols.
  1. Initiate communication and authentication to machine via named pipes – requires local admin access. Performed via SMB communications. Domain or local policy can mandate the use of SMB signing and/or IPSec for network traffic.
  2. Password is transmitted to the system while encrypted using SMB communications as well as any other methods of encrypting or signing traffic deployed on the network.
  3. Set password on target system.
  4. If password set is successful (error 0 returned), then encrypt password using defined encryption algorithm and record encrypted value into database. Included encryption methods include AES 128, 192, and 256bit encryption methods. Although the code used for encryption was FIPS certified, the application is not FIPS certified. RPM can utilize an external FIPS certified encryption module however we would consider this less secure as this module or method can be shimmed. In the near future, RPM will also be able to utilize hardware encryption to protect the passwords. Transmission to the SQL database will in the near future, also allow SSL communication.
  5. Later in the web interface, a user can request a password. The user will be authenticated by their Active Directory domain or by RPM (determined if logging in as a domain user or an explicit user) and compared to the delegation rights defined for RPM. Future versions will grant access based on RSA, CAC cards, and other similar technologies. Access to the website should be secured via SSL authentication. Client based certificates and/or IP restrictions can further be defined in Internet Information Services (IIS) to help restrict access. Any and all certificates used will be provided by the customer.
  6. When the website requests a password, a call is made to the database (which in future versions can also be encrypted with SSL) to recover the encrypted value.
  7. The encrypted value is decrypted at the web server and passed to the client’s web browser. This traffic should be secured using SSL, user certificates, and IP restrictions. Any and all certificates used will be provided by the customer.