Integrating SailPoint with Oracle Solaris
Important
SailPoint has announced the deprecation of the Oracle Solaris SailPoint connector. For more information, refer to Oracle Solaris Connector Deprecation Announcement on SailPoint. Effective January 1, 2025, the Oracle Solaris Connector will enter its deprecation period.
- During this time, existing Oracle Solaris sources will continue functioning as expected, but no new enhancements, bug fixes, or support will be provided.
- Customers will not be able to create new sources in SailPoint for Oracle Solaris.
- The End-of-Life (EOL) date for the Oracle Solaris connector is January 1, 2026, at which point all existing sources utilizing this connector will cease to operate.
To learn more about SailPoint's deprecation and EOL policies, refer to SailPoint Support Policy for Connectivity.
This document is designed to give specific information about the requirements and field definitions needed to get a working instance of an Oracle Solaris source in SailPoint.
If you have user accounts in a Solaris source that you want to load into SailPoint, create a direct connect source for Solaris and load that data into your system. To manage that data, either create an identity profile based on the source or verify that the accounts you load are correlated to an existing identity.
Note
To view the latest features, enhancements, and fixes for all SaaS connectors, refer to the SaaS Release Notes page.
Supported Features
SailPoint's Oracle Solaris source supports the following features:
Source Features
- Load and *provision accounts
- *Password management
- *Access certifications (certification of entitlements connected to accounts)
- Aggregate the last login details
- Enhanced to prevent shell injection attacks
- Allows changes to the
disable.accountattribute value to use theusermod -s /bin/falsecommand to disable users - Supports MD5, SHA-1, and SHA-2 cryptographic hash functions
Note
Before you can use any item above marked with an asterisk (*), SailPoint must activate the feature for your site.
Password Management
If Password Management is enabled for your organization, you can change the password for a user of the source. After enabling password management on the source, be aware of the following:
- The password policy defined in SailPoint applies to accounts on this source.
- If you change the password for an application connected to this source, the change will automatically be made to the source itself.
For more information on configuring password management, refer to Password Management Overview.
Supported Managed Systems
SailPoint supports the following Solaris versions:
- Solaris 11.4 SPARC x86
Prerequisites
- Configure at least one virtual appliance cluster and successfully test the connection. For more information, refer to the Virtual Appliance Reference Guide.
- SSH should be installed on the Solaris computer.
- To use sudo users for SailPoint operation, ensure that the required packages for executing sudo commands are installed on the managed system.
-
Sudo users and permissions for the Solaris source:
- The admin user must have rights to execute the
/usr/bin/awkcommand. - You must update the
/etc/sudoersfile entry for the admin user with the/usr/bin/awkcommand. - The user and group schema must add a new multivalued schema attribute as
sudoCommandsthat collects all the necessary user commands and stores them as a part of the attribute. -
If you want to aggregate the sudo commands from multiple sudo files, you must provide the list of files as a separate configuration attribute in the source config.xml file.
For example:
-
The default command that collects the sudo commands is:
awk '/^[^#]/' /etc/sudoers. In this command, the commented lines are skipped and the remaining content of the/etc/sudoersfile is aggregated in a temporary file on the Solaris system.The temporary file on the Solaris system gets copied to the local SailPoint system and processes all the sudo user and group commands. If you want to use a custom command for aggregating file data, configure this command as part of the source config.xml file.
For example:
- The admin user must have rights to execute the
Required Permissions
You can use root user for managing your applications, however it is recommended to use a minimum permission user. For example, a sudo user for managing your applications.
If you want to use a sudo user to perform the operations, the sudo user must be configured with the following rights and permissions.
Rights to execute the following commands with root privilege:
/bin/chmod, /usr/sbin/useradd, /usr/sbin/usermod,/usr/sbin/userdel,
/usr/sbin/groupadd, /usr/sbin/groupmod, /usr/sbin/groupdel, /usr/bin/passwd,
/usr/bin/groups, /usr/bin/date, /bin/rm -f spt_tmp_*, /bin/echo,
/bin/cat /etc/shadow, /bin/cat /etc/passwd, /bin/cat /etc/group,
/bin/cat /etc/user_attr, /usr/bin/getent, /bin/grep -i * /etc/default/login,
/bin/grep -i * /etc/security/policy.conf, /usr/bin/finger, /usr/bin/dispuid, /usr/bin/awk
An entry in the /etc/sudoers file must look similar to the following:
username ALL = (root) PASSWD: /bin/chmod, /usr/sbin/useradd, /usr/sbin/usermod,
/usr/sbin/userdel, /usr/sbin/groupadd, /usr/sbin/groupmod, /usr/sbin/groupdel,
/usr/bin/passwd, /usr/bin/groups, /usr/bin/date, /bin/rm -f spt_tmp_*,
/bin/echo, /bin/cat /etc/shadow, /bin/cat /etc/passwd, /bin/cat /etc/group,
/bin/cat /etc/user_attr, /usr/bin/getent, /bin/grep -i * /etc/default/login,
/bin/grep -i * /etc/security/policy.conf, /usr/bin/finger, /usr/bin/dispuid, /usr/bin/awk
Note
- If any part of the command is modified in the source XML, then the respective changes in the
/etc/sudoersfile entry should also be performed. Verify command paths on the Solaris systems as they might differ from the values mentioned here. - If you want to use a sudo user to perform the provisioning operations, configure the home directory with proper write access for this sudo user. For example, if the sudo user is using the Guest home directory, then ensure it has proper write access over this directory.
Read Only Permissions
If you want to use a sudo user to perform read only operations, you must configure the sudo user with the following rights and permissions.
For Account Aggregation only
Rights to execute the following commands with root privilege:
/bin/echo, /bin/cat /etc/group, /bin/grep, /bin/rm -f spt_tmp_*, /bin/cat /etc/passwd,
/bin/cat /etc/shadow, /bin/cat /etc/user_attr, /usr/bin/date,
/bin/grep -i 'RETRIES=' /etc/default/login, /bin/grep -i 'Lock_After_Retries=' /etc/security/policy.conf
An entry in the /etc/sudoers file must look similar to the following:
username ALL = (root) PASSWD: /bin/echo, /bin/cat /etc/group, /bin/grep,
/bin/rm -f spt_tmp_*, /bin/cat /etc/passwd, /bin/cat /etc/shadow,
/bin/cat /etc/user_attr, /usr/bin/date, /bin/grep -i 'RETRIES=' /etc/default/login,
/bin/grep -i 'Lock_After_Retries=' /etc/security/policy.conf
For Entitlements Aggregation only
Rights to execute the following commands with root privilege:
An entry in the /etc/sudoers file must look similar to the following:
Documentation Feedback
Feedback is provided as an informational resource only and does not form part of SailPoint’s official product documentation. SailPoint does not warrant or make any guarantees about the feedback (including without limitation as to its accuracy, relevance, or reliability). All feedback is subject to the terms set forth at https://developer.sailpoint.com/discuss/tos.