ImportantAlthough Netscape servers support multiple databases, you might need only one database for all your users. The main reason for maintaining multiple databases is if you have different servers installed on the same computer. A mail server might have a completely different database than a news server or a web server. If you're only maintaining one server on your computer, however, you'll find it's easier to keep track of your users if they're all in the same database. If you need to separate your users, use the grouping features described on page 76. (Netscape servers support multiple databases because older server programs did not have grouping capabilities.)
The server stores its databases in authdb in the root server directory. When specifying a database, use only its name, not its directory path. Using the Manage User Databases form, you can perform the following tasks with databases:
You can have any number of users in your database, and you can put them into as many groups as you like. For example, you might want to separate your users into a Personnel group and a Sales group. You can put a user into more than one group.
You can also maintain multiple databases, but it's much easier to keep track of your users if they're in one database. (Multiple databases are remnants of older server programs that did not have grouping capabilities.)
You can create users, remove them, or change their passwords. You can also list all the users in your database.
Creating a user
To import users from an existing database, see "Importing users" on page 79. To add a user manually:
d*
into the Filter field. For more information on wildcard patterns,
refer to "Understanding wildcard patterns" on page 42.
To save even more time, you can also put other groups into a group. For example, your Sales and Marketing groups could both be part of the group Business. A group may belong to multiple other groups.
The members of a group must all be within the same database. It's recommended that you use only one database for all your users, since your users are easier to keep track of that way, and you can more fully exploit the power of grouping. Also, user databases are shared across all servers that are installed (web servers, mail servers, news servers, and so on), so you may want to have a different database for each server to avoid confusion.
If you need to separate your users, use the grouping features. Netscape servers support multiple databases because older server programs did not have grouping capabilities.
You can create or remove groups, or edit their contents. You can also list the contents of groups.
Creating a group
To create a group:
Removing a group
Removing a group does not remove the individual users in the group from the database. To remove a group from a database:
NoteThe groups and users are not selected unless they are highlighted.
s*
into the Filter field. For more information on wildcard patterns, see
"Understanding wildcard patterns" on page 42.
user1:password1 user2:password2 user3:password3To import users from an existing file:
:
password1:x:x:
Full User Name 1
If you have user or group identification numbers, you can use those instead of x:x.
If you are directly importing Unix password files, x:x would be replaced with the numeric user and group IDs.
To change the access control for part of your server:
When you set these access defaults, they will apply to everyone attempting to read or write to the files or directories you specified earlier.
404 Not Found
.
When determining the exceptions who are denied access, you can specify users from specified hostnames or IP addresses.
First you must specify how hostnames are processed. If you want to deny users from only the exact hostnames you'll specify below, click Include specified names only. However, if you also want to deny users from alias domains of your specified hostnames, click Include aliases of specified names.
To deny users from specific hostnames or IP addresses, type a comma-separated list of hostnames or IP addresses in the text fields. 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, and/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.
Allowing access to a resource
In the Restrict Access form described on page 80, you set the default read and write access of a resource (a directory or group of files). If you set read or write access to deny all access by default, you can specify exceptions by clicking the Permissions button. The Allow Access to a Resource form appears.
When determining the exceptions who are allowed access, you can specify two types of users:
If you will be specifying hostnames to allow users from, decide how you want the hostnames processed. If you want to allow only users from the exact hostnames you'll specify, click Include specified names only. However, if you also want to accept users from alias domains of your specified hostnames, click Include aliases of specified names. To allow users from specific hostnames or IP addresses, enter a wildcard pattern of hostnames or IP addresses in text fields. 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. But on the other hand, restricting by IP address is more reliable--if a DNS lookup fails for a connected client, hostname restriction cannot be used. If someone is allowed access by virtue of their hostname or IP address (as in steps 1 and 2 on page 83), they are not prompted for a login name or password (or their certificate). All other users are asked for that information. To allow access to the users listed in your database, follow these steps:
Sales information
, users would see the following when they tried to the restricted pages:
Enter the username for Sales information at
[servername]
cvuser [-i ncsa-file|-d ndbm-file] [-cfhu] outputdbThe following describes the syntax. (You can also get this information online by typing mkuser -h.)
Managing database users
Using the command-database utilities to create, edit, and remove users is equivalent to using the Server Manager forms to manage database users.
Creating a user
Use the mkuser command to create a user in a database. To run mkuser, type the following command and options at the command prompt:
mkuser [-n real-user-name] [-p encrypted-password] [username]
[authdb-directory]
The following describes the syntax. (You can also get this information online by typing mkuser -h.)
-n real-user-name | User's real name |
-p encrypted-password | User's password |
To create a username of jdoe for John Doe in the marketing database, type the following at the command prompt:
mkuser -n `John Doe' -p"mb!i12mo" jdoe /usr/ns-home/authdb/marketing
Editing a user
Use the chuser command to edit an existing user in a database. To run chuser, type the following command and options at the command prompt:
chuser [-a new-username] [-n real-user-name] [-p encrypted-password] [-u user-id] [username] [authdb-directory]
The following describes the syntax. (You can also get this information online by typing chuser -h.
-a new-username | New username for existing user |
-n real-user-name | User's real name |
-p encrypted-password | User's password |
-u user-id | Use the -u option to specify the user ID rather than the username |
To change the username for John Doe from jdoe to johndoe in the marketing database, type the following at the command prompt:
chuser -ajohndoe -n `John Doe' jdoe /usr/ns-home/authdb/marketing
To specify the user ID rather than the username of johndoe and change the password, type the following at the command prompt. (You can get the user ID by using the shuser command, which is described in the "Showing information about an existing user" section.)
chuser -u263 -pmgi28mo /usr/ns-home/authdb/marketing
Removing an existing user
Use the rmuser command to remove an existing user from a database. To run rmuser, type the following command and options at the command prompt:
rmuser [-u user-id] [username] [authdb-directory]
The following describes the syntax. (You can also get this information online by typing rmuser -h.)
-u user-id | User ID, used instead of username |
To remove the username for John Doe from the marketing database, type the following at the command prompt:
rmuser jdoe /usr/ns-home/authdb/marketing
Showing information about an existing user
Use the shuser command to show information about an existing user in a database. To run shuser, type the following command and options at the command prompt:
shuser [-u user-id] [-N] [username] [authdb-directory]
The following describes the syntax. (You can also get this information online by typing shuser -h.
To show information about John Doe (jdoe) from the marketing database, type the following at the command prompt:
shuser jdoe /usr/ns-home/authdb/marketing
Information about the user John Doe appears:
Username: jdoe
Password: AOFoNlqb
User id: 249
Flags: 0x0
Real name: John Doe
The following describes the information you see.
Username | The username of the user. |
Paword | The password for the user |
User id | The User ID for the user. |
Flags | Reserved (currently unused) |
Real name | The user's name. |
To show information about all the users in the marketing database, type the following at the command prompt:
shuser "*" /usr/ns-home/authdb/marketing
Output similar to the following appears:
jdoe:pmgi28mo:::John Doe
chris:34dwvez:::Chris Smith
Managing database groups
Using the command-database utilities to create, edit, and remove groups is equivalent to using the Server Manager forms to manage database groups.
Creating a group
Use the mkgroup command to create a user in a database. To run mkgroup, type the following command and options at the command prompt:
mkgroup [-d group-description] [-g group-list] [-u user-list]
[group-name] [authdb-directory]
The following describes the syntax. (You can also get this information online by typing mkgroup -h.
To create a group called domestic in the marketing database, type the following at the command prompt:
mkgroup -d `Engineering group' domestic /usr/ns-home/authdb/marketing
Editing a group
Use the chgroup command to edit a group in the database. To run chgroup, type the following command and options at the command prompt:
chgroup [-ar] [-d group-description] [-g group-list] [-u user-list] [-i
group-id] [group-name] [authdb-directory]
The following describes the syntax. (You can also get this information online by typing chgroup -h.)
-d group-description | Description of the group |
-g group-list | List of groups |
-u user-list | List of users |
To edit a group called domestic in the marketing database, type the following at the command prompt:
chgroup -d `domestic marketing' domestic /usr/ns-home/authdb/marketing
Removing a group
Use the rmgroup command to edit a group in the database. To run rmgroup, type the following command and options at the command prompt:
rmgroup [-i group-id] [group-name] [authdb-directory]
The following describes the syntax. (You can also get this information online by typing rmgroup -h.)
-i group-id | Use this option to specify the group ID rather than the group name. |
To remove a group called domestic in the marketing database, type the following at the command prompt:
rmgroup domestic /usr/ns-home/authdb/marketing
Showing information about a group
Use the shgroup command to show information about an existing group in a database. To run shgroup, type the following command and options at the command prompt:
shgroup [-i group-id] [-N] [group-name] [authdb-directory]
The following describes the syntax. (You can also get this information online by typing shgroup -h.)
To show information about the domestic group in the marketing database, type the following at the command prompt:
shgroup domestic /usr/ns-home/authdb/marketing
Information about the group domestic appears:
Group name: domestic
Group id: 250
Flags: 0x0
The following describes the information you see.
Group name | The username of the user |
Group id | The password for the user |
Flags | Reserved (currently unused) |
To show information about all the groups in the marketing database, type the following at the command prompt:
shgroup "*" /usr/ns-home/authdb/marketing
Information about the groups appears in the following format:
group-name:group-description:member-group-list:member-user-list
Note that the member-group-list and the member-user-list are comma-separated lists of member group names and usernames, respectively. These lists might span multiple lines, and therefore contain spaces and newline characters.
Access control list files
An access control list (ACL) file is a text file that contains lists used to control access to server resources. Each list has its own name and a set of specific access control rights it controls. The list specifies information about which clients are allowed or denied access and how to authenticate users. Note that an ACL file does not contain information about which server resources are affected; the directives in the obj.conf file contain references to ACLs that are defined in the ACL file.
When you use the Server Manager to restrict access control, the changes are added to a file called genwork.httpd-[servername].acl, which is located in the httpacl directory in your server root directory; this file contains changes that you have made but not saved and applied yet. After you save and apply your changes, the information you entered is added to a file called generated.httpd-[servername].acl, which is also located in the httpcl directory.
The following is an example of the generated.httpd-[servername].acl.
ACL httpd-server1_formgen-READ-ACL-allow-2898 (GET, HEAD, POST, INDEX) {
Default allow anyone;
}
ACL httpds-server1_formgen-WRITE-ACL_deny-2898 (PUT, DELETE, MKDIR,
RMDIR, MOVE) {
Default deny anyone;
}
ACL httpd-server1_formgen-WRITE-ACL_deny-2249 (PUT, DELETE, MKDIR,
RMDIR, MOVE) {
Default deny anyone;
Default authenticate in {
Database "/usr/ns-home/authdb/default";
Method basic;
};
Default allow all;
}
ACL httpd-server1_formgen-READ-ACL_allow-2249 (GET, HEAD, POST, INDEX) {
Default deny anyone;
Default authenticate in {
Database "/usr/ns-home/authdb/default";
Method basic;
Prompt "Database users";
};
Default allow all;
}
You can have more than one ACL file for your server by specifying multiple ACLFile directives in the magnus.conf file. If you have multiple ACL files, make sure that the ACL names defined in your files, including the generated ACL file, do not conflict with each other. For more information about ACL file syntax, see the "ACL file syntax" section.
For example, you would include the following lines in your magnus.conf file if you wanted to use a generated ACL file and an ACL file called engineer.acl.
ACLFile /usr/ns-home/httpacl/generated.httpd-server1.acl
ACLFile /usr/ns-home/httpacl/engineer.acl
The following is an example of what a directive in the obj.conf file might look like.
<Object ppath="/usr/docs/private/*">
PathCheck fn="check-acl"
acl="read-private"
path="*.doc"
bong-file="/usr/docs/errors/deny.htm"
</Object>
By specifying path="*.doc" the ACL would only be applied to files with a .doc extension. The file specified for bong-file is what is sent to the client if access is denied.
ACL file syntax
You can use letters, numbers, hyphens, and underscores in the ACL file; identifiers, which include ACL names, access-control rights, usernames, and group names, must begin with a letter. Usernames, group names, and database names are case-sensitive; other identifiers are not case-sensitive. You can use spaces, tabs, and newline characters in an ACL file. Comments are specified with # at the beginning of the line and with a newline character.
An ACL file contains a list of ACL definitions, which specify an ACL name, access control rights that are controlled by the ACL, and ACL statements. An example of an ACL definition:
ACL acl-name access-rights {
acl-statements
}
The following defines the parts of the ACL definition.
ACL specs (GET, HEAD) { Default authenticate in { Database "engineers"; Method basic; }; Default allow all at *; Default deny jdoe at *; }In the first ACL statement in the previous example, the database named engineers is being used to store access-control user and group definitions. Basic authentication, which requires that users enter a username and password, is being specified as method used to verify users. The second ACL statement specifies that all users in the engineers database have GET and HEAD access rights as long as they provide a valid username and password, which are stored in the database. The last ACL statement specifies that the user jdoe will be denied access, even after entering a username and password.
ACL specs (GET, HEAD) { Default authenticate in { Database "engineers"; Method SSL; }; Default deny anyone at *; Default allow all at *.netscape.com; Default deny temps at *.netscape.com; }In the first ACL statement in the previous example, the method of authentication specified is SSL. Only users who can authenticate themselves using an SSL client certificate will be allowed access. The second statement denies access to everyone at any host. The third statement allows access to everyone in the engineers database who connects using a system with DNS names ending with netscapst statement denies access to any users in the group called temps.