Learn why Alternate Login ID is Office 365's hidden gem

Not familiar with the Alternate Login ID feature? You should be. It could save you valuable time during an Office 365 migration.

Alternate Login ID allows organizations to skip some of the more time-consuming aspects of enabling end users to...

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 steve@stevieg.org but the UPN is Steve.Goodman@stevieg.local (Figure 1).

Different email and UPN
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).

Incorrect login name in Office 365 portal
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 steve@stevieg.org, in this scenario (Figure 3).

Update end user's UPN value
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.

  1. The client provides a username and password to the on-premises Autodiscover endpoint.
  2. After a successful login, Exchange redirects the client to Office 365.
  3. The client provides a username and password to the Office 365 Autodiscover endpoint.
  4. 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.

Windows username for Exchange login
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).

Autodiscover results
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. 
 

This was last published in June 2014

Dig Deeper on MS Office 365

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

3 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Hi Steve, this is a part of our current Office365 that has confused me a lot (UPN). We are a medium org planning to migrate 20,000+ accounts to Office365 and our current AD UPN is a non internet routable address. We configured DirSync to use the mail attribute for the UPN in Office365 and thought that would be the end of it, but it appears that is not the case. Are you saying for the best experience, the UPN in AD needs to match the email address, meaning that authentication in step1 to on premise exchange will work (by authenticating with UPN) and then authentication to Office365 will flow through as well (because it will match the Office365 UPN)? Being an education org, we have email formats of first.last@domain.edu.au for staff and username@utas.edu.au for student accounts. It would be good to understand what is required to give the most seamless experience to end users, and autodiscover would be one of the things that we wouldn't want the end user to have to intervene with ('auto' being a key bit :) ) Cheers, Matt.
Cancel
Hi Matt, yes - alternate login ID is new and whilst good you need to be aware of its limitations. The best approach where you can is to change the UPN, and this is the approach that has been tried and tested on many, many deployments. Steve
Cancel
Hi,
our in house security team are currently preventing us from rolling out Office 365 to BYOD devices as they don't want users entering their AD credentials on non managed endpoints. Is there a way to use this functionality to get around this problem?
Cancel

-ADS BY GOOGLE

SearchWindowsServer

SearchEnterpriseDesktop

SearchCloudComputing

SearchSQLServer

Close