cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Alternative administrator accounts

Alternative administrator accounts

 

Introduction

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.

 

Alternative account

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>

 

Workgroup

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.

Edit_Workgroup.png

Members of the workgroup will inherit the capabilities assigned to the workgroup.

 

Role

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.

Cursor_and_Edit_Role_Type_Definition.png

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.

Role_Editor.png

Such a role can be used in standard access request processes or can even be assigned automatically based on for example a job title.

Comments

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?

Version history
Revision #:
2 of 2
Last update:
‎Jul 27, 2023 10:09 PM
Updated by: