Where and how does Quest Enterprise Single Sign-On (QESSO) store user credentials?
This information is stored in Active Directory.
QESSO uses the directory (or a dedicated directory in the case of ADAM) to store configuration and SSO's policies and user's SSO data.
The SSO data are the accounts which allow access to applications. Each account is stored in the directory as an LDAP (Lightweight Directory Access Protocol) object. Using an object account allows for better management of security.
The account objects are stored under an object "SSO container", which is under the user object (or his representative in the case of separation of directories for authentication and SSO).
ESSO works in a distributed fashion, without a central server. To secure user's SSO data, two methods are used for security: encryption and ACLs.
To encrypt the SSO data, ESSO obtains an encryption key (private Key) during authentication.
Depending on the type of authentication, this key is obtained in various ways.
This key is not used directly to encrypt SSO data.
For encrypting the SSO data, ESSO uses two SSO keys (AES 128-bit):
- An SSO key, called "recoverable"
- An SSO key, unrecoverable or private.
These keys are randomly generated when SSOwatch is launched for the first time by the user; they are then encrypted by the private key of the user and Public Key of the installation.
The Installation's Public Key is generated at ESSO installation time, based on Pass Phase or Security Module Key.
The Public key is published in the directory to be accessible to all ESSO's clients.
For the more detailed information on ESSO encryption please refer to the CertiPath Method.
The specific object containing the user's encryption is called CN=enatelSSOStorageV3 found under the user's object.
© 2024 One Identity LLC. ALL RIGHTS RESERVED. Feedback Terms of Use Privacy Cookie Preference Center