We have Office 365 setup and working with our external domain. ADFS and DS are both setup and functioning correctly. Users can use their domain credentials and log on the portal/OWA/sharepoint with no issues at any location.
Lync users can log on as long as they are on site with a domain controller, or not logged onto a domain computer with their domain account. If the user take a domain laptop off site (no DC), logs on with their domain account, the lync login will fail saying 'Service is unavailable'. If they are on site with the DC, it works fine. If I change the DNS to point to the router gateway instead of the DC, Lync will no longer log on.
Users are able to hit the
https://sts.domain.com/adfs/services/trust/mex and see the XML with no issues, even though they can't log on lync. I have also run the http://trippsn2.online.lync.com/ web application and it does not show any errors. All DNS resolves correctly.
I have followed this KB for ADFS (http://support.microsoft.com/kb/2839539/en-us). Kerberos shows correctly for the external URL and matches our wildcard cert, the user can be in less than 5 groups and still fail, and the ADFS service is running under a domain account.
The only work around is to log on with a local admin account. But the users then can't log on Lync meetings sent out by email. Only a direct request to the user opens. So this is not an acceptable solution, and definitely not scalable.
Our Setup:
ADFS: Server 2012 w/ ADFS 2.1
Forefront TMG array for inbound/outbound proxy.
Our ADFS server is hosted off site, behind a forefront TMG array. All traffic to/from the internet have to pass through the TMG array. No users have direct access to the ADFS server, regardless of their location. The only way ANY users are able to get to the ADFS server is through the external URL.
I have setup the 2 ADFS rules on TMG following this article (http://www.stevieg.org/2012/05/configuring-ad-fs-2-with-tmg-based-sso-to-office-365/). Everything is working with no blocked requests on TMG.
When a user connects externally, I see 2 connections to https://sts.domain.com/adfs/services/trust/2005/windowstransport then 2 more connections to https://sts.domain.com/adfs/services/trust/2005/usermixed
and they can log in fine.
When the problem users log in, they only try and hit the .../windowstransport endpoint, but no other connections are attempted.