Overview of Users in OES Linux

At its fundamental level, OES Linux provides file and print services and network-enabled application support to end users. These user-level services all require some method of locating a valid user account, and then authenticating the requested user to that account. When identity and permissions have been established, the service is started with the appropriate environment.

OES user accounts are all stored and managed within eDirectory. Not all applications and services, however, directly integrate or support eDirectory. To bring eDirectory functionality to as many applications as possible, OES Linux provides support for two primary methods of authentication:

• Native eDirectory

• LDAP

Native eDirectory

Native eDirectory-aware services are those services that understand the eDirectory Application Program Interface (API). Services that understand this API have the advantage of being able to directly communicate with eDirectory and leverage the many advanced features eDirectory has offered for years.

OES Linux offers several services that communicate directly to eDirectory through this API. Examples of this include iManager, Virtual Office, iFolder, the Novell Client, and many others. Through direct API communication with eDirectory, these services can leverage such things as advanced authentication mechanisms and complex permission structures offered on NSS volumes.

LDAP

Services that do not leverage the eDirectory API can still take advantage of eDirectory for user storage and account management. To accomplish this, services rely on an industry standard known as Lightweight Directory Access Protocol (LDAP).

LDAP is a protocol used to communicate with directories containing some form of information. In the case of eDirectory, the information being requested is quite often user account details. OES Linux installations with eDirectory automatically support LDAP connections for this purpose. LDAP-aware services can be configured to take advantage of this through the use of an LDAP connection to eDirectory. This connection is then used to locate and authenticate user accounts prior to the service being initiated.

OES Linux relies on this LDAP functionality for a number of important Linux services. One example of this is Samba. The Samba software suite provides Linux resources to Windows users as though the Linux server were actually running Windows. This functionality requires Windows users to authenticate to the Linux server just as they would with any other Windows machine. Traditionally, Samba stores users in a local file, unique to Samba. With OES Linux, Samba is configured to use LDAP to locate eDirectory users who are allowed access to Samba resources.

Another example of this situation is the integration of Pluggable Authentication Module (PAM) enabled services into eDirectory. As with Samba, eDirectory user objects are modified with OES to provide local Linux authentication to any PAM-aware service via LDAP and eDirectory. This is provided through the Linux User Management component of OES. Services that can use this functionality include such things as SSH, FTP, and local Linux logins.

It is important to understand that for these services that do not natively support eDirectory, the following three conditions must be met in order to support LDAP storage and authentication of accounts:

• eDirectory with LDAP enabled By default, OES Linux configures eDirectory with LDAP support. This can be disabled, but additional configuration within eDirectory is not normally required.

• LDAP-aware service Services that want to store accounts within eDirectory must be modified to support LDAP communication to a directory server. Most common services providing access to users already support this. (For specific configuration information, refer to the service or application documentation.)

• Valid service account in eDirectory User accounts within eDirectory may not natively be valid accounts in an LDAP-aware service. In the case of Samba, eDirectory users must be modified to contain the required attributes of a Samba user. These modifications are performed via schema extensions as part of an OES Linux installation. Custom third-party applications may require additional schema modifications.

NOTE

More information on schema extensions required with supported LDAP-aware applications can be found in the "Provisioning Linux Users" section of this chapter.

When using LDAP-aware services, security enforcement is primarily handled by the respective service itself (Samba, FTP, SSH, and so on). eDirectory is still used to enforce user password requirements, account expirations, and other important abilities. However, advanced features such as eDirectory rights enforcement may not be available.

This does not mean that these services are insecure! On the contrary, integration with eDirectory actually provides another level of security to these applications. However, when given the choice between one access method versus another, you would be well advised to base your decision, at least in part, on the security of the access methods involved.

NOTE

The majority of this chapter will focus on eDirectory authentication and security. Following this, the "Provisioning Linux Users" section will fill in details regarding LUM and Samba.