LDAP Active Directory Integration for Linux, Unix, and Mac OS X

Authentication, Group Policy, Audit and Reporting

How Likewise Enterprise Stores Unix Information in Active Directory

Likewise Enterprise lets you choose between two operating modes -- schema mode and non-schema mode -- giving you the flexibility to use your existing Active Directory schema, regardless of whether it complies with RFC 2307.

With Likewise, there is no requirement to make risky changes to your schema, there is no need for additional infrastructure, and there is no need to raise the forest functional level to Windows Server 2003.

The two operating modes work slightly differently. Schema mode takes advantage of the Unix- and Linux-specific RFC 2307 object classes and attributes to store Linux and Unix user and group information.In contrast, non-schema mode stores Linux and Unix data without requiring RFC 2307 object classes and attributes and without modifying the existing schema.

Non-Schema Mode: Using a ServiceConnectionPoint to Store Unix Information

In non-schema mode, Likewise Enterprise uses existing object classes and attributes to store its data. To store information about a cell, Likewise creates a container object and stores data in its description attribute. To store information about a group or user, Likewise creates a serviceConnectionPoint object and stores data in its keywords attribute. Both keywords and description are multi-valued attributes that can have multiple values while still allowing AD searches for specific values.

Specifically, in non-schema mode Likewise uses RFC 2307 attribute names to store values in the keywords and description attributes in the form name=value, where name is the attribute name and value is its value. Here's an example of how the keywords attribute name-value pairs can contain Unix and Linux information for an AD user:

uid=
uidNumber=1016
gidNumber=100000
loginShell=/bin/bash
unixHomeDirectory=/home/joe
gecos=
backlink=[securityIdentifierOfUser]
objectClass=CenterisLikewiseUser

In the example, the uid attribute is empty. It is needed only when you want to specify a name alias so that the AD user can log on a computer with something other than his or her AD account name. In ADSI Edit, the properties for a user look like this:

The keywords attribute is also used to store Linux and Unix group information. Here's an example of how the attribute name-value pairs can contain Unix and Linux information for a group:

backLink=[securityIdentifierOfGroup]
description=
displayName=
gidNumber=100000
objectClass=centerisLikewiseGroup

When you set an alias for a group, it is stored in the displayName attribute (for the group in the example above, no alias has been set, and thus displayName is empty). In ADSI Edit, the values of the keywords attribute look like this:

Schema Mode: Adopting RFC 2307 Object Classes and Attributes for Unix Information

Schema mode takes a slightly different approach. To store Linux and Unix user and group information, schema mode takes advantage of the Unix- and Linux-specific RFC 2307 object classes and attributes, namely the posixAccount and posixGroup object classes. For example, the posixAccount and posixGroup object classes include attributes -- uidNumber and gidNumber -- that Likewise uses for UID and GID mapping. In addition, Likewise uses serviceConnectionPoint objects to store the same information as in non-schema mode by using the keywords attribute.

If you choose to use schema mode and your schema does not comply with RFC 2307, you must modify the schema. The Likewise Domain Extension Wizard, which is a tool in the console, can automatically upgrade your schema to comply with RFC 2307. (Windows Server 2003 R2 complies with RFC 2307.) When you use schema mode with a schema that already complies with RFC 2307, Likewise does not change the schema, but you still must run the Domain Extension Wizard to include the RFC 2307 attributes in the global catalog and to index them for faster searches.

The Flexibility to Work with Your AD Use Case

The following table summarizes the differences between schema mode and non-schema mode:

Centralizing Access Control by Mapping UID and GID Information to AD Security Identifiers

Both schema mode and non-schema mode provide a method for storing Unix and Linux information in Active Directory -- including UIDs and GIDs -- so that Likewise can map security identifiers (SIDs) to UIDs and GIDs and vice versa. This mapping enables Likewise to use an Active Directory user account to grant a user access to a Unix or Linux resource that is governed by a UID-GID scheme. When an AD user logs on a Unix or Linux computer, the Likewise Agent communicates with the Active Directory Domain Controller through standard LDAP protocols to obtain the following authorization data:

• UID
• Primary GID
• Secondary GIDs
• Home directory
• Login shell

Likewise Enterprise uses this information to control the user's access to Unix and Linux resources.