SCIM Connector Best Practices for Integration with Secret Server

This section provides best practices regarding configuring SCIM for use with Secret Server.

Broad SCIM Implementation Considerations

  • Secret Server does not delete users to maintain audit trails. As a result, when you delete a user with a SCIM call, it disables the user. The disabled user can’t be granted access to a container, privileged data, or group unless they are enabled again.

  • Secret Server throws an error if instructed to delete an already deleted user. Disabling (deleting) already disabled users (by ID) will result in the SCIM Connector reporting a 404 error in the logs.

  • The process for provisioning local user accounts versus adding AD accounts to Secret Server via SCIM may look extremely different based on each vendor. If you do plan to leverage local accounts in Secret Server, it is recommended in your SCIM provider to auto-create passwords that align with the local user password policy configured within Secret Server. Otherwise, you may get an error when generating a new account through SCIM that does not conform to the Secret Server Local User password requirements. This can be found in Admin > Configuration > Local User Passwords. The following is a screenshot of the local user password requirement that will clear our security hardening report.

    alt

  • Some SCIM providers when creating an application define an “Owner” of that application. This owner may be leveraged for approvals of some requests within the SCIM Server. It is important to think about whom you want theApplication owners to be. This often may be aligned with Secret Server SMEsbut may also be aligned with “approvers” that you use within Secret Server for Request Access for Approval workflows.

  • Careful consideration should be made when determining who should have access to the “SCIM Connector Secret” that is stored within Secret Server long term. Those who are Administering the SCIM Connector should have access to this Secret, but likely no other users except for possibly a Secret Server SME/Admin. This is because this Secret Contains legitimate account information for an API user within Secret Server. It is recommended to combine this Secret with a Request For Access workflow process for any additional users that may request access to this Secret outside of your initially defined list of users.

    alt

  • It is recommended to track where within your environment your SCIM API user account is being leveraged so that you can ensure that the account does not have access to secrets or folders that you do not want it to have access to. Since the account has privileged access within Secret Server, this is important. You may even want to align specific event subscriptions within Secret Server to track the activity of SCIM. Several reports are generated when using SCIM to help track this type of activity as well which can be sent to specific people on a schedule. The following is a list of the built-in reports that are generated and can be used:

  • SCIM All Users

  • SCIM All Groups

  • SCIM All User Groups

  • SCIM All Folders

  • SCIM All Folder Permissions

  • SCIM All Secrets

  • SCIM All Secrets Permissions

  • It is important to be mindful of this setting under Admin > Configuration > Folders.

    alt

    If this is set to Yes, which is a best practice within Secret Server, you will need to be careful when breaking inheritance to assign permissions to a user to a subfolder from your SCIM provider. If for example they are assigned View access to a subfolder but not the parent folder, then they may not be able to go to the folder that they have been provisioned access to. If this setting is unchecked, they can view the folder structure andaccess the specific subfolder they’ve been regardless of parent folder level access.