Office 365 SSO w/ Horizon Workspace 1.8.0/1.8.1

[RabbiX]

Has anyone actually been able to successfully configure Office 365 SSO with Horizon Workspace?  I have configured the provided "Office 365 Outlook" from the VMware Cloud Application Catalogue, only adding my activated Office 365 domain to the value field  for {tenant} under Application Parameters.  I do have SSO working successfully in other Webapps like Google Apps without issues.

Below are my test results from using the Office 365 SSO test from: https://testconnectivity.microsoft.com

The results to me, point to something internally wrong in the metadata that I have no control over (I have modified the actual domain...).

Testing Single sign-on for user: testuser@mydomain.com.
	Single sign-on test failed.
	Additional Details
	Test Steps The Microsoft Connectivity Analyzer is attempting to retrieve domain registration and to validate federation status information for user testuser@mydomain.com. Domain registration was retrieved and validated successfully. Test Steps Attempting to resolve the host name externalurl.mydomain.com in DNS. The host name resolved successfully. Additional Details Testing TCP port 443 on host externalurl.mydomain.com to ensure it's listening and open. The port was opened successfully. Additional Details Testing the SSL certificate to make sure it's valid. The certificate passed all validation requirements. Test Steps Validating ADFS metadata for the on-premises ADFS server. There was a problem validating the ADFS metadata. Test Steps Retrieving ADFS metadata information from metadata exchange URL https://externalurl.mydomain.com/SAAS/auth/wsfed/services/mex. Successfully retrieved ADFS metadata. Additional Details Analyzing the ADFS metadata document for configuration problems. Errors were found while analyzing the ADFS metadata document. Additional Details The Integrated Windows authentication endpoint is missing on the internal metadata document. Elapsed Time: 1 ms.

This is the actual command run against my office 365 pod to setup federation for reference:

Set-MsolDomainAuthentication -DomainName mydomain.com -Authentication Federated -IssuerURi https://externalurl.mydomain.com/SAAS/API/1.0/GET/metadata/idp.xml -FederationBrandName 'mydomain' -PassiveLogOnUri https://externalurl.mydomain.com/SAAS/API/1.0/POST/sso -LogOffUri https:/externalurl.mydomain.com/SAAS/auth/logout -ActiveLogOnUri https://externalurl.mydomain.com/SAAS/auth/wsfed/active/logon -MetadataExchangeUri https://externalurl.mydomain.com/SAAS/auth/wsfed/services/mex -SigningCertificate <SAML Cert Goes Here....>

The release notes for Horizon Workspace 1.8.1 additional say this:

Office 365 Resolved Issues

• Horizon Workspace administrators can now configure the "issuer_uri" attribute for Office 365 applications. Replace your existing Office 365 applications with the new versions published on the cloud application catalog.
• Fixed Office 365 active profile authentication issues.

From what I see though, there is no new application actually available...

Attached full results of the test, only modifying identifying information.

[RabbiX]

I actually finally got this working after banging my head against the wall for the past few days.

For the command: Set-MsolDomainAuthentication the switch "IssuerURi" was wrong.  Honestly I had no idea what I was suppose to set it to, although It turned out being fairly straightforward.

It seems that if your external URL (Horizon Workspace FQDN set in the configurator-va) is, https://externalurl.mydomain.com, then the "IssuerURi" is just "externalurl".

(This is also seen in the very top right hand corner when logged into the "VMware Horizon - Dashboard")

Hopefully this info ends up helping someone else.

[RabbiX]

Seems that regardless of me getting SSO working through the SaaS application from Workstation, it doesn't matter because it breaks access to all rich clients (Outlook 2013, Apple Mail (Desktop/iPhone).

Setting the password on the SaaS application as instructed does nothing to mitigate this problem.  Since this is in the official documentation as a working solution, has anyone else gotten past these problems?

[Linjo]

Please open a Support Ticket with VMware Support.

[RabbiX]

I think I finally got the issues with the rich clients worked out.  The accounts that were setup for testing had different UPNs vs their primary SMTP address.  Since the email addresses in this case were already what was desired, I changed the account names in AD to match them, then manually changed the UPN of the synced account in office 365 using: Windows Azure cmdlet:  Set-MsolUserPrincipalName.  Finally I performed another DirSync, and in about 15 mins or so, SSO with Outlook 2013 and iOS Mail started working.  The Apple OS X native Mail client still doesn't work, but since it is not listed on VMware's documentation as a "Supported Client", I will just infer that this one is a lost cause.

I think in most cases the UPN and primary SMTP addresses would already be the same, but I can think of situations where a company could easily break this for an account, such as a  user getting married/divorced and wants their primary email addressed changed (assuming that most organizations don't bother changing the actual AD account name since it can be a bit of a PITA on the client end in some situations).

Anyways its been working for about 12 hours now...so I'll keep my fingers crossed.