05-09-2012 01:38 AM - last edited on 03-25-2019 09:03 PM by ciscomoderator
Hi,
I was using TMS 13.1.2 as an LDAP Authentication source for both VCS-Control and VCS-Expressway, but noticed, that not all passwords are synched correctly in the TMS H.350 LDAP database, because the user is saved in two entries. I switched to local authentication, including the Provisioning database on the VCS-C and local database with proxying SIP registrations from the VSC-E to the VCS-C. This is working fine and I'm able to do calls.
I've created search rules on the VCS Expressway to replace all MCU aliases to a special external auto attendant. Locally registered endpoints on the VCS-E are allowed to call internal aliases. I tried to do the same for Jabber Clients, which are registered to the Traversal Zone of the VCS-C. This is not working as expected, because the Jabber Clients are not registered to a Local Zone and the SIP INVITE is not challenged.
I expected, that all message from the Jabber client will be challenged by the VCSE, but this is not the case. As a result, the SIP Invite is treated like an external user and not an internal.
May 9 10:11:28 tvcs: UTCTime="2012-05-09 08:11:28,425" Module="network.search" Level="INFO": Detail="Search rule 'my.domain proxy registrations' did not match destination alias 'mcu@my.domain'"
May 9 10:11:28 tvcs: UTCTime="2012-05-09 08:11:28,423" Module="network.sip" Level="INFO": Dst-ip="84.113.206.194" Dst-port="62503" Detail="Sending Response Code=100, Method=INVITE, To=sip:mcu@my.domain, Call-ID=999d4c4d96027b31@192.168.210.19"
May 9 10:11:28 tvcs: UTCTime="2012-05-09 08:11:28,419" Module="network.sip" Level="INFO": Src-ip="84.113.206.194" Src-port="62503" Detail="Receive Request Method=INVITE, Request-URI=sip:mcu@my.domain, Call-ID=999d4c4d96027b31@192.168.210.19"
These are the search rules I was talking about:
110 Enabled "local registered to Traversal" LocalZone No Alias pattern match Regex ^(.*)@my.domain$ Leave Continue TraverselZone
115 Enabled "authenticated to internal" Any Yes Alias pattern match Regex ^(.*)@my.domain$ Leave Continue TraverselZone
120 Enabled "mcu all to 899" Any No Alias pattern match Regex ^(900\d*|conference)@nts\.eu$ Replace Stop TraverselZone
Is it possible to allow Jabber Clients to be authenticated on the VCS-E, so a search rule can aply?
Thanks for your help!
Solved! Go to Solution.
05-11-2012 02:50 PM
You get the "Device Provisioning" key for your VCS-E as well, its free of charge,
it may require a valid service contract.
I have the new provisioning running on a VCS-E cluster in my lab, works fine.
In the old times that deployment was not officially supported, it was running great anyhow :-)
Did not check if its now a officially supported deployment.
I do not know enough about your deployment to say what would be the best for you.
There will always some scenarios where not all features can be deployed together,for whatever reason.
Maybe somebody can assist you in reviewing how the implementation could be best done.
If you would like to have authentication and AD integration you would have to connect
the VCS-E to the AD as well. Endpoints (At least for now) do not auth via AD, but you could
either use a h.350 db (could also be hosted with AD) or the local authentication database.
Which is now also propagated by TMS, might be a answer for your issue as well.
Please remember to rate helpful responses and identify
05-09-2012 01:40 AM
I forgot one info:
All Zones and Subzones are set to check credentials on VCSC and VCSE.
Traversal Server Subzone on VCSE is set to Treat as Authenticated.
05-09-2012 09:11 AM
I did tot check it with 13.2 but the h350 towards the opends was never really officially supported.
and many TMS versions have the limitation that the password in the h350 directory did not
get updated after you changed it.
TMS13.2 can be of your interest as the TMSPE will populate the local database with the
usernames and password. Besides that its also not to hard to set up your own h.350 directory.
I do not know your deployment and the decisions on how it is set up, but
you can register the JabberVideo clients also directly to the VCS-E, then your
search rules would fit as well.
An other option could be to have a CPL doing what you want to do.
Please remember to rate helpful responses and identify
05-11-2012 06:19 AM
Hi Martin,
I'm using TMS 13.2 with TMSPE, but as I know, the Provisioning database could only be synched to the VCS-C. Has this changed with X7.1 and TMSPE?
I'll change the Authentication to the VCS-E, when I switch over from normal authentication to AD Auth. So the Jabber Clients will be authenticated on the VCS-E and my call routing will work as expected. But what's with other clients, like a EX90, which is registered as a provisioning endpoint. This endpoint won't be able to authenticate against AD with NTLM, so we would require the credentials on the VCS-E.
05-11-2012 02:50 PM
You get the "Device Provisioning" key for your VCS-E as well, its free of charge,
it may require a valid service contract.
I have the new provisioning running on a VCS-E cluster in my lab, works fine.
In the old times that deployment was not officially supported, it was running great anyhow :-)
Did not check if its now a officially supported deployment.
I do not know enough about your deployment to say what would be the best for you.
There will always some scenarios where not all features can be deployed together,for whatever reason.
Maybe somebody can assist you in reviewing how the implementation could be best done.
If you would like to have authentication and AD integration you would have to connect
the VCS-E to the AD as well. Endpoints (At least for now) do not auth via AD, but you could
either use a h.350 db (could also be hosted with AD) or the local authentication database.
Which is now also propagated by TMS, might be a answer for your issue as well.
Please remember to rate helpful responses and identify
05-14-2012 01:10 AM
Thanks Martin for your answer.
I think I will either one of this ways, depending on the requirements:
I think the answer of the original question is, that if a endpoint is authorized on the Traversal Subzone of the VCS-C, it is treated as unauthenticated on the VCS-E. The call rules treat the endpoint like an unregistered endpoint.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide