You must first configure and populate your LDAP directory server with user entries. The ACME LDAP agent is configured by performing the following steps:

To enable the SYS$ACM-enabled login (previously known as ACME LOGIN) and ACME LDAP, simply run the command file SYS$MANAGER:SYS$LOGIN_SWITCH.COM.

When the ACME LDAP agent is enabled, proceed to the next section, Section 2.4, “Setting Up the LDAP Persona Extension”.

To set up the persona extension on OpenVMS IA-64 Version 8.4-1H1 or later, complete the following steps:

To set up the persona extension on OpenVMS x86-64 Version 9.2-3 or later, complete the following steps:

After setting up the LDAP persona extension, you can proceed towards configuring your ACME LDAP agent. See Section 2.5, “Configuring the ACME LDAP Agent”.

Configuration of the ACME LDAP agent involves the following steps:

The attribute used for usernames is specified by the login_attribute directive in your ACME LDAP INI configuration file. For more information about login_attribute, see Table 2.1, “LDAP Configuration Attributes”.

The ACME LDAP agent searches this attribute on the directory server for matching usernames (entered at the "Username" prompt during login). The search is done in the set of LDAP entries below the point in your directory tree specified by the base_dn directive.

The username (entered at the "Username" prompt during login) is mapped to the username in the SYSUAF.DAT file. Global and local mappings are also supported. For more information on global and local mapping, see Chapter 3, Global and Local Mapping.

OpenVMS-specific information, such as privileges, identifiers, and so on, is taken from the SYSUAF.DAT file.

A user scenario on configuring the ACME LDAP agent and a sample login are provided in Chapter 4, User Scenario of Configuring an OpenVMS ACME LDAP Agent.

$ SET SERVER ACME/EXIT/WAIT
$ SET SERVER ACME/START=AUTO

For any user to be externally authenticated (via LDAP), the ExtAuth flag has to be set for the user account in the SYSUAF.DAT. When the ExtAuth flag is specified for a user account, the user is validated only externally using external authenticator (LDAP). If you want this user to be authenticated locally as well against the SYSUAF.DAT file, set VMSAuth flag for the user account in the SYSUAF.DAT file and use /LOCAL qualifier during login as described in the following section.

To set ExtAuth flag to the user, enter the following:

$ SET DEFAULT SYS$SYSTEM
$ MCR AUTHORIZE MODIFY <username> /FLAGS=(EXTAUTH,VMSAUTH)

A sample user profile is shown as follows:

$ SET DEF SYS$SYSTEM
$ MC AUTHORIZE
UAF> modify jdoe/flags=(EXTAUTH,VMSAUTH)
%UAF-I-MDFYMSG, user record(s) updated
UAF> sh jdoe

Username:  JDOE                             Owner: 
Account:   TEST                             UIC: [201,2011] ([JDOE]) 
CLI:       DCL                              Tables: DCLTABLES
Default:   SYS$SYSDEVICE:[JDOE] 
LGICMD: 
Flags:  ExtAuth  VMSAuth 
Primary days:    Mon Tue Wed Thu Fri
Secondary days:                      Sat Sun
No access restrictions 
Expiration:             (none)    Pwdminimum:  6   Login Fails:   1
Pwdlifetime:         90  00:00    Pwdchange:      (pre-expired)
Last Login:             (none) (interactive),           (none) (non-interactive)
Maxjobs:           0 Fillm:        128 Bytlm:       128000
Maxacctjobs:       0 Shrfillm:       0 Pbytlm:           0
Maxdetach:         0 BIOlm:        150 JTquota:       4096
Prclm:             8 DIOlm:        150 WSdef:         4096
Prio:              4 ASTlm:        300 WSquo:         8192
Queprio:           4 TQElm:        100 WSextent:     16384
CPU:          (none) Enqlm:       4000 Pgflquo:     256000
Authorized Privileges:
  NETMBX       TMPMBX
Default Privileges:
  NETMBX       TMPMBX
UAF>

If your directory server is configured and your SYSUAF account is mapped with the user name on the directory server, you can now login to the system using ACME LDAP as the authentication agent as shown in the following example.

The password for user "jdoe" is validated against the password from directory server. Note that if the password in directory server is different from the password in the SYSUAF.DAT file, then the password on the SYSUAF.DAT file will be synchronized to the password on directory server. You can disable the password synchronization for a specific user or for all the users on the system. For more information on disabling the password synchronization, see the sections "Enabling External Authentication" and "Authentication and Credentials Management Extensions (ACME) Subsystem" in the VSI OpenVMS Guide to System Security.

$ TELNET 127.0.0.1
%TELNET-I-TRYING, Trying ... 127.0.0.1 %TELNET-I-
SESSION, Session 01, host 127.0.0.1, port 23 -TELNET-
I-ESCAPE, Escape character is ^]

Welcome to VMS Software, Inc. OpenVMS(TM) IA64 Operating System, Version V8.4-1H1

Username: jdoe
Password:
        VMS Software, Inc. OpenVMS(TM) IA64 Operating System, Version V8.4-1H1
        **** Logon authenticated by LDAP ****
    OpenVMS password has been synchronized with external password

In the following example, the user jdoe is validated against the SYSUAF.DAT file. Note that the user will not be mapped when the /LOCAL qualifier is provided during login. The username jdoe must be present in the SYSUAF.DAT file:

$ TELNET 127.0.0.1
%TELNET-I-TRYING, Trying ... 127.0.0.1 %TELNET-I-
SESSION, Session 01, host 127.0.0.1, port 23 -TELNET-
I-ESCAPE, Escape character is ^]

Welcome to VMS Software, Inc. OpenVMS(TM) IA64 Operating System, Version V8.4-1H1

Username: jdoe/local
Password:
   VMS Software, Inc. OpenVMS(TM) IA64 Operating System, Version V8.4-1H1
   Last interactive login on Tuesday, 1-DEC-2015 01:34:50.26

Example 1 – Red Hat or Fedora Directory Server Configuration File

A sample configuration file using the Red Hat or Fedora directory server:

server = roux.vsi.com
port = 636
port_security = ssl
bind_dn = uid=acme-admin,ou=people,dc=acme,dc=mycompany,dc=com
bind_password = swordfish
base_dn = ou=people,dc=acme,dc=mycompany,dc=com
login_attribute = uid
scope = sub 
ca_file = sys$manager:acme_ca.crt

Example 2 – Active Directory Configuration File

server = acme.mycompany.com
port = 636
port_security = ssl
password_type = active-directory
bind_dn = cn=acme-admin,cn=users,dc=acme,dc=mycompany,dc=com
bind_password = swordfish
base_dn = cn=users,dc=acme,dc=mycompany,dc=com
login_attribute = samaccountname
scope = sub
ca_file = sys$manager:acme_ca.crt

server = cssn-ddrs.testdomain.vmssoftware.com
port = 389
bind_dn = CN=query_account,CN=Users,DC=testdomain,DC=vmssoftware,DC=com
bind_password = welcome@123
base_dn = DC=testdomain,DC=vmssoftware,DC=com
scope = sub
port_security = none
password_type = active-directory

server = cssn-ddrs.Americas.vmssoftware.com
port = 389
bind_dn = CN=query_account,CN=Users,DC=Americas,DC=vmssoftware,DC=com
bind_password = welcome@123
base_dn = DC=Americas,DC=vmssoftware,DC=com
scope = sub
port_security = starttls
password_type = active-directory
domain = Americas

server = cssn-ddrs.testdomain.vmssoftware.com
port = 389
bind_dn = CN=query_account,CN=Users,DC=testdomain,DC=vmssoftware,DC=com
bind_password = welcome@123
base_dn = DC=testdomain,DC=vmssoftware,DC=com
scope = sub
port_security = starttls
password_type = active-directory
ca_file = sys$manager:cssn-ddrs.cer

You can configure the ACME LDAP agent to search multiple redundant directory servers for user authentication. This is helpful in a scenario where the first directory server is not reachable or active. As a result, the ACME LDAP agent tries to connect to a set of directory servers to authenticate the user.

In order to provide multiple redundant servers, the mandatory directives (such as server and bind_timeout) and the optional directive ca_file must be updated. For more information on the directives, see Section 2.5.1, “Editing the LDAP Configuration File”.

The ACME LDAP agent can be configured to login from different domains. This is helpful in a scenario where users from different locations or departments in an organization can login by prefixing domain to username.

Example 3 – Multi-Domain Users and Session Details

"AMERICAS\bwills"
"EMEA\John Doe"
"ASIAPACIFIC\Shaun Marsh"

Username: "Americas\bwills"
Password:
   VMS Software, Inc. OpenVMS(TM) IA64 Operating System, Version V8.4-1H1
**** Logon authenticated by LDAP ****
    OpenVMS password has been synchronized with external password
$ SH PROC

 4-NOV-2013 21:04:27.26   User: BWILLS           Process ID:   2020026F
                          Node: BENZ             Process name: "BWILLS"

Terminal:           TNA14:  (Host: LOCALHOST Locn:  FTA5:/SYSTEM)
User Identifier:    [BWILLS] 
Base priority:      4 
Default file spec:  SYS$SYSDEVICE:[BWILLS]
Number of Kthreads: 1 (System-wide limit: 2)

Username: "EMEA\John Doe"
Password: 
  VMS Software, Inc. OpenVMS(TM) IA64 Operating System, Version V8.4-1H1
  on node BENZ Last interactive login on Monday, 30-NOV-2015 00:21:23.54
**** Logon authenticated by LDAP ****
$ SH PROC

 4-NOV-2013 21:17:08.99   User: JDOE             Process ID:   20200270
                          Node: BENZ             Process name: "JDOE"

Terminal:           TNA15:  (Host: LOCALHOST Locn: _TNA14:/BWILLS)
User Identifier:    [JDOE] 
Base priority:      4 
Default file spec:  SYS$SYSDEVICE:[JDOE]
Number of Kthreads: 1 (System-wide limit: 2)

Devices allocated:  TNA15:

Username: "Asiapacific\Shaun Marsh"
Password:
   VMS Software, Inc. OpenVMS(TM) IA64 Operating System, Version V8.4-1H1
   on node BENZ Last interactive login on Monday, 30-Nov-2015 10:40:09.01
**** Logon authenticated by LDAP ****
$ SH PROC

 4-NOV-2013 21:31:26.80   User: SMARSH           Process ID:   20200271
                          Node: BENZ             Process name: "SMARSH"

Terminal:           TNA16: (Host: LOCALHOST Locn: _TNA15:/JDOE)
User Identifier:    [SMARSH]
Base priority:      4 
Default file spec:  SYS$SYSDEVICE:[SMARSH]
Number of Kthreads: 1 (System-wide limit: 2)

Devices allocated:  TNA16:

This section provides a user scenario on how to configure global mapping and local mapping with an OpenVMS ACME LDAP agent.

Global Mapping Configuration

In the SYSUAF.DAT file, the username is stored as "jdoe" and "jhardy". To enable global mapping, perform the following steps:

Local Mapping Configuration

To enable local mapping, perform the following steps:

You require the following information from the Active directory to populate the LDAP INI configuration file:

The base distinguished name (base_dn directive), the distinguished name of the query_account (bind_dn directive), and the samaccountname (login_attribute directive) are obtained from the database log file, .ldf file. For more information on how to obtain the specific attribute value, see Section 4.1.2, “Extracting base_dn, bind_dn, and login_attribute”.

4.1.2. Extracting base_dn, bind_dn, and login_attribute

You can extract the values for the base_dn, bind_dn, and login_attribute directives (in the ACME LDAP configuration file) from the .ldf file.

To extract the .ldf file, at the command prompt, enter the following command on your Windows system:

ldifde –f <filename>.ldf

After the .ldf file is extracted, copy the base_dn and bind_dn values. For more information on the base_dn and bind_dn directives, see Table 2.1, “LDAP Configuration Attributes”.

Figure 4.2, “Sample LDF File” shows a sample .ldf file. Here, the account, query_account is identified as the binding account. The base_dn and bind_dn values are highlighted.

To configure an ACME LDAP agent on a non-secure port, do the following:

To configure an ACME LDAP agent on a secure port, do the following:

Perform the following steps to configure ACME LDAP to utilize the multi-domain support:

What events can be traced using the SET SERVER ACME/TRACE=<value> command, and how do we interpret the traces?

You can view critical errors logged by the agent in ACME$SERVER.LOG without setting the SET SERVER ACME/TRACE=<value>. See Table 5.1, “Trace Flags” for setting the appropriate values. For example:

When the ACME LDAP agent is configured to a directory server that is not reachable, the following error messages are displayed:

%ACME-I-LOGAGENT, agent initiated log event on 25-FEB-2010 10:41:06.43 
-ACME-I-THREAD, thread: id = 4, type = EXECUTION 
-ACME-I-REQUEST, request information, id = 1, function = AUTHENTICATE_PRINCIPAL 
-ACME-I-CLIENT, client information, PID = 2020044C 
-ACME-I-AGENT, agent information, ACME id = 2, name = LDAP-STD 
-ACME-I-CALLOUT, active callout routine = acme$co_accept_principal 
-ACME-I-CALLBACK, active callback routine = acme$cb_send_logfile 
-ACME-I-TRACE, message from LDAP ACME agent: Internal error. LDAP search operation failed 

The following is another example of giving port_security = nonenone instead of port_security = none in the configuration file:

%ACME-I-LOGAGENT, agent initiated log event on 25-FEB-2010 10:42:39.41
-ACME-I-THREAD, thread: id = 1, type = CONTROL
-ACME-I-CONTROL, control information, operation = STARTUP
-ACME-I-AGENT, agent information, ACME id = 2, name = LDAP-STD
-ACME-I-CALLOUT, active callout routine = acme$co_agent_startup
-ACME-I-CALLBACK, active callback routine = acme$cb_send_logfile
-ACME-I-TRACE, MESSAGE FROM LDAP ACME agent: Reading the config file (LDAPACME$INIT) failed 

The information starting from %ACME-I- to the next %ACME-I- marks one trace.

When you execute SET SERVER ACME/TRACE=<value>, tracing is enabled and logged to the SYS$MANAGER:ACME$SERVER.LOG file.

You must search for the "MESSAGE FROM LDAP ACME agent" line in the ACME$SERVER.LOG to locate status messages returned by the LDAP ACME agent.

For details about the various flags that can be enabled for tracing, execute the HELP SET SERVER ACME/TRACE command on an OpenVMS system.

The following table provides details about the trace flags.

For example, the following command would enable tracing of "agent", "general", "report", "message", "dialog", "callout", and "callout_status":

$ SET SERVER ACME/TRACE=1763