Share via

Can I use System directory service assembly in SharePoint ?

  • Article

Background

Exactly 5 years ago,I scribbled on my personal blog on the topic "How to synchronize the Active Directory with SharePoint List"
Yes scribbled, its a relevant word.

I just used the "Active Directory Services" namespace as I came from ASP.NET experience background.

I really do not know the gravity of the impact using the "COM based assemblies" in the SharePoint then and also toddler in the SharePoint.

Nowadays I have seen so many hits on the post, I realized I should ask the apology to  whoever land on my post through search engine,and now try to explain the mature way of dealing with Active Directory in SharePoint. 
External link : [http://intelliview.blogspot.in/2010/12/sharepoint-active-directory-synchronize.html]

Managed Code Vs Unmanaged Code

Just recap,before going to speak about System.Directory Service" assembly in the SharePoint, we must recollect the what is managed code,unmanaged code and interop.

Code that target and executed by the Common Language Run time and .NET Framework known as managed code.

When you working on the Managed code, the activities like memory management, cross-language integration, code access security and garbage collection governed and managed by .NET Framework.

Absolutely the Code Access Security is very crucial feature for SharePoint for identifying the Solution types (Farm, Sandbox).

Unmanaged code: Machine specific and machine level code which in compiled and linked and directly run on the processor. So it has ability to damage the process,unexpected exception and can leads to memory leakage.

Now coming to the topic, an assembly “System.DirectoryServices, System.DirectoryServices. AccountManagement and System.DirectoryServices. Protocol” has been designed and worked as unmanaged code or COM based assemblies or specific to network programming.

Anything that goes beyond the SharePoint limitation need to be  cautious and administrator's job to scrutiny the code that uses the COM based.

These assemblies could be useful for windows application (Single Instanced) but not fully suitable even for ASP.NET application. Even though an interop (Calling the unmanaged code from the managed code) approach is possible still you may receive the “COMException” and limited response to web page request and subsequently stop to respond.

 

Often you have to log into the server and restart all the locked process through “Task Manager”.

 It always requires to execute the highly privileged account (NETWORK SERVICE and System in Process)

 

When you decided to using directory services in SharePoint application then due caution must be given especially on Virtual memory allocation and deallocation and proper garbage collection else it will leads to hog down your costly server.

 “RunwithElevated Privilege “in SharePoint context will not works on the directory services assemblies.

Can I use this assembly in my custom application to retrieve query and CRUD operation against the Active Directory in the SharePoint ecosystem?

My stand is bold, big and strongly "NO".

Here is my outcome of the test:

I have created the simple SharePoint application page and the logic to retrieve the all user object and showing it on the screen on click of the button.

It’s so simple right uh?

I wanted to track and trace how the method has been called on click of the button, so I have activated the SharePoint Dashboard on my site.

And gone through each line of ULS log details, to find the how the AD querying logic being called on the SharePoint environment.

I stumbled and see no traces regard of this in ULS log. But I am still able to see the all the user name printed on my screen.

Again I am not settled with this result, this time I created the simple method to retrieve the specific item from the SharePoint list and showing it on the screen.

Now I am able to see the sequence of log in the ULS entries.

So why it’s not happening to the method that querying the Active Directory.

For shake of the simple understanding is, the unmanaged code block inside the assembly reaching to cross the SharePoint security perimeter.

SharePoint application process will waiting for “unmanaged code transition to manage code” and app domain has to receive all pending activities by the system directory assembly has to be completed.

If you miss any of the best code practices while handling unmanaged code in the SharePoint, there won’t be any synchronization between the SharePoint and app domain.

This overhead performance on your SharePoint server prone to damage the server and poor performance.

Why can’t we use the System directory in the SharePoint?

Often you required to pass the domain controller’s credential along with LDAP query.

SharePoint is the collaborative environment that has built based on strict (SOA) layers that adhere the protocol before communicating the outside of the SharePoint either BCS, Excel communication Services or User Profile services.

To bring any data outside of the SharePoint ecosystem, always you have to use the Services or Web Service.

Example : User Profile Service that will retrieve the data from tightly secured AD and feed to SharePoint and another example the architecture of AD FS implementation.

Even you can go ahead with attribute mapping that matches with your AD, and also if you required any custom attribute for your organizational or your application requires in User Profile Services.

Alternate approaches

Alternate approaches over using the System Directory assemblies in SharePoint application. 

  • You can also build your own AD like User Profile database with all attributes that your organization required and shared among all application using BCS and User Profile Service. 
  • Leveraging the built-in Active Directory Web Service (TCP /IP based - Machine to Machine). Its web service interface to deal with AD Domain Services and Active Directory Lightweight Services.
  • Check this URL on your domain controller net.tcp://localhost:9389/ActiveDirectoryWebServices/mex based on this URL you need to create the wrapper webservice.to be called over HTTP.
    Because TCP/IP based services intended to communicate between machine levels.

Final note

After all " Be a Roman in Rome", Always stick to use the out of the box or the features available within the SharePoint. Choosing the system directory services assemblies in the SharePoint or the 3rd approaches suggested in this article are not a wise decision.