ISAM introduced the concept of non-imported users which we named Basic users, or lite users depending on who you ask, back in 2014 with version 8.0.0.4. I still regularly receive a bunch of questions as to what this means from an architectural perspective, and most importantly, what are the advantages and disadvantages to this new deployment option.
Traditional ISAM LDAP Deployments
Traditionally, ISAM always required the users and groups that can be authenticated against ISAM be ‘imported’ into the ISAM registry. This created an additional step in an ISAM deployment for every user that an organisation wanted to use with ISAM. Furthermore, ISAM historically would only talk to a single LDAP server at any given time.
Whilst we now have much more flexibility in this space, this deployment pattern is still perfectly fine! Its still well and truly the most common deployment pattern, so I won’t go into any detail about this deployment. The only major caveat with this pattern, is that we no longer support AD as the primary/single LDAP with the ISAM appliances, as we have moved away from making AD schema changes to support the ISAM metadata.
Federated Directory Users
Starting with version 8.0 of ISAM, it was possible to configure ISAM to talk to multiple LDAP servers at once. This is known as Federated directory support in ISAM, and Federated Users. (This is a somewhat overloaded term, since we might also use this when dealing with Cross Domain Federated users from SAML etc.)
Configuration is performed at the ISAM/Policy Server runtime level, where we specify the directories we wish to ‘federate’ in.
Once configured, the user can be imported into the ISAM space, much the same as a user in the single LDAP repository, and the full suffix is used to define it’s location in a given LDAP directory.
- Federation removes the need to modify the federated registry’s schema.
- No ISAM meta-data is stored in the federated registry.
- Registry ACLs are not automatically set in the federated registry.
- An identity is required by ISAM to access the federated registry. It’s privileges depend on the ISAM functions required (read group memberships, password reset, user create, …).
- Supported LDAP server types are the same as ISAM supports for it’s Primary registry, plus Microsoft Active Directory.
This feature is most commonly used when we are talking to Active Directory, since there is no requirement to modify the schema.
Here is a good technote on configuring federated directories:
http://www-01.ibm.com/support/docview.wss?uid=swg21694502
Onboard LDAP or external LDAP for the ISAM primary LDAP
Since ISAM has become an appliance, we host an onboard LDAP server for ease of deployment. The onboard LDAP isn’t typically recommended for production deployments however, since we don’t expose a number of maintenance capabilities for backup and the deployment patterns we generally recommend, is to host an LDAP server in a separate data tier, particularly for scalability beyond a somewhat small ~10,000+ LDAP objects. When using federated directories, we would still be importing/creating a number of LDAP objects for the ISAM metadata in the primary LDAP, such that in any sizeable deployment, we would still recommend an external LDAP registry.
Fortunately, the IBM Security Directory Server ships as an appliance in its latest release, so it shouldn’t be hard to host and deploy an ISDS Instance nearby to your ISAM deployment.
ISAM Basic Users (aka Lite Users)
Starting with version 8.0.0.4 of ISAM, it is now possible to use users in a federated directory, without importing the user and creating their meta data.
The knowledge center has fairly good detail on configuring this and points out a few limitations:
The following limitations apply to basic users:
- Basic users work in minimal registry mode only.
(Phils Note: this has been the default since v6.1, so not likely to be an issue.) - Basic users cannot use global sign-on.
- You cannot set access control lists for individual basic users. However, basic users can be members of a Security Access Manager group with access control lists.
- Registry direct Java API does not fully support all operations with basic users.
- Account and password valid settings are set to yes. You cannot modify them for basic users.Warning: Basic users are not subject to any Security Access Manager account and password policies. They always have their account-valid and password-valid values set to yes. Basic users do not record the last login or last password change even if [ldap] enable-last-login is set. You must use the underlying registry equivalents for these capabilities.
Essentially, the pattern is very similar to “federated directories” using full ISAM users, except that there is NO user information stored by ISAM in its own repository, and only group information is handled by the ISAM LDAP where the group is intended to be used by an ACL.
Use Case:
If a person is a member of GroupA, and we wish to allow members of groupA into a particular resource, we need to “tamify” groupA, such that we can then author an ACL which names GroupA in it’s access parameters. But there is no requirement to explicitly call out the person to ISAM when Basic Users are configured.
Onboard LDAP or external LDAP for the ISAM primary LDAP
Using the the onboard LDAP becomes more practical when deploying with basic users, since the capacity of the onboard LDAP need only support the admin accounts (sec_master etc.) and the metadata for ISAM imported groups.
And the ability to stand up a new appliance with replicated configuration, becomes simpler since there is little to no user information stored in the LDAP onboard.
The data that was traditionally handled by ISAM metadata, now becomes the responsibility of the LDAP registry. For example last login time, failed login counts and password complexity policies are no longer stored for the user by ISAM, but relies on the Federated LDAP server to store this.
Philip Nye 