Introduction

Download this manual as a PDF file

This section is intended for administrators who create and manage user accounts. This section assumes that you are familiar with LDAP and/or Active Directory. If you are not familiar with LDAP or Active Directory, you will need to work with your LDAP or Active Directory administrator to perform the tasks in this section.

Use the following menu options to navigate the SL1 user interface:

  • To view a pop-out list of menu options, click the menu icon ().
  • To view a page containing all of the menu options, click the Advanced menu icon ().

What is LDAP?

LDAP (Lightweight Directory Access Protocol) is an application protocol for directory services that runs over TCP/IP. An LDAP directory server provides system administrators with a centralized tool for authenticating users and managing user access on a network and the devices in the network.

What is Active Directory?

Active Directory is Microsoft's implementation of LDAP. Although Active Directory includes some platform-specific features that differ from a standard LDAP implementation, the terminology used in SL1 is also used by LDAP and Active Directory.

LDAP and Active Directory Terminology

A directory (either LDAP or Active Directory) is organized in a tree structure. To understand how directories work with SL1, you should understand the following terms:

  • Entry. A directory tree is made up of entries. Each entry can have a parent entry and multiple child entries. An entry is made up of attributes.
  • Object Class. All LDAP and AD entries in the directory have a type. That is, each entry belongs to one or more object classes that identify the type of data represented by the entry. The object class specifies the mandatory and optional attributes that can be associated with an entry of that class. The object classes for all objects in the directory form a class hierarchy. The classes "top" and "alias" are at the root of the hierarchy. For example, the "organizationalPerson" object class is a subclass of the "Person" object class, which in turn is a subclass of "top". When creating a new entry, you must always specify all of the object classes to which the new entry belongs.
  • Attribute. Each entry in the directory is made up of attributes. Each attribute is made up of an attribute name and one or more attribute values. For example, for the attribute "SN", the name of the attribute is "SN", short for surname. The value could be "Jones". The combination of SN and its value make up an attribute.
  • Domain. Usually the root of a directory tree. Each directory system includes at least one domain. The domain includes the directory server and its clients. Most directories use DNS names as domain names. For example, a directory could use the domain "acme.com".
  • DC. A domain is made up of DC (domain components). If a directory uses the domain "acme.com", the directory will have two DCs: "dc=acme, dc=com".
  • DN. Each entry is assigned a DN (distinguished name). The DN is a unique identifier for the entry. The DN includes an RDN (relative distinguished name) constructed from some attribute(s) in the entry, followed by the parent entry's DN. Think of the DN as a full filename and the RDN as a relative filename in a folder. An entry's DN might change over the lifetime of the entry. For example, an entry's DN might change when parent and child entries are moved within the directory tree.
  • RDN. The RDN (relative distinguished name) is a unique identifier for the entry. For a user, the RDN is frequently the user's full name. An RDN is made up of one or more attributes.
  • OU. An OU (organizational unit) allows you to create a hierarchical structure to your directory tree. Some common OUs are "ou=people" or "ou=devices". An OU is referenced with its full path, for example "ou=Users, ou=ScienceLogicHQ, DC=ScienceLogic, DC=local".
  • Search Base. A search base specifies the location in the directory from which to begin a search. Search base is specified with a DN.
  • Bind. In directory applications, a bind operation authenticates and allows access to the server where the directory resides.
  • uid. Attribute for user ID. This attribute can be used in SL1.
  • CN. Attribute for common name. This attribute is usually assigned a value that contains the user's first name and last name.

LDAP and Active Directory are binary protocols. However, you can use LDIF (LDAP data interface format) to view directory data. In LDIF, a directory entry for a user might look like this:

dn: cn=John Doe,dc=company,dc=com
cn: John Doe
givenName: John
sn: Doe
uid: jdoe
telephoneNumber: +1 888 555 6789
telephoneNumber: +1 888 555 1234
mail: jdoe@company.com
street: 123 Commonwealth Avenue
l: Boston
st: Massachusetts
postalCode: 02134
manager: cn=Sally Smith,dc=company,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top

  • dn is the unique identifier for the entry. The combination of CN plus the root domain uniquely identifies this entry. Note that a dn is an identifier and not an attribute.
  • "cn=John Doe" is the entry's RDN (Relative Distinguished Name). The value of the CN attribute uniquely identifies this entry within its groups and domain.
  • "dc=company,dc=com" is the DN of the parent entry, where dc denotes Domain Component. So the parent entry for John Doe is the domain "company" within the domain "com".
  • The remaining lines display the attributes for this entry. Attribute names are usually mnemonic strings, like "sn" for surname, "givenname" for first name, and "st" for state.

How Can I use LDAP or Active Directory with SL1?

Administrators can use LDAP or Active Directory to authenticate users. There are two ways to use LDAP or Active Directory authentication with SL1:

  1. You can configure SL1 to automatically create user accounts in SL1 for all existing LDAP or Active Directory users and then always use LDAP or Active Directory to authenticate those users when they log in to SL1.
  • Each user logs in to SL1, either through the login page, a CAC card or certificate, or HTTP. The user logs in to SL1 using an LDAP or AD attribute value as a login name and the LDAP or AD password.
  • SL1 examines the login request and applies the appropriate Authentication Profile (and the appropriate Authentication Resource).
  • SL1 then authenticates the user by communicating with the LDAP or Active Directory server.
  • SL1 then creates a ScienceLogic account for the user, using both the mappings defined in the Authentication Resource and a ScienceLogic user policy.
  • SL1 displays the default page in SL1.
  1. You can use LDAP or Active Directory to authenticate one or more users when they log in to SL1. You can also specify that SL1 won't authenticate other LDAP or Active Directory users.
  • Each user logs in to SL1, either through the login page, a CAC card or certificate, or HTTP. The user logs in to SL1 using an LDAP or AD attribute value as a login name and the LDAP or AD password.
  • SL1 examines the login request and applies the appropriate Authentication Profile (and the appropriate Authentication Resource(s)).
  • SL1 then authenticates the user by communicating with the LDAP or Active Directory server.

How Can I View My Company's Active Directory or LDAP?

Some of the steps in this section require you to be familiar with the structure of your company's Active Directory implementation or LDAP implementation.

To view your company's Active Directory structure, talk to your Active Directory administrator, and try using a tool like ldp.exe.

To view your company's LDAP structure, talk to your LDAP administrator, and try using a tool like phpLDAPAdmin.