UNIX

Having tested a couple of the previous releases of OpenBSD on various versions of ESX Server (OpenBSD 3.8 here and version 3.9 here), I decided to test OpenBSD 4.1 on ESX Server 3.0.1.  I didn’t really expect any problems at first, but then I stumbled across this article describing a problem between OpenBSD 4.1 and ESX Server 2.5.  Fortunately, it appears as if that problem does not affect ESX Server 3.0.1.

The VM configuration was pretty straightforward; just change the SCSI controller to LSI Logic instead of BusLogic and everything should work beautifully.  The OpenBSD 4.1 release notes indicate a new driver for the VMware VMXnet NIC driver, but I haven’t had the opportunity to test this yet; my installation is still using the pcn0 driver.

After installing OpenBSD, I was able to successfully install a number of packages using pkg_add (pulling the packages down via FTP).  Not confident that I had transferred enough data to be sure that I wasn’t going to see the same issue the other blogger ran into with his installation, I fired up Interarchy and transferred a 450MB ISO file via SFTP.  The file transfer completed successfully and I ran into no problems.

I’ll likely experiment with adding the VMXnet driver within the next few days to see how that works and how it affects network performance.

Thanks to some very helpful individuals in the #solaris channel on irc.freenode.net, I’ve been able to get ADS support working in Samba on Solaris 10, and thus have been able to incorporate the use of Samba in the Solaris 10-AD integration instructions.

To refer to earlier versions of the Solaris 10-AD integration instructions, see this article or this article. I would expect that you won’t need to refer to those posts, though, and will be able to get most of what you need directly from this post.

Assumptions

This procedure assumes that you are using Windows Server 2003 R2; if you are using a previous version, the LDAP attribute mapping will need to be modified to match the schema extensions found in Microsoft’s Services for Unix (SfU) add-on product. This will require changes to the “ldapclient manual” command shown below, which handles the schema/attribute mapping. (I only have a single article written that includes pre-R2 attribute mapping, and that’s this Linux-AD article. The schema mapping should be very, very similar between that article and Solaris 10.)

Preparing Active Directory (One-Time)

These steps only need to be performed once. Note that if you have performed any of these steps as part of authenticating Linux or Solaris to Active Directory, they do not need to be performed again. Simply make note of the information used earlier and re-use that information again this time.

1. Install the “Server for NIS” component on at least one Active Directory domain controller (DC), so that the Active Directory schema can be extended to become partially RFC 2307-compliant. Installing this component will also add a “UNIX Attributes” tab to objects inside the Active Directory Users and Computers MMC console. You may also need to install the Server for NIS administrative tools on your workstation to see the “UNIX Attributes” tab.
2. Use the Schema Management MMC snap-in to index the uid attribute, which is not indexed by default. This will speed up the login process and reduce the overall load on your DCs. (For more information, refer to the Linux-Windows Server 2003 R2 integration instructions.) It may be possible to change the attribute that Solaris is looking for, but I haven’t found a way to do that yet.
3. Create an account in Active Directory that will be used to bind to Active Directory for LDAP queries. This account does not need any special privileges; in fact, making the account a member of Domain Guests and not a member of Domain Users is perfectly fine. I recommend giving this account a simple, short name; this will make specifying the DN of the account later easier to do.
4. Create a global security group in Active Directory Users & Computers and set the UNIX attributes for this group.

Once these one-time steps have been completed, we can proceed to configuring the individual users that will be authenticating to Active Directory from your Solaris server(s).

Preparing Active Directory (Each User)

Each Active Directory account that will authenticate via Solaris must be configured with a uid and other UNIX attributes. This is accomplished via the new “UNIX Attributes” tab on the properties dialog box of a user account (this tab was made visible by the installation of the Server for NIS component). The attributes that must be populated are:

• NIS domain: It’s required on this tab in order to populate the other fields, but we won’t be using it.
• UID: This is actually the UID number. Each user must have a unique UID; I believe that the Server for NIS defaults at a starting UID of 10000, which is pretty safe for most systems.
• GID: In addition, each member must have a GID (group ID); simply specify the group that was created earlier.
• Login Shell: Specify a login shell (such as “usr/bin/csh” or “/sbin/sh”) for each user.
• Home Directory: Specify the home directory (such as “/export/home/slowe”) that will be used for this user. Keep in mind that these values may apply across multiple systems and platforms, and the path must be valid on all systems and platforms.

Based on my experience so far, the values for Solaris will often be very different than what might be specified for Linux-based logins. The only workarounds I’ve found to address these issues is the clever use of symlinks and the use of NFS automounts for home directories.

After all the user accounts have been configured, then we are ready to perform the additional tasks within Active Directory and on the Solaris server(s) that will enable the authentication.

Configuring Reverse DNS

On the DNS server handling the reverse lookup zones for the subnet on which the Solaris server is located, add a PTR record for the Solaris server and it’s IP address. This will ensure that reverse DNS lookups work as expected. Make sure that each Solaris server that will be authenticating against Active Directory has a reverse lookup record in DNS, and ensure that both forward and reverse lookups work from each of the Solaris server(s).

Configuring Solaris (Each Server)

The following steps need to be performed on each Solaris server that will authenticate against Active Directory.

Configuring the hosts file

To enable reliable TGT validation (this ensures that the Kerberos ticket returned by a KDC actually came from the KDC and not a spoofed server), you’ll need to edit the hosts file. On Solaris 10, this is found in /etc/inet/hosts and is read-only, even for root. Edit this file (changing permissions as necessary) so that the line with the server’s IP address looks something like this:

10.1.1.1      hostname.example.com hostname loghost

What we’re doing here is making sure that the server’s fully qualified domain name (not just the short hostname) is the first name entry on the line for the server’s IP address.

There may or may not be other entries in the file; leave those entries untouched (unless you know you need to modify them).

Installing Blastwave Packages

This is the key to getting ADS support into Samba on Solaris 10. I won’t go into excruciating detail on this since this process is amply covered elsewhere, but here’s the basic idea of the process:

• Use the standard wget (found in /usr/sfw/bin) to download the pkg-get file used by Blastwave.
• Use pkgadd to install pkg-get.
• Configure pkg-get to use the unstable packages (makes sure you get the latest builds).
• Use pkg-get to install the CSWsamba package and all requisite packages (there were quite a few dependency packages during my testing).

Once the CSWsamba package and related packages are installed, we’ll need to configure Samba by creating /opt/csw/etc/samba/smb.conf with the following contents:

workgroup = <NetBIOS name of AD domain>
security = ads
realm = <DNS name of AD domain in UPPERCASE>
use kerberos keytab = true
password server = <Space-delimited list of AD DCs>

At this point, we are ready to configure Kerberos and then proceed with testing the configuration and join the Active Directory domain.

Configuring Kerberos

Solaris keeps its Kerberos configuration in the /etc/krb5 directory as krb5.conf. Edit this file using your editor of choice to look something like the one below. Depending upon how you configured Solaris during the installation, some of this configuration may already be present.

[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_kdc = true
 
[realms]
EXAMPLE.COM = {
kdc = dc01.example.com
kdc = dc02.example.com
admin_server = dc01.example.com
}
 
[domain_realm]
.example.com = EXAMPLE.COM
.subdomain.example.com = EXAMPLE.COM
 
[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
kdc_rotate = {
period = 1d
version = 10
}
 
[appdefaults]
kinit = {
renewable = true
forwardable= true
}

There will also be a file named cswkrb5.conf in the /etc directory; you can configure this file with the contents of the [libdefaults], [reamls], and [domain_realms] sections as listed above. You don’t need to include the [logging] or [appdefaults] sections in this file.

Note that you can’t simply copy and paste from here to the Solaris configuration files, as you’ll need to customize your version for your particular network, hostnames, domain names, etc. If you must copy and paste from here, put it into a text editor first to customize it for your implementation.

Configuring LDAP

We’ll use the native Solaris “ldapclient” utility to configure the LDAP support in Solaris. The command you’ll type in looks something like this (please don’t copy and paste this, as it contains generic/incorrect information that won’t work!):

ldapclient manual \\
-a credentialLevel=proxy \\
-a authenticationMethod=simple \\
-a proxyDN=cn=proxyuser,cn=Users,dc=example,dc=com \\
-a proxyPassword=Password1 \\
-a defaultSearchBase=dc=example,dc=com \\
-a domainName=example.com \\
-a "defaultServerList=172.16.1.10" \\
-a attributeMap=group:userpassword=userPassword \\
-a attributeMap=group:memberuid=memberUid \\
-a attributeMap=group:gidnumber=gidNumber \\
-a attributeMap=passwd:gecos=cn \\
-a attributeMap=passwd:gidnumber=gidNumber \\
-a attributeMap=passwd:uidnumber=uidNumber \\
-a attributeMap=passwd:homedirectory=unixHomeDirectory \\
-a attributeMap=passwd:loginshell=loginShell \\
-a attributeMap=shadow:shadowflag=shadowFlag \\
-a attributeMap=shadow:userpassword=userPassword \\
-a objectClassMap=group:posixGroup=group \\
-a objectClassMap=passwd:posixAccount=user \\
-a objectClassMap=shadow:shadowAccount=user \\
-a serviceSearchDescriptor=passwd:dc=example,dc=com?sub \\
-a serviceSearchDescriptor=group:dc=example,dc=com?sub

The easiest way to handle this would probably be to copy it into a blank text file, edit it to include the specific details for your network, and then paste it into a terminal session on the Solaris server.

After this command has been run, Solaris will create the LDAP configuration in /var/ldap and will update /etc/nsswitch.conf to use LDAP. However, because we only want to use LDAP for specific purposes, we’ll need to go back and edit /etc/nsswitch.conf again. Just remove “ldap” from all entries in /etc/nsswitch.conf except for passwd and group.

While you’re editing /etc/nsswitch.conf, be sure to add a “dns” entry at the end of the line for hosts:

hosts      files dns

This will help ensure that Solaris is properly configured to use DNS for host name resolution.

I think it’s necessary at this point to restart the LDAP client service:

svcadm restart svc:/network/ldap/client:default

Use the “svcs -a | grep ldap” command to verify the exact name of the LDAP client service on your Solaris server.

Configuring the DNS Client

You’ll also need to make sure that the DNS client is enabled and running. Using “svcs -a | grep dns” will help you identify the correct service, which you can then enable with svcadm:

svcadm enable svc:/network/dns/client:default

Test DNS resolution using the “nslookup” command. As mentioned previously, be sure to test both forward and reverse lookups.

Configuring PAM

The /etc/pam.conf file controls the PAM (Pluggable Authentication Mechanism) configuration on Solaris. You’ll need to edit the /etc/pam.conf file to look something like what’s shown below. I’ve edited away all the non-essential sections, so only change the sections listed below.

# Default definition for Authentication management
#
other auth requisite pam_authtok_get.so.1
other auth required pam_dhkeys.so.1
other auth sufficient pam_krb5.so.1
other auth required pam_unix_cred.so.1
other auth required pam_unix_auth.so.1
#
# Default definition for Account management
#
other account requisite pam_roles.so.1
other account sufficient pam_unix_account.so.1
other account required pam_ldap.so.1
#

With this configuration in place, Solaris will use Kerberos authentication and will retrieve account information via LDAP.

Reboot the Solaris Server

I know this sounds stupid, but even after restarting LDAP and enabling/starting/restarting the DNS client, things still didn’t work for me in the lab. However, after rebooting the Solaris server, it worked like a champ. So, just in case, reboot the Solaris server after completing the configuration.

Testing the Configuration

Once all of the configuration steps have been completed, you can test the configuration with the following commands:

• You can use “getent passwd <Name of AD user>” from the Solaris server; this command should return UID number, GID number, UNIX home directory, and login shell.
• You can use “kinit <Name of AD user>” to test Kerberos authentication. A succesful Kerberos test will not return any feedback, and the “klist” command will show a ticket granting ticket (TGT) from the Active Directory DC/KDC.

If either of these tests are unsuccessful, review the log files on the Solaris server and resolve the problems before continuing. Both of these tests will need to be successful in order for authentication to work correctly.

If the tests are successful, then you should now be able to join the Solaris server to Active Directory using Samba.

Joining the Solaris Server to Active Directory

This is the final step. Don’t try this step until you’ve successfully tested the configuration. After this step is completed, you are finished and AD users will be able to login to the Solaris server (assuming the AD users have been properly configured).

To join the Solaris server to Active Directory, follow these steps:

1. Verify the Samba configuration as outlined earlier. Key to the configuration are the “security = ads” and “use kerberos keytab = true” directives.
2. Use “kdestroy” to destroy any existing Kerberos credentials you may have; then run “kinit <Domain administrative account>@AD.DOMAIN.NAME” to get a Kerberos ticket for an account that is a domain administrator account.
3. Run “net ads join” to join the Solaris server to Active Directory. This command will automatically create a computer object in Active Directory and add the appropriate SPNs (service principal names) to the computer object. In addition, it will populate the local Kerberos key table (/etc/krb5.keytab, by default) with the correct entries for authentication against Active Directory. You may see an error about a missing userPrincipalName, but this does not appear to affect any functionality.

At this point, all properly configured AD users (those users who have UNIX attributes) should be able to login to the Solaris server using their Active Directory username and password. Of course, this assumes that you’ve already dealt with home directories (or are automounting home directories).

As with previous instructions, these instructions don’t address password management (the ability to change an AD password from Solaris) and don’t address how to handle home directories. Hey, I’ve got to leave a few challenges for others to tackle, right?

How I Tested

This testing was done using Solaris 10 11/06 (Update 3) running on VMware ESX Server 3.0.1. Active Directory was running on a pair of servers with Windows Server 2003 R2, also virtual machines on ESX Server. Authentication testing was performed using SSH from a client system running Mac OS X.

The idea of chrooting (or jailing) certain security-sensitive services is a well-known and pretty well-accepted method of protecting systems against further compromise in the event of a security breach.  BIND is commonly run in a chroot jail, as can be Apache HTTPD or an FTP server.  SSH is another common target for running in a chroot jail, and SSHjail is a patch designed to simplify the process of running OpenSSH in a chroot jail.  (UNIX die-hards, please forgive me and correct me if I am mistakenly interchanging “chroot” and “jail”.)

I was alerted to SSHjail via this article on Linux.com, and it certainly appears that SSHjail greatly simplifies the process of running OpenSSH in a chroot jail.  What interested me more than the configuration or use of SSHjail (which, as I mentions, looks pretty straightforward—kudos to the developer) was the question, “Could SSHjail be used in centralized authentication environments?”

Perhaps due to my work in Linux/UNIX-Active Directory integration, but the idea of using SSHjail initially seemed to be at odds with an environment where users are being authenticated via Kerberos/LDAP against Active Directory.  After all, the home directory would normally be specified on the user object’s properties in AD, so how would that interact with the home directory configuration specified in the /etc/sshjail.conf file?  Is SSHjail so transparent that it won’t matter?#160; For example, if I specify that “/home/slowe” is the UNIX home directory in AD, and SSHjail is configured to put me into a jail at “/chroot/ssh/”, do I need to then change the UNIX home directory in AD?  The article seems to imply that it does, as it mentions editing local users to specify a new home directory location.  How, then, do we handle disparate systems where SSH may be jailed on some and not on others?

<aside>Of course, this brings back up the question of how to handle different operating systems, such as Solaris and Linux, that (by default) place home directories in different locations on the file system or in different file systems.</aside>

Any feedback or clarification from Linux/UNIX experts out there is welcome.  It would be great to be able to include information on how to utilize SSHjail in conjunction with AD integration.

The last update to the Solaris 10-Active Directory integration instructions was in October of last year, over six months ago.  Since that time, Sun has released another update to Solaris (Solaris 10 11/06, or Update 3) and I have been able to gather some additional information on using an Active Directory-aware version of Samba to help with the process (much like described in the latest version of the Linux-AD instructions).

The new version will use Kerberos for authentication, LDAP for account information, and Samba to do the “heavy lifting” of joining Active Directory, creating the necessary objects, and creating the keytab and keytab entries on Solaris.

I hope to post the updated integration instructions within the next few days, before I have to leave for a business trip to Canada.

Using Samba in Linux-AD integration scenarios is tremendously helpful because it removes the need to manually create the SPNs and export the keytabs out of Active Directory.  I wrote up my first test of Samba in Linux-AD integration, then proceeded to verify that procedure and include it in the full Linux-AD integration instructions.  But would it work in Solaris-AD integration scenarios?

In theory, yes.  After all, Samba is included with Solaris 10, right?  Right!  Unfortunately, the version of Samba that’s included was not compiled with ADS support, and recompiling Samba to include ADS support means also recompiling a whole ton of other junk as well.  Fortunately, this thread titled “Samba on Solaris 10 in native ADS environment” gives complete instructions on how to compile Samba with ADS support on Solaris 10 so that one can use Samba for AD integration.

I plan to test this in my lab as soon as possible, and when I have some first results I’ll post more information here.

I’ve got a lot of respect for OpenBSD, whose maintainers’ relentless focus on security has really paid off.  Until today, the OpenBSD tagline was “only one remote hole in the default install in almost ten years.”  Now, due to the discovery of a new critical vulnerability, that tagline must change to its current form:  “Only two remote holes in the default install, in more than 10 years!”

Fortunately, this new vulnerability is fairly easy to mitigate and is fairly limited in scope to begin with.  This page (look for the security fix dated March 7, 2007) provides some workarounds and a link to the patch that fixes the problem.  If you’re already using OpenBSD’s pf firewalling functionality, then pf can easily be configured to block the traffic that triggers this vulnerability.

If you manage any OpenBSD-based systems, it would be prudent to configure pf and/or apply the patch to address this vulnerability.

This comparison of ZFS (Zettabyte File System) and WAFL (Write Anywhere File Layout) by Network Appliance (no direct link for WAFL) is an interesting comparison of these two advanced filesystems and their feature set.  Be sure to read the comments for some additional insight on the comparison of the two filesystems and some clarification about supported features.

One distinction raised in the comments that’s worthy to be noted here is that any comparison of this sort also, by its very nature, takes into account the operating system that runs the filesystem.  As a result, any comparison of ZFS vs. WAFL also involves, to a lesser extent, Solaris and Data ONTAP, respectively.  Similarly (and I think this may have been pointed out in the comments as well), the underlying hardware used by these filesystems (and their operating systems) also comes into play as well.

For these reasons, it’s impossible—in my mind, at least—to perform any sort of apples-to-apples comparison of these two technologies.  It’s still an interesting article, though.

Changing the IP address of a system running Solaris (Solaris 10, specifically) is different than a lot of other operating systems out there.  Really, all you have to do is just edit a few files and then take the interface down and back up again.  However, there seems to be a “gotcha” with Solaris 10.  (I don’t know how far back this procedure goes—it is unclear to me if this is new to Solaris 10, or if it extends back to Solaris 8 or 9.)

Most of the sites out there I found indicated that you only needed to edit the /etc/hosts file (which is actually just a symlink to /etc/inet/hosts) and place the new IP address of the server in that file.  Since I wasn’t changing the hostname or default gateway, there was no need to edit /etc/hostname.pcn0 (the hostname file for the only interface in the system), /etc/nodename, or /etc/defaultrouter.  So I edited the /etc/inet/hosts file, rebooted the server, and expected to see the new IP address show up on the network.

It didn’t work.  A bit more research indicates that in Solaris 10, the operating system uses /etc/inet/ipnodes over /etc/inet/hosts.  This is a bit odd since ipnodes is only supposed to be used for IPv6, and I know that I specifically disabled IPv6 in this installation.  Some additional targeted searches I performed, however, showed that this was indeed the case even if IPv6 is disabled.

Upon editing /etc/inet/ipnodes and rebooting the server, the IP address change took effect.

So, if you need to change the IP address of a server running Solaris 10, change the following files:

/etc/inet/hosts
/etc/inet/ipnodes

Upon a reboot, the server will now have the new IP address.

(By the way, Solaris 10 U3 runs perfectly under ESX Server.)

Given that I’m neither a Solaris expert (yet) nor an iSCSI expert (yet), I knew that it would be a bit of a challenge to make this work.  Fortunately, a found a very useful blog posting by Frank Berger that gave me the framework I needed to get started.  From there, Sun’s documentation provided the rest of the necessary details.  Perhaps this documentation will prove moderately useful as well.

First, I added the following lines to the /etc/ietd.conf on the CentOS iSCSI target server:

Target iqn.2006-08.net.example:server.lun1
        IncomingUser username complicatedpassword
        Lun 1 Path=/dev/vg00/isanvol1,Type=fileio
        Alias iet-lun1
        MaxConnections          8
        InitialR2T              No
        ImmediateData           Yes

A quick restart of the iSCSI target service and I was all set on the target side.  If you were going to do this yourself in your own environment, you’d need to modify the “IncomingUser” and “Lun X Path”.  In this instance I’m using LVM on CentOS, so my path specifies a logical volume in a volume group.  Your configuration will differ, obviously.  Alternately, if you are using a different iSCSI target implementation, you’d need to configure it appropriately.  (I hope to be able to do some testing against a NetApp iSCSI target in the near future.)

On the initiator side, everything is done with the “iscsiadm” command.  This command is fairly self-explanatory and has built-in help (-?) throughout most of the options, but it did take me a little bit of time to get things working.

First, we have to make sure that the iSCSI initiator is online:

svcs -a | grep iscsi

If disabled, then we can enable it with this command:

svcadm enable svc:/network/iscsi_initiator

From there, we configure the iSCSI initiator:

iscsiadm add discovery-address 10.1.1.1:3260
iscsiadm modify initiator-node -a CHAP
iscsiadm modify initiator-node -H username
iscsiadm modify initiator-node -C
(specify CHAP password)
iscsiadm modify discovery --sendtargets enable

Because I’d also specified a static config as well (dynamic discovery didn’t seem to be working as I expected; more on that in a moment), using “iscsiadm list target” now returned two iSCSI targets.  They appeared to be different targets, and since I do have two targets defined on the iSCSI server (one for VMware and one for this), I didn’t want to take any chances on affecting the VMware LUN.  So, I removed and disabled the dynamic discovery, removed the static config, and then re-added the static config:

iscsiadm add static-config iqn.2006-08.net.example:server.lun1,
10.1.1.1:3260

(This should all be on one line; it was wrapped here for readability.)  After doing that, “iscsiadm list target” showed only a single target identified as “server.lun1”, which assured me that I wasn’t seeing the VMware LUN.

<aside>In a more complex environment, how does one ensure that iSCSI LUNs are properly isolated from unwanted hosts?  The “IncomingUser” parameter was different between my VMware LUN and the raw LUN being presented to Solaris, so in theory I would have been safe.  Better safe than sorry, in my opinion.</aside>

After I was sure that the iSCSI initiator was properly seeing the LUN, then I created a new device, created a new filesystem on that device, and then mounted it:

devfsadm -c iscsi
format (selected new disk identified as iSCSI)
newfs /dev/dsk/c2t1d0s2
mount /dev/dsk/c2t1d0s2 /export/iscsi

Of course, you’ll need to modify the above commands slightly depending upon your configuration, but the overall process should be pretty close to what I’ve outlined above.

A number of the readers of my article describing integration between Linux and Active Directory on Windows Server 2003 R2 have inquired about the need to install Server for NIS on a domain controller.  Even though we don’t necessarily need NIS for this process (although we will need NIS if we are going to use NFS and automounts), installing the Server for NIS also makes available the “UNIX Attributes” tab in the Active Directory Users and Computers console.  You’ll need some sort of access to the attributes in Active Directory (unixHomeDirectory, gidNumber, uid, uidNumber, gecos, loginShell) in order to set them so that Linux and UNIX systems can utilize the information in those attributes, so installing Server for NIS in order to get the “UNIX Attributes” tab makes sense.

It’s not the “UNIX Attributes” tab that’s important; it’s access to those attributes in Active Directory.  You could just as well use ADSI Edit, LDP, or programmatically edit the attributes via VBScript or an LDIF import file.  It doesn’t matter.  All that matters is that you have the ability to set and modify the values in the UNIX-related attributes.

One common workaround that has been mentioned is just registering the nisprop.dll file, using a command like this:

regsvr32 c:\windows\idmu\common\nisprop.dll

Normally, this trick would work well.  I used this trick, for example, to make Active Directory Users and Computers available to help desk personnel without having to install all the administrative tools (just copy down dsadmin.dll and register it).  Not this time, though.

As Andy Loggia pointed out to me (first in the comments, and again later in a separate e-mail message), registering nisprop.dll requires Schema Admin privileges.  At first, I didn’t believe him, but he’s absolutely right.  When you register nisprop.dll, a change needs to be made in the Configuration naming context of Active Directory—and making that change requires Schema Admin privileges.

Specifically, registering nisprop.dll adds the CLSID of nisprop.dll to the AdminPropertyPages attribute of the user-display and group-display objects in this location in Active Directory:

CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=example,DC=net

(The “CN=409” would change if you are running a language other than English.)  I verified this myself on my own instance of Active Directory in the lab and Andy is absolutely correct.  Good work, Andy!

If you are working on Linux-AD integration in your shop, then just keep in mind that at some point during the process you’ll probably need to have Schema Admin privileges.  Certainly while you are extending the schema (if it’s not already extended, which you can check using ADSI Edit), then when you install Server for NIS or register nisprop.dll.  Alternately, if you don’t want the “UNIX Attributes” tab in Active Directory Users and Computers, you can use tools such as LDP, ADSI Edit, LDIF import files, or scripts to populate and edit the values in the UNIX-related attributes.  Populating these values is necessary for the process to work correctly, but the method by which the attributes are populated is up to you.