Oracle Solaris 11.3 LDAP目录服务深度探索

需积分: 5 92 浏览量更新于2024-06-24 收藏 678KB PDF 举报

"Oracle Solaris 11.3 Working With Oracle Solaris 11.3 Directory and Naming Services: LDAP" 本文档详细介绍了如何在Oracle Solaris 11.3操作系统环境中与Oracle Solaris 11.3目录和命名服务进行交互，特别是关于Lightweight Directory Access Protocol (LDAP) 的使用。Oracle Solaris 11.3 是一个功能强大的企业级操作系统，它包含了先进的网络和系统管理特性，而LDAP是其核心组件之一，用于管理和存储组织的目录信息。在Oracle Solaris 11.3中，LDAP作为一个中央化的数据库，可以存储用户账户、组、网络设备配置、安全策略等大量信息。这种集中式的管理方式提高了系统的可管理性和安全性。本文档将帮助管理员了解如何配置和操作LDAP服务器，包括安装、配置、备份和恢复，以及日常的维护工作。文档可能会涵盖以下关键知识点： 1. **LDAP基础**：解释了LDAP的概念，包括其架构、数据模型和查询语言（如LDAP过滤器）。 2. **Oracle Solaris LDAP集成**：描述了Oracle Solaris操作系统如何与LDAP服务集成，以及系统中的哪些服务和功能依赖于LDAP。 3. **设置LDAP服务器**：指导如何在Oracle Solaris 11.3环境中安装和配置LDAP服务器，包括创建目录树、导入和导出数据。 4. **用户和组管理**：说明如何使用LDAP管理用户账户、组和其他身份信息，包括创建、修改和删除账户。 5. **安全性与访问控制**：讨论如何配置权限和访问控制列表（ACLs），确保只有授权的用户或服务能访问目录信息。 6. **备份与恢复**：介绍如何备份LDAP数据库以防止数据丢失，并学习如何在必要时恢复数据。 7. **故障排查与性能优化**：提供诊断和解决LDAP服务问题的技巧，以及如何监控和优化LDAP服务器的性能。 8. **与其他系统的集成**：可能还会涉及如何将Oracle Solaris 11.3 LDAP服务与其它系统（如Windows、Linux或其他Unix变种）集成。 9. **案例研究与最佳实践**：通过实际场景展示如何应用这些知识，同时分享最佳实践以提高效率和稳定性。请注意，由于本文档是Oracle的版权作品，使用、复制、修改或分发需要遵守Oracle提供的许可证协议条款，未经授权的逆向工程、拆解或反编译是被禁止的。对于美国政府或代表美国政府的任何一方，该软件或相关文档可能适用特定的通知和限制条件。这份文档对于那些需要管理和维护使用Oracle Solaris 11.3 LDAP服务的IT专业人士来说是一份宝贵的参考资料，提供了全面的操作指南和深入的技术细节。

LDAP Naming Service Security Model

The basis for user authentication differs depending on the PAM module. LDAP can use the

following PAM modules:

■

pam_krb5 module – Uses the Kerberos server for authentication. For more information, see

the pam_krb5(5) man page. For a more extensive description about Kerberos, see Managing

Kerberos and Other Authentication Services in Oracle Solaris 11.3.

■

pam_ldap module – Uses the LDAP server and local host server for authentication. For

more information, see the pam_ldap(5) man page. For information about using the pam_ldap

module, see “LDAP Account Management” on page 27.

■

Equivalent pam_unix_* modules – Information is provided by the system and the

authentication is determined locally.

Note - The pam_unix module is no longer supported in Oracle Solaris. This module has been

replaced by a different set of service modules that provides equivalent or greater functionality.

In this book, pam_unix refers to the modules that provide equivalent functionality, not to the

pam_unix module.

If the pam_ldap module is used, the naming service and the authentication service access the

directory in the following ways:

■

The naming service reads various entries and their attributes from the directory based on

predefined identity.

■

The authentication service authenticates a user’s name and password with the LDAP server

to determine whether the correct password has been specified.

You can use Kerberos and LDAP at the same time to provide both authentication and naming

services to the network. With Kerberos, you can support a single sign-on (SSO) environment in

the enterprise. You can use the Kerberos identity system for querying LDAP naming data on a

per-user or per-host basis.

If you use Kerberos to perform authentication, enable LDAP naming services as a requirement

of the per-user mode. Kerberos can provide dual functions: It authenticates to the LDAP server

and the Kerberos identity for the user or host is used to authenticate to the directory. In this way,

the same user identity that is used to authenticate to the system is also used to authenticate to

the directory for lookups and updates. If required, you can use ACI in the directory to limit the

results out of the naming service.

Transport Layer Security

You can use Transport Layer Security (TLS) to secure communication between an LDAP client

and the directory server and hence ensure both privacy and data integrity. The TLS protocol is a

16 Working With Oracle Solaris 11.3 Directory and Naming Services: LDAP • September 2018

Client Credential Levels

superset of the Secure Sockets Layer (SSL) protocol. The LDAP naming service supports TLS

connections. However, using SSL adds load to the directory server and the client.

The requirements to use TLS are as follows:

■

Configure the directory server and LDAP clients for SSL.

To configure ODSEE for SSL, see the administration guide for the version of ODSEE

that you are using. For example, see Administrator’s Guide for Oracle Directory Server

Enterprise Edition.

■

Install the following necessary security databases, specifically the certificate and key

database files.

■

If you use an older database format from Netscape Communicator, install cert7.db and

key3.db.

■

If you use a new database format from Mozilla, install cert8.db, key3.db, and secmod.

db.

The cert* files contain trusted certificates. The key3.db file contains the client’s keys. You

must install the key3.db file even if the LDAP naming service client does not use client

keys. The secmod.db file contains security modules such as the PKCS#11 module.

For information about setting up TLS security, see “Setting Up TLS Security” on page 74.

Client Credential Levels

The LDAP server authenticates LDAP clients according to the client credential level. You can

assign any one of the following credential levels for LDAP clients:

■

anonymous – With an anonymous credential level, you can access only the data that is

available to everyone. No LDAP BIND operation occurs. An anonymous credential level

is a high security risk. Any client can change information in the DIT to which the client

has write access, including another user’s password or their own identity. Further, the

anonymous level enables all clients to have read access to all LDAP naming entries and

attributes.

Note - ODSEE enables you to implement security measures by restricting access based on

IP addresses, DNS name, authentication method, and time-of-day. For more information,

see "Managing Access Control" in the Administration Guide for the version of ODSEE that

you are using.

■

proxy – With a proxy credential level, the client binds to a single shared set of LDAP

bind credentials. The shared set is also called a proxy account. The proxy account can be

Chapter 2 • LDAP and Authentication Service 17

Client Credential Levels

any entry that is allowed to bind to the directory. The account requires sufficient access to

perform the naming service functions on the LDAP server.

The proxy account is a shared-per-system resource, which means that users, including the

root user, who are logged into a system using proxy access see the same information. You

must configure the proxyDN and proxyPassword attributes on every client system that uses

the proxy credential level. Further, the proxyDN must have the same proxyPassword on all

of the LDAP servers.

The encrypted proxyPassword is stored locally on the client. If the password changes for a

proxy user, you must update the password on every client system that uses that proxy user.

Also, if you use password aging on LDAP accounts, make sure to exempt proxy users.

You can set up different proxies for different groups of clients. For example, you can

configure a proxy that limits all the sales clients to access only the company-wide accessible

directories and sales directories. Access to Human Resource directories with payroll

information are forbidden. Or, in the most extreme cases, you can either assign different

proxies to each client or assign just one proxy to all clients.

If you plan to set up multiple proxies for different clients, consider the choices carefully.

Too few proxy agents can limit your ability to control user access to resources. However,

too many proxies complicate the setup and maintenance of the system. You need to

grant the appropriate rights to the proxy user depending on your environment. For more

information about how to determine which authentication method to use, see “Storing

Credential for LDAP Clients” on page 19.

The proxy credential level applies to all users and processes on any specific system. Users

that need to use different naming policies must log in to different systems, or use the per-

user authentication model.

■

proxy anonymous – The proxy anonymous credential level is a multi-valued entry where

more than one credential level is defined. With this level, a client first attempts to be

authenticated by using its proxy identity. If the authentication fails because of user lockout

or expired password, then the client uses anonymous access. Depending on how the

directory is configured, different credential levels might be associated with different levels

of service.

■

self – The self credential level is also known as the per-user mode. This mode uses the

Kerberos identity, called the principal, to perform a lookup for each system or user for

authentication. With per-user authentication, the system administrator can use access control

instructions (ACIs), access control lists (ACLs), roles, groups or other directory access

control mechanisms to grant or deny access to specific naming-service data for specific

users or systems.

To use the per-user authentication model, the following configurations are required:

■

Deployment of the Kerberos single sign-on service

■

Support for the SASL and the SASL/GSSAPI authentication mechanism in one or more

directory servers

18 Working With Oracle Solaris 11.3 Directory and Naming Services: LDAP • September 2018

Client Credential Levels

■

Configuration of DNS, which Kerberos uses together with files to perform host name

lookups

■

Enabling of the nscd daemon

Enabling Shadow Data Updates

If the enableShadowUpdate switch is set to true on the client, administrator credentials

are used to update the shadow data. Shadow data is stored in the shadowAccount object

class on the directory server. Administrator credentials are defined by the values of the

adminDN and adminPassword attributes, as described in “Defining LDAP Local Client

Attributes” on page 67.

Administrator credentials have properties similar to proxy credentials. However, for

administrator credentials, the user must have all privileges for the zone or have an effective UID

of root to read or update the shadow data.

You can assign administrator credentials to any entry that is allowed to bind to the directory.

However, do not use the same directory manager identity (cn=Directory Manager) of the

LDAP server.

An entry with administrator credentials must have sufficient access to read and write the

shadow data to the directory. The entry is a shared-per-system resource. Therefore, you must

configure the adminDN and adminPassword attributes on every client.

The encrypted adminPassword is stored locally on the client. The admin password uses the

same authentication methods that are configured for the client. All users and processes on a

specific system uses the administrator credentials to read and update the shadow data.

Storing Credential for LDAP Clients

In the LDAP implementation, proxy credentials that are set during initialization are stored in the

SMF repository instead of a client’s profile. This implementation improves security surrounding

a proxy’s distinguished name (DN) and password information.

The SMF repository is svc:/network/ldap/client. It stores proxy information of clients that

use a proxy identity. Likewise, shadow data updates of clients whose credential level is not self

are also saved to this repository.

For clients that use per-user authentication, the Kerberos identity and Kerberos ticket

information for each principal is used during authentication. The directory server maps the

Chapter 2 • LDAP and Authentication Service 19

Authentication Methods for the LDAP Naming Service

Kerberos principal to a DN and the Kerberos credentials are used to authenticate to that DN.

The directory server can use its ACI mechanisms to allow or deny access to naming service data

as necessary.

In this environment, Kerberos ticket information is used to authenticate to the directory server.

The system does not store authentication DNs or passwords. Therefore, setting the adminDN and

adminPassword attributes is unnecessary when you initialize the client with the ldapclient

command.

Authentication Methods for the LDAP Naming Service

When you assign the proxy or proxy-anonymous credential level to a client, you must also

select a method by which the proxy is authenticated. By default, the authentication method

is none, which implies anonymous access. The authentication method might also have an

associated transport security option.

The authentication method, like the credential level, can be multi-valued. For example, in the

client profile, you can specify that the client tries to bind by using the simple method that

is secured by TLS. If unsuccessful, the client would try to bind with the sasl/digest-MD5

method. In this case, you would configure the authenticationMethod attribute as tls:simple;

sasl/digest-MD5.

LDAP naming service supports some Simple Authentication and Security Layer (SASL)

mechanisms. These mechanisms enable a secure password exchange without requiring TLS.

However, these mechanisms do not provide data integrity or privacy. For information about

SASL, see RFC 4422.

Note - Do not use the CRAM-MD5 and DIGEST-MD5 mechanisms without an encrypted TLS

connection.

LDAP supports the following authentication mechanisms:

■

none – The client does not authenticate to the directory. This method is equivalent to the

anonymous credential level.

■

simple – The client system sends the user’s password in the clear to bind to the LDAP

server. The password is subject to snooping unless the session is protected by IPsec. This

method is easy to set up and all directory servers support it.

■

sasl/cram-MD5 – The LDAP session is not encrypted but the client’s password is protected

during authentication. Do not use this obsolete authentication method.

20 Working With Oracle Solaris 11.3 Directory and Naming Services: LDAP • September 2018

剩余143页未读，继续阅读

weixin_40191861_zj

粉丝: 83
资源: 1万+

Oracle Solaris 11.3 LDAP目录服务深度探索

Oracle Solaris 11.3 Working With Oracle Solaris 11.3 Directory

Oracle Solaris 11.3 Configuring an Oracle Solaris 11.3 System a

Oracle Solaris 11.3 Resource Management and Oracle Solaris Zones

Oracle Solaris 11.3 Working With DHCP in Oracle Solaris 11.3-44

Oracle Solaris 11.3 Creating a Custom Oracle Solaris 11.3 Insta

Oracle Solaris 11.3 Introduction to Oracle Solaris 11.3 Network

Oracle Solaris 11.3 Installing Oracle Solaris 11.3 Systems-300

Oracle Solaris 11.3 Introduction to Oracle Solaris 11.3 Adminis

Oracle Solaris 11.3 Managing Auditing in Oracle Solaris 11.3-16

Oracle Solaris 11.3 Managing Devices in Oracle Solaris 11.3-282

最新资源