Q: How can I use my Windows AD credentials to log in to LISTSERV Maestro?

By Robert Graf-Waczenski,
Senior Applications Programmer, L-Soft

Having to remember and maintain many different passwords and user names frequently leads to insecure passwords. With only one set of login credentials, a user will more easily be able to memorize a longer and more secure password. LISTSERV Maestro's authentication settings allow the administrator to configure a Maestro account in such a way that the login to Maestro is verified through a given Windows AD domain controller.

With the setup described in this tip, not only will the user benefit from having to remember only one password. From an administrative point of view, this also means that all existing password security settings (password length, complexity and validity period) apply exactly as they are configured on the domain controller, thus yielding not only one login password for the user but also only one central location to configure passwords security, both for operating system logins and logins to LISTSERV Maestro.

Configuring Default User Authentication for Windows AD

To configure default user authentication through Windows AD, log in to the Administration HUB and select from the menu: Global Settings > Maestro User Interface > Default Authentication Settings.

On this screen, you first select "Authenticate Through Windows Active Directory". Then you configure how LISTSERV Maestro shall create a Windows AD authentication principal's exact name from a given LISTSERV Maestro account. The default settings are such that the account name is suffixed with the Windows AD domain name that you supply on this screen in the input field next to the {{account}} prefix under "User". The input you supply under "Domain Controller" defines the DNS host name of the Windows AD domain controller that manages user logins in your Windows network.

Note: Two important caveats apply to the inputs that you supply for the domain controller and the Windows AD domain name. Due to historic reasons, a Windows AD domain has two, often different, names. In the early days of Windows networking, the NetBIOS protocol was invented, and Windows still supports supplying the NetBIOS name of a Windows domain at some locations. Since several years, however, Windows domains are closely coupled to DNS and therefore also have a so-called fully qualified domain name. LISTSERV Maestro requires that you supply the FQDN of your Windows AD domain (usually in ALL CAPS), not the NetBIOS name. The second caveat applies to the input that you supply for the domain controller. The interaction between a client computer and a domain controller requires that the DNS setups of both computers match the domain controller's host name to and from its IP address in exactly the same way, including uppercase/lowercase. This means that not only must the input you supply for the domain controller host name match to the correct IP address, you also have to use the same uppercase/lowercase spelling that is defined in the DNS setup of both the LISTSERV Maestro server and the domain controller server.

Both inputs together have the effect that LISTSERV Maestro is able to forward the user's password input during login to the domain controller for verification, allowing login only if the password is accepted by the domain controller.

The technology used by LISTSERV Maestro has several key properties:

1. No configuration of a Windows AD administrator-level account/password necessary
   
   Since you tell Maestro how to textually create the name of a Windows AD authentication principal from a given Maestro user name, this information can easily be used to perform a password validation on behalf of that user principal alone, without any previous authentication with administrator-type credentials.


2. No passwords stored in LISTSERV Maestro
   
   Since the user's password input is forwarded transparently to the Windows AD domain controller for verification, the password itself is no longer stored in LISTSERV Maestro, contrary to how this must be done when you use the default "Authenticate With Internal Passwords in Maestro".


3. Secure communication between LISTSERV Maestro and the domain controller
   
   Internally, LISTSERV Maestro uses the Kerberos protocol to perform the password validation handshake with the domain controller. This method is comparable to how a Windows Client computer communicates with the domain controller to perform a standard Windows login.

Note: Windows AD user authentication is possible in LISTSERV Maestro even if the Maestro servers are not configured to use HTTPS. Without HTTPS, the users' passwords (regardless of whether authentication is configured via internal passwords or via Windows AD), are sent through an unencrypted channel from the user's browser to the LISTSERV Maestro server. The communication from the Maestro server to the domain controller server, however, is considered to be secure even if the domain controller is accessed through an unencrypted connection. This is a key property of Windows logins and the Kerberos protocol.

Defining Custom Windows AD Settings for Specific Users/Groups

Similar to most other LISTERV Maestro settings, user authentication can be defined on the usual three levels: on application default level (described above), custom for specific groups, and custom for specific users in certain groups.

To configure Windows AD user authentication for a specific group, select the group from the "Accounts and Identities" overview. With the group selected, select from the menu: Group > Authentication Settings. This opens a screen that is similar to the one shown above:

To override the default settings, first select "Use custom settings", then select "Authenticate Through Windows Active Directory" and proceed in the same way as described above.

To configure Windows AD authentication for a specific user, select the user from the "Accounts and Identities" overview. The select from the menu: User Account > Authentication Settings. The following screen opens:

In addition to the two inputs described further above, this screen has an additional input field that allows you to override the default behavior of suffixing the FQDN domain name to the name of the given account. This is necessary if the Windows AD user principal name part (before the ‘@' character) is different from the LISTSERV Maestro account name. You may also decide to even supply this custom name prefix even if it currently happens to be the same, to allow the user's name to be changed in LISTSERV Maestro in the future and still be mapped to the same Windows AD user authentication principal in your Active Directory.

Testing And Troubleshooting

Once you have supplied the domain controller and the domain name inputs for any of the three configuration levels, the "Test connection" link is enabled. Clicking this link opens a popup similar to the one shown above. Even though testing the connection is an optional step, it is recommended to test the authentication settings at least with one account that you, the administrator, have access to (including the account password in your Active Directory). As you see written on the screen, your password input is not stored but only used to perform an actual, live password verification through the domain controller server host with the other settings supplied on the screen.

This connection test not only verifies that you supplied the correct Windows password for the user authentication principal as it is configured in your Active Directory, it also verifies that:

1. The domain controller is reachable when it is accessed from the LISTSERV Maestro server (or, more exactly the server running the LUI component, even if you perform this test through the HUB).


2. You supplied the correct uppercase/lowercase spelling of both the domain controller host name and the correct uppercase/lowercase spelling of the FQDN of the Windows domain.

If you receive an error message when you attempt the connection test, examine the message closely, it should tell you enough to resolve the problem. Should you be unable to resolve the problem, make sure to quote the exact error message when contacting L-Soft support.

Alternative to Windows AD Authentication: LDAP Authentication

If your network logins are protected by a server not running as a standard Windows Active Directory domain controller but as an LDAP server running for example OpenLDAP or some other standard LDAP server software, you can select "Authenticate Through LDAP" on all the screens shown further above in this tip.

The mechanisms necessary for standard LDAP are different, but the basic principle in LISTSERV Maestro is the same: You configure how LISTSERV Maestro shall textually create the "username" part for authentication. This is then used together with the user's password input to forward actual password authentication to a remote server. The key differences are:

1. Instead of a Windows AD "User Authentication Principal", you configure a "Distinguished Name" (a DN).


2. The LDAP server must be accessible through SSL. This is required because otherwise the user's password would be sent through an unencrypted channel. The Kerberos protocol employed by LISTSERV Maestro's Windows AD authentication does not send the actual password. Instead, a more complex token exchange is performed, which is secure even if the connection is not encrypted.

Subscribe to LISTSERV at Work.