Tag Archive for Active Directory

The Business Value of Microsoft Azure – Part 2 – Active Directory

This article is part 2 of a series of articles that will focus on the Business Value of Microsoft Azure. Microsoft Azure provides a variety of cloud based technologies that can enable organizations in a variety of ways. Rather than focusing on the technical aspects of Microsoft Azure (there’s plenty of that content out there) this series will focus on business situations and how Microsoft Azure services can benefit.

There are many risks that businesses and governmental entities face when it comes to data loss. Most have taken steps to do things like encrypt hard drives, enforce password change policies and limit the use of consumer oriented applications like Facebook. However, one the biggest gaps that exist has emerged as a result of the prevalence of Software as a Service (SaaS) solutions. These cloud based systems require little to no IT involvement to get up and running. A consequence of this ease of deployment is that countless new opportunities for compromise emerge.

Let’s take something like a file sharing service. Whether it’s Dropbox, box, or some other solution, an individual in an organization can quickly set it up with a username and password and begin sharing files inside or outside the organization. In most cases this isn’t carried out by a nefarious user with malicious intent. Rather, it’s set up to address a specific business need. Perhaps it’s a new product catalog and price list that’s too large to send to distributors via email. While this sounds good on the surface, let’s fast forward six months…

Six months after the service has been in use there are now a couple dozen fellow employees using the service, all with an individual username and password. The CIO finally becomes aware of this because he gets a link shared with him from one of his employees that takes him to a file in a box account. He immediately spots a problem – what happens if one of these employees leave?

  1. We don’t know that they are using the service
  2. We can’t terminate their access
  3. We have no ability to enforce any password complexity or change frequency requirements

Now, there are a variety of solutions to this problem. First, the CIO could disable access to box and prevent users from using the service. OneDrive for Business, part of Office 365 could be implemented as a secure, enterprise alternative. However, what if the CIO didn’t want to take away this service, but have more control over it. Is there a solution?

Enter Microsoft Azure Active Directory. Microsoft Azure Active Directory provides a variety of services to the enterprise that can help our CIO. First and foremost is the Access Panel portal for Single Sign On (SSO) based access to SaaS applications. This allows the CIO to configure access to box so that the user actually uses their standard Active Directory credential to authenticate against box. This also means that when that employee leaves or is terminated and their Active Directory account is disabled…so too is their access to box!

In addition to the Access Panel, another key feature is something called Azure Active Directory Cloud App Discovery. This service allows a small agent to be deployed to an end user workstation which allows for access to various cloud services to be monitored. This is a huge benefit to IT organizations because they:

  • Get a summary view of the total number of cloud applications in use and the number of users using cloud applications
  • See the top cloud applications in use within the organization
  • See top applications per category
  • See usage graphs for applications that can be pivoted on users, requests or volume of data exchanged with the application
  • Can drill down into specific applications for targeted information
  • Can view which users are accessing which apps
  • Can easily proceed to integrate an application with Azure Active Directory

There are many other reasons for organizations to look at Azure Active Directory, but this is the first one that pops into mind whenever I think about security risks and simple ways to reduce exposure while still providing end-users with access to the productivity applications they desire.

As a partner with BlumShapiro Consulting, Michael Pelletier leads our Technology Consulting Practice. He consults with a range of businesses and industries on issues related to technology strategy and direction, enterprise and solution architecture, service oriented architecture and solution delivery.

Refining Unstructured Search Results in SharePoint 2013

SharePoint search is awesome. It gives you the ability to search content inside of SharePoint, as well as outside of it. Plus, it gives you the ability to search for other employees in your organization. And quite easily!

Though, what it also gives you is a window into your organization’s disorganization. How many times have you taken a look into Active Directory only to find that users have job titles like “Mgr”, “Manager”, “Senior Manager”, etc.? One person’s naming convention is rarely ever exactly like someone else’s.

Now what happens if users actually want to refine these results. Say they want to pull back a list of all managers. They’d need to create a query similar to this:

Not very intuitive, is it?

Another option is to go back to your IT department and ask them to standardize this naming convention. Which wouldn’t be that difficult of a task for them, except they are already over worked and don’t really have time for another non-mission critical task.

So what does that leave? How about trying out a custom entity extractor? What is that you say? A custom entity extractor is a keyword mapping for a managed property, allowing you to customize the search refiner. In laymen’s terms, it’s a way for us to map our unstructured data (Mgr, Manager, Senior Manager) into a single term (Manager). Which allows you to add it as a search refiner so you can easily filter on just the “Managers”.

Our Example

For our tutorial, I’m going to use baseball as an example. Our people search returns the following players.

Each player has a unique job title, “Designated Hitter”, “Right Field”, and “Second Base”. We want to search for these players by “Infield” or “Outfield”. This would be akin to having “Mgr” / “Manager” / “Senior Manager” as job titles and wanting to filter by just “Manager” or “Partner”.

Create the Custom Extraction Dictionary

First we need to create our Custom Extraction Dictionary. This a comma separated (CSV) file which will define our mappings. I’m going to name this PositionsDictionary.csv and have all the infield positions map to “Infield” and all the outfield positions map to “Outfield”.

 

Import the Dictionary

Next we will need import the dictionary into our search application. Here is where we need to decided what type of extract it is. Should “First Base” match exactly to our values in AD, or should it just match part of it, and is it case sensitive? You can view the different types over on TechNet. For this example we will be using the Word Extraction type which is case-insensitive and matches the full word exactly. Run the following PowerShell cmdlet as an administrator on your SharePoint box:

$searchApp = Get-SPEnterpriseSearchServiceApplication
Import-SPEnterpriseSearchCustomExtractionDictionary -SearchApplication $searchApp
-FileName \\UNC-PATH\PositionsDictionary.csv
-DictionaryName Microsoft.UserDictionaries.EntityExtraction.Custom.Word.1

 

The FileName argument needs to be a UNC path. The DictionaryName argument needs to be exactly whats defined on TechNet (if you follow the link above). And if done correctly you will see a “Dictionary imported successfully”.

 

Map the Property

We now have to link our dictionary / mappings to the Job Title managed property. To do this, head over to the Search Service Application in Central Administration. Click on “Search Schema” link in the left navigation, which is found under “Queries and Results”, and search for the managed property “JobTitle”, and click on it to edit it. Then scroll down to the “Custom Entity Extraction” section.

This is where we need to link our managed property to the dictionary. Since we used the first Word Extraction dictionary, we need to check it off. If you used a different one, you will need to choose that one instead. Click “Ok”, and run a full crawl.

Add the refiner

Since we cannot change the default People Search page, I’ve created an exact replica of the People Search page in my Search Center, and changed the “People” link to that new page. The only difference, is that in my refinement webpart, I used “WordCustomRefiner1″ instead of “JobTitle”, which I also gave it Display Name of “Job Title” just like the actual JobTitle managed property.

Click “Ok” and Save / Check In / Publish the People Search page.

 

Results

Now to test it out. If we do our search again, you can see that we just have two different job titles, “Infield” and “Outfield”. Which we can refine our results based on that.

And just like that, we’ve managed to filter our employees exactly as we desired without updating Active Directory or bothering IT.

Adding Pictures to Active Directory and Show in SharePoint 2013

Adding Pictures to Active Directory and Show in SharePoint 2013

A very common setup request for SharePoint is for it to pull pictures of employees directly from Active Directory. This allows all employee photos to be managed in a central location, and give some governance to how the photos should look.

This post will take you through adding images into Active Directory and having SharePoint display it.

 

Adding Photos into Active Directory

Adding Photos into Active Directory is not as simple as opening up Active Directory Users and Computers, choosing the employee and uploading a photo. Active Directory stores photos as a bytes, so when adding images to Active Directory, you have to pass it in as bytes. Not a big challenge using PowerShell.

The following command will upload the Harvey_Brent.jpg photo into active directory for the user bharvey. I’ve ran this on the AD server.

$userName = “bharvey”
$filePath = “c:\temp\Harvey_Brent.jpg”
[byte[]]$img = Get-Content $filePath –encoding byte
Get-ADUser –filter {samaccountname –eq $userName} |
Set-ADUser –replace @{thumbnailphoto=$img}

Now, if you look into the bharvey AD user, you can see the thumbailphoto attribute is set with a list of hex values which make up the photo’s bytes.

 

Setting up Photos in SharePoint 2013

To set up SharePoint to use these photos, our first step will be to map the SharePoint “Picture” column to the Active Directory “thumbnailPhoto” column. We can do this from within the User Profile Service Application. While in the “Manage Profile Service” page, within Central Administration, click on the “Manage User Properties” link.

 

On the “Manage User Properties” page, find the “Picture” property and go into the Picture property’s edit page. This is where you will configure the mapping, as well as set other settings, e.g. if users should be able to change the image themselves. For the mapping, select thumbnailPhoto, and Import, and click the “Add”.

Publishing Photos to SharePoint 2013

Now that we have the photos in Active Directory and the mapping configured. All we need to do is run an incremental Profile Synchronization from the same “Manage Profile Service” page to get the photo(s) we’ve added into Active Directory. Then, we will just need to run another PowerShell command to make sure that the SharePoint profile photo store is compatible with SharePoint Server 2013. (This will need to be run by a user with AD edit rights).

We also specify the MySites Host site, where the images will be stored.

$mySitesUrl = “http://my.bharveyserver”
$mySitesHost = Get-SPSite –Identity $mySitesUrl
Update-SPProfilePhotoStore –MySiteHostLocation $mySitesHost
–CreateThumbnailsForImportedPhotos $true

With that, all the images that we’ve added to Active Directory are now available in SharePoint.