REG$_DISPOSITION

REG$_FLAGOPCODE

REG$_FLAGSUBKEY

• If set to 1, report changes in a specified key and any of its subkeys.
• If set to 0, report changes to a specified key only.

REG$_KEYID

REG$_KEYRESULT

REG$_KEYPATH

REG$_LASTWRITE

REG$_LINKCOUNT

REG$_LINKPATH

REG$_LINKTYPE

REG$_NEWNAME

REG$_NOTIFYFILTER

REG$_PATHBUFFER

REG$_REQLENGTH

REG$_RETURNSTATUS

REG$_SECACCESS

REG$_SECURITYPOLICY

REG$_SEPARATOR

Using this item code, you can group multiple requests into a single call to the $REGISTRY service. If you use this multiple-request feature, use the REG$_SEPARATOR item code to indicate the end of the set of item codes for the current request and that there is another request to process.

REG$_SUBKEYINDEX

REG$_SUBKEYNAME

REG$_SUBKEYNAMEMAX

REG$_SUBKEYSNUMBER

REG$_VALUEINDEX

REG$_VALUEDATA

REG$_VALUEDATAMAX

REG$_VALUENAME

REG$_VALUENAMEMAX

REG$_VALUENUMBER

REG$_VOLATILE

For example, you can specify the function modifier REG$M_CASE_SENSITIVE with the function REG$FC_CREATE_KEY. When you use the function and function modifier together, the data passed to the OpenVMS Registry is treated as case sensitive. The two values are written in DEC C as REG$M_CASE_SENSITIVE | REG$FC_CREATE_KEY.

The OpenVMS Registry function modifiers are defined in the header file REGDEF.H.

REG$M_CASE_SENSITIVE

Use case-sensitive matching for keys and values.

REG$M_DISABLE_WILDCARDS

Treat wildcard characters as normal characters for this function.

REG$M_IGNORE_LINKS

Force the operation to not follow any symbolic links associated with a key or a value.

By default, if a key or value is symbolically linked to another key or value, the system follows all links so that the operation specified by the function code is performed on the linked key or value.

When you specify the REG$M_IGNORE_LINKS function modifier, the operation specified by the function code affects only the specified key or value, not the linked key or value.

By default, if a key or value has a symbolic link, it can not be deleted. If you specify the REG$M_IGNORE_LINKS function modifier, the system deletes the key or value.

REG$M_NOW

Write to disk immediately, regardless of the REG$_CACHEACTION item code value.

On a Windows NT system, an event is any significant occurrence in the system or an application---for example, a service starting or stopping, a user logging on or off, or accessing resources. When the system encounters an event, the Event Log service writes the event (or audit entry) in the form of a record that contains date and time, source, category, event number, user, and computer information to a system, security, or application log, creating an audit trail. On Windows NT systems, you display these logs and their recorded events using the Event Viewer.

With COM Version 1.0 for OpenVMS, OpenVMS wrote all COM for OpenVMS events to the DCOM$EVENTLOG.RPT text file. With COM Version 1.1 for OpenVMS, OpenVMS supports both Windows NT logging and Advanced Server for OpenVMS logging of COM for OpenVMS events. You can now log a COM for OpenVMS event (such as the starting of a COM server on OpenVMS), and review these OpenVMS events from a Windows NT system or an OpenVMS system.

For a detailed review of OpenVMS Events dependencies and a description of how OpenVMS Events interacts with other parts of the OpenVMS infrastructure, see Section 4.9.

11.1.1 Suggested Reading

The following sources can provide you with more information on Events and related topics:

• Third-party books on event logging:
  • Windows NT Server 4.0 Unleashed, Jason Garms, SAMS Publishing, Indianapolis, IN, 1998. ISBN: 0-672-30933-5.
  • Win32 System Services: The Heart of Window 95 and Windows NT, Marshall Brain, Prentice Hall, Upper Saddle River, NJ, 1996. ISBN: 0-13-324732-5.
• Other sources:
  • Microsoft Win32 Software Development Kit
    In particular, see the sections about the RegisterEventSource, ReportEvent, and DeregisterEventSource functions, and System Services: Event Logging section.

The system logs OpenVMS Events to a Windows NT event log, to the Advanced Server for OpenVMS event log, and to a log file on the OpenVMS system.

You can use the following techniques to view OpenVMS Events:

• Windows NT event viewer (see Section 11.2.1)
• Advanced Server for OpenVMS event viewer (see Section 11.2.2)
• OpenVMS event log file (see Section 11.2.3)

Use the following procedure to view OpenVMS Events through the Windows NT event viewer:

1. Start the Windows NT event viewer.
   From the Start menu, select Programs, Administrative Tools, Event Viewer.
2. From the Event Viewer window, click the menu bar Log option. Click Select Computer...., and select the OpenVMS system from the list box.
3. From the Event Viewer window, click the menu bar Log option. Click System to display the System event log. The System event log contains the COM for OpenVMS events.
   To display COM for OpenVMS events only, use the following procedure:
   • From the Event Viewer window, click the menu bar View option. Click Filter Events....
     The system displays the Filter window.
   • On the Filter window, click the Source: list box. From the list, choose DCOM.

Use the following procedure to view the COM for OpenVMS events:

1. Ensure that the Advanced Server for OpenVMS is running.
2. Enter the following Advanced Server for OpenVMS ADMINISTRATOR command:

   $ ADMIN SHOW EVENTS/TYPE=SYSTEM/SOURCE=DCOM/FULL

   
   The viewer displays COM for OpenVMS events only, along with any additional information associated with the COM for OpenVMS event.

In some cases, you might want to write and view COM for OpenVMS events only on an OpenVMS system. In place of the Windows NT log, Compaq has included an alternate event logger that writes COM event information to an OpenVMS file. You can find this file in the following location:

SYS$MANAGER:DCOM$EVENTLOG.RPT

COM for OpenVMS creates this event logging report automatically when the COM server (DCOM$RPCSS) encounters an error. The event logger appends new events at the bottom (end) of the file. A logged event has the following format:

event type : ddd mmm dd hh:mm:ss yyyy First event message event type : ddd mmm dd hh:mm:ss yyyy Second event message . . .

Example 11-1 shows the contents of an event log.

Example 11-1 Sample OpenVMS Event Log

$ Type SYS$MANAGER:DCOM$EVENTLOG.RPT (1) ERROR : Tue Sep 15 11:18:54 1998 Unable to start a DCOM Server: {5E9DDEC7-5767-11CF-BEAB-00AA006C3606} Runas (null)/SMITH The Windows NT error: 1326 Happened while starting: device:[account]SSERVER.EXE (2) ERROR : Tue Sep 15 19:14:45 1998 The server {0C092C21-882C-11CF-A6BB-0080C7B2D682} did not register with DCOM within the required timeout.

1. The system logged the first error event on Tue Sep 15 11:18:54 1998. The COM server (DCOM$RPCSS) was unable to start the COM application device:[account]SSERVER.EXE on behalf of the client running under the SMITH account. (The client may have received an error such as "access denied.") The resulting Windows NT error was 1326, which translates as "Logon failure: unknown user name or bad password."
   If you see this error, check the validity of the user account using the OpenVMS Authorize utility (AUTHORIZE).
2. The system logged the second error event on Tue Sep 15 19:14:45 1998. The COM server (DCOM$RPCSS) was able to start the COM application {0C092C21-882C-11CF-A6BB-0080C7B2D682}, but the application did not run successfully. The application failed to register with DCOM$RPCSS within the specified time limit. (The client may have received an error such as "Server execution failed" CO_E_SERVER_EXEC_FAILURE.)
   If you see this error, run the server application interactively to determine its integrity.

Allows an application to record information in the event log files.

The NTA$EVENTW routine completes all operations synchronously.

Format

NTA$EVENTW [nullarg], func, itmlst, evsb

Arguments

nullarg

OpenVMS usage:	reserved
type:	longword (unsigned)
access:	read only
mechanism:	by value

Reserved for Compaq use.

func

OpenVMS usage:	function_code
type:	longword (unsigned)
access:	read only
mechanism:	by value

Function code specifying the function NTA$EVENTW is to perform. The func argument is a longword containing this function code. The $EVENTDEF macro defines the names of each function code.

itmlst

OpenVMS usage:	address of item list
type:	64-bit address
access:	read only
mechanism:	by value

Item list specifying information about the event source or the event. The itmlst argument is the 64-bit address of a list of item descriptors, each of which describes an item of information. An item list in 64-bit format is terminated by a quadword of 0.

The following diagram shows the 64-bit format of a single item descriptor.

evsb

NTA$EVENTW sets the status block to 0 upon request initiation. Upon request completion, the EVT$L_VMS_STATUS field contains the primary (OpenVMS) completion status for the operation.

If an error occurs, EVT$L_NT_STATUS (if non-zero) is the secondary error status to further define the error condition. Function Codes

EVT$_FC_REGISTER_EVENT_SOURCE

Open an association with an event log.

Item code	Required	Parameter	Data type
EVT$_SERVER_NAME	No	Input	String (4-byte Unicode)
EVT$_SOURCE	No	Input	String (4-byte Unicode)
EVT$_HANDLE	Yes	Output	Unsigned longword

• EVT$_SERVER_NAME
  The universal naming convention (UNC) name of the server on which this operation is to be performed.
  UNC names have the form \\server\share\path\file. This item must be zero or unspecified. This performs the operation on an available Advanced Server for OpenVMS server in the cluster.
• EVT$_SOURCE
  The name of the application that logs the event. This field associates an application message file that contains descriptive text with the application's event log entries.
  If specified, the source must be a subkey of the Eventlog\System key, the Eventlog\Security key, or the Eventlog\Application registry key. For example, a source name of Myapp indicates a registry entry in the following:

  HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\Eventlog\Application\Myapp)

  
  The Myapp registry value EventMessageFile names the path and message file to be used to translate this application's events.
  The source can be unspecified or specified as NULL. In this case, the system logs events to the Application log file but the application logs no message file (and, as a result, no replacement text) for the associated events.

• EVT$_HANDLE
  Returns a handle to the Application event log. This handle is required input for other $EVENT functions.
  On failure, a handle of 0 is returned. This handle is outside the responsibility of the CloseHandle API.

EVT$_FC_REPORT_EVENT

Generate an event log entry.

Item code	Required	Parameter	Data type
EVT$_HANDLE	Yes	Input	Unsigned longword
EVT$_EVENT_TYPE	Yes	Input	Word mask
EVT$_EVENT_CATEGORY	No	Input	Word
EVT$_EVENT_ID	Yes	Input	Longword
EVT$_USER_SID	No	Input	NT Security ID
EVT$_NUMSTRINGS	No	Input	Word
EVT$_DATASIZE	No	Input	Longword
EVT$_STRING_ARRAY	No	Input	Array of varying-length descriptors. (4-byte Unicode)
EVT$_RAW_DATA	No	Input	Binary data

• EVT$_HANDLE
  Value returned by a previous EVT$_FC_REGISTER_EVENT_SOURCE call.
• EVT$_EVENT_TYPE
  Indicates the severity of the event. The type is one of the following:
  • EVT$_SUCCESS
  • EVT$_ERROR
  • EVT$_WARNING
  • EVT$_INFO
  • EVT$_AUDIT_SUCCESS
  • EVT$_AUDIT_FAILURE
  
  The severity type maps to its Windows NT equivalent, defined in WINNT.H.
• EVT$_EVENT_CATEGORY
  An integer value from 1 to 65535. EVT$_EVENT_CATEGORY is unique to a particular source.
  EVT$_EVENT_CATEGORY allows an application to divide its message file into sections, each indexed by event ID. If you do not specify a category, the system defaults to a category of zero.
• EVT$_EVENT_ID
  An unlimited integer value. This value indexes the category in an application message file that locates the text string displayed for this event message. The event ID is unique to a particular source.
• EVT$_USER_SID
  The optional Windows NT Security ID of the thread logging the event. An application that has acquired Windows NT credentials through the $PERSONA system service can obtain its SID through calls to the OpenProcessToken and GetTokenInformation Win32 APIs. The format is opaque to this service.
• EVT$_NUMSTRINGS
  A count of the strings specified in the EVT$_STRING_ARRAY item code.
• EVT$_DATASIZE
  Length in bytes of the buffer indicated by the EVT$_RAW_DATA item code.
• EVT$_STRING_ARRAY
  An array of string pointers. Each entry points to a null terminated string. A description string in a message file can contain string placeholders in the form %n, where %1 indicates the first placeholder. Strings specified in this array replace these placeholders when the system displays the event message.
• EVT$_RAW_DATA
  Allows you to include binary data in an event message.
  For example, you might use this to dump a data structure from a failing component.

EVT$_DEREGISTER_EVENT_SOURCE

Close an association with an event log.

Item code	Required	Parameter	Data type
EVT$_HANDLE	Yes	Input	Unsigned longword

• EVT$_HANDLE
  Value returned by a previous EVT$_FC_REGISTER_EVENT_SOURCE call.

The NTA$EVENTW routine completes synchronously; that is, control is returned to the caller only after the request completes.

Use the following process to write event data:

1. Register the event source.
   This operation defines the event log to which the system writes event data.
2. Report the event.
   This operation causes the system to write the information to the appropriate event log.
3. Deregister the event source.
   This operation frees resources acquired as part of the event source registration operation.

Condition Values Returned

SS$_NORMAL	Service completed successfully.
SS$_ACCVIO	One of the arguments cannot be read/written.
SS$_BADPARAM	Bad parameter.
SS$_NOPRIV	Insufficient privilege to access the specified event log.
SS$_TIMEOUT	Request timed out.
SS$_UNREACHABLE	Events service unavailable.
SS$_REJECT	The Windows NT LAN Manager server encountered an error. See the Win32 status for more information.

11.3 Writing Your Own Events

The COM for OpenVMS kit includes sample code that shows how to generate an application event using Win32 APIs. You can use this example as is on a Windows NT system. The example also builds correctly using the instructions for building COM for OpenVMS applications on OpenVMS (to get the required header files from DCOM$LIBRARY). See Chapter 6 for these instructions. The example also includes the linking instructions to build the example using Wind/U.

11.4 Troubleshooting OpenVMS Events

Errors that occur during event reporting can be difficult to trace because of the number of intervening software layers through which the event passes. The following list describes how OpenVMS Events pass through other software layers until they are recorded in the Windows NT log.

1. An application calls one of the Win32 event functions (RegisterEventSource, ReportEvent, or DeregisterEventSource).
2. Using the supplied arguments, the Win32 API builds an appropriate item list and calls the NTA$EVENTW routine.
3. The NTA$EVENTW routine validates the information supplied (function code, item list, and so on) and builds an appropriate item list for the SYS$ACM system service.
   If NTA$EVENT detects any errors NTA$EVENT returns the errors to the Win32 API using R0 and the event status block.
4. The SYS$ACM system service validates the information and passes it to the NT ACME.
   If SYS$ACM detects any errors, SYS$ACM returns the errors to NTA$EVENTW using R0 and the ACM status block..
5. The NT ACME passes the supplied information (using an IPC pipe) to a dispatcher in the Advanced Server for OpenVMS.
   If the NT ACME detects any errors, the NT ACME returns the errors to the caller using the ACM status block.
6. The Advanced Server for OpenVMS dispatcher validates the information and calls the appropriate routines to perform the requested operation (register, report, or deregister).
   If the Advanced Server for OpenVMS detects any errors, it reports the errors to the NT ACME. The NT ACME passes the errors back to the other callers.

Checking the contents of the event status block help you determine where the failure might have happened. Table 11-1 lists (in order of importance) the checks you should perform.

Table 11-1 Troubleshooting OpenVMS Events Failures

R0 Status	Status Field Value	Component to Check
Failure (bit 0 clear)	EVT$L_NT_STATUS field is nonzero.	Error most likely occurred within Advanced Server for OpenVMS.
Failure	EVT$L_VMS_STATUS field is nonzero and the EVT$L_NT_STATUS is zero.	Error most likely occurred within the SYS$ACM system service or the NT ACME.
Failure	EVT$L_VMS_STATUS is zero and EVT$L_NT_STATUS is zero.	Error most likely occurred within the SYS$ACM system service.

Authentication is the act of verifying a user's identity by the computer system before permitting access to the system. After successfully authenticating a user, the system binds the user's authorization information to the user's process in the form of credentials. The system uses these credentials to determine whether to grant or deny access to system resources.

OpenVMS provides both native (SYSUAF-based) and Windows NT-compatible authentication and authorization capabilities as follows:

• Native: The system performs authentication using password information stored in the SYSUAF.DAT file. Authorization information consists of UIC, privileges, and rights identifiers.
• Windows NT: The system performs authentication using password information stored in a SAM database managed by domain controllers. Authorization information consists of primary SID, group SIDs, session key, and privileges obtained from the user's account information in the SAM database.

After OpenVMS successfully authenticates a user (either native or Windows NT), OpenVMS attaches the user's native credentials to the process using a structure known as a persona. If the system used Windows NT for authentication, OpenVMS also attaches the user's Windows NT credentials to the process (as an extension to the persona).

12.2 Acquiring Windows NT Credentials Using NTA$LOGON

NTA$LOGON is a utility that allows you to acquire NTLM credentials. All processes that need Windows NT security to access the OpenVMS Registry or COM for OpenVMS facilities require NTLM credentials.

You must provide NTA$LOGON with a user account name, a password, and (if required) a domain name. NTA$LOGON uses the Authentication and Credential Management (ACM) Authority to contact the domain controller and acquire a Windows NT access token. NTA$LOGON merges the Windows NT information with the user's OpenVMS credentials.

For a detailed review of NTA$LOGON dependencies and a description of how NTA$LOGON interacts with other parts of the OpenVMS infrastructure, see Section 4.8 and Section 4.9 (especially the ACME server and Advanced Server for OpenVMS server).

To use the NTA$LOGON utility, you can enter any of the following:

• Enter the following command to run the NTA$LOGON utility:

  $ RUN SYS$SYSTEM:NTA$LOGON

  
  The system prompts you for a user account name and password.

• Define a DCL symbol to use NTA$LOGON to parse the command line. For example:

  $ NTLOGON :== $NTA$LOGON $ NTLOGON

  
  You can specify parameters on the command line. Table 12-1 shows the command line parameters. If you do not specify any parameters, the system prompts you for the required information.

• Use the MCR command to use NTA$LOGON to parse the command line. For example:

  $ MCR NTA$LOGON

  
  You can specify parameters on the command line. Table 12-1 shows the command line parameters. If you do not specify any parameters, the system prompts you for the required information.

Table 12-1 shows the NTA$LOGON utility command line parameters.

Table 12-1 NTA$LOGON Utility Command Line Parameters

Argument	Value	Required/Optional
P1	User account name. If an account name is needed but was not specified on the command line, NTA$LOGON prompts for input.	Optional
P2	Password. If a password is needed but was not supplied on the command line, NTA$LOGON prompts for input (echoing suppressed).	Optional

Example 12-1 shows a typical NTA$LOGON session to acquire credentials.

Example 12-1 Sample NTA$LOGON Session

$ NTLOGON :== $NTA$LOGON $ NTLOGON joesmith Password:

NTA$LOGON accepts the following optional qualifiers:

• /DELETE
  Deletes the current Windows NT credentials.
  If you specify the /DELETE qualifier with the /WRITE_FILE qualifier, the system deletes the password record for the specified domain name and user account name from the file.
• /DOMAIN=name
  Specifies a domain name. This qualifier converts the name to uppercase. If you do not specify this qualifier, the system uses the default domain name.
• /LIST
  Lists the domain name and the user account name assigned to the current process.
  If you use the /LIST qualifier with the /READ_FILE or /WRITE_FILE qualifier, the system lists the contents of the file.
• /LOG
  Displays a message when an operation completes.
• /OVERRIDE_MAPPING
  Acquires Windows NT credentials for the specified Windows NT user account name even if the OpenVMS user name of the process does not match the OpenVMS user name associated with that Windows NT user account name in the domain controller.
  This qualifier requires the IMPERSONATE privilege.
• /READ_FILE [=file]
  This qualifier causes the system to search the binary input file created by the /WRITE_FILE qualifier for the specified domain name and user account name, instead of reading the password from the user input device. The /READ_FILE qualifier supports only binary files created by the NTA$LOGON/WRITE_FILE command.
  If the system finds a matching record, NTA$LOGON attempts to use that password to acquire Windows NT credentials.
  If you do not provide a file specification, the system uses the following default file specification:

  DCE$COMMON:[000000]NTA$LOGON.DAT

• /TYPE={BATCH | DIALUP | LOCAL | NETWORK | REMOTE}
  Specifies the rules under which access is to be granted or denied. If you do not specify this qualifier, the default is the type of the current process. This qualifier is usually used for detached processes (detached processes do not have a default type).
  This qualifier requires IMPERSONATE privilege.
• /WRITE_FILE [=file]
  This qualifier causes the system to write the specified domain name, user account name, and password into an output file to be used later (see the /READ_FILE qualifier), instead of using the user-supplied password.
  If you do not provide a file specification, the system uses the following default location and file name:

  DCE$COMMON:[000000]NTA$LOGON.DAT

  Caution The /READ_FILE and /WRITE_FILE qualifiers are intended to be used only by servers that have no other way to acquire Windows NT credentials to access the OpenVMS Registry or COM for OpenVMS facilities. Compaq does not recommend general use of the /READ_FILE and /WRITE_FILE qualifiers. Once you have written a password into a disk file, Compaq recommends you take strong precautions to protect the password file from unauthorized access.

Example 12-2 shows how a user acquires NT credentials for the first time.

Example 12-2 Acquiring Windows NT Credentials for the First Time

$ NTLOGON :== $NTA$LOGON $ NTLOGON/LIST ERROR: NtOpenProcessToken() failure: -1073741700 0xc000007c %SYSTEM-E-NOSUCHEXT, no such extension found $ NTLOGON/LOG JOESMITH [Persona #1 NT extension: Account= "JOESMITH" Domain= "NT_DOMAIN" ] Password:

Example 12-3 shows how the user replaces the Windows NT credentials.

Example 12-3 Replacing Windows NT Credentials

$ NTLOGON/DELETE $ NTLOGON/OVERRIDE_MAPPING/DOMAIN=OTHER_DOMAIN Username: janebrown Password:

Example 12-4 shows how a user saves a password in a disk file. The system requests that the user enter the password twice with echoing suppressed.

Example 12-4 Saving a Password to a File

$ NTLOGON :== $NTA$LOGON $ NTLOGON/WRITE_FILE=DEV:[DIR]NTA$LOGON.DAT COM_SERVER Password: Confirm: $ NTLOGON/READ_FILE=DEV:[DIR]NTA$LOGON.DAT/LIST File DEV:[DIR]NTA$LOGON.DAT contains the following records: 02-MAR-1999 16:57:23.20 COM_SERVER

After you have created this file, you can add the following to a DCL command procedure:

$ NTLOGON :== $NTA$LOGON $ NTLOGON/READ_FILE=DEV:[DIR]NTA$LOGON.DAT COM_SERVER

12.3 The Authentication and Credential Management (ACM) Authority

The Authentication and Credential Management authority authenticates users and determines the user security profile for OpenVMS and Windows NT. The ACME_SERVER process provides these ACM services. The ACME_SERVER process uses plug-in modules called ACME agents. ACME agents perform the actual work of responding to authentication requests, query requests, and event requests.

The OpenVMS ACME agent (VMS$VMS_ACMESHR.EXE) provides OpenVMS native services. The MSV1_0 ACME agent (PWRK$MSV1_0_ACMESHR.EXE, an Advanced Server for OpenVMS product component) provides Windows NT connectivity services.

The MSV1_0 ACME agent forwards Windows NT connectivity service requests from NTA$LOGON and SSPI/NTLM to an Advanced Server for OpenVMS process running on one or more systems in the cluster. The PWRK$ACME_SERVER logical name can contain a comma-delimited list of cluster node names to which the MSV1_0 ACME can forward requests. Running the Advanced Server for OpenVMS process on more than one cluster node and including the node names in the PWRK$ACME_SERVER logical name allows the MSV1_0 ACME agent to fail over a request automatically if a connection is interrupted. If the logical name is undefined, the system defaults to the local machine name.

The ACME_SERVER process must be present on any system running RPC or COM for OpenVMS. However, the Advanced Server for OpenVMS process needs to be present on only one node in the cluster.

12.3.1 Windows NT Authentication on OpenVMS

Because the ACME_SERVER returns to its callers a complete OpenVMS persona with the requested attached Windows NT persona extension, the VMS ACME agent enforces the following rules:

• Every Windows NT user must be mapped to a local OpenVMS user name.
  The MSV1_0 ACME provides this mapping through the Advanced Server for OpenVMS HOSTMAP database.
• The mapped OpenVMS user name must be a valid (and not disabled) account in the SYSUAF.DAT. The account's access restrictions must allow access during the specified days and times. COM for OpenVMS and RPC typically require NETWORK access during authentication.
• The mapped OpenVMS user name must be an account with the EXTAUTH flag set. EXTAUTH allows the system manager fine control over which OpenVMS accounts can be used for mapping. You can use the IGNORE_EXTAUTH bit (bit number 11 [decimal]) in the SECURITY_POLICY system parameter to override this per-account feature. If you set the IGNORE_EXTAUTH bit to 1, OpenVMS allows you to map to any account, regardless of the account's EXTAUTH setting. Note that the IGNOTE_EXTAUTH is used only for the ACME_SERVER and is ignored by Loginout.

To authenticate a Windows NT user on OpenVMS and attach the Windows NT user's credentials to an OpenVMS process, do the following:

1. Define a HOSTMAP entry in the Advanced Server for OpenVMS database.
   A HOSTMAP entry defines the association between a Windows NT user account and a local OpenVMS user account. When OpenVMS authenticates a Windows NT user, OpenVMS uses the HOSTMAP entry to map the OpenVMS user account to the Windows NT user account and build the local OpenVMS user profile and the Windows NT user profile. If no HOSTMAP entry exists, OpenVMS uses the Windows NT user account name as the local OpenVMS user account name.
   Use the Advanced Server for OpenVMS ADMINISTER utility to define HOSTMAP information. For example, to map Windows NT user FRED to the local OpenVMS user account FREDERICK, enter the following command:

   $ ADMINISTER ADD HOSTMAP FRED FREDERICK

   
   If FRED is defined in trusted domain FINANCE, you must specify the trusted domain name in the HOSTMAP entry. For example:

   $ ADMINISTER ADD HOSTMAP FINANCE\FRED FREDERICK

2. Enable the OpenVMS user account for hostmapping.
   By default, OpenVMS can use only OpenVMS user accounts that have the EXTAUTH flag set for hostmapping. This policy allows the OpenVMS system manager to control which OpenVMS user accounts can be used with Windows NT authentication.
   (You can override this per-account restriction systemwide by setting the IGNORE_EXTAUTH bit [bit number 11 (decimal)] in the SECURITY_POLICY system parameter.)
   Use the AUTHORIZE utility to set the EXTAUTH flag on an OpenVMS user account. For example, you can enable the EXTAUTH flag for the OpenVMS user account FREDERICK as follows:

   $ AUTHORIZE MODIFY FREDERICK/FLAG=EXTAUTH

To start the ACME_SERVER process and configure the MSV1_0 ACME agent at system startup, add the following entry to SYLOGICALS.COM:

$ DEFINE NTA$NT_ACME_TO_BE_STARTED YES

You can also start the ACME_SERVER process manually using the following startup command file:

$ @SYS$STARTUP:NTA$STARTUP_NT_ACME

To shut down ACME_SERVER, enter the following command:

$ SET SERVER ACME/EXIT

If an abnormal condition in an ACME agent prevents a normal server shutdown, use the /ABORT qualifier in the place of the /EXIT qualifier to force the ACME_SERVER to terminate.

To turn on ACME_SERVER logging, enter the following command:

$ SET SERVER ACME/LOG

This command creates a ACME$SERVER.LOG file in the SYS$MANAGER directory. You might find this file useful when you are trying to diagnose potential problems.

To display the ACME_SERVER configuration information, enter the following command:

$ SHOW SERVER ACME[/FULL]

12.3.4 Configuring the MSV1_0 ACME Agent

Table 12-2 lists and describes systemwide logical names you can use to control certain features of the MSV1_0 ACME agent.

Table 12-2 MSV1_0 ACME Agent Logical Names

Logical name	Description
PWRK$ACME_SERVER	Comma-delimited list of cluster SCS node names that are running Advanced Server for OpenVMS processes that can service Windows NT connectivity requests. If you do not define the node names, the MSV1_0 ACME agent tries to connect to the Advanced Server for OpenVMS process on the local system.
PWRK$ACME_RETRY_COUNT	The maximum number of retry attempts the MSV1_0 ACME agent performs when connecting to an Advanced Server for OpenVMS process. The default value is 10.
PWRK$ACME_RETRY_INTERVAL	The number of tenths of seconds between retry attempts. The default is 2.5 seconds.

	privacy and legal statement
6539P006.HTM