Mobile Apps, internal use, certificate warnings

[Benoit Machiavello]

Hi,

We are currently deploying Skype for business mobile apps for internal use.

Before that, the use of mobile apps was mostly external. No problem...

But it appears that by using applications internally, users receive many warning related to the fact that internally, certificates are signed by the Active Directory Certification Authority.

In BYOD scenario, we can deploy our root CA to device, not a problem, but for some population, mobile are only used as "mobile Lync Phone", and when you deploy root CA to android phones, you are required to set an unlock code. This is not compatible with the intended use. 

Is there a way to prevent this ? After a lot of reading I have find a discussion saying that you have to redirect ALL https connections like meet.domain.com, including desk phones, windows clients, etc..., to reverse proxy, like that it's our public certicates that are presented to mobile.

This seems to me completely absurd and at least not optimized

So what is the good practice for Mobile Apps using internally with internal certs from ADCS ?

Thanks

[#2]

Hi Benoit,
Mobile apps are using the dns records lyncdiscover.domain.com for login in.
Desktop clients are using in first case lyncdiscoverinternal.domain.com.

Recommendation is to point A record lyncdiscoverinternal.domain.com to front end server/pool. lyncdiscover.domain.com A record should point to the reverse proxy, in this case the external webservices url will be used (port translation 80,443 to 8080 4443).

There is documentation on technet about how mobility needs to be configured.
link: https://technet.microsoft.com/en-us/library/hh690030(v=ocs.15).aspx

[#3]

Hi Erwin,

currently I don't have lyncdiscover.xxxx record on our internal DNS.

But it's not what I understand here :

When you use Automatic Discovery, mobile devices use DNS to locate resources. During the DNS lookup, a connection is first attempted to the FQDN that is associated with the internal DNS record (lyncdiscoverinternal.<internal domain name>). If a connection cannot be made by using the internal DNS record, a connection is attempted by using the external DNS record (lyncdiscover.<sipdomain>). A mobile device that is internal to the network connects to the internal Autodiscover Service URL, and a mobile device that is external to the network connects to the external Autodiscover Service URL. External Autodiscover requests go through the reverse proxy. The Lync Server 2013 Autodiscover Service returns all Web Services URLs for the user's home pool, including the Mobility Service (Mcx and UCWA) URLs. However, both the internal Mobility Service URL and the external Mobility Service URL are associated with the external Web Services FQDN. Therefore, regardless of whether a mobile device is internal or external to the network, the device always connects to the Lync Server 2013 Mobility Service externally through the reverse proxy.

For me, it tries first to lyncdiscoverinternal, and as soon it will find it, it will connect to it.

After it should use external web url. but if it uses another url, like meet.domain.com, etc, internal DNS will always send it to front end server, and we will have problem with certificates.

[#4]

You won't, as the described in the article mobility is always hairpinned over the reverse proxy. 

consult here

The UCWA request will land on your RP and redirect to external web fqdn. 

[#5]

Mobile devices don't connect to internal Autodiscover Service (will use internal certicate). This is only used for Desktop Client. Like Ivan mentioned UCWA request will land on Reverse proxy and will be forwarded to Skype external web services url(public certificate which the mobile phone can check), this one is using port 8080 and 4443 (in default configuration).

[#6]

If he did that, he would not show me any private certificates and I would not have warning: D

[#7]

---

@Erwin Bierens wrote:
Mobile devices don't connect to internal Autodiscover Service (will use internal certicate). This is only used for Desktop Client. Like Ivan mentioned UCWA request will land on Reverse proxy and will be forwarded to Skype external web services url(public certificate which the mobile phone can check), this one is using port 8080 and 4443 (in default configuration).

---

If mobile device use lyncdiscoverinternal dns, then it will connect internally first ?

[#8]

Is that internally a DNS record lyncdiscover.domain.com must exist and point to the reverse proxy?

[#9]

Mobile devices are not checking lyncdiscoverinternal. First check on mobile devices is lyncdiscover.

[#10]

I just sent me the log from the device mobile.

It seems that it first try to connect to lyncdiscover.domain.com, failed because DNS entry doesn't exist (Exception UnknownHostException caught while executing http request Get http://lyncdiscover.domain.com) and then try to connect to https://lyncdiscoverinternal.domain.com

But it's strange because for me it's the opposite of what I read before (first lyncdiscoverinternal then lyncdiscover)

[#11]

---

@Erwin Bierens wrote:
Mobile devices are not checking lyncdiscoverinternal. First check on mobile devices is lyncdiscover.

---

So I will create it.

but no impact on windows clients and desk phones ?

[#12]

Like mentioned above pc client is using lyncdiscoverinternal first then lyncdiscover. Mobile clients use lyncdiscover.

[#13]

Correct

[#14]

not better ...

I see in the log that it try to contact https://lyncdiscover.domain.com then he try to contact http://lyncdiscover.domain.com (not allowed, only https) then https://lyncdiscoverinternal.domain.com

Does I have to open http ? I have read in microsoft document that it is not recommended

[#15]

If HTTPS is configured correctly it will hit the first try.

[#16]

I attach you the log if you see something..

domain.com replace our public domain name

domain.local replace our internal domain name

[#17]

actually they do query it just that we redirect to UCWA external. THat's all.

[#18]

So you are failing here:

06-21 14:56:27.853 14597 INFO TRANSPORT CUcwaAutoDiscoveryResponse.cpp:116 location value is external
06-21 14:56:27.854 14597 INFO TRANSPORT CUcwaAutoDiscoveryResponse.cpp:190 User url is https://pools4bpriws.domain.com/Autodiscover/AutodiscoverService.svc/root/user?originalDomain=domain...

===

06-21 14:56:28.547 14597 DEBUG [Http] CertificateDialog: Showing certificate dialog for UserCertificateApprovalRequest { mRequestId = edf8ca96-309a-43fe-afc7-59a84adc5fe2, mTrigger = UntrustedCertificate, mCertificateInfo = X509CertificateInfo { Issuer = DOMAIN-CA, Subject = pools4bpri.domain.local, SigAlgName = SHA1withRSA, NotBefore = 02 nov. 2015 02:11:47 PM, NotAfter = 01 nov. 2017 02:11:47 PM, SerialNumber = 758225337598940103081203869516454363911946403 }, mTrustModel = null }=

===

So, in your topology, what's the FQDN of your external webserviceS?

[#19]

Are you pointing DNS (internal) to internal DMZ address or external IP?
Like Ivan is asking, what's the external webservices FQDN?

[#20]

pools4bpriws.domain.com is pointing to public ip of the reverse proxy (internally and externally) 

pools4bpriws.domain.local is pointing to frontend

so I don't unterstand why I've got this internal cert

I have just verified and from an internal computer with IE, if I go to the URL I receive the public cert from globalsign...I can't verify from home in the Wifi vlan but it should be the same...I will verify tomorrow

So, in your topology, what's the FQDN of your external webserviceS?

pools4bpriws.domain.com