cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1313
Views
0
Helpful
2
Replies

VCS-E to VCS-C MOVI AUTHENTICATION WITH AD AUTHENTICATION

RAMEEZ RAHIM
Level 1
Level 1

Hi,

We have a VCS-C and VCS-E. We are having movi users currently authenticated by Local TMS Agent Database.

Now we are in the processing of migrating the authentication to Active Directory.

We have done this by enabling "Check for Credentials" on VCS-C Default Zone(entry point for provisioned clients) and every movi user on Internal network is getting authenticated with AD credentials. (domain\username & domain password)

However if a user from VCS-E is trying to authenticate with AD credentials, the login fails with invalid username and password.

If we try to use the username and password of TMS agent, it works fine.

Proceeding to the next step, we enabled the "Check for Credentials" on VCS-C Traversal CLient Zone toward the VCS-E. Then  the authentication is fine with AD credentials for External movi users.

Now i want to know, will enabling the "Check for Credentials" on VCS-C Traversal CLient Zone will affect the call flow between VCS-C and VCS-E or any service will be interrupted.

Regards // Rameez

2 Accepted Solutions

Accepted Solutions

Martin Koch
VIP Alumni
VIP Alumni

Do you have any other things registered to the VCS-E? Like endpoints, gateways? In short

anything with the same domains that are set up on the VCS-C as well?

Do you register the movi clients on the VCS-E or proxy register them on the VCS-C?

Calls from external parties shall not be affected at all, as the auth hits the same domain only.

What you could test is if your movi users can still properly dial in from the outside via

the VCS-E to devices registered to the VCS-C and also presence and phonebooks.

These are things that break most likely tend to break if there is something else wrong.

Besides that if you have set it up properly it shall work fine

Please take some time and go through this guide, they have nice examples in the appendix,

so you can recheck your setup:

http://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/config_guide/Cisco_VCS_Authenticating_Devices_Deployment_Guide_X7-0.pdf

Maybe Andreas has something else to add.

Please rate the answers! (simply click on the stars below the messages)

Please remember to rate helpful responses and identify

View solution in original post

Hi Rameez,

to start off, I want to mention that authentication works differently for H323 and SIP. The VCS Admin guide has quite a lot of information explaining the differences, so I recommend that you read through this if you are unsure of how the authentication mechanisms on the VCS work.

The main question in this case is whether any non-provisioned devices will be registering to your VCS-E, or the VCS-E will be hosting Movi/provisioning registrations exclusively.

When you configure the traversal client zone on the VCS-C to 'Check for credentials', this will affect all incoming calls/requests from VCS-E to VCS-C for the (SIP) domains which exist on the VCS-C.

This means that if the SIP domain 'cisco.com' exists on both the VCS-C and VCS-E, and you register a non-provisioned endpoint on VCS-E, for example 'ex90@cisco.com', and this endpoint attempts to call an endpoint registered on VCS-C on SIP, then the EX90 will be challenged for credentials by the VCS-C, unless the EX90 is

- registered in a subzone on the VCS-E which has the authentication set to 'Treat as authenticated' AND

- the ingress zone on the receiving VCS has 'Authentication trust mode' set to 'On' (Traversal client zones do not have this setting as Authentication trust mode is implicitly set to 'On' for this type of zone).

Since only Movi 4.2 and higher supports NTLM authentication against AD, the VCS-C would have to verify the challenge response from the EX90 towards its local database or an external LDAP, depending on what the 'Database type' on the 'VCS Configuration > Authentication > Devices > Configuration' page is set to.

This means that in order for allowing hard endpoints/devices to properly authenticate with the VCS-C, these endpoints/devices would have to be configured with credentials which match those existing in the VCS-C's local database/LDAP. In this case, LDAP could equate to AD if you patch your AD environment with the required H.350 schemas (But note that this is not identical to the NTLM authentication which Movi is capable of).

In other words, there is no black and white answer to your question, you have multiple ways of making this work depending on which devices will be registering to your VCS-E and whether or not these devices will be registering into a pre-authenticated subzone or not.

Hope this helps,

Andreas

View solution in original post

2 Replies 2

Martin Koch
VIP Alumni
VIP Alumni

Do you have any other things registered to the VCS-E? Like endpoints, gateways? In short

anything with the same domains that are set up on the VCS-C as well?

Do you register the movi clients on the VCS-E or proxy register them on the VCS-C?

Calls from external parties shall not be affected at all, as the auth hits the same domain only.

What you could test is if your movi users can still properly dial in from the outside via

the VCS-E to devices registered to the VCS-C and also presence and phonebooks.

These are things that break most likely tend to break if there is something else wrong.

Besides that if you have set it up properly it shall work fine

Please take some time and go through this guide, they have nice examples in the appendix,

so you can recheck your setup:

http://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/config_guide/Cisco_VCS_Authenticating_Devices_Deployment_Guide_X7-0.pdf

Maybe Andreas has something else to add.

Please rate the answers! (simply click on the stars below the messages)

Please remember to rate helpful responses and identify

Hi Rameez,

to start off, I want to mention that authentication works differently for H323 and SIP. The VCS Admin guide has quite a lot of information explaining the differences, so I recommend that you read through this if you are unsure of how the authentication mechanisms on the VCS work.

The main question in this case is whether any non-provisioned devices will be registering to your VCS-E, or the VCS-E will be hosting Movi/provisioning registrations exclusively.

When you configure the traversal client zone on the VCS-C to 'Check for credentials', this will affect all incoming calls/requests from VCS-E to VCS-C for the (SIP) domains which exist on the VCS-C.

This means that if the SIP domain 'cisco.com' exists on both the VCS-C and VCS-E, and you register a non-provisioned endpoint on VCS-E, for example 'ex90@cisco.com', and this endpoint attempts to call an endpoint registered on VCS-C on SIP, then the EX90 will be challenged for credentials by the VCS-C, unless the EX90 is

- registered in a subzone on the VCS-E which has the authentication set to 'Treat as authenticated' AND

- the ingress zone on the receiving VCS has 'Authentication trust mode' set to 'On' (Traversal client zones do not have this setting as Authentication trust mode is implicitly set to 'On' for this type of zone).

Since only Movi 4.2 and higher supports NTLM authentication against AD, the VCS-C would have to verify the challenge response from the EX90 towards its local database or an external LDAP, depending on what the 'Database type' on the 'VCS Configuration > Authentication > Devices > Configuration' page is set to.

This means that in order for allowing hard endpoints/devices to properly authenticate with the VCS-C, these endpoints/devices would have to be configured with credentials which match those existing in the VCS-C's local database/LDAP. In this case, LDAP could equate to AD if you patch your AD environment with the required H.350 schemas (But note that this is not identical to the NTLM authentication which Movi is capable of).

In other words, there is no black and white answer to your question, you have multiple ways of making this work depending on which devices will be registering to your VCS-E and whether or not these devices will be registering into a pre-authenticated subzone or not.

Hope this helps,

Andreas