Download the PDF  

Single Sign On (SSO) Implementation

The purpose of this document is to define how Single Sign On (SSO) via Active directory can be implemented for EMS logins utilizing LDAP authentication with Active Directory.  This enables a user to log into the EMS utilizing their Microsoft Active Directory username and password.  This login is also sometimes known as a domain login, or network login.  

Document Number

ENG-010633

Applies To

This document applies to EMS versions 31.3 and above.

LDAP Authentication Description 

LDAP, or Lightweight Directory Access Protocol, is an open vendor-neutral industry standard application protocol for accessing and maintaining distributed directory information services over an IP network. This allows the sharing of information about users, systems, networks, services and applications throughout the network. This allows the service to provide any organized set of records, including authentication.  

The most common use of LDAP is to store the username, passwords, and network access rights of users.  The most common software used to perform network authentication is Microsoft’s implementation of this protocol or Microsoft Active Directory.

The EMS client and server software as of SR31.3 supports an LDAP interface to Microsoft Active Directory. This enables logging into the EMS using the user’s network or domain username and password.  This will allow Single Sign On (SSO) throughout the enterprise and allow enabling and disabling of Active Directory users will disable those users in the EMS. 

The actual authentication will be performed by the EMS server to minimize the capability to spoofing of authentication. The client will send login credentials from the EMS client to the EMS server.  It is recommended that on EMS server and client install that Secure Client be selected to ensure all credentials are sent via a TLS encrypted link secured by a certificate.  This ensures that the client is authentic, allows access to the server and strongly protects the user’s credentials.  The EMS server will then open a secure connection to the LDAP server and attempt to authenticate the user to Windows Active Directory.  If the authentication is successful, the server will allow access to the EMS from that client session.  If the authentication fails, the user will be informed of the failure on the EMS client and denied access.   

A very similar architecture will be used for the Web client. The only difference is that since there is no client as a part of the web interface, the web user will only be allowed access via the HTTPS protocol.  This will ensure that a TLS1.2 link is utilized to protect the user credentials.  The server, as before, will perform the authentication with LDAP and provide access or not based on the results of the authentication.

In both the case of web auth and client authentication, the EMS server will get the users role and access rights to the EMS database from the role data stored on the EMS server. The user will be created by an admin user, the role assigned to the user, and then LDAP network access will be enabled for that user. 

For admin users, local logins will be enabled so that access can be maintained during a network outage that might deny access to the LDAP server.   

The authentication process will involve the following steps:

1. Collect Credentials: The EMS client will collect user credentials and the desired AD Domain to log into and will send them to the EMS server over the TLS1.2 encrypted connection between EMS server and client.
2. EMS Server Sends Credentials via LDAP to AD: The EMS will send the credentials using the LDAPS (LDAP over TLS1.2) to the Microsoft AD server.  Authentication is done by the server to prevent spoofing by the client.
3. Authentication Pass/Fail Sent from AD: Active Directory will authenticate the user credentials and send back a pass/fail for the authentication.
4. EMS will Retrieve Role Data: The EMS will use the role data associated with that username and domain and this will be used to control the access given to the user.
5. Authentication Pass/Fail to client: The authentication result is sent to the client and the user granted access or denied access.  

Configuration of LDAP Authentication

The following steps outline the high-level configuration flow for setting up Single Sign On authentication via Active Directory: 

• Configure the Active Directory Domain Services if the domain does not already exist.
  • Enable Group Policy Management
  • Set domain name (this is needed later in configuration)
• Verify Working domain using ldp.exe without Certificates
• Add Active Directory Certificate Services so LDAPS can be used
• Configure Active Directory CA
• Request AD Server Certificate
• Verify Proper LDAPS (Secure LDAP service) on the Server Machine
• Export the CA Root Certificate for installation on the EMS
• Import CA root certificate to the Tellabs Application Keystore of a remote client.
• Enable SSO Authentication on Tellabs Panorama PON
• Test SSO User login to Tellabs Panorama PON
• Troubleshooting Tips 

Configuration of Active Directory Domain

Microsoft documentation and training should be used to understand the creation and maintenance of Domains and Active Directories.  This section will only cover key settings needed for proper interop.  In most instances, the domain will likely already exist.  When configuring Active Directory, the "Active Directory Domain Service" must be added to the server role. Additionally, the feature "Group Policy Management" must be added.  These are settings that are typically selected in most AD setups.   

During the creation of the domain, you will create a root domain. You will need to know the root domain name in order to set up Single Sign On (SSO) on the EMS.  Please take note of the root domain name.

Verification of LDAP prior to securing with Certificate

Microsoft Active Directory after creation will enable the LDAP service.  At this point, you can verify basic connectivity to the LDAP service using the ldp.exe application.  This isolates connectivity prior to adding certificates.  Tellabs EMS to ensure strict security and therefore, in a later stage, LDAPS is required, but this is a good spot to test just connectivity and access to the AD server.  This step is not necessary and may not work on systems where LDAP has been disabled in favor of LDAPS (Secure LDAP over SSL). 

Execute the application ldp.exe as an Admin user or from a cmd window opened as an admin user.  You will be prompted for the server name, and port number. 

Enter the domain server Fully Qualified Domain Name (FQDN) and it will attempt to connect to the LDAP interface of Active Directory.

An output similar to the following will be displayed if the connection is successful.

Add Active Directory Certificate Services

Directory Services must be installed to use SSL (TLS 1.2) to communicate using LDAPS.  This requires that the Active Directory Certificate Service be installed, and certificates created on the Domain server.  This allows securing of all the interfaces with strong encryption and protects user credentials.  It is good practice to always use certificates and LDAPS for authentication to protect user credentials and data. 

The Active Directory Certificate Servers must be installed as a role on the Domain Server.

After the addition of the AD CS, the user will be warned to create a CA certificate which is necessary.  The CA or Certificate Administrator certificate allows the user to create and sign certificates that are used to secure communications. The user then needs to create a certificate for the server to secure communications, and it should be signed by the server's CA certificate.

Use the link on the right side of the screen to create the CA certificate under the Action column: "Configure Active Directory Certificate Authority" and create a root CA. 

It is recommended that the key be created with SHA1 and a key length of 2048 bits.

Typical CA Cert setup.

Request AD Server Certificate

Open the certificate console via the mmc snapin and request a new certificate for the domain controller if you do not already have one.

Request a domain controller certificate.

Open the certificate manager window(certsrv.exe), check "issued certificate" for certificates requested.

Switch back to certificate console, one new DC certificate has been added to the personal store. Double click it to check it.

Verify Proper LDAPS operation on the Server

The certificate installation should now enable the LDAPS service, which can then be utilized by the EMS for logins.  To verify the LDAPS service, run the ldp.exe program, input port "636" and hostname, and enable SSL.  The result window should return with the text:  "SSL connection successful." This indicates LDAPS service and certificates have been setup correctly on the server.  This should be executed on the domain server and verify everything is correct prior to setting up the EMS.

 You should see output similar to the following:

Ensure that you see that it established a connection and was able to retrieve the base DSA information. 

Export the CA Root Certificate from the Domain Server

The EMS will attempt to validate the certificate of the domain server. It is necessary that the CA root certificate be extracted so that it can be added to the EMS certificate store so that the EMS will accept the Domain Server’s certificate. 

To export the AD server CA root certificate to a file, first open the certificate console(certlm.msc), select the root certificate and use the right-click menu Export tab to export the certificate.

Since this is the root CA public certificate, it is safe to use Base-64 encoded X.509.

LDAPS Interop With Tellabs Application

For proper interop between the AD LDAPS and the Tellabs EMS Server application, the following steps need to be performed:

• Import the AD Server CA root certificate to the EMS Server application keystore.
• Configure the LDAP Server information via the Tellabs Client
• Test EMS login using authentication via Active Directory. 

Import AD Root CA to Tellabs Application Keystore

The certificate is imported using the certificateMgr.bat tool on the EMS server.

The certificate manager is found here:

             c:TellabsPanoramaPonbbmgrservercertificateMgr.bat

Execute this batch file to modify the certificate store and add the Windows Domain server CA certificate to the Tellabs Anchor Certificate store on the EMS. 

On the command prompt select option 3) PON EMS Device/Anchor certificate menu.

On the next prompt select option 3) Append to the Existing Anchor Certificates.

Then the system will prompt you to backup the certificates.

The system will then prompt you to login using an EMS user that has the CertificateAdmin role.  This will enable processing of the certificates.  Then enter the path to the certificate, including the file name.  This will then import the CA cert from the domain controller so that the EMS will trust the domain controller.

The EMS will now trust the domain controller and allow SSL connections with the domain controller for LDAPS.

Enable SSO Authentication on Tellabs Panorama PON

Once the system is properly set up, you can enable Single Sign On via Active Directory by enabling it on the EMS.   

First Login as a user with the Admin Role on Panorama PON. Then click the menu item:  

   "File -> Users" to bring up User Management view, then click on the Menu button.

   "Options -> User Authentication" opens an SSO Authentication configuration view.

Check Enable SSO LDAP Authentication and click the Add SSO LDAP Connection. Multiple LDAP connections can be added, which enables authentication to multiple domains if you have two or more sets of users authenticating to separate domains. This enables both users to authenticate to their respective LDAP/AD servers based on the domain they are in.

.

Give the connection a name and fill out the additional fields:

• Connection: Name the connection so that people can understand the connection name or domain they should authenticate to. This is the name that will appear on the login screen to identify the AD domain.
• Hostname/IP: Enter the Hostname or IP address of the Domain Server.
• Port: The standard port of 636 should be utilized.
• Base DN: The basis for the distinguished name. This must be configured to match the format in use by the Active Directory / LDAP server.  

  • The most common form is domainuser, also known as the down-level login name. The format can be verified at a user workstation by issuing the command whoami at the prompt in a command window.  
    
    In this example: 

      C:temp>whoami

       tellabs/johnd
    
    The Base DN would be tellabs and the username utilized in the EMS login would be johnd.
    
    If the Active Directory server utilizes the fully qualified domain name is used instead, it can be displayed utilizing the command: 

       C:temp>whoami /fqdn

    If the user is John.Doe@tellabs.com

       CN=John.Doe@tellabs.com,CN=Users,DC=tellabs,DC=network
    
    If this is the login method used, then the base DN would be equal to cn=Users,DC=tellabs,DC=network and the username entered into Panorama EMS should be john.doe@tellabs.com. This typically only works for users within the same organization; different organizations typically require different SSO LDAP connections.

• Enable LDAPS: You should always use LDAP with SSL/TLS to ensure proper protection of user credentials.
• Enable Connection: Enable the LDAPS connection to the AD Server.  
• With FQDN, authenticate with:
  • CN attribute for Common Name. This is the default selection for a typical LDAP/Active Directory setup in an enterprise domain.
  • UID attribute for Unique ID. This should ONLY be selected when using a cloud-based LDAP server that could be shared amongst various enterprises.

Input AD server information as example shown below, then click on the Apply button to save it. Once saved, all the fields are greyed out.

If you want to edit it or delete it, just move your mouse to the side area then double click, then the fields are editable except for the connection name. Use the Apply button to save the edit, or the Delete button to remove it. 

Add User

Add the same username to Tellabs EMS via the User Manager view. The username must match exactly. 

During the user's first login, the local password will be synchronized with the AD login so that if local login is needed, it will be using the current AD password as of the last EMS login.

Test SSO User Login to Tellabs Panorama PON

A new user, once SSO is enabled, is forced to use SSO (Active Directory) login on first login to the system.  This ensures that local and SSO passwords are synchronized and that the administrator no longer knows the user’s local password.

In order to sync passwords once SSO is enabled, all users must perform at least one SSO login.  After the first SSO login, users can login, locally or remotely.

Then, the user needs to choose the desired domain to perform the authentication against. DISABLED is used for local domain logins:  

If the login is successful, the status line at the bottom of the screen will show the last successful and number of unsuccessful logins since the last successful login.

Troubleshooting

If an error occurs at login, always press the detail button to see the detailed reason for failure. 

If the SSO username or password is wrong, then authentication will fail.  No further feedback is given from AD.  Windows login should be used as a troubleshooting step to test authentication if unexpected failures occur.

If the AD server is not reachable, the error will be SSO login failed and the detailed error code will show that the LDAP server cannot be reached:

If an SSO user is not present in the EMS database, the following error will be shown, and the detailed error information will indicate that the user needs to be added to the EMS database.

An SSO user will be locked out of the EMS due to failed login attempts exceeding the configured limit.  The account is locked out for the configured timeout.

The EMS users with an Admin role are the only users allowed to perform configuration of SSO Authentication.

Web Configuration of Active Directory Single Sign On

The web interface has also been modified to allow the configuration of Active Directory Server connections.  

Under the user dropdown menu, select SSO Domains:

• The user can then use the create button to create new LDAP connections to Active Directory Servers.
  
  
• The fields in the web interface are identical to those in the Java GUI.  Pressing the Apply button will add the new connection entry.
  
  
• Connection_Name: Name the connection so that people can understand the connection name or domain they should authenticate to.  This is the name that will appear on the login screen to identify the AD domain.
• Hostname/IP: Enter the Hostname or IP address of the Domain Server.
• LDAP Port: The standard port of 636 should be utilized.
• Base DN: Typically this would be of the form, cn=users,DC=<domain>,DC=<suffix>.  As an example "cn=users,DC=tellabs,DC=com".
• LDAPS TLS: You should always use LDAP with SSL/TLS to ensure proper protection of user credentials.
• Enable Connection: Enable the LDAPS connection to the AD Server.

Web Login of Active Directory Single Sign On User

The web login is slightly altered to support the Web login Single Sign on. The new SSO Authentication field will be shown. The dropdown will support local login via the Disabled option and will also list all the Active Directory servers that have been configured on the EMS Server. The user should select the appropriate SSO authenticator and then login as usual. Yubico authentication is independent of the Single Sign On and can still be used to implement two-factor authentication in addition to AD authentication.