One of the big challenge to deploy a Office 365 enviroment in a big company is doubtless the security…obviously from corp net to the office 365 cloud and viceversa, but main problems are certainly on Lync online due to the type of authentication with MSOSIA (Microsoft Online Sign In assistant).
Typically in a Lync on premise all of the authentication and communications protocol is managed by Lync servers and there’s not need to use MSOSIA to login, but with Lync Online all of communications (except the authentication to the ADFS that is internally located ) pass through a web proxy (in each company we have a proxy…) and we are not sure that this web proxy is a ISA server or TMG server . Here you can find a good KB that describe exactly how to configure an ISA or TMG to exclude the MSOSIA service for each user’s client :
but , as i write before we have to consider that with a SQUID proxy or other type not well know , not MS, we have to bypass the proxy and permit Lync to pass directly on Internet . Ok….done.. but typically we have also a firewall between that work only with ip address (network level) and not name or service (application level) , so we have to exclude this list provided by MS :
good to use but in this condition we have to configure firewall with static route, and if subnet change we have to change accordingly on it, but for now is the only way, for this enviroment.
After all you think that now it’s all ok , lync connected fine etc…not completly… because there are another important things to manage on MSOSIA .
MSOSIA is needed to connect to office365 cloud , with it we can obtain the personal certificate that lync use to connect to Lync online cloud , and when you install it the first time on a client , after you close the installation windows that seems that all working fine , services MSOIDSVC.EXE try to connect to internet to download Certification authority CRL to confirm the origin of various root certificate installed on the client, infocert, verisign and so on. But if the client is a Windows 7 and it’s not connected on internet or it have a web proxy configured that ask authentication to browse to those CA CRL site, at the time of Lync login , we have always this :
At the moment we are investigating how to solve the problem , and at this time the only way to make it work is to disabled authentication in web proxy side for this site :
- – *.verisign.net
- – *.verisign.com
- – *.inforcert.it
An update from MS :
To avoid this on your proxy web authentication you can add and filter to exclude *.crl.
This is because Authenticode is trying to ensure that the certs that signed the files in use are valid. It does that by checking that the serial numbers are not in the CRL files that the issuing CA produces.
If it can’t get a CRL it assumes the certs are invalid
Also the CRL files have to be cryptographically signed by the same cert as signed the cert in question
If anyone have ideas or comments , please contribute 🙂