All requesters of cryptographic services from SAKA must be authorized. A username and a password must be supplied in the web service call to SAKA. The username must be granted either the privilege to encrypt, decrypt, or both. SAKA provides you the option of choosing where to define authorized users of SAKA cryptographic services. By default, SAKA will use the internal database to authenticate users and determine their authorization. However, with the exception of the administrator1 credential, SAKA allows you the choice of using your Active Directory (or another LDAP-based directory server) to authenticate users and determine their authorization for cryptographic services.

Using AD for managing access control to SAKA requires either modifying the strongkeylite-configuration.properties file in the STRONGKEYLITE_HOME/etc directory of the appliances, or using DACTool to modify the configuration. The former applies to all encryption domains on the appliance, while the latter applies only to the modified encryption domain. Thus, it is possible to host multiple encryption domains on the same appliance and have them use the internal database, an external LDAP directory, or Active Directory at the same time in different domains.

To have all encryption domains in SAKA use Active Directory to authenticate and authorize users, perform the following tasks:

1. Login to your Windows AD server as a Domain Administrator.

2. From the Administration Tools menu, start the management tool to manage AD Users and Groups.

3. Create the following containers under your domain's base DN (you may also use the script identified in Appendix A to execute this from a Command Tool):

   • OU=applications

   • OU=StrongAuth, OU=applications

   • OU=StrongKeyLite, OU=StrongAuth, OU=applications

   • OU=v1, OU=StrongKeyLite, OU=StrongAuth, OU=applications

   • OU=Users, OU=v1, OU=StrongKeyLite, OU=StrongAuth, OU=applications

   • OU=groups, OU=v1, OU=StrongKeyLite, OU=StrongAuth, OU=applications

    

   To use the same part of the AD tree that contains the domain users, specify the container DN for the strongkeylite.cfg.property.dnsuffix property so SAKA knows where to find AD users in the tree.

4. Create the following groups (or to use groups defined in the location where AD normally creates its groups, specify the container DN of the groups for the strongkeylite.cfg.property.ldapencryptiongroup, the strongkeylite.cfg.property.ldapdecryptiongroup, the strongkeylite.cfg.property.ldapdeletiongroup, the strongkeylite.cfg.property.ldaprelaygroup, and the strongkeylite.cfg.property.ldapsearchgroup properties):

   • CN=EncryptionAuthorized, OU=groups, OU=v1, OU=StrongKeyLite, OU=StrongAuth, OU=applications

   • CN=DecryptionAuthorized, OU=groups, OU=v1, OU=StrongKeyLite, OU=StrongAuth, OU=applications

   • CN=DeletionAuthorized, OU=groups, OU=v1, OU=StrongKeyLite, OU=StrongAuth, OU=applications

   • CN=RelayAuthorized, OU=groups, OU=v1, OU=StrongKeyLite, OU=StrongAuth, OU=applications

   • CN=SearchAuthorized, OU=groups, OU=v1, OU=StrongKeyLite, OU=StrongAuth, OU=applications

5. Add the users to the encryption and decryption groups as members so SAKA knows they are authorized for that operation.

6. Add the following properties to the strongkeylite-configuration.properties file in the STRONGKEYLITE_HOMEdirectory. Make sure to replace “diligentcompany” and “com” with the appropriate values for your domain:

   #
   			# Properties to use Active Directory for SAKA access control
   #
   strongkeylite.cfg.property.ldaptype=AD
   strongkeylite.cfg.property.ldapurl=ldaps://ads01.diligentcompany.com:636
   strongkeylite.cfg.property.basedn=dc=diligentcompany,dc=com
   strongkeylite.cfg.property.dnsuffix=,ou=users,ou=v1,ou=StrongKeyLite,ou=StrongAuth,ou=applications,dc=diligentcompany,dc=com
   strongkeylite.cfg.property.ldapencryptiongroup=cn=EncryptionAuthorized,ou=groups,ou=v1,ou=StrongKeyLite,ou=StrongAuth,ou=applications,dc=diligentcompany,dc=com
   strongkeylite.cfg.property.ldapdecryptiongroup=cn=DecryptionAuthorized,ou=groups,ou=v1,ou=StrongKeyLite,ou=StrongAuth,ou=applications,dc=diligentcompany,dc=com
   strongkeylite.cfg.property.ldapdeletiongroup=cn=DeletionAuthorized,ou=groups,ou=v1,ou=StrongKeyLite,ou=StrongAuth,ou=applications,dc=diligentcompany,dc=com
   strongkeylite.cfg.property.ldaprelaygroup=cn=RelayAuthorized,ou=groups,ou=v1,ou=StrongKeyLite,ou=StrongAuth,ou=applications,dc=diligentcompany,dc=com
   strongkeylite.cfg.property.ldapsearchgroup=cn=SearchAuthorized,ou=groups,ou=v1,ou=StrongKeyLite,ou=StrongAuth,ou=applications, dc=diligentcompany,dc=com

    

7. Test the connection by using the ldapsearch command on the appliance to connect to the ldapurl specified in the properties file; try to access each of the containers specified in the properties files—specifically the ones specifying the dnsuffix and the two groups. Until you can successfully connect and access these groups from the command line, don't attempt to test SAKA for AD integration. If AD cannot be reached from the command line, SAKA will never be able to do so, either. See the main page for ldapsearch to see how to use the tool.

8. After verifying connection to AD using ldapsearch, restart the application server on the SAKA instance (or restart SAKA). Set the PINs for the cryptographic hardware module before cryptographic services are available (see Chapter 10—KAM KCSetPINTool for details).

To enable AD integration for a specific encryption domain, as opposed to all SAKA domains, perform the same tasks described above, but instead of adding the properties to the strongkeylite-configuration.properties file, use the DACTool and add them to the domain's Mutable Configuration.

However, because SAKA configuration through DACTool goes into effect immediately, it is advisable to test the values from the command line (using ldapsearch) before modifying the properties in DACTool.

NOTE: It is strongly advised that before making changes to SAKA affecting access control, that it is thoroughly tested, and to pause application service requests for 10‒15 minutes while you make the final changes.