Chapter 15: Authenticating RealServer Users

RealServer authentication provides a way for you to control what or who can access your RealServer, whether it is an encoder sending a stream, a colleague perusing RealSystem Administrator, or a user viewing content for which they've paid.

Overview

Authentication verifies the identity of the users or software that make requests of RealServer. The verification can come in the form of asking for a name and password, or it can be hidden from the user.

You can require a name and password for the following RealServer areas:

• Encoder users-Require content creators to supply a name and password before sending their live streams to RealServer. In this way, only authorized people can send streams to your RealServer.

• RealSystem Administrator users -Allow certain people in your organization to use RealSystem Administrator. To protect your RealServer from changes made by unauthorized users, RealServer is installed with authentication turned on for RealSystem Administrator access.

• Individual users-The most popular use of all is limiting user access to individual presentations or directories of clips. An additional database can be used to list which content each user can view, and what type of access they have. Several additional options are available for this type of authentication.

The names of authorized users for each item above are stored in separate databases. One database stores the names for the authorized encoder users, another stores names of other administrators, and still another stores names of people who can view presentations. You can set up additional authentication areas and databases.

RealServer identifies requests (in the form of URLs) for secure content by the mount point. The URL must contain the mount point, and it may contain additional directory information. Encoders are an exception to this-RealServer looks at the port number at which live data arrives in deciding whether it should accept the connection.

	Additional Information
	To limit visitors to RealServer via bandwidth, connection volume, client version, or IP address, use the methods described in Chapter 14, "Limiting Access to RealServer".

Compatible Client Versions

RealPlayer versions 3 and earlier do not work with authentication and may display an error message. RealPlayer 4 works with player validation only. RealPlayer 5 and later support both player validation and user authentication.

When to Use Authentication

The following are factors in deciding to use this feature:

• You are hosting material to which you want to limit access, and you want to use a more specific method than noting the client's IP address. (The access control list enables access based on the client's address.)

• You want to allow different types of access to different types of material.

• You want to collect data from users before they play your clips. (Collecting data is not necessarily part of authentication; it is just something you can require if you implement authentication.)

• You want clients to pay money before or after playing clips.

• You want to track how much time specific users are playing certain clips.

Authentication Used with Other Features

Authentication works with all other RealServer features. There are few special considerations for each feature, however.

On-Demand Streaming and Authentication

All on-demand files stored in the Secure directory (or in any subdirectories) are authenticated automatically, once the authentication feature has been set up.

Live Unicasting and Authentication

Once the authentication feature has been set up, live broadcasts are authenticated automatically if they include /secure/ as part of the path when you encode the events.

Archiving and Authentication

Archived files are on-demand files; they can be authenticated if they are moved to the correct location first. They must be placed in the Secure directory or in a subdirectory of Secure, or the archiving feature must be configured to use the Secure directory.

G2SLTA and Authentication

Just like any other live event, broadcasts created by G2SLTA can be authenticated, as long as you include /secure/ in the path you type for livefile. For an example, see "Unicasted Live Content (from Encoders)".

Splitting and Authentication

If you are sending a stream to a RealServer that is acting as a receiver, you must put copies of all the databases that store authentication information on the receiver. This distributes the authentication load.

Multicasting and Authentication

In both back-channel and scalable multicasts, the user or client is authenticated through the initial control channel connection. Be sure the multicast (either / or /scalable/) path is on the list of Commerce Rules.

RealProxy and Authentication

RealProxy makes requests on behalf of clients, and caches the streams it receives. Although RealProxy stores the streamed data, it requires a control channel between the requesting client and RealServer. RealServer uses the control channel to request and receive authentication information.

Firewalls and Authentication

Authentication is performed over the two-way control channel. As long as the client can establish a connection through the firewall to RealServer, all material can be authenticated for clients who are behind firewalls.

Access Control and Authentication

The access control feature, which checks the client's IP address against a list of allowed addresses, takes place before authentication. So if a client's IP address is blocked, authentication will not take place. If you have users who should be able to play secure material are receiving error messages, check the list of access rules to see if their client's address is disallowed.

ISP Hosting and Authentication

Authentication of content cannot be applied to the files of ISP-hosted customers. Their material is always available. Depending on the access needs, you may be able to apply access control rules so that customers can allow or deny certain users' access to content.

Monitoring and Authentication

You can monitor which secure presentations are in use by viewing the paths of the files in Java Monitor. Those that contain the /secure/ mount point are authenticated.

Reporting and Authentication

Efforts to authenticate users are not included in the access log; records are created for successful serves. You can identify authenticated material in the access log by the GET statement; secure material always contains the /secure/ mount point in the path.

In addition, connection attempts for authenticated material are stored in the accesslog.txt file in the Logs directory of appropriate data storage directory (if you are using the text file method), or in the Access_log table (if you are using the database method).

Adding User Names and Passwords

Use the following instructions to add to the list of authorized users for any type of authentication.

	Note
	If you are using Window NT to manage the list of users, passwords, and groups, use those tools instead of the instructions below.

To add a user name and password:

1. In RealSystem Administrator, click Security. Click Authentication.

2. In the Authentication Realms list, select the name of the realm to which you want to add a user:

   • For encoder users, select SecureEncoder.

   • For RealSystem Administrator users, select SecureAdmin.

   • For content authentication users, select SecureContent.

   • For any other category of authentication, select the name of the realm. (To learn more about realms, see "Creating a New Realm".

3. Click Add a User to Realm.

4. In the new window that appears, type the user's name in the Name box.

5. In the Password box, give the user's password.

6. In the Confirm Password box, type the password again.

7. Click OK.

Authenticating Encoder Users

Encoder user authentication is configured automatically at setup; when you installed RealServer, you gave a user name and password for RealServer to use. These were added to the administrator database and the encoder database. Users of RealSystem encoders version 6 and later must supply this user name and password to connect.

	Additional Information
	Other authentication features that can be used in authenticating encoder users are listed in "Optional Authentication Features (for All Types of Users)".

Encoders

RealServer uses the following settings for encoder user authentication (you can view these settings with RealSystem Administrator by clicking Broadcasting>Encoders):

• Encoder Authentication Realm-a realm to use for encoders is included with your RealServer installation, named EncoderRealm. If you want to use a realm which does not yet exist, see "Creating a New Realm".

To add user names and passwords for encoders:

Add each encoder user and password with the instructions in "Adding User Names and Passwords"; use SecureEncoder for the realm.

Pre-G2 Encoders

Content creators who use older encoders need only supply a password, but the password must be the same for everyone. During installation, you were prompted for this password. If you change the password with RealSystem Administrator, be sure to tell the new password to everyone who will be connecting.

RealServer uses the following settings for encoder user authentication (you can view these settings with RealSystem Administrator by clicking Broadcasting>Pre-G2 Encoders):

• Password-the password which all pre-G2 encoders must supply in order to connect to RealServer.

Authenticating RealSystem Administrator Users

At installation, RealServer is configured to prompt all RealSystem Administrator users for a user name and password. Use the user name and password you entered during Setup.

	Additional Information
	Other authentication features that can be used in authenticating RealSystem Administrator users are listed in "Optional Authentication Features (for All Types of Users)".

To add user names for RealSystem Administrator authentication:

Use the instructions in "Adding User Names and Passwords"; use SecureAdmin for the realm.

Authenticating Content Users

There are four steps to setting up authentication for users and content:

1. Add user names and passwords for users.

2. Give those users access to specific content.

   When RealServer is first installed, it is automatically configured to look for on-demand secure content in the Secure directory.

3. Create the content.

4. Create links to the secure content.

This section describes the steps necessary for authenticating users who request secured media.

	Additional Information
	There are two sets of optional authentication features that can be used in authenticating content users: those listed in "Optional Content User Authentication Features", and the more general options shown in "Optional Authentication Features (for All Types of Users)".

Step 1: Adding User Names and Passwords

Add user names and passwords by following the instructions in "Adding User Names and Passwords"; use SecureContent for the realm.

	Note
	A type of authentication which does not require user names and password is also available; refer to "Player Validation".

Step 2: Giving Users Access to Content

The steps in this section assign access permission to all content stored in the default supplied directory. For live content, these steps use the default live encoding path.

You can have multiple directories that contain secure material, and they can be in different physical locations.

To give users access to secure content:

1. In RealSystem Administrator, click Security. Click Commerce.

2. Choose the rule that matches the type of content you're delivering:

   For on-demand content:

   1. From the Commerce Rules list, select SecureUserContent.

   2. In the Protected Path box, verify that /secure is typed in the box. (This is the name of the default secured directory.) If your content is in a subdirectory, type the full path here. For example, add a subdirectory named Earnings as /secure/Earnings.

      For live content:

   3. From the Commerce Rules list, select SecureG2LiveContent.

   4. In the Protected Path box, verify that /encoder/secure is typed in the box. (This is the name of the default secured directory.) If your content is in a subdirectory, type the full path here. For example, add a subdirectory named Earnings as /secure/Earnings.

      	Note
      	If you use subdirectories, be sure to also add the main secured directory as a Protected Path, or anything you put in the main directory will not be authenticated!)

3. Use the supplied values for all other settings.

4. Click Grant Permission. A new browser window appears.

5. In the Username box, type the name of the first user whose account you created in "Step 1: Adding User Names and Passwords".

6. From the Access Type list, select the type of access you want to give.

   Permission Types

   Type	Access to presentation or presentations in a directory
   Event	Unlimited viewings of a given clip.
   Calendar	Permission expires on a certain date and time. If the date and time of expiration arrives while the visitor plays a clip, transmission of that clip to the player is stopped, and an error message appears.
   Duration	User gets a finite amount of time to view presentations. All viewing time is deducted from this amount, and when time expires, permission is revoked.
   Credit	Time spent viewing presentations is noted by RealServer, and the administrator can use this information later for billing purposes. Access is granted per presentation or directory, and is unlimited.

7. Depending on the option you selected, another dialog box may appear; type the appropriate value in this box.

8. Use the default values for all other settings in this browser window.

9. Click OK.

Step 3: Creating the Content

For on-demand content, place the files in the Secure subdirectory of the main RealSystem Administrator.

For live content, encode it using the virtual path encoder/Secure.

Step 4: Linking to Authenticated Content

Links to individual on-demand or live streams are similar to their non-authenticated counterparts, with the addition of the /secure/ mount point.

To link to authenticated on-demand content:

The link in a Web page to on-demand content, located in the Secure directory, has the following format:

http://address:HTTPPort/ramgen/secure/path/file

where:

To link to authenticated live content:

Live content which will be authenticated has this format:

http://address:HTTPPort/ramgen/encoder/secure/path/file

Notice that it includes the /encoder/ mount point, which invokes the live broadcasting feature.

Optional Content User Authentication Features

There are several more options in setting up content authentication than for encoder or RealSystem Administrator user authentication:

• Allowing Users to View a Clip from More Than One Location

• Player Validation

• Registering Player Validation Users Via Links

• Using the Evaluate Permissions Feature

• Working with SMIL Files

Allowing Users to View a Clip from More Than One Location

If you want a user to be able to log in at more than one location and view the same content from more than one location, set Allow Duplicate IDs to Yes.

Normally, when Allow Duplicate IDs is set to No, a user can view a given clip from only one computer at a time. If a user tries to log in from a second computer and view the same content, he or she will receive an error message. The user must log out at the first location before being permitted to log in at the second location. Users will still be able to view different content even though they are logged in at different locations.

To allow users to view a clip from more than one location:

1. In RealSystem Administrator, select Security. Select Commerce.

2. From the Commerce Rules list, select the rule you created in "Step 2: Giving Users Access to Content".

3. Set Allow Duplicate IDs to Yes.

4. Click Apply.

Player Validation

Player validation allows or denies access to individual clients (usually one per computer), rather than to specific people, and authentication is transparent to the visitor-a dialog box warning only appears when the visitor attempts to access content for which he or she is not authorized. The user isn't asked for a user name and password. This type of authentication involves less viewer interaction than regular user authentication, but each client must be registered individually by the viewer or RealServer administrator.

Player validation requires a user name the first time the user registers. The player ID is associated with the original user name, no matter who is using the client software.

To use player validation:

1. In RealSystem Administrator, select Security. Select Commerce.

2. From the Commerce Rules list, select the rule you created in "Step 2: Giving Users Access to Content".

3. From the Credential Type list, select Use Player Validation.

   Additional options appear in the lower right portion of the browser window.

4. In the Player Registration Prefix box that appears, type a word to use as a registration prefix. The word you use here must be unique; it will be used in the URL for player validation, and identifies to RealServer which Commerce Rule applies to the request.

5. The Redirect Protected Path option enables you to supply a clip which unregistered Players will receive if they click on a link that requires authentication. You might create a clip with a recording of instructions for registering. (Remember to use a non-authenticated clip, or unregistered users won't receive your alternate clip.) To use this option:

   1. Click Redirect Protected Path.

   2. In the new browser window that appears, type the URL for the clip in the Destination URL box. Do not type the full name; instead, type the URL without the protocol and server name. Thus a link that you would normally type as rtsp://realserver.example.com:554/video/real8video.rm would appear in the Destination URL box as video/real8video.rm.

   3. Click OK.

6. Click Apply.

Using Player Validation with Generic Identifiers

Because of privacy concerns, users can elect to suppress the unique identifiers which RealServer and other applications use to identify RealPlayers; instead, RealPlayer will send a generic identifier (GUID) consisting of zeroes.

If users were allowed to register RealPlayers that use this particular GUID, all users with that GUID would log in using the first zero-GUID user's settings. You would not get a true picture of the number of users. To prevent this, RealServer's predefined data stores contain a single record for a "dummy" user with the all-zero GUID, and no permission is granted for this user to access any secure content. All users who have the zero-GUID option selected in their RealPlayer will be denied access to secure content.

For more information about RealPlayer and privacy, please read RealNetworks' Consumer Software Privacy Statement:
http://www.realnetworks.com/company/privacy/software.html.

Automating Registration

In its default state, RealServer requires that you individually add the names of users to the appropriate databases before they can receive secure content. This is feasible if you are administering RealServer for a small site. But in case you want to allow users to register themselves via a Web page, some versions of RealServer include a sample CGI program and HTML files that interact with a Web site and your RealServer so that users may register themselves. To set up self-registration, you'll need to customize two sets of supplied files: HTML pages containing forms for registration, and .cgi files that connect the .htm files with RealServer and the data storage files. Instructions are located within the Commerce subdirectory of the main RealServer directory.

Registering Player Validation Users Via Links

To quickly register individual RealPlayers when player validation is in use, you can customize the link that users click so that RealServer registers and recognizes the client software in one step.

You can also use these instructions as a basis for writing your own CGI scripts and Web pages to accomplish the same purpose automatically.

	Note
	If you are automating this procedure, you may omit Step 1. A realm is only required if you add users from RealSystem Administrator.

To register players:

1. Create a realm to use for player validation:

   1. In RealSystem Administrator, click Security. Click Authentication.

   2. In the Authentication Realms area, click Add New.

      A generic realm name appears in the Edit Realm Description box.

   3. In the Edit Realm Description box, type a name for this realm. For instance, type SecurePlayer.

   4. Click Edit.

   5. In the Realm ID box, type a unique text string. For example, SP.

   6. From the Authentication Protocol list, select RealSystem 5.0.

   7. From the Database list, select the supplied PlayerContent option.

   8. Click Apply.

2. Add a user name:

   1. In RealSystem Administrator, click Security. Click Authentication.

   2. In the Authentication Realms list, select SecurePlayer.

   3. Click Add a User to Realm.

   4. In the new window that appears, type the user's name in the Name box. (You don't need to supply a password for Player Validation). For example, type Chris.

   5. Click OK.

3. Give permission to the user you just created:

   1. In RealSystem Administrator, click Security. Click Commerce.

   2. From the Commerce Rules list, select SecurePlayerContent.

   3. Make a note of the value shown in the Player Registration Prefix box; you'll use this value in the self-registration link. The default value is register.

   4. Click Grant Permission.

      A new browser window appears.

   5. In the Name box, type a user name.

   6. Click OK.

4. Now register a RealPlayer with the special self-registration URL. (The syntax of the special URL format is shown "Web Page Self-Registration URL Format".)

   • For a Web page, use a link such as the following.

     http://realserver.example.com:8080/ramgen/registerChris!real8audio.rm

     The user clicks the link and is added to the database; she can then begin viewing secure content.

   • For a link that the user can paste into the File>Open Location box of RealPlayer, create a link such as:

     rtsp://realserver.example.com:554/registerChris!real8audio.rm

Web Page Self-Registration URL Format

The following shows the syntax to use in creating a link that can be used to register Players automatically, as shown in the preceding section.

http://address:HTTPPort/ramgen/PrefixUsername!file 




 RealServer URL Components 

Component
Meaning


http
The protocol used to initiate streaming. Always use http in Web pages. 


address
Address of RealServer; IP address or machine and domain name.


HTTPPort
Port number where RealServer listens for requests sent via HTTP. Its default value is 8080. 


ramgen
Ram file generator mount point.  


Prefix
Prefix as shown in the Player Registration Prefix box (on the Security>Commerce page of RealSystem Administrator). 


Username
User's name as it will appear in the database; you typed this in Step e of "Add a user name:". 


!
This delimiter separates the user name from the file name. 


file
The name of the presentation, including the extension. Do not use a file located in a secure directory.

For a link that users can type or paste directly in the File>Open Location dialog box in RealPlayer, use the following syntax:

rtsp://address:RTSPPort/PrefixUsername!file 

Using the Evaluate Permissions Feature

Once RealServer has verified the identity of the user or client, an additional level of verification is available: it can allow access to all files or only to very specific files. Evaluate Permissions controls this; when set to No, it allows general access to all authenticated users or players. When set to Yes, RealServer performs the additional step of examining the requested URL and looking for it in the database. If the user or player who requested it has permission for that clip or content path, RealServer streams the requested file.

If you'll be looking up permissions for specific files or directories, you must also indicate the database which stores the clip permission information. This database can be the same as the database that stores user names and passwords.

To set up access to all material or to specific material only:

1. In RealSystem Administrator, click Security. Click Commerce.

2. From the Commerce Rules list, select the rule you created in "Step 2: Giving Users Access to Content".

3. From the Evaluate Permissions list, select Yes.

4. Click Apply.

You can use a different setting for each rule.

If you selected this box, you must also set up the different permissions type for each user and each clip or directory to which you'll be giving them access. See the following section for a list of the different permission types.

Working with SMIL Files

Users are prompted only once per realm for name and password for SMIL files, regardless of how many files in the presentation require a name and password. When the user clicks on a link to a SMIL presentation that contains secure materials, RealServer prompts the player for security information on the first clip. The player then prompts the user for an authorized name and password. The player then stores the information and supplies it when the RealServer asks for security information on remaining clips in that realm.

Should any clip in the presentation expire sooner than the others, the entire presentation will halt. The person viewing the presentation will not be able to continue until more time is allotted by the administrator.

For this reason, it is important that all the permissions on all the files within a presentation be the same.

The best methods of organizing authentication and SMIL files are the following:

• Authenticate the SMIL file but not its contents (use if you do not need high security levels).

• If you are using duration access, use it only for the longest file in the presentation (usually the audio or video file). Apply event access for the other files.

SMIL Files and Directory-Level Duration Access

This is one case in which giving identical permission to all files (including the SMIL file) will not work as expected.

As each clip is viewed, RealServer subtracts the viewing time from the directory. If each clip is 10 minutes long, and there are three clips in the presentation, RealServer subtracts 30 minutes from the total viewing time. This means that in setting up this type of access, the time allotted must be the sum of all the clips.

Keeping track of all the clips, their lengths, and the total directory access time can be tricky. A better solution is to limit the access time only for the SMIL file.

Optional Authentication Features (for All Types of Users)

RealServer has these optional features, which apply to all types of users:

• Creating a New Realm

• Creating a New Database

• Changing RealSystem 5.0 Authentication Passwords

Creating a New Realm

A realm contains information about the type of authentication protocol and the database where the authenticated users' names will be stored.

RealServer has three authentication protocols for authenticating the identity of visitors:

• Basic-encodes the user's name and password with the Base64 algorithm and sends it to RealServer, which then decodes the password and verifies it. This protocol sends the user's password over the public Internet in a simple manner. Users should use a unique password for this material.

• RealSystem 5.0-also called RN5, it is RealNetworks' own authentication protocol, developed for RealServer version 5. If your material will be served to users working with RealPlayer version 5 and later, use this authentication protocol. This is a more sophisticated protocol than Basic authentication. It provides better security than Basic because it does not send the password in a manner that can be reversed.

  If the clients that will be accessing content on your RealServer are RealPlayer 5 and earlier, be sure to use the RealSystem 5.0 style for content authentication.

• Windows NT LAN Manager-this method enables RealServer to use the existing NT database of user groups and permissions. It also allows access control of content via NTFS file permissions. The protocol uses Windows NT authentication.

  This method is only available to systems using Windows NT, and requires that RealServer itself be installed on an NT Server. For authenticating content, it also requires Microsoft Internet Explorer and RealNetworks RealPlayer.

To create a realm:

1. In RealSystem Administrator, click Security. Click Authentication.

2. Click Add New.

   A generic realm name appears in the Edit Realm Description box.

3. In the Edit Realm Description box, type a name for this realm.

4. Click Edit.

5. In the Realm ID box, type a name. You will use this name in other areas of RealSystem Administrator, so make a name that is meaningful to you. The Realm name may also appear to users as part of the name and password prompt.

6. In the Authentication Protocol list, select the authentication method you want to use for this realm:

• Basic-use for authenticating encoders and RealSystem Administrator. You will also need to select a database in which the names and passwords of authenticated users will be stored; refer to "Creating a New Database".

• RealSystem 5.0-use for authenticating encoders and content users. You will also need to select a database in which the names and passwords of authenticated users will be stored; refer to "Creating a New Database". In addition, these passwords are encrypted. To change them, refer to "Changing RealSystem 5.0 Authentication Passwords".

• Windows NT Lan Manager-use for encoders, RealSystem Administrator, and content users (on intranets only). You do not need to select a database-instead, RealServer will use the NT list of names. Use the additional steps shown here:

  1. Type the appropriate provider in the Provider list, such as NTLM.

  2. Type the Group name in the Group box.

1. Click Apply.

Creating a New Database

The list of databases groups database interfaces and the locations of databases. RealServer includes four database interfaces:

• Flat file-The text file method is enabled during installation, as it enables the greatest insight into the access permission structure, but the text file method lacks the flexibility of a full database application.

  It's best to use the text file method only for simple tracking or for troubleshooting the system before linking a full-fledged database to RealServer. For small-scale data, the text file method is also faster than a full-fledged database.

• ODBC and MSQL-The authentication package contains templates for common databases, including mSQL and the ODBC-compliant databases Microsoft Access and Microsoft SQL Server. Users can also work with databases for which templates do not exist, by setting up the data source with the appropriate table structure. The mSQL database is generally used on UNIX.

• RN5 DB Wrapper-If you used authentication features with RealServer version 5, or if you have a data store plug-in created by a third-party company, you can still use that plug-in with RealServer 8.

Use the instructions below to choose the name and type of database that will store users' names and passwords.

To set up a database:

1. In RealSystem Administrator, click Security. Click Databases.

2. Click Add New.

   A generic database name appears in the Edit Database Name box.

3. Type a description for the new database in the Edit Database Name box.

4. Click Edit.

5. From the Database Type list, select the data storage method you want to use.

6. Depending on the database type method you chose, additional information is required.

   Flat File needs only the path to the main text file directory. For example, the enc_r_db directory under the main RealServer directory. See "Overview".

   mSQL has two required names, and three optional items:

   • Host Name-IP address or DNS name of computer where database is stored.

   • Database Name-Name of the database.

   • Table Name Prefix-Prefix used to make field names unique, when used with an existing database.

   • User Name-Name required by database application.

   • Password-Password required by database application. Re-enter your password in the Confirm Password box to ensure you typed it correctly.

     ODBC uses the same information as mSQL, but ODBC does not ask for a Host Name. (Refer to "Setting Up Other Types of Data Storage" for further instructions.)

     RN5 DB Wrapper-these items are needed:

   • Database Name-name or location of the data storage plug-in. Consult your plug-in documentation for information about what should go here.

   • Plugin Path-Location of the plug-in.

   • User Name-Name required by the database application.

   • Password-Password required by the database application. Re-enter your password in the Confirm DB Login Password box to ensure you typed it correctly.

7. After filling out the appropriate values, click Apply.

Changing RealSystem 5.0 Authentication Passwords

In RealSystem 5.0 authentication protocol, RealServer stores all passwords in an encrypted format. Passwords can be entered and changed through the RealServer Administration page.

If you want to change the passwords manually, without using RealSystem Administrator, you can use the supplied password command line utility. It is located in the RealServer Bin directory.

You can also use these instructions as a basis for writing your own CGI scripts and Web pages to accomplish the same purpose automatically.

To use the password tool manually:

1. At a command line, in the Bin directory, type the following:

   
   mkpnpass username realm
   

   where:

   username is the user name exactly as it is entered or will be entered in the authentication database or text file.

   realm is the value of the Realm variable specified in the relevant list. For encoders, this is given by Authentication Realm on the Broadcasting>Encoders page in RealSystem Administrator. (In the configuration file, it is given by the value of the Realm variable in the G2_Encoders list.)

   For RealSystem Administrator users, use the value of the Realm variable in the RealAdministrator_Files list within the FSMount list in the configuration file. (You must open the configuration file itself to see this value.)

2. A password prompt appears, followed by a prompt to type the password again.

   The resulting encrypted password is displayed on the screen.

   RealServer encrypts passwords with the MD5 hashing algorithm. It uses the form MD5("username:realm:new_password"). On BSD systems and some other UNIX systems, you can generate these passwords with the following command:

   
   echo -n "username:realm:new_password" | md5
   

3. Add the resulting encrypted password into the appropriate field of the database.

   • For text files, place it in the password field of the User directory (see "Users Directory").

   • For databases, place it in the password field of the Users table (see "Users Table").

Copyright © 2000 RealNetworks
For information on RealNetworks' technical support, click here.
Comments on this document? Click here.
This file last updated on 11/28/00 at 17:35:02.