# // SharePoint

### Windows Azure Active Directory Federation In Depth (Part 2)

In my last post I talked a little bit about the provisioning and federation processes for Office 365 and Windows Azure Active Directory (WAAD). This time around I want to talk a little bit about how the various pieces fit together when federating an on premise Active Directory environment with WAAD and Office 365. You can find lots of articles online that talk about how to configure everything, but I wanted to dig a little deeper and show you why everything is configured the way it is.

Out of the box a Windows Azure Active Directory tenant manages users for you. You can create all your users online without ever having to configure anything on premise. This works fairly well for small businesses and organizations that are wanting to stop managing identities on premise altogether. However, for more advanced scenarios organizations will want to synchronize their on-premise Active Directory with WAAD. Getting this working revolves around two things: the users, and the domain.

First off, lets take a quick look at the domain. I’m using the Microsoft Online Services Module for PowerShell to query for this information. I’m going to use my domain as an example: syfuhs.net.

PS C:\Users\Steve\Desktop> Get-MsolDomain -DomainName syfuhs.net | fl *

Authentication : Managed
Capabilities   : Email, OfficeCommunicationsOnline
IsDefault      : True
IsInitial      : False
Name           : syfuhs.net
RootDomain     :
Status         : Verified

The important thing to look at is the Authentication attribute. It shows Managed because I haven’t configured federation for this domain.

If we then take a look at a user we see some basic directory information that we entered when the user was created. I’ve removed a bit of the empty fields but left an important one, the ImmutableId field.

PS C:\Users\Steve\Desktop> Get-MsolUser -UserPrincipalName steve@syfuhs.net | fl *

DisplayName                 : Steve Syfuhs
FirstName                   : Steve
ImmutableId                 :
LastName                    : Syfuhs
OverallProvisioningStatus   : Success
UserPrincipalName           : steve@syfuhs.net
ValidationStatus            : Healthy

The Immutable ID is a unique attribute that distinguishes a user in both on-premise Active Directory and Windows Azure Active Directory. Since I haven’t configured federation this value is blank.

Skip ahead a few pages after running the Convert-MsolDomainToFederated cmdlet and my domain is magically federated with my local Active Directory. If I re-run the first command we’ll see the Authentication attribute set to Federated. However, running the second command doesn’t return an Immutable ID and if I tried logging in through ADFS I get an error. What gives?

If we look at the token that is passed from ADFS to WAAD after sign in we see that there is actually a claim for an Immutable ID. This ID is what is used to determine the identity of the user, and if Office 365 has no idea who has that value it can’t trust that identity.

This particular problem is solved through directory synchronization using the DirSync service. DirSync is configured to get all users from Active Directory and add them to Windows Azure Active Directory. It synchronizes most attributes configured for a user including the objectGUID attribute. This attribute is synchronized to the ImmutableID attribute in WAAD. It’s the anchor that binds an on-premise user with a cloud user.

Two questions tend to arise from this process:

1. Why not just use the UPN for synchronization?
2. Why do you need to synchronize in the first place?

Both questions are fairly simple to answer, but the answers depend on one another. You cannot synchronize against a UPN because a user’s UPN can easily change. You need a value that will never change across the lifetime of a user account (hence the name “immutable”). You need the value to stay constant because synchronization will happen often. You need to synchronize any time a value changes in the on-premise Active Directory. Examples of changes include address changes or name changes. Changing your name can often result in changing your UPN.

It’s preferred to keep these attributes up to date in both systems because then applications can trust that they are getting the right values when requested from either system. This still begs the question though, why do you need to synchronize in the first place? Some people may ask this because it’s theoretically possible to provision new users as they first sign into an application. If the user doesn’t exist when they log in just create them. Simple.

The problem of course is that certain systems require knowledge of the user before the user ever logs in. A perfect example is Exchange. Imagine if a user is on vacation while the transition to Office 365 occurs. If the user doesn’t log in until they get back, that means they wouldn’t have received any email while they were away. Admittedly, not receiving a few weeks of email might be the preferred scenario for some, but I digress.

So we have to configure DirSync. Skip ahead a few more pages and DirSync executed and synchronized all my users. If we take a look back at my account we now see a value for the immutable ID:

PS C:\Users\Steve\Desktop> Get-MsolUser -UserPrincipalName steve@syfuhs.net | fl *

DisplayName                 : Steve Syfuhs
FirstName                   : Steve
ImmutableId                 : lHh/rEL830q6/mStDnD4uw==
UserPrincipalName           : steve@syfuhs.net
ValidationStatus            : Healthy

If I navigate to https://portal.microsoftonline.com I’m redirected to https://login.microsoftonline.com and prompted for credentials. However, as soon as I type in my username it prompts telling me I have to go else where to sign in.

The sign in screen is smart enough to parse the domain name from my user and lookup the Authentication type tied to that domain. If the domain is configured as Federated the sign in page is told to redirect to ADFS. If we return back to that first PowerShell command we’ll see the authentication is set to Federated. This was set by the Convert-MsolDomainToFederated  command. Two things happened when it was called.

We can take a look at exactly what was configured in WAAD by running more PowerShell.

PS C:\Windows\system32> Get-MsolDomainFederationSettings -DomainName syfuhs.net

FederationBrandName    : syfuhs.net
IssuerUri              : urn:syfuhs:net
LogOffUri              : << adfs signout url >>
NextSigningCertificate :
PassiveLogOnUri        :
SigningCertificate     : MIICzDCCAbSgA.....sh37NMr5gpFGrUnnbFjuk9ATXF1WZ

I’ve stripped out a few things to make it a little more readable. The key is that PassiveLogOnUri field. That is the URL passed back to the sign in page and is what is used to compose a WS-Federation signin request.

If I click the link I’m redirected to ADFS and if the computer I’m using is a member of the same domain as ADFS I shouldn’t be prompted for credentials. After Windows Authentication does it’s thing ADFS determines that WAAD sent us because the wtrealm URL parameter is set to urn:federation:MicrosoftOnline which is WAAD's Audience URI.

When Convert-MsolDomainToFederated was called, ADFS was instructed to create a Relying Party Trust for WAAD. That trust had a set of claims issuance rules that query Active Directory for various things like a user’s objectGUID and UPN. These values are formatted, bundled into a SAML token, and signed with the ADFS signing key. The token is then POST’ed back to WAAD.

The SigningKey field we saw in the Get-MsolDomainFederationSettings command is the public key to the ADFS signing key. It was configured when Convert-MsolDomainToFederated was called. It is used to verify that the token received from ADFS is valid.  If the token is in fact valid the domain is located based on the Issuer URI and UPN, and the user is located in the domain. If a user is found then WAAD will create a new token for the user and issue it to whichever service initially requested login, which in our case is https://portal.microsoftonline.com.

From this point on any time I browse to an Office 365 service like Exchange, I’m redirected back to https://login.microsoftonline.com, and if my session is still valid from earlier, a new token is issued for Exchange. Same with SharePoint and Dynamics, Windows Intune, and any other application I’ve configured through Windows Azure Active Directory – even the Windows Azure management portal.

Federation with Office 365 through Windows Azure Active Directory is a very powerful feature and will be a very important aspect of cloud identity in the near future. While federation may seem like a complex black box, if we start digging into the configuration involved we start to learn a lot about the all the various moving parts, and hopefully realize its not too complex.

Got an email the other day with a bunch of pictures to stick into my email signature, website, blog, slide decks, and etc for the SharePoint Summit in 2011 here in Toronto.  Since I’m content with the size of my signature, have no access to modify this website’s layout, and will never remember to stick them into any of my slide decks, here they are

Please go visit the site, see if you are interested in any of the presentations, and if you are, go!  It’ll be well worth the cost!

### Managing Identity in SharePoint

Yet another presentation on the docket!  I submitted an abstract to SharePoint Summit 2011 and they accepted!  I will be presenting on SharePoint and how it manages Identity.  More specifically, how SharePoint 2010 uses WIF to handle Claims based authentication and Federation.

Here are the details

Event: SharePoint Summit 2011, January 31st 2011 – February 2nd, 2011

When: 11:30 a.m. - 12:45 p.m. February 1st, 2011

Where: Four Seasons Hotel, Toronto

Abstract: Managing identities within an organization is relatively easy. However, as business changes, we need to be able to adapt quickly. Identity is something that often gets overlooked in adaptation. In this session we will discuss the Windows Identity Foundation and how SharePoint uses it to adapt easily to change.

### Using Claims Based Identities with SharePoint 2010

When SharePoint 2010 was developed, Microsoft took extra care to include support for a claims-based identity model.  There are quite a few benefits to doing it this way, one of which is that it simplifies managing identities across organizational structures.  So lets take a look at adding a Secure Token Service as an Authentication Provider to SharePoint 2010.

First, Some Prerequisites

• You have to use PowerShell for most of this.  You wouldn’t/shouldn’t be adding too many Providers to SharePoint all that often so there isn’t a GUI for this.
• The claims that SharePoint will know about must be known during setup.  This isn’t that big a deal, but…

Once you’ve collected all the information you need, open up PowerShell as an Administrator and add the SharePoint snap-in on the server.

Next we need to create the certificate and claim mapping objects:

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("d:\path\to\adfsCert.cer")$claim1 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" –SameAsIncoming

$claim2 = New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" –SameAsIncoming There should be three lines. They will be word-wrapped. The certificate is pretty straightforward. It is the public key of the STS. The claims are also pretty straightforward. There are two claims: the roles of the identity, and the email address of the identity. You can add as many as the STS will support. Next is to define the realm of the Relying Party; i.e. the SharePoint server.$realm = "urn:" + $env:ComputerName + ":adfs" By using a URN value you can mitigate future changes to addresses. This becomes especially useful in an intranet/extranet scenario. Then we define the sign-in URL for the STS. In this case, we are using ADFS:$signinurl = https://[myAdfsServer.fullyqualified.domainname]/adfs/ls/

Mind the SSL.

And finally we put it all together:

New-SPTrustedIdentityTokenIssuer -Name "MyDomainADFS2" -Description "ADFS 2 Federated Server for MyDomain" -Realm $realm -ImportTrustCertificate$cert -ClaimsMappings $claim1,$claim2 -SignInUrl $signinurl -IdentifierClaim$claim2.InputClaimType

This should be a single line, word wrapped.  If you wanted to you could just call New-SPTrustedIdentityTokenIssuer and then fill in the values one at a time.  This might be useful for debugging.

At this point SharePoint now knows about the STS but none of the sites are set up to use it.

Authenticating SharePoint sites using the STS

For a good measure restart SharePoint/IIS.  Go into SharePoint Administration and create a new website and select Claims Based Authentication at the top:

Fill out the rest of the details and then when you get to Claims Authentication Types select Trusted Identity Provider and then select your STS.  In this case it is my ADFS Server:

Save the site and you are done.  Try navigating to the site and it should redirect you to your STS.  You can then manage users as you would normally with Active Directory accounts.

### Naming Conventions can be Your Enemy

Or your ally in the fight against technology management.  Earlier this week I was given the task of doing some naming for new servers, which is pretty much SOP.  Problem is, we don’t have a naming standard.  As such, I may choose a name that annoys someone, or they choose a name that annoys me.  This becomes very political.  We don’t want to name things in such a way that they annoy people.  It’s a bad idea.  And, much to my dismay, I said something this morning that was pretty much just insulting to one of my team members.

I could have given loads of excuses, but it wouldn’t have mattered.  I was being petty.  Man, that’s a bad idea in an office.  It divides teams, and man, that’s *really* bad in an office.  The reason it came about was because a few people were talking about moving into “fun” server names, as apposed to functional server names.  Examples of this would be Cygnus or Badger, as apposed to GR-SQLCluster1.

The reasons behind it being:

• It’s more secure if the attacker doesn’t know what the server does, based on it’s name
• Server roles change over time, so GR-SQLCluster1 might become relegated to an apps server
• Sections of functional names become redundant
• Organize names by type; i.e. birds, galaxies, different words for snow, etc

At first glance, they make great sense.  However, after a little time to digest the reasons, a few things become clear.

• If an attacker is able to get to the server, to the point that they can know the name, you are already screwed
• A good practice is to rebuild the server if it changes roles, and with that change the name
• People don’t want to connect to the Badger Server
• You need a reference list to figure out what the Cygnus server does/where the Cygnus server physically is
• If you want to create DNS entries to provide functional names to it, that’s another level of complexity to manage
• What happens when you run out of server names?

Given this list, it now becomes an interesting debate.  But I have one question for you:

As a developer, would you name a variable ‘badger’ if it was holding a shopping cart?  Not a chance.  You would only do that if it were badger related, and even then you are better off with ‘meanLittleWoodlandCreature’ in case you change something.

In my response I called the security reason laughable.  Again – petty and a really, really, really bad idea when in a team discussion.  Obviously I was in a pissy mood for some reason, or maybe a greater than thou mood thinking I knew more about the topic.  I tend to do that.

I think what really made me do it was that we are developers, not administrators.  It’s not our job to name servers.  So why were we?  I didn’t want to piss anyone off, I just wanted to name the server so we could move on to the next stage of the deployment.  This situation could have easily been averted.

If we had a naming convention for our servers, regardless of fun vs functional, I could have followed the convention and washed my hands of the problem.  So I guess the question is, why don’t we have one?  Lot’s of companies don’t have them.  And I think it’s because of stagnant server growth.

If you are only setting up a couple servers every so often, you aren’t bogged down with these types of questions.  You have time to discuss.  The problem we are having, I think, is because we have increased our server growth dramatically in the last little while, which hasn’t given us enough time to discuss names as a group.  I was rushing to get the server into production because the administrators were busy working on other tasks that were filed under the category “Do Now Or ELSE!”

So I think we need a naming convention.  A functional naming convention.  It will prevent a world of hurt down the road.  Now to get buy in, and ask for forgiveness.  I still have lots to learn.

### Stop Complaining About Software Expenses

It’s been a long week, and it’s only Monday.  It all started with an off-the-cuff comment.  It was of the petty nature, and it certainly wasn’t accurate.  It seems that is usually the case with petty comments.

I was berated for suggesting SharePoint Services as a replacement for our ageing intranet, and the commenter responded with a quick “SharePoint?  Microsoft makes that, it’ll cost too much.  Our current java site works just fine, and it’s free.”  Or something of that nature.

How do you respond to a petty comment?  It’s pretty damn hard:

1. While Microsoft Office SharePoint Server 2007 does cost money for licensing, Windows SharePoint Services 3.0 (which MOSS is built on) is free.  Not free as in speech, but free as in beer.  Always has been.
2. Java is a terrible language for websites.  It’s slow, and none of the developers in the company know Java.  We all program with .NET languages.
3. The current intranet is running on an AS/400.
4. The bulk of the stuff we do on our current intranet could very easily be done in SharePoint, without any development.  And, we can also increase productivity with the added features of team workspaces and free templates for other departments.
5. The only cost will be in man-hours setting the server up, and migrating content.

Those have been my main arguments since I started working here.  We are a Microsoft shop, but very often choose non-Microsoft products.  Hmm…

The main reason we don’t use Microsoft products is cost.  Plain and simple.  Ironically, that is also the same reason WHY we use Microsoft products.

We use SQL Server, Windows Server 2008, Active Directory (finally!), IIS, MOSS (soon), and program in C#.  We don’t use office 2007, only Office 2003, some computers are still on Windows 2000 and XP.  Only one computer is running Vista, and two are running Windows 7.  But then again, we are a Not-For-Profit company.  Budgets are tight.

This post is NOT a comment on our current state of technology, because like I said in a previous post, we do a pretty good job of staying on the cutting edge in a few cases.

This post IS a comment on the people out there who think cost is the only thing to look at when evaluating a product.  For the love of god, STOP bitching about price.  START bitching about quality.

I can’t stand bad software.  People don’t pay for good software, but then complain about its quality.  Come on!  There is a formula out there that calculates the cost of a piece of software over time.  It takes into account initial cost, and the cost of the updates that follow.  It’s a simple y = mx+b formula.

Now, when you have a higher initial cost, you tend to assume it’s of higher quality.  Put this into the equation, and the number of updates, and the cost to implement these updates goes down.  Over the life of the product, it’s cheaper to go with the software that is initially more expensive.  This is basic business.

What this basic business formula doesn’t show you is the added headaches you get with crappy software.  You tend to end up with silos of systems, and silos of data.  You don’t get integration.  This is where the cost sky rockets.  Or more accurately, this is where productivity decreases.

Ironically…

SharePoint Services 3.0 is free.  It doesn’t cost anything to use.  It’s easy to use, and integrates with most of our internal systems.  I just ruined my entire argument.  Sorta.  SharePoint is a quality piece of software, and over time, it will cost less to use and maintain than any of the other intranet/middleware applications out there.  Most people don’t realize this.

I’ll probably get flack for this one:  Most people don’t complain about software expenses.  They complain about Microsoft expenses.

• “We give Microsoft too much money, and don’t get enough in return.”
• “There must be better software vendors out there than Microsoft that are cheaper.”
• “Why bother upgrading; XP Works fine.”

Have you seen the cost of a friggen Oracle license?  What about IBM’s iSeries?  Novell’s Groupwise?  My jaw dropped when I saw the cost of these things.  I can’t say a single nice thing about Groupwise.  It’s a terrible product.  IBM’s iSeries is pretty good, but it’s limited what you can do with it.  Oracle knows databases, but has a higher license cost than a good chunk of a department’s salary.

Microsoft gets most of our money because it has quality products, at a good price.  Look at a few competing vendors products and compare cost and quality as well as the ability to integrate across platforms.  Revelation is a wonderful thing.  You might think twice before settling on cost.

### Silverlight 3.0 and Why Flash Still (unfortunately) Won

Last week Silverlight 3.0 was released.  In Toronto, ObjectSharp put on a very cool launch event, with lots of great demos and compelling reasons to start using Silverlight immediately.  I was impressed, but I’m a Microsoft fan-boy (fan-boi?), so that doesn’t count.  It was certainly fitting that ObjectSharp propose using Silverlight for some parts of our new website www.woodbineentertainment.com, seeing as they won the bid to build the new site.  I saw the potential; as did a few others on the team.  However, some executives did not see the benefit.  I respect their opinion, somewhat because I have to – they can fire me after all, and mostly because they have business sense on their side.

The company is very much on the cutting edge of technology in a few respects, but very conservative in the way we choose technology.  For instance, our new site will be built on Microsoft Office SharePoint Server 2007.  I’d wager there are less than a hundred publically facing websites on the internet that use MOSS (probably due to complexity and cost), yet we chose to use it because of the potential in further developing it in future iterations.

Silverlight on the other hand is a different story.  Recent reports peg Silverlight penetration at around 25-30% of all browsers.  Whether or not this is accurate, who knows.  It’s the only data available.  Flash penetration is at 96%.  Now, in my opinion 25% growth in 2 years on Silverlight’s part is impressive.  Flash has been around for nearly 2 decades.  There is definitely a correlation to be made in there somewhere.

At this point, I was sold on using Silverlight.  The exec’s still weren’t.  Seeing as Silverlight is a browser plug-in, it must be installed in some way, shape, or form.  At 25%, that means our customer demographic would have around 10% penetration.  That is terrible.  Getting them to install a plug-in to view site content is a tough sell.  The executives didn’t want to scare away customers by making them install the plug-in.  SharePoint doesn’t need a browser plug-in.

And here in lies the Catch-22

To expand our marketed audience, we build on Silverlight to give them more content that is better authored to their needs.  In doing so, we lose customers because they need to install the plug-in.  There is no metric at this point in time to help us extrapolate the difference.  There is a reasonable risk involved with using such cutting-edge technology.  We will use it when browser penetration is high enough, yet browser penetration won’t grow if sites like ours don’t use Silverlight.

Ah Well

I’m a technology risk taker.  I live on the bleeding edge.  I run Exchange 2010 beta, on Server 2008 virtualized on Hyper-V, with IIS7 running this site, browsed by IE8 on Windows 7 RC, and authored in Office 2007 (2010 if Microsoft would give me the flippin bits!).  The company, not so much.  Risk is good – as long as you can mitigate it properly.  I can manage my risk, as it’s not the end of the world is something here crashes.  I don’t lose an audience.  If the company can’t market to it’s customers because the tools in use are too new, it will lose audience.  Period.  And that means lost revenue.

Maybe we can convince the exec’s in Phase II.

### Security, Architecture, and Common Sense

Good enough is sometimes not good enough.  I’ve been doing a lot of thinking lately (well, I’m always thinking), and security has been an issue that has come up a lot.  Frankly, I’m a two-bit software developer.  I know my code isn’t the best, nor the most secure.  I use strong passwords, encrypt my sensitive data, and try to limit access to the applications for those who need to use it.

In theory this works.  Problem is, it’s a lame theory.  There are so many unknown factors that have to be taken into account.  Often times they aren’t.

When I go to build an application I spend time designing it and architecting it.  This is usually the case for most developers.  What I’ve noticed though, is that I don’t spend time securing it.  I can’t.

Imagine building a house.  You put locks on the doors, bars on the windows, and someone breaks in.  Why?  Because someone left the key in the door.  You can’t build against that.  You just can’t.

You can follow the Security Development Lifecycle, which I recommend to each every single developer I meet.  There are tons of resources available.  But it can only go so far.  It’s designed more for being part of the iterative processes, not the architecture.  Or at least, that’s how most people interpret it.

So?

My last post talked about Single Sign-On (SSO).  It’s a great sellable feature for any product.  What most people don’t realize though is the inherent security benefit to it.  With it, that means one less password to remember, one less password that could get intercepted, one less password to change every month.  This is a fundamental architectural issue.  But at the same time, it’s common sense.

What is sometimes the simplest idea, is usually the correct solution

What the hell does that mean?  It means keep it simple.  Security is simple.  Keep data from prying eyes, and keep it from getting lost.  This is common sense.

Security is not difficult to comprehend.  It becomes difficult when academics get involved.  Spouting theories and methodologies scares people into thinking security is extremely difficult to implement.  It’s not!

Understanding the flow of data is crucial in properly architecting an application.  It’s crucial in properly securing an application as well.  SSO is a perfect example of this.

The SSO feature in Office SharePoint Server 2007 maps user credentials to back-end data systems. Using SSO, you can access data from server computers and services that are external to Office SharePoint Server 2007. From within Office SharePoint Server 2007 Web Parts, you can view, create, and change this data. The SSO feature ensures that:

• User credentials are managed securely.

• User permission levels that are configured on the external data source are enforced.

It makes perfect sense.  It’s simple when you think about, and it affects every subsystem of SharePoint.  Make security a feature.