Jun 20 2017 10:07 AM
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
Jun 20 2017 11:47 PM
Jun 21 2017 03:12 AM
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.
Jun 21 2017 03:44 AM
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.
Jun 21 2017 04:54 AM
Jun 21 2017 06:06 AM
If he did that, he would not show me any private certificates and I would not have warning: D
Jun 21 2017 06:08 AM
@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 ?
Jun 21 2017 06:24 AM
Is that internally a DNS record lyncdiscover.domain.com must exist and point to the reverse proxy?
Jun 21 2017 06:31 AM
Jun 21 2017 06:31 AM
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)
Jun 21 2017 06:32 AM
@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 ?
Jun 21 2017 06:35 AM
Jun 21 2017 07:03 AM - edited Jun 21 2017 07:05 AM
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
Jun 21 2017 07:53 AM
Jun 21 2017 08:04 AM
I attach you the log if you see something..
domain.com replace our public domain name
domain.local replace our internal domain name
Jun 21 2017 08:20 AM
actually they do query it just that we redirect to UCWA external. THat's all.
Jun 21 2017 08:24 AM
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?
Jun 21 2017 10:21 AM
Jun 21 2017 01:27 PM - edited Jun 21 2017 01:27 PM
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