Baking up some departmentalized security on user profile attributes.

One item I failed to mention in my profile is that I LOVE to cook, which isn't a bad thing but at the same time I love to bake!  I am always bringing in goodies to the office to share, and it is funny because it is at random times I get into a baking mood and tonight is no different, although tonight's baking will be a different sort of baking all together.  Below I am providing a Bamboo family secret recipe (OK, OK not really a "secret" recipe) about departmentalized security on user profile attributes.

In this recipe I will be providing you with a step-by-step guide how to allow each of your major departments within your company (for example, Telecommunications, Human Resources, and individuals) the ability to view/modify particular attributes of a given user profile.  When the baking is completed, using Bamboo User Directory Web Part, Active Directory Services and potentially SharePoint 2007 profiles will be synchronized with the latest information while still providing a secure Active Directory and minimal resource costs.

Now that I've got your attention, let's rollup those sleeves and dive right in!

With any great "secret" recipe, you need your ingredients.

Ingredients:
Active Directory Services (ADS)
Bamboo User Directory Web Part
Microsoft Office SharePoint Server (MOSS) 2007 or Windows SharePoint Services (WSS) v3.0

Optional Spices (If WSS v3.0 is used)
User Profile Sync

Preparation: (Takes about 30 minutes per department to complete)
Before you can actually start cooking, there is prep work that needs to be done to lay the foundation.  First, you will need to create any custom attributes in ADS that will store other details not pre-set by ADS's initial deployment.

Next is to prep your baking dishes.  Since each department will be managing and viewing a different set of attributes, we will use a different baking dish, or in this kitchen, SharePoint Site for department to keep the contents separate.  You can use existing SharePoint Sites if each department already has one, but note that each department site will need to have unique permissions so only those department members can see the Web Part Page where User Directory Web Part will reside.

Now that the baking dishes are prepped, add a layer of Bamboo User Directory Web Part to each of the baking dishes / SharePoint sites.  In the Web Part properties tool pane, configure the User Directory Web Part to connect to Active Directory.  Enter an ADS user who has enough rights to read and write to user objects in ADS and a SharePoint account that has rights to read users in SharePoint group.

Select SharePoint site group within the department that will be allowed to modify changes in the User Directory Web Part, everyone else on the site will be able to just view the details.  If you prefer to narrow the scope of your ADS, you can specify a specific Organizational Unit in the properties tool pane also.  Save the tool pane when you are finished the configuration.

Now go to View All Site Content.  You will notice a new list is created called ActiveDirectoryConfig.  This list is the atoms that make up the attributes in the User Directory Web Part.  The molecules / columns of the list serve different roles as defined below

Property Name. The LDAP Display Name from ADS.
Display Name. The name of the field as it is displayed in User Directory Web Part.
Tab Name. The section name where this attribute will be grouped in the tab section of the User Directory Web Part.
Public. Set this property to "Yes" to allow all users to view, otherwise only the owner and administrators can view this attribute.
Editable. Set this property to "Yes" to allow designated users to modify this attribute, otherwise this information will only be viewable based on Public setting.
Sort Order. Leaving this field blank will sort all of these attributes in alphabetical order on their respective tabs. Otherwise, you can enter a number to order the attributes on each of the tabs.

User Directory Web Part by default adds most common attributes to this list however base on which department you are in, you may want to see certain fields while others are not of interest.  Configure this list to meet the needs of the department.  For example, your Human Resources department will need writer's access to paid leave availability, insurance records, and salary but only view access office address, phone number and e-mail.  While the telecommunications department would have write access to office address and office phone number but does not view paid leave, insurance records or salary. After configuring the ActiveDirectoryConfig list, set permissions to the list as Read-only for all users except individuals who should have the right to modify attributes available to the department (preferably the domain administrators).

Repeat the above steps for each individual department.  You then can configure a public address and phone book for the company by configuring the Web Part on a intranet site.  Here you can set up the AcitveDirectoryConfig list with public facing attributes, for example, office location, phone number, e-mail, fax and so on, and allow users the ability to modify their own accounts for example maintaining Home Address and Home Phone.

Baking
While baking, each department can use User Directory Web Part on their site to update necessary attributes for specific users. 

You will notice on the left side of the User Directory Web Part, members of the department can drill down to the specific user they are looking for by either Alphabetically or by Organization (who reports to who). 

You can also search for users by entering First or Last Name.

When the team member locates the user they want to update they click on the name to view the details.  Information is broken down by individual tabs. 

When the user clicks on Edit, only specific fields will be available for modification while others will be omitted from the edit mode view. 

  
*Notice - Image on the left is while the Web Part is in View mode.  When the user clicked on Edit, the attributes Account Name, Full Name, and Email are hidden from the user.  This occurs when Editable is set to No in the ActiveDirectoryConfig list.

This is defined in the Preparation phase prior to Baking. Upon saving, changes will be sent to ADS to be updated.  The Baking process is continual revolving door and has no limit to departments or users in ADS.

If you are using MOSS 2007, you can add an optional additional step to the baking process on a daily routine.  Using MOSS 2007 out-of-box functionality, you can "push" user details to the MOSS 2007 Profile Database in MOSS 2007 Shared Services Provider.  You can then display these details to the public or only allow the individual and their Manager to view the details.

Optional Spices
If you selected to use WSS v3.0 to save few bucks but want the same fashionable results as MOSS 2007, no worries, Bamboo's here to the rescue!  Pick yourself up from the Bamboo Storefront User Profile Sync application.  With the versatile power of User Profile Sync, you can push particular user details from ADS to your top-level site collection in WSS v3.0 as often as you liked.  Just use the cook's trusty Microsoft Windows timer called Windows Scheduler, and schedule for the push from ADS to WSS v3.0 to happen as often as you see fit.

Now sometimes depending on depth of your WSS v3.0 deployment you baking in, it can be deceiving and only the outside might be getting cooked and not the center.  That is why it is good to fold your spices into your sub sub-site collections.  Another option available from User Profile Sync is the ability to push changes from the top level site collection to all children site collections in one shot, again using the trusty Windows Scheduler to time out the times User Profile Sync Application should fold the changes in.

Walla! You have now successfully baked departmentalized user profile attributes. 

Bon Appétit!