立即与支持人员聊天
与支持团队交流

One Identity Management Console for Unix 2.5.3 - Administration Guide

One Identity Privileged Access Suite for Unix Introducing One Identity Management Console for Unix Installing Management Console for Unix Preparing Unix hosts Working with host systems Managing local groups Managing local users Active Directory integration Authentication Services integration Privilege Manager integration Reporting Setting preferences Security Troubleshooting tips
Auto profiling issues Active Directory Issues Auditing and compliance Cannot create a service connection point Check Authentication Services agent status commands not available CSV or PDF reports do not open Database port number is already in use Elevation is not working Hosts do not display Import file lists fakepath Information does not display in the console License information in report is not accurate Out of memory error Post install configuration fails on Unix or Mac Privilege Manager feature issues Profile task never completes questusr account was deleted Readiness check failed Recovering from a failed upgrade Reports are slow Reset the supervisor password Running on a Windows 2008 R2 domain controller Service account login fails Setting custom configuration settings Single Sign-on (SSO) issues JVM memory tuning suggestions Start/stop/restart Management Console for Unix service Toolbar buttons are not enabled UID or GID conflicts
System maintenance Command line utilities Web services Database maintenance

Changing allowed ciphers

The cipher suites used by Jetty SSL are provided by the JVM. See Java Cryptography Architecture Oracle Providers Documentation.

The ciphers are used in preference order. If a vulnerability is discovered in a cipher (or if it is considered too weak to use), it is possible to include or exclude it in the Jetty configuration without the need to update the JVM.

For more information, see Disabling/Enabling Specific Cipher Suites. The jetty.server.dumpAfterStart property, described at the end of that topic is a useful aid for diagnosing Jetty configuration in general and SSL/TLS configuration in particular.

Active Directory

Note: When you are logged on as an Active Directory user, you can access information about Active Directory users, groups and computers. See Active Directory configuration for details.

This information is protected by using your credentials to securely connect to Active Directory using the GSS/SASL security layer for the LDAP protocol. Only the information that is visible to the Active Directory account to which you are logged on is available. While some of this information may be cached on the server, it is only available to the user that originally requested it, ensuring that the access control rules for Active Directory objects are honored by the Management Console for Unix server.

The mangement console may request Active Directory credentials when you perform tasks, such as the Check for AD Readiness or when you configure the Active Directory settings for a host. In this case, the credentials are not stored on the server, but are only used for the selected task.

Managed Unix Hosts

Secure access to the managed Unix hosts is performed using the SSH protocol. Management Console for Unix uses SSH internally to profile hosts, manage users and groups, and run Readiness Check Results reports.

While the SSH protocol encrypts traffic and can use passwords to authenticate users, it uses public key cryptography to authenticate the server. If the server is not correctly authenticated, it is possible for an attacker to act as a 'man-in-the-middle' and obtain the user's logon and root passwords for a host. For this reason, it is important to understand how the options to manage SSH host keys affect the security of your Management Console for Unix installation.

Managing SSH host keys

Management Console for Unix uses SSH as the network protocol to provide secure remote access and administration of Unix hosts. It maintains a list of valid SSH host keys used to authenticate the connections.

The mangement console allows you to directly import these keys, using one of the following methods:

  • By using the Import SSH Host Keys button to upload a new public SSH key for a selected host.

    When you use this command you are prompted to accept the new fingerprint for the selected host.

  • By supplying an OpenSSH known_hosts file when using the Import option on the Add Hosts dialog.

    The known_hostfile contains the host addresses and public key data for known server hosts.

Note: See Known_hosts file format for more information about the supported known_hosts file format.

Alternatively, when profiling a host, new SSH keys are automatically accepted for the selected host by default. However, you can clear the Automatically accept SSH keys option on the Profile Hosts dialog if you want to be prompted to validate the host's SSH key if a key is not already cached for the selected host. If you clear this option, you must accept a host's fingerprint in order to proceed with the profiling process.

Note: While the Automatically accept SSH keys option is enabled by default, clearing this option disables it for subsequent profiles for this user. Regardless of whether the Automatically accept SSH keys option is selected or not, when a modified key is encountered, the profile task will prompt you to accept the new changed keys.

You can view the SSH fingerprint and algorithm used to access a host on the Details tab of a host's properties.

Note: While the Management Console for Unix server automatically accepts SSH host keys by default, to avoid potential "man-in-the-middle" attacks, One Identity recommends that you either disable this option so that you can manually review and accept the key fingerprints, or directly import the keys by using one of the methods described above. This ensures that your SSH connection is secured to a trusted host before supplying your log on or root credentials.

相关文档

The document was helpful.

选择评级

I easily found the information I needed.

选择评级