Novell Doc: OES 2 SP3: Planning and Implementation Guide

I.4 Planning Your Proxy Users

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.

I.4.1 About Proxy User Creation

The first step in planning your proxy user implementation strategy is understanding the do’s and don’ts of proxy user creation.

Creation Options

Table I-2 presents information about the creation options for each OES proxy user.

Table I-5 Proxy User Creation Options

Associated Service	Service Proxy User Name if Applicable	Creation Information
AFP	n/a	Beginning with OES 2 SP3, the need for an AFP proxy user has been eliminated.
Archive Versioning	admin	The admin account that installs the server is automatically assigned as the Archive and Versioning proxy user. This is not configurable. Thefore, the new Common Proxy User feature doesn’t apply.
CIFS	OESCommonProxy_hostname Or CifsProxyUser-servername	Common Proxy User: If a Common Proxy User is specified, CIFS will be automatically configured to use it by default, but you have the option to change this. No Common Proxy User: If a Common Proxy User is not specified, the CIFS YaST install automatically does the following: Creates a proxy user named cifsProxyUser-servername in the same context as the server. Generates a password, and stores it in either CASA or in an encrypted file on the server, depending on which option you select. Alternatively, you can modify any of the defaults, including the password. Or if you have already created a proxy user, you can specify that as well.
Clustering (NCS)	OESCommonProxy_hostname Or installing admin user	Common Proxy User: If the Common Proxy User is specified, it is granted membership in the NCS_Management group, which enables it to communicate with eDirectory on behalf of the clustering service. No Common Proxy User: If a Common Proxy User is not specified, the system automatically uses the installing administrator, which is granted membership in the NCS_Management group, which enables it to communicate with eDirectory on behalf of the clustering service.
DHCP	OESCommonProxy_hostname Or installing administrator	Common Proxy User: If a Common Proxy User is specified, DHCP will be automatically configured to use it by default, but you have the option to change this. No Common Proxy User: If a Common Proxy User is not specified, the admin account that installs the server is assigned as the DHCP proxy user. If you want to assign an alternate user account, it must already exist in the tree and be able to access the DHCP server object.
DNS	OESCommonProxy_hostname Or installing administrator	Common Proxy User: If a Common Proxy User is specified, DNS will be automatically configured to use it by default, but you have the option to change this. No Common Proxy User: If a Common Proxy User is not specified, the admin account that installs the server is assigned as the DNS proxy user. If you want to assign an alternate user account, it must already exist in the tree and have Read, Write, and Browse rights in the contexts where the DNS Locator, Root Server, and Group Object are created.
Domain Services for Windows (DSfW)	OESCommonProxy_hostname Or DNS	Common Proxy User: If a Common Proxy User is specified, DSfW will be automatically configured to use it by default, but you have the option to change this. No Common Proxy User: If a Common Proxy User is not specified, the admin account that installs the server is assigned as the DNS proxy user. Alternatively, you can modify any of the defaults, including the password, or if you have already created a proxy user, you can specify that as well. The user must have the Read right to the LDAP service.
iFolder 3	OESCommonProxy_hostname Or iFolderProxy IMPORTANT:The Common Proxy user cannot be used if iFolder is running on a cluster node.	Common Proxy User: If a Common Proxy User is specified, iFolder will be automatically configured to use it by default, but you have the option to change this. No Common Proxy User: If a Common Proxy User is not specified, the system automatically creates a proxy user named iFolderProxy. Alternatively, you can modify any of the defaults, including the password, or if you have already created a proxy user, you can specify that as well. The user must have the Read right to the LDAP service.
Linux User Management	OESCommonProxy_hostname Or LUM_proxy (optional)	By default, no LUM proxy user is created. Common Proxy User: If a Common Proxy User is specified, you have the option of specifying that it be used as the LUM proxy user. If you do this, LUM is automatically configured to use it. No Common Proxy User: If you create a proxy user for LUM, it will be assigned rights to search the LDAP tree for LUM objects. If you assign a previously created user as the LUM proxy user, it must have the Read right to the LDAP service.
NetStorage	OESCommonProxy_hostname Or Installing administrator	Common Proxy User: If the Common Proxy User is specified, NetStorage will be configured to use it by default, but you have the option to change this. You must manually configure the proxy user with the rights specified in NetStorage in Table I-4. For more information, see Changing the NetStorage Default Configuration in the OES 2 SP3: NetStorage Administration Guide. No Common Proxy User: If a Common Proxy User is not specified, the system automatically uses the installing administrator. Alternatively, you can modify any of the defaults, including the password, or if you have already created a different proxy user, you can specify that as well. The user must have the Read right to the LDAP service.
NSS	server_nameadmin	This admin account must have full rights to administer NSS and must be unique to each server. The Common Proxy User does not apply to NSS.
Samba (Novell)	server_name-SambaProxy	By default, the Samba proxy user is created in the container specified as the Base Context for Samba Users and is named servername-sambaProxyUser. A password is automatically generated for the default proxy user, or you specify a different password for this user when you configure Novell Samba. You can specify another eDirectory user as the Samba proxy user. If you do, be aware of the following: If you specify a user that doesn’t already exist in eDirectory, the user account is created and granted the necessary rights. You must also specify a password for the new user. If you specify an existing eDirectory user, it is assumed that you have already created the user account with the necessary rights and no modifications are made to the existing user. If you specify an existing eDirectory user but enter a new password, you are prompted to change the password for that user. Because of the Samba proxy password requirements, the Common Proxy User cannot be used with Novell Samba.

Do Not Manually Configure Proxy Users

Best practices for most OES installation scenarios dictate that either the Common Proxy user be used or that proxy users be created in eDirectory prior to installing OES. For more information, see Common Proxy User - New in SP3 and Limiting the Number of Proxy Users in Your Tree.

IMPORTANT:The information in the preceding and following sections only answers security questions and provides general information. It is not intended to be used for the manual configuration of proxy users.

Manually created proxy users must be configured for OES-rootservice use only by the YaST based install, not manually.

Avoid Assigning an Admin User As a Proxy User

We recommend that you always use the special-purpose proxy user accounts described in this and the accompanying sections rather than specifying admin users as proxy users. Best practice dictates that proxy users have strictly limited functionality that supports only their specific system-level responsibilities. Proxy users should not be used for any other purposes.

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 if the Common Proxy user option isn’t selected), 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 the credentials were 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.

I.4.2 There Are No Proxy User Impacts on User Connection Licenses

Novell policy dictates that proxy users that function only as proxy users, are simply system users. Therefore, proxy users do not consume user connection licenses.

I.4.3 Limiting the Number of Proxy Users in Your Tree

Table I-6 outlines various options for limiting the number of proxy users in your tree and summarizes the security and manageability considerations of each approach.

Table I-6 Options for Limiting the Number of Proxy Users

Approach	Security Considerations	Manageability Considerations
Per Service per Server (default)	For CIFS, iFolder 3, and Samba this is the most secure option. By default, the 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	This confines any security vulnerabilities to individual servers and is the scenario for which the Common Proxy User was developed.	This requires that a proxy user for the server is created before the server is installed. If the Common Proxy User is not leveraged, then for the first server in the tree, eDirectory and iManager must be installed with the server. After the server installation finishes, a proxy user can be created. And finally the services can be installed and configured to use the proxy user for the server. This approach is useful when each OES server is managed by a separate administrator, or for enterprises where branch users access a server in the branch office. Knowing the proxy user password is not required unless additional services will be installed or password policies require periodic changing, in which cases the install admin must know the proxy user’s password.
Per 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 first server in the partition is created before services are installed in the partition. The install admin must know the proxy user’s password.
Per Service	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 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	This exposes all OES services and servers in the tree to any security vulnerabilities.	A proxy user for the tree must be created before any OES services are installed in the tree. This is suitable for organizations that have Centralized eDirectory administration Users that are not confined to the partition or subtree where the OES servers reside, but instead access different OES servers from all over the tree. The install admin must know the proxy user’s password.

I.4.4 Password Management and Proxy Users

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 vs. Manually Specified Passwords

Auto-Generated Passwords: These offer the highest security because the passwords are known only to the system.

The Common Proxy User, CIFS Proxy User, iFolder Proxy User (YaST calls this the LDAP proxy user), and Samba Proxy User all use auto-generated passwords by default.
Manually Specified Passwords: Although you can change the auto-generated passwords for the various proxy users, this is not recommended because it is less secure and requires that someone keep track of the passwords. Also, manually specified passwords can easily lead to problems, such as service disruption. For a related example of the problems this can cause, see Avoid Assigning an Admin User As a Proxy User.

Passwords Are Stored on the Server

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

Associated Service	Where the Password Is Stored Locally	How the Password Can Be Reset
Archive and Versioning	The service-specific password is stored in CASA.	You must use the script provided by Archive and Versioning Services to change the password on the server.
CIFS	If the service-specific proxy user is used, the password is stored in either CASA or in an encrypted file, depending on the configuration option specified during service installation.	You can use iManager to reset the password in CASA or in the encrypted file, or the CASAcli tool if it is stored in CASA.
Common Proxy User	This password is stored in CASA.	We recommend that you only use the change_proxy_pwd.sh script to manage Common Proxy User passwords.
DHCP	If the service-specific proxy user is used, the service-specific password is stored in CASA if it is available. If CASA is not available, it is stored in the /etc/dhcpd.conf file.	If the password is stored in CASA, you can set it using the CASAcli tool. If not, edit the /etc/dhcpd.conf file.
DNS	If the service-specific proxy user is used, the service-specific password is stored in CASA if it is available. If CASA is not available, it is stored in an encrypted file.
iFolder 3	If the service-specific proxy user is used, the service-specific password is stored in the iFolder store with PKI cryptography.	It can be changed either from a terminal prompt using the iFolder command line utilities or through the iFolder Admin Console.
Linux User Management	If the service-specific proxy user is used, the service-specific is stored in CASA.	This can be changed in iManager through the Linux User Management plug-in.
NetStorage	If the service-specific proxy user is used, the service-specific password is stored in the XTier registry.	This can be changed in iManager through the NetStorage plug-in.
NSS		This password is system-generated at install time and cannot be reset.
Samba (Novell)	The service-specific password is stored in Samba.	You can change the password by using the smbpasswd command.

IMPORTANT:Although the YaST based install can sometimes be used successfully to reconfigure some OES services, Novell neither recommends nor supports that practice.

Avoid Password Expiration Problems

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, we strongly urge you to implement an automatic password change routine as explained inChanging Proxy Passwords Automatically.

Otherwise you should probably do the following.

Ensure that the responsible administrator knows or has a record of each proxy user’s password and is aware of when each password expires.
Before passwords expire, change them in eDirectory and reset them on the server. See the information in Table I-7.

Changing Proxy Passwords Automatically

You can configure your server so that your proxy users are regularly assigned new system-generated passwords by doing the following:

Open the file /etc/opt/novell/proxymgmt/proxy_users.conf in a text editor.
List the FQDN of each proxy user on the server that you want to automatic password management set up for.

For example you might insert the following entries:
- cn=OESCommonProxyUser_myserver.o=novell
- cn=myproxy.o=novell
IMPORTANT:Users listed here must not be listed in the proxy_users.conf file on any other servers in the tree.
Save the file.
Enter the following commands:

cd /opt/novell/proxymgmt/bin

change_proxy_pwd.sh -A Yes

By default, the crontab job will run on the fifteenth (15th) day of each month.