So I set up a local environment with an Active Directory ,DirSync, TMG (with proxy chaining) and federated a sub-domain with the cloud - the last one will be the focus of this post

The local environment consists of the following:

1.       Domain controller (contoso.com) with 5 users

2.       Sub-Domain controller (cont.contoso.com)with 5 users

3.       TMG (with proxy chaining)

4.       DirSync

5.       Client 1

6.       Client 2

The plan was to have the sub-domain (cont.contoso.com) federated with the cloud and to keep using the domain (contoso.com) un-federated.

In order to federate a domain, you will first have to deploy and configure ADFS 2.0 and DirSync. After you have done this, you need to install the

Microsoft Online Services Module for PowerShell. You will need these cmdlets to connect to your online account and to convert your domain to a federated domain (you can find the installer here: 32/64). I say convert, because I assume that you already added your domain to Office 365. When you convert a domain, automatically all users will become federated and will need to start logging in using their Active Directory credentials. Unfortunately the rollout of this feature cannot be performed in stages, therefore I advise you to do this during non-peak hours.

The problem encountered here, was the following:

I already added the vanity domain (contoso.com) to the cloud as well as the sub-domain (cont.contoso.com). When I ran the cmdlets to convert the sub-domain to a federated domain, I kept getting an error. Unfortunately I did not take a screenshot at that time and a repro would be too time consuming right now. Anyhow, the problem was that Office 365 does not allow you to federate  a sub-domain if you also have the domain added in the cloud. If you federate a domain, all the sub-domains will inherit the federation. If you want to federate only the sub-domain, as it was in this case, you need to only have the sub-domain added to your tenant.  

Very important: Before converting a standard domain to single sign on, make sure that you have at least one global administrator in your Office 365 tenant set on the *.onmicrosoft.com domain . If you don't have one, create one right now. By having this backup administrator, you are sure you can still access your tenant, no matter what happens to your vanity domain.

To convert a sub-domain to a SSO domain, you will have to do the following steps:

1.       Open the Microsoft Online Services Module .

2.       Run $cred=Get-Credential. When the cmdlet prompts you for credentials, type your Office 365 administration account credentials.

3.       Run Connect-MsolService -Credential $cred. This cmdlet connects you to Office 365. Creating a context that connects you to Office 365 is required before running any of the additional cmdlets installed by the tool.

$credCet—Credential cndlet Get—Credential at comnand pipeline position 1 Suppl9 values for the following paraneters Credential PS C:\windows\system32> Connect—MsolService —Credential $cred PS C:\windows\system32>" type="#_x0000_t75" o:spid="_x0000_i1026">

4.       Run Convert-MsolDomainToFederated -Sub-DomainName <domain>, where <domain> is the domain to be converted. This cmdlet changes the sub-domain from standard authentication to single sign-on.

…and make sure you have an active internet connection on the ADFS server. Without this, you will get an error in the MOSDAL report stating that the login token is not valid:

The AD FS token received is not valid until: 17/07/2012 16:47:41.

This is just one of the problems encountered while deploying a federated domain. I will post more on ADFS and SSO in the near future.

There are several options you can use to share meetings with your partners, Lync WebApp, Lync Attendee Client or Lync Client, all of these Clients included with your Lync Environment have by default the Option to “Join using your corporate credentials” and there is no one configuration option that you can select to block this, there are however a few configuration changes that you can undertake that will get you the hoped-for result.

Because there are 2 major Client Architectures, Lync WebApp, a web based client that uses the External Web Farm to connect you to your meeting and Lync Attendee and Lync Client that use the Lync Edge Server.

In the following we will discuss each in details.

Lync WebApp

In order to use the Lync WebApp to share meetings outside your network you will need to first deploy an Edge Server (used for Media Sharing) and a Reverse Proxy (Used for Publishing your External Web Farm). A step by step Deployment Guide for Reverse Proxy and Edge Server can be downloaded here

http://www.microsoft.com/download/en/details.aspx?id=11379

After you have deployed the Edge Server and the Reverse Proxy and configured all your Firewall rules make sure everything is working as it should, at this stage you should be able to log on to meetings from outsideyou network using the “Join as a guest” and “Join using your corporate credentials” option.

If everything is working we need to focus our attention on the Reverse Proxy as we will need to somehow block the “Join using your corporate credentials” option before the credentials get to the Director or Front End Server.

In our Environment we used an ISA/TMG Firewall and Reverse Proxy but you may use any other Product you wish as long as it provides you with the needed configurations.

We noticed, in a ISA Firewall Log, that if you use the “Join using your corporate credentials” option in Lync WebApp and type in your Credentials, the Lync WebApp Client will attempt to use the following link to authenticate you ttps://externalwebfarmfqdn/WebTicket/WebTicketService.svc/Auth.

So we tried several authentication methods on the Lync Director but found that if we block all traffic to /WebTicket/* we lose all connectivity from LyncWebApp (even for “Join as a guest” users), so what we did was to create a second reverse proxy rule on our ISA/TMG Server to block just https://externalwebfarmfqdn/WebTicket/WebTicketService.svc/Auth but allow all other requests for https://externalwebfarmfqdn/
WebTicket/WebTicketService.svc

On the ISA/TMG we just copied the external web farm rule created during our Edge Server Deployment (http://www.microsoft.com/download/en/details.aspx?id=11379 Page: 52) and added a Deny to the Name (just to make thing clear in the configuration).

We then set this second web publishing rule to a higher priority than the default rule so that ISA would check this rule first, and potentially block the traffic, and only then move to the second standard rule.

We ended up with 2 rules in our Reverse Proxy Configuration:

 
 
 
 
Now on the Deny Rule that you have just created go to Properties and the click the Action Tab, here select “Deny”. The move on to the “Paths” Tab and remove the /* (meaning everything) and replace it with /WebTicket/WebTicketService.svc/Auth, then just save the settings and you are done.

This would block all the requests for the URL https://externalwebfarmfqdn/WebTicket/WebTicketService.svc/Auth at Reverse Proxy level but will allow everything else to pass thru (as described in the Deployment Guide)

From a User’s side the experience is the following:

When he clicks the meeting invite (i.e. meet.<domain>/username/meetingID) and he will use the LyncWebApp he will get a windows giving him the option to “Join as a guest” or “Join using your corporate credentials”, should he attempt to
type in his corporate credentials he will get an error saying “The user name or password you entered is incorrect” (this is because the rule we just created did not pass the credentials back to the server and blocked them on the Reverse proxy)

Lync Attendee Client

Now that we have blocked the LyncWebApp let’s check out what we can do with regard to the Lync Attendee client. As the Lync Attendee Client will use the Edge Server to connect and not the WebFarm the changes we did on the reverse proxy side will not influence the behavior of the Lync Attendee, “Join using your corporate credentials” option will still be available for your users at this stage using the Lync Attendee.

Depending on you environment and architecture you have several options here, you might chose to disallow meeting attendance using the Lync Attendee client or you may choose to block only the “Join using your corporate credentials” option.

Both methods have pro’s and con’s, so if you need to allow your users to have remote access via Lync Client then you will need to use the first option and block Lync Attendee altogether using the Client Version Policy. This is because the settings that we will use to block “Join using your corporate credentials” on the Lync Attendee Client will also impact the Lync Client.

If you just want to use your Edge Server to allow Partners to join as guests to meetings and are not interested in allowing your Internal Users any remote access to the Network or if you are using VPN for this then you can do the following:

1. Deploy Lync Server Director Role

The Lync Server Director Role is recommended not only as its primary role is to increase security and add an extra hop between external servers (EDGE) and Internal Lync Environment (FE POOL) but as in order to achieve the intended behavior we need to modify the security settings on the Lync Environment. With a Director in place we have the possibility to change these settings more granularly (i.e. only on connections coming from Edge) without changing the security setting on the internal pool or globally

Deploy the Lync Server Director Role as described in the Microsoft Lync Server 2010 Edge Deployment Guide (PG:35)

 2. In the Lync Topology Builder set the Director as the Next Hop for the Edge Server

3. After you have successfully deployed the Lync Director Role and have set the Edge Server to point to the Director using the “Lync Server Control Panel” go to the Security Page and select the Registrar TAB

On the Registrar Tab Click New and from the drop down list select the Lync Director Server FQDN

4. On the New Registrar Security Provider list Disable Kerberos and NTLM and leave in only Certificate

5. Save the Settings and wait for the changes to be replicated on all Servers

NOTE: By disabling Kerberos and NTLM and only allowing Certificate Based authentication the only method provided to the Lync Attendee Client when trying to log on with corporate credentials will be Certificate authentication using the URL https://externalwebfarmfqdn/WebTicket/WebTicketService.svc/Auth/. Moreover the Lync Attendee Client will attempt to log on using Certificate (if one is present on the local computer in the user store) but will not attempt to request a new one if NTLM method is disabled on the registrant. Corporate Credentials entered in the Lync Attendee Client should never reach the Internal Servers in this configuration.

From a User’s side the experience is the following:

When he clicks the meeting invite (i.e. meet.<domain>/username/meetingID) and he will use the Lync Attendee Client he will get a window giving him the option to “Join as a guest” or “Join using your corporate credentials”, should he attempt to type in his corporate credentials he will get an error saying “Cannot sign in to Lync Attendee” (this is because in the security provider negotiation the Lync Attendee just got Certificate as the only possible Authentication Method and Lync Attendee client is unaware of this option )

Disclaimer:

Please Note that even though lots of different scenarios have been tested, like application and desktop sharing, PowerPoint Upload, Poll and Upload both from internal and from external, you may encounter problems in this configuration due to the fact that it is impossible to cover all the scenarios.

Should you at any stage have any issues regarding conferencing the Microsoft Support Engineer might ask you to modify the settings to a supported mode during the troubleshooting phases