Remote user sign in fails

venerdì 25 settembre 2009 13:47

0

Windows Server 2003 STD - dual honed

OCS R1 Consolidated Edge

We have enabled the firewall to support the OCS edge server (5061 and 443). Have had Federation and PIC running for a while but now looking to support external remote users. (443 has not been enabled on the internal firewall, logs have not indicated this is being hit or denied)

Using the OC client from an external network partially works but fails on authentication.

Logging has also identified the request is being received by the Director but logged as unauthorized. Same user works fine internally.

The users involved have been enabled for remote access and the Edge server has been configured for remote access.

We have used the external OCS testing tool testocsconnectivity.com. Passes all port and cert tests but simply fails on signin.

We have raised a case with Microsoft but wanted to put it out the community also for ideas.

Tutte le risposte

venerdì 25 settembre 2009 15:09

Moderatore

0

How are clients being pointed to the Edge server? If using Automatic Configuration then there may be a problem with how the SRV/A records are deployed and published. If using Manual Configuration make sure that you enter the External Servername or IP Address with the port, as in "sip.domain.com:443" otherwise Communicator will attempt to connect over 5061 by default, which is incorrect (as that is the federation port and not external client access port).
Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
sabato 26 settembre 2009 02:23

0
Yes we have included the port for the small group testing this functionality, manual config at the moment.

Soon as I come home the OC client pops up and wants me to sign in, then is fails on auth.

jh
- Modificato Johnhodg venerdì 2 ottobre 2009 13:45 typo
sabato 26 settembre 2009 15:20

0

Let's try isolating the dependencies by allowing the connection from the Edge directly to the Front-end Pool instead of going through the Director Server. Then try again and let us know the results

While doing that, make sure you've added the Access Edge to the allowed list as well.
domenica 27 settembre 2009 11:43

0

in regards to the allow list; this is only for federated domains right? Not our own yeah?

jh
venerdì 2 ottobre 2009 02:49

0

Hi John,

Sorry for the late reply, was too obssessed with my image for the past few days. OK, here's where you want to modify the settings to allow Access Edge & the Front-end to communicate to isolate whether is it your Director or other unexpected areas:

Access Edge
1. Computer Management > Office Communications Server 2007 R2 > Right Click > Properties
2. Click on the Internal tab > On the next hop address, replace the Director FQDN to your Front-end Pool
3. Under the Internal Servers authorized to connect to edge server, click Add Server > type in the FQDN of your Front-end Pool
4. Click OK to apply the new changes

Front-End
1. Launch the Office Communications Server 2007 R2 Console
2. At the Forest - YourADForestName > Right Click > Properties > Global Properties
3. Select the Edge Servers tab > Add the Access Edge, Web Conferencing Edge & A/V Edge Servers respectively
4. Click OK to apply the new changes

Do update us on this once you've manage to do so.

Thanks!
James Ooi MCTS - Office Communications Server 2007 - Blog:http://JamesOSW.Wordpress.com
venerdì 2 ottobre 2009 13:44

1

Hey James, thanks for the steps above, we have a change scheduled to change a local security policy setting on the Director.

Based on the work Microsoft PSS have undertaken they beliweve it relates to the enforcement of NTLMv2.

Now it appears this was applied to accommodate a Group Chat pilot so it seems strange be reducing the affective security of the environment.

Yet to see if this change works.

Will also check the settings you've mentioned but I believe this has been done.

FYI this is the explaination from PSS based on info in the logs :

The error code 0x80090302 means SEC_E_UNSUPPORTED_FUNCTION (The function requested is not supported). Based on our research, this issue can occur when the OCS server set to "require NTLMV2", Please help us follow the steps below to confirm whether this is the issue:

1. Logon the OCS Director server, click Start->Run, type "GPEDIT.MSC" and press Enter

2. Navigate to Computer Configuration->Windows Settings->Local Policies->Security Options, check the settings of the following policies:

Network Security: Minimum session security for NTLM SSP based (including secure RPC) clients

Network Security: Minimum session security for NTLM SSP based (including secure RPC) servers

Are they set to "Require NTLMv2 session security" or "No minimum"?

3. Also you can export the following registry keys to us for checking:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

Regards

jh
sabato 3 ottobre 2009 04:31

0

Hi John,

Thanks for the info. I support right now the Director has been identified to be the 'culprit' then
James Ooi MCTS - Office Communications Server 2007 - Blog:http://JamesOSW.Wordpress.com
domenica 4 ottobre 2009 11:17

0

So it seems PSS was right. Remote user is working. Enforcing NTLMv2 was the culprit.

So next steps..... thus far we have only enabled 443/TCP and 5061/TLS for IM and presence and this works great now over the internet without VPN after this change.

However video and audio doesn’t work. Partially expected this of course. However I sort of "hoped" video calls would work when both users are on the same network even without enabling the port range 50000-59000 or whatever it is.

But from testing today a video call still needs additional ports to even establish a call even though it ends up point to point.

Correct?

johnh