In Office 365, regardless if you are using ADFS or have configured a custom login screen (using Azure AD Free), you will still be presented with the standard Login Screen when for example accessing the Portal (portal.office.com) or SharePoint Online (tenant.sharepoint.com).
If using federation for single sign-on, entering the email address is enough to be redirected to your ADFS server. When using Synchronized Identities or Cloud Identities with a customized sign-in screen the process is similar, you will be redirected to your organizations login screen when you type the user name.
But what if we want to show our organizations branded login screen or ADFS login before the username is typed? Exchange Online has had this possibility since long, by using the URL https://outlook.com/tenant.onmicrosoft.com, but there is another solution that work for all Office 365 services.
Let’s start by looking on the URL you get redirected to when logging on to SharePoint Online:
There are two important parameters in this URL:
whr=tenant.onmicrosoft.com: This controls which login screen to use
wreply=https%3A%2F%2Ftenant%2Esharepoint%2Ecom%2F: The URL to redirect to after a successful logon (URL must be percent-encoded).
By replacing the whr and wreply parameters you can build your own links and deploy them in your organization, for example by setting the home page to point to your intranet in SharePoint Online. Regardless the method your organization are using for authentication, the users will now always be presented to the correct login page!
This blog post is reflecting how the process was made in early 2014, and has since then been replaced with built-in tools in ADConnect.
Some time ago Johan wrote a post about how to convert a federated domain to a standard domain in Office 365. Much has happened since, and one feature that has been added is to synchronize the passwords between on-premises Active Directory and Office 365.
An important reason to implement ADFS and federation is to keep all user passwords the same, to reduce support and Helpdesk calls. The drawback is that a high availability server (or even better, an ADFS farm distributed over several locations) is needed on-premises. If your internet connection is dropping, no-one will able to access Exchange or SharePoint even though it is located “in the Cloud”.
Now when Password Sync is available, some organizations choose to retire their ADFS servers to implement Password Sync instead. It is now possible to have the same password in all systems without those high availability servers.
The process to move to a non-federated state with Password Sync is similar to how Johan described the process, but to minimize the service interruption for your end-users there are a few things to think of. All steps below are performed on the server hosting the Azure Active Directory Sync tool.
- First of all you need to upgrade to the latest version of Azure Active Directory Sync tool. The upgrade process is simple; just uninstall the old version and install the new one. The installation may take a few minutes. Make sure that you check the Password Sync option during installation. End by running the Configuration Wizard.
- Check the Synchronization Service Manager (miisclient.exe) to make sure that the synchronization was successful. You may have to log off and log in again to be able to access Synchronization Service Manager.
- Time for PowerShell 🙂
#Connect to MSOnline
#Set context and credentials
Set-MsolADFSContext -Computer srv01
#From here on the Office 365 services will be unavailable
#for the end-users until all passwords are in in sync.
#This is where we change our federated domain to a standard domain.
#This command generates a text file with new random passwords for all users.
#In the next step we will replace these passwords with passwords synced from AD.
Convert-MSOLDomainToStandard -DomainName "mydomain.com" -SkipUserConversion $false -PasswordFile C:\userpwd.txt
#Make sure that all user passwords has ForceChangePassword flag set to False
Get-MsolUser -Synchronized | Set-MsolUserPassword -ForceChangePassword $false
- Now all users are converted. A file with new temporary passwords for each user is saved to the path you specified, but we will not use it. Instead, we now have to initialize a full password sync.
To see the status of the password sync you should check the Application Log in Event Viewer for event id 657. When all passwords are synchronised the users will be able to access their services again. This will take a few minutes depending on the number of users in your environment.
The idea with federation/ADFS combined with Office 365 is that you don’t have to care about changing/remembering passwords in multiple places.
Of course that is a good thing and the setup of ADFS is quite easy as long as you know your certificates and size the solution for redundancy.
A couple of days ago I ran in to a scenario where I needed to revert/disable federation for an Office 365 domain.
You do it with the Powershell module for Online Services (can be found on http://go.microsoft.com/fwlink/?linkid=236293).
First you connect to remote powershell with the following command where you will provide your administrative credentials for Office 365:
Then to change your domain back to a non-Federated state you simply type the command:
Convert-MsolDomainToStandard -DomainName example.com -PasswordFile c:\Passwords.txt
The command will convert all users to non federated ones and create a new password for them and put it in the file you specified with the “-PasswordFile” flag. It will also set the flag “ForceChangePassword” on the users to $true, so the users will have to change their own password after the first time they log on with the new one you provided from the file.
If something goes wrong with the conversion of the users when running the conversion command above you may have to convert the users manually to non-federated ones with the “Convert-MsolFederatedUser -UserPrincipalName ” cmdlet.