Controlling access to your server


ou can control who accesses the files on your web site. This chapter discusses the various methods you can use to determine who has access to what files or directories on your web site. If you want to control who can configure the web server itself and who can access the server configuration files, see Managing Netscape Servers. You should also ensure the security of your web server's computer, as discussed in Chapter 8, "Using encryption and SSL."

 

What is access control?

Access control lets you determine who can access the server. You can use two attributes for controlling access:

User-Group authentication

You can require users to authenticate themselves before getting access to 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 Navigator or Netscape Communicator. The first method of getting the username and password is the "Basic" method, which can be done with or without encryption. The second method of using client certificates is the "SSL" method, which must be done with encryption on.

 

Username and password authentication

If you require users to enter a username and password to get access to your web site, you store the list of users and groups in an LDAP database, which can be either a file stored on the web server computer or an LDAP server on a remote computer (for example, a computer running Netscape Directory Server).

When users attempt to access a file or directory that has User-Group authentication, the web browser displays a dialog box asking the user to enter a username and password. The server can get this information encrypted or not, depending on whether encryption is turned on for your server.

 After entering the information, the user either sees the file or directory listing requested or a message denying access. (You can customize the access-denied message that they see.) Figure 6.1 shows the authentication window. This window shows a custom message.

 Users see this window when authenticating themselves to the server.

 

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

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: When a request comes in and you have client authentication on, the server performs these actions in order:
  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.

  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 Managing Netscape Servers for more information on setting up the certificate mapping file.)

  3. If the certificate maps correctly, then the web server follows the ACL rule specified for that user. The rule can deny or allow the request.
New in 3.x
In version 2.0, users had to enter a username and password along with sending a certificate to the server. In 3.x, 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 certificates for all connections to the server. To require client certificates for the entire server, you check a box in the Encryption Preferences form. To require client authentication with access control, you use the SSL authentication method.
Users must first install a client certificate in their network browser and then optionally publish the certificate in an LDAP directory, such as Netscape Directory Server.

Host-IP authentication

You can limit access to files and directories on your web site by making them available only to people 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. If you want to use this feature, you must have DNS running in your network and your computer must be configured to use it.

 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 computer doesn't have access, the user will get a message denying access. (You can also customize this message.)

 

Note
It's possible for more than one person to have access to a particular computer. For this reason, Host-IP authentication is most 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 before getting access.

Access control files

When you use access control on your web server, the settings are stored in a file with the extension .acl. Access control files are stored in the directory server_root/server_typeacl where server_type is the name of the server. For example, the administration server uses the directory adminacl. Netscape Enterprise Server uses 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 the Server Manager forms to restrict access, you'll have these two files. However, if you want to do 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. For example, you can restrict access to the server depending on the time of day or day of the week.

 You also manually create and edit .acl files if you want to customize access control. For example, you might want to use an Oracle or Informix database of users instead of an LDAP database. To do this type of customizing, you need to use the access control API to program a hook into the server's access control structure. This API is written in C. For more information on the API, see the Netscape DevEdge Online site at http://developer.netscape.com.

 For more information on access control files and their syntax, see the online help.

 

How does access control work?

You can control access to the entire server or to parts of the server (that is, directories, files, file types). 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.

 For example, suppose someone requests the following URL:

 http://www.mozilla.com/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 forms, 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.

 The following sample ACL file illustrates one way to control access to this resource.

 

# File automatically written

#

# You may edit this file by hand

#

version 3.0;
# This ACL allows everyone in the local database or LDAP directory

acl "agents";

authenticate (user,group) {

        prompt = "Enterprise Server";

};

deny (all) 

    user = "anyone";

allow absolute (all) 

    user = "all";
# This ACL denies all access to the my_stuff directory

acl "path=C:\Netscape\SuiteSpot\docs\my_stuff";

deny (all) 

    user = "anyone";
# This ACL allows access to anyone in the user database

acl "path=C:\Netscape\SuiteSpot\docs\my_stuff\web";

allow (all) 

    user = "anyone";
# This ACL allows access to the file to anyone in the "my_group" group

acl "path=C:\Netscape\SuiteSpot\docs\my_stuff\web\presentation.html";

allow (all) 

    user = "anyone";

    group = "my_group"
# This is the default ACL and denies access to anyone

acl "default";

deny (all)

Restricting access

This section takes you through the process of restricting access to documents 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.

 There is also a section of examples you can review on page 112.

 To create an access-control rule:

  1. Go to the Server Manager and choose System Preferences|Restrict Access. A form appears where you select and edit an existing access-control rule or specify a new rule by either choosing the resource you want to apply to the rule (that is, the file, directory, or wildcard pattern you want to control) or typing a name to assign to the ACL. There are three sections to this main form:
The Restrict Access form has three sections.

 

  1. Specify the part of your web site (the resource) that you want to control. For example, you can select Entire Server to set up access control for your entire server.

  2. The following items are some common examples of resources you might use for access control.
    Resource wildcard 

     

    What it means 

     

    default 

     

    A named ACL created during installation that restricts write access, so only users in the local database or LDAP directory can publish documents (for example, by using the web publisher). 

     

    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/ns-home/cgi-bin/* 

     

    Controls access to all files and directories in the cgi-bin directory. Note that the path is absolute. On NT, the path must include the drive letter. 

     

    agents 

     

    A named ACL that restricts access to all agents. The web server contains this ACL by default 

     

    uri="/sales" 

     

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

     

  3. Click the Edit Access Control button. The right frame 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 following figure briefly describes the form elements.
The ACL form contains links that, when clicked, display another form in the bottom frame (not shown).

 

  1. Click the New Line button. 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, if needed.

  2. Select the action you want to apply to the rule by clicking the Deny link. The bottom frame displays a form where you can check if you want to deny or allow access to the users, groups, or hosts you'll specify in the following steps. Check the option you want, and then click Update.

  3. Specify User-Group authentication by clicking the "anyone" link listed under the Users/Groups column. The bottom frame displays a form for configuring User-Group authentication. By default, there is no authentication, meaning anyone can access the resource.

  4. Check the options you want, and then click Update.
  5. Specify the computers you want to include in the rule by clicking the "anyplace" link. The bottom frame displays a form where you can enter wildcard patterns of host names or IP addresses to allow or deny.

  6. Check the options you want, and then click Update.
  7. Specify the access rights you want to include in the rule by clicking the "all" link. Check the access rights in the bottom frame, and then click Update.

  8. 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.

  9. Check 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.

  10. Repeat steps 4 through 10 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.

  11. Click the Submit button 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 window. 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.
The following sections describe the options that appear in the bottom frame of the access-control window.

 

Setting access-control actions

You can specify the action the server takes when a request matches the access-control rule. The server goes through the list of ACEs to determine what the access is. 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 6.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.

 You can combine Deny and Allow statements in an ACL.

 

Specifying users and groups

You can restrict access to 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.

The web server uses a list of users, who might be sorted into groups, to determine access rights for the user requesting a resource. The list of users (and the groups they are included in) are stored either in a database on the web server computer or in an LDAP server, such as Netscape Directory Server. You should make sure the database has users and groups in it 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 form appears in the bottom frame. The following list describes the options in the form.

Specifying host names and IP addresses

You can restrict access to 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 *.netscape.com.

To specify users from hostnames or IP addresses, follow the general directions for restricting access. When you click the From Host field (the link called "anyplace"), a form appears 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 198.*.251.30 is not.

 For hostnames, the * must also replace an entire component of the name. That is, *.netscape.com is acceptable, but *sers.netscape.com is not. When the * appears in a hostname, it must be the left-most character. For example, *.netscape.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. This is particularly useful when you use the web publishing feature to publish documents.

 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 check or uncheck the access rights you want to set for a particular rule. The following list describes each access right you can check.

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 the online help.

 

When "Access control on" is checked

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.

 

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 wasn't found (the HTTP error code 404 Not Found is also sent).

 To change what message is sent for a particular ACL:

  1. In the ACL form, click the link called "Response when denied."

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

  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. Make sure the file doesn't contain references to other files (such as style sheets) or images because they won't be sent. Click Update.
    Note

    Make sure any users who get the response file have access to that file. That is, 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.

  1. Make sure you submit the access -control rule by clicking the Submit button in the top frame.

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.

 

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:

  1. In the Server Manager, choose Server Preferences|Restrict Access.

  2. In the section called Pick a Resource, select "The entire server" from the Editing drop-down list. Click Edit Access Control. The two-frame forms appear.

  3. 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.

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

  5. Click the "anyone" link in the second rule. In the bottom form, 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.

  6. Click the "anyplace" link in the second rule. In the bottom form, 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.

  7. Uncheck the Continue box in the second rule of the top frame, and then click Submit. The form should look like the one in Figure 6.5. Save and apply your changes.
Restricting access to the entire server

 

Be sure to restart the server for the changes to take effect. 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";

deny (all) 

    user = "anyone";

allow absolute (all) 

    user = "employees" and

    dns = "*.emp.mozilla.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:

  1. In the Server Manager, choose Server Preferences|Restrict Access.

  2. In the section called Pick a Resource, click the Browse button. In the form that appears, click the link for the directory you want to restrict. The directories listed in this form 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 the Options button and check the box labeled "List files as well as directories" and then click OK.

  1. Click Edit Access Control. The two-frame forms appear.
  2. 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.
  3. Click the Deny link in the second rule. In the bottom form that appears, check Allow, and then click Update.
  4. Click the "anyone" link in the second rule. In the bottom form, type the group you want to have access to the server. For this example, type executives in the Group field. Click Update.
  5. Click the "all" link 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.
  6. Click New Line to create a rule for the "ceo" user. Check Allow for the third rule, as you did in Step 5.
  7. Click the "anyone" link. In the bottom form, type ceo in the User field. Click Update.
  8. 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 2. The form should look like the one in Figure 6.6. Click Submit, and then save and apply your changes.
Restricting access to a path in the server

 

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

 acl "path=d:/netscape/suitespot/docs/senior-staff/";

deny (all) 

    user = "anyone";

allow absolute (read,execute,list,info) 

    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:

  1. In the Server Manager, choose Server Preferences|Restrict Access.

  2. In the section called "Type in the ACL name," type the URI you want to control. For example, type uri=/my_directory. Click Edit Access Control. The two-frame forms appear.

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

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

  5. Click the "all" link in the top frame. Uncheck the Write and Delete access rights. This means users can't add or remove files, but they can view them and run any applications in the directories. Click Update.

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

  7. Click the "anyone" link. In the bottom form, type me in the User field. Click Update.

  8. 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 2. The form should look like the one in Figure 6.7. Click Submit, and then save and apply your changes.
Restricting access to a URI (path) in the document root

 

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:

  1. In the Server Manager, choose Server Preferences|Restrict Access.

  2. In the section called "Pick a resource," click the Wildcard button. 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.

  3. Click Edit Access Control. The two-frame forms appear.

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

  5. Click the Deny link. In the bottom form 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 users can't add or remove files or directories with the .cgi extension. Click Update.

  7. Click New Line to create a rule that allows write and delete access to the "programmers" group. Check Allow for the second rule, like you did in Step 5.

  8. Click the "anyone" link. In the bottom form, type programmers in the Group field. Click Update. The form should look like the one in Figure 6.8. Click Submit and then save and apply your changes.
Restricting access to a file type--in this case, to files with the .cgi extension

 

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 server checks ACLs in this 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:

  1. In the Server Manager, choose Server Preferences|Restrict Access. In the section called Pick a Resource, select "The entire server" from the Editing drop-down list. (You can select any resource.) Click Edit Access Control. The two-frame forms appear.

  2. Click New Line.

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

  4. 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.

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

  6. Click the X link to create a customized expression. In the bottom form, edit the existing lines to include the following:

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

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

  8. 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.

 

Converting a 2.0 ACL file

If you have a 2.0 server installed when you install the 3.0 server, you'll have the option of converting your 2.0 ACL file to a 3.0 format. You can also convert them after installation. For example, if you have the access-control files on a different computer, you can copy them to the 3.0 server computer and then convert them.

To convert 2.0 ACL files:

  1. Choose System Settings|Convert 2.0 ACL File.

  2. By default, the server assumes you copied the 2.0 file to the directory server_root/httpacl and named the file generated.https-serverid.acl. If you have copied and renamed the file, check the Default radio button and then click OK. If you haven't copied and renamed the file, follow the rest of these steps.

  3. Type the absolute path to the 2.0 access control file.

  4. Type a file name you want to assign to the 3.0 file. If you don't specify a 3.0 file name, the 2.0 file is converted and saved with the default name generated.https-serverid.acl.
Warning

If you don't specify a 3.0 path and filename, the conversion will overwrite the default 3.0 file if one exists.

  • Click OK.

  • If your 2.0 ACL files contain references to databases, convert the database entries to the 3.0 local database or LDAP directory. You might need to edit the userdb/dbswitch.conf file to reference the database files.

  • Restart the web server. (From the Server Manager, choose Server Preferences|On/Off, and then click Server On to restart the web server.)
  • Once the file is converted, you can manually edit it. Or if you converted to the default file generated.https-serverid.acl, you can use the Server Manager forms to edit the settings.

     


    Copyright 1997 Netscape Communications Corporation. All rights reserved.