?
Solved

Exchange 2010 Disjoint Namespace and user authentication in Outlook

Posted on 2012-09-15
10
Medium Priority
?
1,594 Views
Last Modified: 2012-09-24
Hello Exchange adminstrators!  Looking some direction on an Exchange Disjoint Namespace and user authentication.  For example I have an internal domain "domain.local" and a couple of e-mail domains "domain.com" & "domain2.com".  Autodiscover is configured and working with "autodiscover.domain.com" and half of my users use "domain.com" as a primary e-amil domain, but the other half use "domain2.com" as their primary.

First question: I have to instruct all users to enter the "username@doamin.com" e-mail address in order for Autodiscover to successfully configure their mail client.  Even users that have the "domain2.com" for a primary e-mail domain.  This isn't really a huge deal, just ends up being confusing for the end user and usually results in a 30 second support call.  Anyway to configure Autodiscover to function with multiple domains with only one CAS server?  Other suggestions?

Second question: Another issue with a Disjoint Namespace is that during the Outlook configuration the user will be prompted for credentials in Outlook a second time and if they do not use the "domain.local\username" format, they don't get Outlook configured and will be prompted repetedly for creds.  Again the user will attempt to just enter their e-mail address here and it results in a 30 second support call.  I've seen some situations where administrators have added an "Alternative UPN suffix" in AD Domainsand Trusts.  Then went to each user and configured the new domain as their primary authentication domain.  What is the recommended way to deal with this?
0
Comment
Question by:4roi
  • 4
  • 4
  • 2
10 Comments
 
LVL 5

Expert Comment

by:elevationkevin
ID: 38402670
0
 
LVL 5

Expert Comment

by:elevationkevin
ID: 38402674
0
 
LVL 63

Expert Comment

by:Simon Butler (Sembee)
ID: 38405237
Autodiscover internally, for domain clients works differently for external clients that cannot see the domain, or are not members of the domain.

Internally they will use the value from get-clientaccessserver for AutodiscoverInternalServiceURI. The host name in that value MUST resolve internally and MUST be on the SSL certificate.

By using a split DNS system you can make it anything that you like, so if you want to use autodiscover.example.com because that is on the SSL certificate, then you can do so.

Externally, cleints will use a nubmer of predefined URLs - the most common one to use is autodiscover.example.com - where example.com is the doamin in their email address. If you have multiple domains on the server that isn't an issue, you either need to have autodiscover.example.com and autodiscover.example2.com on the certificate, or use one of the methods to redirect the traffic - which depends on the DNS provider for your external name.

Not really sure what you are asking in the second part of the question.
Changing the UPN value to match the email address is pretty common, as it makes it easy to tell the users to login with their email address. Done it loads of times before and it is very successful. What is the actual question there though? How to make the change?

Simon.
0
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

 

Author Comment

by:4roi
ID: 38425035
Simon,

Thank you for the follow-up.  Let me elaborate a little on each point.

** Oringinal Post: First question: I have to instruct all users to enter the "username@doamin.com" e-mail address in order for Autodiscover to successfully configure their mail client.  Even users that have the "domain2.com" for a primary e-mail domain.  This isn't really a huge deal, just ends up being confusing for the end user and usually results in a 30 second support call.  Anyway to configure Autodiscover to function with multiple domains with only one CAS server?  Other suggestions?

** New Comments: I think where I am confused here is that when you configure Autodiscover on your CAS role, you have to specify an FQDN.  that FQDN I was under the impression had to be used in order for Autodiscover to function.  so for example I configure an Autodiscover address as "autodiscover.domain.com".  My end user has an e-mail alias of "username@domain2.com".  I assumed that I would have to tell them to configure Outlook using the "username@domain.com" instead of "username@domain2.com" because I had configured Autodiscover for the "mail.doamin.com".

If I read your comments correctly, you are saying that I can setup a public A record for "Autodiscover.domain2.com" even though my CAS is setup for "Autodiscover.domain.com"?  I just need to ensure that domain2.com's record is configured to the correct IP and that the FQDN for "Autodiscover.domain2.com" is on the certificate to keep from seeing a cert related error on the client....  Am I tracking here?

** Original Post: Second question: Another issue with a Disjoint Namespace is that during the Outlook configuration the user will be prompted for credentials in Outlook a second time and if they do not use the "domain.local\username" format, they don't get Outlook configured and will be prompted repetedly for creds.  Again the user will attempt to just enter their e-mail address here and it results in a 30 second support call.  I've seen some situations where administrators have added an "Alternative UPN suffix" in AD Domainsand Trusts.  Then went to each user and configured the new domain as their primary authentication domain.  What is the recommended way to deal with this?

** New Comments: I think I may have this one figured out.  I basically have just addd a new DNS Suffix to the AD domain and configured the specific user account to use the preferred suffix.  This allows the user to now use the e-mail address to authenticate rather than having to enter the internal domain alias.  I have tested this.

However, when I originally referenced the "disjoint" namespace, I think I may have been referencing a different issue all together.  I've been reading up on the termin Microsoft Uses called "Disjoint Namespace" and this is what I get for a deffinition.

~~~~~~~~~~~~~~~~~~~~~~~~~
"By default, the primary Domain Name System (DNS) suffix portion of a computer's fully qualified domain name (FQDN) is the same as the name of the Active Directory domain where the computer is located. When the primary DNS suffix portion of a computer's FQDN is different from the Active Directory domain where the computer is located, this is known as a disjoint namespace."
~~~~~~~~~~~~~~~~~~~~~~~~~

So my follow up question here is, what would cause the computers name FQDN to be different than the AD domain?  Is this an example of a different domain in the same forest possibly?  Where the internal domain name for one AD environment might be doamin.local vs the other domain located in the same forest is domain2.local?  Or perhaps it also applies to child domains?  Where the exchange server resides in the child "child.domain.local domain where the users reside in "domain.local?

Any clarification you can provide here would be great.  Thank you.
0
 
LVL 63

Assisted Solution

by:Simon Butler (Sembee)
Simon Butler (Sembee) earned 2000 total points
ID: 38426259
You are confusing URLs I think.
There is no place to specific an autodiscover URL for certain domains. If you have been setting on on set-autodiscovervirtualdirectory then you have been wasting your time.

Autodiscover works in one of two ways only.

Method 1: If the machine is on the domain AND can communicate with the domain controller (so is on the LAN), then it will query the domain for an autodiscover service value. This value is set on the ClientAccessServer role, and can be seen via
get-clientaccessserver | select Name, AutodiscoverServiceInternalURI

This is completely independent of the domain name in the user's email address.

Method 2: If the machine is on the Internet OR is not a member of the domain, then it will query predefined URLs. These cannot be changed.

In both cases, Outlook will attempt to make a connection on HTTPS, so the URLs involved need to be in the SSL certificate. When it comes to Autodiscover, there is nothing to configure URL wise for different domains - Exchange simply doesn't care about them. As long as they are in the SSL certificate, allowing the client to connect successfully, then Exchange will find the user from their email address and configure as appropriate.

That is it. You can have as many domains as you like, as long as the SSL certificate and DNS records are setup correctly. Obviously if you are hosting 20 domains then an SSL certificate can get expensive, so Microsoft have provided other methods to allow the client to connect to an SSL certificate in another domain, using either SRV record in DNS or a redirect.

On the second question, I have never seen a computer's FQDN different to the AD FQDN, so I cannot answer any further on that.

Simon.
0
 

Author Comment

by:4roi
ID: 38426654
Thanks Simon, I think we're getting there.  2 follow up questions.

1: Could you elaborate some on SRV and TXT records in pubilc DNS and how they would make the name on the SSL cert not make a difference?

2: When I refer to setting an FQDN for Autodiscover, I am talking about when you are in the EMC GUI, under Server Configuration>Client Access> "right click CAS server & select properties">Select Outlook Anywhere tab.

Here it asks you to set the External Hostname.  I assumed this was for Autodiscover also.  Can you explain the difference and why this seems to contradict what you've explained above.  I am sure this is where I am confused.  Thanks again.
0
 
LVL 63

Assisted Solution

by:Simon Butler (Sembee)
Simon Butler (Sembee) earned 2000 total points
ID: 38426918
Autodiscover is NOT Outlook Anywhere. They are two different things. Outlook Anywhere configuration is delivered to the clients by Autodiscover, but the client has to find the server via Autodiscover to being with.
Effectively the internal and external host name set in Exchange are there to tell Autodiscover what to tell the clients.

Autodiscover with SRV records: http://support.microsoft.com/kb/940881

Simon.
0
 

Author Comment

by:4roi
ID: 38427321
Ah, I've got it now.  As long as "Outlook" for example can find the Autodiscover virtual directory, it will pick up the Outlook Anwhere settings you've put in place.  Even if the Outlook Anywhere domain happens to be different from the e-mail address domain.  You just need to ensure that you create an autodiscover record for each domain or rely on TXT/SRV records.

So I am using GoDaddy for example.  What data would I put in for a TXT or SRV record?  The inforamtion does not have to be on the certificate?  Outlook will not throw cert errors?
0
 
LVL 63

Accepted Solution

by:
Simon Butler (Sembee) earned 2000 total points
ID: 38428696
Who the DNS host is doesn't matter. As long as the records are configured as per the KB article, and point to a host name which is on the SSL certificate then you are fine.

For example, if the SSL certificate autodiscover.example.com on it, then in the SRV record for example.net you could put in autodiscover.example.com as the host.

Simon.
0
 

Author Closing Comment

by:4roi
ID: 38428730
Great detail.  This cleared it up.
0

Featured Post

NFR key for Veeam Agent for Linux

Veeam is happy to provide a free NFR license for one year.  It allows for the non‑production use and valid for five workstations and two servers. Veeam Agent for Linux is a simple backup tool for your Linux installations, both on‑premises and in the public cloud.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Here in this article, you will get a step by step guidance on how to restore an Exchange database to a recovery database. Get a brief on Recovery Database and how it can be used to restore Exchange database in this section!
Last month Marc Laliberte, WatchGuard’s Senior Threat Analyst, contributed reviewed the three major email authentication anti-phishing technology standards: SPF, DKIM, and DMARC. Learn more in part 2 of the series originally posted in Cyber Defense …
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller. Log onto the new domain controller with a user account t…
Established in 1997, Technology Architects has become one of the most reputable technology solutions companies in the country. TA have been providing businesses with cost effective state-of-the-art solutions and unparalleled service that is designed…
Suggested Courses

862 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question