What schema changes and rights assignments does ADSSchema.Exe make?
For SecureLogin to save user SSO data such as their usernames and passwords to applications, and to read SSO enabled applications and settings, the ADS schema must be extended and rights must be assigned.
If you have installed SecureLogin in Microsoft Active Directory mode, you wonât be able to run it until you have extended the Schema and assigned the rights using adsschema.exe. ADSSchema.Exe must be run if you plan to use AD as the SecureLogin datastore. To extend the schema and assign the rights, first install the SecureLogin client on at least one workstation and run ADSchema.Exe (which only needs to be run once per ADS forest).
To extend the schema of a given domain, you must have sufficient rights over the domain. The extension may take some time to filter throughout your network, depending on the size of your network and the speed of the links.
In AD mode, the six new attributes are:
- Contains a key that is generated using a one way hash of the userâs passphrase.
- On both OU and User objects it contains data such as application scripts and settings, and against the user object only, it stores all the user IDs, passwords and other variables ($VariableName) for applications.
- Runs a check to ensure only âprotocom-SSO-Entriesâ data that has changed is synchronized between the Directory and the local cache.
- Redirects the object to read itâs SecureLogin configuration information from another container. Typically all applications and settings for a user are set in the Users parent container. User CN=MichaelC,OU=Users,DC=Utah,DC=ACME,DC=COM would inherit applications and settings from OU=Users,DC=Utah,DC=ACME,DC=COM. However, you could configure OU=Users,DC=Utah,DC=ACME,DC=COM to read itâs SecureLogin configuration from another container such as OU=Users,DC=NewYork,DC=ACME,DC=COM.
- Note: This function is rarely used but provides flexibility depending on your network design and requirements
- Contains passphrase configuration information such as predefined passphrase questions, passphrase policies, help text etc.
- Runs a check to ensure only âprotocom-SSO-Security-Prefsâ data that has changed is synchronized between the Directory and the local cache.
All SecureLogin data is protected from unauthorized access in a number of ways to maximize the security of the product. At the raw database level data is protected by Access Control Lists (ACLs)/Directory rights assignments. When SecureLogin is installed, it sets up default rights enabling users to read and write their SSO data.
When SecureLogin is installed, it sets up default rights enabling users to read and write SSO data stored against their user object (but not others). For example, users require the ability to read and write their passphrase, application usernames and passwords etc.
The default rights users have to their user object are as follows:
- protocom-SSO-Auth-Data RW
- protocom-SSO-Entries RW
- protocom-SSO-Entries-Checksum RW
- protocom-SSO-Profile RW
- protocom-SSO-Security-Prefs RW
- protocom-SSO-Security-Prefs-Checksum RW
For centralized administration and management of the product, users must be able to read (but not write) SSO data, such as SSO enabled applications, corporate password policies and corporate preferences, defined at the corporate level (e.g. against Organization and Organizational Unit objects such as OU=Users,DC=New York,DC=ACME,DC=COM).
To assign rights, you will be prompted to define a context where you would like the user object rights to be updated from (e.g. CN=Users,DC=protocom,DC=com), allowing them access to their own SSO credentials. They will then be added automatically.
The default rights users have to O and OUs are as follows:
- protocom-SSO-Entries R
- protocom-SSO-Entries-Checksum R
- protocom-SSO-Profile R
- protocom-SSO-Security-Prefs R
- protocom-SSO-Security-Prefs-Checksum R
Note: protocom-SSO-Auth-Data only applies to user objects as it stores user specific data such as the passphrase.