The document IdentityIQ Secure Deployment Guide contains a recommendation to replace the spadmin account with an alternative, non-default, administrator account. The spadmin account will still exist, but should no longer be used and its password should be stored in a safe place for emergency situations.
There are multiple ways to achieve this.
A simple way to create an alternative administrator-account is by adding an identity using an XML document, similar to the standard spadmin-account. It must have a different name and id, or the id must be left empty. It must have the SystemAdministrator capability. To prevent accidental deletion it could be marked as protected. The password can be encrypted using the console, or left empty and filled in later through the user interface.
As an example, one could use the following XML:
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE Identity PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<Identity name="altadmin" password="2:7ShTsZ++2jXLeI857XPMSAQO0Eec3V9eSHaQwFHsNR4=" protected="true">
<Attributes>
<Map>
<entry key="displayName" value="Alternative Administrator"/>
<entry key="email"/>
<entry key="firstname" value="Alternative"/>
<entry key="lastname" value="Administrator"/>
</Map>
</Attributes>
<Capabilities>
<Reference class="sailpoint.object.Capability" name="SystemAdministrator"/>
</Capabilities>
</Identity>
Another, more flexible option is to create a workgroup in IdentityIQ and assign the SystemAdministrator capability to that workgroup. Then all the identities that need the SystemAdministrator capability can be added to the workgroup as members.
Members of the workgroup will inherit the capabilities assigned to the workgroup.
Yet another option to create alternative administrative accounts is by using roles. By default, none of the available role types can be used to assign capabilities. All out of the box role types have the option "Disallow Granting of IdentityIQ User Rights" enabled. In order to enable assignment of capabilities using role this option must be disabled, either on an existing role type (most likely Entitlement or IT) or a new custom role type.
Once you have configured a role type with the option to grant IdentityIQ capabilities, you can create a new role that grants SystemAdministrator rights to those identities to whom the role has been assigned.
Such a role can be used in standard access request processes or can even be assigned automatically based on for example a job title.
Great menno.pieters! Thanks.
Hi menno.pieters,
As spadmin is the default IIQ administrator, many workitems are automatically generated for this user.
Would it be enough, in an OOTB IIQ installation, to set the new admin (or admin workgroup) as the fallback approver in the following workflows:
LCM Provisioning
LCM Create and Update
LCM Registration
LCM Manage Passwords
Thanks,
Charlie
That would definitely help. You may also consider setting the alternative admins (workgroup) as the forwarding user for spadmin.
- Menno
Hi menno.pieters,
Modifying the default password to the spadmin would definitely help. To make the installation more secure though, wouldn't it be a good idea to also remove the "System Administrator" capability to the spadmin, after setting the new administrator (workgroup) as its forwarding user? Or does IIQ rely on spadmin to have System Administrator capability to perform some of its activities?
Charlie
Hi charlie.vattani,
That is an excellent question and idea... I have not tried that, yet, but it definitely makes sense. As far as I know most non-interactive tasks/actions are performed by the SYSTEM user, so it will not affect those. Some items may become more difficult to access as most objects are, by default, owned by spadmin. I guess it's worth trying in a sandbox environment.
- Menno
One thing we did in our installation was to set up a forward from spadmin to an administrative workgroup. This ensured that any work items sent to SPADMIN would not disappear into an account no one ever logs into.
Hi @charlie.vattini,
I have the same question when I come across your question
Can you share whether the removal of the System Administrator rights of the spadmin was successful?
BR,
Pascal
Do we have an impact when we disable a user and he is owner many items?
Your "leaver" functionality should include logic to reassign ownership of objects owned by people whose identities are now disabled. Or you should consider using workgroups as owners and just validating that someone in still in any workgroups the disabled users are removed from.
In my case the identity is spadmin, and all my app owners, role owners are spadmin. So we dont want to change chane the ownership. and woul dlike to enable when needed.
So do we have any impact on it?