LDAP Quick Start Guide - SevOne NMS 5.7

What's this LDAP I keep hearing about?

If you've attended any cocktail parties, you've probably heard the term LDAP tossed around. And if you're not already familiar with LDAP, you've likely wondered what all the buzz is about.

LDAP refers to the Lightweight Directory Access Protocol. It's a standards-based protocol used to query and modify directory services. This way, organizations can maintain centralized directories of users. Not only that, distributed applications can authenticate against those directories.

LDAP directories use a tree structure for storing information. This structure is known as a Directory Information Tree (DIT). The directory tree contains three main components:

• Trunk

• Branches

• Leaves

The trunk is the directory root. It'll likely be named after your domain. For example, if your domain is hobgoblins.org, the root of your directory would be named dc=hobgoblins, dc=org. The branches of the trunk are organizational units. If your organization has multiple sites, you might have an organizational unit, or ou, for each site. For example, you could have one ou for California, another for Texas, and one more for Pennsylvania.

Just as an individual branch can have its own branches, an ou can have, or contain, its own ous. The ous mentioned above might each contain three subordinate ous: a Users ou, a Groups ou, and a Machines ou. These ous can also contain ous, but they don't have to. The Users ou, for instance, might just contain the users for that location. The actual user entries would be considered leaves because they can't contain any subordinate entries.

A few benefits of the tree structure are:

• Increased ease of administration and maintenance

• Flexible application of security policies and access controls

• Scalability

• Simplified resource sharing

Common systems that provide implementations of LDAP include Microsoft's ActiveDirectory, the open source OpenLDAP project, and the Oracle Internet Directory product line.

Will LDAP make me a better person?

No, but it's still pretty useful. A lot of organizations have standardized on LDAP-based directory platforms and would like to apply the user and group structures maintained in that directory within SevOne NMS. There are two main reasons for this integration:

1. Synchronization - You can incorporate existing user group or user role information into SevOne NMS with the Group Synchronization option. When you synchronize a group into SevOne NMS, the members of that group are automatically added to SevOne NMS. This saves you the trouble of manually adding users who already exist in your directory.

   A user group in LDAP creates a user role in SevOne NMS. However, manually adding a user to that role may result in automatically removing the added user from that role and/or deleting it from SevOne NMS.

2. Authentication - You can set up SevOne NMS to accept authentication using existing passwords stored in your central directory.

So, by configuring LDAP in SevOne NMS, you're just managing user access and credentials in your LDAP instance without having to do it in SevOne NMS, too. What's more, with LDAP group synchronization, you can sync up an LDAP group into SevOne NMS as a user group or user role (user roles are included in SevOne NMS version 5.3 and higher). This automatically adds the LDAP group and all its users into SevOne NMS and eliminates the need to maintain user access.

This is closely related to a nifty concept known as single sign-on, which we'll talk about shortly.

A note on terminology.

LDAP likes to use the term User Groups. SevOne, on the other hand, prefers to say User Roles. This lines up with our implementation of Role-based Access Control in NMS version 5.3 and higher. Basically, these two concepts become the same thing after synchronization.

What should I expect to see with LDAP?

By configuring LDAP authentication, you enable single sign-on (also known as SSO). Single sign-on permits a user's network password to be shared between multiple resources. This means that users don't have to enter a separate set of credentials each time they log into an application, website, etc. that they're authorized to use.

One of the great selling points of single sign-on is efficiency. It eliminates the need for users to have multiple passwords. This, in turn, lessens the risk of users forgetting passwords or using wrong passwords. Users are happy because they spend less time reentering passwords, and IT folks are happy because they spend less time resetting passwords.

Is there anything I need before I get started?

For starters, you'll need to have an LDAP server up and running. Your LDAP administrator may want to create a specific group for SevOne NMS users. For example, the administrator might create a group called SevOne Users, which would contain existing users who will be working with SevOne NMS on a regular basis. You'll also need to have a few bits of information handy. Your LDAP administrator should be able provide you with any information you don't have already. Below is the breakdown of what you'll need.

LDAP Server

This can be either the host name or the IP address of the LDAP server. For example, imagine that you work for a company that sells okra-frying appliances. Your LDAP server might be at ldap.okrafryers.com, which has the IP address of 192.168.10.22. You could either use the host name ldap.okrafryers.com or the IP address 192.168.10.22.

Port

Which network port is your LDAP server on? The default port for LDAP traffic is port 389, but make sure to check with your LDAP administrator in case a different port is used. The LDAP server generally accepts clear text connections on port 389. For LDAP connections over SSL (LDAPS), you would typically use port 636.

Bind DN

The bind distinguished name, or bind DN, is the user name for authenticating to the LDAP server. The bind DN's authorizations also allow SevOne NMS to search the directory tree. A couple of examples of bind DNs are cn=guest and cn=users.

Bind Password

This is the password for the bind DN that you entered in the previous step. A password isn't required in LDAP version 3 (LDAPv3).

Base DN

The base distinguished name, or base DN, refers to the top level of the directory tree. This is the starting point for searches. For an Active Directory system, the format of the base DN is generally dc=example, dc=com. Imagine, for example, that you own a chain of stores where customers get made over to look like clowns. You've named your company Clown Makeovers, Inc., and you have a website at www.clownmakeovers.com, where customers can locate stores and schedule makeovers. Your base DN would be dc=clownmakeovers, dc=com.

User Attribute

This is the attribute that SevOne NMS will check to find user names. Active Directory generally uses sAMAccountName while other directories might use uid or cn.

Encryption

There are two options for securing the connection to your LDAP server: SSL and StartTLS.

Security Sockets Layer (SSL) is a security protocol used for establishing an encrypted connection between a client and server. Sometimes the term SSL is used interchangeably with TLS, which stands for Transport Layer Security. TLS is the successor of SSL. After SSL version 3 (SSLv3.0), the protocol became known as TLS, with the first version being TLS version 1 (TLSv1.0). SSL generally uses port 636. The use of SSL has been deprecated, with StartTLS being the preferred standard.

StartTLS isn't actually a protocol but rather a protocol command. As you might have guessed, the TLS in StartTLS refers to Transport Layer Security. When enabled, StartTLS sends a command to upgrade an existing plain text connection to an encrypted connection using SSL/TLS. StartTLS normally runs on port 389 and doesn't require using a separate port for SSL/TLS. This is because SSL/TLS is applied after the connection is made.

Your LDAP administrator should be able to tell you which option to use.

SSL/TLS Certificates

During LDAP configuration, you'll have the option to upload and ignore certificates.

• Uploading Certificates. If your LDAP server's SSL/TLS certificates are signed by an unknown CA, you'll need to upload the certificates. This will enable SevOne NMS to authenticate to your LDAP server. Certificates need to be base64-encoded PEM files.

• Ignoring Certificates. Ignoring certificates means that SevOne NMS will still allow the connection to your LDAP server but won't be able to validate the identity of the LDAP server. This is like standing behind your front door and saying, "I don't know if you are who you say you are, but come on in!"

  If you change this setting, you must contact SevOne Support for it to properly take effect.

Configuration Steps

In this section, we'll cover the following topics.

• Adding and editing LDAP servers

• Testing LDAP server connections

• Synchronizing directory groups

• Adding a guest user

• Specifying SSL/TLS certificate settings

• Uploading a root certificate

Troubleshooting

Check the basics.

It's a good idea to start with the basics. If you've added a server and the connection test has failed, double-check that all the basic settings are correct. Select the server in question and click to display the Edit LDAP Server pop-up. Check line-by-line to confirm that the information in the fields is accurate. If you used a bind password, try reentering it to see if that fixes the problem.

You uploaded a certificate, and the server connection test fails when using StartTLS or SSL.

There are a few possibilities here:

1. The newly uploaded certificate may not have taken effect yet. Just give it a few minutes and try again. If that doesn't work, proceed to the next step.

2. Something went wrong during the upload. Try uploading your certificate again and wait about five minutes for it to take effect. If that doesn't work, proceed to step 3.

3. There's a problem with your certificate. If there's a problem with the certificate itself, you may need to get another copy of the certificate file. Upload the new certificate file and wait about five minutes for it to take effect. If you're still having problems after that, the original certificate file may be corrupted. If it is, you'll need to get a good certificate file and upload that. Once again, give it about five minutes to take effect.

Terms