Because of the prominent role played by the proxy users on your OES network, it is important that you understand your implementation options and the implications for each option. You can then plan an overall proxy user implementation strategy.
The first step in planning your proxy user implementation strategy is understanding the do’s and don’ts of proxy user creation.
Table I-2 presents information about the creation options for each OES proxy user.
Table I-5 Proxy User Creation Options
Best practices for most OES installation scenarios dictate that proxy users be created in eDirectory prior to installing OES. For more information, see Limiting the Number of Proxy Users in Your Tree.
After creation, proxy users should be configured for OES service use only by the YaST based install, not manually.
The information in these sections only answers security questions and provides general information. It is not intended to be used for the manual configuration of proxy users.
We recommend using special-purpose proxy user accounts rather than specifying admin users as proxy users.
Although specifying an admin user as the proxy user appears to be an easy way of setting up OES services (and is the install default in some cases), there are potential problems. Mixing actual users with system-level functionality always creates some risk.
The following is a real-life example of risks that can occur when admin users are assigned as proxy users:
Novell Support received a call from an administrator who was getting locked out due to intruder detection after changing the administrator password. The lockout happened several times each day and seemed to be coming from the OES 2 servers. The support technician checked LUM and all of the services he could think of, and didn’t see the admin credentials anywhere.
Further investigation revealed that the administrator credentials had been used to install OES 2 on multiple servers, and by default the credentials were therefore also used as the proxy user credentials for some of the OES services. Consequently, the credentials were stored in CASA for use when the OES services came up.
Because the Admin password had changed, the CASA credentials had expired and service authentication requests were failing, resulting in the intruder detection lockout.
From a licensing standpoint, each proxy user counts as a user on the OES network and consumes one user connection license.
It is not unreasonable to expect that the OES servers you install could average five to six proxy users a piece, meaning that an organization that has three to five OES servers installed with the default settings, can expect that 15 to 30 of its user connection licenses might be taken by proxy users.
For large organizations with hundreds of servers, the user connections consumed by default installations would be substantial. Therefore, large organizations are especially interested in methods for limiting the number of proxy users on their network.
Table I-6 outlines various options for limiting the number of proxy users in your tree and summarizes the licensing, security, and manageability considerations of each approach.
Table I-6 Options for Limiting the Number of Proxy Users
|
Approach |
Licensing Impact |
Security Considerations |
Manageability Considerations |
|---|---|---|---|
|
Per Service per Server (default) |
One for each service on each server |
For AFP, CIFS, iFolder 3, NSS, and Samba this is the most secure option. Passwords for these are system-generated and not known by anyone. For LUM there is no option to have a system-generated password. For DNS, DHCP, and NetStorage, the install admin’s credentials are used by default. This has separate security implications as outlined in Avoid Assigning an Admin User As a Proxy User. |
This approach requires no proxy user planning. Services are installed at the same time as the OES server. This is a good option for small organizations or installations where only a few services are used. This is not a good option if security policies dictate that all passwords must be reset periodically. |
|
Per Server |
One for each server |
This confines any security vulnerabilities to individual servers. |
This requires that a proxy user for the server is created before the server is installed. For the first server in the tree, eDirectory and iManager must be installed with the server. Then after the server installation finishes, the proxy user can be created. And finally the services can be installed and configured to use the proxy user for the server. This is not generally recommended. However, it can be useful when each OES server is managed by a separate administrator, or for enterprises where branch users access a server in the branch office. The install admin must know the proxy user’s password. |
|
Per Partition |
One for each partition |
This confines any security vulnerabilities to individual partitions. |
This is useful when users are co-located with the OES servers in a single partition, and cross-partition access of users to services is rare. This is a good approach for organizations where eDirectory administration is done at a partition level. This requires that a proxy user for the partition is created before services are installed in the partition. The install admin must know the proxy user’s password. |
|
Per Service |
Up to nine licenses depending on the number of OES services deployed |
This confines any security vulnerabilities to individual services. It also ensures that proxy user rights are not overloaded but are distributed so that there is a single proxy user for each type of service |
For example, you might have one proxy user for file-access (AFP, CIFS), one for DNS/DHCP, one for iFolder, one for iPrint etc. This is useful in trees where the users and servers are not co-located, and different services are administered by different administrators. This requires that a proxy user for the service is created before the service is installed in the tree. The install admin must know the proxy user’s password. |
|
Per Tree |
One license |
This exposes all OES services and servers in the tree to any security vulnerabilities. |
This requires that a proxy user for the tree is created before any OES services are installed in the tree. This is suitable for organizations that have
The install admin must know the proxy user’s password. |
Proxy user passwords must be stored on the individual OES servers where the services are installed because proxy users must be able to log in to eDirectory to perform their required functions.
Auto-Generated Passwords: AFP, CIFS, iFolder 3, NSS, and Samba use auto-generated passwords by default.
This offers the highest security because the passwords are known only to the system. However, this option generates one proxy user per service per server, and it is critical that the assigned password policies not cause passwords to expire.
Manually Specified Passwords: For Archive and Versioning, DNS, DHCP, LUM, and NetStorage, this is the only available option, and it applies to the other OES services in all but the default (per service per server) installation scenario. It requires that someone keep track of the proxy user names and passwords for installation purposes.
Of course all proxy user passwords are stored in eDirectory. Table I-7 explains where they are stored on the server and how they can be reset if needed.
Table I-7 Password Storage Locations
IMPORTANT:Although the YaST based install can sometimes be used successfully to reconfigure some OES services, Novell neither recommends nor supports that practice.
Many organizations require that all network users have password policies to enforce regular password expiration and change.
Such policies create complications for the proxy user design. Proxy user passwords are stored on the local system to enable the OES services to log in to eDirectory. Every time a password change is forced in eDirectory, services stop working until the password is sychronized on the server.
These problems can be avoided by:
Not assigning proxy users a password policy that enforces password expiration.
Not using real user credentials for proxy users. See Avoid Assigning an Admin User As a Proxy User.
If password expiration policies cannot be avoided, or a security policy dictates that proxy user passwords must be changed periodically, you can do the following.
Ensure that the responsible administrator knows or has a record of each proxy user’s password and is aware of when they expire.
Before passwords expire, change them in eDirectory and reset them on the server. See the information in Table I-7.