Dienstag, 4. November 2008 16:27
I have question related to the SIP ID and the Live meeting client.
From the whitepaper "Designing Your Perimeter Network for Office Communications Server 2007" I got the following information:
". Remote users who belong to the organization that hosts the conference are authenticated through Windows authentication (NTLM); anonymous users are authenticated through HTTP digest authentication; and federated users are authenticated by their own organization and validated in the host organization by the Access Edge Server through MTLS."
With the communicator client I'm able to log on using my SIP account as the username (that is equal to my email address). The customer doesn't want to use the email account as username but is considering the Kerberos Principle Name (UPN) as ID for all users in the AD forest. This would become a problem for remote users I guess since Live Meeting requires an NTLM logon name.
Is NTLM obliged to use for remote users?
Why can I use my SIP account as user id in Communicator and not in Live Meeting (I need to use the domain\username combination).Is there a way to get rid of the domain name and use digest authentication for external Live Meeting users?
Is an ISA reversy proxy required since NTLM authentication is required for external Live Meeting users?
Thanks in advance for sharing your thoughts.
Dienstag, 4. November 2008 20:29Hi,
if I recall correctly I have used UPN based logons before in Livemeeting. Also the following support article suggests that it's possible.
In fact maybe the problem explained in this article is why you can't get it to work with your livemeeting client. See if downloading this patch helps solve your problem.
Digest authenticaton is for web-based applications and HTTPS. Livemeeting uses mainly PSOM for it's purposes with the exception of meeting content downloads which are over HTTPS. For remote connectivity you need to deploy both the OCS Web Conferencing Edge Servers and a Reverse Proxy to publish the meeting content locations.
Have a look at the following document from Microsoft on how to properly deploy your EDGE infrastructure:
Also there is an EDGE planning tool you can use to make sure you get to the right topology for your requirements:
Mittwoch, 5. November 2008 07:42
Thanks Tonino for the hint. The confusing thing is that I use a much newer version of Live Meeting (8.0.6362.28). So I believe the hotfix should be included?
One more question about the reverse proxy: should it support NTLM as well? Are we obliged to use ISA or can we also use Bluecoat or Apache?
Mittwoch, 5. November 2008 16:08
Mmm....strange. I was testing it again and it seems to be working now. Maybe I was using an older version of Live Meeting before.
Mittwoch, 5. November 2008 18:53For Livemeeting your Reverse proxy doesn't have to support NTLM. What happens is that you will authenticate to the Web Conferencing EDGE Server and do your uploads using the PSOM protocol. When you want to download content you will use HTTPS but there is no authentication involved here. Basically when you joined the meeting Livemeeting receives a download URL and a meeting key which is to be used to access the content share.
However for Communicator and Group Expansion, Address Book Downloads you will be using HTTPS as well through the reverse proxy (when connected remotely). Here you do need your reverse proxy to support NTLM or Kerberos authentication. It should be enough for your Reverse Proxy to support the propagation of the authentication headers which I believe Apache can do by adding a specific module for NTLM but I am not sure on that.
Dienstag, 11. November 2008 09:59
Hi Tonino, just some comments on your previous answer:
"However for Communicator and Group Expansion, Address Book Downloads you will be using HTTPS as well through the reverse proxy (when connected remotely). Here you do need your reverse proxy to support NTLM or Kerberos authentication"
I was also getting some consultation from one of our internal security experts. He told me the following:
The windows (web) servers should use windows authentication with the following things to take into account:
- Forms based authentication or another authentication method on ISA/IAG (could be basic, RSA or certificate based)
- Kerberos Constrained delegation on ISA/IAG for the translation of the authentication mechanism
- Per published service this translation has to be done
- Windows 2003 in native AD mode
- SPN's must be published
- ISA/IAG should be a member of the domain
- In case web services are used: they should be accessible on port 80 or 443, different host headers will be supported
- The user account should not be blocked for delegation.
Read more about kerberos delegation on the following website : http://technet.microsoft.com/en-us/library/cc441606.aspx
About setting up Apache as your reverse proxy, more info can be found in the following post:
Dienstag, 11. November 2008 22:51True if the application would be a web application such as Communicator Web Access or Outlook Web Access but the Communicator or LiveMeeting client cannot present the user with a form based authentication page and then use these "credentials" for accessing the OCS Web Components. That's why your reverse proxy has to support NTLM or kerberos directly.