Federation

SharePoint Online & Sign-In Acceleration – SSO for SPO

Posted on

SPO

For those using SharePoint Online, you may have noticed that it does not provide the same home realm discovery that Exchange Online does, with Home Realm discovery meaning the services knows what domain/upn is being used and leveraging that authentication type for the user (Managed/Online versus Federated/ADFS).  SharePoint Online support now supports Sign-In Acceleration, which allows SPO to understand whether a browsing user is a Federated user and send to https://login.microsoftonline.com, with a directive that instructs login.microsoftonline.com to then forward the authentication request on to their ADFS deployed endpoint (i.e. https://sts.contoso.com).

Note – To enable this for your Office 365 tenant, please log a support case for this request and they can fulfill your request!

Explanation

Once auto-acceleration is enabled, the SPO authentication process works as follows:

  1. The user navigates to https://contoso.sharepoint.com in their web browser.
  2. SharePoint receives the request and detects that auto-acceleration is enabled for this tenant by leveraging the domain name in the domain.sharepoint.com URL being used to access SPO.
  3. The user is then sent to login.microsoftonline.com with extra information in the URL (a whr tag). This tag indicates to AAD that it is safe to accelerate the user directly to the ADFS endpoint, login.contoso.com.
  4. Once there, the user may enter their credentials and sign-in. In the case of domain-joined machines, the user will be signed in immediately based on browser settings for SSO.

This effectively allows SPO to provide home realm discovery and SSO for users, like Exchange Online does today and will make your SPO users much more happy, reducing the authentication prompts and requests for UPNs/Passwords.

ADFS CAP & Limiting Mail Client Access – Thunderbird/IMAP Mishap

Posted on

For you Exchange Online / ADFS Administrators who have to support your older IMAP clients, you may have had to wrangle with your ADFS deployment, specific the Client Access Policy (CAP) settings, which limit which users/devices can use the ADFS Services.

Many times ADFS is deployed internally, so users MUST be on the corporate network in order to access the server. The default ADFS Token Issuance rule states that any authenticated user can use the server/ADFS service, however there is the ability to define Client Access Policies (CAP) which have a more granular approach, on who/what/where these users must be or conform before they are allowed access.

There are many sites and articles on how the use the ADFS CAP rules, one of particular note is the Client Access Policy Builder, created by a Microsoft person, which is a graphical UI that helps in defining these conditions and requirements for accessing ADFS.  If you are looking to create and use an ADFS CAP setting, you should definitely review all available material BEFORE turning on this feature, as I found, it can be tricky:

ADFS Client Access Policy Builder

Sample ADFS CAP Entry

Rule to allow Autodiscover, ActiveSync and POPIMAP Access when coming through ADFS-Proxy, which covers Exchange Online.

exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy”%5D)
exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path”, Value == “/adfs/services/trust/2005/usernamemixed”])
&& NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value == “Microsoft.Exchange.ActiveSync”])
&& NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value == “Microsoft.Exchange.Autodiscover”])
&& NOT exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application”, Value == “Microsoft.Exchange.POPIMAP”])
&& exists([Type == “http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip&#8221;, Value =~ “”<NEED any Internal and EXO and O365 IP Addresses HERE>”])
=> issue(Type = “http://schemas.microsoft.com/authorization/claims/deny&#8221;, Value = “true”);

When defining the CAP you will find that you can define different applications, connections, etc.  I found that while allowing Microsoft.Exchange.Autodiscover and Microsoft.Exchange.ActiveSync, I did NOT define Microsoft.Exchange.POPIMAP, which stopped my Thunderbird IMAP clients from obtaining authorization and authentication.  As a result Thunderbird seemingly connects into an Exchange Online MBX, however their LIST request for the different folders errors with Bad or Invalid Data.  As a result the issue appears to be a Protocol/EXO services issue, when in fact ADFS is failing to allow the user to authenticate.

SO if you are going to use ADFS CAP AND you are defining entries for Microsoft.Exchange.ActiveSync and other items and you will be using POPIMAP, then you must also enter the Microsoft.Exchange.POPIMAP entry as well, otherwise the IMAP client will fail during connectivity but show that is has authenticated without issue….very strange.

 

 

Replacing ADFS 2.0 Secure Communications Certificate – “The Certificate Cannot Be Processed”

Posted on Updated on

For all Office 365 Active Directory Federation Services (ADFS) administrators, you may find that your ADFS “Secure Communications” certificate has expired and needs to be replaced or you need to replace the certificate and having issues replacing.  Many times administrators will start with an internal Certificate Authority (CA) cert and later upgrade to a public certificate, in order to support users with Outlook or other rich applications.

Whatever the reason, there are a few things you need to think about when performing this task:

  1. The Active Directory Federation Services MMC (UI) can be used to set the “Secure Communications” certificate by doing the following:
    1. Expand the ADFS –> Service –> Certificates node and right-click the certificates folder and select: Set Service Communications certificate option, which sets the certificate applied to your IIS default website as the secure communications certificate for use in ADFS.
      1. Note – You will be presented with all viable certificates in the Local Machine –> Personal –> Certificates store.
    2. Select the proper certificate presented and click OK

Note – I attempted this in my lab environment, however I had to rekey my certificate and the old certificate had been revoked.  Because of this, I believe the above steps failed with the following error, which forced me to use PowerShell to set the proper certificate while clearing out my old certificate.

Attempt to Set Secure Communications Certificate

set-secure_comms

Steps to Resolve

  1. Remove the old certificate from the Local Machine –> Personal –> Certificates store
  2. Import new certificate using IIS –> Import Certificate
    1. Place into the Local Machine –> Personal –> Certificate store
  3. Manage Certificates –> Manage Private Keys –> Grant read (I gave the ADFS AppPool identity Full Access)
  4. Launch PowerShell
    1. Add-PSSnapin Microsoft.ADFS.PowerShell
    2. Set-ADFSCertificate –CertificateType Secure-Communications –Thumbprint “e3 r 45 d4 5t 7u 8i 3e”
      1. Note:  Turns out the –CertificateType string is NOT enclosed in quotations while –Thumbprint is.  I had this backwards and the error states that “-CertificateTYpe is invalid”.  This is wrong, it was which string was wrapped in quotes.
          • Error Message if you enclose the wrong string in quotations:
            1. adfs_invalid_certType
        1. Example using PowerShell 3.0 ISE, which is an outstanding tool for working in PowerShell
          • set-secure_communications-success
  5. Restart IIS and ADFS Services
    1. IISReset
    2. ADFS 2.0 Service Restart
  6. Launch the ADFS 2.0 MMC –> Services –> Certificates and verify that the new certificate is listed
  7. Launch the Microsoft Online Windows PowerShell and update the Microsoft Federation Gateway with the new certificate and thumbprint
    1. Download and install Online PowerShell: https://portal.microsoftonline.com/IdentityFederation/IdentityFederation.aspx
    2. Launch and connect to Microsoft Online Services:  connect-MSOLService
      1. Note: Enter your online Global Admin credentials
    3. Update MFG with new certificate information:
      1. Update-MSOLFederatedDomain -DomainName <domainName.com>
    4. Check that the new certificate information, such as Thumbprint has been uploaded into the cloud:
      1. Get-MSOLFederationProperty -DomainName <domainName.com>

AND TEST…you should be set and ready to go!

Being Prompted for Username/Password After Office 365 ADFS is Deployed?

Posted on Updated on

Problem

When your administrator deploys Active Directory Federation Services (ADFS) for use in Office 365, you were told that you would no longer need to provide separate username’s and passwords, as your Active Directory credentials (username/password) can be used instead.  However when you attempt to access OWA, SharePoint or other online services, you are prompted to enter your username and password, potentially multiple times, such as when accessing the Microsoft Online Portal (MOP) [enter UPN, get redirected to ADFS and enter username/password].

Reason

This is due to your Internet Explorer not having the ADFS endpoint, such as sts.contoso.com, added to the Intranet Security Zone setting.  IE sees sts.contoso.com as an Internet address, falling into the Internet security zone, which does not automatically release/send username/password or the logged on user.

Resolution

To resolve this issue you must add your ADFS endpoint into this IE Intranet Security Zone location.

Internet Explorer

  1. Tools
  2. Internet Options
  3. Security
  4. Local Intranet –> Sites
  5. Advanced
  6. Add this website to the listhttps://*.contoso.com
  7. OK all the way out of this IE setting

Test

  1. Close all Internet Explorer browsers
  2. Login to the Office 365 Online Portal (MOP): https://portal.microsoftonline.com
  3. Enter your login User Principal Name (UPN) and notice that you are not able to enter password, instead click the link to login using ADFS

At this point, your browser is redirected to your local ADFS endpoint for Active Directory authentication.  With the IE setting in place, your machine logged in credentials are passed to ADFS, you are authenticated and redirected back to the Online Portal (MOP) and granted access!

Office 365, ADFS & Client Access Policies – Restrict Office 365 User Authentication via ADFS

Posted on Updated on

As Office 365 tenants start to use Active Directory Federation Services (ADFS) with Office 365 to allow AD users to access online (Office 365) using their domain accounts.  ADFS is installed by default to allow all users with an active AD account to use it’s authentication services.  However many admins have found that they would like to restrict ADFS usability/access and limit who can use this particular service.  The ADFS Client Access Policy Builder in conjunction with an ADFS Hotfix Rollup provides just such functionality.  To learn more about how to download the .ps1 PowerShell script and information on what variables/options are available:

Understanding Active Directory Federation Services (ADFS) Authentication

Posted on Updated on

As you move into Office 365 and decide that you would rather use Active Directory to authenticate, as opposed to using a separate username and password (ala Online Identity), you may need to explain this authentication process to other IT Admins and end-users.  The following Microsoft Knowledge Base article does a great job of explaining this process, which will hopefully help you in explaining this to your end-users and admins.  Many times explaining not only how the authentication process works BUT how this can help reduce admin tasks of online user password resets and login management will help move a company from using Online Identities to Active Directory identities, SIGNIFICANTLY reducing this task!

Source:  http://support.microsoft.com/kb/2565539

To learn more about the full capabilities of ADFS 2.0 and Office 365 please review the new Office 365 Single Sign-On with AD FS 2.0 whitepaper, which describes in great detail the services, installation, configuration and usage:  http://www.microsoft.com/download/en/details.aspx?id=28971

Posted on Updated on

Great option for those in the cloud who would like to extend their Messaging capabilities by Federating with other Exchange Online tenants, providing the possibility to view Free/Busy and other information of others outside your Messaging environment.