LDAP::Schemin’ with schemas – Part 3

This post is part 3 of the new LDAP series I’ve started to help people become more aware of what LDAP is and how it works. Part one was posted here:

What the heck is an LDAP anyway?

This post will focus on the schema portion of LDAP.

homer-ldap-schema

What is a schema in LDAP?

A schema, as used by LDAP, is a set of defined rules that govern the kinds of information a server can hold. These include, but are not limited to:

  • Attribute Syntaxes—Provide information about the kind of information that can be stored in an attribute.
  • Matching Rules—Provide information about how to make comparisons against attribute values.
  • Matching Rule Uses—Indicate which attribute types may be used in conjunction with a particular matching rule.
  • Attribute Types—Define an object identifier (OID) and a set of names that may be used to refer to a given attribute, and associates that attribute with a syntax and set of matching rules. These are defined in detail in RFC-2252.
  • Object Classes—Define named collections of attributes and classify them into sets of required and optional attributes.
  • Name Forms—Define rules for the set of attributes that should be included in the RDN for an entry.
  • Content Rules—Define additional constraints about the object classes and attributes that may be used in conjunction with an entry.
  • Structure Rule—Define rules that govern the kinds of subordinate entries that a given entry may have.

When dealing with LDAP schemas, there are a subset of the above that we deal with on a regular basis for name services/identity management.

Attribute syntaxes

Attribute syntaxes define what type of information can be stored as an attribute. These are defined by an object identifier (OID) and control whether an entry can be in Unicode, integer format or other format.

The following table from OpenLDAP.org shows some commonly used attribute syntax OIDs:

Name OID Description
boolean 1.3.6.1.4.1.1466.115.121.1.7 boolean value
directoryString 1.3.6.1.4.1.1466.115.121.1.15 Unicode (UTF-8) string
distinguishedName 1.3.6.1.4.1.1466.115.121.1.12 LDAP DN
integer 1.3.6.1.4.1.1466.115.121.1.27 integer
numericString 1.3.6.1.4.1.1466.115.121.1.36 numeric string
OID 1.3.6.1.4.1.1466.115.121.1.38 object identifier
octetString 1.3.6.1.4.1.1466.115.121.1.40 arbitary octets

Microsoft Active Directory LDAP uses different OIDs for their attribute syntaxes. These can be seen in the schema via ADSI edit. As an example, while OpenLDAP uses an OID of 1.3.6.1.4.1.1466.115.121.1.15 for Unicode (UTF-8) strings, Active Directory uses 2.5.5.12:

attr-syntax-unicode

These attribute syntaxes are generally not modifiable.

Object classes

Object classes in LDAP are collections of specific types of attributes that help LDAP searches execute more efficiently. When a search is kicked off, the objectClass is passed in the search. For example:

Filter: (&(objectClass=User)(sAMAccountName=ldapuser))

The above objectClass is defined as “User,” but an also include (but is not limited to):

  • Person
  • organizationalPerson
  • Group
  • Top

For a complete list of objectClass attributes, see: http://oav.net/mirrors/LDAP-ObjectClasses.html

In Active Directory, the objectClass can be modified and viewed via the Active Directory Users and Computers in advanced view via the Attribute Editor tab.

attribute-edit-objectclass

When a LDAP search runs, it would pass the defined schema attribute for objectClass as defined in the client configuration. In NetApp’s clustered Data ONTAP, it would be passed via one of the object-class attributes:

cluster::*> ldap client schema show -vserver SVM -schema AD-IDMU -fields nis-object-class
 (vserver services ldap client schema show)
vserver schema  nis-object-class
------- ------- ----------------
SVM     AD-IDMU nisObject
cluster::*> ldap client schema show -vserver SVM -schema AD-IDMU -fields nis-netgroup-object-class
 (vserver services ldap client schema show)
vserver schema  nis-netgroup-object-class
------- ------- -------------------------
SVM     AD-IDMU nisNetgroup
cluster::*> ldap client schema show -vserver SVM -schema AD-IDMU -fields posix-group-object-class
 (vserver services ldap client schema show)
vserver schema  posix-group-object-class
------- ------- ------------------------
SVM     AD-IDMU Group
cluster::*> ldap client schema show -vserver SVM -schema AD-IDMU -fields posix-account-object-class
 (vserver services ldap client schema show)
vserver schema  posix-account-object-class
------- ------- --------------------------
SVM     AD-IDMU User

In a Linux client like RedHat running SSSD, it might look like this:

# cat /etc/sssd/sssd.conf | grep class
ldap_user_object_class = user
ldap_group_object_class = group

In general, we could think of objectClasses like we’d think of how we use a phone book’s Yellow Pages. We don’t look for things in the Yellow Pages by name, but rather by type of business. If we wanted to find a grocery store, we’d use an objectClass of “groceryStore” to filter our results to speed up our search.

Attributes

The most relevant and necessary parts of a LDAP server’s schema (at least when it comes to client configuration) are the attributes themselves. These are the specific entries in the LDAP schema that define who and what the object is, specifically. If we extend our Yellow Pages analogy, after we find the objectClass=groceryStore, these would be the phone number, address, etc. of the grocery store. That information happens to be the most critical portion of the object, as they tell us what we need to know about the object we were looking for.

In a LDAP server used for name services/identity management, the attributes will tell us information about users, groups, hosts, netgroups, etc. such as phone numbers, email addresses, physical location, IP addresses, UID/GID for UNIX based permissions, SIDs for Windows environments and many, many more.

Attributes are broken down into two categories: the attribute and the value.

The attribute

With regards to name services/identity management, an attribute that might matter to us would include (but are not limited to):

  • uid
  • uidNumber
  • gid
  • gidNumber
  • memberOf
  • objectClass
  • primaryGroupID
  • objectSid
  • sAMAccountName

These attributes are defined in schema templates of clients and should be compliant with RFC-2307 standards for a valid LDAP server configuration. Common LDAP servers such as Microsoft Active Directory, OpenLDAP, Sun Directory Server, RedHat Directory Server (and IdM), Apple Open Directory, Oracle Internet Directory, Vintela… these all fall under the RFC standards. For a list of LDAP software available, see this Wiki entry.

The value

This is the portion of the attribute that populates the information we want to be used in queries. For example, if I have an attribute of uid, I can populate the value with the list of UNIX names I want to use in queries.

When a LDAP search is issued, the attribute and value are passed.

Filter: (&(objectClass=User)(sAMAccountName=ldapuser))

In the above, both objectClass and sAMAccountName are attributes. User and ldapuser are values.

How do I change them?

Attribute values are editable in most cases, but in some cases, the LDAP schema might have set the value to “read only.” This is fairly common in Active Directory as a means of idiot-proofing/CYA. But there often are ways to modify the schemas to allow editing of these attributes, if desired. Always do this with caution, and ideally, in a lab first and with the guidance of your LDAP server vendor.

Attributes themselves are also editable. We can also create custom attributes in LDAP if we choose. 3rd party LDAP products like Vintela do this for you. But in most cases, it’s best to leave the default schemas alone, and instead, modify the clients to query the attributes we have populated. Many clients have default schema templates, including NetApp’s clustered Data ONTAP.

 Schema Template: AD-IDMU
 Comment: Schema based on Active Directory Identity Management for UNIX (read-only)
 RFC 2307 posixAccount Object Class: User
 RFC 2307 posixGroup Object Class: Group
 RFC 2307 nisNetgroup Object Class: nisNetgroup
 RFC 2307 uid Attribute: uid
 RFC 2307 uidNumber Attribute: uidNumber
 RFC 2307 gidNumber Attribute: gidNumber
 RFC 2307 cn (for Groups) Attribute: cn
 RFC 2307 cn (for Netgroups) Attribute: name
 RFC 2307 userPassword Attribute: unixUserPassword
 RFC 2307 gecos Attribute: name
 RFC 2307 homeDirectory Attribute: unixHomeDirectory
 RFC 2307 loginShell Attribute: loginShell
 RFC 2307 memberUid Attribute: memberUid
 RFC 2307 memberNisNetgroup Attribute: memberNisNetgroup
 RFC 2307 nisNetgroupTriple Attribute: nisNetgroupTriple
ONTAP Name Mapping windowsAccount Attribute: msDS-PrincipalName
 Vserver Owns Schema: false
 RFC 2307 nisObject Object Class: nisObject
 RFC 2307 nisMapName Attribute: nisMapName
 RFC 2307 nisMapEntry Attribute: nisMapEntry

Schema extension

By default, Microsoft Active Directory do not contain the UNIX attributes needed to use the server as a UNIX Identity Management server. The schema had to be extended to create the necessary attributes types to allow for proper UNIX-based authentication. Extending the schema in domains with multiple domain controllers is non-disruptive; only one server needs to have the schema extended and then it can replicate to the other servers. For information on extending schemas or enabling identity management, see the TechNet article on IDMU.

UNIX-based LDAP servers such as OpenLDAP don’t have to do this, as they are intended for use with UNIX authentication by default.

Replication of schemas

One of the reasons I like Microsoft’s Active Directory so much for UNIX identity management (aside from the integration of services and pre-existence in enterprise environments) is the built-in schema replication. Want to create a new LDAP server? Cool. Add it to the domain. You’re done.

Microsoft Active Directory replicates every 15 minutes by default. That means all schemas, attributes, etc. get copied over to all domain controllers in a domain.

In a forest with multiple domains, it’s possible to replicate UNIX attributes across those domains to allow cross-domain UNIX authentication. So if your company acquires another company, you can simply add their domain to your forest and enable replication of their UNIX attributes and keep using your existing set up. I describe how to do this in TR-4073 on page 103.

Non-Windows LDAP servers also have the capability to replicate schemas and attributes, but they need configuration and are not as robust as Windows, in my opinion. This is changing somewhat with RedHat Directory Server/IdM, especially with RedHat 7 and the ability to integrate into Active Directory domains. I’ll cover that set up in a later blog post. 🙂 (thanks to Natxo for pointing out that omission)

What else?

LDAP schemas are the lifeblood of directory services, so it’s important to understand them as best as possible. Hopefully this post has helped clear some things up.

For more detailed information on LDAP configuration (particularly with NetApp clustered Data ONTAP), see TR-4073: Secure Unified Authentication.

Also, stay tuned for more in the series of LDAP basics on this blog! Links to other sections can be found on the first post in this series:

What the heck is an LDAP anyway?

Advertisements

5 thoughts on “LDAP::Schemin’ with schemas – Part 3

  1. Nice write-up, thanks!

    By the way, openldap is not the only game in town for the linux folks. Running Red Hat’s Identity Management creating replica’s was just a question of spinning a new host and running a few commands: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/Setting_up_IPA_Replicas.html

    The ldap software is 389 directory server: http://directory.fedoraproject.org/

    Like

  2. Pingback: LDAP::What the heck is an LDAP anyway? – Part 1: Intro | Why Is The Internet Broken?

  3. Pingback: LDAP::LDAP servers and clients and bears, oh my! – Part 5 | Why Is The Internet Broken?

  4. Pingback: LDAP::LDAP Servers and Clients – Part 5 | Why Is The Internet Broken?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s