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:
This post will focus on the schema portion of LDAP.
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 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:
|directoryString||18.104.22.168.4.1.1422.214.171.124.15||Unicode (UTF-8) string|
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 126.96.36.199.4.1.14188.8.131.52.15 for Unicode (UTF-8) strings, Active Directory uses 184.108.40.206:
These attribute syntaxes are generally not modifiable.
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:
The above objectClass is defined as “User,” but an also include (but is not limited to):
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.
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.
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.
With regards to name services/identity management, an attribute that might matter to us would include (but are not limited to):
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.
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.
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
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)
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: