In a number of contexts, we hear about directory services plug-ins. A directory services plug-in is a way for a Mac OS X computer to leverage the DirectoryServices daemon to obtain account information (be it authentication or policy information) from a server. This might be an Active Directory server that uses the Active Directory Plug-in or an Open Directory server that uses LDAP.
You disable plug-ins that you don’t need and enable plug-ins (ie Active Directory plug-in or third party plug-ins) that you need in order to access directory services of various types. These plug-ins are developed in the form of .dsplug files. The default plug-ins that Apple includes with Mac OS X are located in the /System/Library/Frameworks/DirectoryService.framework/Versions/A/Resources/Plugins folder in Mac OS X. Any .dsplug file stored in this directory will be loaded as a plug-in, assuming it matches the parameters laid out in the DirectoryServices API.
By opening up the plug-in architecture (thus a plug-in rather than just a daemon) Apple has then left room for third party developers to provide solutions that supplement the tools that Apple has included in the operating system. Thus, companies like Thursby, Quest, Likewise and Centrify have all provided ways of extending the usefulness of third party directory services.Third party plug-ins are typically installed in the /Library/DirectoryServices/PlugIns directory of a computer, which is where you will find plug-ins for Quest and products from Thursby. Again, by virtue of a .dsplug being stored in this location the DirectoryServices daemon will load the plug-in. Likewise chooses to store their .dsplug in the same place that Apple stores theirs, which is likely just accidental (although confusing when you’re researching how their plug-in works) – but the plug-in works just fine in either location.
You won’t typically run plug-ins you do not need. Some, such as the Local plug-in cannot be disabled (then you couldn’t have local accounts to run services after all). Plug-ins can be enabled or disabled in the Directory Utility, clicking on the Services icon in the toolbar. When you do so you’re editing the /Library/Preferences/DirectoryService/DirectoryService.plist, either toggling strings to Inactive or Active (which seems like it should be boolean btw, but that is another story). When a plug-in has been set to inactive the Daemon will skip loading it. But it is still stored in the same place. Because a plug-in’s active vs. inactive nature is stored in this property list we can then programatically enable or disable it using the defaults command. For example, to enable the Active Directory plug-in you would use the following command:
defaults write /Library/Preferences/DirectoryService/DirectoryService “Active Directory” “Active”
Once the plug-ins are enabled or disabled we can then use them for authentication or for looking up Contacts assuming that custom search paths that include the directory service have been enabled and that we have properly bound to each, most if not all of which is defined very granularly elsewhere. But suffice it to say that the plug-in architecture of Directory Services is well thought out and well laid out.
If you are interested in developing against the Directory Services API see the developer documentation here or you can access 10.5 specific information here.