10-22-2012 05:32 AM - edited 03-18-2019 12:01 AM
Dear all
I know some Discussion are started answered in the forum, myself also https://supportforums.cisco.com/message/3590491#3590491
but now I cam come allways back with a like similar questions:
I have tried to configure VCS-C and VCS-E with MOVI Authentification via AD and some MOVI user authentification as "Treat as authenticated"
follow Situation:
- TMS 13.2.1
- VCS-C and VCS-E 7.2
- Provisioning with agent legacy
- call Policy Rules on the VCS-E to prevent call to ISDN GW (working fine)
I would like to have a good Security on the VCS-E with a maximum possible Authentification on the VCS-E and
I have now try to configure the VCS's:
VCS-C (is working OK )
defualtZone: do not check credential
default subzone: do not check credential
subzone "MOVI clients": check credential
subzone "local Device" : treat as authenticated (for all internal VC Device)
Traversal Subzone: check redential
VCS-E (problem with Manual MOVI User)
I have configured diffrent Subzone MemberShip rules, so that MOVI via AD in a Subzone with "check credential" and the other MOVI without Password as "treat authenticated"
defaulZone: do not check credential
default subzone: do not check credential
subzone "MOVI clients": do not check credential
subzone "external Manual Movie user" : treat as authenticated (for all MOVI user which are not on the AD can login without password)
subzone "external VC endpoints": check credential (via local LDAP, only for H323 Device)
Traversal Subzone: do not check redential
The Problem which I have is, that all SIP request are going first through the DefaultZone, as soon I have the DefaulZone set as "treat authenticated"
than alls MOVI User (without password) can login, and the MVIA User via AD can login without Password .
if set the Defaultzone to "do not check credential" is working fine for the MOVI via AD but other can not login anymore.
Is really no way to do that in way?
Problem is Customer can not create all User in the AD, 20-30 User are external Partner Companys.
any Inputeappreciated?
Best Regards
Georg
10-22-2012 05:41 AM
Hi Georg,
This sort of mixedd mode authentication isn't supported at present. There is a feature request open for it though -
CSCuc55043
Thanks,
Guy
10-22-2012 05:49 AM
Hi Guy
Thanks for the queick Feedback.
What do you think how is the chance that this will be implemented? and how long will it take?
Best Regards
Georg
10-22-2012 06:08 AM
Hi Georg,
Similar request have come in from a number of places, so there is demand for it. The request is sitting with the product Principle Engineer/Architect at the moment for prioritsation, and then the development and test effort would be on top.
Personally I think it will happen, but I don't know of time scale. I doubt it would be in the next 3-6 months though unless it gets escalated to a higher level.
I have refered to this forum thread on the request so they know the demand is still there.
Thanks,
Guy
10-22-2012 06:13 AM
Hi Guy
Thank you very much.
I hope now it will be escalated to a higher level.
Best Regards
Georg
10-22-2012 08:21 AM
Hello Georg,
I think that you have to force your customer to migrate to TMSPE instead of looking for a solution that you use. If you ask me if it is safe to do that. Yes it is. and this answer is based on the fact that Cisco major customers migrated to this new generation software which proved that is reliable and stable software. Let me put another point here. This is a support forum. You can not ask something to be escalated to a higer level in the forum. As you know there is a procedure which first step is to open a ticket with TAC and if TAC has dificulties to help you they will follow the Cisco internal procedures for escalations ect.
./Teodor
10-22-2012 11:23 PM
Hi Teodor
Regarding Escalation, maybe my English, I know that I can't escalate, I have mean " I hope ":-)
Regarding to migrate to TMSPE, we will do that in the near future.
You have say that this is or could be the solution for my request, what do you mean with them.
Is this correct that with TMSPE all password synchronised in the Provisioning database on the VCS?
But now with them I have allways the Problem with the Mix authentication, some MOVI suer via AD and some via Local database or to set a s "treat as autheticated".
Or exist a Config set with TMSPE which resolve my Problem?
Any help very appreciated.
Do I understand something wrong or not?
Best Regards
Georg
10-23-2012 01:26 AM
Hi Georg
The problem with mixed authentication or by having AD authentication and digest authentication is the Jabber client it self. Even if the VCS is offering both Digest and NTLM the Jabber client is designed to prefer NTLM regardless and then the VCS try to authenticate the user to AD. TMSPE won't fix this issue since the behavior is the same on the client, but I agree its anyway better to step away from the legacy TMS Agent.
The only workaround I know about for this is to have 2 VCS's. One setup for AD authentication and the other setup for Local authentication. Pretty expensive workaround but this is the only way I can come up with unless they change this in Jabber.
As I remember before to login with AD credentials you specified the domain in the username Domain\username. For local accounts you just type in the username without the domain. I don't know when this changed...
/Magnus
10-24-2012 11:53 PM
I am successfully running mixed mode authentication using Subzones and multiple domains on a VCS Cluster.
I have a TMS group that pulls users from AD then another group where local manual accounts are created.
We have a domain for internal staff (company.co.za) and a domain for external staff (contractor.company.co.za)
I have a subzone for Company Staff and another for Contractors each with the required authentication settings.
10-25-2012 12:34 AM
Hi Haydn
So you are able to login with the manual users using the local credentials on the VCS (password set in TMS) and login with the AD users making the VCS authenticate those specific users to AD? All this using Jabber video for Telepresence?
/Magnus
10-25-2012 01:24 AM
Hi Magnus
The contractors Subzone is currently se to treat as authenticated so they can sign in with the username provided and any password.
The staff Subzone is set to Check Credentials and they are check against AD.
I have two Provisioning templates set so that correct domain registration is added when signing in.
I will try set the Contractors Subzone to Check Credentials but I then don’t think that will work.
This is all currently running on TMS Legacy Agent Provisioning.
I will see what I can get working using provisioning extensions.
10-25-2012 02:18 AM
What Haydn says here is correct , as long as you have proper subzone mebership rules then the reigster message will hit the appropriate zone. If the authentication mode is set to Treat as Authenticated then the emessage will not be challenged. The disadvantage of this is that one can sign in with whatever passowrd.
So basically the Contractors accounts are never challenged for authentication.
10-25-2012 02:38 AM
Hi Haydn,
so basically what you are checking is only the registration part and not challenging the initial subscribe messages??
i believe with TMS agent the default zone to "do not check credentials" will work but for TMSPE you need to have default zone set as "check credential".
and then the specific registration challenge would be what you configure on subzone.
But then setting default zone " check credential" wil break the things for you in TMSPE.
Rgds
Alok
10-25-2012 02:52 AM
I will give it a try though..
I will test it in my lab first and give feedback.
If you use TMSPE thought you can setup multiple user groups. So one group’s users could be imported from AD and the other a manually created user group.
MOVI should them be able to check any user then from any group.
10-25-2012 03:43 AM
Hi Haydn,
if you use x7.2 then you can use LDAP and have mixed mode authentication. In this case there would be digest authentication either could be with local database or to any external H.350 directory server.
as pointed earlier in thread by Guy i think its a good feature request for AD direct access.
Rgds
Alok
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