Subscribe via RSS Feed Connect on LinkedIn

Lync 2013 client “Network Password Required to Connect” Proxy Issue

21/05/2013 41 Comments

Update 25/5/2013: Others are experiencing this issue too and three different people have said they have raised cases with Microsoft and been told it is due for a CU “fix”. I’m not sure what this fix looks like and am trying to find out more.

Update 24/9/2013: A number of reports say that this issue is resolved in Lync 2013 Client September Cumulative Update (CU3). If/when I understand what has changed I will post, but for now if you are having the issue please try this CU and let me know, thanks – Tom

###########

I’ve noticed this on a few Lync 2013 deployments (or Lync 2013 clients against Lync 2010 pools) and heard from others, the Lync 2013 client prompts for “network password”, why?

image

Note, this is not the same as the prompt for Exchange credentials or for Lync Better together sign in.

It seems that (unlike Lync 2010 client as far as I can make out) Lync 2013 client respects the Internet explorer proxy settings (as arguably it should). In many corporate environments a web proxy is setup to restrict web traffic/authenticate users (often to log access against a user).

Lync 2013 client picks up that there is a proxy and when it goes to a site/https web service that is not specifically excluded from the proxy, the proxy challenges for credentials, hence the prompt. Put in your creds and all is well (until your password changes potentially).

Lync client hits a bunch of web services as part of it’s normal operation, so you can reduce the likelihood of seeing this prompt by excluding those addresses from the proxy (or from proxy authentication), names such as

  • lyncdiscoverinternal.domain.com
  • lyncdiscover.domain.com
  • poolname-webint-domain.com (EE Web services)
  • hostname.domain.com (SE web services)
  • owa.domain.com (outlook web access/web services)
  • autodiscover.domain.com (exchange autodiscover)
  • meet.domain.com
  • dialin.domain.com

(Obviously use your own judgment for the correct domains for your environment).

Since these are internal addresses it shouldn’t be a big deal to get them excluded from the proxy with a PAC file or excluded from authentication. In fact it takes needless load off the proxy. It’s not the case that Lync 2010 client doesn’t use any of these web services, just that it doesn’t seem to respect the proxy settings. Testing in fiddler shows the proxy challenge and response.

While setting the above addresses to bypass the proxy (or authentication) will reduce the likelihood of being prompted, unfortunately it potentially won’t eliminate the prompt. The 2013 client seems to have some hard coded web lookups to various Microsoft domains (probably for 365 autodiscovery/setup), and even if you find and exclude those (and if someone does with fiddler, please post the list!), if a federated user has a photo set in 2010 to do to a website (internal or public) Lync client will attempt a lookup to pull down the photo via http.

Interested to hear feedback if others are hitting this issue.

Tom

Useful? Please take a second to shareTweet about this on TwitterShare on LinkedInShare on Google+Email this to someone
Tom Arbuthnot

Tom Arbuthnot

Managing Consultant at Modality Systems
Tom Arbuthnot is a Microsoft Lync Certified Master and MVP. He is a blogger, regular on The UC Architects Podcast, contributing writer to Lync Server 2013 Unleashed and speaker at events such as Lync Conference and The Microsoft UC User Group London. He is currently Managing Consultant at Modality Systems.
Tom Arbuthnot
Filed in: Lync • Tags: , ,

Comments (41)

Trackback URL | Comments RSS Feed

  1. Dan Berry says:

    Here’s where I’ve seen the craziest effect of this occur: Lync Phone Edition (ie.- Polycom CX600).

    Here’s a prime example…
    https://docs.google.com/file/d/0BwFHOu764AKRc3g5SS1ienQ4YU0/edit?usp=sharing

    (I always knew the phones ran Windows CE, but seeing the Windows widgets was oddly amusing and entertaining to me :) )

    • wow that’s crazy, is that CU8/repeatable?

      • Dan Berry says:

        Well Tom, funny you should ask… we’re running hybrid mode, with 2010 CU8 and 2013 CU1. And yeah, that’s the latest Polycom firmware. Definitely repeatable, as it happened to all the phones in our UC practice office. Our organization has a Cisco Ironport (if it wasn’t obvious) for traffic on 443/80.

        The good news is that I had the network team add all the host records (above) to the unfiltered list and it cleared it up. And of course, they were confused as to why it would be a problem (again, as you said, they’re internal addresses, right?)… but there you have it.

        • OK, if the LPE only reaches out for Lync/Exchange Web services (rather than fed contact photos/random Microsoft public domains), at least that allows an easy workaround, really interesting though.

          In the environment I’m seeing it LPE aren’t up to CU8 yet. I’ll see if I can flash a couple and replicate, but as the proxy in this case has all the exclusions in place I suspect it won’t happen if the proxy exclusions are in place.

          cheers

          Tom

  2. Adam Jacobs says:

    Hi Dan,

    How did you manage to get this response, can you let me know how to reproduce this error?

    Many thanks,

    A

    • Dan Berry says:

      Adam: Easy… If you have a security gateway ‘issue’, and you have the latest Polycom Lync Phone edition firmware… wipe all credentials and attempt to sign in with PIN authentication on the phone. Don’t use a USB tether via PC.

  3. John Smith says:

    We have an office 365 Lync online env. setup with ADFS and use our “corporate” credentials that the Lync client automatically uses to sign in. We are getting this prompt as well. It makes no sense to me why the client will use integrated authentication for the client and not the proxy login. Why not try the integrated credentials one time and it if fails pop the login. Microsoft at work

  4. Peter says:

    This is a known bug in Lync 2013 client. I have just had a case with Microsoft on this and the fix is addressed in an updated scheduled for the last quarter of this year.
    The only solution is to enter username/password and check save password, has to be redone when password is changed.

    • Thanks Peter, do you have a PS ticket number you can share with me privately so I can backchannel/verify details.

      What’s considered the “bug” and what’s the proposed fix?

      Tom

      • Adrián Matías Sarabia says:

        I’m having the same problem! Peter, you can pass me the same information requested by Tom?

        Thank you!

  5. bb says:

    Its more than this.
    http://social.technet.microsoft.com/Forums/en-US/lyncdeploy/thread/5ff113c7-b660-4e76-917d-58bf32e856ad

    Its also for https://images.edge.messenger.live.com/Messenger_16x16.png if you just enable msn federation in lync (for all Clients!).
    Or for users that have external contacts with pictures, this also occurs.

    So exclude proxy for internal servers is only a workaround for some people.

  6. Will says:

    We have been suffering from the same problem. The big change that we noticed between 2010 and 2013 client is that the 2013 client no longer sends user-agent info in the proxy request. In 2010 it was possible to identify the client and allow it unauthenticated access – not brilliant but there was no pop-up. This is no longer possible with the 2013 client.

    I suspect that the fix will be to add back the user-agent info in the proxy request.

    If you have any information on how the fix will work I would be very interested

  7. Tony says:

    Why don’t they just provide an option in the client not to use a proxy? We’re using office 365 and some Lync 2013 clients have this problem. I need the office 365 Lync 2013 server addresses so I can bypass the proxy.

    • Yes, I am hoping someone will run a sniffer for a long period of time and collect the addresses, but it’s a bit of a moving target. Also with fed pictures downloads more urls still…

  8. Gazsi says:

    In our case, at the startup the Lync client looked for the autodiscover.MAILDOMAIN/autodiscover/autodiscover.xml file (I think this is a step from the exchange discovery process. This MAILDOMAIN is not the SIP domain in our case)… if this record is not exist for internal or external users(our exchange is not published), the Lync client ask for this….trough proxy. I put this DNS alias autodiscover.MAILDOMAIN available for internal network … and the Lync started without asking the proxy authentication.

  9. Mykhaylo says:

    Doesn’t Lync 2013 client have possibility to provide credentials of logged on user?

  10. Mat says:

    Hi Tom,

    Any new about CU fix for that issue?

    • No official news, a customer said they have been told it’ll be fixed in a future CU, its not in CU2.

      Worth asking MSFT if you have a contact, the more people that ask the better

      cheers

  11. Bryan Childs says:

    I got the proxy.pac file changed internally here yesterday to try to fix this issue – after having tested locally with a file:// based proxy pac url – which had worked.

    But downloading the real .pac file from our internal proxy server, the lync client is just ignoring the directive around autodiscover.. It’ll only honour it if the .pac file is loaded from a file:// url.

    Weird eh?

    PS – I’ve confirmed with our Microsoft TAM that there *is* a fix in the works for this. He doesn’t have a firm date for it, but seems to think Q4 this year is likeliest.

  12. Jordon says:

    Im running CU2 issue still present with a split DNS but a different internal domain. I’ve added all the internal and external DNS names in TMG excluding for pass through and exclude on auth.
    The proxy prompt happens sporadically at least once a day and is unpredictable. Running netmon shows access to the following urls, however i cant exclude from TMG for security reasons.

    osiprod-scus01-odcsm.cloudapp.net

    I believe the above has something to do with the translator – however i dont even have this enabled.

    • Yes, it reaches out to a whole bunch of MSFT domains, it would be good if someone found the time to document them, but a cu fix is on the way apparently

  13. Hi all,

    Lots of references to Proxy issue fixes in the September 2013 CU. Interested to hear how everyone gets on:

    http://tomtalks.uk/2013/09/lync-2013-client-september-2013-cu-released-new-spell-check-and-tray-icon-back/

    thanks

    Tom

  14. Lorian says:

    fixes the issue here too

  15. Excellent article. I’m facing a few of these issues as well..

  16. John says:

    Having this issue, in case when Lync 2013 client must connect to outside for image file (like https://images.edge.messenger.live.com/Messenger_16x16.png ) through TMG. User gets prompted for credentials – doesn’t matter if enters valid ones, invalid ones, cancel, or valid & save : will get repeated (1-2 per hour) prompts. Only occurs to small number of users (out of about 1000). Running latest version of Lync 2013 client as of today. Cannot find any pattern.
    What else to look for?

    • John says:

      Further testing showed that the cause of the prompts was not the connection for image files, but rather misconfiguration of Exchange autodiscovery. Once the missing DNS records for autodiscover.sipdomain.com were added, the annoying login prompts went away.

  17. Gio says:

    Hello John,

    We have an identical issue, was your fix to add an internal DNS for Autodoscover.domain.com?

    Thanks for sharing :)

  18. Gio says:

    Hello John,

    We have an identical issue, was your fix to add an internal DNS for Autodoscover.domain.com?

    Many Thanks for sharing :)

Leave a Reply