This chapter describes how to add, delete, and edit the users and groups who can access your server.
The Administration Server provides access to your application data about user accounts, group lists, access privileges (ACL), organization units, and other user- and group-specific information.
User and group information is stored either in flat files in text format or in a directory server such as the Sun Java System Directory Server, which supports Lightweight Directory Access Protocol (LDAP). LDAP is an open directory access protocol that runs over TCP/IP and is scalable to a global size and millions of entries.
A directory server such as the Sun Java System Directory Server enables you to manage all your user information from a single application. You can also configure the directory server to allow your users to retrieve directory information from multiple, easily accessible network locations.
In Web Server 7.0, you can configure three different types of directory services to authenticate and authorize users and groups. If no other directory service is configured, the new directory service created will be set to the value default, irrespective of its type.
When you createa directory service, the server.xml file is updated with the directory service details.
The different types of directory services supported by Web Server 7.0 are:
LDAP — Stores user and group information in an LDAP-based directory server.
Key File — A text file that contains the user’s password in a hashed format, and the list of groups to which the user belongs. The users and groups stored in a key file are used for authorization and authentication by the file realm alone; these bear no relationship to system users and groups.
The key file format can only be used when the intent is to use HTTP Basic authentication.
Digest File — Stores user and group information based on encrypted username and password.
The digest file format is meant to support using HTTP Digest authentication. It does, however, also support Basic authentication, so it can be used for both authentication methods.
If you want to set up distributed administration, the default directory service must be an LDAP-based directory service.
A user is an individual in your LDAP database, such as an employee of your company. A group is two or more users who share a common attribute. An organizational unit is a subdivision within your company.
Each user and group in your enterprise is represented by a Distinguished Name (DN) attribute. A DN attribute is a text string that contains identifying information for an associated user, group, or object. You use DNs whenever you make changes to a user or group directory entry. For example, you need to specify DN information each time you create or modify directory entries, set up access controls, and set up user accounts for applications such as mail or publishing.
The preceding figure shows a sample DN representation. The following example represents a typical DN for an employee of Sun Microsystems:
uid=doe,e=doe@sun.com,cn=John Doe,o=Sun Microsystems Inc.,c=US
The abbreviations before each equal sign in this example have the following meanings:
uid: user ID
e: email address
cn: the user’s common name
o: organization
c: country
DNs may include a variety of name-value pairs. They are used to identify both certificate subjects and entries in directories that support LDAP.
If you do not currently have a directory, or if you want to add a new subtree to an existing directory, you can use the Directory Server’s Administration Server LDIF import function. This function accepts a file containing LDIF and attempts to build a directory or a new subtree from the LDIF entries. You can also export your current directory to LDIF using the Directory Server’s LDIF export function. This function creates an LDIF-formatted file that represents your directory. Add or edit entries using the ldapmodify command along with the appropriate LDIF update statements.
To add entries to the database using LDIF, first define the entries in an LDIF file, then import the LDIF file from Directory Server.
The Authentication Database, also referred to as auth-db, represents a database of known users and the mechanism for authenticating client requests against that database. The server can have multiple auth-db entries configured at the same time and these may be of the same type. The auth-db user databases are used by the ACL processing module.
The server supports the following authentication databases:
LDAP — The user data is stored in an LDAP directory server, such as the Sun Java System Directory Server.
File — The user data is stored in a disk file. This auth-db is particularly convenient for development or small deployments where no centralized user management is available (or desired). The file auth-db supports several different file formats:
keyfile — The keyfile format stores a list of users (and optional group memberships for each user). The password is stored as a one-way (unrecoverable) hash. This is the default format.
digestfile — The digestfile is very similar to the keyfile and also supports the HTTP Digest authentication method.
htaccess — The htaccess is a legacy format and should never be used for new installations or adding new users.
PAM — PAM is the new auth-db supported by Web Server . The PAM auth-db delegates the authentication to the Solaris PAM stack, this enables existing Solaris users on the web server system to authenticate to the web server as well.
PAM auth-db is only supported in Solaris 9 and 10 (or higher) and the web server instance must be running as root.
FTo create an authentication database through the Administration Console, click Configurations > Configuration Name > Access Control > Authentication Databases > New button. Check out the Administration Console Inline help for field descriptions. Based on the selected Authentication Database, the fields change. For example, for PAM based Authentication DB, only the authentication DB name is required.
The options required to create an Authentication Database are enumerated here:
LDAP |
|
Key FIle |
|
Digest File |
|
PAM |
|
To create an authentication database through CLI, execute the following command.
wadm> create-authdb --user=admin --password-file=admin.pwd --host=serverhost --port=8989 --config=config1 --url=ldap://ldapserver.com:20002/dc=xxx,dc=sun,dc=com LDAP1 |
See CLI Reference, create-authdb(1).
In the previous example, a URL has been specified for the authentication database. The type of authentication database is specified in this URL scheme. For example, ldap://ds.example.come/dc=example,dc=com configures an LDAP directory server as an authentication database.
The Administration Server enables editing user accounts, group lists, access privileges, organization units, and other user- and group-specific information for both LDAP and File auth-db types.
Click the Configuration tab to see a list of users and select the configuration you need.
Click the Access Control > Users tab.
Click the New button.
Add User Information.
Enter the user id and password. Optionally enter the group which the user belongs to. The user ID must be unique. In case of LDAP based authentication DB, the Administration Server ensures that the user ID is unique by searching the entire directory from the search base (base DN) down to see if the user ID is in use. Be aware, however, that if you use the Directory Server ldapmodify command line utility (if available) to create a user, that it does not ensure unique user IDs.
Using CLI
To create a user through CLI, execute the following command.
wadm> create-user --user=admin --password-file=admin.pwd --host=serverhost --port=8989 --config=config1 --authdb=KEYFILE1 --full-name=keyfile-config1-u1 keyfile-config1-u1 |
See CLI Reference, create-user(1).
Select the configuration from the configuration list. Click Configurations tab to get the list.
Click Access Control > Groups tab.
Click the New button.
Enter the Group Name.
From the Add Users To Group section, search and add existing users to the group.
Creating a group in an authentication database like keyfile or digestfile requires atleast one user to be specified.
Using CLI
To create a group through CLI, execute the following command.
wadm> create-group --user=admin --password-file=admin.pwd --host=serverhost --port=8989 --config=config1 --authdb=LDAP1 group1 |
See CLI Reference, create-group(1).
Select the configuration from the configuration list. Click Configurations tab to get the list.
Click the Access Control > Users tab.
Select the authentication database from which you need to delete the user.
Enter the User ID in the Search Users text box and click the Search button.
Select the user from the UserID column and click the Delete button.
Deleting users from a keyfile or digestfile authentication database will delete any associated groups even if the groups contain no members. Groups without members are not allowed in keyfile or digestfile authentication databases.
Using CLI
To delete a user through CLI, execute the following command.
wadm> delete-user --user=admin --password-file=admin.pwd --host=serverhost --port=8989 --config config1 --authdb KEYFILE1 user1 |
See CLI Reference, delete-user(1).
Select the configuration from the configuration list. Click Configurations tab to get the list.
Click the Access Control > Groups tab.
Select the authentication database from which you need to delete the group.
Enter the Group Name in the Search Users text box and click the Search button.
Select the group from the Group Name column and click the Delete button.
Deleting a group does not delete the users belonging to the group. You have to delete the users manually or reassign groups.
Using CLI
To delete a group through CLI, execute the following command.
wadm> delete-group --user=admin --password-file=admin.pwd --host=serverhost --port=8989 --config config1 --authdb LDAP1 group1 |
See CLI Reference, delete-group(1).
A group is a set of objects in an LDAP database. In Web Server 7.0 a group consists of users who share a common attribute. For example, the set of objects might be the number of employees who work in the marketing division of your company. These employees might belong to a group called Marketing.
For LDAP services, there are two ways to define membership of a group: statically and dynamically. Static groups enumerate their member objects explicitly. A static group is a CN and contains uniqueMembers and/or memberURLs and/or memberCertDescriptions. In static groups, the members do not share a common attribute except for the CN=<Groupname> attribute.
Dynamic groups allow you to use a LDAP URL to define a set of rules that match only for group members. In Dynamic Groups, the members do share a common attribute or set of attributes that are defined in the memberURL filter. For example, if you need a group that contains all employees in Sales, and they are already in the LDAP database under
“ou=Sales,o=Airius.com,” you’d define a dynamic group with the following memberurl:
ldap:///ou=Sales,o=Airius.com??sub?(uid=*)
This group would subsequently contain all objects that have an uid attribute in the tree below the “ou=Sales,o=sun” point; thus, all the Sales members.
For static and dynamic groups, members can share a common attribute from a certificate if you use the memberCertDescription. Note that these attributes will only work if the ACL uses the SSL method.
Once you create a new group, you can add users, or members, to it.
For LDAP services, the Administration Server enables you to create a static group by specifying the same group attribute in the DNs of any number of users. A static group doesn’t change unless you add a user to it or delete a user from it.
Consider the following guidelines when using the Administration Server forms to create new static groups:
Static groups can contain other static or dynamic groups.
You can optionally also add a description for the new group.
If any organizational units have been defined for your directory, you can specify where you want the new group to be placed using the Add New Group To list. The default location is your directory’s root point, or topmost entry.
A dynamic group has an objectclass of groupOfURLs, and has zero or more memberURL attributes, each of which is a LDAP URL that describes a set of objects.
For LDAP services, Web Server enables you to create a dynamic group when you want to group users automatically based on any attribute, or when you want to apply ACLs to specific groups which contain matching DNs. For example, you can create a group that automatically includes any DN that contains the attribute department=marketing. If you apply a search filter for department=marketing, the search returns a group including all DNs containing the attribute department=marketing. You can then define a dynamic group from the search results based on this filter. Subsequently, you can define an ACL for the resulting dynamic group.
Web Server implements dynamic groups in the LDAP server schema as objectclass = groupOfURLs. A groupOfURLS class can have multiple memberURL attributes, each one consisting of an LDAP URL that enumerates a set of objects in the directory. The members of the group would be the union of these sets. For example, the following group contains just one member URL:
ldap:///o=mcom.com??sub?(department=marketing)
This example describes a set that consists of all objects below "o=mcom.com" whose department is "marketing." The LDAP URL can contain a search base DN, a scope and filter, however, not a hostname and port. This means that you can only refer to objects on the same LDAP server. All scopes are supported.
The DNs are included automatically, without your having to add each individual to the group. The group changes dynamically, because Web Server performs an LDAP server search each time a group lookup is needed for ACL verification. The user and group names used in the ACL file correspond to the cn attribute of the objects in the LDAP database.
Web Server uses the cn (commonName) attribute as group name for ACLs.
The mapping from an ACL to an LDAP database is defined both in the dbswitch.conf configuration file (which associates the ACL database names with actual LDAP database URLs) and the ACL file (which defines which databases are to be used for which ACL). For example, if you want base access rights on membership in a group named "staff," the ACL code looks up an object that has an object class of groupOf<anything> and a CN set to "staff." The object defines the members of the group, either by explicitly enumerating the member DNs (as is done for groupOfUniqueNames for static groups), or by specifying LDAP URLs (for example, groupOfURLs).
A group object can have both objectclass = groupOfUniqueMembers and objectclass = groupOfURLs; therefore, both "uniqueMember" and "memberURL" attributes are valid. The group’s membership is the union of its static and dynamic members.
There is a server performance impact when using dynamic groups. If you are testing group membership, and the DN is not a member of a static group, Web Server checks all dynamic groups in the database’s baseDN. Web Server accomplishes this task by checking if each memberURL matches by checking its baseDN and scope against the DN of the user, and then performing a base search using the user DN as baseDN and the filter of the memberURL. This procedure can amount to a large number of individual searches.
Consider the following guidelines when using the Administration Server to create new dynamic groups:
Dynamic groups cannot contain other groups.
Enter the group’s LDAP URL using the following format (without host and port info, since these parameters are ignored):
ldap:///<basedn>?<attributes>?<scope>?<(filter)>
The required parameters are described in the following table:
Note that the <attributes>, <scope>, and <(filter)> parameters are identified by their positions in the URL. If you do not want to specify any attributes, you still need to include the question marks delimiting that field.
You can optionally also add a description for the new group.
If any organizational units have been defined for your directory, you can specify where you want the new group to be placed using the Add New Group To list. The default location is your directory’s root point, or topmost entry.