Previous     Contents     Index     Next     
iPlanet Web Server: FastTrack Edition Administrator's Guide



Chapter 12   Controlling Access to Your Server


This chapter discusses the various methods you can use to control access to the Administration Server and to the files or directories on your web site. For example, for the Administration Server, you can specify who has full control of all the servers installed on a machine and who has partial control of one or more servers. Before you can use access control on the Administration Server, you must enable distributed administration from The Encryption On/Off Page and set up an administration group in your LDAP database. This chapter assumes you have already configured distributed administration and have defined users and groups in your LDAP database.

You should also ensure the security of the web server as discussed in Working with Server Security.

This chapter contains the following sections:



What Is Access Control?

Access control allows you determine who can access iPlanet Web Administration Server and which servers and tabs (also called programs) they can access as well as who can access the files or directories on your web site.

You can control access to the entire server or to parts of the server such as specific tabs or pages in the Administration Server or the files or directories on your web site. When the server evaluates an incoming request, it determines access based on a hierarchy of rules called access control entries (ACEs), and then it uses the matching entries to determine if the request is allowed or denied. Each ACE specifies whether or not the server should continue to the next ACE in the hierarchy. The collection of ACEs is called an access control list (ACL).When a request comes in to the server, the server looks in obj.conf for a reference to an ACL, which is then used to determine access. By default, the server has one ACL file that contains multiple ACLs.

You can use two methods for controlling access:

  • User-Group. This method requires users to enter a username and password before accessing the server. The server compares the information in a client certificate or the client certificate itself with a directory server entry. This methods requires the use of a directory server. If you choose to use client certificates, you should increase the value of the AcceptTimeout directive in magnus.conf.

  • Host-IP. This method requires the user to access the web server from a specific computer, where the web server recognizes the computer by either its hostname or its IP address. This methods does not require a directory server.

This section includes the following topics:


Setting ACL User Cache Time

To control the amount of time that ACL user cache is valid, use the ACLCacheLifetime directive in the magnus.conf file. Each time an entry in the cache is referenced, its age is calculated and checked against ACLCacheLifetime. The entry is not used if its age is greater than or equal to the ACLCacheLifetime. The default value is 120 seconds. If this value is set to 0, the cache is turned off. If you use a large number for this value, you may need to restart iPlanet Web Server when you make changes to the LDAP entries. For example, if this value is set to 120 seconds, iPlanet Web Server might be out of sync with the LDAP server for as long as two minutes. If your LDAP is not likely to change often, use a large number.

The maximum number of entries that can be held in the cache is configurable as of iPlanet Web Server 4.0, using the magnus.conf parameter, ACLUserCacheSize. The default value for this parameter is 200, which is the fixed size of the cache in ES 3.x. New entries are added to the head of a list, and entries at the end of this list are recycled to make new entries when the cache reaches its maximum size.

The maximum number of group memberships that can be cached per user entry is configurable as of ES 4.x, using the magnus.conf parameter, ACLGroupCacheSize. The default value for this parameter is 4, although in ES 3.x it has a fixed value of 1. Unfortunately non-membership of a user in a group is not cached, and will result in several Directory Server operations for each such check on every request.


User-Group Authentication

User-Group authentication requires users to authenticate themselves before getting access to the Administration Server or the files or directories on your web site. Authentication means that users verify their identity either by entering a username and password or by using a client certificate installed in their network browser, such as Netscape Communicator. The first method of getting the username and password is the basic method, which can be done with or without encryption. The latter method of using client certificates is the SSL method, which must be done with encryption on. For information on using SSL, see Working with Server Security.


Username and Password Authentication

To require users to enter a username and password to get access to the web server or your web site, you must store the list of users and groups in an LDAP database such as the Netscape Directory Server. The directory server can be running on the same machine as the web server, or you can use a directory server installed on a remote machine.

When users attempt to access a resource that has User-Group authentication in the Administration Server or on your web site, the web browser displays a dialog box asking the user to enter a username and password. The server receives this information encrypted or unencrypted, depending on whether encryption is turned on for your server.

After entering the username and password, the user either sees the Server Administration page if logging in to iPlanet Web Administration Server, the file or directory listing requested if logging in to a web site, or a message denying access if the username or password was invalid. You can customize the access denied message that unauthorized users see through the Access Denied Response page. Figure 12-1 shows the authentication dialog box. This dialog box displays a customized login prompt message.

Figure 12-1    Users see this dialog box when authenticating themselves to the server.


Note If your server does not use SSL encryption, the username and password that the end user types are sent in unencrypted text across the network. Someone could intercept the network packets and read the username and password being sent to the Administration Server. For this reason, User-Group authentication is most effective when combined with SSL encryption or Host-IP authentication, or both.


The server maintains two connections to the directory server. One of these is used to authenticate users, by doing an LDAP bind as the specified user. The other is permanently bound as the binddn specified in The Configure Directory Service Page, and is used for locating user entries and checking group memberships. Only one HTTP request thread can access the directory server at a time, which means that a global lock controls access to both LDAP connections. This can be a potential performance bottleneck, especially when combined with the fixed size of the ACL user/group cache.


Client Certificate Authentication

You can confirm users' identities with security certificates before giving the users access to your web site. You can do this in two ways:

  • The server can use the information in the certificate as proof of identity.

  • The server can verify the certificate itself if certificates are published in an LDAP directory.

When a server with client authentication enabled receives a request, the server performs the following actions:

  1. When the browser sends the certificate, the server checks if the certificate is from a trusted CA. If not, the server ends the transaction, and the authorization fails.

  2. If the certificate is from a trusted CA, the server maps the certificate to a user's entry using the certmap.conf file. See Using the certmap.conf File for more information on setting up the certificate mapping file.

  3. If the certificate maps correctly, then the web server checks the ACL rule specified for that user. Therefore, even though the certificate maps correctly, if the ACL denies the user access, the rule can deny the request.

The web server looks up the entry in an LDAP directory, so the access appears seamless to the end user.

Requiring client authentication for controlling access to specific resources is different than requiring client authentication for all connections to the server. To require client authentication with access control, choose the SSL authentication methods you want to use from The Encryption Preferences Page (in the Preferences tab, click Encryption Preferences). To require client authentication for the entire server, select "Require Client Certificates (regardless of access control)" in The Encryption Preferences Page.


Note Only the SSL authentication method requires modification to the certmap.conf file. Allowing client authentication for all connections to the server does not.


In order for a client to successfully gain access to a SSL authenticated resource requiring client certificates, the client must install a certificate on their browser which is from a certificate authority trusted by the web server. It may be necessary to have the same client certificate published in a directory server if the web server's certmap.conf file is configured to compare the entire certificate between the client's certificate in the browser and the client certificate in the directory server entry. However, the certmap.conf file can be configured so that it only compares selected information from the certificate to the entry in the directory server. For example, you can configure the certmap.conf file so that the server only compares a user ID and an email address in the browser certificate with the directory server entry. In such a case, it would not be necessary to publish the entire client certificate to the directory server since only the user ID and email address must match to gain access.


Host-IP Authentication

You can limit access to the Administration Server or the files or directories on your web site by making them available only to clients using specific computers. You specify hostnames or IP addresses for the computers that you want to allow or deny. You can use wildcard patterns to specify multiple computers or entire networks. End user access to a file or directory using Host-IP authentication appears seamless. Users can access the files and directories immediately without entering a username or password. If the machine does not have access, the user will see a message denying access. For information on customizing this message, see Responding When Access is Denied.


Note It is possible for more than one person to have access to a particular system. For this reason, Host-IP authentication is more effective when combined with User-Group authentication. If both methods of authentication are used, the end user will have to enter a username and password on a particular computer before getting access.


IP authentication does not require DNS to be configured on your server. If you want to use hostname authentication, however, you must have DNS running in your network and your server must be configured to use it. You can enable DNS on your server through The Performance Tuning Page in the Preferences tab.

Enabling DNS degrades the performance of iPlanet Web Server since the server is forced to do DNS look-ups. To reduce the effects of DNS look-ups on your server's performance, resolve IP addresses only for access control and CGI instead of resolving the IP address for every request. To do this, add the line "iponly=1" to the line that begins: AddLog fn="flex-log" name="access" in your obj.conf file. The resulting line is as follows:

AddLog fn="flex-log" name="access" iponly=1


Access Control Files

When you use access control on the Administration Server or the files or directories on your web site, the settings are stored in a file with the extension .acl. Access control files are stored in the directory server_install/httpacl where server_install is the location where the server is installed. For example, if you installed the server in /usr/netscape/server4, the ACL files for both the Administration Server and each server instance configured on your server would be located in /usr/netscape/server4/httpacl/.

The main ACL file name is generated-https-server-id.acl; the temporary working file is called genwork-https-server-id.acl. If you use iPlanet Web Server to restrict access, you'll have these two files. However, if you want more complex restrictions, you can create multiple files and reference them from the magnus.conf file. There are also a few features available only by editing the files such as restricting access to the server based on the time of day or day of the week.

Also, you can manually create and edit .acl files to customize access control. For example, if you want to use an Oracle or Informix database of users instead of an LDAP database, you need to use the access control API to program a hook into the server's access control structure. This API is written in the C programming language. For more information on the API, see the iPlanet documentation site at http://www.iplanet.com/docs.

For more information on access control files and their syntax, see ACL File Syntax.



How Access Control Works


When the server gets a request for a page, the server uses the rules in the ACL file to determine if it should grant access or not. The rules can reference the hostname or IP address of the computer sending the request. The rules can also reference users and groups stored in the LDAP directory.

For example, the following ACL file contains the two default entries for the Administration Server (admin-serv) plus an additional entry that allows users in the "admin-reduced" group to access The Preferences Tab in the Administration Server.

version 3.0;

# The following "es-internal" rules protect files such

# as icons and images related to iPlanet Web Server.

# These "es-internal" rules should not be modified.

  acl "es-internal";

  allow (read, list, execute,info) user = "anyone";

  deny (write, delete) user = "anyone";

# The following "default" rules apply to the entire document

# directory of iPlanet Web Server. In this example, the rules

# are set up so that "all" users in the directory server are

# allowed to read, execute, list, and get information.

# The "all" users are not allowed to write to or delete any files.

# All clients that accesses the document directory of the web

# server will be required to submit a username and password

# since this example is using the "basic" method of

# authentication. A client must be in the directory server

# to gain access to this default directory since "anyone"

# not in the directory server is denied, and "all" in the

# directory server are allowed.

  acl "default";

  authenticate (user,group) {

     database = "default";

     method = "basic";

  };

  deny (all)

  (user = "anyone");

  allow (read,execute,list,info)

  (user = "all");

# The following rules deny access to the directory "web"

# to everyone not in the directory server and deny everyone

# in the directory server who is not in GroupB.

# Only the users in GroupB are allowed read, execute, list,

# and info permissions. GroupA can not gain access to the

# directory "web" even though (in the ACL rule below) they

# can access the directory "my_stuff". Furthermore, members

# of GroupB can not write or delete files.

  acl "path=/export/user/990628.1/docs/my_stuff/web/";

  authenticate (user,group) {

     database = "default";

     method = "basic";

  };

  deny (all)

  (user = "anyone");

  allow (read,execute,list,info)

  (group = "GroupB");

# The following rule denies everyone not in the directory

# server and denies everyone in the directory server except

# user with the ID of "SpecificMemberOfGroupB". The ACL rule

# in this setting also has a requirement that the user

# connect from a specific IP address. The IP address setting

# in the rule is optional; it has been added to for extra

# security. Also, this ACl rule has a Customized prompt

# of "Presentation Owner". This Customized prompt appears

# in the username and password dialog box in the client's

# browser.

  acl "path=/export/user/990628.1/docs/my_stuff/web/presentation.html" ;

  authenticate (user,group) {

     database = "default";

     method = "basic";

     prompt = "Presentation Owner";

  };

  deny (all)

  (user = "anyone" or group = "my_group");

  allow (all)

  (user = "SpecificMemberOfGroupB") and

  (ip = "208.12.54.76");

# The following ACL rule denies everyone not in the directory

# server and everyone in the directory server except for

# GroupA and GroupB access to the directory "my_stuff"

  acl "path=/export/user/990628.1/docs/my_stuff/";

  authenticate (user,group) {

     database = "default";

     method = "basic";

  };

  deny (all)

  (user = "anyone");

  allow (read,execute,list,info)

  (group = "GroupA,GroupB");

If someone requests the URL: http://server_name/my_stuff/web/presentation.html, the server would first check access control for the entire server. If the ACL for the entire server was set to continue, the server checks to see if there is an ACL for the file type (*.html). Then, it checks for an ACL for the directory, my_stuff. If one exists, it checks the ACE and then moves on to the next directory. The server continues traversing the path either until it reaches an ACL that says not to continue or until it reaches the final ACL for the requested URL (in this case, the file presentation.html).

To set up access control for this example using the Server Manager, you could create an ACL for the file only or for each resource leading to the file. That is, one for the entire server, one for the my_stuff directory, one for the my_stuff/web directory, and one for the file.



Restricting Access to Your Web Site


This section takes you through the process of restricting access to the files or directories on your web site. The sections following this one describe in detail each option available when using access control. Keep in mind that most access control rules use only a subset of the available options.

You can set access control through two iPlanet Web Server mechanisms, both offer flexibility in the scope of your desired settings:

  • Administration Server

  • Server Manager


    Note You can set access control globally for all servers through the Administration Server or for a resource within a specific server instance through the Server Manager. This section describes how to use the Server Manager to set up access control within a specific server instance. For more information regarding how to use the Administration Server to set access control globally, see Restricting Server Access.


There is also a section of examples you can review in the section Access Control Examples.

To create an access control rule:

  1. From the Server Manager, choose the Preferences tab.

  2. Click the Restrict Access link.

    The Access Control List Management Page appears. There are three parts to this page:

    • Pick a resource allows you to specify a wildcard pattern for files or directories to restrict access to (such as *.html), or you can choose a directory or a filename to restrict. You can also browse for a file or directory by using the Browse button.

    • Pick an existing ACL lists all the ACLs you have enabled. Even if an ACL exists, if you have not enabled it, it will not appear in this list.

    Do not delete all the ACL rules from the ACL files. At least one ACL file is required to start the server, and the ACL file must have at least one ACL rule. If you delete all the ACL rules in the ACL files, and try to restart the server, you will see a syntax error.

    • Type in the ACL name allows you to create named ACLs. Use this option only if you're familiar with ACL files and the obj.conf configuration file—you'll need to manually edit obj.conf if you want to apply named ACLs to resources.

Figure 12-2    The Restrict Access page has three sections.

  1. Specify the part of the server (the resource) that you want to control in the Pick a resource section.

    For example, you can select Entire Server to set up access control for the entire server. The drop-down list contains an entry for each ACL resource defined in the server root.

    For some common examples of resources you might use for access control, see Table 12-1.

  2. Click Edit Access Control.

    The page divides into two frames that you use to set the access control rules. If the resource you chose already has access control, the rules will appear in the top frame. The ACL for iPlanet Web Administration Server, begins with two non-editable deny statements by default. The following figure briefly describes the page elements.

Figure 12-3 The ACL page contains links that, when clicked, display additional information in the bottom frame
(not shown).

  1. Click New Line.

    This adds a default ACL rule to the bottom row of the table. You can use the up and down arrows in the left column to move the rule.

  2. Select the action you want to apply to the rule by clicking Deny.

    You can specify whether to deny or allow access to the users, groups, or hosts specified in the following steps in the bottom frame. Select the option you want, and then click Update.

  3. Specify User-Group authentication by clicking "anyone" listed under the Users/Groups column.

    The bottom frame allows you to configure User-Group authentication. By default, there is no authentication, meaning anyone can access the server resource. Select the options you want, and then click Update.

  4. Specify the computers you want to include in the rule by clicking anyplace.

    You can enter wildcard patterns of host names or IP addresses to allow or deny in the bottom frame. Select the options you want, and then click Update.

  5. Specify the access rights you want to include in the rule by clicking all. Select the access rights in the bottom frame, and then click Update.

  6. Specify the programs you want to restrict. Programs are the forms in the Server Manager for the server you selected. For example, you can restrict access to all forms for configuring the administration server by checking the "All Programs" radio button. If you want to restrict access to one or two sets of forms, choose the categories in the drop-down list. If you want to restrict access to one form in a category, type the name of the form in the "Program Items" field. For example, to restrict access to the access control form, type distacl in the Program Items field. For more information, see Access to Programs.

    Click Update to add the programs options to the rules for the line you're editing.

  7. If you are familiar with ACL files, you can enter a customized ACL entry by clicking X under the Extra column.

    This area is useful if you use the access control API to customize ACLs.

  8. Select Continue if you want the access control rule to continue in a chain.

    This means the next line is evaluated before the server determines if the user is allowed access. When creating multiple lines in an access control entry, it's best to work from the most general restrictions to the most specific ones.

  9. Repeat steps 5 through 11 for each rule you need.

    If you want the user to be redirected to another URL if their request is denied, check Response when denied. Click the link to specify the URL for redirection.

  10. Click Submit to store the new access control rules in the ACL file.

    If you click Revert, the server removes any changes you made to the rules from the time you first opened the two-frame page. Be cautious when using Revert because you can't restore your edits. In most cases, it's probably better to delete the rule lines individually.


    Table 12-1 LDAP Attributes

    Resource wildcard

    What it means

    default  

    A named ACL created during installation that restricts write access so only users in the LDAP directory can publish documents.  

    Entire Server  

    One set of rules determines the access to your entire web site, including any virtual servers you have running. To restrict access to a virtual server, specify the path of its document root.  

    *.html  

    Controls access to all files with the .html extension  

    *.cgi  

    Controls access to all files with the .cgi extension  

    /usr/netscape/server4/docs/
    cgi-bin/*          

    Controls access to all files and directories in the cgi-bin directory. You must specify an absolute path. On NT, the path must include the drive letter.  

    uri="/sales"  

    Controls access to the sales directory in the document root. To specify URIs, create a named ACL.  

The following sections describe the options that appear in the bottom frame of the access control page.


Setting Access Control Actions

You can specify the action the server takes when a request matches the access control rule.

  • Allow means the users or systems can access the requested resource.

  • Deny means the users or systems cannot access the resource.

The server goes through the list of ACEs to determine the access permissions. For example, the first ACE is usually to deny everyone. If the first ACE is set to "continue," the server checks the second ACE in the list. (If continue is not checked, everyone would be denied access to the resource.) If the second entry matches, then the next ACE is used. The server continues down the list until it reaches either an ACE that doesn't match or that matches but is set to not continue. The last ACE that matches is used to determine if access is allowed or denied. For example, in Figure 12-4 any user in the database can view a file (read access), but they must be in the "pubs" group if they want to publish a file to the server.

Figure 12-4    You can combine Deny and Allow statements in an ACL.


Specifying Users and Groups

You can restrict access to the Administration Server or your web site based on the user who requests a resource. With user and group authentication, users are prompted to enter a username and password before they can access the resource specified in the access control rule.

iPlanet Web Server uses a list of users, who might be sorted into groups, to determine access rights for the user requesting a resource. You must define an administrators group (the group you set up for distributed administration) for access control in the Administration Server. The list of users (and the groups they are included in) are stored in an LDAP server, such as Netscape Directory Server. You should make sure the database contains users and groups (including the administrators group) before you set access control.

You can allow or deny access to everyone in the database, or you can allow or deny specific people by using wildcard patterns or lists of users or groups.

To configure access control with users and groups, follow the general directions for restricting access. When you click the Users/Groups field, a additional options appear in the bottom frame. The following list describes the options in the bottom frame.

  • Anyone (No Authentication) is the default and means anyone can access the resource without having to enter a username or password. However, the user might be denied access based on other settings, such as host name or IP address. For the Administration Server, this means that anyone in the administrators group that you specified with distributed administration can access the pages.

  • All in the authentication database matches any user who has an entry in the database. To use this option, you must also check "Authenticated people only." For the Administration Server, the users you specify must also be in the "administrators" group you specified for distributed administration.

  • Only the following people lets you specify certain users and groups to match. You can list the users and groups of users individually by separating the entries with commas. Or, you can enter a wildcard pattern. To use this option, you must also check "Authenticated people only."

    • Group matches all users in the groups you specify. For the Administration Server, the users in the groups you specify must also be in the "administrators" group you specified for distributed administration.

    • User matches the individual users you specify.

  • Prompt for authentication lets you specify message text that appears in the authentication dialog box. You can use this text to describe what the user needs to enter. Depending on the operating system, the user will see about the first 40 characters of the prompt. Netscape Navigator and Netscape Communicator cache the username and password and associate them with the prompt text. This means that if the user accesses areas (files and directories) of the server that have the same prompt, the user won't have to retype usernames and passwords. Conversely, if you want to force users to reauthenticate for various areas, you simply need to change the prompt for the ACL on that resource.

  • Authentication Methods specifies the method the server uses when getting authentication information from the client.

    • Default uses the default method you specify in the obj.conf file, or "Basic" if there is no setting in obj.conf. If you check Default, the ACL rule doesn't specify a method in the ACL file. Default is the best choice because you can easily change the methods for all ACLs by editing one line in the obj.conf file.

    • Basic uses the HTTP method to get authentication information from the client. The username and password are only encrypted if encryption is turned on for the server.

    • SSL uses the client certificate to authenticate the user. If you use this method, SSL must be turned on for the server. If you have encryption on, you can combine Basic and SSL methods.

    • Other uses a custom method you create using the access control API.

  • Authentication Database lets you select a database that the server uses to authenticate users. The default setting means the server looks for users and groups in an LDAP directory. However, you can configure individual ACLs to use different databases. You can specify different databases and LDAP directories in the file server_root/userdb/dbswitch.conf. Then, you can choose the database you want to use in the ACL by selecting it in the drop-down list. If you use the access control API to use a custom database (for example, to use an Oracle or Informix database), you can type the name of the database in the "Other" field in the User/Group window.


Specifying Host Names and IP Addresses

You can restrict access to the Administration Server or your web site based on which computer the request comes from. You specify this restriction by using wildcard patterns that match the computers' host names or IP addresses. For example, to allow or deny all computers in a specific domain, you would enter a wildcard pattern that matches all hosts from that domain, such as *.iplanet.com. You can set different hostnames and IP addresses that the superuser must use when accessing the Administration Server.

To specify users from hostnames or IP addresses, follow the directions for restricting access in Restricting Access to Your Web Site. When you click the From Host field (the link called anyplace), additional options appear in the bottom frame. Check the Only from option and then type either a wildcard pattern or a comma-separated list of hostnames and IP addresses. Restricting by hostname is more flexible than by IP address—if a user's IP address changes, you won't have to update this list. Restricting by IP address, however, is more reliable—if a DNS lookup fails for a connected client, hostname restriction cannot be used.

The hostname and IP addresses should be specified with a wildcard pattern or a comma-separated list. The wildcard notations you can use are specialized; you can only use the *. Also, for the IP address, the * must replace an entire byte in the address. That is, 198.95.251.* is acceptable, but 198.95.251.3* is not. When the * appears in an IP address, it must be the right-most character. For example, 198.* is acceptable, but not 198.*.251.30.

For hostnames, the * must also replace an entire component of the name. That is, *.iplanet.com is acceptable, but *sers.iplanet.com is not. When the * appears in a hostname, it must be the left-most character. For example, *.iplanet.com is acceptable, but users.*.com is not.


Setting Access Rights

You can set access rights to files and directories on your web site. That is, in addition to allowing or denying all access rights, you can specify a rule that allows or denies partial access rights. For example, you can give people read-only access rights to your files, so they can view the information but not change the files.

When you create an access control rule, the default access rights are set to all access rights. To change access rights, click the Rights link in the top frame, and then choose the access rights you want to set for a particular rule. The following list describes each access right you can check.

  • Read access lets a user view a file. This access right includes the HTTP methods GET, HEAD, POST, and INDEX.

  • Write access lets a user change or delete a file. Write access right includes the HTTP methods PUT, DELETE, MKDIR, RMDIR, and MOVE. To delete a file, a user must have both write and delete privileges.

  • Execute access applies to server-side applications, such as CGI programs, Java applets, and agents.

  • Delete access means a user who also has write privileges can delete a file or directory.

  • List access means the user can get directory information. That is, they can get a list of the files in that directory.

  • Info access means the user can get headers (http_head method).


Access to Programs

You can select areas of the administration server that administrators can access. You can choose groups of tabs that appear in the Server Manager , or you can choose specific pages that appear as links in the left frame of the Server Manager (such as "New User" in the User & Groups tab).

To control access to a program in a server, perform the following steps:

  1. From the Administration Server, choose the Global Settings tab

  2. Choose Restrict Access.

  3. From the drop-down list, choose the server whose administration access you want to restrict. The administration server is labeled "https-admserv." Other servers are labeled with their type and their server id (for example, https-mozilla).

    When you select a server to restrict, you are restricting who can view the Server Manager pages and which pages they can use to configure that server. For example, you might allow some administrators to configure the Users & Groups section of the administration server and not allow them access to the Global Settings.

  4. Click Edit ACL. The web server displays the two-frame access control pages.

  5. Each ACL begins with two deny lines (the default setting), one that restricts access to only those users in the "administrators" group set for distributed administration, and another that restricts access to all users. If you want to change either of these lines, you need to manually edit the ACL file. Click New Line to add a rule to the ACL. Each rule you create allows access to the server. By specifically allowing access for users, you reduce the risk that you'll allow access to users you don't want.

  6. Choose the users, groups, hosts, and IP addresses you want to apply to this access control rule.

  7. By default, administrators have access to all programs for a server. Click the All link under Programs in the top frame. The bottom frame displays a page that lists the programs for the server type you selected.

  8. Select Only the following, and then select the Program Groups you want to apply to the rule. You can choose multiple groups by pressing the Control key and then clicking the groups you want.

    The Program Groups listed use the same name as the buttons in the top frame of the Server Manager for the server type you selected. For example, in the administration server, there are tabs labeled Preferences, Global Settings, and so on. When an administrator accesses the administration server, the server uses their username, host, and IP to determine what pages they'll see. If they have access to only one or two pages, they will only see those pages.

  9. You can control access to a specific page within a tab. Type the name of the page in the Program Items field. To determine the name of a page, place your pointer over the link in the left frame of the Administration Server and then view the text in the status bar on the bottom of your browser. The last word after the last %2b is the name for that page.



    For example, suppose you have one person who administers a Netscape Directory Server and you want that person to have access only to the "Configure Directory Service" page. In this case, you would set up a rule that applies to them (host, IP, and so on), and then you would enter dsconfig in the Program Items field.

  10. Click Update and then Submit to save the access control rule.


Writing Customized Expressions

You can enter custom expressions for an ACL. You can use this feature if you are familiar with the syntax and structure of ACL files. There are a few features available only by editing the ACL file or creating custom expressions. For example, you can restrict access to your server depending on the time of day, day of the week, or both.

The following customized expression shows how you could restrict access by time of day and day of the week. This example assumes you have two groups in your LDAP directory: the "regular" group gets access Monday through Friday, 8:00am to 5:00pm. The "critical" group gets access all the time.

allow (read)
{
   (group=regular and dayofweek="mon,tue,wed,thu,fri");
   (group=regular and (timeofday>=0800 and timeofday<=1700));
   (group=critical)
}

For more information on valid syntax and ACL files, see ACL File Syntax and Referencing ACL Files in obj.conf.


Selecting "Access control on"

When you uncheck the option labeled "Access control on," you'll get a prompt asking if you want to erase records in the ACL. When you click OK, the server deletes the ACL entry for that resource from the ACL file.

If you want to deactivate an ACL, you can comment out the ACL lines in the file generated-https-server-id.acl by putting # signs at the beginning of each line.

From the Administration Server, you could create and turn on access control for a specific server instance and leave it off (which is the default) for other servers. For example, you could deny all access to the Server Manager pages from the Administration Server. With distributed administration on and access control off by default for any other servers, administrators could still access and configure the other servers, but they cannot configure the Administration Server.


Note This access control is in addition to the user being in the administrators group set for distributed administration. The the Administration Server first checks that a user (other than superuser) is in the administrators group, and then it evaluates the access control rules.



Responding When Access is Denied

You can choose the response a user sees when denied access. You can vary the message for each access control object. By default, the user is sent a message that says the file was not found (the HTTP error code 404 Not Found is also sent).

To change what message is sent for a particular ACL, perform the following steps:

  1. In the ACL page, click the Response when denied link.

  2. In the lower frame, check the Respond with the following file radio button.

  3. In the text field, type a URL or URI to a text or HTML file in your server's document root that you want to send to users when they are denied access. The server must have read access to this file, so you should consider putting the file in the document root.

    Make sure the file does not contain references to other files or images because they will not be sent.

  4. Click Update.

    Make sure any users who get the response file have access to that file. If you have access control on the response file and the user is denied access to both the original resource and the response file, the server will send the default denied response.

  5. Make sure you submit the access control rule by clicking Submit in the top frame.



Access Control Examples

This section describes some common examples for restricting access to a web server and its contents. Some of these examples assume you set up the "default" ACL to deny anyone access to the server. You can also add a "deny all" line as the first rule to each of these examples, as done in the example for the entire server (see Restricting Access to the Entire Server).

This section includes the following topics:


Restricting Access to the Entire Server

This example allows access to users in a group called "employees" who access the server from computers in a subdomain. There are no access control rules for other resources on the server. You might use this example if you have a server for a department and you only want users to access the server from computers in a specific subdomain of your network.

To restrict access to the entire server, perform the following steps:

  1. In iPlanet Web Server, choose Server Preferences.

  2. Click the Restrict Access link.

    The web server displays the Access Control List Management page.

  3. In the section called Pick a Resource, select "The entire server" from the Editing drop-down list and then click Edit Access Control.

    The two-frame page appears.

  4. Click New Line.

    The default rule appears, which denies all access to the server. Typically, you should deny all access to your server, and then allow specific access to users, groups, and computers; however, you might change this if you want to deny access only to a small group of users or groups. Click New Line again to create a second rule.

  5. Click the Deny link in the second rule. In the bottom frame that appears, check Allow, and then click Update.

  6. Click the "anyone" link in the second rule. In the bottom frame, type the group you want to have access to the server.

    For this example, type employees in the Group field. Note that the two options called "Authenticated people only" and "Only the following people" are checked automatically. Click Update.

  7. Click the "anyplace" link in the second rule. In the bottom frame, type a wildcard pattern for the host names of the computers you want to allow.

    For example, type *.emp.mozilla.com in the Host Names field. Click Update.

  8. Unselect Continue in the top frame, and then click Submit.

    The frame should look like the one in Figure 12-5.

  9. Submit your changes.

Figure 12-5    Restricting access to the entire server

Be sure to restart the server for the changes to take affect. The following text is the ACL file for this example.

# File automatically written

#

# You may edit this file by hand

#

version 3.0;

acl "default";

authenticate (user,group) {

  prompt = "Web Server"

}

deny (all)

  user = "anyone";

allow absolute (all)

  (group = "employees") and

  (dns = "*.emp.netscape.com");


Restricting Access to a Directory (Path)

This example lets users in a group called "executives" have read access to a directory and its subdirectories and files on the server. The user called "ceo" has full permissions to the directory.

You might use this example if you have a directory on your server that one person owns (that is, they publish to this directory) and you want one group of users to read the files. For example, you might have a project owner who publishes status information for the project team to review.

To restrict access to a directory on the server, perform the following steps:

  1. In the Server Manager, choose Server Preferences.

  2. Click the Restrict Access link.

    The web server displays the Access Control List Management page.

  3. In the section called Pick a Resource, click the Browse button.

    In the page that appears, click the link for the directory you want to restrict. The directories listed in this page are in the servers document root. Once you click a link, the Editing drop-down list displays the absolute path to the directory.


    Note If you want to view all files in your server root, click Options and check the box labeled List files as well as directories and then click OK.


  4. Click Edit Access Control.

    The two-frame pages appear.

  5. Click New Line twice to create two rules.

    Don't edit the default values for the first rule—they deny all access to the directory. You'll edit the second rule to allow read access to the "executives" group.

  6. Click Deny in the second rule. In the bottom frame that appears, check Allow, and then click Update.

  7. Click anyone in the second rule. In the bottom frame, type the group you want to have access to the server. For this example, type executives in the Group field. Click Update.

  8. Click all in the top frame. Uncheck the Write and Delete access rights.

    This means the users in the executives group can't add or remove files, but they can view them and run any applications in the directories. Click Update.

  9. Click New Line to create a rule for the "ceo" user. Check Allow for the third rule.

  10. Click anyone. In the bottom frame, type ceo in the User field. Click Update.

  11. Uncheck Continue for both the second and the third rules.

    This means that the server ignores any ACLs for directories or files under the directory you specified in Step 3. The frame should look like the one in Figure 12-6.

Figure 12-6    Restricting access to a path in the server

  1. Click Submit and save and apply your changes.

The entry in the generated.https-serverid.acl file for this example looks like this:

acl "path=/usr/netscape/server4/nes/docs/senior-staff/";

deny (all)

    user = "anyone";

allow absolute (read,execute,list)

    group = "executives";

allow absolute (all)

    user = "ceo";


Restricting Access to a URI (Path)

This example uses a URI to control access to a single user's content on the web server. URIs are paths and files relative to the server's document root directory. Using URIs is an easy way to manage your server's content if you frequently rename or move all or part of it (for example, for disk space). It's also a good way to handle access control if you have additional document roots.

This example gives anyone read access to files and directories in the path specified by the URI /my_directory. Only one user ("me" in this example) has full access to the directories and files.

You might use this example if you have several users who publish their content on your server. The users want to have write access to their content, and they want anyone to have read/execute access.

To restrict access to a URI, perform the following steps:

  1. In the Server Manager, choose Server Preferences.

  2. Click the Restrict Access link.

    The web server displays the Access Control List Management page.

  3. In the Type in the ACL name section, type the URI you want to control. For example, type uri=/my_directory.

  4. Click Edit Access Control.

    The two-frame pages appear.

  5. Click New Line to create the first rule that allows all users read access.

  6. Click the Deny link. In the bottom frame that appears, check Allow, and then click Update.

  7. Click the all link in the top frame. Uncheck the Write and Delete access rights.

    This means users cannot add or remove files, but they can view them and run any applications in the directories. Click Update.

  8. Click New Line to create a rule for the owner of the directory. Check Allow for the second rule.

  9. Click anyone. In the bottom frame, type me in the User field. Click Update.

  10. Uncheck Continue for both the first and second rules.

    This means that the server ignores any ACLs for other URIs, directories, or files under the URI you specified in Step 3. The frame should look like the one in Figure 12-7.

Figure 12-7    Restricting access to a URI (path) in the document root

  1. Click Submit and save and apply your changes.

The entry in the generated.https-serverid.acl file for this example looks like this:

acl "uri=/my_directory";
allow absolute (read,execute,list,info)
    user = "anyone";
allow absolute (all)
    user = "me";


Restricting Access to a File Type

This example controls write and delete access to all files with the extension .cgi. You might use this example if you only want specific users to create programs that run on your server. In this example, anyone can run the programs, but only users in the "programmers" group can create or delete them.

To restrict access to a file type, perform the following steps:

  1. In the Server Manager, choose Server Preferences.

  2. Click Restrict Access.

    The web server displays the Access Control List Management page.

  3. In the Pick a resource section, click Wildcard. In the prompt that appears, type *.cgi and click OK.

    This wildcard pattern matches any request that contains a file or directory with the .cgi extension.

  4. Click Edit Access Control.

    The two-frame pages appear.

  5. Click New Line to create the first rule that will allow all users read access.

  6. Click Deny. In the bottom frame that appears, check Allow, and then click Update.

  7. Click all in the top frame. Uncheck the Write and Delete access rights.

    This means users can't add or remove files or directories with the .cgi extension. Click Update.

  8. Click New Line to create a rule that allows write and delete access to the "programmers" group. Check Allow for the second rule.

  9. Click anyone. In the bottom frame, type programmers in the Group field. Click Update.

    The frame should look like the one in Figure 12-8.

Figure 12-8    Restricting access to a file type—in this case, to files with the .cgi extension

  1. Click Submit and save and apply your changes.

In this example, both continue boxes are checked. This means that if a request for a file comes in, the server will first look at the ACL for the file type, and then it will continue to look for another ACL that matches (for example, am ACL on the URI or the path). The web server checks ACLs in the following order:

  1. Pathcheck functions in obj.conf. For example, these could be wildcard patterns for files or directories. The entry in the ACL file would appear as follows: acl "*.cgi";

  2. URIs. For example, a path relative to the document root. The entry in the ACL file would appear as follows: acl "uri=/my_directory";

  3. Pathnames. For example, an absolute path to a file or directory. The entry in the ACL file would appear as follows: acl "path=d:\netscape\suitespot\docroot1\sales/";

The entry in the generated.https-serverid.acl file for this example looks like this:

acl "*.cgi";
allow (read,execute,list,info)
  user = "anyone";
allow (all)
  group = "programmers";


Restricting Access Based on Time of Day

This example restricts write and delete access to the server during working hours. You might use this example if you don't want people publishing documents at times when people might be accessing the files. This example allows users to publish during the evening during the week (between 6:00pm and 6:00am, Monday through Friday) and all time during the weekend.

To restrict access based on time of the day and day of the week, perform the following steps:

  1. In the Server Manager, choose Server Preferences.

  2. Click Restrict Access.

  3. In the Pick a Resource section, select "The entire server" from the Editing drop-down list. (You can select any resource.) Click Edit Access Control.

    The server displays the two-frame pages.

  4. Click New Line.

  5. Click the Deny link. In the bottom frame that appears, check Allow, and then click Update.

  6. Click the all link in the top frame. Uncheck the Write and Delete access rights.

    This means that if a user wants to add, update, or delete a file or directory, this rule won't apply and the server will search for another rule that matches. Click Update.

  7. Click New Line to create a rule that restricts the write and delete methods. Check Allow for the second rule.

  8. Click the X link to create a customized expression. In the bottom frame, type the following lines:

    user = "anyone" and
    dayofweek = "sat,sun" or
    (timeofday >= 1800 and
    timeofday <= 600)

    You might want to select the entire text element and copy to memory—if there are errors, you'll have to reenter the text. Click Update. The top frame will display "Unrecognized expressions" in the Users/Groups and From Host fields because you created a custom expression.

  9. Click Submit. If you made any errors in the custom expression, you'll get a JavaScript alert. Correct any changes and click Submit again.

Restart your server for the changes to take effect.


Previous     Contents     Index     Next     
Copyright © 2000 Sun Microsystems, Inc. Some preexisting portions Copyright © 2000 Netscape Communications Corp. All rights reserved.

Last Updated July 13, 2000