Month: June 2014

Posted on

My Tribute to Joseph Thomas Alvarez and his mother Maria Helen Alvarez – True Oklahoman’s

This evening I was watching "Saving Mr Banks" and it made me think about my recently passed away friend Joe Alvarez.  Joe and I met three years ago during one of my wife's and I's trips out and about in Rancho Sante Fe (specifically a little place called Dolce).  Joe was a very friendly guy and over several months we got to know Joe really well.  He loved his red wine, and of course flirting with Lidiya (but harmless of course).  Over those few months, I found that Joe had just lost his mother Maria a few months before.  He proceeded to let me know she was co-owner in the first Television station in Tulsa, OK. In addition, she fronted a lot of the money for the Disneyland Hotel (hence why I remembered Joe tonight).  As you can read in one of the links below, Mr. Disney had leveraged all the money he could to build Disneyland, so he turned to Joe's mom and her business partner to build the hotel.  Here is a picture of Joe's mom, Maria, manning a TV camera for her TV station KOTV.  For those of you that live in Oklahoma today, you still watch KOTV:

 

Here is a picture of her at the opening of the Disneyland Hotel:

 

You can read more about this incredibly smart Oklahoman woman here:

After I did all this research on Joe's mom, I brought it up about how cool his mom was one night.  He appreciated it and we talked about all his time growing up in Oklahoma.  After all, Joe had been born in Oklahoma City, Oklahoma before his mother sold the TV/Radio station and moved to San Diego.  When Joe brought up his mom, I told Joe I was born and raised in Oklahoma as well, and needless to say, there is a bond between fellow Oklahoma's similar to that of the bond people have to their country (for example, all you watching the USA in the worldcup).  After we realized we were both born and raised in Oklahoma, we became really good friends. 

We met Joe's lovely wife and his daughter Kennedy on a few occasions, both very lovely people.  We also went to Joe's house a few times, he had this really cool and massive collection of Harry Jackson bronze sculpture cowboys.  They were everywhere, small ones, medium ones and really big ones, all of them, prominently placed in a way that just made you ache for Oklahoma. And they did, every time at his house, it brought back tons of memories for me in growing up in Oklahoma.  Joe was such a friendly guy.  He invited us on more than a few occasions to sit at his finish line table at the Del Mar Racetrack (Joe was the longest standing member of the racetrack after his mother).  It was awesome walking and hanging out with Joe as he was so nice and everyone liked him.  He invited us to his friends houses (some of them incredibly extravagant, yet, all down to earth amazing people).  One fond memory I'll never forget, is competing against Joe with his horse picking skills and challenging him to see who could lose the less or make the most money at the track.  He broke under the pressure and I won…it was quite the victory, as he could read the horse stats like no one I have ever met!

I learned of Joe's death a couple weeks after it happened (I didn't get to go to the funeral, and I didn't get to say anything, which probably bummed me out more than anything).  Some of you may have seen the tweets.  It was one of the saddest feelings knowing that two special Oklahoman's (Joe and his mom), and one of my friends, had passed away leaving the rest of us Oklahoma's to lead the way in this world. I know those last few years of hanging out with Joe, he enjoyed us being around and coming over to our house for our parties.  Joe had a pretty amazing life himself, as you can read in this article, he hung out with some pretty amazing people and had a lot of cool stories (and yeah, he even talked about fish a couple of times):

This blog post is to you and your mom Joe, rest in peace my friend.  I'll try to hold the fort down…

 

Posted on

Cannot find module ‘sax’ – Cordova with Visual Studio

You may run across this error when compiling your Hybrid-App / Cordova application in Visual Studio.  One of my students got it this week.  It looks something like this:

This means that the install of the Cordova extensions did not work properly and you are missing some files.  Mainly these two:

Simply uninstall (yeah, I know it takes a really long time to uninstall and reinstall).  And the files should show up.  If that doesn't work for you, install on another machine and copy over those directories.  Then all will be fine!

Posted on

O365 and Non-ADFS Federation – It’s not O365’s fault

I'm not a fan of ADFS.  It sits right below Azure Access Control Services (ACS).  ACS used to be my favorite identity provider aggregation platform, but how times change (ref this post).  Several new players are entering the market and all of them realize the missing gaps in ADFS and ACS.  Therefore, the drive to make a better authentication toaster is ON!

The goal of this post is to make you realize that you are having the wool pulled over your eyes in terms of the bigger picture around Identity Management when it comes to O365.  To make this point, let's take a look at a typical on-premises solution:

  • A SharePoint customer wants to setup multiple site collections (yes, all host header site collections) to support different customers
  • Each customer has different requirements around supporting federated external customers
  • Some customers prefer Google as their auth, others Yahoo and others Facebook, etc

On-premises

Solving this problem with on-premises environments is a piece of cake.  You have complete control over adding trusted Identity Providers (IdP) all day long. To solve the problem above, its likely you are going to think that adding a Trusted Identity Provider for each required auth mechanism is the answer.  That would be false.  As tempted as you may be to do this, its a really bad idea to have more than one. You should ultimately have a single Identity Provider with that provider supporting multiple "Apps/Replaying Parties (in this case site collections)" that would then show different options when a user needs to auth.  This allows you the most flexibility in that you simply set the IdP once, then configure the apps in the IdP.  Totally seamless, perfect.

Office 365 and Single Sign On (ADFS)

If you had this requirement in O365, you are out of luck.  Do not pass GO, do not collect $200USD.  In terms of O365, you are by default forced to use this one IdP mentality.  For each verified O365 domain, you can only setup a single Federated Identity Provider.  In most cases, everyone I have seen has used ADFS to integrate their on-premises Active Directory to sync accounts and/or configure Single-Sign On to redirect to their ADFS proxy.  This unfortunately, is the Microsoft promoted way of achieving Single-Sign-On nirvana.  I'm not a baby swimming in a pool, so let's take a look at what lives outside the koolaid-y-ish sugar water.  If you do this (which unfortunately, you probably already have), you are locking yourself into the current limited features of ADFS and hoping that ADFS gets some much needed development attention in the future (such as supporting OAuth 2.0). That being true, ADFS is a Microsoft product, you'll find a lot of people that can help you (support and consultant resources) to get it setup within a few hours.  You could also do it yourself by using TechNet/MSDN et all. 

Office 365 and Something else

If you want to use something other than ADFS, well, you better dig in for doing a ton of research on how WS-Fed and WS-Trust works and similarly, OAuth.  If you don't have time for that, then you'll need to request the services of people that do know that space. Unfortunately, having the identity management skills matched with an understanding of the future of App Models across vendors is a rare breed of consultant.  You also have to contend with a cold hard fact:

  • Currently, Office 365 only supports users of your verified domains (such as contoso.com)

Say what?  It means that even if you wanted to use Twitter, Facebook, whatever, the people that signed up have to have used the email address from their verified domain!  Uh…say that again?  Yeah, that means you can't login with your user@hotmail.com account using Facebook.  If you signed up with your contoso.com account on Facebook, then it will likely map your email over in the claims and let you in, but that's up to how fancy your Identity Provider is.  Azure AD is expecting a very specific format of token with specific claims.  If it doesn't get them, then your login will fail.

So if you can't login using something other than a verified account, what's the point?  

I feel this is a major fundamental loss of functionality between on-premises and O365.  If I want to create a site collection with a specific relaying party app to my IP (which then provides a set of auth services), I should be able to do it. It is such a common pattern in on-premises SharePoint. I don't think the band aid of "external access" fits the bill here.  Those links that are generated can be freely sent all over the web punching small barely noticeable holes in your O365 tenant. I'd like to see the governance page in O365 that shows me every link that has been generated across the entire tenant (you can see on a site by site basis using this link – https://domain.sharepoint.com/_layouts/15/start.aspx#/Access%20Requests/pendingreq.aspx).  There is not global admin UI to tell you who has been added or what has been shared – reference notes at bottom of this article. With an IdP in the picture, you simply disable their access and now they will never gain access to anything in your environment. This would require the removal of this "external sharing" feature that bypasses Azure AD in O356.  Wow, isn't that innovative?

Can I even use something other than ADFS in O365?

Heck yeah you can!  I recommend it!  By adoptingchoosing an Identity Provider solution (whether one you install on-premises or cloud hosted) that allows for you to expand
out past basic AD accounts, you will be ready for when Azure and O365 wakes up one day to
realize they should have allowed it in the first place.  You can set this up by removing the ADFS federation and replacing it with new Ws-Fed endpoints of your IdP.  This is enabled using the following cmdlets (this one is using Auth0.com):

  • $cred = Get-Credential
  • Connect-MsolService –Credential $cred
  • Set-MsolDomainAuthentication -DomainName "chrisgivens.com" -FederationBrandName "chrisgivens.com" -Authentication Federated -PassiveLogOnUri "https://chrisgivens.auth0.com/wsfed/ID" -ActiveLogonUri "https://chrisgivens.auth0.com/ID/trust/usernamemixed?connection=yoyo.chrisgivens.com" -MetadataExchangeUri "https://chrisgivens.auth0.com/wsfed/ID/FederationMetadata/2007-06/FederationMetadata.xml?connection=fs.chrisgivens.com" -SigningCertificate "Cert" -IssuerUri "urn:chrisgivens" -LogOffUri "https://chrisgivens.auth0.com/logout" -PreferredAuthenticationProtocol WsFed 

NOTE:  If you have already setup ADFS, you'll need to disconnect from that.  I have yet to test out all the paths, but the one I choose was really painful.  I used the Remove-MsolFederatedDomain cmdlet.  This forced me to remove all users (but did not require me to remove my groups).  Once I removed all users the command succeeded, but proceeded to delete the domain completely from my tenant!  I then had to re-add it, re-verify it, then fire off a DirSync.  Once that once done, I could run the above commands and it redirected properly to my IdP.

After configuring the federation when you go to "login.microsoftonline.com" and type your verified email, it will redirect to your IdP login page.  From there, you will see all the options that you have enabled for that relaying party.  Even though you can enable all the OAuth 2.0 providers you can imagine, an attempt to login will fail miserably.  There are some current technology issues that Azure AD must resolve:

  1. Azure expects a UPN/Email that matches a user in your Azure AD (at a minimum, you would have needed to sign up for a service using that verified domain email)
  2. Azure AD is expecting an ObjectID
  3. O365 Services have to support these accounts (even if that means simply ignoring them)

For the first issue.  Azure AD would have to allow the addition of users other than your verified domain.  Or at your IP, you map a user from external to internal.  For the second issue, again, this can resolved by either Azure, or by the Identity Provider.  IPs can choose to implement this today by integrated with Azure AD to query for the object id based on a valid UPN.

Until this these items are resolved, you can certainly fall back to the "forced" way by Microsoft to use Active Directory users from a verified domain (and yes, you should feel angry about this) by setting up a pass through from your IP to ADFS/Active Directory.  The preferred way is to utilize a client on your Active Directory server (pretty much every IdP has this). As only a few of you know or will understand, if you use ADFS, you will currently lose Office Client features. But don't be worried, later this year, Office will release an update that will support SAML-P.  This will let you utilize many different types of auth (basically anything you can do via browser) with Office clients.  That will be awesome, even though users will never fully understand what just happened.

Take It Up Another Level

Home realm discovery is not extensible in Azure AD.  What is home realm discovery?  Its the login drop page that takes your context, in this case, your email domain, and then redirects you to the proper IdP.  What does it mean to not be extensible?  It means that IdP's cannot create a portal of Apps page.  What does that mean?  Think Universal Access Gateway (UAG).  Imagine UAG-like portals, only hosted by your IdP, such that an external party can login to your IdP, and are then presented with the applications (such as O365), that they have access too.  When they select it, it will immediately redirect you to your O365 site (no need to go to login.microsoftonline.com).  As it stands right now, O365 does not support external home realm discovery pages.  This is also a serious limitation that needs to be added to the road map.

Summary

If enough people push the O365 and the Azure teams to fill the gap of this major difference between the products, I feel it would fulfill many of the requirements we have with customers today and make O365 an even more popular platform!  Here is your call to action:

  • Quit using ADFS, find an IdP with an eye towards the future
  • Highly "Suggest" to Azure and O365 that they support external identities (Vote for it here on UserVoice)
  • "Suggest" to Azure that they allow tenants to have a custom home realm discovery page

Stay classy internet,
CJG

 

 

Posted on

Errors when Installing DirSync.exe

I ran across two different errors with DirSync today.  The first had to do with the fact that I had DirSync on a computer previously and then re-installed it.  Because of this, I received this error:

System.Management.Automation.CmdletInvocationException: Access denied  —> System.Management.ManagementException: Access denied
   at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
   at System.Management.ManagementObjectCollection.ManagementObjectEnumerator.MoveNext()
   at Microsoft.Online.DirSync.Common.MiisAction.GetTargetMA()
   at Microsoft.Online.DirSync.Common.PrerequisiteChecks.ThrowIfSyncInProgress()
   at Microsoft.Online.Coexistence.PS.Config.SetCoexistenceConfiguration.VerifyMachinePreRequisites()
   at Microsoft.Online.Coexistence.PS.Config.SetCoexistenceConfiguration.BeginProcessing()
   at System.Management.Automation.Cmdlet.DoBeginProcessing()
   at System.Management.Automation.CommandProcessorBase.DoBegin()
   — End of inner exception stack trace —
   at System.Management.Automation.Runspaces.PipelineBase.Invoke(IEnumerable input)
   at Microsoft.Online.DirSync.PowerShellAdapter.PowerShellCommand.ExecuteCommand(Command command, Boolean refreshPath)

Looking a little deeper, it turns out that DirSync install will create a user account and then add it to other created local groups.  This is all very similar to how SharePoint installs because both DirSync and SharePoint use MIIS. Because I had already installed DirSync at some point in the past, the account existed, but I'm guessing the password was out of whack.  Since I wasn't sure how to reset the password (and didn't want to spend the time to figure it out), I defaulted to uninstalling everything, deleting that user, rebooting and re-installing. Done.

But it didn't end there.  I was attempting to install a secondary DirSync machine as a cold standby, but was getting an error when attempting to configure it:

System.Management.ManagementException: Generic failure
   at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
   at System.Management.ManagementObjectCollection.ManagementObjectEnumerator.MoveNext()
   at Microsoft.Online.DirSync.Common.MiisAction.GetTargetMA()
   at Microsoft.Online.DirSync.Common.MiisAction.IsSyncInProgress()
   at Microsoft.Online.DirSync.Common.PrerequisiteChecks.ThrowIfSyncInProgress()
   at Microsoft.Online.DirSync.UI.IntroductionWizardPage.PrerequisiteValidation()
   at Microsoft.Online.DirSync.UI.IntroductionWizardPage.OnLoad(EventArgs e)
   at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
   at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
   at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
   at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
   at System.Windows.Forms.Control.CreateControl()
   at System.Windows.Forms.Control.WmShowWindow(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

This means that the DirSync tool was not smart enough to tell you that you were installing it on a SharePoint server (which I didn't realize I was doing) with the ForeFront services already installed.  When you attempt to do this, you will overwrite your SharePoint ForeFront settings with the account mentioned above and then the two will fight over the service.  Obviously, this is bad.  I hadn't really done much research on some of the best practices around DirSync so its a bit of shame on me, but I also didn't find answers to these errors on the web when I google/binged them, so I'm making a mental blog note for others.

Posted on

O365 is not secure

I used to think it was.  After all the amazing things you read on the O365 Trust Center, you all but think it is Fort Knox (well, at least one part of it is right Bill Baer?) 

Let me go back to that title. "O365 is not secure…once you start adding users".  Last week I blogged about a security oversight in O365's partner sharing feature.  Basically what this means is that once you accept an invitation from a partner (aka a "user"), you become just another customer in their "customer management" portal. You can read more about this feature here:

http://blogs.office.com/2014/01/28/introducing-the-new-office-365-partner-admin-center/

Do you know who else they have as customers and who is accessing your data and when?  No. They don't really have any logs to tell you when a partner is accessing your portal for accountability.  Nor do you know who on the backend is working on your O365 deployment project.  Just too many unknowns to say it is secure.

O365/Azure Apps

But that's not the focus of this post.  A few weeks ago, O365 released the O365 APIs for Exchange (Mail, Contacts, Events and Files).  All of this piggybacks on Azure Active Directory for authorization utilizing the Consent Framework.  The Azure AD platform allows you to build an application that can make calls to Azure Active Directory or your O365 data. The permissions of the consent framework can allow an application to read the current mail item, all your mails items, your contacts, your calendar…your files. 

As a simple example, one of the more impressive abilities is to create a Mail App.  You can do this using Visual Studio 2013 and creating an App for Office project.  This isn't going to be a developer post so I'm not going to show you any code, but simply talk about the importance of "Mail Apps" and your users.

Once you have a Mail app created, you can deploy it to your O365 instance, or even post it in the Office store.   You can find a small set of mail apps in the following link (these have been publicly deployed to the office store, but you can have rogue apps that simply are registered somewhere in Azure AD and users give them ad hoc permissions):

http://office.microsoft.com/en-us/store/apps-for-outlook-FX102804983.aspx?app=outlook.exe

Many of these are poorly designed (for example, the LinkedIn app is a total disaster, the cert is locally generated and not even a public CA).  In some cases, you may find the deployment endpoint isn't even available so the app install fails.  If you were to install one of these apps, you will find that they simply request access to the "current" mail item.  This is the preferred scenario if you were to use these apps.  In some cases however, you may find that the app is given "carte blanche" to your entire mail inbox.

So back to users and mail apps.  When you are in your Outlook, your users will ultimately find the settings icon and this nice menu item called "Manage Apps":

 

Clicking on this, they will be taken to the "Exchange" app center.  This is where you see administrator installed apps and user installed apps:

 

This is JUST for Exchange.  This has nothing to do with the bigger picture of Azure AD Apps and the consent framework.  There are some governance controls implemented in the Exchange app architecture, however, when it comes to Azure AD and your tenant, the story hasn't been written yet. This goes back to the premise of this blog post.  All it takes to make your highly secure O365 environment to be unsecure is:

  • A user
  • An App
  • A click 

The permissions given to that app can now comprise the integrity of your entire system.  When on-premise, you at least had the ability to prevent incoming requests using your router and DMZ.  In this instance, O365 doesn't have any of that, so once permissions have been given, that's all folks.  So what hacking scenario might come up?

  • Hacker builds an Azure app, puts your company name and logo on it
  • Hacker does some social engineering to find out your name, title, work phone number and other information
  • Hacker asks you to install the app and because it has your logo and company info, your user thinks nothing of it and clicks "trust"
  • Hacker can now gain access to an access token that can be used to download all your email and your my site files

If you are in defense or government, you know hacking enemy number one is China.  For those of you that think that insensitive to say, you haven't watched the traffic logs with the FBI and CIA as it happens, almost on a daily basis.  But the US is not a good guy when it comes to that stuff either, so all is fair in love and war.

O365/Azure App Governance

It is my suggestion, that you disable the ability for users to add apps.  It simply creates security holes that equate to users writing company checks that can't be cashed.  So, with that recommendation, can I provide you the steps to deny a user the ability for users to add apps" in your tenant, *sure*, thanks to some recently surfaced info (see below) [:D] (thanks to @richdizz, @jthake and @Matthias1o1) In terms of Exchange, there are some user roles in Exchange that you can "remove" to prevent users from deploying apps, these roles are enabled by default:

 

————————
[UPDATE 6-5-2014] After this post the following was brought to my attention from the O365 team.  It is a non-UI based way to disable all user consent, thanks to the O365 team for pushing this content out!:

http://blogs.msdn.com/b/exchangedev/archive/2014/06/05/managing-user-consent-for-applications-using-office-365-apis.aspx

————————

Even with the above update, what is still not available to us is an Azure AD UI (to make it more apparent of the risk) that allows me to
disable apps, and/or designate a "safe/white list" of apps that my users *can* utilize in Exchange or Azure AD.

Just for kicks, I have created a UserVoice suggestion that more advanced App Governance features (such as a UI and white list) be added to Azure AD and O365, you can vote for it here:

http://officespdev.uservoice.com/forums/224641-general/suggestions/6010008-create-app-governance-in-o365-azure-ad

My God, What Have You Done?

So, this brings up an interesting point.  Last night at the SanSpug.org meeting I announced that we have moved to Auth0.com as our auth mechanism as it provides the most flexibility and telemetry data.  One person asked, what is telemetry data?  I said every time you login, I get data about you (first name, last name, email, blah blah).  It freaked out half the group.  Only one person was educated enough to know which of the supported auth systems had the least amount of data being sent.  So again, this brings up that interesting point I started this paragraph with…do you know what apps you have simply just clicked on the "authorize" button just so you could use the app?  I bet you don't, my god, what have you done?  Think about all those apps across all your services (facebook, twitter, liveid, google, etc).  So in an effort to help you understand just how bad this is going to get with O365, based on how bad it has gotten in a general sense, here is the links to where you can check what you have authorized for each of the major platforms:

Facebook:

https://www.facebook.com/settings?tab=applications

Twitter:

https://twitter.com/settings/applications

Google:

https://security.google.com/settings/security/permissions?pli=1

LiveID:

https://account.live.com/consent/Manage

eBay:

http://cgi6.ebay.com/ws/eBayISAPI.dll?ManageESubscriptions

Yammer:

https://www.yammer.com/YOURDOMAIN/account/applications

SharePoint:

I suppose you could say that this page (http://youweburl/_layouts/15/viewlsts.aspx) is as close as it gets?  At a farm level, in O365:

https://yourdomain-admin.sharepoint.com/_layouts/15/TA_AllAppPrincipals.aspx

On-premises:

http://centraladminurl/_admin/AllAppPrincipals.aspx

Azure AD:

https://myapps.microsoft.com

Back to the question…"My god, what have you done?"  After clicking on all those links, I'm sure you have an idea of just how bad the problem has gotten.  Some of you might be surprised to find out that your Hotmail/Outlook.com email and OneDrive (consumer) files have probably already been downloaded and analyzed by that cool app you gave permissions too.  Most of you that read my blogs are the cream of the intellectual crop.  You understand what that "Trust" dialog means.  For the rest of the population, not so much.  The meaning of the word "Trust" has been eroded by fancy graphics and the promise of a simple functionality at the expensive of selling your data soul to the app provider.  That all being said,  its time for enterprise solutions to have a "white list" to keep users from eroding the meaning of "Trust", to anyone's dog or cat.  One last thing on O365, no matter how secure you make the back end, its the front end that matters.

CJG

Posted on

Eliminate App Web Part IFRAME issues – Use App Installing

I have had a few different conversations with people about the whole App Web Part IFRAME problem lately.  Basically this problem means that you can't make calls outside the IFRAME using your code (it is a security feature of browsers).  This leads to the whole, "how limiting it is blah blah" conversation.  I simply say to them…why are you doing it like that? 

Most people think that using the App Model means that you are constrained to the boundaries that the App Model enforces.  The truth is, you are not.  If you are building useful "longtail" apps for companies, you should realize, the App Model doesn't need to be used as it was originally intended. You can utilize its deployment mechanisms to get your files to the host web.  This pattern is a part of one of the labs in the O365 Dev course.  For example, if you have a workflow that needs a well defined url for external communication (ie the random app web url won't work [think redirect urls]), you can deploy all of the content of the workflow to the host web and then run it from there (no app web needed at all, as a matter of fact, you could delete it completely after deploy).

How do you do this?  Use the App installing event handler.  As part of the App Model and the Visual Studio project, you can create an App installing event handling web which will get called and pass an access token to make calls back to the app and host webs.  Once you have that, the sky is the limit.  You don't have to deploy your code to the app web, but simply copy it from your web server to the host web.  In this essence, you are simply using the App Model as a "means to an end".  This will eliminate all your app web part IFRAME woes.