Alternate Login ID allows organizations to skip some of the more time-consuming aspects of enabling end users to...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
log into Office 365.This tip from Exchange MVP Steve Goodman looks at why Alternate Login ID could be the answer to some Active Directory problems associated with Office 365 migrations, where it's appropriate to use during your migration and some downsides organizations need to know before installing it.
In many organizations, Active Directory was set up before Office 365 existed. Current typical practices mean the login IDs for the domain aren't necessarily compatible with the strict requirements for Office 365 login IDs.
This may happen when the User Principal Name (UPN) doesn't use an Internet-routable domain name and doesn't match the end user's email address. For example, this can be seen if the email address is email@example.com but the UPN is Steve.Goodman@stevieg.local (Figure 1).
Figure 1. Compatibility issues may arise because of current practices.
When this occurs, we'll encounter problems that need to be fixed when we use the Windows Azure Directory Sync Tool (DirSync). The login name will show incorrectly in the Office 365 portal and use the tenant name -- stevegoodman.onmicrosoft.com, for example (Figure 2).
Figure 2. Some of these issues may come up when using DirSync.
This prevents us from giving end users their proper login ID, which is something they should already know (like their email addresses). This also means we can't use Active Directory Federation Services (AD FS) to allow single sign-on with AD.
The typical method to fix this is fairly straightforward. You would add an alternative UPN suffix in Active Directory Domains and Trusts and then update the user's UPN value, from Steve.Goodman@stevieg.local to firstname.lastname@example.org, in this scenario (Figure 3).
Figure 3. The method to fix this particular problem is pretty straightforward.
This is a straightforward change for many organizations as end users still continue to use the pre-Windows 2000 login name format of DOMAIN\username. However, it's a big change to make and requires discovery, validation and testing to make sure the change won't affect anything.
Where Alternate Login ID can help
Even though it makes sense to update the UPN value to use an Internet-routable domain (and ideally the email address), there's a way around this prerequisite with Alternate Login ID.
Alternate Login ID allows you to switch and use a different Active Directory attribute as the Office 365 login ID, which will typically be the email address.
This means if you are looking to pilot mailboxes in Office 365, or initially consume only certain services such as Lync Online, SharePoint Online, Yammer or OneDrive, then Alternate Login ID could enable you to quickly get up and running and avoid updating UPNs for end users before you begin.
What's not so great about Alternate Login ID
There are some downsides to Alternate Login ID whereby, if you implement it, you will probably want to update UPN values before your main migration.
In particular, Alternate Login ID can cause an issue with a hybrid Exchange environment or a staged migration. These issues are particularly apparent during a migration or in long-term hybrid Exchange when the Autodiscover service still (correctly) points to on-premises servers.
The login process causes this issue.
- The client provides a username and password to the on-premises Autodiscover endpoint.
- After a successful login, Exchange redirects the client to Office 365.
- The client provides a username and password to the Office 365 Autodiscover endpoint.
- After successful login, Office 365 provides an XML response with server details.
This may not be an issue for a domain-joined machine because it will use Windows Integrated Authentication to log into the on-premises Exchange server; the Alternate Login ID will then be used when accessing Office 365.
For a non-domain-joined PC or another client (like an ActiveSync device), the process will fail at either step one or step three.
If we attempt Autodiscover using the Alternate Login ID, it will fail at Step 1 (Figure 4), because you cannot log into an Exchange Server without actually providing a real Windows username.
Figure 4. You'll experience failure at step 1 if you attempt Autodiscover with Alternate Login ID.
If we attempted Autodiscover using the UPN accompanied by an email address for Autodiscover, we can log into Exchange and successfully redirect to Office 365 but fail to log in to Office 365 using the UPN (Figure 5).
Figure 5. It's possible to log into Exchange and redirect to Office 365 but fail logging into Office 365 with the UPN.
For most migrations, this means that, although Alternate Login ID will quickly get the pilot off the ground, you'll still need to plan UPN updates before migrating mailboxes en masse to Office 365.
This only affects non-domain-joined PCs, and the server name (outlook.office365.com) can be specified for ActiveSync clients; this doesn't necessarily present a major issue for a pilot. And it certainly doesn't prevent the use of other services such as Lync Online, SharePoint and OneDrive.
This concludes part one of our series introducing Alternate Login ID. Stay tuned for part two, which covers the prerequisites for using Alternate Login ID and how to configure it.
About the author:
Steve Goodman is an Exchange MVP and works as a technical architect for one of the U.K.'s leading Microsoft Gold partners. Goodman has worked extensively with Microsoft Exchange since version 5.5 and with Office 365 since its origins in Exchange Labs and Live@EDU.