locked
Mobiles on Internal WiFi RRS feed

  • Question

  • Hi,

    We have a Lync 2013 FE pool with Federation and External Access enabled. The External Access via the Edge works well as the certificates are valid public certs. Mobile devices work well (Android, iPhone/iPad, Windows 8.1).

    However, these devices (e.g. Windows 8.1 on Nokia) do not connect succesfully on the Internal corporate WiFi. The certificates on the FE servers are signed by the AD Enterprise CA. The Root CA is being installed on the device but the connection still fails:

    ----

    An error occured in Lync. Please retry.......

    ----

    Can I have that certificates with internal (e.g. int-domain.local) domains as SAN signed by external (public) CA?

    Monday, May 11, 2015 12:29 PM

Answers

  • First, let’s step back and think of the concept of mobility support.

    1. Mobile devices uses only HTTPS protocol for signaling i.e. sign-in, initiate or receive call etc.
    2. Mobile devices are meant to always sign via the External (4443) Lync web site (services) no matter of the physical location (Corporate Wi-Fi or public internet)
    3. Mobile devices rely on lyncdiscover services (lyncdiscover or lyncdiscoverinternal) to receive provisioning URL information.

    #1 and 2 implies that reverse proxy will be always used. Since we configure RP with Public certificate, the mobile device will not have to be configured with local cert chain.

    #3 – it is vital to configure RP to serve both 443 and 80 requests and here is why:

    Internal flow: mobile device connects to http://lyncdiscoverinternal.contoso.com (not SSL). The response is “Go to the FQDN of the External Pool web services on port 443”. Mobile device now does SSL connection to the RP (where we terminate with Public cert). Because the connection is made on the RP, the request is forwarded to Lync server web services on 4443. Lync server now knows this is “external” connection and continues to use the public FQDN of any service that is related to the mobile device.

    What do you have deployed? Standard edition or EE pool?

    Drago


    http://www.lynclog.com

    • Proposed as answer by Eason Huang Sunday, May 17, 2015 3:34 AM
    • Marked as answer by Eason Huang Tuesday, May 19, 2015 8:00 AM
    Tuesday, May 12, 2015 1:26 PM

All replies

  • HI,

    Yes you can use pubic cert for Internal servers as well. then you need to enable port 80 for all users so that they could reach to CA authority.

    Regards

    Monday, May 11, 2015 2:00 PM
  • Hi,

    From your description above, did you mean Lync mobile client could login from Internet successfully but from internal WiFi?

    Did you deploy the Reverse Proxy in the DMZ zone?

    Base on my understanding, the internal .local SAN certificate couldn't be request by public CA already.

    You may need manually import the internal root CA to the Lync mobile client.

    Best Regards,
    Eason Huang


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Eason Huang
    TechNet Community Support

    Tuesday, May 12, 2015 2:57 AM
  • Hi Eason,

    It is my understanding that the DMZ and reverse proxy is not in play while on internal WiFi.

    The ".local" was just an example, the point being: can any internal (but externally unsupported) domain (e.g. .inter, .local, .kom, etc.) be part of the SAN where the subject is legal (e.g. .com, .co.za, .net, etc.)

    The manual import of the CA seems not to work on my Nokia Lumia 930 with Windows 8.1. Unless I'm doing it incorrectly as it does not give the option (like in Desktop Windows) to choose the location so I can put it in 'Trusted Root.....'

    Regards

    Danie


    • Edited by Vinkie Tuesday, May 12, 2015 7:06 AM
    Tuesday, May 12, 2015 6:16 AM
  • First, let’s step back and think of the concept of mobility support.

    1. Mobile devices uses only HTTPS protocol for signaling i.e. sign-in, initiate or receive call etc.
    2. Mobile devices are meant to always sign via the External (4443) Lync web site (services) no matter of the physical location (Corporate Wi-Fi or public internet)
    3. Mobile devices rely on lyncdiscover services (lyncdiscover or lyncdiscoverinternal) to receive provisioning URL information.

    #1 and 2 implies that reverse proxy will be always used. Since we configure RP with Public certificate, the mobile device will not have to be configured with local cert chain.

    #3 – it is vital to configure RP to serve both 443 and 80 requests and here is why:

    Internal flow: mobile device connects to http://lyncdiscoverinternal.contoso.com (not SSL). The response is “Go to the FQDN of the External Pool web services on port 443”. Mobile device now does SSL connection to the RP (where we terminate with Public cert). Because the connection is made on the RP, the request is forwarded to Lync server web services on 4443. Lync server now knows this is “external” connection and continues to use the public FQDN of any service that is related to the mobile device.

    What do you have deployed? Standard edition or EE pool?

    Drago


    http://www.lynclog.com

    • Proposed as answer by Eason Huang Sunday, May 17, 2015 3:34 AM
    • Marked as answer by Eason Huang Tuesday, May 19, 2015 8:00 AM
    Tuesday, May 12, 2015 1:26 PM