1

In my portal I have a list where we keep track of officials that belong to a particular location. If someone adds or subtracts a person from that list, then I have to manually adjust the Active Directory membership for the corresponding group.

Is there a way I can have the membership adjusted automatically when that Sharepoint List is modified?

How would you do it? Can it be done via a workflow? Do I need to make a custom webpart and connect the list to it or can I connect a workflow to it?

I don't want to buy any premade kit for this job. I want to either use a free module or make my own.

I am running Sharepoint Server 2010 Enterprise on my own machine and have full rights everywhere.

  • Quick idea - could an event handler on the list be enough for you task? Just intercept the update, add, delete etc events and write custom code to interface to AD and perform the required activities. I don't believe there are OOB components to do that. – Hitodama Jul 31 '13 at 8:47
  • I'm open to that; till now, I've done custom masterpages, jquery fixes, and html inserts with good success. I need to move forward into the more advanced areas of webparts and services but am procrastinating. Maybe you could post me an answer with a basic approach with the event handler? I've got Sharepoint Server on a VM along with VS. – bgmCoder Jul 31 '13 at 15:32
  • umm. First things first - are you trying to perform a bidirectional sync? If something changes inside Active Directory, how will your list react? If I understood correctly, you want to make it so that when you add an user to the list, the same user is added to an Active Directory group, right? Is there any reason for having the users in the list in first place? Do you plan to use them somewhere? – Hitodama Aug 2 '13 at 7:37
  • Yes, I would prefer it bidirectional, but would settle (for now) with just list-to-AD. The list will only be able to recieve certain fields like the username field (that's the only one that would be updated). The list is a list of locations across the country that we serve, and the usernames in three different columns are the way to denote the officials attached to the location. If we need details about the officials, I am using a webpart that will display their profile info. – bgmCoder Aug 2 '13 at 14:53
1

Let's start from the requirement. If I interpreted your needs correctly, you want to manage membership for an AD group through a SharePoint page. There are multiple way to obtain this, I will try to list what comes to mind.

Option #1: event handlers on the list
Implement some update/insert/delete events handlers for the list. The handler will then contain the code to sync the new data with the AD group.
Pro: probably one of the simplest solution to implement, almost all complessity is in accessing AD. Cons: unidirectional by design. You just act on some event that occurs on the list - there is no way to manage the opposite.

Option #2: timer job
Implement a SharePoint timer job that performs the required sync operations between the list and AD.
Pro: the sync operation can be made bidirectional.
Cons: Since you act in reaction to a state instead that to an event, it can become hard to decide the direction of an update: if the grup on AD contains an user that the list doesn't, it means that the user has been added via AD or deleted via list? Also notice that you might need to use the secure store to save some sort of credential for accessing to AD (you are in a timer job, which is run by the appropriate SharePoint process which may not have enough permission)

Option #3: external list
You could use an external list to map to the users in your group. That way, the two models - List on SharePoint and Group on AD - would be synched by design.
Pro: by design sync.
Cons: working with the Business Data Catalog is never fun. Could be manageable if you stick to c# based external list and SharePoint 2010.

Option 4#: drop the list, use a custom web part instead If you don't really need the list, you could just drop it and develop a custom web part that manages add/remove of users to the AD group. This way the WP will be always in sync with the group.
Pro: again, sync is by design
Cons: you can do this only if you can drop the use of the list.

Those are some basic idea. Notice that you will still have to write the code that interacts with AD.

Could some of this options be applied to your situation? If you can provide some further input, I could offer some more insight on a specific solution or other unclear aspects.


EDIT: as requested, here are some more detail about the first option/solution.

As we said before, the idea is to use an event handler attached to your list to perform an unidirectional sync from the list to the AD group. I will give you a quick overview of the general implementation process: keep in mind that some of the steps I will describe may be automated by using Visual Studio/CKSDev projects/items templates.

Start by creating a class that inherits from SPItemEventReceiver. This is the base class to use when you want to create handlers that respond to item-level events on a list. In your case, we will override the default "empty" handlers for the item added, updated and deleted events.

After you complete coding the above methods, you will need do attach the handler to a list. As you may see from MS documentation, there are many way to do this:

  1. attach the receiver to a content type
  2. attach the receiver to a list template
  3. attach the receiver to a specific list.

All the above can be achieved both programmatically that declaratively via CAML. Anyway, in your case I would opt for the declarative approach: Visual Studio will create the default structure for you when you create a new project of type "event handler".

Having the event handler infrastructure attached to your list, you will be left with coding the actual methods for adding/removing the users from the AD group. This is out of the scope of this question, but you can easily find some sample around. This question comes to mind.

Last words: in my ranting above I have referenced events for handling item added/updated/deleted. As you will see there actually are TWO events for each group, one triggered before the action and one after: so for example you have item ADDING and item ADDED. By using this at your advantage you can cancel update events or detect update to an item.

  • Wonderful! For now, #1 seems to be the fastest and easiest. #2 seems nice, but then we'd have to scrounge for the "last modified" dates in both the AD object and in the list - and that date might not reflect the date of the field's change anyway == too insecure. #3- sounds really hard. #4 - probably the correct way (I don't mind dropping the list, and then I could code whatever I wanted there) - problem is I've only ever made one webpart, and that was just a demo. I think I'd like to do #1, and then #2 in some time. – bgmCoder Aug 2 '13 at 15:37
  • I'm going to mark this answer, since it's exactly what I was looking for, but if you elaborate for me on where to begin with #1, I'd be really happy. – bgmCoder Aug 2 '13 at 15:38
  • Sorry for keeping you waiting. I will elaborate on the first solution, just give me the time to gather my though. – Hitodama Aug 5 '13 at 7:34
  • 1
    @BGM - first part of the edit. I will try to update later. In the meantime, leave a notice if you need something particular. Just avoid question that are AD specific - you may use the main stack site for this. – Hitodama Aug 5 '13 at 15:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.