Domain Management

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.

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!

Attempting to Convert Office 365 Domain to Federated May Result In: Microsoft.Online.Administration.Automation.IdentityInternalServiceException

Posted on

Problem

When an Office 365 administrator attempts to convert their Office 365 “Managed” Domain, with user credentials stored in the cloud, to Federated, where authentication and credentials are stored in an on-premises Active Directory, you may run into the following error:

Convert-MSOLDomainToFederated : Microsoft.Online.Administration.Automation.IdentityInternalServiceException

At line:1 char:30

+ Convert-MSOLDomainToFederated <<<<

+ CategoryInfo : notSpecified: (:) [Convert-MSOLDomainToFederated]

, FederationException

+ FullyQualifiedErrorId: Microsoft.Online.Administration.Automatition.IdentityInternetServiceException, Microsoft.Online.Identity.Federation.PowerShell.ConvertDomainToFederated

 

Possible Reason

Administrators may have modified the PasswordExpirationPolicy, which defines how long online user passwords can exist before being forced to change the password.  However, the maximum setting for this is 720 and if this setting is > 720, you will hit this error!

Resolution

  1. Change the Online Tenant’s PasswordExpirationPolicy to something less than 720, using the following PowerShell command(s)
    1. Install and Connect to Office 365 via Windows PowerShell for Online Services:  http://technet.microsoft.com/en-us/library/jj151814.aspx
      1. Login using an online tenant Global Administrator
  2. Run the following PowerShell Command
    1. C:\PS>Set-MsolPasswordPolicy -ValidityPeriod 90 -NotificationDays 14 -DomainName contoso.com
      1. Note – This command updates the policy on the domain contoso.com so that users passwords will expire after 60 days and that the users will receive notification of 14 days prior to expiration.
  3. Once the PasswordExpirationPolicy has been updated, wait ~20 minutes, then attempt to convert the Managed Domain to Federated, using the following:
    1. Convert-MsolDomainToFederated -DomainName contoso.com -SupportMultipleDomain
      1. Note – Only use -SupportMultipleDomain IF you need to support separate/different/distinct UPN namespaces, such as contoso.com & fabrikam.com. You will need to run the above command twice, each time for the different domain namespace with the -SupportMultipleDomain parameter.

 

SUCCESS!!!!