Credential Mismatch Due to Reply-To Address Not Matching User Name
-
2 februarie 2012 22:55
Background: I am set up on a large academic campus. The main campus IT department uses university.edu. My domain is college.university.edu and is completely separate from university.edu. Our email is complicated. Everyone on campus can get an username@university.edu email address which is managed by the main campus IT. However, for most of my users, it's just an external contact pointing to their username@college.university.edu mailbox on my Exchange server. For those users who want to use the campus address, I set their reply-to to username@university.edu.
When they log into my Lync server, they use username@college.university.edu. This worked great until the main campus IT created an SRV record for their own domain. Now, whenever one of my people logs into Lync, they get this logon prompt:
Lync - Services Sign In
Credentials are required
Type your user name and password to connect for retrieving calendar data from Outlook.
If the user puts in his password and clicks ok, the window just blinks. You can click Cancel and Lync works with a few exceptions. It doesn't save conversation history in Lync, only in Outlook. And the status bar at the bottom of the Lync window shows an error:
Lync cannot connect to the Exchange server. To restore this connection, please try signing out and signing back in. Until the connection is restored, history, voice mail and Outlook-related features will be unavailable.
Looking at the Communicator-uccapi-0.uccapilog file, it appears that Lync is attempting to connect to an Exchange server that matches the reply-to address (username@university.edu), instead of the account or user name (username@college.university.edu). Here's an excerpt:
<category name="calendarData" instance="1387935970" publishTime="2012-02-02T14:27:12.283" container="400" version="5" expireType="time" expires="63257"> <calendarData xmlns="http://schemas.microsoft.com/2006/09 /sip/calendarData" mailboxID="username@university.edu"><freeBusy startTime="2012-02-01T06:00:00Z" granularity="PT15M" encodingVersion="1">AAAAAAAAAAAAAAAAAAAAoKoKAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA</fre eBusy></calendarData> </category>
I have no control or input over what srv records the main university creates for their own domain name. How can I force Lync to ignore the reply-to address and only authenticate using the username that I give it?
- Editat de reprac 7 februarie 2012 20:23 correction
Toate mesajele
-
3 februarie 2012 21:22
I tried using the hosts file to redirect all of these to our local server, but that didn't fool Lync:
_sip._tls.university.edu
_sip._tcp.university.edu
_autodiscover._tcp.university.edu
_autodiscover_._tcp.university.edu
_sipinternaltls._tcp.university.edu- Editat de reprac 3 februarie 2012 21:24
-
6 februarie 2012 10:17Moderator
Hi,reprac,
That'e because the sip address is different from the primary SMTP address,you can check the following links for the solution
http://www.codesalot.com/2011/lync-2010-and-exchange-web-servicesautoconfigure/
Regards,
Sharon
Sharon Shen
TechNet Community Support
******************************************************************************************************************************************************* Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community memb
-
6 februarie 2012 14:27
Thank you, Sharon, but that doesn't really help.
I use over a dozen domains on my Exchange server, ten of them are Internal Relays with completely independent active directory databases, DNS records, and email servers over which I have zero authority or control. I cannot set the SIP equal to the default SMTP address for 95% of my users, because the default SMTP address is not a valid SIP domain for my server.
- Active directory UPN = username@college.university.edu
- SIP address = username@college.university.edu
- Exchange username (same as upn, of course) = username@college.university.edu
- Default SMTP address = username@university.edu (domain is owned by a different organization with their own AD, Exchange, and Lync)
The problem is only with one of those domains. Everything works great for the rest of my users whose SIP addresses don't match their default SMTP addresses.
-
10 februarie 2012 15:50
More information:
Early in our deployment, we had added "university.edu" to the HKCU\Software\Microsoft\Communicator\username@college.tamu.edu\TrustModelData value. A new user without that modification gets a different prompt:
If the user checks "Always trust this server..." and clicks Connect, then Lync adds "university.edu" back into the TrustModelData value and breaks the Exchange connection again. The "Credentials Are Required" box opens immediately and will not accept the user's credentials because it's connecting to the wrong server.
However, if the user clicks "Try Another Server", it will connect to the correct Exchange server at college.university.edu after a minute or two.
Even if the user says to always trust this (incorrect) server, if we remove the domain from TrustModelData again, we can get this "Lync is attempting to connect" box back and get it to connect to the right server.
This is better, but still not good enough.
How can we get Lync to quit trying to log into the Exchange server that corrolates to the user's reply-to domain?
-
10 februarie 2012 16:05
Adding this line (where xx.xx.xx.xx is the ip address for autodiscover.college.university.edu) to the hosts file is a workaround:
xx.xx.xx.xx autodiscover.university.edu
But it's not perfect. We do have some users with email accounts in both domains, so it would be nice for autodiscover.university.edu to be correctly resolvable. And I'd rather not have to edit the hosts files on every computer.
- Propus ca răspuns de Sharon.ShenMicrosoft Contingent Staff, Moderator 14 februarie 2012 10:28
-
14 februarie 2012 10:28Moderator
Hi,reprac,
Have you cheked the last link I posted above?
What's about you add a DNS SRV or CNAME record pointed to the Exchange CAS for autodiscover in the other domain?
Regards,
Sharon
Sharon Shen
TechNet Community Support
******************************************************************************************************************************************************* Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community memb -
14 februarie 2012 16:08
Hi Sharon,
I have clients using about a dozen different domains (configured as internal relays) as their primary smtp addresses, and this is the only domain I have trouble with. Unfortunately, it's also the only one for which I have no control over DNS records. I cannot add or modify any DNS records for the university.edu domain. They already have their own autodiscover and Exchange systems set up, which is the source of the problem. If they had no autodiscover records at all (as is the case with the other internal relay domains) Lync would work fine.
Is there really no way to tell Lync to ignore the primary smtp and get calendar data from the sip domain instead? Other than modifying the hosts file, I mean.
Also, a large percentage of my clients are external, using ISP provided DNS, so I don't think I use the split-brain technique Tom posted in the comments, either.- Editat de reprac 14 februarie 2012 16:12 More info
-
16 februarie 2012 09:30Moderator
Hi,reprac,
Unfortunately I haven't another more idea to solve it except modifying the SRV record or adding host file,but adding host file with batch file maybe an available option.Some information for your reference(Note:Please test before you adopt it and take the risk by your own).
Update: would you please check if creating a DNS Cname record for the autodiscover record in your domain can solve this issue?Maybe autodiscover.collegue.university.edu pointed to the autodiscover record in the main office domain,I am not very familar with DNS Cname record,you can go to windows server forum for more help on this DNS record.
Regards,
Sharon
Sharon Shen
TechNet Community Support
***************************************************************************************************************************************************************************** Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial t
- Editat de Sharon.ShenMicrosoft Contingent Staff, Moderator 24 februarie 2012 09:19
- Editat de Sharon.ShenMicrosoft Contingent Staff, Moderator 24 februarie 2012 09:19
-
27 februarie 2012 15:20Thanks for your help, Sharon. I have a ticket open with Ms Enterprise Communications Support now. I'll post the resolution when i have one.
-
20 aprilie 2012 18:12
According to Microsoft's Lync and Exchange technicians, the user's primary smtp domain must be in the same forest as the Lync user's Exchange login for the EWS link to work. Then you can have a CAS server in the primary smtp domain proxy the authentication request to a CAS server in the Exchange login domain. That was not an option for us.
We found three solutions of varying utility:
- Modify the hosts file on the user's workstation to break autodiscover for the primary smtp domain. E.g. 127.0.0.1 autodiscover.university.edu. If Lync cannot reach the autodiscover service for the primary smtp domain, it will never give the user a logon prompt. This causes a red bang on the Lync icon and an Exchange connection error, but it works.
- For users on domain-joined computers, create GPO that applies an IPSec rule denying outbound traffic to the primary smtp domain's autodiscover ip address. Lync will fail over to the logon domain, and everything is good. This won't work if the user boots their laptop off the network or if they aren't domain joined.
- Configure the autodiscover service for the primary smtp domain to direct the client to requery with the correct domain. This requires custom coding (a black box to me) and a database matching the primary smtp address to the actual logon domain. We already had that database because we were forwarding email from the @university.edu address to the @college.university.edu mailbox, so it was only a matter of coding. I can't tell you any more about this because it was implemented by people with a completely different skill set than mine, and I won't claim to understand how it works. :-)
.png)
