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 ratherthan just a daemon) Apple has then left room for third party developersto provide solutions that supplement the tools that Apple has includedin the operating system. Thus, companies like Thursby, Quest, Likewiseand Centrify have all provided ways of extending the usefulness ofthird party directory services.Third party plug-ins are typicallyinstalled in the /Library/DirectoryServices/PlugIns directory of acomputer, which is where you will find plug-ins for Quest and productsfrom Thursby. Again, by virtue of a .dsplug being stored in thislocation the DirectoryServices daemon will load the plug-in. Likewisechooses to store their .dsplug in the same place that Apple storestheirs, which is likely just accidental (although confusing when you'reresearching how their plug-in works) – but the plug-in works just finein either location.
You won't typically run plug-ins you do notneed. Some, such as the Local plug-in cannot be disabled (then youcouldn't have local accounts to run services after all). Plug-ins canbe enabled or disabled in the Directory Utility, clicking on theServices icon in the toolbar. When you do so you're editing the/Library/Preferences/DirectoryService/DirectoryService.plist, eithertoggling strings to Inactive or Active (which seems like it should beboolean btw, but that is another story). When a plug-in has been set toinactive the Daemon will skip loading it. But it is still stored in thesame place. Because a plug-in's active vs. inactive nature is stored inthis property list we can then programatically enable or disable itusing the defaults command. For example, to enable the Active Directoryplug-in you would use the following command:
defaults write /Library/Preferences/DirectoryService/DirectoryService "Active Directory” "Active"
Oncethe plug-ins are enabled or disabled we can then use them forauthentication or for looking up Contacts assuming that custom searchpaths that include the directory service have been enabled and that wehave properly bound to each, most if not all of which is defined verygranularly elsewhere. But suffice it to say that the plug-inarchitecture of Directory Services is well thought out and well laidout.
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.