SharePoint, My Site & Managing User Profile Properties – Part 1/2

A couple of months ago I posted an article introducing My Site and social enterprise networking with SharePoint, and focused the discussion around tracking colleagues via the colleague tracker web part. If you missed that article, you can access it here.  I also promised that I would provide future articles discussing other My Site features so here is a two part series on My Site and Managing user profile properties with today’s discussion around populating Windows Active Directory (AD).  Some of the common question’s asked are what fields should be populated in AD and how does one populate the Organizational Hierarchy web part?  I will be providing answers to these questions in today’s post.

A lot of the information or metadata that a SharePoint user inherits comes from Windows Active Directory.  Depending on how much information is populated, this can be a little or a lot.  SharePoint by default includes 46 user profile properties, in which 21 of these are mapped to Windows Active Directory. In most cases, it’s best practice when setting up a new user in Active Directory  to try and populate as much of these 21 attributes as possible which is then automatically imported into the SharePoint User profile properties.  This should be relayed to your AD guys.  You also have the ability to create custom mapped properties in your SharePoint profile property store which can also be mapped to Active Directory.  I will expand on this in part 2 of this series which will also discuss how users can configure other user profile details such as interests, skills and responsibilities.

So let’s begin by creating a new user in Active Directory in which we will then begin populating the relevant AD fields. 

Under the General Tab, Populate First Name, Last Name, Display Name, Office, Telephone Number and Email (this should be populated via Microsoft Exchange).  Please note that Web page is automatically populated when a user creates their My Site for the first time and clicks on “Set as default My Site”

 

Navigate to the Telephones Tab and populate the Fax Number.  

Under the Organization Tab, populate Job Title, Department and specify the Manager.  This field is important as it build’s the organizational hierarchy which is displayed via the Organization Hierarchy web part.

 

In order to specify the Manager, Click on Change and enter the Manager’s name as per the below screen shot.

The result is the below. 

The Direct reports field in Active Directory is the reciprocal of the Manager, i.e. If I navigate to Manager : George Khalil, my Test SharePoint User will be listed under Direct reports as per the below screen shot.

The Organization Hierarchy Web Part will be automatically populated as per the below example based on Manager and Direct reports information from AD.

 

The SharePoint User profile details that are mapped to Active Directory are also populated automatically based on your Active Directory Import Schedule.  As you can see below, Name and Title are non-editable fields and can only be changed in Active Directory.  More on SharePoint User profile details will be discussed in Part 2 of this series.

You will also notice that some of these mapped fields are also displayed as part of your public user site referred to as My Profile such as Job Title, Department, Office and Phone Number.

We have learnt that by populating Active Directory you are inadvertently populating SharePoint user profiles with meaningful information which is also made public to other users via My Profile.  The My Profile page also contains the organization hierarchy  web part which also draws it’s information from the Manager field in Active Directory.

In the next part of this series I will delve into creating and mapping custom fields with Active Directory and how users can contribute other personal information outside of Active Directory such as Interests and Skills and control how this information is being displayed through privacy controls.

If you would like to subscribe via email to be notified of future articles you can do so from here or via RSS here.

Outlook Web Access redirection via Microsoft ISA 2006

We all know from experience that advising end users to browse  to https://mail.yourdomain.com/OWA if you are running Exchange 2007 or /exchange if you are running Exchange 2003 is usually problematic .  Oh! and did I forget to mention that it’s HTTPS and not http!  We must admit that not all end users are likely going to remember this URL and at times even struggle to distinguish the difference between secure and non secure sites.  Well if you are running ISA 2006 as an edge or secondary application layer firewall then we can easily simplify the URL that we will publish to our end users by creating a deny rule which will then automatically redirect them to the correct address.  By the end of this post,  your end users will only need to remember a simple URL in the form of  mail.yourdomain.com (notice that http or https is not required).  This post is assuming that you already have an existing Exchange Publishing Rule in ISA 2006.  Note, that this technique can also be used for other websites that ISA may already be protecting such as SharePoint and Terminal Server Web Access.

Let’s begin by launching the ISA Management Console, and navigate to create a new web site publishing rule.  The New Access Rule Wizard will launch in which you will begin by specifying a name for your rule.

Select Deny as your Rule Action

Select Publish a single web site or load balancer.

Select Use SSL to connect to the published Web server or server farm.

Enter your Internal Publishing Details which should be identical to the original Exchange Publishing rule.

Click Next and then Next again skipping the Path details.

Enter the Public Name details as per your original Exchange Publishing rule.

Select the existing Exchange Web listener that you already have created for your Exchange Publishing Rule.

Select, No delegation, and client cannot authenticate directly.

Remove Authenticated Users if present and select All Users instead.

You will then receive the below warning as we have selected All Users.  Ignore this warning and click on OK to continue.

Now that the rule has been created, we need to specify the redirect page.  Right Click on the newly created rule and select properties.  Navigate to the Action tab and click on the check box beside “Redirect HTTP requests to this Web page:” and enter the full Outlook Web Access URL.

We are now complete.  You will need to ensure that the deny rule is place immediately below the original Exchange Publishing Rule as per the below screen shot.  When a user now enters the url mail.yourdomain.com it will hit the redirection rule that we have just created which will then redirect to https://mail.yourdomain.com/owa and authenticate against your original Exchange OWA rule.

In summary we have removed the all so common confusion that end users may encounter when browsing to the Outlook Web Access site.  This methodology provided above with the deny rule can also be used against any other web site publishing rule including SharePoint Sites and Terminal Server Web Access.

Securing your SharePoint Sites with ISA 2006 using Forms Based Authentication – Part 2/2

In the second and last part of this series we will be focusing our efforts in securing our SharePoint Site through setting up a publishing rule in ISA 2006.  If you recall in the first article, we began our setup by extending the default SharePoint site into the Internet Zone, created a certificate request via IIS to be sent to a 3rd Party Certificate Authority and applied the certificate to our newly created extended site.  If you missed it, you can access part 1 here.

So let’s begin the second part of our setup!  The first item we need to address is the newly created certificate that has been applied to our site in IIS.  ISA also needs to be aware of this certificate so we need to export it from IIS and then import it to the certificate store on the ISA server.  This certificate will be required when creating the web listener in the ISA rule later below.

To export the certificate, select it in IIS and select Export under Actions.

Specify the export path and enter a password.

After exporting the certificate, copy it to your ISA server and then launch the Certificate MMC snap-in from the ISA Server.

 

Right click on the Personal Folder and select All Tasks /  Import.  This will invoke the Import Certificate Wizard.

Click Next.  Browse for the certificate file that we exported and copied earlier.

Click Next.  Enter the password that we supplied to the exported certificate.

Click Next and ensure that the certificate is placed in the Personal Certificate Store.

 

Now that we have done the pre-work for ISA, it’s time to launch the ISA Server Management Console in order to create our SharePoint Publishing Rule.

• · Right click on Firewall Policy and select New / SharePoint Site Publishing Rule
• · Specify a SharePoint publishing rule name
• · Select your Publishing Type, in my case I selected Publish a single Web site or load balancer.
• · Click on Use SSL to connect to the published Web server or server farm

Type the Internal site name: The warning here states that the site name must match the common name or subject alternative name on the certificate. This should be the World Wide Web Address.

Then click on Use a computer name or IP address to connect to the published server and enter the correct details. This could potentially be a single server  IP or the IP address of your Network Load Balanced Cluster.

 

Specify the Public domain name.

We will now create a New Web Listener by clicking New. This will invoke the New Web Listener Wizard

• · Provide your web listener with a friendly name. e.g SharePoint FBA
• · Select Require SSL secured connections with clients in the Client Connection Security Window

• - Specify the Web Listener Internal IP address.  If you recall from part 1, this is a domain joined ISA server sitting in the internal network in between an existing edge firewall and your SharePoint Site.

The next step requires you to select your SSL certificate. Depending on the number of certificates your ISA server is storing you will either select Single certificate (in the event you are using a SAN or wild card certificate) or assign a certificate for each IP address. In my case I am using singular certificates for my SharePoint Sites so I will assign a specific certificate against a unique IP address.

You now need to select your Authentication Settings for the web listener. We are providing Forms based Authentication for our SharePoint Sites so I will select HTML Form Authentication and then select how ISA server will validate these. I am selecting Windows (Active Directory in my instance).

• · Specify your Single Sign On Settings, Click Finish.
• · Select your Authentication Delegation. In my case I am selecting NTLM

• · Select “SharePoint AAM is already configured on the SharePoint server. We completed this step after extending our site in Part 1 of this series.

• · Select your User Sets

• · Then Click Finish to complete the Wizard.

One of the great enhancements to ISA 2006 Service Pack 1, is the ability to test your rules automatically within the ISA Management console.  This will do the hard work for you and ensure that your rule is correctly setup and that your certificates are correctly in place.  All you need to do is right click on the rule that we have just created and select properties. 

Under the General tab, click on the Test Rule button.

You should get green ticks as per below.

 

We are done!  Our internal users can now navigate to the external published URL and get directed to ISA’s Forms Based Authentication screen as per below. After successfully authenticating with Active Directory via the ISA server the users will be automatically redirected to the SharePoint site.

Some important points to emphasise;

• Ensure your Alternate Access Mappings (AAM) are setup correctly for the correct zone.
• Ensure your certificate common name matches the fully qualified external domain name which in turn matches the AAM in SharePoint.
• Ensure that you have successfully exported the certificate from IIS Manager and Imported it to your Certificate store on the ISA Server.
• Use the Test Rule Button in ISA 2006 SP1 to test your rule, so ensure you are running the latest Service Pack for your ISA server.

If you missed part 1 of this series, you can access the article from here.

Securing your SharePoint Sites with ISA 2006 using Forms Based Authentication – Part 1/2

Do you want to provide your information workers access to your SharePoint Site whilst out of the office easily from any internet connection without compromising security?  Do you want to accomplish this without complicated client-site VPN setups.  In this 2 part series I will be providing you with step by step instructions explaining how you can leverage Microsoft’s Internet Security and Acceleration Server (ISA) 2006 and the out of the box SharePoint publishing rule to provide secure access for your corporate users using SSL.  YES! That’s right! Whether you like it or not, Microsoft ISA is a great reverse web proxy application firewall in which HTTP/HTTPS traffic from the internet is inspected first before it is forwarded onto the destination server, in our case our SharePoint web servers.  Microsoft ISA is also more than capable in providing you with a secure edge firewall as well.

Providing reverse web proxy is something that most major firewall vendors cannot accomplish out of the box including some of the big players like Checkpoint and Cisco.  ISA is an ideal choice of reverse proxy to place in between your existing edge firewall and your SharePoint server due to the application layer inspection filtering that is also provided.  Our ISA 2006 server should be domain joined in this instance as it will be acting as a dedicated reverse proxy and there are a lot of articles at isaserver.org supporting my case.

The below diagram is an example of how ISA can be strategically placed within your network.  In our example, all servers are running Windows Server 2008, SharePoint 2007 and ISA 2006 with the latest Service Packs applied at the time of this writing.

Our goal at the end of this 2 part series is to setup Forms-Based Authentication (FBA) (screen capture below) where users are forced to authenticate successfully with Active Directory first before being passed on to the SharePoint Server. 

So let’s begin. This post is assuming that you already have your current SharePoint Site setup correctly in IIS and Central Administration assigned to the Default Zone with Windows being our assigned Membership Provider. Our goal is to now be able to access the same SharePoint site outside of the corporate LAN via the World Wide Web using the same authentication method, i.e. via <DOMAIN>\<Password> . In order to do so, we need to extend the current site, ensure that the Alternate Access Mapping (AAM) is setup correctly and secure the extended site using  SSL via a 3^rd party root certificate.

Extend your existing SharePoint Site

Browse to Central Administration / Application Management and under SharePoint Web Application Management, select

• · Create or extend Web application
  · Click on Extend an existing Web application
  · Select an existing Web application to Extend
  · Create a new IIS web site and type in your description
  · Port should be set to 443 (SSL)
  · Specify a Host Header : yousite.externalfullyqualifieddomain.com
  · Select Yes Use Secure Sockets Layer (SSL)
  · Select Internet for your Zone as requests are coming from world wide web
  · Click OK

 

Alternate Access Mappings (AAM)

The Alternate access mappings for the zone should have been created for you and you can confirm this via Central Administration / Operations / Global Configuration / Alternate access mappings.

More detailed information on Alternate Access Mappings (which I highly recommend) can be found at this TechNet Article http://technet.microsoft.com/en-us/library/cc288609.aspx (Plan alternate access mappings)

By default your Alternate access mappings for all 5 zones (Default, Intranet, Internet, Custom, Extranet) are set to use Windows as your Membership Provider Name which is what is required in this example. Recall that we want our users to authenticate using their Active Directory credentials. You can confirm the Membership provider for your zones via Central Administration / Application Management / Authentication Providers. Ensure the correct Web Application in question is selected first.

Please also note that the extended Website will have been automatically created and listed in IIS Manager (Windows 2008)

SSL and Certificate Creation

We now need to create a certificate request that we will pass on to our preferred Certificate Authority (CA). Please note that it is best practice  to use an external CA to avoid SSL warnings and errors for your users when browsing to the site.  My preference is Godaddy.com who provide decently priced certificates, and no I am not a Godaddy reseller :)

In IIS 7 Windows 2008 this is done via Server Certificates located under the properties page of the IIS Server.

• · Click on Server Certificates, under the IIS heading 
  · Under Actions, Click on Create Certificate Request
  · Fill in the details; please note the Common name is important and should be the fully qualified domain name that is being accessed from the World Wide Web.

• · Select your Cryptographic Service Provider Properties.
  · Specify the filename and location to output the certificate request (The contents of this file (MODIFIED EXAMPLE BELOW) is important as it will be required by your Certificate Authority. In my case I am using a 3^rd Party Certificate Authority that will issue the certificate.

• · Once you have been issued with your certificate file from your Certificate Authority, go back into IIS Manager and re-launch Server Certificates and this time under Actions select Complete Certificate Request
  · Browse for the File Name and specify a Friendly name

Upon completion of the wizard your certificate will appear beside the already self signed machine certificate in IIS7.

You will now need to apply the new certificate against the recently extended website.

• · Click on the Site you wish to apply the certificate and then click on SSL Settings.

• · Select Require SSL and Require 128-bit SSL for your SSL settings and click on Apply

We now need to apply our newly imported certificate to the extended site by clicking again on the extended site, and under Actions select Bindings and then click on Edit.

Select the newly added SSL certificate from the drop down and ensure the port and IP address settings are correct.

Our site is now secure and ready to be accessed via the World Wide Web, well almost!  Stay tuned for next week for part 2 of this article, in which we will be focusing on the configuration of ISA 2006 and how we can leverage the inbuilt SharePoint Publishing Wizard to allow external access to our SharePoint site via SSL and Windows Forms Based Authentication.

You can subscribe to future articles by clicking here